(headers trimmed) > From: Scott Leibrand <[EMAIL PROTECTED]> > > Paul Vixie wrote: > > please re-think this in terms of "connectivity realms", of which the DFZ > > is one, and the american automotive exchange is another, ..., and every > > ad-hoc wireless mesh is another. ... > > ... I'm not sure that we can simply see the public Internet as just another > connectivity realm. I believe that the history of the Internet, and the > architecture we have built up to support it (particularly the addressing > architecture, as defined by the IETF and delegated from IANA to the RIRs to > ISPs and to end sites), require that we consider the public Internet to be a > unique connectivity realm.
assume for a moment that FC00::/16 becomes reserved for "non-public internet" due to actions by IETF, IESG, and IANA; assume furthermore than some RIRs ask IANA for /32 slice of this and adopt policies allowing their members to request /48 allocations. assume that fred templin gets one for his laptop and manages to speak a routing protocol with every wireless cloud operator he sits in, so that for each of those AS's, his /48 is "reachable" by other folks in the same AS. what would stop these wireless cloud operators from privately peering with each other and turning off the filter that we all hope normally prevents FC00 routes out of BGP? we know they will want to do this, just as they want to share RADIUS and towers -- it makes the wireless world appear to be more unified and means more revenue for everybody. now assume that someone like ISC or CENIC is present at a peering exchange and one of these wireless ISP's solicits a BGP relationship with us. would they want to send us their FC00 /48's? you betcha! would we want to take them? you betcha! the only time these /48's aren't likely to be accepted or offered is by a transit provider. in private peering relationships, they'll be seen as a value-add by most peers. which connectivity realm is the "public" one in that scenario? is it the one that includes more reachable places? or the one we _call_ the "public" one? > ..., any connectivity realm that approaches the public Internet in terms of > the number and diversity of interconnected participants will require an > addressing and routing framework to meet the various needs of its different > participants in a mutually acceptable manner. the wonderful thing about the internet is that plans don't matter. what exists is whatever a lot of people decide to do. for a lot of people, accepting /48's from their peers will make good "cost:benefit sense". for others, not so much. so, address space in FC00::/16 will not be as reachable by some as by others, and thus won't be as valuable as other address space that's more universally reachable. however, to call it "private" is an exceptional misnomer. it'll be advertised among consenting networks, and it will work for a lot of users and a lot of applications. when it doesn't work, all heck will break loose, just like today when "public" address space goes unreachable for some people. > As long as we're talking about IPv6, that addressing framework will need to > coexist with the addressing framework of the public Internet. Given the > current Internet addressing architecture, that means we need some way to > partition off part of the IPv6 address space, designate it as "not to be > routed in the DFZ", and assign pieces of that space to anyone wishing to > internetwork in a connectivity realm other than the DFZ. we can designate it any way we want. let's designate it however we have to designate it in order to start using it. then we'll find out the real facts, because real users will do real things. if the DFZ must be ostensibly defended from two million /48 end site announcements, then let's ostensibly defend it. however, just privately, just among the smallish subset of folks who read this mailing list, we all know that the DFZ fiction will simply get more fictional. to the meat, then: > > 7. all global-scoped addresses need ongoing reliable DNS and WHOIS support > > 8. address DNS/WHOIS support is traditionally a regional, bottom-up function > > Agreed, which is why I advocate that ULA-C space (or whatever we end up > calling the space that fills the needs described above) be assigned to > Regional Internet Registries (RIRs), who can then assign it to end users > and provide appropriate DNS and WHOIS support. ok by me. > I would also support allowing the RIRs to allocate such non-DFZ-routed space > to Local Internet Registries (LIRs), so that they can serve their members / > customers by reassigning such space and providing DNS and/or WHOIS services > in a method (and possibly a connectivity realm) not served by the RIRs > directly. also ok by me. > ... I would draw the following conclusions: > > * There is a need to allocate and assign IPv6 address space, in a > non-restrictive manner, to entities wishing to internetwork > outside of the public Internet's DFZ. > * There is a need to provide reliable DNS and WHOIS support for > these addresses. The methods of providing such DNS support should > include, but should not be limited to, allowing registrants to > delegate DNS authority to servers reachable from the public > Internet. Other methods for providing reliable DNS support for > these addresses should be explored, but no method should be > allowed which imposes an undue burden on Internet DNS infrastructure. i'd say "from both its own connectivity realm and from the DFZ" where you've said "the public internet" above, but otherwise, i can live with that summary. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
