On Thu, Feb 16, 2012 at 09:35, Martin Millnert <martin@xxxxxxxxxxx> wrote: > Dear Chris, > > On Thu, 2012-02-16 at 08:43 -0700, Chris Grundemann wrote: >> On Thu, Feb 16, 2012 at 03:43, Martin Millnert <martin@xxxxxxxxxxx> wrote: >> >> > This is 100% matched by an allocation of globally unique space from a >> > RIR, shared by whoever the interested parties are. >> > The IETF *need not* specify any BCP on how to improve NAT444 >> > "CGN"-scale alone, because such action is attached with high risk of >> > leading to a local maximum in a plot of the state of the Internet, >> > rather than towards a global maximum. >> > >> > Citing RFC6264, "An Incremental Carrier-Grade NAT (CGN) for IPv6 >> > Transition" warns: >> > Carrier-Grade NAT (CGN) [CGN-REQS], also called NAT444 CGN or Large >> > Scale NAT, compounds IPv4 operational problems when used alone but >> > does nothing to encourage IPv4 to IPv6 transition. Deployment of >> > NAT444 CGN allows ISPs to delay the transition and therefore causes >> > double transition costs (once to add CGN and again to support IPv6). >> > >> > The draft as written, makes no effort to require the RFC6264 or >> > equivalent approaches to a IPv6 transition, to the CGN deployments it >> > specifies v4 address space for. All carrot, no stick. >> > I believe the state of the Internet would be much more reliably >> > improved by the RIRs each having (for the purpose of being able to serve >> > their own users) one /10 special allocation for this purpose, which they >> > can assign to multiple users upon demonstrating, under contract, they >> > are transitioning to IPv6 according to 6264, or equivalent. >> > >> > As written there is no effort to mitigate the risk mentioned in the >> > quote above, and I can't support a draft that will hurt the Internet and >> > neither should you. >> >> Apologies for my bluntness, but this argument is a complete >> misinterpretation of the facts on the ground. > > Taking: > This draft is not about encouraging nor facilitating CGN deployments. > Allocating a /10 for inside CGN addressing use _will not_ make anyone > deploy CGN who would not have otherwise done so. Not allocating a /10 > for inside CGN addressing use _will not_ stop anyone from deploying > CGN who would have otherwise done so. > + > What we can do, is ensure that when those folks who must deploy > CGN do so, that they break the Internet as little as possible. And > _that_ is what this I-D seeks to accomplish. > > you seem to be of the opinion that improving the feasibility of CGN, by > making it suck less, will not have any impact on potential set of > networks who are deploying it, or in what way they will deploy it. Correct. > You seem to want me to believe that: > - there is a fixed set of networks, who are going to deploy either: > - a sucky IPv4 network, or, > - a less sucky IPv4 network, > - it would be entirely depending on the passing of this draft, > - the failure of passing of this draft somehow will exclude from these > networks the possibility of obtaining non-RFC1918 space in another way, > for example as I outlined > > The latter two points seem a bit far-fetched. Not quite, let me try again. I am stating that: - Dual-Stack requires both IPv4 and IPv6 addresses - There is a non-zero number of networks which will exhaust all available IPv4 resources before the world is able to fully transition to IPv6 - These networks must choose one of either: -- Go out of business -- Find a new way to provide IPv4 connections to customers - NAT44* CGN will be chosen by a non-zero number of these networks - This decision is independent of what addresses they will use inside of the CGN (No one wants to go through two transitions. Folks who deploy CGN do so because they must. As such, the addresses used are an afterthought. The cost of CGN and it's alternatives are what drive the decision, not this I-D or the addresses it seeks to reserve.) > I'm curious how you can possibly have sufficient knowledge to make those > statements as *facts*, rather than opinions, informed as the may be (but > of limited scope -- I think it unlikely you've spoken to every network > on the planet). You are again correct, I have not spoken to every network on the planet. I have spoken to many. Several in the Asia/Pacific region have already experienced the chain of events I outlined above. Further, my job is to understand the IPv6 transition and as such, much of my time is dedicated to creating this understanding. I do not make these claims lightly. > In fact, neither you nor I nor the IETF can stop operators who must > deploy CGN for business continuity from doing so. > > I hold no such illusions. What the IETF ought to do however, IMHO, is > to point them in a good direction. I don't see that happening in this > document. > > A less-sucky IPv4-run-out access network is still a local maxima > compared to the global maxima of DS. > Convince me that our journey to reach the global maxima will not be > negatively affected by this document, and gain my support. Once an operator has decided that they have no other choices remaining and that they must deploy CGN, they then have to decide how to architect that deployment. One of the architectural decisions to be made (and the one we are concerned with here) is what addresses to use within the CGN. They have several options: - Globally Unique "Public" Addresses This option burns addresses that they or others could use to number devices that actually require a unique address, this is a net loss to the Internet. - RFC 1918 "Private" Addresses The chance for collision and the low margins of residential broadband make this option a non-starter. Nothing any of us say will convince any substantial number of operators to shoot themselves in the foot in this way. - Class E Addresses Too much equipment is hard coded to reject these addresses. It simply will not work in time to make a difference. - "Squat" Addresses Without a shared address space, this is the likely winner. Squatting on someone else's address space works and is free. A misconfigured filter allows these to leak however, another net loss to an un-borked Internet. - "Shared" Addresses This is the solution put forth in the I-D under discussion here. This allows an alternative that is attractive to operators and can be managed (since it is a known prefix). If one operator leaks routes, others will have filters in place. This option removes the least amount of addresses from the remaining free pools thus allowing Dual-Stack to work in the most possible networks. All in all, this is the best way to ensure a less broken Internet than any of the other options can provide. Again, we are not talking about encouraging or discouraging CGN use, that is outside the scope of this discussion. What we can do is "point them in a good direction" when they must deploy it... Cheers, ~Chris PS - See https://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#section-2.2 for a more detailed analysis of these alternate options. > Kind regards, > Martin -- @ChrisGrundemann http://chrisgrundemann.com _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf