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

From: Bob Hinden <[email-masked]>
Date: Fri, 24 Aug 2001 15:58:07 -0700

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: Pekka Savola <[email-masked]>
Date: Sun, 26 Aug 2001 00:20:38 +0300 (EEST)

> week from today on August 31, 2001.

2.1 Addressing Model reads:

   A
   single interface may also be assigned multiple IPv6 addresses of any
   type (unicast, anycast, and multicast) or scope.

I don't think it's good practise to talk about assigning multicast
addresses to an interface.  This may confuse people, and make people think
of doing stuff like 'ifconfig xl0 inet6 ff0e::1 alias' ie. actually assign
it to as a regular IPv6 address, which might confuse source address
selection a bit and be a little funky to say at least.

Editorial nit: first CIDR reference is in 2.3.

2.5.5 IPv6 Addresses with Embedded IPv4 Addresses:

This discussion, dating back a few years, is based on times when there
were only compatible/mapped addresses which embed IPv4 addresses.  Now
there are more, and more on the way.  I'm not sure whether it's sensible
to include all of them in this draft, but a decision should be made
whether the current ones are really that much needed either or enough,
given others also exist.

Personally I think mapped address, stuff like SIIT aside, should be
fundamentally different than compatible address, and at least mapped addr
should be discussed in this draft.  Compatible is just a transitionary
mechanism that happens to use FP 000.

2.6 Anycast Addresses

Anycast usage scenarios listed in the draft are very router-centric, and I
doubt they have been used at all (or very little).

Therefore, based on IPv6 anycast analysis draft, I think this would be
perfect time to remove/edit(move to recommendation or something) this:

      o An anycast address must not be assigned to an IPv6 host, that
        is, it may be assigned to an IPv6 router only.

Lest we be burdened for this for another 3 years or whatever, if e.g. a
DNS server wants to use anycast addresses.

The source address restriction is trickier business...

2.7 Multicast Addresses

        FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface
        (i.e., the same node) as the sender.

        FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as
        the sender.

Perhaps it would make sense to point out the differences of:
 - interface
 - link
 - node

wrt. scoping (ref to scoping draft?), especially on scenarios where
interface != link. (interface really only includes the loopback, I think).

I think "interface-local" is a bit of a misnomer, but I guess changing it
to "node-local" at this point may be too late.

This has been discussed IIRC before, but it may not exactly obvious if
some first-timer reads the draft.

2.8 A Node's Required Addresses

Editorial:

      o It's required Link-Local Address for each interface.

Its.

Editorial:

[TRAN] reference should probably be updated to point at RFC2893, not
RFC1933.

There's some fluctuation in the casing of some special words, like 'the
unspecified address' and 'loopback address'.  The preferred form should be
decided and the occurrences where they're being used,fixed.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Aug 2001 10:23:09 -0500

>            global unicast and a singe entry that identifies everything

I apologise. I hadn't noticed this change before and I think it is very
confusing. I think the detail you have dropped from the table at the
beginning of 2.4 and replaced by
   Global unicast       (everything else)
was useful. Hiding this detail in pointers and references in the text is
a mistake in terms of document clarity. 

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?

The goal of ensuring that global unicast addresses are treated opaquely except
by the routing system is a good one of course. However, I think this was not the
best way to achieve it, or rather you have gone too far.

(Also, there are options that multi6 might adopt that would change things so
that hosts would look inside global unicast addresses. This would cause us
to re-invent the format prefix PDQ.)

   Brian