FW: status of IPng addressing documents

To All:

FYI

Ray

-----Original Message-----
From: owner-multi6 at ops.ietf.org [mailto:owner-multi6 at ops.ietf.org]On
Behalf Of Thomas Narten
Sent: Wednesday, March 21, 2001 9:40 AM
To: multi6 at ops.ietf.org
Subject: FWD: status of IPng addressing documents


This may be of interest to those not on the ipng list.

Thomas

------- Forwarded Message

From: Thomas Narten <narten at hygro.adsl.duke.edu>
To: ipng at sunroof.eng.sun.com
Date: Sun, 18 Mar 2001 21:54:08 -0500
Subject: status of IPng addressing documents

This note is to summarize some recent discussions concerning a number
of IPv6 documents and bring the WG up-to-date on a suggested plan of
action.

First, the IESG is currently discussing whether to advance
draft-ietf-ipngwg-addr-arch-v3-04.txt (the original ID submitted to
the IESG) to draft standard. IESG discussions have resulted in
requests for two changes to the document:

a) Section 2.5.6 "Aggregatable Global Unicast Addresses" contains text
   and a diagram excerpted from a separate document, RFC 2374. That
   text is deemed inappropriate in a Draft Standard document because:

   - the described fields and their widths are not a fundamental part
     of the IPv6 architecture. Implementations do not (and should not)
     need to know the format of any of the fields, their widths, etc.
   - Putting them in the document can lead people to believe they are
     fundamental part of the architecture
   - The topic of RFC 2374 deals with that portion of address space that
     is managed by the RIRs, rather than the IETF (more on this
     below). 

IESG request: rework the discussion in Section 2.5.6 to make the
reference to RFC 2374 an example, to make it clear that the address
allocations and formats in RFC 2374 are not a part of the IPv6
architecture (i.e., have no implications for implementations).

b) The document makes reference to the format prefix (FP). There have
   been concerns raised that implementations may take the FP into
   consideration and treat addresses differently depending on their FP
   (i.e., FP 1 is assigned, while others are unassigned). But for
   future flexibility, it is important that all implementations
   process global unicast addresses consistently and predictably,
   regardless of what the FP is.

IESG request: strengthen/clarify wording in the document to make it
clear that all unassigned FPs are to be treated as global unicast
addresses. 

These requests are editorial in nature and are not expected to affect
the document in a way that impacts implementations. Once these changes
are made, the document is expected to be approved as a Draft Standard.

Note that version -05 appeared recently; it addresses most of the
issues raised. A -06 version, under preparation, is expected to
resolve the remaining issues.

While discussing the addressing architecture document, the IESG also
discussed RFC 2374. The WG originally asked that this document also be
advanced to Draft Standard a couple of years ago, but the IESG pushed
back wanting to see more experience. While the IPng WG has not
formally asked the IESG to advance this document at this time, there
is an assumption that such a request might come once the addressing
architecture document had been successfully advanced. Hence, the
preliminary discussion on RFC 2374.

The IESG has in previous discussion not had consensus on advancing RFC
RFC 2374 ("An IPv6 Aggregatable Global Unicast Address Format"). Over time
the specific issues have evolved, as the community has gained more
experience from IPv6 testbeds, the RIRs have begun handing out
addresses, etc. Some of the current issues that have been raised
include:

   - there is a lack of clear consensus in the community regarding the
     exact size of the various fields (TLA vs. NLA, etc.), how
     permanent the boundaries will be over time, etc. Boundaries that
     seem appropriate today, may be different in ten or twenty
     years. As an example, while the limitation of 8192 TLAs is viewed
     as a laudable goal, it is also not viewed as a hard architectural
     limit that can/will never change. If the boundaries are subject
     to change in the future, that argues against the document being
     advanced on the Standards Track to Draft status.
     
   - there is concern that it does not reflect the current practice of
     what the addressing registries (RIRs) are doing or will be doing
     over the next few years (again an argument against advancement to
     Draft Standard). For example, sub-TLAs are not defined in
     RFC 2374.

   - on matters of address allocations and assignments, the RIRs (and
     not the IETF) have responsibility for managing and assigning
     unicast address space to ISPs and end sites. Note that on issues
     of address boundaries, the further one moves from the right to
     the left within an address, the greater the role of the RIRs, and
     lesser the impact on the overall IPv6 architecture. For example,
     the IPv6 architecture clearly defines the /64 boundary.  But the
     /48 boundary is less clearly required by the architecture, though
     there are many technical reasons for having it.

     While the IETF can (and should) provide technical input to the
     RIRs on how to manage the IPv6 address space, it is the RIRs that
     ultimately adopt and execute allocation policies.  Consequently,
     the topic of RFC 2374 (specifically, the assignment and usage of
     the "routing part" of IPv6 addresses) is not really an
     appropriate Standards Track activity of the IETF. A more
     appropriate role for the IETF would be to provide input/advice to
     the registries, that focuses on technical aspects, especially
     those related to the overall IPv6 architecture. This could be
     done through an informational RFC, or possibly through some other
     means.
     
   - Because the RIRs are are the ones that carry out any
     recommendations the IETF might make, they need to be in agreement
     with those policies and incorporate them into their own formal
     policies. This argues for engaging the RIRs on the topic of
     address assignments and encouraging them to develop such policies
     in a cooperative manner with appropriate input from the IETF.

Summary: the IESG is unlikely to advance RFC 2374 on the standards
track in its current form, and recommends that the RIRs be approached
for their views on this topic and on what recommendations they have
for how best to cooperate on reaching a common goal -- that of
assigning addresses in a way that encourages deployment and supports
the IPv6 vision and architecture. Should the RIRs be willing to
formally take up this topic, it is expected (and imperative!) that the
IETF provide technical input.

Note that moving the policy component to the RIRs is not expected to
result in any change in current assignments and operations in the
short term, but one can expect assignment policy to evolve over
time. Any such changes would be the subject of extensive review by the
IETF and RIR communities.  The exact details of how to do this need to
be worked out through discussions between the IETF and RIRs.

A third document, draft-iesg-ipv6-addressing-recommendations-00.txt
recently appeared. This document is a revised version of a statement
issued by the IESG/IAB in September, 2000. The focus of the document
is to provide a strong case that that the default IPv6 address
allocation to end sites should be a /48.  The reason for publishing
the document is to refine and clarify the statement and eventually
publish it as an informational RFC (i.e., for the historical
record). The purpose of this statement is to provide input to the
RIRs, as they formulate their IPv6 address assignment policies.

Thomas

------- End of Forwarded Message