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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf