[arin-discuss] use of 128.66.0.0/16 not clear
Michael Hasse
mhasse at itwerx.net
Wed Sep 23 01:45:03 EDT 2009
Or simply a usage audit of legacy /8s owned by such as duPont, Eli
Lily, Ford, Merck et al. There's more than a few /8s out there that
are likely pretty sparsely implemented. Not to mention ones that have
been rolled into other orgs, e.g. ranges originally assigned to DEC,
CSC and others. (How many /8s does a non-ISP need anyway? Hope I'm
not speaking out of turn here...)
Thanks,
Michael Hasse
Itwerx
206-850-1496
http://www.itwerx.net/
**********************************
If our service is not 100% satisfactory please tell us!
If it is 100% please tell others!
**********************************
On Sep 22, 2009, at 8:05 PM, David Farmer wrote:
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
===============================================
_______________________________________________
ARIN-Discuss
You are receiving this message because you are subscribed to
the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-discuss
Please contact info at arin.net if you experience any issues.
More information about the ARIN-discuss
mailing list