Subject: Changes to IPv6 Addressing Architecture Draft

From: Bob Hinden <[email-masked]>
Date: Fri, 09 Aug 2002 15:27:15 -0700

At the IPv6 working group sessions at the Yokohama IETF two changes to the 
IP Version 6 Addressing Architecture draft

   <draft-ietf-ipngwg-addr-arch-v3-08.txt>

were discussed.  These changes were proposed based on feedback received 
from our area director and email discussion on the mailing list.  A summary 
of the AD comments is include at the end of the email.

The changes that were proposed at the meeting were to relax the interface 
identifier uniqueness requirements (from the link to subnet prefix) and to 
change the definition of Site-Local addresses to make the subnet field 
54-bits (and eliminate the 38-bit zero field).

After discussing the proposed changes, a consensus was reached at the 
Yokohama meeting to make them.  The purpose of this email is to validate 
that consensus on the mailing list and to review the specific changes to 
the internet draft.

The proposed changes (changed lines marked by "|") to the ID are as follows:

Change to second sentence in the first paragraph of section 2.5.1:

  Interface identifiers in IPv6 unicast addresses are used to identify
  interfaces on a link.  They are required to be unique within a subnet  |
  prefix.  They may also be unique over a broader scope.  In some cases  |
  an interface's identifier will be derived directly from that
  interface's link-layer address.  The same interface identifier may be
  used on multiple interfaces on a single node, as long as they are
  attached to different links.

and from section 2.5.6 where site-local is defined:

  Site-Local addresses have the following format:

  |   10     |
  |  bits    |         54 bits         |         64 bits            |
  +----------+-------------------------+----------------------------+
  |1111111011|        subnet ID        |       interface ID         |    |
  +----------+-------------------------+----------------------------+

  Site-local addresses are designed to be used for addressing inside of
  a site without the need for a global prefix.  Although a subnet ID may |
  be up to 54-bits long, it is expected that most globally-connected     |
  sites will use the same subnet IDs for site-local and global prefixes. |

If there is agreement with these changes I will submit a new draft (-09) 
that the area directors can proceed with.

Bob

-------------------------------------------------------------------

Comments from Thomas Narten:

>1) The -07 ID contains the wording:
>
> >    Interface identifiers in IPv6 unicast addresses are used to identify
> >    interfaces on a link.  They are required to be unique on that link.
>
>Given the on-going issues surrounding DAD vs DIID, I felt it
>appropriate to check with the WG whether this wording was indeed what
>the WG believed the architecture should require.
>
>2) The -07 ID contains the wording:
>
> >    Site-Local addresses have the following format:
> >
> >    |   10     |
> >    |  bits    |   38 bits   |  16 bits  |         64 bits            |
> >    +----------+-------------+-----------+----------------------------+
> >    |1111111011|    0        | subnet ID |       interface ID         |
> >    +----------+-------------+-----------+----------------------------+
>
>Given that the fixed 16-bit subnet ID in global addresses was changed
>to one having a flexible boundary, the subnet ID in site-locals should
>also not have a fixed boundary.  Note that other parts of the document
>showing addresses were updated to use generic "m" bits, rather than
>fixing the field at 16 bits, under the concern that implementations
>*might* somehow hardcode the boundary in their implementations.
>
>Also, it might be good to clarify that the middle bits are undefined
>and should be 0. I.e., implementors could interpret the above words as
>saying the bits are defined to always be zero (as opposed to just
>reserved for future use and MUST be zero), which could lead
>implementations to somehow check that those bits are 0, and if not, do
>something incorrect (like signal an error).
>
>The specific text that was proposed and discussed at the Yokohama
>meeting addresses the main concern I had.
>
>At the meeting, there were still some folks that seemed unhappy with
>the proposed change. I'd be interested in understand why. Only itojun
>spoke up on this point, and he stated this would make site-local
>addresses more attractive, which he didn't consider a feature. :-)
>
>Thomas

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 9 Aug 2002 17:34:20 -0500

Has the ICANN Board and staff approved this ?

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

---

From: Robert Elz <[email-masked]>
Date: Sun, 11 Aug 2002 15:37:54 +0700

Date:        Fri, 09 Aug 2002 15:27:15 -0700
    From:        Bob Hinden <[email-masked]>
    Message-ID:  <[email-masked]>

  | If there is agreement with these changes I will submit a new draft (-09) 
  | that the area directors can proceed with.

Bob, I have no problems with either proposed change, I support both of them.

By all means, submit a new draft if you like - but please don't send it
back to the ADs until the other issue surrounding it has been dealt with.

Since this doc is going to DS (we hope) it requires an implementation
report.   There is one of those already - can be found on the IETF web site,
but for anyone who wants a direct URL, it is:
	http://www.ietf.org/IESG/Implementations/address-architecture.txt

That's great.   It doesn't mention either of the new features, but I
would assume they can easily be added (since everyone does DAD, rather
than DIID anyway, reporting it as implemented will be easy, and I doubt
it will take much effort for a couple of implementation at least to test
longer SLAs in SL addresses).

Those need to be fixed, but should be easy.

But the implementation report also lacks any mention of testing, using,
or implementing the 'u' bit means "address has a globally unique IID"
feature, nor the "all unicast prefixes other than 0::/3 must be /64"
feature.

If there are no implementations of those, then the IESG is just going
to tell the WG to delete them before the doc does to DS, isn't it?

Why don't we just do that now?   You could include those changes in the
next draft that you submit.

kre

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 12 Aug 2002 09:57:14 -0400

We can only perform interoperability testing for external behaviours of
boxes that are visible on the wire.  This does make it fairly tricky to 
write an implementation checklist for something like an addressing 
architecture, and I think that Bob has done an outstanding job of figuring
out which features do/don't have interoperability concerns.

>longer SLAs in SL addresses).

The subnet ID changes don't affect the external behaviour of an IPv6
implementation.  We were always required to perform all routing and
comparisons in a CIDR-like fashion, and that hasn't changed.  I agree
that vendors may want to check that their configuration mechanisms don't
have a problem setting subnet IDs of longer than 16-bits, but that isn't
an interoperability testing issue.

DAD is actually specified in the IPv6 Address Autoconfiguration spec, not
in the addressing architecture, so interoperability testing of DAD isn't
necessary to advance the addressing architecture.  

>feature, nor the "all unicast prefixes other than 0::/3 must be /64"

The Addressing Architecture doesn't specify any behaviour related to the 
global uniqueness of addresses with the 'u' bit set.  It does have an
appendix that explains how nodes that use EUI-64 identifiers or ethernet 
addresses should set the 'u' bit when building IIDs for autoconfiguration.
I don't know whether it is necessary to provide interoperability reports
on items included in appendices, but we obviously wouldn't have any
trouble finding two or more implementations that set this bit correctly.

>to tell the WG to delete them before the doc does to DS, isn't it?

I don't think that there is any interoperability-related feature in the 
current addressing architecture document (including the proposed changes) 
that isn't implemented in two or more implementations.

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 12 Aug 2002 16:08:39 -0700

> that consensus on the mailing list and to review the specific 

What wasn't asked at Yokohama was how many people had operational clue
about the consequences of these decisions.

>   attached to different links.

While it might sound theoretically nice to be able to reuse an IID on
multiple nodes on a single subnet, the operational reality is that it
will be confusing and never used in practice. It will be difficult
enough to get first line operators to understand the concept of multiple
addresses per node and multiple prefixes per subnet. If we allow the
possibility that an IID might point to different nodes on some wires,
but the same node on other wires, we will have exceeded any reasonable
ability to train the operations staff. This is a bad idea that doesn't
provide any compelling value to begin with, so why change it? The only
reason I have heard is that changing it will make it clear that DIID is
insufficient. Solving that problem is better done by stating that DAD is
required, and leave this text as it was.

>   |  bits    |         54 bits         |         64 bits            |

To be clear, I agree with the Site-local change.

Tony

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 12 Aug 2002 19:57:43 -0400

>will be confusing and never used in practice. 

IID uniqueness on a link is an artificial restriction:  We don't check
for it with DAD, and not other part of the IPv6 architecture depends
on it.  Leaving it in will complicate privacy addresses and some other
situations, and taking it out does not actually require operators to
number their networks in a confusing fashion.

In practice, permanant addresses probably won't have overlapping IIDs.
Autoconfigured addresses will never have overlapping IIDs because there
will always be a corresponding link-local address that is check for
uniqueness with DAD.  And, I expect you are correct that operators will
not manually configure multiple nodes on a link to use the same IID.

However, there are two cases where overlapping IIDs may occur:

         - Randomly-generated IIDs used for privacy addresses.
                 To prevent the possibility of overlapping IIDs in
                 this case, we'd have to generate a link-local 
                 address and perform DAD on it (or some equivalent), 
                 in addition to performing DAD on the privacy address.

         - Two separate subnets that are merged onto a single 
                 physical network (due to topology changes, etc.).
                 If these were manually configured networks, its
                 likely that both sets of IIDs will include the 
                 same low numbers.  However, the original global
                 and site-local addresses could still be distinguished
                 by their different subnet IDs, so why require the
                 IIDs to change?

I don't see any reason why we should keep an artificial restriction
in the addressing architecture that would complicate either of these
cases.

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 12 Aug 2002 17:59:25 -0700

Margaret Wasserman wrote:
> IID uniqueness on a link is an artificial restriction:  We 
> don't check for it with DAD, and not other part of the IPv6 
> architecture depends on it.  Leaving it in will complicate 
> privacy addresses and some other situations, and taking it 
> out does not actually require operators to number their 
> networks in a confusing fashion.
> 
> In practice, permanant addresses probably won't have 
> overlapping IIDs. Autoconfigured addresses will never have 
> overlapping IIDs because there will always be a corresponding 
> link-local address that is check for uniqueness with DAD.  
> And, I expect you are correct that operators will not 
> manually configure multiple nodes on a link to use the same IID.
> 

And the problem with running an additional DAD is??? LL with privacy
IIDs make no sense, so why wouldn't the node just configure all the
available prefixes and defend them directly? Even without the LL-DAD,
the only case where a collision would not be detected is when a subnet
has multiple prefixes, but nodes are not configured to use all of them.
In real networks, the likelyhood that some nodes on a wire would use one
prefix while others use a different one is so close to 0 that it
shouldn't be special cased. 

>                  by their different subnet IDs, so why require the

Because it will happen anyway to avoid the operator confusion of
multiple nodes with the same IID. I can appreciate the desire to
perpetuate legacy procedures and allow the concept of 2 logical subnets
on the same wire, but with the IPv6 concept of multiple prefixes per
subnet, that becomes a real mess. Since these are theory, what happens
in the merge example if both sites were using autoconf based on
configured macs of 1,2,3...? In the real world when 2 subnets are
merged, one or both of them require reunmbering, so why should we change
the address architecture to allow a case that might someday make
creating a confusing mess easy? 

> 
> I don't see any reason why we should keep an artificial 
> restriction in the addressing architecture that would 
> complicate either of these cases.

Because they are theoretical scenarios, not something that a network
operator would expect to have work.

---

From: Robert Elz <[email-masked]>
Date: Tue, 13 Aug 2002 19:17:18 +0700

Date:        Mon, 12 Aug 2002 09:57:14 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | We can only perform interoperability testing for external behaviours of
  | boxes that are visible on the wire.

True, but interoperability testing isn't required.

Let me quote 2026, section 4.1.2 (part thereof) just in case anyone
here isn't clear on the requirements ...

   [...] "interoperable" means to be functionally
   equivalent or interchangeable components of the system or process in
   which they are used.

   The requirement for at least two independent and interoperable
   implementations applies to all of the options and features of the
   specification.  In cases in which one or more options or features
   have not been demonstrated in at least two interoperable
   implementations, the specification may advance to the Draft Standard 
   level only if those options or features are removed.

   The Working Group chair is responsible for documenting the specific
   implementations which qualify the specification for Draft or Internet
   Standard status along with documentation about testing of the
   interoperation of these implementations.  The documentation must
   include information about the support of each of the individual
   options and features.

Note: nothing requires that there be any interoperability testing, and
while it is great that there has been some (lots) of v6 implementations,
other protocols advance with none.

What is required is that every feature be implemented in a way that is
interoperable (twice, independently).

Every feature, or it must be removed.

There's nothing unclear about this, nor is it without good reason.  This
is how we get rid of the odd attachments that people just thought would be
a good idea when the doc was proposed, but then no-one (except possibly the
one who suggested it) ever bothered to implement.   It is how all the
chaff is removed.

  | This does make it fairly tricky to 
  | write an implementation checklist for something like an addressing 
  | architecture, and I think that Bob has done an outstanding job of figuring
  | out which features do/don't have interoperability concerns.

Yes, some things are harder than others.  And I agree, what's there now
is pretty good - it documents all that is important (except the new stuff,
which it couldn't possibly have done) which needs to be in the doc.

That's great.    What follows from that is that the parts that aren't
documented as having been implemented, get removed from the doc, just
as the process I quoted above requires.

What happens to those bits afterwards is for the WG to decide.

I'm not sure why we're even discussing this next part, but ...

  | The subnet ID changes don't affect the external behaviour of an IPv6
  | implementation.

Yes it does.   If one implementation refused to accept a prefix with
fec0::/10 which is not also fec0::/48 (which I believe was once actually
implemented somewhere, I recall someone mentioning it) then it will not
interoperate with anything which attempts to use the new larger SLA.

  | We were always required to perform all routing and
  | comparisons in a CIDR-like fashion, and that hasn't changed.

Sure, but this has nothing to do with that.

  | I agree
  | that vendors may want to check that their configuration mechanisms don't
  | have a problem setting subnet IDs of longer than 16-bits, but that isn't
  | an interoperability testing issue.

It is an implementation report issue as regards with getting this accepted
as a DS (even if it gets included, it could be decided that this is a big
enough change to require the doc to recycle at PS anyway.  I don't think it
quite goes that far, but that isn't out of the question).

But what is the issue here - all we need is for two different implementations
to say "We allow 54 bit SLAs for SL addresses", that goes in the implementation
reports for those two implementations, and we're done ?

Why would anyone want to even tempt fate just to avoid doing that?

  | DAD is actually specified in the IPv6 Address Autoconfiguration spec, not
  | in the addressing architecture, so interoperability testing of DAD isn't
  | necessary to advance the addressing architecture.  

No.   But the specification of IID uniqueness is.   That's why there is
text in this draft being changed after all.

Again, all it takes is for (at least) two implementations to say "we allow
this in our code" (and I'd be surprised if there were any who don't already)
and for an entry to be added to the report.   This is easy, why not just
do it to be complete?

  | The Addressing Architecture doesn't specify any behaviour related to the 
  | global uniqueness of addresses with the 'u' bit set.

No, it just says that should be set on addresses formed from IIDs
with global scope.   And not otherwise.

The question is where are the two implementations that actually do that?
And before anyone claims "mine does" first answer the question how you
determine that the IID does really have global scope?

  | I don't think that there is any interoperability-related feature in the 
  | current addressing architecture document (including the proposed changes) 
  | that isn't implemented in two or more implementations.

The changes should be fine - they just need to be actually documented
(that is, we aren't allowed to just say "we know it is all OK", we are,
or more correctly, you (with Bob & Steve) as chair are, required to
actually document all of this).

But for the rest of the doc, how about (sect 2.5.4)...

   All global unicast addresses other than those that start with binary
   000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
   described in section 2.5.1.

Where are the two implementations that implement/enforce that feature?
This is quite clearly an feature of the specification.  If not, why is
it there?   Thus, according to 2026, we (you) are required to document
the implementations of it.

If there are none, 2026 requires that it be removed for the doc to go
to DS.

kre