Brian E Carpenter wrote: > On 2007-07-09 13:58, Jeroen Massar wrote: > ... >> >> Now I do see another use for this kind of address space, but then it >> should not be called this way. It could be used for ID/LOC solutions, >> where these kind of addresses are Explicit-non-DFZ addresses. But if >> that is the reason for what folks want to use them, as that is what I am >> sort of reading between the lines as actual real usage has still not >> been identified, then please just state that. > > I believe that ULA-G as proposed by Paul is an interesting candidate > for unrouteable EIDs in the sense that the LISP proposal defines "EID". > But that conversation belongs on another list.
I fully agree with this and I also support this route. But then don't call them ULA or assign them any functionality in this area which is completely misleading. Call the beast what it is supposed to be called. > However, if we're worried about keeping /48s out of the DFZ, I agree > that it really doesn't matter whether they're called "PI", "ULA", > "2002::/48" or simply /48 holes in PA prefixes. It's the ISPs who > will keep them out, or let them in, not the IETF. Indeed. If we are going to carve a block out which should never show up in routing tables (except maybe site internal ones etc), then give them the name that they should have and the description that they should have. Assigning this /8 as something which is not PI but is PI is only ambiguous. Giving them the a name like "EID" and stating that these are not to be used for routing in the DFZ, but can be used globally with the help of an upcoming protocol which does an ID/LOC split does make sense. It then all of a sudden is also logical that these blocks will need reverse DNS delegations, as they will be used _on_ the Internet, but just not _routed_ on the Internet. IMHO it is thus much better to put this ULA-C proposal on ice and await the requirements and structure that that the upcoming ID/LOC proposal. Although, I guess that they will be quite like what Paul proposed in delegation structure, but the description of the addresses and the name will be different and more appropriate to what they will be actually used for. The above is also why I say "/48's are not a big problem", as when the routing tables get too large, ISP's will start filtering, forcing the /48 PI users to start using their address space as EID's. Having a special block which solely restricts this is of course a good thing. The RIR's can then easily explain "these kind are EID's and are 'cheap', while these kind are accepted in the DFZ". Now what the RIR's policies will be on who can get what kind of addresses is of course to be questioned and something the RIR's will have to fight out with their membership. Greets, Jeroen
signature.asc
Description: OpenPGP digital signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
