[arin-discuss] use of 128.66.0.0/16 not clear

[David Farmer]

Owen DeLong wrote:
> I think that now is NOT the time to be expanding the wasted IPv4
> address space.  This block should be documented for it's prior
> misuse in examples.  That use should be deprecated, and, the block
> should be placed in the free pool.
> 
> I would not object to placing it low on the priority list of blocks to be
> issued, but, that's 65,536 IPs that should not be left fallow simply
> due to prior misuse.
> 
> Owen

I'm not sure I would classify it as misuse.  If IANA assigned it for 
that purpose that is its use.  So, my initial reaction is let it be, we 
don't need it that bad.

But, lets do a little spelunking in historical RFCs.  Because that is a 
really old chunk of IP address space, I should know my organization has 
128.101.0.0/16. Which we got even a couple years after the one in 
question was assigned;

First documented in RFC 923 - "ASSIGNED NUMBERS", IANA originally 
assigned 128.64.0.0 - 128.79.255.255 to Net Dynamics Exp, the contact 
listed was Zaw-Sing Su, SRI, ZSu at SRI-TSC.ARPA (Now thats an old email 
address :)).

I assume that is Network Dynamics Experiment and in the modern CIDR 
world that would be 128.64.0.0/12.

A little more spelunking I find this excerpt from RFC 898 - "GATEWAY 
SPECIAL INTEREST GROUP MEETING NOTES" that looks like it might be related;

    SAC Gateway -- SRI - Su/Lewis

       Postel:  This was a presentation of the design for the gateways to
       be used in the advanced SAC demo experiments on network
       partitioning and reconstitution, and communication between
       intermingiling mobile networks.  Much of these demonstrations will
       be done with packet radio units and networks.  Some of the ideas
       are to use a gateway-centered type of addressing and double
       encapsulation (i.e., an extra IP header) to route datagrams.

       Muuss:

       Network dynamics due to component mobility or failure.
       Mobile host, reconstitution, partitioning.
         H/W:  11/23
         S/W:  Some "C" gateway
         OS:   VMOS (SRI)

       Gateway-centered addressing, rather than network.
         Gw host instead of net.host.
       Double encapsulation:  additional IP header.
         TCP uses addr as an ID, IP uses it as an ADDRESS (-> route)
         Need to separate these dual uses of this address field.
       Incremental Routing (next-hop indication)

I'm not sure that these are the same thing, but they both sound like 
cool projects.  If anyone can provide some pointers I'd personally be 
interested in more details.  But, enough spelunking in dank dark old 
RFCs, lets jump a little further forward.

Looking at RIPE's Early Registration Transfer Project information, by 
the way trying ARIN's I get a 404 page.

http://www.ripe.net/projects/erx/erx-ip/network-128.html#networks

ARIN was transfered 128.64.0.0/16 and 128.66.0.0/16, all the rest of 
128.64.0.0/12 I assume stayed with IANA.

The only thing I can find in whois now;

OrgName:    Interop Show Network
OrgID:      ISN-4
Address:    600 Harrison St
City:       San Francisco
StateProv:  CA
PostalCode: 94107
Country:    US

NetRange:   128.64.0.0 - 128.64.255.255
CIDR:       128.64.0.0/16
NetName:    SHOWNETB3
NetHandle:  NET-128-64-0-0-1
Parent:     NET-128-0-0-0-0
NetType:    Direct Assignment
NameServer: DNS.INTEROP.NET
NameServer: SOLARIS.CC.VT.EDU
Comment:
RegDate:    1991-09-18
Updated:    2003-03-06

Maybe we can get this returned too?

So we are talking about maybe re-aggregating a whole /12 if 
128.64.0.0/16 and 128.66.0.0/16 were returned to IANA and put in the 
free pool.  A /12 is going to become a very globally significant chunk 
of IP space very soon now.

So I take back my initial reaction and believe that Owen is right, 
document that 128.66.0.0/16 is no longer considered a test network, 
raise the word far and wide don't filter 128.66.0.0.  Then recover it.

Further, should Interop be asked to return 128.64.0.0/16?

It should be done very politely, with the utmost diplomacy, if it is 
asked at all.  But, should it be asked? If, so Who? and, How?

I've probably added more that a couple cents worth, but Scott did ask 
for a little history.  This is by no means authoritative, I wasn't 
there, some that actually knows details please speak up.

Thanks

> On Sep 22, 2009, at 7:46 AM, Jason Schiller wrote:
> 
>> On behalf of Ron Bonica,
>>
>> Folks,
>>
>> The IETF has recently passed draft-iana-rfc3330bis-08. This draft
>> documents the fact that the following address ranges have been reserved
>> for documentation:
>>
>> - 192.0.2.0/24 (TEST-NET-1)
>> - 198.51.100.0/24 (TEST-NET-2)
>> - 203.0.113.0/24 (TEST-NET-3)
>>
>> In addition, some authors have used 128.66.0.0/16 (TEST-B) for example
>> purposes. There is no RFC that talks about this block, but my
>> understanding is that IANA/ARIN have marked it as reserved. If you
>> search the Internet you will find at least some number of examples and
>> firewall rule sets that use this block, but I have no good idea about
>> how widespread such usage is.
>>
>> What should we do about this block? Some of the potential answers
>> include documenting its role, marking it as reserved but deprecating its
>> use in examples, and returning it to the free pool immediately (with a
>> warning sign about possible filtering problems).
>>
>> Comments?
>>
>>                                      Ron

-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================