[ga] Re: Changes to IPv6 Addressing Architecture Draft

["Jim Fleming" <JimFleming@ameritech.net>]

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" <hinden@iprg.nokia.com>
To: "IPv6 List" <ipng@sunroof.eng.sun.com>
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 majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------

--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html