Subject: Re: Summary of W.G. Last Call Comments on IPv6 Addressing Architecture

From: [email-masked]
Date: Wed, 14 Nov 2001 09:26:46 +0100

I have another comment/question (bit late, but I thought I could better
mention it before people reissue the draft):

Section 2.5.5 says:
  "A second type of IPv6 address which holds an embedded global IPv4
   address is also defined.  This address type is used to represent the
   addresses of IPv4 nodes as IPv6 addresses.  This type of address is
   termed an "IPv4-mapped IPv6 address" and ...

Why is the definition of ipv4-mapped restricted to global ipv4
addresses?  I can imagine applications in which one wants to embed a
local ipv4 address in an ipv6 format. Or should one use a variant of
ipv4-mapped with a site-local prefix for this case?  Maybe this requires
another way of defining ipv4-mapped: 

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

Prefix could possible also be the multicast prefix in case one wants to
map an ipv4 multicast address in an ipv6 format.

dirk

Bob Hinden wrote:
> 
> The IPng working group last call for Draft Standard for:
> 
>         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
> 
> was completed on August 31, 2001.  A summary of the comments received on
> the mailing list and their disposition is attached.  Note: Editorial
> comments are not included in this summary.
> 
> Once a new version of the draft is issued, the document can be forwarded to
> the IESG for Draft Standard.
> 
> Bob Hinden & Steve Deering
> 
> ------------------------------------------------------------------------
> 
> COMMENT 1: Suggestion that it isn't good practice to talk about assigning
> multicast address to an interface because it may confuse people and they
> might be assigned directly to interfaces (e.g., via ifconfig command).
> 
> Text will be changed to clarify this issue.
> 
> COMMENT 2: Questioned whether the IPv6 addresses with embedded IPv4 address
> should be included in the document.
> 
> This was discussed at the interim meeting in Seattle and there was a
> consensus to keep the mapped and compatible address in this
> document.  Other types of transition addresses can be defined in other
> documents.
> 
> COMMENT 3: Suggestion that the anycast usage scenarios in the document are
> very router centric and restrictions for router only usage be eased.
> 
> The current text will be revised to clarify that other anycast usage is
> possible, but that new uses need to be specified.
> 
> COMMENT 4: Suggestion that there be more clarification on the differences
> between interface, link, and node in section 2.7 on multicast addresses.
> 
> Will add a summary description of the multicast scope values to the document.
> 
> COMMENT 5: Questioned the removal of the format prefix (FP) and detailed FP
> table, and instead only listing the exceptions to global unicast.
> 
> This issue was discussed on the mailing list and there was a consensus that
> the current text is appropriate.  The resulting behavior of treating the
> address space as global unicast, except for the listed exceptions, is correct.
> 
> COMMENT 6: Suggestion to reserve some part of the IPv6 and have it's usage
> be unspecified.
> 
> The discussion on the mailing concluded was this was not a good idea.  Past
> experience with IPv4 indicated that it becomes very hard to utilize
> "unspecified" address space in the future.
> 
> COMMENT 7: Suggestion to move IANA considerations to a numbered section
> instead of an appendix to make clearer it is normative.
> 
> Document will be updated to make the IANA consideration a numbered section.
> 
> --------------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------

-- 
Dirk Ooms                       mailto:[email-masked]
                                tel:+32 3 2404732
Network Strategy Group (NSG)    http://aww.alcatel.com/nsg
Alcatel                         http://www.alcatel.com
--------------------------------------------------------------------
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: Wed, 14 Nov 2001 10:10:56 +0100 (CET)

> addresses? 

The implementations I know have no way to tell whether the
IPv4 address returned by the DNS is a global IPv4 address or something else.
So in the API the IPv4-mapped addresses are used to carry any IPv4
address.

I think it is sufficient to drop the "global" in the text above to clean this
up.

  Erik

---

From: Bob Hinden <[email-masked]>
Date: Wed, 14 Nov 2001 07:17:08 -0800

Dirk, Erik,

I agree.  The IPv4-mapped Ipv6 address does not need to contain a global 
IPv4 address.

Thanks,
Bob