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
----- Original Message ----- From: "Bob Hinden" <[EMAIL PROTECTED]> To: "IPv6 List" <[EMAIL PROTECTED]> Sent: Friday, August 09, 2002 5:27 PM Subject: Changes to IPv6 Addressing Architecture Draft > > 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] > -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
