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
Ron Bonica wrote:
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.
The only examples that I've found are firewall rule sets that block many ranges now allocated. Such as NANOG 2002 email: http://www.merit.edu/mail.archives/nanog/2002-12/msg00127.html It's no different from net 69 et alia. A couple of larger examples, widely propagated: NoRouteIPs="{127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, 0.0.0.0/7, 2.0.0.0/8, 5.0.0.0/8, 10.0.0.0/8, 23.0.0.0/8, 27.0.0.0/8, 31.0.0.0/8, 69.0.0.0/8, 70.0.0.0/7, 72.0.0.0/5, 82.0.0.0/7, 84.0.0.0/6, 88.0.0.0/5, 96.0.0.0/3, 127.0.0.0/8, 128.0.0.0/16, 128.66.0.0/16, 169.254.0.0/16, 172.16.0.0/12, 191.255.0.0/16, 192.0.0.0/19, 192.0.48.0/20, 192.0.64.0/18, 192.0.128.0/17}" block in log quick on external from 0.0.0.0/7 to any block in log quick on external from 2.0.0.0/8 to any block in log quick on external from 5.0.0.0/8 to any block in log quick on external from 10.0.0.0/8 to any block in log quick on external from 23.0.0.0/8 to any block in log quick on external from 27.0.0.0/8 to any block in log quick on external from 31.0.0.0/8 to any block in log quick on external from 69.0.0.0/8 to any block in log quick on external from 70.0.0.0/7 to any block in log quick on external from 72.0.0.0/5 to any block in log quick on external from 82.0.0.0/7 to any block in log quick on external from 84.0.0.0/6 to any block in log quick on external from 88.0.0.0/5 to any block in log quick on external from 96.0.0.0/3 to any block in log quick on external from 127.0.0.0/8 to any block in log quick on external from 128.0.0.0/16 to any block in log quick on external from 128.66.0.0/16 to any block in log quick on external from 169.254.0.0/16 to any block in log quick on external from 172.16.0.0/12 to any block in log quick on external from 191.255.0.0/16 to any block in log quick on external from 192.0.0.0/19 to any block in log quick on external from 192.0.48.0/20 to any block in log quick on external from 192.0.64.0/18 to any block in log quick on external from 192.0.128.0/17 to any block in log quick on external from 192.168.0.0/16 to any block in log quick on external from 197.0.0.0/8 to any block in log quick on external from 201.0.0.0/8 to any block in log quick on external from 204.152.64.0/23 to any block in log quick on external from 224.0.0.0/3 to any
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).
Return to the free pool immediately. Allocate it to *IXen, who might appreciate it being blocked from view by random outsiders.
participants (2)
-
Ron Bonica -
William Allen Simpson