Re: [RRG] Renumbering...

[Eliot Lear <lear@cisco.com>]

Stephen Sprunk wrote:
> We _already_ have a scalable solution that requires end-sites to 
> renumber: RFC 4192.  The target market rolled their eyes and got the 
> RIRs to change policy to allow PI assignments in IPv6, just like in 
> IPv4, rather than even give it a try because the very concept was so 
> unacceptable.

As one of the co-authors of that document I believe we may have failed 
to communicate its intentions clearly.  That document doesn't exist to 
say that renumbering is easy or even particularly scalable in any 
engineering sense, but rather it provides  a method that has been shown 
to functionally work.  If you read it in this light I think you will 
find that it is quite involved and could take many months to renumber 
sites because of information retained in configuration files that needs 
to be sussed out.  For instance, we talk about the use of packet 
analyzers to spot this stuff.  That's quite manual.

This having been said, we also hoped that the document would be a call 
to action on improving renumbering and no matter the RRG's decision (or 
anyone elses') here, I still think those improvements would be a good 
idea.  PD is a big leap forward but wasn't sufficiently deployed at the 
time of writing.  Even with PD, addresses and prefixes live on in many 
static places.  Those places need to be abstracted.  Similarly, the 
cases where addresses MUST live (like DNS) require substantial care and 
feeding to allow for automated interactions.  That's not easy, because 
it involves establishing trust relationships and mechanisms.

And there are several cases to consider:

1.  NS delegation mechanism

Both forward and reverse mappings need to change.  Both NS delegations 
will need to be changed.  This is often times cross organization, 
dealing with one group for forward and one group for reverse.

2.  Hardcoded addresses in the nameserver configuration itself.  This 
typically impacts people's secondary configuration.  All of these need 
to change.

3.  The DHCP configuration for various scopes needs to take into account 
PD.  This is no small task.

Many of these steps are interwoven, and what RFC 4192 *does* do is talk 
about the order in which to execute tasks.

Eliot


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg