Draft Proposal: Assignment of an IPv4 /24 for documentation purposes
Dear WG, this is a rough draft policy proposal. I'd appreciate some feedback before I decide whether to invoke the formal process. Summary: The RIPE NCC is asked to assign an IPv4 /24 for documentation purposes. Background: In example configurations, RFCs, training material and other documentation it is necessary from time to time to include IP addresses, domain names or even phone numbers as examples. These resources should meet all syntactical requirements (e.g., be "real" IP addresses), but should not interfere with assignments or registrations by innocent third parties. See RFC 4085 (BCP 105) for what could happen in the worst case. For the DNS, RFC 2606 (BCP 32) has set aside several top level and second level domain names and the network 192.0.2/24 has been dedicated for documentation and test purposes by the IANA in the past (see RFC 3330). RFC 3849 ("IPv6 Address Prefix Reserved for Documentation") documents APNIC's assignment of 2001:DB8::/32 for the sole use in example texts. Motivation: During recent discussion within the IETF, but also on other occasions in the past, it appeared that a single /24 is often not enough to support instructive examples. This may include more complex network designs, or the use of addresses for DNS name servers, where good practice (see RFC 2182, BCP 16) suggests topological diversity. Sometimes, address space from RFC 1918 (BCP 5) is used in addition to or as a replacement for 192.0.2/24, but this is also a source of confusion due to the special nature of the "private address space". It also conflicts with the goal to avoid any collision with addresses used in real life, even if the burden would be spread across many users of RFC 1918 address space. Request: The RIPE NCC is asked to assign and dedicate a /24 that is reasonable visually distinct from 192.0.2/24 for documentation only purposes. The network is not to be used and the prefix is never expected to be announced in any BGP session (cf. 3849). The new assignment is not intended to serve as a supplement to RFC 1918 address space. It is intentionally left open here whether similar considerations would suggest an additional assignment in v6 space, as well. The pros should be obvious to anyone who ever had to write documentation or example configurations, but there are also some cons: o another /24 is a waste of space o just a /24 won't be enough o this creates yet another bogon o any invest in IPv4 is a waste of resources, anyway o nobody knew 192.0.2/24 in the first place, so why add to the confusion? o this doesn't need a policy proposal, but could be dealt with through a specially "sponsored" PI assignment A special action seems cleaner to me than some random PI assignment, but this is why I'd like to ask the WG for feedback. Also, if anyone is aware of other address space similar to 192.0.2/24, I'd appreciate a pointer. Best regards, Peter
Hello Peter, Why not use private address space in documentation? It is used many times for things it is not really designed for, but it works great. For example the 10.254.254.0/24 is a range I did see a long time back in documentation, it is something that could be used in documentation I guess. Default private address space that is used on devices are in the 192.168.x.x range and 10.0.x.x and 10.10.x.x and 10.8.x.x range for as far as I know. Wasting IPv4 IPs isn't good for the future I guess. Also I am missing some other private address space that I did never see in use. Best regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Peter Koch Sent: woensdag 15 april 2009 18:58 To: RIPE address policy WG Subject: [address-policy-wg] Draft Proposal: Assignment of an IPv4 /24 for documentation purposes Dear WG, this is a rough draft policy proposal. I'd appreciate some feedback before I decide whether to invoke the formal process. Summary: The RIPE NCC is asked to assign an IPv4 /24 for documentation purposes. Background: In example configurations, RFCs, training material and other documentation it is necessary from time to time to include IP addresses, domain names or even phone numbers as examples. These resources should meet all syntactical requirements (e.g., be "real" IP addresses), but should not interfere with assignments or registrations by innocent third parties. See RFC 4085 (BCP 105) for what could happen in the worst case. For the DNS, RFC 2606 (BCP 32) has set aside several top level and second level domain names and the network 192.0.2/24 has been dedicated for documentation and test purposes by the IANA in the past (see RFC 3330). RFC 3849 ("IPv6 Address Prefix Reserved for Documentation") documents APNIC's assignment of 2001:DB8::/32 for the sole use in example texts. Motivation: During recent discussion within the IETF, but also on other occasions in the past, it appeared that a single /24 is often not enough to support instructive examples. This may include more complex network designs, or the use of addresses for DNS name servers, where good practice (see RFC 2182, BCP 16) suggests topological diversity. Sometimes, address space from RFC 1918 (BCP 5) is used in addition to or as a replacement for 192.0.2/24, but this is also a source of confusion due to the special nature of the "private address space". It also conflicts with the goal to avoid any collision with addresses used in real life, even if the burden would be spread across many users of RFC 1918 address space. Request: The RIPE NCC is asked to assign and dedicate a /24 that is reasonable visually distinct from 192.0.2/24 for documentation only purposes. The network is not to be used and the prefix is never expected to be announced in any BGP session (cf. 3849). The new assignment is not intended to serve as a supplement to RFC 1918 address space. It is intentionally left open here whether similar considerations would suggest an additional assignment in v6 space, as well. The pros should be obvious to anyone who ever had to write documentation or example configurations, but there are also some cons: o another /24 is a waste of space o just a /24 won't be enough o this creates yet another bogon o any invest in IPv4 is a waste of resources, anyway o nobody knew 192.0.2/24 in the first place, so why add to the confusion? o this doesn't need a policy proposal, but could be dealt with through a specially "sponsored" PI assignment A special action seems cleaner to me than some random PI assignment, but this is why I'd like to ask the WG for feedback. Also, if anyone is aware of other address space similar to 192.0.2/24, I'd appreciate a pointer. Best regards, Peter
Peter Koch wrote:
The new assignment is not intended to serve as a supplement to RFC 1918 address space. It is intentionally left open here whether similar considerations would suggest an additional assignment in v6 space, as well.
Why would you not want to use RFC1918's IPs in documentation? Everybody inclined enough to read documentation will probably know those addresses at a glance ... instead, you want to throw a new set of IPs on the market that nobody knows, nobody cares for, most likely nobody will use and that have no real benefit as far as documentation goes ... (at least none I'd see). Heck, I've never known that 192.0.2/24 is reserved for test purposes ... or that there are "test domains" ... but maybe I'm just ignorant ... ;) (not that saving that /24 would mitigate the dawning IPv4 shortage ...) -garry
On 15/04/2009 17:57, Peter Koch wrote:
A special action seems cleaner to me than some random PI assignment, but this is why I'd like to ask the WG for feedback. Also, if anyone is aware of other address space similar to 192.0.2/24, I'd appreciate a pointer.
Isn't this sort of thing more the area of the IETF? I'm not sure if it's really the responsibility of a regional IR to assign space for this sort of thing, in much the same way that I am sure that it's more appropriate to have this sort of thing encoded in an RFC. Nick
Hello Peter,
For the DNS, RFC 2606 (BCP 32) has set aside several top level and second level domain names and the network 192.0.2/24 has been dedicated for documentation and test purposes by the IANA in the past (see RFC 3330).
I am curious why the RIPE NCC is asked for this /24. If IANA has provided 192.0.2/24 in the past, why can't IANA provide another /24? It would require an RFC, but isn't that the right place to do this? Just trying to get all the background information :) Sander
On 16/04/2009, at 5:52 AM, Sander Steffann wrote:
Hello Peter,
For the DNS, RFC 2606 (BCP 32) has set aside several top level and second level domain names and the network 192.0.2/24 has been dedicated for documentation and test purposes by the IANA in the past (see RFC 3330).
I am curious why the RIPE NCC is asked for this /24. If IANA has provided 192.0.2/24 in the past, why can't IANA provide another /24? It would require an RFC, but isn't that the right place to do this?
Just trying to get all the background information :) Sander
Perhaps I may be permitted to add some background data here. This topic has surfaced in the past in the case of IPv6 addresses and AS numbers. In the case of IPv6 the original APNIC proposal was rephrased as an RFC and the IANA documented the reservation in the IPv6 address registry on the basis of the published RFC. In the case of AS numbers there was a policy proposal in APNIC whose implementation was abandoned following the publication of an RFC that requested IANA to perform the registration. My interpretation of the relative roles of the RIRs, IANA and the IETF in this area is that such reservations, as distinct from allocations or assignments, should be performed by the IANA, and for IANA to undertake this it should be part of the protocol's address plan, and hence should be published as an RFC. i.e. as far as I understand the situation such reservations of number resources for documentation purposes falls to IANA to perform, and the instructions to IANA are in the form of a published RFC. The logical inference is that such proposals should head to the IETF rather than the RIRs. thanks, Geoff
Hi Geoff,
Perhaps I may be permitted to add some background data here.
Ofcourse! Thank you :)
My interpretation of the relative roles of the RIRs, IANA and the IETF in this area is that such reservations, as distinct from allocations or assignments, should be performed by the IANA, and for IANA to undertake this it should be part of the protocol's address plan, and hence should be published as an RFC. i.e. as far as I understand the situation such reservations of number resources for documentation purposes falls to IANA to perform, and the instructions to IANA are in the form of a published RFC. The logical inference is that such proposals should head to the IETF rather than the RIRs.
I had the same feeling, but it's good to get this background information. Thanks, Sander
Dear WG,
Summary: The RIPE NCC is asked to assign an IPv4 /24 for documentation purposes.
thanks for all the questions and comments. It seems that several people share the need but the current wisdom suggests that a formal policy proposal is not necessary right now. In responding to the original message I'll try to address the questions in a single message. Apologies for anyone I missed. Basicly, two questions came up: 1) Why not use RFC 1918 space for documentation purpose? 2) Why not address this through IANA/IETF (or: why RIPE [NCC])? An attempt to address the first question was already in the proposal,
Sometimes, address space from RFC 1918 (BCP 5) is used in addition to or as a replacement for 192.0.2/24, but this is also a source of confusion due to the special nature of the "private address space". It also conflicts with the goal to avoid any collision with addresses used in real life, even if the burden would be spread across many users of RFC 1918 address space.
but the feedback suggests some additional explanation could help in whatever document will describe additional documentation prefixes. Also, the awareness of these special reservations could be raised (and I missed RFC 5398 as a reference myself). The second question or bundle of questions deserves more thought: o Why do this in the RIPE region? There's nothing special, any of the five RIRs would do, it's just that this region is the one I had easiest "access" to. As Geoff mentioned (see below), the IPv6 and ASN examples have resulted from similar initiatives in the APNIC region. o Isn't this something for the IETF or IANA to do? Geoff was kind enough to provide detailed background:
This topic has surfaced in the past in the case of IPv6 addresses and AS numbers.
In the case of IPv6 the original APNIC proposal was rephrased as an RFC and the IANA documented the reservation in the IPv6 address registry on the basis of the published RFC.
In the case of AS numbers there was a policy proposal in APNIC whose implementation was abandoned following the publication of an RFC that requested IANA to perform the registration.
My interpretation of the relative roles of the RIRs, IANA and the IETF in this area is that such reservations, as distinct from allocations or assignments, should be performed by the IANA, and for IANA to undertake this it should be part of the protocol's address plan, and hence should be published as an RFC. i.e. as far as I understand the situation such reservations of number resources for documentation purposes falls to IANA to perform, and the instructions to IANA are in the form of a published RFC. The logical inference is that such proposals should head to the IETF rather than the RIRs.
and I'm foolish enough to argue the following: Once the addresses (or number resources) are instantiated and handed over to IANA for distribution (maintenance) through the RIRs, they are out of the hands of the IETF but subject to the applicable policies set in the respective regions. When an addressing (or numbering) plan is designed from scratch, a special range can be set aside as "protocol elements" rather than number resources and subsequently be reserved or dedicated for the purpose intended here (and others). But this time is long since gone for IPv4. {192.0.2/24 appears in an "Assigned Numbers" or "Internet Numbers" RFC the first time around March 1987: RFC 997, was UNASSIGNED in RFC 990.} So, my reading is that the IETF has no such addresses at its disposal (in contrast to, say, 240/4, not yet dedicated). Now, the IETF can ask IANA (in a different role) to assign these prefixes, but where would IANA get these? As the IPv6 example quoted above shows, there's little else than go asking the RIRs to "hand back" the requested assignment (or reservation). Fine, but under what criteria (read: policy) would an RIR satisfy this request? Back to square one. Meanwhile I have been very kindly enlightened off-list that things are already progressing (the source may or may not choose to elaborate here), so I'm convinced that no further action on this draft proposal is necessary. Thanks for all the responses, Peter
* Peter Koch:
During recent discussion within the IETF, but also on other occasions in the past, it appeared that a single /24 is often not enough to support instructive examples. This may include more complex network designs, or the use of addresses for DNS name servers, where good practice (see RFC 2182, BCP 16) suggests topological diversity.
Uhm? Thanks to CIDR and IGPs supporting VLSMs, it's possible to have topological diversity within a /24. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On 21/04/2009 15:54, Florian Weimer wrote:
Uhm? Thanks to CIDR and IGPs supporting VLSMs, it's possible to have topological diversity within a /24.
Sometimes for the purposes of documentation, it helps to have different significant digits to clearly indicate different subnets. I don't think that there should be a problem filing away a couple of /24s for this purpose: we have quite a few left, and documentation is a worthy cause. Nick
participants (7)
-
Florian Weimer -
Garry Glendown -
Geoff Huston -
Nick Hilliard -
Peter Koch -
Sander Steffann -
Stream Service