Subject: I-D ACTION:draft-ietf-ipv6-addr-arch-v4-01.txt

From: [email-masked]
Date: Fri, 18 Feb 2005 15:25:50 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.

	Title		: IP Version 6 Addressing Architecture
	Author(s)	: R. Hinden, S. Deering
	Filename	: draft-ietf-ipv6-addr-arch-v4-01.txt
	Pages		: 25
	Date		: 2005-2-18
	
This specification defines the addressing architecture of the IP
   Version 6 protocol [IPV6].  The document includes the IPv6 addressing
   model, text representations of IPv6 addresses, definition of IPv6
   unicast addresses, anycast addresses, and multicast addresses, and an
   IPv6 node's required addresses.

   This document obsoletes RFC-3513 "IP Version 6 Addressing
   Architecture".

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipv6-addr-arch-v4-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipv6-addr-arch-v4-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Tue, 22 Feb 2005 14:34:10 -0800

A diff from the previous (-00) draft can be found at:

  http://people.nokia.net/~hinden/draft-ietf-ipv6-addr-arch-v4-01.html

and a diff between the current (-01) draft and RFC3515x can be found at:

  http://people.nokia.net/~hinden/diff-rfc-draft.html

The latter was made be removing most of the boiler plate from each document 
before running the diff.

The summary changes in this draft are (from APPENDIX B):

    The following changes were made from RFC-3513 "IP Version 6
    Addressing Architecture":

     o Deprecated the Site-Local prefix.  Changes included
        - Removed Site-Local from special list of prefixes in Section
          2.4.
        - Split section titled "Local-use IPv6 Unicast Addresses" into
          two sections, "Link-Local IPv6 Unicast Addresses" and "Site-
          Local IPv6 Unicast Addresses".
        - Added text to new section describing Site-Local deprecation.

     o Changes to resolve issues raised in IAB response to Robert Elz
       appeal.  Changes include:
        - Added clarification to Section 2.5 that nodes should make no
          assumptions about the structure of an IPv6 address.
        - Changed the text in Section 2.5.1 and Appendix A to refer to
          the modified EUI-64 format interface identifiers with the "u"
          bit set to one (1) as universal.
        - Added clarification to Section 2.5.1 that IPv6 nodes are not
          required to validate that interface identifiers created in
          modified EUI-64 format with the "u" bit set to one are unique.

     o Changed the reference indicated in Section 2.5.4 "Global Unicast
       Addresses" to RFC3587.

     o Removed mention of NSAP addresses in examples.

     o Clarified that the "x" in the textual representation can be one to
       four digits.

     o Editorial changes.

The editorial changes include updating the example addresses to not use 
site-local in one example and to use the documentation prefix where 
appropriate.

Please review.  I belive I got all of the important items from the mailing 
list discussions.  Let me know if I missed something.

Thanks,
Bob

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Feb 2005 09:58:49 +0200 (EET)

> 	Filename	: draft-ietf-ipv6-addr-arch-v4-01.txt

Two high-level comments:

1) The use of compatible addresses does not belong to the revised addr 
arch specification, especially if we want to move it to Draft 
Standard.  I suggest removing it right now to avoid fuss in the 
future.

2.5.5 IPv6 Addresses with Embedded IPv4 Addresses

    The IPv6 transition mechanisms [TRAN] include a technique for hosts
    and routers to dynamically tunnel IPv6 packets over IPv4 routing
    infrastructure.  IPv6 nodes that use this technique are assigned
    special IPv6 unicast addresses that carry a global IPv4 address in
    the low-order 32 bits.  This type of address is termed an
    "IPv4-compatible IPv6 address" and has the format:

    |                80 bits               | 16 |      32 bits        |
    +--------------------------------------+--------------------------+
    |0000..............................0000|0000|    IPv4 address     |
    +--------------------------------------+----+---------------------+

    Note: The IPv4 address used in the "IPv4-compatible IPv6 address"
    must be a globally-unique IPv4 unicast address.

2) Site local deprecation document is Proposed Standard (it should 
have been published as BCP, sigh..), so it cannot be a normative 
reference if we want to move this to Draft Standard (unless SLDEP is 
also moved to DS).  Luckily enough, I think this only provides 
additional information, so it should be OK to move it over to 
Informative references.

5.1 Normative References

    [SLDEP]   C. Huitema, B. Carpenter, "Deprecating Site Local
              Addresses", RFC3879, September 2004.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings