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

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 2 Aug 2018 16:42:42 +0200

Hi Martin,

I finally reviewed the doc completely and I really like the „use-it-or-lose-it“ message and the background explanations. However, I’m less sure about the migration techniques you propose (sec 4). 

First section 4.1. (Active Use), I think, could be more concrete: does it make sense to specify two versions in parallel just to use this mechanism? Or just make sure you actually have a plan to specify a next version soon. And does it also mean that you should not have a versioning mechanism if you don’t plan to specify another version soon?

Then I’m really not sure about section 4.2. Maybe I’m just not a full believer in greasing but I really think it worked „well" for TLS because you used it as a mechanism to detect deployed brokenness afterwards. I really don’t think you will have the same result if you reserve something for greasing at the time of the first specification, because then people will implement this as an extra case (even if it would be easier to just implement the versioning mechanism correctly, because this is just how people work).

Also section 4.3: I have the feeling that the middlebox problem is a bit a different question. It’s a good note to spell out that middleboxes are protocol participants (as done in section 2.2), however, explicitly only exposing what should be expose is rather the message of the path-signals and wire-image drafts and I think I would rather refer to these drafts instead.

Not sure if section 4.4. should be rather an own section because it is something additional and not really a migration technique/design principle for protocols, is it?

Mirja

> Am 26.04.2018 um 12:27 schrieb Brian Trammell (IETF) <[email-masked]>:
> 
> Hello, stackevo!
> 
> We've sent wire-image and path-signals up to the IAB; it seems to me that Martin's document on protocol extensibility and agility (draft-thomson-use-it-or-lose-it) fits well with these two, and would benefit from being published together with them.
> 
> So, please have a look at this document (https://tools.ietf.org/html/draft-thomson-use-it-or-lose-it-01) over the next couple of weeks, and send feedback with a view toward sending this document up to the IAB.
> 
> Thanks, cheers,
> 
> Brian
> 
> 
> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Aug 2018 18:03:59 +1000

Thanks for reading Mirja,  Comments inline.

> First section 4.1. (Active Use), I think, could be more concrete: does it make sense to specify two versions in parallel just to use this mechanism? Or just make sure you actually have a plan to sp…

I don't think that we know the answer to this question just yet.  So
I'm not confident in writing anything concrete.

I seriously doubt that deploying two versions from day 0 would be
effective.  There were cases of TLS extension points that shipped with
a small set of options, which ultimately ossified: though each of
those values would work, new values couldn't be deployed.  That
happened because the entire set remained unchanged over a fairly long
period.  Greasing revealed and ultimately fixed those, hence some of
the enthusiasm for that mechanism - but you might easily argue that
this was something that could be found by other means (and I would
agree with you).

TLS version negotiation is another example of this as well.  SSLv3,
TLS 1.0 through 1.2 could all be negotiated, but even attempting to
advertise TLS 1.3 caused enough things to break that deployment was
untenable.  And TLS version negotiation couldn't be greased.  Moving
to a new mechanism means that it can be greased now, but we don't know
how effective that will be.

So my guess is that shipping with any small N isn't effective.  What
we know is effective is continual addition of new values.  That plan
you have for v2 isn't useful until you ship v2.  And you don't know
that v3 can be shipped until you ship v3.  As long as N is small, I
don't think that you can ever be confident that N+1 will work.  I
don't know what the value of N is when you can be confident in the
success of N+1 either.  Maybe the only measure of defense is velocity
- any sufficiently stable target will be nailed down, but a moving
target evades capture.

There is talk now about shipping new TLS versions every few months.
Not major revisions, but revisions that rearrange the protocol in
different ways that exercise various capabilities that we might like
to preserve.  It's still essentially grease, so apply the same
skepticism, but the idea is that you can't just say that x&0x0f0f ==
0x0a0a is safe to ignore because everything changes.  For instance,
one change might add 13 to all extension codepoints, another might
reorder the fields in some messages.

> Then I’m really not sure about section 4.2. Maybe I’m just not a full believer in greasing but I really think it worked „well" for TLS because you used it as a mechanism to detect deployed brokenne…

I tried hard to capture some of this skepticism, because I share your
view.  That it sort of worked for TLS isn't a great proof that the
general technique is effective.  As it says "Incorrect implementations
might still be able to correctly identify these code points and ignore
them."  I've added some more negative language as well :)

> Also section 4.3: I have the feeling that the middlebox problem is a bit a different question. It’s a good note to spell out that middleboxes are protocol participants (as done in section 2.2), how…

I will do that.  That document had rather uncertain status when this
was first written.  That no longer true :)

> Not sure if section 4.4. should be rather an own section because it is something additional and not really a migration technique/design principle for protocols, is it?

It's a separate concept, but Section 4 is more broadly about
strategies, and while Section 4.4 isn't a strategy on its own, it's
complementary to the other strategies.  I've made this clearer in the
lead-in to prevent there from being any misapprehension about why that
section is there.  (I was originally going to put this with grease,
because it's so essential there, but it's really a separate
technique.)

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 6 Aug 2018 11:46:12 +0200

Hi Martin, hi all,

I agree with the main point this document makes which is only using a versioning mechanism actively helps to avoid ossification. And reading through the doc, I also thought that maybe we should recommend to have a versioning plan while developing the protocol (as you say below is under discussion for TLS). However, thinking further about it and given were TLS is right now, I have the feeling that we really don’t have enough experience to make a recommendation here. So I wonder, should we maybe rather try to just document what we have experienced so far and not even try to give a recommendation, or it that not what we want in the StackEvo program?

Mirja

> Am 03.08.2018 um 10:03 schrieb Martin Thomson <[email-masked]>:
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 6 Aug 2018 20:25:35 +1000

> I agree with the main point this document makes which is only using a versioning mechanism actively helps to avoid ossification. And reading through the doc, I also thought that maybe we should rec…

Note that this isn't exclusively about version negotiation (though
that is the extension point you most want to safeguard, for sure).
It's more general than that.

The question is the right one though: Can we reasonably publish a
document that lacks really concrete advice about what to do?  The
answer probably depends on whether you think that an answer is
imminent.  Personally, I don't think that the proposed experiments in
TLS will provide definitive answers.  They will provide more
information about that experiment, but not about the problem more
generally.

So the question is whether it is enough to identify the problem and to
provide a general principle.  We did that with path signals and wire
image.  We're still learning about what does and doesn't work with
those, but we have agreed on the principles that we should apply in
those cases.  The same applies here, so I tend to think that there's
value in proceeding, as long as we are clear about the limits of the
advice.

I've tried to proscribe the limitations in another update:
https://github.com/martinthomson/use-it-or-lose-it/

---

From: Brian Trammell (IETF) <[email-masked]>
Date: Mon, 6 Aug 2018 12:51:53 +0200

Back from holidays. Slowly digging out of the mailpile...

> On 3 Aug 2018, at 04:03, Martin Thomson <[email-masked]> wrote:
> 
<snip>

> reorder the fields in some messages.

This reminds me a bit of some defensive computer architecture work done about a decade ago, that attempted to fix buffer overflow attacks by dynamically compiling executables to an encrypted instruction set, with the idea that the shell code would not decrypt to a valid instruction stream without a key. Applying this analogy to protocol design (where it seems to be a generalization of the TLS every six weeks approach), complicated sub-parts of the version number space would act in effect as encryption “keys” for the protocol’s codepoint and state transition space.

IMO the challenge here is to make sure that the cost of the complexity added is much less than the amortized cost of the complexity of dealing with ossification after the fact. The encrypted state/codepoint space idea is reductio ad absurdum: iirc the POC for the encrypted instruction set (basically valgrind-as-VM) made it into one of the top three security conferences because it only induced a four-order-of-magnitude performance penalty.

> general technique is effective.

This is the main reason I’d like to see the document expand beyond TLS/H2-derived experience: I'm mostly convinced that version-negotiation-agility is a desirable protocol feature in its own right, but evidence that greasing's effect isn't just a property of the vagaries of how TLS 1.2 negotiation was supposed to work would be nice to have.

Cheers,

Brian

> As it says "Incorrect implementations

---

From: Martin Thomson <[email-masked]>
Date: Mon, 6 Aug 2018 20:56:36 +1000

> IMO the challenge here is to make sure that the cost of the complexity added is much less than the amortized cost of the complexity of dealing with ossification after the fact. The encrypted state/…

:) TLS is easier than that, and almost cost free.  Flip any bit and
everything changes.  The only trick is to ensure that you have a human
making the changes at the other end, so the changes you make need to
be different every time in different ways.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 6 Aug 2018 15:22:03 +0200

Martin,

This is a good work, but along with the following concern...

> value in proceeding, as long as we are clear about the limits of the

Right now you are focusing on TLS, QUIC, and HTTP.  That seems just a
bit too narrow to determine just how general the advice is.  Maybe this
is a matter of applicability, but if you really mean to be general, why
not look for some successes outside those three approaches?  Some of the
advice given, by the way, is not particularly useful in some cases.  For
example, while encryption might buy other things, it doesn't protect you
from ossification in the case of routing protocols.  Moreover, greasing
is fine from the beginning, but quite hazardous if introduced to an
environment where it is not expected.

Finally, there are times and places for multi-party protocols.  Here,
encryption may well be the right way to go, but having the right
signaling framework for all intended parties is important.  An
interesting case study is one I seem to be spending a lot of time with
lately- EAP/802.1X.  Here you have three separate protocols (802.1X,
Radius, and EAP) with three separate parties, all of which need to be
addressable by one another.

Sometimes the problems aren't with the extensibility mechanism, but with
other aspects of design.  We probably *could* have crammed an infinitely
extensible IPv4 mechanism through 240/4, but paradigm shift and
performance issues made that difficult.  When we finally got around to
freeing up that space, it was far too late.

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.

Eliot

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Aug 2018 10:24:48 +1000

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 7 Aug 2018 08:18:27 +0200

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

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 7 Aug 2018 10:26:29 +0200

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=[email-masked]> wrote:
> 
> Signed PGP part
> Hi Martin,
>

---

From: Lee Howard <[email-masked]>
Date: Tue, 7 Aug 2018 11:51:36 -0400

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

---

From: "Aaron Falk" <[email-masked]>
Date: Thu, 09 Aug 2018 17:34:55 -0400

On 7 Aug 2018, at 4:26, Brian Trammell (IETF) wrote:

> 3GUSD

3 gigadollars?

---

From: "Aaron Falk" <[email-masked]>
Date: Thu, 09 Aug 2018 17:38:56 -0400

I'm missing some context for this thread.  Sounds like Class E isn't 
routable because some routers don't expect it.  Is this close?  Can 
someone provide a cite?  Is it worth measuring?  I understand the point 
that finding more IPv4 space is kind of irrelevant given the growth of 
the Internet but there may be good reasons to have it and worth knowing 
how bad the problem is and whether it is getting better.

--aaron

On 7 Aug 2018, at 11:51, Lee Howard wrote:

> "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.
>
> 100.64/16 (rfc6598) probably could have come from Class E, though, 
> since all affected devices would be under single administrative 
> control.
>
> 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.
>
>> 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.
>>
>> "Class E IP addresses, i.e. those with "1111" as their high-order 
>> four bits, are reserved for future addressing modes."
>>
>> 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
>>
>>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 10 Aug 2018 00:39:21 +0200

Hi Aaron,

On 09.08.18 23:38, Aaron Falk wrote:
> someone provide a cite?
This came up, I think, in the opsawg, almost a decade ago.  There was a
draft, and there were concerns both that routers wouldn't expect it, and
that some firewalls would not handle the behavior correctly.  Dave
Thaler made that point, as I recall.  The draft to open up that space
died pretty much on first presentation due to those concerns and the
time that would be needed to diffuse any changes such that people could
reliably use the space.

> Is it worth measuring? I understand the point that finding more IPv4
> space is kind of irrelevant given the growth of the Internet but there
> may be good reasons to have it and worth knowing how bad the problem
> is and whether it is getting better.
>
> --aaron
>
>     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.
>
>     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.
>
>     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.
>
>     architectures to have IPv4 unicast address space (Classes A, B, C,
>     E) split by IPv4 multicast address space (class D).
>
>     Lee
>

---

From: Aaron Falk <[email-masked]>
Date: Thu, 9 Aug 2018 18:46:31 -0400

So it's been 10 years, that's a long time in Internet years. Think anything
has changed? Is anyone measuring the ground truth?

On Thu, Aug 9, 2018 at 18:39 Eliot Lear <[email-masked]> wrote:

> routable because some routers don't expect it. Is this close? Can someone
> provide a cite?
>
> that some firewalls would not handle the behavior correctly.  Dave Thaler
> made that point, as I recall.  The draft to open up that space died pretty
> much on first presentation due to those concerns and the time that would be
> needed to diffuse any changes such that people could reliably use the space.
>
>
> Is it worth measuring? I understand the point that finding more IPv4 space
> is kind of irrelevant given the growth of the Internet but there may be
> good reasons to have it and worth knowing how bad the problem is and
> whether it is getting better.
>
> --aaron
>
> 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.
>
> reached consensus on reclassifying. In the 2000s, it was too late--we only
> had 12 years before we would need it.
>
> architectures to have IPv4 unicast address space (Classes A, B, C, E) split
> by IPv4 multicast address space (class D).
>
> Lee
>
> On 7 Aug 2018, at 08:18, Eliot Lear <lear=[email-masked]> <lear=[email-masked]> wrote:
>
> Signed PGP part
> Hi Martin,
>
> On Mon, Aug 6, 2018 at 11:22 PM Eliot Lear <[email-masked]> <[email-masked]> wrote:
>
> Stackevo mailing [email-masked]://www.iab.org/mailman/listinfo/stackevo
>
>
> Stackevo mailing [email-masked]://www.iab.org/mailman/listinfo/stackevo
>
>
> --
-- aaron Sent from Gmail Mobile

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 9 Aug 2018 20:37:40 -0500

I wasn't Present At The Creation, of course ...
On Thu, Aug 9, 2018 at 5:46 PM Aaron Falk <[email-masked]> wrote:

> So it's been 10 years, that's a long time in Internet years. Think
> anything has changed? Is anyone measuring the ground truth?
>

I had the impression that the routing problem with Class E wasn't quite
that routers didn't expect them, it was that it's not obvious what routers
do with addresses with undefined semantics. What if you just assumed that
you would be routing Class E as unicast based on prefixes and some helpful
Internet Wizard defined part of that address block as some weird flavor of
multicast, or something? So it's not obvious what "expecting" these
addresses means.

The firewall problem, of course, is that we couldn't even get firewalls to
forward packets with unexpected protocol numbers ("welcome, TCP and UDP,
sorry about the rest of you transport protocols"), so you have to assume
that firewalls would be even more likely to drop packets with unexpected
addresses ...

If I was tracking this conversation correctly, it sounded like we could
work really hard to make one year's worth of unused IPv4 addresses usable,
and in 366 days we'd be in the same mess with the same need to do something
else ("IPv6"), modulo more fragility in the deployed Internet. I think
that's what's not changing.

Spencer

>> space is kind of irrelevant given the growth of the Internet but there may
>> be good reasons to have it and worth knowing how bad the problem is and
>> 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.
>>
>> Stackevo mailing [email-masked]://www.iab.org/mailman/listinfo/stackevo <https://www..iab.org/mailman/listinfo/stackevo>
>>
>>
>> Stackevo mailing [email-masked]://www.iab.org/mailman/listinfo/stackevo <https://www..iab.org/mailman/listinfo/stackevo>
>>
>>
>> --

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Fri, 10 Aug 2018 04:52:31 +0000

I know that 240/4 is not assigned to anyone still...

Eliot

On Aug 10, 2018, at 00:46, Aaron Falk <[email-masked]<mailto:[email-masked]>> wrote:

So it's been 10 years, that's a long time in Internet years. Think anything has changed? Is anyone measuring the ground truth?

On Thu, Aug 9, 2018 at 18:39 Eliot Lear <[email-masked]<mailto:[email-masked]>> wrote:

Hi Aaron,

I'm missing some context for this thread. Sounds like Class E isn't routable because some routers don't expect it. Is this close? Can someone provide a cite?

This came up, I think, in the opsawg, almost a decade ago.  There was a draft, and there were concerns both that routers wouldn't expect it, and that some firewalls would not handle the behavior correctly.  Dave Thaler made that point, as I recall.  The draft to open up that space died pretty much on first presentation due to those concerns and the time that would be needed to diffuse any changes such that people could reliably use the space.

Is it worth measuring? I understand the point that finding more IPv4 space is kind of irrelevant given the growth of the Internet but there may be good reasons to have it and worth knowing how bad the problem is and whether it is getting better.

--aaron

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

hi all,

Cheers,

Brian

On 7 Aug 2018, at 08:18, Eliot Lear <lear=[email-masked]><mailto:lear=[email-masked]> wrote:

Signed PGP part
Hi Martin,

Eliot

On Mon, Aug 6, 2018 at 11:22 PM Eliot Lear <[email-masked]><mailto:[email-masked]> wrote:

_______________________________________________
Stackevo mailing list
[email-masked]<mailto:[email-masked]>
https://www.iab.org/mailman/listinfo/stackevo

_______________________________________________
Stackevo mailing list
[email-masked]<mailto:[email-masked]>
https://www.iab.org/mailman/listinfo/stackevo

_______________________________________________
Stackevo mailing list
[email-masked]<mailto:[email-masked]>
https://www.iab.org/mailman/listinfo/stackevo

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 10 Aug 2018 12:00:11 +0200

Hi Martin,

so I think there is definitely value to publish a document that talks 
about the problem and what we have "tried" so far to address it. 
However, I guess in this case the wording in the doc could be toned down 
even a bit more...

I know the doc is already phrase carefully, and I guess my main problem 
is about recommending greasing, given we only have experience with it in 
one use case and that use case is not quite the same as described in 
this doc.

I think the other thing that would help, is to make a stronger point 
that greasing also has costs involved, e.g. it limits the available code 
space or can result in additional latency (e.g. when version negotiation 
is triggered).

Mirja

---

From: "Aaron Falk" <[email-masked]>
Date: Fri, 10 Aug 2018 11:32:51 -0400

I can't tell from the descriptions whether anyone confirmed then or 
recently whether there's a problem there.  I'm thinking this might be a 
MAPRG topic.

--aaron

On 10 Aug 2018, at 0:52, Eliot Lear (elear) wrote:

> On Aug 10, 2018, at 00:46, Aaron Falk 
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> On Thu, Aug 9, 2018 at 18:39 Eliot Lear 
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Aaron,
>
> This came up, I think, in the opsawg, almost a decade ago.  There was 
> a draft, and there were concerns both that routers wouldn't expect it, 
> and that some firewalls would not handle the behavior correctly.  Dave 
> time that would be needed to diffuse any changes such that people 
> could reliably use the space.
>
>
>
> seems to me that this document should try to capture that somehow, but 
> I'm not sure how.
>
> "Class E IP addresses, i.e. those with "1111" as their high-order four 
> bits, are reserved for future addressing modes."
>
> 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.
>
> 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...)
>
> On 7 Aug 2018, at 08:18, Eliot Lear 
> <lear=[email-masked]><mailto:lear=[email-masked]> 
> wrote:
>
> Signed PGP part
> Hi Martin,
>
> On Mon, Aug 6, 2018 at 11:22 PM Eliot Lear 
> <[email-masked]><mailto:[email-masked]> wrote:
>
>