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 PROTECTED] --------------------------------------------------------------------
