Hi,
I have reviewed the draft. Please see my comments below. Most of them are
nits.
Yours,
Daniel
Special-Purpose IP Address Registries
draft-bchv-rfc6890bis-02
1. Introduction
In order to support new protocols and practices, the IETF
occasionally reserves an address block for a special purpose. For
example, [RFC1122] reserves an IPv4 address block (0.0.0.0/8) to
represent the local (i.e., "this") network. Likewise, [RFC4291]
reserves an IPv6 address block (fe80::/10) to represent link-scoped
unicast addresses.
The current list of all special-purpose address blocks are described
in [RFC6890].
MGLT: I find this sentence confusing. It sounds like a reference to some
definitions of RFC6890, which somehow contradict the fact this document
obsoletes RFC6890.
However, several issues have been raised with how
"global" is defined in that document. Specifically, the definition
of global provided in [RFC6890] focuses on the prefix's ability to be
routed globally within the Internet and does not indicate if the
prefix is globally scoped (i.e., may be routed beyond the local link;
described as "global unicast" in the IPv6 addressing architecture
[RFC4291]).
MGLT: I believe the motivation could be more explicitly specified.
I would probably propose something around the lines:
For each special-purpose address block, [RFC6890] defines information
maintained for IPv4 and IPv6 Special-Purpose Address Registries. The use of
the "global" information in [RFC6890] IPv4 and IPv6 Special-Purpose
Address Registries was misleading as it slightly differed from the
generally accepted definition of "global scope", that is the ability by be
forwarded beyond the boundaries of an administrative domain.
This memo reiterates the assignments made to the IPv4 and IPv6
Special-Purpose Address Registries and augments the fields contained
within the registires in order to address the confusion raised by the
definition of "global".
MGLT: registires/registries
Furthermore, this memo defines:
o a common set of information that the registries will maintain
regarding each special-purpose address block
o a common set of requirements for future entries
This memo obsoletes [RFC6890].
MGLT: Although this text is from RFC6890, I understand both bullets to be
section 2.2.1 for ("a common set of requirements for future entries") and
section 2.2.2/3 for ("a common set of information that the registries will
maintain regarding each special-purpose address block"). If I am correct,
the bullets are not in the right order. Although English is not my
language, but the use of "furthermore" seems to give the impression the
current draft defines things that have not been defined in RFC6890, rather
than updating RFC6890.
Feel free to ignore the proposal, but It sounds to me clearer to say
something around the lines:
The current document obsoletes RFC6890. It clarifies the definition for
IPv4 and IPv6 Special-Purpose Address Registries as well as provides an
updated list of the IPv4 and IPv6 Special-Purpose Address Registries.
2. IANA Considerations
2.1. Assignment of an IPv4 Address Block to IANA
2.2. Restructuring of the IPv4 and IPv6 Special-Purpose Address
Registries
2.2.1. Information Requirements
Forwardable - A boolean value indicating whether a router may
forward an IP datagram whose destination address is drawn from the
allocated special-purpose address block between external
interfaces.
MGLT: Should we specify to clarify that Forwardable is set to True whether
the address is forwarded within an administrative domain or between
different administrative domain.
Reserved-by-Protocol - A boolean value indicating whether the
special-purpose address block is reserved by IP, itself. This
value is "TRUE" if the RFC that created the special-purpose
address block requires all compliant IP implementations to behave
in a special way when processing packets either to or from
addresses contained by the address block.
MGLT: This is not very clear to me. When "Forwardable" is set to False for
one address block, I interpret it as a specific behavior to implement. This
seems not to be the case. My interpretation of the RFC requires is that
there is a MUST in that RFC and it does not seem either to be the case. I
believe that we should clarify when True, False, N/A should be set.
If the value of "Destination" is FALSE, the values of "Forwardable"
and "Globally Reachable" must also be false.
MGLT: Maybe this sentence could be placed in the "Destination" information
description.
MGLT: Maybe Source, Destination, Forwardable, Globally Reachable and
Reserved-by-protocol should clearly state when there value is set to True,
False and N/A. I believe that at some point it might help the person
requesting a block to fill the information appropriately.
2.2.2. IPv4 Special-Purpose Address Registry Entries
Table 1 though Table 16,
MGLT: I might be wrong, but I prefer to double check that is not "Table 1
through Table 16" instead.
+----------------------+-------------------------------+
| Attribute | Value |
+----------------------+-------------------------------+
| Address Block | 192.88.99.0/24 |
| Name | Deprecated 6to4 Relay Anycast |
| RFC | [RFC7526] |
| Allocation Date | June 2001 |
| Termination Date | March 2015 |
| Source | N/A |
| Destination | N/A |
| Forwardable | N/A |
| Globally Reachable | N/A |
| Reserved-by-Protocol | N/A |
+----------------------+-------------------------------+
Table 10: 6to4 Relay Anycast
MGLT: Maybe some text should be added to specify that a block even expired
remains registered. I assume that some information are set to N/A as the
block has expired. If that is correct, I believe we need a note in section
2.2.1 that explains the rule in as well as its the motivations.
+----------------------+----------------------+
| Attribute | Value |
+----------------------+----------------------+
| Address Block | 255.255.255.255/32 |
| Name | Limited Broadcast |
| RFC | [RFC0919], Section 7 |
| Allocation Date | October 1984 |
| Termination Date | N/A |
| Source | False |
| Destination | True |
| Forwardable | False |
| Globally Reachable | False |
| Reserved-by-Protocol | True |
+----------------------+----------------------+
Table 16: Limited Broadcast
MGLT: RFC6890 set Reserved-by-protocol to False. I believe that
Reserved-by-Protocol should be clearly formulated so we have no doubts on
how to assign such values. In my case, I have not seen MUST in RFC919
although it mentions "The receiving IP must be able to recognize...". Is
that a sufficient reason ?
2.2.3. IPv6 Special-Purpose Address Registry Entries
+----------------------+---------------+
| Attribute | Value |
+----------------------+---------------+
| Address Block | 2002::/16 [2] |
| Name | 6to4 |
| RFC | [RFC3056] |
| Allocation Date | February 2001 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Globally Reachable | N/A [3] |
| Reserved-by-Protocol | False |
+----------------------+---------------+
Table 27: 6to4
[3] See [RFC3056] for details.
MGLT: Maybe we could provide some additional explanation.
On Fri, Aug 26, 2016 at 2:56 PM, Brian Haberman <[email protected]>
wrote:
> All,
> This version incorporates a feedback from Mike Heard on the
> 255.255.255.255/32 entry.
>
> Regards,
> Brian
>
>
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-bchv-rfc6890bis-02.txt
> Date: Fri, 26 Aug 2016 11:52:25 -0700
> From: [email protected]
> To: Ronald Bonica <[email protected]>, Michelle Cotton
> <[email protected]>, Brian Haberman <[email protected]>,
> Leo Vegoda <[email protected]>, Ron Bonica <[email protected]>,
> Michelle S. Cotton <[email protected]>
>
>
> A new version of I-D, draft-bchv-rfc6890bis-02.txt
> has been successfully submitted by Brian Haberman and posted to the
> IETF repository.
>
> Name: draft-bchv-rfc6890bis
> Revision: 02
> Title: Special-Purpose IP Address Registries
> Document date: 2016-08-26
> Group: Individual Submission
> Pages: 22
> URL:
> https://www.ietf.org/internet-drafts/draft-bchv-rfc6890bis-02.txt
> Status: https://datatracker.ietf.org/doc/draft-bchv-rfc6890bis/
> Htmlized: https://tools.ietf.org/html/draft-bchv-rfc6890bis-02
> Diff: https://www.ietf.org/rfcdiff?url2=draft-bchv-rfc6890bis-02
>
> Abstract:
> This memo updates the IANA IPv6 Special-Purpose Address Registries to
> address issues raised by the definition of a global prefix. For
> completeness, this memo contains all the assignments made by RFC 6890
> to the IANA Special-Purpose Address Registries.
>
> This memo obsoletes RFC 6890.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> _______________________________________________
> Int-area mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/int-area
>
>
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
