On Sat, Mar 21, 2009 at 03:06:20PM -0700, The IESG wrote:
> - 'Special Use IPv4 Addresses'
> <draft-iana-rfc3330bis-06.txt> as an Informational RFC
It is worth documenting the changes to several allocations or assignments since
RFC 3330 and the draft does that well.
Here are some questions and remarks that could be addressed before publication.
Should I have re-opened issues from earlier discussion, I'd appreciate a pointer
to the proper venue. Please don't be annoyed by the length of this; I've quoted
extensively and some comments apply to several paragraphs.
Summary: I do not believe the use of normative language is appropriate in this
document. The assignment policy for 192.0.0/24 is missing. Several editorial
remarks.
> This document is a revision of RFC 3330 [RFC3330], which it
> obsoletes; its primary purpose is to re-publish the technical content
> of RFC 3330 mostly unchanged as an Informational RFC.
RFC 3330 was Informational, too, and the changes between the two _are_ important.
Maybe: "its primary purpose is to reflect the changes to the list of special
IPv4 assignments since the publication of RFC 3330."
> 2. Terminology
>
> The terms "Specification Required", "Expert Review", "IESG Approval",
> "IETF Review", and "Standards Action", are used in this memo to refer
> to the processes described in [RFC5226].
There is no further reference to these keywords; otherwise [RFC5226]
should be a normative reference, but I believe this paragraph can be
deleted.
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in BCP 14, [RFC2119].
While normative language can appear in Informational documents, due to
the purely descriptive nature of previous actions I think it is inappropriate
in this draft (see below).
> 3. Differences between this document and RFC 3330
[...]
This rationale for the RFC update is very interesting and helpful, but would
probably better go into an appendix, so that the changes appear after the
actual content.
NIT: consistent use of "an RIR" vs "a RIR"
> 4. Global and Other Specialized Address Blocks
>
> 0.0.0.0/8 - Addresses in this block refer to source hosts on "this"
> network. Address 0.0.0.0/32 may be used as a source address for this
> host on this network; other addresses within 0.0.0.0/8 may be used to
> refer to specified hosts on this network [RFC1122], page 30.
NIT: use ``"this"'' consistently.
> 10.0.0.0/8 - This block is set aside for use in private networks.
> Its intended use is documented in [RFC1918]. Addresses within this
> block SHOULD NOT appear on the public Internet and can be used
> without any coordination with IANA or an Internet registry.
My reading of RFC 1918 suggests a stronger approach, even though RFC 1918
predates RFC 2119. But more importantly: either this is an update or
clarification to RFC 1918, then it should say so in the header _and_
this document should aim at BCP, or (preferrably) this is just descriptive,
then the RFC 2119 language should not be used.
> 127.0.0.0/8 - This block is assigned for use as the Internet host
> loopback address. A datagram sent by a higher level protocol to an
> address anywhere within this block should loop back inside the host.
> This is ordinarily implemented using only 127.0.0.1/32 for loopback,
> and addresses within this block SHOULD NOT appear on any network
> anywhere [RFC1122], page 31.
Again, the wording in RFC1122 is stronger, and with the same pre-2119 caveat
as above, the normative language should not be used here IMHO.
> 172.16.0.0/12 - This block is set aside for use in private networks.
> Its intended use is documented in [RFC1918]. Addresses within this
> block SHOULD NOT appear on the public Internet and can be used
> without any coordination with IANA or an Internet registry.
See above (10/8).
> 192.0.0.0/24 - This block is reserved for IETF protocol assignments.
This block is the only reservation that survived since RFC 3330. Is there
any description of the registration/assignment policy?
> 192.0.2.0/24 - This block is assigned as "TEST-NET" for use in
> documentation and example code. It is often used in conjunction with
> domain names example.com or example.net in vendor and protocol
> documentation. Addresses within this block SHOULD NOT appear on the
> public Internet and can be used without any coordination with IANA or
> an Internet registry.
Now, this is the only occurence of normative language that makes sense to
me, only because I couldn't find any previous RFC except outdated "Assigned
Numbers" that actually describes the designation of 192.0.2/24. However,
for consistency reasons and to accomodate the additional demand for
documentation only prefixes, I'd rather see this covered in a separate
document (such as RFC 3849 for the v6 case).
NIT: "example.{com,net}" used without reference to RFC 2606
NIT: "Internet registry" isn't a defined term; maybe refer to RFC 2050?
> 192.168.0.0/16 - This block is set aside for use in private networks.
> Its intended use is documented in [RFC1918]. Addresses within this
> block SHOULD NOT appear on the public Internet and can be used
> without any coordination with IANA or an Internet registry.
See above (10/8).
> 240.0.0.0/4 - This block, formerly known as the Class E address
> space, is reserved. The "limited broadcast" destination address
> 255.255.255.255 SHOULD NOT be forwarded outside the local network of
> the source. The remainder of this space is reserved for future use.
> See [RFC1112], page 2.
While the designation of 240/4 as "Class E"/reserved appears in section 4 of
RFC 1112 (that's page 3), the link local broadcast is described in two other
RFCs that are part of the STD0005 set: RFC 919 and RFC 922:
The address 255.255.255.255 denotes a broadcast on a local hardware
network, which must not be forwarded. This address may be used, for
example, by hosts that do not know their network number and are
asking some server for it.
Again, the language in the draft appears too weak, IMHO. In any case,
"NOT be forwarded outside the local network" is ambiguous; there must be
no layer 3 forwarding for these packets at all. Ceterum censeo: no normative
language here.
> 6. Assignments of IPv4 Blocks for New Specialized Uses
>
> The IANA has responsibility for making assignments of protocol
> parameters used in the Internet according to the requirements of the
> "Memorandum of Understanding Concerning the Technical Work of the
> Internet Assigned Numbers Authority" [RFC2860]. Among other things,
> [RFC2860] requires that protocol parameters be assigned according to
> the criteria and procedures specified in RFCs, including Proposed,
> Draft, and full Internet Standards and Best Current Practice
> documents, and any other RFC that calls for IANA assignment.
>
> The domain name and IP address spaces involve policy issues (in
> addition to technical issues) so that the requirements of [RFC2860]
> do not apply generally to those spaces. Nonetheless, the IANA is
> responsible for ensuring assignments of IPv4 addresses as needed in
> support of the Internet Standards Process. When a portion of the
> IPv4 address space is specifically required by an RFC, the technical
> requirements (e.g., size, prefix length) for the portion should be
> described [RFC5226]. Immediately before the RFC is published, the
> IANA will, in consultation with the Regional Internet Registries,
> make the necessary assignment and notify the RFC Editor of the
> particulars for inclusion in the RFC as published.
>
> As required by [RFC2860], the IANA will also make necessary
> experimental assignments of IPv4 addresses, also in consultation with
> the Regional Internet Registries.
This section has remained unaltered since RFC 3330, except for the reference
update (2434->5226). Still, I am not convinced that RFC 5226 covers the case
of IPv4 unicast address assignments through IANA, even though the process
outlined here follows RFC 5226, section 5.1. In other words, the informal
process described above, that uses IANA as the IETF's interface to the RIRs,
isn't governed by RFC 5226, it's only that the same textual method is
suggested for addresses that RFC 5226 defines for protocol parameter assignments.
For the purposes of the document, this section might not be needed at all.
-Peter
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf