Subject: Re: Last Call: <draft-bonica-special-purpose-03.txt> (Special-Purpose Address Registries) to Best Current Practice

From: Randy Bush <[email-masked]>
Date: Fri, 30 Nov 2012 06:42:40 +0900

first cuppa, so i am easily confuddled.  and apologies for doing this at
last call.

are the following definitions

   o  Routable - A boolean value indicating whether a IP datagram whose
      destination address is drawn from the allocated special-purpose
      address block is routable (i.e., may traverse more than a single
      IP interface)

   o  Global - A boolean value indicating whether a IP datagram whose
      destination address is drawn from the allocated special-purpose
      address block is routable beyond a specified administrative
      domain.

intended to be baked in hardware, or are they SHOULDs to operators?  i
look at RFC 1918 space and 127.0.0.0/8 and am not so sure how hard these
boundaries are meant to be.  i worry because i think we regret how we
specified (threw away is more like it) E space.

does the prefix describes a specific prefix length or a covering range?

e.g. 192.0.0.0/24 is neither routable nor global, while a subnet,
192.0.0.0/29, is routable.  i.e. might i route and forward
192.0.0.128/25?

randy

---

From: Geoff Huston <[email-masked]>
Date: Fri, 30 Nov 2012 09:26:42 +1100

On 30/11/2012, at 7:55 AM, The IESG <[email-masked]> wrote:

> 
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Special-Purpose Address Registries'
>  <draft-bonica-special-purpose-03.txt> as Best Current Practice
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2013-01-02. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This memo instructs IANA to restructure its IPv4 and IPv6 Special-
>   Purpose Address Registries.  Upon restructuring, the aforementioned
>   registries will record all special-purpose address blocks,
>   maintaining a common set of information regarding each address block.
> 
>   This memo updates RFC 5736 and RFC 4773, which define the current
>   structure of the IPv4 and IPv6 Special-Purpose Address Registries.
>   It also obsoletes RFC 5735 and RFC 5156 which document special-
>   purpose address blocks that are not currently, but will in the
>   future, be recorded in the IPv4 and IPv6 Special-Purpose Address
>   Registries.
> 

I am not in favour of publication of this draft in its current form. 

The reasons for this are that I believe that the draft continues to promote a position that has been espoused in recent drafts it references that blurs the distinction between a special purpose address assignment and an address reservation. I believe that this distinction is a useful distinction and the number registries should explicitly preserve this distinction rather than blur it out.

In my view reservations are an implicit part of the address plan for the protocol, and the expectation behind the reservation is that all implementations of the protocol will honour the same set of reservations in the same way. For example 0/8 is a reservation - all conformant implementations of the IPv4 would be expected to treat addresses drawn from 0/8 in the same fashion, namely as self identification.

On the other hand I see 192.88.99.0/24 as an IANA special purpose assignment - its use is by a particular application or service, and conformant implementations of the IPv4 protocol stack are under no obligation to treat IP packets that include this address in any way that is different to any other general use IPv4 address.

I see the proposal to push reservations and special purpose allocations into a single registry as being a source of potential confusion in so far as it a) blurs the distinction between what all conformant implementations of the protocol stack must respect in terms of reservation of addresses and the behaviour of the protocol stack if and when a reserved address is encountered and b) does not explicitly state the policies relating to the manner in which an address block is reserved and the policies relating to the manner in which an address block is assigned by virtue of a special purpose registry assignment.

I also disagree with the approach to publish the intended contents of this special purpose registry as an RFC ans the registry itself is the intended mode of authoritatively describing those resources that have been assigned for special purposes. Obviously any RFC will age out and drift away from the registry, and the need to constantly publish updating RFCs to ensure that the latest RFC is reasonably close to the registry contents seems to me to be counter-productive at best.

I can appreciate the "better housekeeping" motivation behind this draft, to group all IANA-held resources into a single registry, but I do not agree with this motivation given that the reason WHY resources are located in an IANA-maintained registry is then not explicit. Such addresses as listed in this draft can be delineated into reservations as part of the protocol's overall address plan, and special purpose address assignments that are undertaken by the IANA in support of particular applications and service operation that are not necessarily part of the protocol's underlying address plan and do not require reserved behaviours on the part of implementions of the protocol stack when such addresses are encountered.

Geoff

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Nov 2012 07:31:18 +0900

hi geoff,

i get your point.  but it sure is convenient to find everything in one
place.  can your issues be addressed by adding an attribute(s) to the
entries?

randy

---

From: Geoff Huston <[email-masked]>
Date: Fri, 30 Nov 2012 09:45:32 +1100

> place.  can your issues be addressed by adding an attribute(s) to the

Convenience vs maning a semantic distinction overt.

Yes, it is possible to add an attribute to a common registry.

On the other hand it is possible to realign what entries go in which registry according to:

- "reservations" to be in the "main" registry, using a working definition of a "reservation" as something that all implementations of the protocol have to honour.

- all other IANA special purpose address assignments to be placed in this special purpose registry (including, for example RFC1918 space, 6to4 relays, etc), and the RFC to document the process of special purpose assignment.

Geoff

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Nov 2012 08:04:47 +0900

> - "reservations" to be in the "main" registry, using a working
>   definition of a "reservation" as something that all implementations
>   of the protocol have to honour.
> 
> - all other IANA special purpose address assignments to be placed in
>   this special purpose registry (including, for example RFC1918 space,
>   6to4 relays, etc), and the RFC to document the process of special
>   purpose assignment.

an N-ary attribute or N lists, semantically about the same, syntax seems
a matter of taste.  i agree with the distinction, and am happy with
either syntax.

randy

---

From: Pete Resnick <[email-masked]>
Date: Thu, 29 Nov 2012 17:41:46 -0600

Like Randy, I am completely agnostic on the question of dividing the 
registries vs. adding an attribute to the registries to distinguish 
between reservations and other special uses. But one comment on the 
other item in your message:

> I also disagree with the approach to publish the intended contents of this special purpose registry as an RFC ans the registry itself is the intended mode of authoritatively describing those resour…

I think (hope) you've misinterpreted this. The document serves two 
purposes: To define the registries (section 2.1, which is really the 
BCPish part of this document) and to populate the registries with 
initial values (sections 2.2 and 2.3). 2.1 is the real content of the 
documentthat will live on, get updated, etc., whereas 2.2 and 2.3 are 
probably better as an appendix, and I don't think there's any 
expectation that those sections ought to be kept up to date with future 
RFCs to match the registry. (Indeed, it might be nice if 2.2 and 2.3 
were removed before publication, but that's not been our practice.)

Does that allay your concern?

For the authors, one thing I did notice in section 2:

    IANA will update the aforementioned registries as requested in the
    "IANA Considerations" section of an IESG-reviewed document.  The "
    IANA Considerations" section must include all of the information
    specified in Section 2.1 of this document.

It would probably be better to use the specific 5226 language of "IETF 
Review", "IESG Approval" or "Standards Action" (whichever you really 
mean) instead of "an IESG-reviewed document".

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Geoff Huston <[email-masked]>
Date: Fri, 30 Nov 2012 11:15:15 +1100

On 30/11/2012, at 10:41 AM, Pete Resnick <[email-masked]> wrote:

> Like Randy, I am completely agnostic on the question of dividing the registries vs. adding an attribute to the registries to distinguish between reservations and other special uses. But one comment on the other item in your message:
> 
> I think (hope) you've misinterpreted this. The document serves two purposes: To define the registries (section 2.1, which is really the BCPish part of this document)

And I was saying that I would prefer to see protocol address plan reservations not be included in the special purpose registry.

> and to populate the registries with initial values (sections 2.2 and 2.3).

Some time ago there was value in this "initial population" concept to sort some of the claims of special purpose address assignments, but I thought that we were over it and the draft restates what is already n the registry.

> 2.1 is the real content of the documentthat will live on, get updated, etc., whereas 2.2 and 2.3 are probably better as an appendix, and I don't think there's any expectation that those sections ought to be kept up to date with future RFCs to match the registry. (Indeed, it might be nice if 2.2 and 2.3 were removed before publication, but that's not been our practice.)

Personally the removal before publication of the registry contents would be something I would support.

> Does that allay your concern?

no - as I would prefer to see protocol address plan reservations not be included in the special purpose registry. The IPv4 address plan reservations appear to be 0/8, 127/8 and  240/4. The others appear to be various forms of special prupose assignments. In IPv6 I see reservations for ::1/128, ::/128 as far as I can tell - the remainder are reasonably seen as Special Purpose Assignments I would suggest.

regards,

  Geoff

---

From: SM <[email-masked]>
Date: Thu, 29 Nov 2012 19:22:46 -0800

>[email-masked] mailing lists by 2013-01-02. Exceptionally, comments may be

 From the Abstract:

   "This memo updates RFC 5736 and RFC 4773, which define the current
    Registries."

BCP 153 is about Special Use IPv4 addresses.  This intended BCP will 
create a mishmash as the draft covers both IPv4 and IPv6.  I suggest 
handling the IP versions in two separate drafts.

RFC 5375 is being obsoleted by this draft.  RFC 6598 updates RFC 
5375.  Could someone explain that to me (see 
http://www.rfc-editor.org/errata_search.php?rfc=5375&eid=3309 and the 
relevant discussion for details)?

The following text is from RFC 3330 which was written by the Internet 
Assigned Numbers Authority:

   "Throughout its entire history, the Internet has employed a central
    Internet Assigned Numbers Authority (IANA) responsible for the
    allocation and assignment of various identifiers needed for the
    operation of the Internet [RFC1174].  In the case of the IPv4 address
    space, the IANA allocates parts of the address space to Regional
    Internet Registries according to their established needs.  These
    Regional Internet Registries are responsible for the assignment of
    IPv4 addresses to operators and users of the Internet within their
    regions.

    [paragraph omitted]

    On an ongoing basis, the IANA has been designated by the IETF to make
    assignments in support of the Internet Standards Process [RFC2860].
    Section 4 of this document describes that assignment process."

The text was also present in RFC 5735.  I unfortunately have to 
object to the disappearance of that text.

RFC 5736 provides direction to IANA concerning the creation and 
management of the IANA IPv4 Special Purpose Address Registry.   The 
information in RFC 5375 is not obsolete.

 From the IANA Considerations Section:

   'IANA will update the aforementioned registries as requested in the
    "IANA Considerations" section of an IESG-reviewed document.  The "
    IANA Considerations" section must include all of the information
    specified in Section 2.1 of this document.'

RFC 5735 mentions that:

   "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."

This draft changes it.

Regards,
-sm