On Dec 4, 2011 10:40 AM, "Joel jaeggli" <[email protected]> wrote: > > On 12/4/11 08:48 , Hadriel Kaplan wrote: > > Hi Victor, Yes that helps, thanks - it confirms what I had always > > assumed was the case but could not grok from the discussions on this > > list nor the draft. > > > > Because the new address space is actually seen/used by the consumer's > > interface, we cannot possibly pick a "safe" RFC 1918 address nor > > 240/experimental space, for the reasons I stated in my email. We > > *have* to allocate a new space. > > It's an absurdity that the clearly impossible is in fact the defacto > deployment model. > > this is a verizon 4g card... > > en3: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1428 > ether 64:99:5d:fd:b2:d4 > inet6 fe80::6699:5dff:fefd:b2d4%en3 prefixlen 64 scopeid 0xc > inet6 2600:1010:b005:c97d:6699:5dff:fefd:b2d4 prefixlen 64 autoconf > inet6 2600:1010:b005:c97d:b963:23e7:3ae1:e287 prefixlen 64 autoconf > temporary > inet 10.170.127.207 netmask 0xffffffe0 broadcast 10.170.127.223 > media: autoselect (1000baseT <full-duplex>) > status: active > > > 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 >
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. Cb > > Furthermore, I would suggest the draft include the following in > > section 4: "Administrative entities other than Service Providers MUST > > NOT use the IPv4 address space reserved for this use. An example of > > why this would be a problem is if an Enterprise's internal private > > network used this address space and the Enterprise someday wanted to > > provide remote employees with VPN access to the private network, then > > any employees connected to any Service Provider anywhere using the > > same address space would not be able to VPN in to the local > > Enterprise because of the resulting overlap in their local device's > > routing table." > > > > -hadriel > _______________________________________________ > Ietf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
