Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd)

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 18-jun-04, at 23:06, Pekka Savola wrote:

> IMHO, making sure that renumbering a network is as simple as it can be
> is a subject which is very much related to multi6 designs.. and IMHO
> an operational requirement if we wish to deploy a model where we might
> envision populating hosts on a site with multiple addresses.

> So, review of the v6ops document describing a renumbering procedure
> would be very much appreciated.  Please send the comments on v6ops
> list!

Ok, first comment is relevant to multi6:

Having two prefixes at the same time lands you squarely inside the 
domain of draft-huitema-... The draft now assumes that having both old 
and new addresses works, and this isn't an assumption you can just 
make. In the case of changing addresses where both address ranges come 
from the same ISP this could be the case, but I don't see how this 
would be a regularly occurring event (after the 6bone has been shut 
down). In the case that both prefixes come from different ISPs, the 
network essentially becomes multihomed periodically, so it suffers all 
the ingress filtering trouble that we've been discussing in multi6. The 
draft only talks about ingress filtering with regard to security, which 
IMNSHO is stupid because there are no attacks that are possible with 
spoofed addresses that aren't possible with unspoofed addresses. It's 
just that tracking the attacks down takes longer. The real issue is 
that you MUST deliver packets to the ISP that matches the source 
address or you have no connecitivity. There are three ways this can 
happen:

1. disable ingress filtering for one ISP and route everything over that 
ISP
2. use policy routing or some other source address based routing to 
route packets to the ISP matching the source address
3. have a flag day

Talking about flag days: I'm missing a discussion on making use of the 
possibility of deprecating a prefix when stateless autoconfiguration is 
used. This mechanism makes it possible to move all new (outgoing) 
sessions to a new prefix in a couple of minutes.

All in all I think this draft is suffering from lack of ambition. 
Either provide some real guidance rather than a bunch of truisms or 
drop the whole thing.

As I'm feeling generous today here's a partial list of suggestions in 
the area of renumbering that people usually only get to read after 
paying $40 or so:

- register the new addresses for authorative nameservers with all 
pertinent registries as soon as the nameservers are reachable over the 
new addresses
- there are two ways to change server addresses fairly painlessly: 
lower the DNS TTLs and do it at once, or run two addresses side by side 
for a while. The latter is usually more work but can be done without 
any interruption at all
- log (attempted) use of the old addresses to see whether everything 
has switched
- turn off the old addresses for a while to flush out the last users, 
then turn them back on again so those last users get to change over 
without too much network interruption
- when the old addresses are removed, do traceroutes in various places 
to see if they're really gone