On 12/4/11 11:06 , Hadriel Kaplan wrote:
Yes, I know that mobile networks have started going that way - which
is why I asked the question.
It's not a question of starting. outside of some small number of
developed economies mobile carriers and a number of wireline providers
were always depolyed that way, or out of squat space however bad an idea
that may have been.
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)
the vpn connection is going to work, it's being established against a
public endpoint. the risk for a collision between the resulting routing
tables is scoped to the netmask of that outside interface.
enterprises have a lot of experience with this, it's a necessary
consequence of supporting mobile users whether they are wireless or in
hotels.
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