On Dec 4, 2011 10:40 AM, "Joel jaeggli" <joelja(_at_)bogus(_dot_)com> 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
An additional fact is that Verizon reuses 10/8 across their network, 10/8
per region.
Net net, rfc1918 is used in cgn today. Squat space is also used in cgn
today. Making an allocation creates another permutation of how cgns are
deployed.
Furthermore, a /10 is not a large enough allocation to be the one solution
everyone can converge on.
Cb
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