You may have received an answer to this already, but I am just catching up and since you asked for help understanding, I thought I would provide some context.
The RIR community is being spun up that ULA-C is nothing more than PI because some members want to retain control over who has addresses and how much. PI is a hot issue because there is a potential impact to the global routing system if it runs unchecked. ULA L or C is about a space that is not intended to show up in the global routing system. As such it should not have the same restrictions over who can have it that PI would have. Yes an organization with PI could implement an acl or simply limit the length of the prefix that is announced to routing and have the same effect ---from their perspective---. From the perspective of the rest of the world though, it is not clear if a PI block is intended to be globally routed or not so they can't filter it arbitrarily. ULA has the upfront global expectation that if it shows up it is a bogon that should be filtered. ULA-L is targeted at the soho router default config and organizations that just don't want to deal with the RIRs. Their probability of collision is low enough relative to their likelihood of multiple connections that it really doesn't matter. ULA-C is about organizations that really want to have public bogon filtering to help restrict access to a given network, but also want to ensure that future mergers and acquisitions or partnerships that form will not have any possibility of collision. This should never have been a big deal, but when all the RIRs were refusing to allow any PI space ULA-C was seen as an end-around that policy. Even now, only ARIN & APnic allow PI, so ULA-C is still perceived to be a problem for the DFZ. My suggestion to both the RIPE and ARIN communities has been to embrace ULA-C and give every member a ULA-C block in addition to whatever else they ask for. If they don't own the space someone will, then there will be competing registries and a real risk that ULA becomes PI due to easier access or lower cost. If a ULA-C requires RIR membership, the member can choose whatever space makes sense for their deployment and all this RIR/IETF noise will not matter. Tony > -----Original Message----- > From: Kevin Kargel [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 19, 2007 1:11 PM > To: [email protected] > Subject: RE: draft-ietf-ipv6-ula-central-02.txt - reverse DNS > > I fail to see the point of mandating non-routable space with allocated > ULA-C. Any network administrator has the ability and freedom to not > route as much or as little of their PI space as they want. Why force > constraints on usage? > > If they are going to link two physically seperated sites (into a WLAN > or > MLAN for example) with 'private' IP's then isn't that just access- > listed > PI? > > Please explain to me what you could do with ULA-C that you can't do > with > PI and an ACL. I really want to understand. > > The only possible use I can figure is so that soho router manufacturers > can have something to hard-code in to their LAN/DHCP defaults, but even > then there would have to be a subnet parameter passed to the router by > DHCP unless one was going to assume that the WAN network was the entire > PI space. > > Thanks in advance for the constructive education. > > Kevin > > > > > > -----Original Message----- > > From: Pekka Savola [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 19, 2007 2:41 PM > > To: Jeroen Massar > > Cc: Thomas Narten; Mark Andrews; [email protected] > > Subject: Re: draft-ietf-ipv6-ula-central-02.txt - reverse DNS > > > > On Tue, 19 Jun 2007, Jeroen Massar wrote: > > > What is the point of that? How can a ULA address reach a global > > > unicast address or for that matter, how is such a ULA > > address, which > > > is most likely going to be the sole user of those reverse servers > > > going to contact any of the root servers, .arpa servers, > > RIR servers > > > etc to actually find out where that server is located in > > the first place? > > > > > > Are those people going to do NAT from their ULA space? Then please > > > directly kill this whole ULA proposal completely. If NAT is > > involved > > > in anyway it should never see daylight. > > > > I do not know the intended deployment scenarios, but in many > > cases where I'd expect ULA-C migth be deployed, I'd expect > > such sites to have some global addresses as well for v4, v6 > > or both (maybe at a different physical site, just for a > > couple of infrastructure servers instead of all hosts, etc.) > > > > You're right that if a ULA(-C) site would have no global > > addresses whatsoever, reverse-DNS delegations can't be done. > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [email protected] > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
