(6bone) renumbering

[Jeroen Massar]

Michel Py [mailto:michel@arneill-py.sacramento.ca.us] wrote:

> Jeroen,
> 
> > Jeroen Massar wrote:
> > And one can do that with almost a flip of the switch.
> 
> You have to explain me how you do that. I just looked at my home
router
> and a single /48 block appears nine times in the config and related
info
> such as tunnel addresses appears eight more times, so a total of
> _seventeen_ occurrences of addresses related to _one_ of my pTLAs, and
> again this is my home router with only one subnet, not a 
> production one with long access-lists, DMZs and other stuff. 
> 
> What kind of software is it that can read a config, inventory what
needs
> to be changed, change it, and not screw the pooch?
> 
>     | interface Loopback4046
>     |  description loopback for viagenie block
>  1  |  ipv6 address 3FFE:B00:4046::1/64
>     |
>     | interface Ethernet0/1
>     |  description Internal network
>  2  |  ipv6 address 3FFE:B00:4046:1::1/64
>  3  |  ipv6 nd prefix-advertisement 3FFE:B00:4046:1::/64 3600 3600
>     |
>     | router bgp 23169
>  4  |  network 3FFE:B00:4046::/64
>  5  |  network 3FFE:B00:4046:1::/64
>  6  |  aggregate-address 3FFE:B00:4046::/48
>     |
>  7  | ipv6 access-list IPV6-ACL-OUTSIDE-IN permit any
3FFE:B00:4046::/48
>     |
>     | ipv6 prefix-list IPV6-PREFIX-LIST-VIAGENIE-BLOCK seq 5 permit
>  8  | 3FFE:B00:4046::/48
>     |
>     | arneill-py.sacramento.ca.us - 209.233.126.65 - ASN 23169
>  9  | 3FFE:B00:4046::1 - 3ffe:8270:5::1 - 2002:D1E9:7E41::1
>     |
>     | interface Tunnel4046
>  10 |  description tunnel to Viagenie - endpoint 3ffe:b00:c18::8c
>  11 |  ipv6 address 3FFE:B00:C18::8D/127
>     |
>     | router bgp 23169
>  12 | neighbor 3FFE:B00:C18::8C remote-as 10566
>  13 |  neighbor 3FFE:B00:C18::8C ebgp-multihop 99
>  14 |  neighbor 3FFE:B00:C18::8C update-source Tunnel4046
>     | address-family ipv6
>  15 |  neighbor 3FFE:B00:C18::8C activate
>  16 |  neighbor 3FFE:B00:C18::8C route-map ROUTE-MAP-VIAGENIE-OUT out
>     |
>  17 | ipv6 access-list IPV6-ACL-OUTSIDE-IN permit any
3FFE:B00:C18::8D/128

Let's say you wanted, for one reason or another, change over to 6to4 and
have your router at IPv4: 10.100.13.42:

The router:
get config etc. dump it into file 'router.conf'
cat router.conf | sed "s/3FFE:B00:4046/2002:0A64:0D2A:/g"
>new-router.conf
upload the config, restart/reload/reboot it, done.

You do have to update your tunnel to replace it with a 6to4 instance now
though, but "s/3FFE:B00:C18::8C/<new>/g" fixes that for you.
If you had more routers, those routers are very probably 'under' your
main router, receiving routeadverts, which they should pick up.
Otherwise repeat over for the other routers.

The DNS:
Same as the router, dump config and use sed or similar tool to replace
the old subnet with the new one.
A6 records are great for this ofcourse you'll only have to change them
at one place.
The longest time taken will probably be the negotation with your
upstreams for the new address space and ofcourse the reverse
delegations.

I heared some companies keep their routerconfigs in CVS, they are thus
also probably in a state where they can replace their whole config
in one go, issue a upload on all routers et voila.

Ofcourse this all takes into consideration that you don't downsize your
address space, if you do you'd prolly need a completely new numberplan.
In your case you could also do an extra 'sed "s/48/60/g"' which will
downsize you from that huge /48 to a /60 :)
But that's because you are at the 'bottom' (3ffe:b00:4096:0:0:0:0...) of
the address space.

It all boils down how one manages things;

In my case I would have to replace the entries in the dns, update my
tunnel config (nopes no native _yet_ :( here), restart the router
adverts, done.
All the boxes down the trail will eventually pick up the announcements,
deprecate the old prefix and start using the new one.

I know this little story is taken from a very simple case but IMHO it
eventually all boils down on how one manages things, doing a good job in
the first
place makes sure one doesn't have to handle those problems any later on.

Maybe that's why there should be a nice document explaining _all_ the
boobytraps we can come up with.
I very probably missed out a load of them, so call me names and bring
them on. Better find them, document and supply alternatives/fixes now
than
get them right in the face when you come accross them and really need to
renumber. Who can come up with a _big_ case with loads of problems
ofcourse.

One thing which I still haven't seen for example is the 'server' case.
If one does it the 'nice' way and want to use EUI-64 addressing, thus
using the
router adverts to find out and configure there prefix, there is always a
possibility of a NIC going down, hardware breaking etc.
You could ofcourse configure your NIC's MAC address to have a certain
ID, most NIC's can do that anyways.
But it would be very nice if one could instruct the networking layer of
the OS to tell it "use this as an extra EUI-64 id",
which could save up on downtime as now when one box goes down you ssh
into the other, tell it to use the known EUI-64 id and the server is up
again.
One could ofcourse automate this etc. I did say 'extra EUI-64 id', this
so you can always use the boxes real EUI-64 address to gain access to
it.
Otherwise you can't reach it if your webserver comes back online again
;)

Greets,
 Jeroen