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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf