Yes, I know that mobile networks have started going that way - which is why I
asked the question. The reason we (the IETF) cannot possibly pick the same
RFC1918 address space is because those mobile networks now have the problem I
described: when you try to run your VPN client on that laptop, if your
employer's Enterprise private network happens to use the same private address
space as the mobile provider, it no workie. (assuming the VPN connection
succeeds to begin with, of course)
There is nothing the mobile provider can reasonably do about that, short of
charging more money for "VPN-capable" connections as some hotels and access
spots do. Some providers would probably be fine with such a charging model,
but some providers I've talked to don't want to have such a charging model and
don't want to use the 10.x.x.x address space, but don't have much choice since
we haven't allocated a different one.
-hadriel
p.s. I didn't mean "cannot possibly" in the sense of it being technically
impossible, I meant it in the sense of it being a very bad idea. :)
On Dec 4, 2011, at 1:39 PM, Joel jaeggli 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
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf