On Dec 4, 2011 10:40 AM, "Joel jaeggli" <joelja(_at_)bogus(_dot_)com> 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(_dot_)list6(_at_)gmail(_dot_)com> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf