Paul Vixie wrote: >> Without going into debate about consenting adults, and while I might >> disagree with Paul in certain fine points, I'd suggest that we consider the >> ULA-G proposal within the IETF and ask that Paul submit it as an I-D. ULA-G >> could have broad application if in fact we solve the multihoming problem >> (IMHO) and I'd like to be the optimist and say that we can do that. > > i'll need new coauthors. i ain't signing up for this alone, and the authors > of ULA-C only wrote it up so that we would all know what ideas had been > abandoned, not as a way forward. And in another mail wrote: > i'm at the "ignore ietf now" stage with things like DNSSEC DLV, and > it's going to come as no shock to me if SIXXS is at the "ignore ietf > now" stage with ULA. My view on the ULA story and for that matter any address space being given out is much simpler and it has nothing to do with ignore, it has to do with what is realistic. That "ULA registry" is just to demonstrate that a very cost effective (aka 0.0EUR cost) way can be setup where people can register their prefixes if it really is so important for them to have that little bit more certainty that they are 100% unique instead of the collision probability of 4.54*10^-05 even when having 10k connections to other ULA sites. If IANA would want to run similar code I am very happy to provide them with the details etc on how to do it, though I am fairly sure they can easily do it themselves too. Currently organizations need IPv6 address space. ARIN/APNIC/AfriNIC allow them to get a nice /48, or larger if they can justify that. In RIPE land you just become LIR and get a /32 along with it. This allows them to deploy IPv6 today. As for organizations wanting 'disconnected' address space, just go to your RIR and get it. There is (except for AfriNIC) no requirement anywhere to announce the space in the DFZ. If you don't want to go to an RIR, go to an LIR who have a /32 and just ask them for a /48, and pay them a 100 EUR or something for 'administrative fees' or whatever. That is why LIRs exist. This is also what happens today with IPv4 address space. IMHO The /48 "PI" thing is a good thing. Except that in my view of things in a year or 10-20 they won't be floating in the DFZ any more. The DFZ as we know it will be a real Tier system. Only the "Tier 1s and Tier2s", the current organizations who get the /32's and up will be in there. All the 'small' parties, thus the /40 - /48's will be using a non-BGP method of connecting up to the Internet and thus won't contribute to DFZ re-calculations. Routing will become more 'geographic', the only thing you will need to know is that "Organization X is a customer of transit Z and Y and they prefer Z", you have a BGP route to transit Z and simply send your packets there. When transit Z flaps around, then you only need 1 update, not 100000, which are their customers. Still you will have some state which can be updated in near-real-time, where X will say "please send packets destined to me preferably over Y" or "Transit W is now our preferred transit, use them please". In my vision the /48s being given out as "PI" today can be used for the ID portion, while every transit will give a "location" /48 to the site that needs it. Over the DFZ the src/dst will be in DFZ/location style, but when it arrives at the endsite it will be in PI mode again. NAT (that evil thing) is useful and when you do it twice you actually still have the same packet and have achieved a tunnel without the overhead of it. The signaling of what to use is the tricky part though. See ram@xxxxxxx for more of those discussions. Those folks are doing good work. It might indeed not be ready tomorrow, not next year, maybe not in the next 10 years, but really current routing hardware will scale up to that. Remember, only 900 IPv6 routes today and only 1517 prefixes have really been allocated from the RIRs to the ISPs and I don't see another 200k popping out of nowhere anywhere soon. I could be very wrong of course though :) Who can be Tier1 or 2 will then be determined based on cash, connectivity and weight; eg YouTube and Google for instance can do pretty much they want, if they do www.google.com A 1.2.3.4, 1.0.0.0/8 will most likely quickly be theirs, just because otherwise you will have your customers whining that you broke the Internet. Greets, Jeroen
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf