Bob Hinden wrote: > 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.
What wasn't asked at Yokohama was how many people had operational clue about the consequences of these decisions. > > 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. 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. > > 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. | > To be clear, I agree with the Site-local change. Tony > > 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 PROTECTED] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 PROTECTED] --------------------------------------------------------------------
