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

[George, Wes E IV [NTK]]

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