Subject: Re: [Int-area] Fwd: New Version Notification for draft-bchv-rfc6890bis-02.txt

From: Daniel Migault <[email-masked]>
Date: Tue, 17 Jan 2017 14:00:33 -0500

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-masked]>
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-masked]
> To: Ronald Bonica <[email-masked]>, Michelle Cotton
> <[email-masked]>, Brian Haberman <[email-masked]>,
> Leo Vegoda <[email-masked]>, Ron Bonica <[email-masked]>,
> Michelle S. Cotton <[email-masked]>
>
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>
>

---

From: Leo Vegoda <[email-masked]>
Date: Wed, 25 Jan 2017 02:25:07 +0000

Hi,

Brian Haberman wrote:

[...]

> > 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
> I think that relates to how IANA manages the block.
>
> Michelle or Leo?

This registry is already quite wide and detailed. Adding additional text 
within the registry entry might make it difficult for readers to get a 
complete view of the registry without a particularly wide screen. Instead, 
perhaps we could add a footnote that paraphrases the last sentence of the IC 
section from RFC 7526:

7.  IANA Considerations

   The document creating the "IANA IPv4 Special-Purpose Address
   Registry" [RFC6890] included the 6to4 Relay Anycast prefix
   (192.88.99.0/24) as Table 10.  Per this document, IANA has marked the
   192.88.99.0/24 prefix (originally defined by [RFC3068]) as
   "Deprecated (6to4 Relay Anycast)" and added a reference to this RFC.
   The Boolean values for the address block 192.88.99.0/24 have been
   removed.  Redelegation of this prefix for any use requires
   justification via an IETF Standards Action [RFC5226].

Does that approach work for people? Does this need to be specified in the 
document updating this registry?

Kind regards,

Leo

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Jan 2017 17:28:47 +1300

> document updating this registry?

Hmm. Paraphrasing is always a risk - citing the exact text is safer. Or perhaps
include a definition of 'deprecated' even though it is only used once.

Something like:

An address block marked as Deprecated remains reserved and might still
be in operational use. It should not be used in new deployments and
must not be redelegated except by IETF Standards Action [RFC5226].

    Brian

---

From: Brian Haberman <[email-masked]>
Date: Tue, 24 Jan 2017 19:17:06 -0500

Hi Daniel,
     Thanks for the comments... I have some responses in-line and a
proposed -03 attached...

Michelle & Leo,
     There is a comment below that could benefit from your IANA role.

> definitions of RFC6890, which somehow contradict the fact this document

I dropped the sentence as it adds no value.

> forwarded beyond the boundaries of an administrative domain.

I have re-worded the above motivation.

> MGLT: registires/registries

Fixed.

> updated list of the IPv4 and IPv6 Special-Purpose Address Registries.

I actually dropped the bulleted list and updated the sentence.

> different administrative domain.

I have made this clarification.

> believe that we should clarify when True, False, N/A should be set.

I don't think hard and fast rules are applicable here. The document
defining the special address need to select the values appropriate for
the use they are designing.

> MGLT: Maybe this sentence could be placed in the "Destination" information

The problem with that is one of a forward reference to fields that
haven't been described yet.

> requesting a block to fill the information appropriately.

See my above comment about giving flexibility to future special address
definitions. New scenarios may not fit existing rules.

> through Table 16" instead.

I don't understand this comment.

Michelle or Leo?

The change in value of Reserved-by-Protocol was one of the errata that
this draft is fixing.

> 2.2.3.  IPv6 Special-Purpose Address Registry Entries

We originally tried to do that in 6890 and it ended up looking like a
copy/paste of 3056. That was the reason for using a reference.

Regards,
Brian

---

From: Daniel Migault <[email-masked]>
Date: Thu, 26 Jan 2017 17:41:07 -0500

Hi,

I believe I was confused as the draft defines a new attribute: "Globally
Reachable", but the values True/False/Boolean are not defined by the draft
- inferred from RFCs - , but by the referenced RFC itself. I believe this
example is a good one to indicate that "deprecation" as well as creation or
any updates requires an IETF standard Action. In this case RFC7526
obsoletes RFC3068. Maybe some text could be added to emphasize that this
draft is not supposed to define the values.

I agree the reference to RFC7526 is sufficient and no text needs to be
added. I apology for the confusion.

Yours,
Daniel

---

From: Daniel Migault <[email-masked]>
Date: Mon, 30 Jan 2017 09:21:01 -0500

Hi,

Just to be more specific:
The introduction mentions:
"""
Furthermore, this memo defines:

"""

I think it would be good to make clear that these requirements MUST
 be provided when future allocation are requested.

The reasons to insist on it might be that it has not been always the case,
this RFC changes one type, some values as well, some RFCs mentions
these information as "boolean values"....

I am not saying the text is not mentioned, but maybe we could be more
specific and not waiting for section 2.2 to have this clear.

"""
The "IANA Considerations" section MUST include all
   of the information specified in Section 2.2.1
<https://tools.ietf.org/html/draft-bchv-rfc6890bis-02#section-2.2.1>
of this document.
"""

Regards,

Daniel

On Thu, Jan 26, 2017 at 5:41 PM, Daniel Migault <[email-masked]