On Dec 4, 2011 11:06 AM, "Hadriel Kaplan" <HKaplan@xxxxxxxxxxxxxx> 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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf