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 > 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 Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf