Re: Heads up - Plea for allocating a /8 to ISPs

Thanks, James, for this detailed explanation.

It has a substantial technical content, something that, IMHO, has been missing so far in this discussion.

Actually, I am now convinced that if ISPs would use a reserved /8 where they use a 10/8 today, they would create new problems possibly even worse than the solved one.

I therefore change my mind and no longer support the idea of a new reserved /8.

Best regards,
RD


Le 11 nov. 2010 à 13:15, james woodyatt a écrit :

> On Nov 10, 2010, at 19:31, Brian E Carpenter wrote:
>> 
>> Announcing a new ambiguous prefix will be misunderstood by the ISPs who are ignoring IPv6 as a clear invitation to continue ignoring IPv6 and serve their new customers, badly, using NAT444 indefinitely.
> 
> I share that concern, and I have some technical misgivings too.
> 
> In particular, I think it's worth noting that "Connection of IPv6 Domains via IPv4 Clouds" [RFC 3056] makes what would now be regarded as a *normative* reference to "Address Allocation for Private Internets" [RFC 1918].
> 
> Adding a new address prefix for supporting NAT444 operators would require A) revising RFC 3056 to add the prefix explicitly to the set of IPv4 address ranges that MUST NOT appear in the V4ADDR field of 6to4 addresses, and B) updating all globally deployed 6to4 hosts and routers accordingly.  If you don't do that, then subscriber gateways with 6to4-router functions and other 6to4-enabled hosts will mistakenly expect that 6to4 addresses with NAT444-reserved V4ADDR fields are globally scoped when they are not.  Some 6to4-routers will happily advertise such prefixes on their local network links, and most existing hosts today will stateless autoconfigure IPv6 interface address and proceed to expect native IPv6 service to the public Internet over a broken 6to4 tunnel.  Some older implementations will prefer the broken 6to4 default route over the NAT444 default route.
> 
> A second consideration also comes to mind.  Dynamic port-forwarding services, e.g. NAT-PMP and UPnP-IGD, are typically incompatible with NAT444 (unless somebody has hauled off and implemented I-D.woodyatt-spnatpmp-appl without telling me).  Some [most?, *all*?] operating systems with application service interfaces that use these dynamic port-forwarding services in some kind of dirty UNSAF [RFC 3424] system aimed at registering the exterior address for a server in a directory of some kind, e.g. DNS-SD, would need to be upgraded to handle the NAT444-reserved prefix the same as they currently handle RFC 1918 prefixes.
> 
> The way I see it: NAT444 proponents don't have a good story for coping with a whole bunch of related problems, i.e. 6to4, NAT-PMP/UPnP-IGD, etc, all swirling around address realm foo.
> 
> This latest proposal for a NAT444-reserved private prefix doesn't really help solve any of them.  Sure, it let's the NAT444 operators avoid an address realm conflict between subscriber local networks and provider networks, but it only does so at the expense of further operational complications related to UNSAF systems that have hard-coded the prefixes defined currently in RFC 1918 and would need to be upgraded to cope.


> 
> On balance, I don't see the point of explicitly marking out the prefix at the IANA level.  What good do we imagine that would do beyond what could simply be had by having the NAT444 operators conspire to choose a globally-addressable prefix from among one of their own allocations?  Do we imagine that host and router implementors will respond to the new IANA allocation by rushing out software upgrades to everything in the world that knows about private address prefixes?  If you're one of those people, then I'd like to introduce you to some senior executives for system software engineering I know.  I think you'll be enlightened by the experience of explaining your concerns to them.
> 
> 
> --
> james woodyatt <[email protected]>
> member of technical staff, communications engineering
> 
> 
> _______________________________________________
> v6ops mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/v6ops


_______________________________________________
v6ops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/v6ops