Special Use IPv4 Addresses
draft-iana-rfc3330bis-11

[Ballot comment]
My Discuss was fixed by adding "legitimately" in many places, but I note...

  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 loops back inside the host.  This
  is ordinarily implemented using only 127.0.0.1/32 for loopback.  As
  described in [RFC1122], Section 3.2.1.3, addresses within the entire
  127.0.0.0/8 block do not appear on any network anywhere.

In fact, RFC1122 goes on to describe the behavior a router must follow if it receives a packet with a loopback address. So this would be another case for "legitimately".

[Ballot discuss]
Building on Dan's Comment I wouldlike to discuss the use of 2119 language throughout.

The only use of 2119 seems to be in the Security section, and Dan correctly points out the inconsistency of usage within that section.

But I have a wider question about the use of "do not" and "cannot". For example, in the discussion of 10.0.0.0/8 I don't understand the change from the language used in RFC 3330.

We used to have...
  Addresses within this block should not appear on the public Internet.

Now we have...
  addresses within this block do not appear on the public Internet. 

I don't see how that assertion can be upheld. Indeed, the Security section points out that attacks may be made by injecting packets with "reserved" addresses into private networks from the Internet. Furthermore, I can easily send a packet on the public Internet addressed to 10.0.0.1. It should not get routed or replied, but that doesn't mean it doesn't appear.

Changing this back to shoulds and musts and using RFC 2119 language seems appropriate.

[Ballot comment]
I support Adrian's discuss issue regarding  the use of "do not" and "cannot".

I wonder if it could be resolved by the following change:
OLD
    addresses within this block do not appear on the public Internet. 
NEW
    addresses within this block do not legitimately appear on the public Internet. 

For me, the word "legitimately" clarifies that it can happen, but that it is either
a mistake or an attack.

This change, or some other like it, needs to occur in five places in section 3.

[Ballot discuss]
Building on Dan's Comment I wouldlike to discuss the use of 2119 language throughout.

The only use of 2119 seems to be in the Security section, and Dan correctly points out the inconsistency of usage within that section.

But I have a wider question about the use of "do not" and "cannot". For example, in the discussion of 10.0.0.0/8 I don't understand the change from the language used in RFC 3330.

We used to have...
  Addresses within this block should not appear on the public Internet.

Now we have...
  addresses within this block do not appear on the public Internet. 

I don't see how that assertion can be upheld. Indeed, the Security section points out that attacks may be made by injecting packets with "reserved" addresses into private networks from the Internet. Furthermore, I can easily send a packet on the public Internet addressed to 10.0.0.1. It should not get routed or replied, but that doesn't mean it doesn't appear.

Changing this back to shoulds and musts and using RFC 2119 language seems appropriate.

[Ballot comment]
In Section 7 - 'if you expect (for instance) that all packets from a
  private address space such as the 10.0.0.0/8 block or the link local
  block 169.254.0.0/16 originate within your subnet, all routers at the
  border of your network should filter such packets that originate from
  outside your network.'

I believe the 'should' in this phrase needs to be capitalized 'SHOULD', which would also be consistent with the 'SHOULD NOT' in the following paragraph o fthe same section.

[Ballot comment]
Section 3., paragraph 7:
>    documentation.  As described in [TBD-REF-IANA-IPV4-EXAMPLES],

  Missing Reference: 'TBD-REF-IANA-IPV4-EXAMPLES' is mentioned on line
  180, but not defined


Section 9.2., paragraph 10:
>    [RFC2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
>              Names", BCP 32, RFC 2606, June 1999.

  Unused Reference: 'RFC2606' is defined on line 324, but no explicit
  reference was found in the text


Section 9.2., paragraph 16:
>    [RFC5156]  Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
>              April 2008.

  Unused Reference: 'RFC5156' is defined on line 345, but no explicit
  reference was found in the text

[Ballot discuss]
Section 4., paragraph 1:
> 192.0.2.0/24        TEST-NET-1                TBD-REF-IANA-IPV4EXAMPLES

  DISCUSS: What reference is [TBD-REF-IANA-IPV4EXAMPLES]? (This is also
  called TBD-REF-IANA-IPV4-EXAMPLES elsewhere in the text.)

Section 9.1., paragraph 1:
>    [I-D.iana-special-ipv4-registry]
>              Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special
>              Purpose Address Registry",
>              draft-iana-special-ipv4-registry-01 (work in progress),
>              February 2009.

  DISCUSS: Downref: Normative reference to an Informational draft:
  draft-iana-special-ipv4-registry (I think this can simply be converted
  into an Informative reference)

[Ballot comment]
Section 3., paragraph 7:
>    documentation.  As described in [TBD-REF-IANA-IPV4-EXAMPLES],

  Missing Reference: 'TBD-REF-IANA-IPV4-EXAMPLES' is mentioned on line
  180, but not defined


Section 9.2., paragraph 10:
>    [RFC2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
>              Names", BCP 32, RFC 2606, June 1999.

  Unused Reference: 'RFC2606' is defined on line 324, but no explicit
  reference was found in the text


Section 9.2., paragraph 16:
>    [RFC5156]  Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
>              April 2008.

  Unused Reference: 'RFC5156' is defined on line 345, but no explicit
  reference was found in the text

[Ballot discuss]
Section 4., paragraph 1:
> 192.0.2.0/24        TEST-NET-1                TBD-REF-IANA-IPV4EXAMPLES

  DISCUSS: What reference is [TBD-REF-IANA-IPV4EXAMPLES]?

Section 9.1., paragraph 1:
>    [I-D.iana-special-ipv4-registry]
>              Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special
>              Purpose Address Registry",
>              draft-iana-special-ipv4-registry-01 (work in progress),
>              February 2009.

  DISCUSS: Downref: Normative reference to an Informational draft:
  draft-iana-special-ipv4-registry (I think this can simply be converted
  into an Informative reference)

[Ballot comment]
In the last paragraph of section 3, for clarity:

OLD:

  The one exception to this is the "limited broadcast" destination
  address 255.255.255.255.  As described in [RFC0919] and [RFC0922],
  packets with this destination address are not forwarded at IP layer.

NEW:

  The one exception to the designation of 240.0.0.0/4 as reserver
  is the "limited broadcast" destination
  address 255.255.255.255.  As described in [RFC0919] and [RFC0922],
  packets with this destination address are not forwarded at IP layer.

IANA comments:

IANA will implement the request to assign two additional IPv4 /24
prefixes for use in documentation and sample code. We will identify
two prefixes and include them in an update to the document. Unless
there is considerably more support for a separate document describing
the assignment of the TEST-NET prefixes, IANA would prefer to address
the issue in draft-iana-rfc3330bis.

In addition, IANA intends to

- review and work with the IESG on normative language

- improve the language in the Security Considerations section

- add a reference to draft-iana-special-ipv4-registry, which
documents the assignment of 192.0.0.0/24

-  and change the document's intended status from Informational to BCP.

Comments provided to the author.  The document is inconsistent about being Informational or BCP.  That needs to be cleared up, but the comments have assumed BCP is the desired outcome.