Hi Chris, On Thu, 2012-02-16 at 10:09 -0700, Chris Grundemann wrote: > On Thu, Feb 16, 2012 at 09:35, Martin Millnert <martin@xxxxxxxxxxx> wrote: <snip> > > 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. .. except for the part of actually changing what addresses they put on the inside, which the I-D is about. Perhaps it's splitting hairs whether that constitutes a "change" or not, but if it's not a change, it's weird that it would improve the quality of the network. :-) <snip> > 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.) In the end, I suppose, networks who do not also roll-out DS in combination with NAT44* CGN, are a blessing for their competition... where such competition physically exists. > > 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. Check. (I'm aware, as well.) > 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. Cool. I haven't/certainly didn't mean to suggest you did. > > 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. Not seeing a limitation to NAT444, you left out various alternatives which have integrated IPv6/DS. Alternatives which, once installed, will lead to a steady (comparing with the v4-only case) reduction in load on the CGN equipment, as the world increasingly moves towards DS/v6-only. Such alternatives may not apply to the CGN variant NAT444, which I ACK the I-D addresses. > 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... I agree, and would like the direction we point them in to include the case for DS. There's always the risk there are very ill-advised networks around, who push through such upgrades without simultaneously enabling (a gradual roll-out of) DS, perhaps for nothing else than lack of sufficient knowledge! Thanks! Best, Martin
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf