I would have thought that router renumbering should be no
harder that host renumbering. Essentially all you are
changing is the higher (/48 normally) prefix bits. All
that is required is a method to distribute the set of
prefixes in use with a set of tags (global, deprecated,
ula, advertise in RA, etc.).
Everything else should flow from that set. Firewall rules
should be using that information as it really doesn't matter
which global prefix a host uses to talk to the world. They
are all essentially equal.
I may we be showing my ignorance here but I don't believe
that this really is a "to hard" job.
Mark
> Jeroen Massar wrote:
>
> > The above hosts are Internet connected and most likely will thus also
> > end up
> > talking to the Internet at one point or another. I can thus only guess that
> > they will be wanting to fully connect to the Internet one day and the
> > generic solution to that problem is NAT. We wanted to get rid of NAT for
> > IPv6. If NAT is again being done for IPv6 then we can just as well give up
> > and just keep on using IPv4 as there really is not a single advantage then
> > anymore to IPv6.
> >
> >
> I think what we wanted to get rid of in IPv6 was one-to-many NAT, also
> know as PAT (among other names). In IPv6, we can stick to one-to-one
> NAT, which eliminates most of the nastiness we associate with NAT in
> today's IPv4 world.
>
> > But see below for a scenario that might have actual merit here.
> >
>
> > **SCENARIO**
> > One possible scenario could maybe be: use ULA-C local in your local site,
> > use global (PA) addresses from the upstream ISP, from whom you get a /48
> > too, thus the number plan is the same, just different first 48 bits. Every
> > host gets a ULA and a PA address. The PA address might change when changing
> > ISP. RFC3484 and related work can be used to configure preferring what
> > address to use. Then you never need to reconfigure your local network and
> > local addresses are globally unique and can use the Internet.
> >
> > The big thing there is though: configure your firewalls correctly as the
> > public addresses do also allow access to everything.
> >
> I don't think routers are at the point yet where you can easily renumber
> your routers' interfaces when your PA addresses change. As a result,
> networks wanting to avoid the pain of renumbering, but who don't qualify
> for PI and a global routing slot, might want to do something similar:
>
> Say a network gets a ULA-C block, and numbers everything on their
> network out of that block. They later connect to the Internet, and get
> a PA block from their upstream, and configure it on their border
> routers. To avoid reconfiguring all their routers every time they
> change upstreams, they configure one-to-one NAT on their border routers,
> such that every address on their internal network (which is ULA-C) maps
> to the same address, except with different first 48 bits, in their
> provider-allocated block.
>
> This wouldn't present the same kinds of problems you'd get from
> one-to-many NAT, but I'm sure there are some ways where this wouldn't be
> as good as PI space. However, my first-order evaluation is that it
> would be better to have small networks achieve their provider
> independence this way, rather than by relaxing the PI rules and
> threatening the scalability of the current routing system with a large
> number of additional non-aggregatable netblocks.
>
> Now as expressed earlier, most ULA-C use cases probably won't involve
> NAT. But if people do elect to use NAT with ULA-C, what problems do you
> see with this kind of use of NAT? Do you see those problems as worse
> than the problems caused by completely rejecting the original PA-only
> architecture of IPv6 in favor of PI-for-everyone?
> > Still, the above can also be accomplished perfectly fine with PI space and
> > that doesn't require any changes (except RIPE+APNIC policy) to be done.
> >
> >
> I agree that PI space, if it were widely available, would meet the same
> needs as ULA-C. However, I think we need to be realistic that
> PI-for-everyone won't fly, and need to think creatively about ways to
> achieve the same goals (such as provider independence) in such a way
> that we don't impose more public cost than private benefit.
>
> Another thing to consider when evaluating whether to specify something
> like ULA-C is that we can't know what kind of innovation it will make
> possible in the future. Therefore, the question we should be asking is,
> is there any remaining reason *not* to allow networks to register ULA-C
> space? When it was last proposed there was: it was thought that
> networks would get ULA-C and use it as PI space. Now, since PI space is
> readily available to multihomed networks, that is much less likely. As
> a result, I am in favor of allowing small networks to register their own
> unique private space, as this draft would do. I can't predict how ULA-C
> will be used, but I'm confident that innovation is a good thing, and
> that we can safely open up the ULA-C sandbox to networks who wish to use it.
>
> -Scott
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
