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

From: Bob Hinden <[email-masked]>
Date: Mon, 27 Mar 2000 17:04:37 -0800

This is a IPng working group last call for comments on advancing the
following document as a Draft Standard:

	Title		: IP Version 6 Addressing Architecture
	Author(s)	: R. Hinden, S. Deering
	Filename	: draft-ietf-ipngwg-addr-arch-v3-00.txt
	Pages		: 25
	Date		: 15-Mar-00

Please send substantive comments to the ipng mailing list, and minor
editorial comments to the authors.  This last call period will end two
week from today on April 10, 2000.

Bob Hinden / Steve Deering

--------------------------------------------------------------------
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: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 28 Mar 2000 10:25:17 +0900

>week from today on April 10, 2000.

	Based on analysis outlined in the following URL,
	I would suggest adding the following into the document.
http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-00a.txt

	I'm tempted to add more lines like "SHOULD drop invalid packets",
	however, the document may not be the best place to discuss node
	behavior...

itojun

---
*** draft-ietf-ipngwg-addr-arch-v3-00.txt-	Tue Mar 28 10:14:35 2000
--- draft-ietf-ipngwg-addr-arch-v3-00.txt	Tue Mar 28 10:23:05 2000
***************
*** 573,578 ****
--- 573,586 ----
     |0000..............................0000|0000|    IPv4 address     |
     +--------------------------------------+----+---------------------+
  
+    The IPv4 address embedded into an IPv4-compatible IPv6 address MUST be
+    an IPv4 unicast address.  For example, the following lists some of
+    non-conforming IPv4 address prefixes [IANA]:
+    - IANA reserved, usually used for unspecified address (0.0.0.0/8)
+    - IANA reserved, usually used for loopbacks (127.0.0.0/8)
+    - IPv4 multicast (224.0.0.0/4)
+    - IANA reserved, usually used for subnet broadcast (255.0.0.0/8)
+    - subnet broadcast addresses
  
     A second type of IPv6 address which holds an embedded IPv4 address is
     also defined.  This address is used to represent the addresses of
***************
*** 586,591 ****
--- 594,600 ----
     |0000..............................0000|FFFF|    IPv4 address     |
     +--------------------------------------+----+---------------------+
  
+    The form of address does not usually appear on the wire. [RFC2553]

  2.5.5 NSAP Addresses
***************
*** 1315,1320 ****
--- 1324,1332 ----
     [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
               Networks", RFC2467, December 1998.
  
+    [IANA]    "Internet protocol address space",
+ 	     http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space
+ 
     [IPV6]    Deering, S., R. Hinden, "Internet Protocol, Version 6
               (IPv6) Specification", RFC2460, December 1998.
  
***************
*** 1329,1334 ****
--- 1341,1349 ----
  
     [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", RFC2119, BCP14, March 1997.
+ 
+    [RFC2553] R. Gilligan, S.  Thomson, J. Bound, W. Stevens,
+ 	     "Basic Socket Interface Extensions for IPv6", RFC2553, March 1999.
  
     [TOKEN]   Crawford, M., T. Narten, S. Thomas, "Transmission of IPv6
               Packets over Token Ring Networks", RFC2470, December 1998.
--------------------------------------------------------------------
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: Erik Nordmark <[email-masked]>
Date: Mon, 27 Mar 2000 22:47:47 -0800 (PST)

Re: IPv4-mapped address.

> +    The form of address does not usually appear on the wire. [RFC2553]

RFC 2765 (SIIT) does state that these addresses may appear on the wire.
Thus I don't see how adding the above sentence brings more clarity to
the specification.

In addition, it would make sense to specify the IPv4-translatable
addresses (in SIIT) in the addressing architecture in section 2.5.4
(those addresses are ::ffff:0:a.b.c.d where a.b.c.d is an IPv4 address.
Note 16 bits of zero between ffff and the IPv4 address)

   Erik

---

From: Jim Bound <[email-masked]>
Date: Tue, 28 Mar 2000 10:20:01 -0500

Erik,

I agree with you on mapped addresses.  But last I checked 2373 says they
can't be on the wire?  But I will recheck.

/jim

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 29 Mar 2000 00:30:03 +0900

>Thus I don't see how adding the above sentence brings more clarity to

	(after talking with eric) I see, I drop the suggestion to add
	notice about IPv4 mapped address in addr-arch-v3-00.

	Though separate topic but worth mentioning: SIIT requires IPv6 routers
	to forward IPv6 native packets with IPv4 mapped address as is.
	Therefore, I will need to rephrase abuse draft to something like:
	"Check IPv6 packets in following occasions, and drop the packet if you
	see IPv4 mapped address on the packet:
	- last stage of IPv6 input logic, when IPv6 packet is accepted by
	  the node itself (after forwarding decision)
	     Note: for SIIT to work, IPv6 routers needs to forwards packets
	     with IPv4 mapped source/destination
	- transport layer input, like TCP/UDP."

itojun

---

From: Dave Thaler <[email-masked]>
Date: Thu, 30 Mar 2000 19:34:44 -0800 (PST)

Here's my review of the multicast section of the draft.
(My proposed fixes are in draft-haberman-ipngwg-mcast-arch-01.txt,
but I will try to repeat everything relevant here.)

Section 2.7:
   The list of multicast scopes is arguably out of date...

   RFC 2365 defines the "Local Scope" as (to paraphrase)
   the smallest enclosing scope larger than link-local,
   and therefore associates it with scop 3.  This scope
   is used by MZAP, and is also a requirement by the zeroconf wg,
   etc.

   Also, draft-ietf-malloc-arch-04.txt (The Internet Multicast 
   Address Allocation Architecture) has already been submitted 
   to the IESG for consideration as Informational.  It proposes
   an "Allocation Scope" (which could conceivably apply to other
   purposes as well, but couldn't think of any more general name)
   which would be scop 6.  (The argument being that most of the
   time it's identical to site, but could need to be larger in some
   scenarios.)

Section 2.7.1:
Regarding FF0x::0 table... is a table really necessary here?
It makes you want to look more closely just to see if all 16 are there.
Proposed text:
> The following well-known multicast addresses are pre-defined:
> 
>    Reserved Multicast Addresses:     FF0x:0:0:0:0:0:0:0
and possibly adding something like:
> where "x" indicates all scop values.

Section 2.7 states:
> The "meaning" of a permanently assigned multicast address is
> independent of the scope value.

Section 2.7.1's definitions of All-nodes, All-Routers, and Solicited-node
addresses appear to contradict the above statement because they
specifically _don't_ seem to apply to all scopes.
Some language to clarify this seems warranted.

Proposed text (and perhaps SHOULD NOT should be MUST NOT below?)
>    All Nodes Addresses:      FF0x:0:0:0:0:0:0:1
>
> The above multicast addresses identify the group of all IPv6 nodes
> within a given scope.  The All-Nodes-Address for scopes larger than
> scope 2 (link-local) SHOULD NOT be used or joined by nodes.
>
>    All Routers Addresses:    FF0x:0:0:0:0:0:0:2
>
> The above multicast addresses identify the group of all IPv6 routers
> within a given scope.  The All-Routers-Address for scopes other than
> scope 1 (node-local), 2 (link-local), and 5 (site-local) SHOULD NOT be
> used or joined by routers.
>
>    Solicited-Node Address:   FF0x:0:0:0:0:1:FFXX:XXXX
>
> The above multicast address is computed as a function of a node's
> unicast and anycast addresses, and SHOULD NOT be used or joined for any
> scope value other than scope 2 (link-local).  [...rest of current text...]

-Dave