On Dec 4, 2011 10:40 AM, "Joel jaeggli" <joelja@xxxxxxxxx> wrote: > > > 10.170.127.192/27 link#12 UCS 2 0 en3 > 10.170.127.193 4c:47:45:56:44:58 UHLWIi 422 34 en3 > 1197 > 10.170.127.207 127.0.0.1 UHS 0 0 lo0 > And "Cameron Byrne" <cb.list6@xxxxxxxxx> wrote: An additional fact is that Verizon reuses 10/8 across their network, 10/8 per region. Net net, rfc1918 is used in cgn today. Squat space is also used in cgn today. Making an allocation creates another permutation of how cgns are deployed. Furthermore, a /10 is not a large enough allocation to be the one solution everyone can converge on. [WEG] I don't believe that anyone is suggesting that any one size of block fits all. I fully expect that networks of sufficient size would end up reusing the shared space multiple times for multiple NAT regions just like they would 1918 space. I also don't believe that the IETF could ever formally recommend using squat space given the known breakage cases that exist, especially since the party subject to the breakage may not be involved in the discussion of the calculated risk being taken. Put another way, existence proofs don't make it any better of an idea or reduce the risk of breakage. This leaves either GUA space, which we're ostensibly trying not to "waste" on things that shouldn't use up the precious resource, or 1918. I don't think that anyone on here is saying that it's completely impossible to use 1918 for CGN. I think they are saying that it has enough breakage cases that it's not possible to say that it's good enough for all cases by itself. Just as you say above that the size isn't good for all, you have multiple operators saying that 1918 as a solution is not good enough for all, along with technical and operational justifications as to why, and it mainly sounds like this is a question of whether "IETF knows best" trumps those justifications in determining whether they're legitimate problems or not. Also, independent of whether VPN works or does not work if the host is using 1918 space + NAT, there is an important distinction on the wireless CGN using 1918 example that covers the other breakage case: It's NAT44 in wireless (device directly to CGN), and not NAT444 as it would be in most broadband applications. It's only when you start talking about using a mobile device for connection sharing (MiFi or Phone WiFi hotspots, routers with LTE cards in them instead of wired uplinks, etc) that you're really comparing the two in a way that's directly applicable, since then you could have: [local 1918 segment] -LAN- <SOHO/res NAT router> -WAN- [CGN 1918 block] -- <CGN> -- [PublicIP] If these hotspot devices are doing NAT444 with private space on both LAN and WAN, vs doing NAT444 using Squat space on the WAN side vs doing NAT44 with a public address on the WAN side, that'd be good information to have, as it may be an existence proof one way or the other regarding whether having 1918 on both sides of a CPE "router" actually works. However, it's worth noting that in most cases, the mobile provider owns the device being used as that intermediary, so they can explicitly configure and test it to ensure that it functions correctly in the case where there is 1918 addresses on both LAN and WAN interface. There's no way to make that assumption with customer-provided CPE. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf