Subject: Re: Last Call: draft-iana-ipv4-examples (IPv4 Address Blocks Reserved for Documentation) to Informational RFC

From: Jari Arkko <[email-masked]>
Date: Sun, 23 Aug 2009 23:19:28 +0300

Further discussion would be useful on one issue that was brought to our 
attention.

The issue is the status of 128.66.0.0/16. This block, TEST-B, has been 
used 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).

Jari

---

From: IETF Member Dave Aronson <[email-masked]>
Date: Sun, 23 Aug 2009 16:35:28 -0400

Jari Arkko<[email-masked]> wrote:

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

If we can arrive at an agreement with ARIN, maybe we could document it
indirectly, by pointing to some place where ARIN would document *all*
its reserved spaces.  (Possibly even including things like "reserved
for expansion of the previous block", or "reserved for future use".)
A very brief Googling of arin.net did not reveal such a master list.

-Dave

-- 
Dave Aronson, software engineer or trainer for hire.
Looking for job (or contract) in Washington DC area.
See http://davearonson.com/ for resume & other info.

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 23 Aug 2009 16:38:31 -0400

On Aug 23, 2009, at 4:19 PM, Jari Arkko wrote:

> Further discussion would be useful on one issue that was brought to  
> our attention.
>
> The issue is the status of 128.66.0.0/16. This block, TEST-B, has  
> been used 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.
>
> 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).

In whois, it's listed as

NetRange:   128.66.0.0 - 128.66.255.255
CIDR:       128.66.0.0/16
NetName:    TEST-B
NetHandle:  NET-128-66-0-0-1
Parent:     NET-128-0-0-0-0
NetType:    IANA Special Use
Comment:
RegDate:    1993-03-18
Updated:    2002-09-12

RFC3330 says

128.0.0.0/16 - This block, corresponding to the numerically lowest of  
the former Class B addresses, was initially and is still reserved by  
the IANA. Given the present classless nature of the IP address space,  
the basis for the reservation no longer applies and addresses in this  
block are subject to future allocation to a Regional Internet Registry  
for assignment in the normal manner.
------
If there is no RFC, IANA or ARIN documentation assigning it to some  
use, why not put it into the free pool ? Users have been warned for 7  
years now.

Regards
Marshall

>
> Jari
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Geoff Huston <[email-masked]>
Date: Mon, 24 Aug 2009 07:38:28 +1000

On 24/08/2009, at 6:38 AM, Marshall Eubanks wrote:

>> 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.
>>
>> 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).
>
> In whois, it's listed as
>
> 128.0.0.0/16 - This block, corresponding to the numerically lowest  
> of the former Class B addresses, was initially and is still reserved  
> by the IANA. Given the present classless nature of the IP address  
> space, the basis for the reservation no longer applies and addresses  
> in this block are subject to future allocation to a Regional  
> Internet Registry for assignment in the normal manner.
> ------
> use, why not put it into the free pool ? Users have been warned for  
> 7 years now.\

Your whois search was for 128.66.0.0/16 while RFC3330 describes  
128.0.0.0/16

If one was to have interpreted RFC3330 as the authoritative list of  
_all_ special use reserved blocks then at the time, September 2002,  
then RFC3330 effectively reassigned 128.66.0.0/16 back into the pool  
of unallocated number with no special use reserved by the IANA. Or are  
you saying that the ARIN whois registry "trumps" RC3330 in this  
regard? I personally don't think that this is the Right Thing, and  
that RFC3330 (and its successors) should be the single authoritative  
information source over these IANA special use / reserved address  
blocks.

(I notice that draft-iana-rfc3330bis also drops 128.0.0.0/16 from the  
list and effectively also throws this prefix back into the unallocated  
pool.)

So if the IETF wants to pull 128.66.0.0/16 (and/or 128.0.0.0/16 - see  
appendix A of 3330bis) back out of the unallocated pool of recyclable  
addresses then someone had better pull draft-iana-rfc330bis out of the  
RFC editor queue real quick and fire up a text editor, or else we'd  
better start working on rfc3330bisbis any day soon!

regards,

     Geoff

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 24 Aug 2009 07:24:28 -0700

IETF Member Dave Aronson wrote:
> its reserved spaces.

By definition, if the IETF directed IANA to reserve it, it's not a Arin
prefix.

>  (Possibly even including things like "reserved

---

From: IETF Member Dave Aronson <[email-masked]>
Date: Mon, 24 Aug 2009 11:45:05 -0400

> By definition, if the IETF directed IANA to reserve it, it's not a Arin

D'oh, sorry, I mean IANA.  That's what I get for typing in a hurry,
juggling too many ETLAs....

-Dave, putting on dunce cap and sitting in corner....

---

From: AJ Jaghori <[email-masked]>
Date: Mon, 24 Aug 2009 11:48:53 -0400

To my knowledge, ARIN does not have a standalone master db that maintains
all of it's *current *and *future *reserved blocks.  Most ACLs that
implicitly block this block tag it as "bogus" or "bad" IP addresses.

With documentation, it's important to broadcast this knowledge to industry
so that there is a concise understanding.

v/r,
-AJ

Chief Architect, Data Network & Security
[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Fri, 28 Aug 2009 22:06:30 +0300

I wrote earlier:

> used for example purposes. There is no RFC that talks about this 
> block, but my understanding is that IANA/ARIN have marked it as 

Geoff brought up the argument that RFC 3330 already effectively released 
this block, as it did not list it as a special purpose block. Having 
read the responses on this thread and having talked to several people 
off-line, I'm getting the sense that returning 128.66.0.0/16 to the free 
pool should be the recommended action. (Or recognizing that it was 
already returned there earlier ...)

Is everyone happy with this course of action?

We still have no exact information about how widespread the use of this 
block in example is. Google finds some examples and two books from 
O'Reilly published in the 1990s have used it. We also intend to post a 
question in registry and operator forums to solicit further comments. 
Hopefully that will reveal any widespread usage.

I also believe that it would be better to explicitly document the fact 
that this block is no longer reserved for this purpose. Here are some 
suggested words that could go to draft-iana-ipv4-examples, Section 6:

  Note that 128.66.0.0/16 has been used for some examples in
  the past . However, this block did not appear in the list of
  special prefixes in RFC 3330 or its successors, and the block
  is therefore not reserved for any special purpose. The block
  can be used for regular address assignments with caution.

Jari Arkko

---

From: Jari Arkko <[email-masked]>
Date: Sat, 29 Aug 2009 07:50:48 +0300

Geoff,

> works for me 

Good.

> I would avoid this - the problem is that if a future rfc3330 revision 
> drops another block from the reserved set, then this raises the 
> question of if you really meant it if the explicit documentation is 
> missing.

I'd like to push back a little on this. My personal preference is a 
specification style which makes everything very explicit. If a block has 
been used for examples, I think we owe it to the reader to say what its 
fate was. I do agree though that we should not set a precedent that 
every block not listed in RFC 3330(bis)* needs to be explicitly 
mentioned or else they are still somehow reserved. But maybe there is a 
way to write the text that this becomes clearer. How about this:

  Note that 128.66.0.0/16 has been used for some examples in
  the past. However, this role was never specified formally and
  RFC 3330 confirmed that this block has no special role by not
  listing it.

Jari

---

From: Geoff Huston <[email-masked]>
Date: Sat, 29 Aug 2009 20:11:51 +1000

On 29/08/2009, at 2:50 PM, Jari Arkko wrote:
> specification style which makes everything very explicit. If a block  
> has been used for examples, I think we owe it to the reader to say  
> what its fate was. I do agree though that we should not set a  
> precedent that every block not listed in RFC 3330(bis)* needs to be  
> explicitly mentioned or else they are still somehow reserved. But  
> maybe there is a way to write the text that this becomes clearer.  
> How about this:
>

I'm not sure if its "push back" or working though to an acceptable  
consensus in wording that does not set a precedent. I think its a case  
of the latter, and this wording certainly works for me.

regards,

    Geoff