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