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

Summary of the proposal - adverse possession (i.e. squatters' rights) with the 444 operators being the desseisor?

	Chris

On 12Nov2010, at 05.23, james woodyatt wrote:

> On Nov 11, 2010, at 00:51, Brian E Carpenter wrote:
>> 
>> [...] The answer is in RFC 2650 "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority". [...] So to answer James, the advantage is that the IETF *can* direct IANA, but the IETF can't direct the RIRs.[...]
> 
> Thus Mr. Carpenter exposes an ambiguity in the question I posed.  I should have asked what is the *technical* advantage to be gained by obtaining a direction from IETF to IANA for a proposed NAT444-reserved non-global space, and how would that technical advantage promote a smoother or faster transition to IPv6?
> 
> I understand that operators have a thorny political problem complicating the technical problems involved in NAT444 deployment.  They don't like using RFC1918 space because it conflicts with subscriber address realms.  So, they feel the need to use non-RFC1918 space (and live with the breakage thereby done to 6to4, NAT-PMP, UPnP-IGD, dynamic DNS, et cetera).  The political problem is that none of them want to be the ones to give up their hard-won global allocation from a RIR for the good of the tribe.  The same political problem arises at the level of the NRO, i.e. none of the registries want to give up *their* hard-won numbers to promote the global welfare.  So, now the NAT444 operators are here at the IETF [again] asking us to do what NRO won't do.
> 
> But IETF doesn't have the authority to direct IANA to allocate numbers for *political* purposes.  We need a technical problem to solve.  Hence, my annoying questions, which so far have gone unanswered.
> 
> Let's take a trip down memory lane, back to the ancient days before RFC 1918.  Even before its predecessor, RFC 1597, there were networks on private address realms.  Does anyone here remember how we settled on the prefixes that IANA assigned for private networks in RFC 1597?
> 
> The Internet community did a survey and found the three most common unallocated prefixes that were already in use at the time.  Those became what IANA reserved.  The key point here is that IETF could point to a good technical reason for pulling those prefixes out of the global free pool: they were already in use by a lot of existing private address realms, and directing IANA to reserve those blocks explicitly would allow future systems to distinguish private and global addresses from one another.
> 
> If service providers want IETF to deny the NRO another block of scarce IPv4 address space, for a purpose similar but not identical to the purpose described in RFC 1918, then they're going to need a good technical reason for it-- because the terms of RFC 2650 demand it.  So, let's hear it.
> 
> I very much would like to hear how the proposal under discussion is intended to allow future CPE systems to *use* the fact that IANA has reserved a new prefix for them.  Note well: I'm not interested in hand-waving about what legacy CPE with current software loads will do.  I'm concerned about future systems here, and I suspect the NAT444 proponents have a very naïve view of how CPE system implementors are likely to react to a new IANA reservation, prior to its uptake by operators.
> 
> A more effective way to get CPE implementors to recognize the NAT444 prefix is to pick one and start using it.  Then, when systems break under NAT444 with intermediate realms using non-RFC1918 space, as you have been planning all along, the CPE vendors may-- depending on how important the damage is to *them*-- be induced to fix them somehow, most likely by adding one or more NAT444 prefixes to their software to be treated as non-global addresses.  Once *that's* done, operators should come back to IETF and say, "Here are the prefixes we poisoned for global use by using them to support NAT444 operations.  Please direct IANA to reserve them so that the next release of FreeBSD can safely stop treating them like they might be valid global addresses somewhere."
> 
> 
> --
> james woodyatt <[email protected]>
> member of technical staff, communications engineering
> 
> 
> _______________________________________________
> OPSAWG mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/opsawg
> 

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

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