On Dec 4, 2011 10:40 AM, "Joel jaeggli" <joelja@xxxxxxxxx> 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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf