Re: [Stackevo] draft-thomson-use-it-or-lose-it

[Lee Howard <[e-mail]>]

Demand for IPv4 addresses in the years leading up to IANA and RIR 
exhaustion rose to 15 /8s per year. (see, e.g., 
https://www.nro.net/wp-content/uploads/NRO_Q4_2012.final_.pdf slide 
"IPv4 Address Space Issued"). The effort required to make the 15 /8s of 
Class E available didn't seem (to me) to be worth the effort, and in 
fact risked worse Internet fragmentation since there would be no way to 
know when "all" routers could route the space.

Economically, losing Class E did not affect the IPv4 supply curve, 
except by moving it sideways a year. $5 billion USD might seem like a 
lot, but if the choice is Class E plus NAT (to reach things that don't 
speak Class E; how would you know when to NAT?) or IPv6 plus NAT (to 
reach things that don't speak IPv6), the latter leads to a less 
fragmented Internet.

100.64/16 (rfc6598) probably could have come from Class E, though, since 
all affected devices would be under single administrative control.

More specifically to the question:
I think in the 1990s enough people thought there might still be 
interesting experiments in Class E, and that IPv6 was still going to be 
deployed before address family fragmentation, that we could not have 
reached consensus on reclassifying. In the 2000s, it was too late--we 
only had 12 years before we would need it.

A final thought: I don't know if it would have messed up anyone's 
architectures to have IPv4 unicast address space (Classes A, B, C, E) 
split by IPv4 multicast address space (class D).

Lee

On 08/07/2018 04:26 AM, Brian Trammell (IETF) wrote:
> hi all,
>
> One thing that strikes me both about the 240/4 space (and, indeed, other below-the-application examples like IP options and TCP options) is that the ossification here took a *very* long time to happen. It seems to me that this document should try to capture that somehow, but I'm not sure how.
>
> Digging into this example:
>
> All that 791 (September 1981, 36+ years ago) says about Class D/E space is:
>
> "The extended addressing mode is undefined.  Both of these features are reserved for future use."
>
> 988 (July 1986, 32 years ago) updates this with the equally useful:
>
> "Class E IP addresses, i.e. those with "1111" as their high-order four bits, are reserved for future addressing modes."
>
> Neither 1519 nor 4632 (CIDR) mention class E addresses at all.
>
> An open question here: at what point would it have been possible to revise this "reserved for future use" in a meaningfully deployable way? Much of the discussion on ossification and greasing in QUIC assumes "never", essentially that undefined and unexercised bits (like all 0xfXXXXXXX IPv4 addresses) are dangerously underspecified and will accrue middleboxes (I still like that image) as quickly as an unpatched Win98 machine would get owned on the open Internet during the Age of the Great Worms.
>
> For class E, it seems to me that there was probably a window (before most of the core routers were primarily ASIC-based) that a change in use could have been rolled out in an uncoordinated way. And much of the difficulty of doing anything with the space now is linked to the fact that the implementations of packet forwarding that will choke on class E addresses are (1) often implemented in hardware and (2) replaced on a 10-year depreciation cycle, if (as is the case with lots of end-network NAT boxes) ever.
>
> (An academic digression into economics: the current value of the class E space at open market rates sold off in /24 blocks is on the order of 3GUSD, ignoring the effects that releasing about a million /24s into the market would have on the dynamics of the market. The unfixability of the "class E problem" is therefore a matter of (1) the total marginal cost of fixing implementations to the point that class E becomes saleable being higher than three billion, which is almost certainly the case and/or (2) an inability to allocate or distribute the proceeds of an auction of said space to the entities that would need to deploy the changes, which is definitely the case. It's a shame that other "stuck migrations" don't map so neatly onto a market to which codepoints can be assigned values, but I suspect the outcome would largely be the same if they did...)
>
> In any case, shipping a protocol with underspecified bits is definitely unsafe, and to be avoided, but we should probably explore the dynamics of how this unsafety actually unfolds. Different layers have different timescales and different amounts of reversibility.
>
> I might swing back around on this and send a PR with something hopefully insightful after I burn down my queue...
>
> Cheers,
>
> Brian
>
>
>> On 7 Aug 2018, at 08:18, Eliot Lear <lear=[e-mail]> wrote:
>>
>> Signed PGP part
>> Hi Martin,
>>
>> I'm just delving into Radius and EAP, but what I like is how opacity was
>> used early on for privacy purposes.   So for instance, perhaps the
>> largest federated network in the world is Eduroam, and it is built on
>> Radius and EAP.  Proper layering has made it possible for there to be
>> inner and outer identities that allow for IdPs to manage their user
>> bases independently and to keep some amount of privacy.  Klaas Wierenga
>> at GEANT was the principal designer.
>>
>> We are trying to expand out AAA for IoT use cases, and in that context.
>> Some of that work was done with EAP-TEAP, but a little bit more is
>> needed.  A key insight there is that it is sort of in between routing
>> and application, in that it is multi-party, but not to the insane extent
>> of a routing system.
>>
>> At the Internet layer, of course, we have a big fat wasteland called
>> 240/4, which is just sad.  Vince Fuller, Dave Meyer, and I wanted to
>> free up that space, but there were serious concerns that using it would
>> cause harm to systems not expecting it to be used, or simply would be
>> ineffective.  That was a while ago.
>>
>> Eliot
>>
>>
>> On 07.08.18 02:24, Martin Thomson wrote:
>>> On Mon, Aug 6, 2018 at 11:22 PM Eliot Lear <[e-mail]> wrote:
>>>> In short, my suggestion is to first decide on what applicability you
>>>> want to have, and if broad, then let's explore some other cases.
>>> Brian made a similar comment.  I would really like to hear more about
>>> broader experience with this.  It seems like TLS is uniquely crappy
>>> when it comes to these issues (investigating why would be another
>>> valuable research subject...), but I can't believe for a moment that
>>> the implementation ecosystem of other protocols is pristine and
>>> blemish-free.
>>>
>>> If your experience with the AAA protocols reveals anything, I'd be
>>> very interested.  My understanding of RADIUS, having used it many
>>> years ago, was that it was a great example of the active use thing I
>>> advocate for.  That is, the mechanism you use to extend the protocol
>>> is so fundamental to the protocol that you cannot avoid correctness in
>>> extension handling.  Even having a stronger reaffirmation of that
>>> would be helpful.
>>>
>>
>>
>>
>
>
> _______________________________________________
> Stackevo mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/stackevo