no renumbering event is "too hard" in isolation ...... BGP peers, MRTG/CRICKET monitoring, AAAA/ACL configs, syslog all come to mind as issues/considerations for router renumbering.
and remember tht the router is the distribution engine.... of "the set of prefixes in use with a set of tags (global, deprecated, etc) one has to be very careful about "catch22 situations, deprecating the in use prefixes before the new prefixes are in use. operationally, renumbering DNS/DHCP servers is a whole lot easier. --bill On Wed, Jun 20, 2007 at 10:41:33AM +1000, Mark Andrews wrote: > > 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 > > ipv6@ietf.org > > 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 > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
