[arin-discuss] use of 220.127.116.11/16 not clear
farmer at umn.edu
Tue Sep 22 23:05:41 EDT 2009
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.
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
18.104.22.168/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 22.214.171.124 - 126.96.36.199 to Net Dynamics Exp, the contact
listed was Zaw-Sing Su, SRI, ZSu at SRI-TSC.ARPA (Now thats an old email
I assume that is Network Dynamics Experiment and in the modern CIDR
world that would be 188.8.131.52/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.
Network dynamics due to component mobility or failure.
Mobile host, reconstitution, partitioning.
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.
ARIN was transfered 184.108.40.206/16 and 220.127.116.11/16, all the rest of
18.104.22.168/12 I assume stayed with IANA.
The only thing I can find in whois now;
OrgName: Interop Show Network
Address: 600 Harrison St
City: San Francisco
NetRange: 22.214.171.124 - 126.96.36.199
NetType: Direct Assignment
Maybe we can get this returned too?
So we are talking about maybe re-aggregating a whole /12 if
188.8.131.52/16 and 184.108.40.206/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 220.127.116.11/16 is no longer considered a test network,
raise the word far and wide don't filter 18.104.22.168. Then recover it.
Further, should Interop be asked to return 22.214.171.124/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.
> On Sep 22, 2009, at 7:46 AM, Jason Schiller wrote:
>> On behalf of Ron Bonica,
>> 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 126.96.36.199/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).
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
More information about the ARIN-discuss