Re: IPV6 renumbering painless?

[Owen DeLong <owen () delong com>]

--On Thursday, November 11, 2004 11:37 AM -0500 Leo Bicknell 
<bicknell () ufp org> wrote:

> In a message written on Thu, Nov 11, 2004 at 04:22:28PM +0000,
> Michael.Dillon () radianz com wrote:
> > Correct me if I'm wrong, but doesn't IPv6 do away
> > with the need to renumber when switching providers?
> > So if RFC 2462 is right, and you use DNS outside
> > your network and you update that DNS at the moment
> > of switching providers, everything on your network
> > automatically acquires new IPv6 globally routable
> > addresses as soon as the gateway router is connected
> > to the new provider. Seems to me that with a little
> > bit of help from a "Change providers" tool, this
> > would be virtually painless without the need to
> > own or announce a small globally unique prefix.
>
> That is how it has been designed, however there are some practical
> problems with this system:
I still think that we should pursue making the design work and not adopt
cruft as standards (ULA).

> - Until very recently DNS software did not support A6 records at
>   all, and "chain" support for A6 records still seems to be a work
>   in progress.
This is getting resolved and I suspect will be long since functional by
the time v6 comes to widespread deployment consideration.

> - I presume the problem with using DNS to find your DNS servers is
>   obvious, so you probably still need a mechanism (static config,
>   DHCP) to push out nameserver addresses to all boxes at some point
>   in the cut over.
If you're willing to use DHCP, then, why not use a similar helper mechanism
to find the resolver... Host that doesn't know it's resolver or can no
longer reach it's resolver sends some form of a standardized "Who's
my resolver" query to the link-local broadcast address.

        If there's a resolver on the local link, then the resolver(s)
        respond "I am."

        If not, the router is either configured with resolver addresses
        and can respond "They are." or is configured with a resolver-helper
        address which would function identically to the current dhcp-helper
        addresses.  In this case, as long as the router had an interface
        on a link which contained a resolver, no reconfiguration of the
        route would be necessary, since it could use the resolvers link-local
        address.  In fact, the router could dynamically learn the resolvers
        through a similar mechanism.


If your organization is large enough to involve reconfiguring a significant
number of routers, it is unlikely to be small enough to have to use PA
space instead of getting PI space in the v6 world.

> - This solution works only to update the interface IP address on
>   a box, and does not address any of the other application
>   configurations that might need to be updated, including but not
>   limited to:
>
>   - ACL's on the box or routers to allow/disallow the new network.

	I would argue that ACL's in the v6 world should probably include A6 
support.

>   - Network analysis tools to include the new network.

	Again, no reason these can't be based on A6 resolution instead of 
hard-coded
        IP addresses.

>   - IGP or BGP configuration to include the new network.
        If you are large enough for IGP configuration for the new network to
        be a major undertaking, then, you probably qualify for PI space.
        If you are large enough that BGP is more than a couple of routers
        that need changing, you probably qualify for PI space.

> - Also note, if you are unable to have the two services overlap
>   (eg, must disconnect from the first, and then hours, days, weeks)
>   connect to the second you have the potential to lose access to
>   all your boxes locally in the mean time with this system.  The
>   solution is some sort of site-local/1918/ula address overlay.
        ??? Why not simply perform the address switch somewhere in the
        middle.  You should be able to get the prefix for use with the new
        provider some time before the link comes up, and, if you're disconnected,
        there's no harm in continuing to use the old provider's prefix during
        that time.  This makes no sense to me.

> It is the last point that leads to the most interesting problem.
> If you create a local overlay network to always maintain access to
> your local boxes, then is it actually easier to push out an additional
> IP address to every end box, and update your IGP, firewall rules,
> and other configs, or is it easier to run NAT at the edge to convert
> your local network to public IP's?
If you take the last point as a given, but, to me, the last point seems
irrational.  I still think NAT is evil cruft that had a purpose in the V4
world, but, is highly undesirable in the v6 world.

Owen


--
If it wasn't crypto-signed, it probably didn't come from me.

Attachment: _bin
Description: