Re: [OPS-AREA] Heads up - Plea for allocating a /8 to ISPs

Greetings James,

On 11Nov2010, at 16.15, james woodyatt wrote:

> 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.

That is an impact, agreed.

> 
> 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.

We never said that NAT444 did.  In fact, we said it's broken.  However, NAT444 WILL happen, the CPE fleet out there isn't ready for anything else.  The question is, do you want to have residential gateways / routers to have conflicting addresses on either side of the NAT function, or not?  That's the what this block is intended to deal with.

> 
> 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.

See above
> 
> 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.

We could do that - but guess what, we'd all do it - there goes the rest of the pool.  I don't think that's what most of the community wants.  I think the only thing that needs to be updated, based on a new "private" block, is, from what you say, is 6to4.  Yes, it's an impact of 444, one of many.  However, if we're throwing around senior software engineering executives, maybe we should introduce them to the concept of testing the continuity of a link before bringing up a route or tunnel, rather than just seeing if a magic address is present on a device.  Just a thought....


> 
> 
> --
> james woodyatt <[email protected]>
> member of technical staff, communications engineering
> 
> 
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ops-area
> 

---
李柯睿
Check my PGP key here:
https://www.asgaard.org/~cdl/cdl.asc

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