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
[email protected]
https://www.ietf.org/mailman/listinfo/ietf
