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

["Aaron Falk" <[e-mail]>]

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:

> I know that 240/4 is not assigned to anyone still...
>
> Eliot
>
> On Aug 10, 2018, at 00:46, Aaron Falk 
> <[e-mail]<mailto:[e-mail]>> 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 
> <[e-mail]<mailto:[e-mail]>> wrote:
>
> Hi Aaron,
>
> On 09.08.18 23:38, Aaron Falk wrote:
>
> 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
>
> On 7 Aug 2018, at 11:51, Lee Howard wrote:
>
> 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]><mailto: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]><mailto:[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]<mailto:[e-mail]>
> https://www.iab.org/mailman/listinfo/stackevo
>
>
>
> _______________________________________________
> Stackevo mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.iab.org/mailman/listinfo/stackevo
>
>
>
> _______________________________________________
> Stackevo mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.iab.org/mailman/listinfo/stackevo
>
>
> --
> -- aaron Sent from Gmail Mobile