On Dec 4, 2011 11:06 AM, "Hadriel Kaplan" <HKaplan(_at_)acmepacket(_dot_)com>
wrote:
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)
Started? I would say most mobile data networks started with rfc1918 at the
inception of WAP mobile data services nearly 10 years ago and have stayed
that way, replacing WAP proxies with CGN 5 years ago. This is not a novel
problem.
Regarding enterprise vpns, the client VPN abstracts the host routing to
make this work. I am not sure which part you don't understand. You do
know 1918 is in most home networks and most enterprises and it just works,
right ?
Sorry if I misunderstand your concern.
Cb
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf