Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture"

From: Alex Conta <[email-masked]>
Date: Thu, 13 Sep 2001 16:31:19 -0400

Bob,

Apologies for a late set of comments. 

I. Esthetics:  (this was true in earlier incarnations of the document)

There are 3 numbered sections in the document, which is a very
conservative use of 
section numbering. 

Practically there is only one section, section 2, that has more than a
couple of paragraphs of content. 

Each of the next level subsections of section 2, could be independent
sections by themselves. The text representation could be grouped in one
section, plus two subsections.
Etc...

For instance:

(current)
2. IPv6 Addressing			
   2.1 Addressing Model			    
   2.2 Text Representation of Addresses     
   2.3....

(suggested)
2.  Addressing Model
3.  Text Representation
    3.1 Representation of Addresses 
    3.2 Representation of Prefixes
4. Address Type Representation
5. Type of Addresses
   5.1 Unicast Addresses
   5.2 Anycast....
etc....

II. Address space fully allocated.

It seems that the new document specifies an address space which is fully
allocated for IPv6. 
There is no space set aside at this time for experiments, or future use,
while the future carving of the space is left to future specifications.
The model in which space was set aside ahead of time worked well in
IPv4, while the experience of carving out space from space already
allocated for one purpose never worked well before, or it does not
currently.

Therefore I am a strong supporter of having some space set aside now -
two chunks: experimental, and reserved.

III Multicast address local scopes.

The document defines now:

interface-local
subnet-local
admin-local
site-local
organizational-local

Some of the names used are self-explanatory, but others are not, and no
explanations are
given, or references to other documents, which I do not think it is
good.

For instance, I am not sure what what "interface local" means.
"interface-local" means forwarding within the interface? Does not make
too much sense to me. 

 "node local" was dropped, although through its name it made sense as
scope for multicast packets forwarded internally, within a node, but
which never left the node.

Regards,
Alex

, or 

Bob Hinden wrote:
> 
> This is a short IPng working group last call for comments on advancing the
> following document as an Draft Standard:
> 
>         Title           : IP Version 6 Addressing Architecture
>         Author(s)       : B. Hinden, S. Deering
>         Filename        : draft-ietf-ipngwg-addr-arch-v3-06.txt
>         Pages           : 27
>         Date            : 19-Jul-01
> 
> A complete list of changes from RFC-2373 is in Appendix B of the draft and
> is reproduced below.
> 
> Please send substantive comments to the ipng mailing list, and minor
> editorial comments to the authors.  This last call period will end one
> week from today on August 31, 2001.
> 
> We are doing a short w.g. last call because there have been earlier w.g.
> and IETF last calls on this document and wanted to insure that the changes
> in the current draft has been reviewed by the w.g.
> 
> Bob Hinden / Steve Deering
> 
> --------------------------------------------------------------------------
> 
> APPENDIX B: Changes from RFC-2373
> ---------------------------------
> 
>     The following changes were made from RFC-2373 "IP Version 6
>     Addressing Architecture":
> 
>      - Many small changes to clarify and make the text more consistent.
>      - Revised sections 2.4 and 2.5.6 to simplify and clarify how
>        different address types  are identified.  This was done to insure
>        that implementations do not build in any knowledge about global
>        unicast format prefixes.  Changes include:
>          o Removed Format Prefix (FP) terminology
>          o Revised list of address types only includes exceptions to
>            global unicast and a singe entry that identifies everything
>            else as Global Unicast.
>          o Removed list of defined prefix exceptions from section 2.5.6
>            as it is now the main part of section 2.4.
>      - Clarified text relating to EUI-64 identifiers to distinguish
>        between IPv6's "Modified EUI-64 format" identifiers and IEEE
>        EUI-64 identifiers.
>      - Combined the sections on the Global Unicast Addresses and NSAP
>        Addresses into a single section on Global Unicast Addresses,
>        generalized the Global Unicast format, and cited [AGGR] and [NSAP]
>        as examples.
>      - Reordered sections 2.5.4 and 2.5.5.
>      - Removed section 2.7.2 Assignment of New IPv6 Multicast Addresses
>        because this is being redefined elsewhere.
>      - Added an IANA considerations section that updates the IANA IPv6
>        address allocations and documents the NSAP and AGGR allocations.
>      - Added clarification that the "IPv4-compatible IPv6 address" must
>        use global IPv4 unicast addresses.
>      - Divided references in to normative and non-normative sections.
>      - Added reference to [PRIV] in section 2.5.1
>      - Revised section 2.4 Address Type Representation to
>      - Added clarification that routers must not forward multicast
>        packets outside of the scope indicated in the multicast address.
>      - Added clarification that routers must not forward packets with
>        source address of the unspecified address.
>      - Added clarification that routers must drop packets received on an
>        interface with destination address of loopback.
>      - Clarified the definition of IPv4-mapped addresses.
>      - Removed the ABNF Description of Text Representations Appendix.
>      - Removed the address block reserved for IPX addresses.
>      - Multicast scope changes:
>          o Changed name of scope value 1 from "node-local" to "interface-
>            local"
>          o Defined scope value 3 for "subnet-local" for multi-link
>            subnets
>          o Defined scope value 4 as "admin-local"
>      - Corrected reference to RFC1933 and updated references.
> 
> ------------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> 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: "Christian Huitema" <[email-masked]>
Date: Fri, 14 Sep 2001 17:50:22 -0700

> >>   Unassigned:
> >>
> >>   6/8 + 57/512 (2.5521177519070384759753095557382e+38
> >> +
> 3.788299787987010237775850121799e+37
> >> of addresses)
> >>                This is the remaining of the address space, which
> has not
> >> been assigned.
> 
> 	for implementers, it needs to be known that the unassigned
> region is
> 	unicast addresses, not just "unassigned".
> 	otherwise, implemnters cannot implement the code to handle these
> 	"future allocation" addresses.  in my understanding this is the
> 	main reason for the wording change between RFC and i-d.

Second that. We have to be able to decide thinks like "address scope"
and "address type", in order to implement requirements such as
"addresses used in this context must be global scope unicast addresses."
If we want compatibility with future assignments, that should not be
done by testing for 200::/3...

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 7 Sep 2001 12:35:40 -0700

Brian,

Yes, we have in some cases to test whether the address is "global in
scope" or not; such tests are mandated for example in the behavior of
Shipworm routers. This points us to section 2.4 of the addressing spec,
which reads:

   The type of an IPv6 address is identified by the high-order bits of
   the address, as follows:

      Address type         Binary prefix        IPv6 notation   Section
      ------------         -------------        -------------   -------
      Unspecified          00...0  (128 bits)   ::/128          2.5.2
      Loopback             00...1  (128 bits)   ::1/128         2.5.3
      Multicast            11111111             FF00::/8        2.7
      Link-local unicast   1111111010           FE80::/10       2.5.6
      Site-local unicast   1111111011           FEC0::/10       2.5.6
      Global unicast       (everything else)

So, when I implement the test, I am going to check whether the address
matches ::/127, FF00::/8, or FF80/9, and if yes recognize a non local
scope. What I should specifically not do is check whether the address
matches 2000::/3, and if not recognize a non local scope! In short,
looking for an inexistent format prefix would drive a programming error.

-- Christian Huitema

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 11:49 AM
> To: Erik Nordmark
> Cc: Bob Hinden; [email-masked]
> Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture"
> 
> Well, I miswrote slightly - the fact is that an implementation has to
> first check if the address is any of the non-global-unicast cases, and
> that
> involves doing a sequence of matches which involve the bits
> Formerly Known as the Format Prefix (not just 3 of them of course).
> I think the new text makes this harder to understand. It doesn't
> change
> what implementors should do.
> 
> Feel free to ignore my comment if nobody else has the same reaction.
> 
>    Brian
> 
> Erik Nordmark wrote:
> >
> > > I also think that abolishing the term "format prefix" is
> obfuscation. The
> > > fact is that the leading bits of an address *are* a format prefix
> and
> > > implementors *will* look at those bits before processing an
> address. Why
> > > obscure that fact?
> >
> > Brian,
> > It is exactly this that we want to avoid - implementors thinking
> that they
> > need to inspect the first 3 bits of the addresses.
> > There is no need to do this and we need to reduce the probability
> that
> > implementors hard-code any knowledge of any leading 3 bit
> combinations
> > since it will make it harder to use the other 15/16th of the address
> space
> > in the future.
> >
> >   Erik