[arin-ppml] Use of "reserved" address space.

[Eliot Lear]

 Wes,

You've covered a lot of the ground of the discussion.  I presented this
draft on behalf of our author group to the int-area, and got pushback
from the room in the following forms:

    * It would take forever to fix printers, fridges, and other
      appliances, along with routers, firewalls, and other middle boxes.
    * /4 is a honking lot of private address space that would benefit few.
    * /4 really doesn't buy us much time in terms of staving off or
      easing a transition
    * *There are several v4/v6 transition protocols that base
      assumptions about private address space.*
    * Better to focus on v6 transition.

That's my recollection.  That forth one pretty much means you have to
choose a path and go with it.  And so the question is whether it would
be worth removing filters to make that address space useful in some
number of years, and there certainly wasn't overwhelming demand in the
room to do that.  Quite the opposite.

Eliot

On 6/25/10 9:48 PM, George, Wes E IV [NTK] wrote:
> The latest drafts that I'm aware of to fix this unfortunately died in the IETF without a lot of support. General consensus was that it was nearly impossible to get a critical mass of changes in networking and end user gear to make this work reliably in the global internet fast enough to make this useful. There is some credence to that idea - do you really want to have to field the calls from a customer who can't reach a given website because the people on the other end are dumping the traffic since they didn't get the memo that RFC3330 had been updated? It would be roughly equivalent to what has to happen every time we de-bogonize a new block from IANA, but much worse because it's hard-coded, instead of simply being rules that have to be changed in route and packet filters. I voiced support for it in IETF because I think that it still could have had applications, especially in areas of the network where you had some ability to coordinate and ensure that your gear supported th
>  e change, but to no avail.
> It might have worked if we had proposed it in 2005 (or maybe it failed then too, that was before my time in IETF), but the closer we get to exhaustion, the less support there seems to be for this sort of thing. At this point, I too think we're more or less out of runway, but this is an example I cite whenever I see people defending "reserved for future use" in a spec from those who might try to use it for something useful, or worse, proposing new "TBD" reservations for scarce resources, "just in case..."
>
> My discussions with Vince Fuller, who wrote one of the drafts, indicated that he had filed bugs internally with his employer to implement this on all of their platforms, but I'm not sure where that went after the draft fizzled.
> http://tools.ietf.org/search/draft-fuller-240space-02
>
> Here's another draft:
> http://tools.ietf.org/html/draft-wilson-class-e-02
> This might be something you could go and implement on your own network assuming you have control of the devices inside of it, but that's probably the best we could hope for.
>
>
> Thanks,
> Wes George
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell
> Sent: Friday, June 25, 2010 2:58 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Use of "reserved" address space.
>
>
> A year or two ago there was some discussion about "reserved" address
> space.  Specifically, Class E space, but in a CIDR world one has
> to wonder why we can't use most of 0/8, 127/8, and 240/4 as regular
> unicast space.  There were folks who were going off to discuss that
> at the IETF and with some vendors.
>
> That's potentially ~18 /8's worth of address space "left on the
> table".  Early review suggested that most of this in several free
> operating systems could be enabled with simple "user interface"
> changes; that is there were some checks to make sure they weren't
> used improperly by tools that set addresses but if those were removed
> they would be forwarded and treated like unicast.  That is the cost
> of implementation was low.
>
> I realize "everything in the middle" must be upgraded to support this,
> but considering the level of effort and cost that may go into transfers
> folks may in fact find using this space cheaper.  I'm surprised there
> isn't more effort to look into this area.  Is there something going on
> I'm just not seeing?
>
> --
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
>
> This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100627/e6340b7a/attachment.htm>