Subject: RE: Deprecate the "IPv4-compatible IPv6 address"

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 16 Mar 2005 16:15:45 -0500

Are RFC 2893 Para. 5.2 and 5.3 going to be updated accordingly? Otherwise, I have no objection.

Bert

> -----Original Message-----
> From: Bob Hinden [mailto:[email-masked]]
> Sent: Wednesday, March 16, 2005 2:46 PM
> To: [email-masked]
> Subject: Deprecate the "IPv4-compatible IPv6 address"
> 
> 
> Hi,
> 
> At last weeks IPv6 session in Minneapolis, the working group 
> reached a 
> consensus to deprecate the "IPv4-compatible IPv6 address".  
> This email is 
> to verify this consensus on the mailing list and to review 
> the proposed 
> text to deprecate these address in the update to the IPv6 Address 
> Architecture document.  A proposed revision of Section 2.5.2 
> is include below.
> 
> Please review and comment.
> 
> Thanks,
> Bob
> 
> ----------------------------------------------------------
> 
> 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses
> 
>     Two types of IPv6 addresses are defined that carry an 
> IPv4 address in
>     the low-order 32 bits of the address.
> 
>     The first, termed an "IPv4-compatible IPv6 address", was 
> defined to
>     assist in the IPv6 transition.  These addresses are now deprecated
>     because the current IPv6 transition mechanisms no longer use them.
> 
>     The format of "IPv4-compatible IPv6 address" is:
> 
>     |                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.
> 
>     New or updated implementations are not required to support this
>     address type.  Existing implementations and deployments 
> may continue
>     to use these addresses.
> 
>     A second type of IPv6 address which holds an embedded 
> 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 has the format:
> 
>     |                80 bits               | 16 |      32 
> bits        |
>     
> +--------------------------------------+--------------------------+
>     |0000..............................0000|FFFF|    IPv4 
> address     |
>     
> +--------------------------------------+----+---------------------+
> 
> 
> ----------------------------------------------------------
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Mar 2005 23:58:46 +0200 (EET)

> Otherwise, I have no objection.

RFC2893 is going to be obsoleted any day now, by 
draft-ietf-mech-v2-xx, so this is not an issue.

While I would have liked to remove the mention of compatible addresses 
completely, deprecation as proposed by Bob is good enough for me.

Some might argue (and argued in the past) that there should be some 
health warnings about the use of mapped addresses (e.g., a reference 
to now-published RFC4038), but IMHO that kind of text may be ill fit 
to the address architecture and is opening a can-of-worms that we 
_don't_ want to touch here.  But I could live with adding a reference 
if required.

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

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 17 Mar 2005 10:07:43 +0100

>_don't_ want to touch here.  But I could live with adding a reference 

I am all in for the current proposal of deprecation.

The only addition I would _suggest_ is that both the mapped and
compatible addresses are basically a way of representing addresses to a
user. Users are familiar with IPv4 addresses (eg 192.0.2.0), thus maybe,
for the people who want to use IPv6 sockaddr's to store also IPv4
addresses, they might want to represent IPv4 addresses using the normal
192.0.2.0, the on-the-wire traffic is IPv4 also in these cases* and the
user sees a IPv4 address, which is what she expects. Showing ::1.2.3.4
or ::ffff:1.2.3.4 only confuses them as they would think "that is IPv6,
it looks like IPv4 but it has a ':' thus it is IPv6" even though it is
not.

* = there where some mentioning that they used either or both compat+
mapped addresses but afaik they did not use them on the wire, eg really
sticking ::ffff:1.2.3.4 in a IPv6 packet.

Greets,
 Jeroen

---

From: Bob Hinden <[email-masked]>
Date: Thu, 17 Mar 2005 10:07:12 -0800

Pekka,

>completely, deprecation as proposed by Bob is good enough for me.

Thanks!

>Some might argue (and argued in the past) that there should be some health 
>warnings about the use of mapped addresses (e.g., a reference to 
>now-published RFC4038), but IMHO that kind of text may be ill fit to the 
>address architecture and is opening a can-of-worms that we _don't_ want to 
>touch here.  But I could live with adding a reference if required.

How about adding the following after the mapped address diagram:

   See RFC4038 for background on the usage of "IPv4-mapped IPv6 address".

and adding an informational reference to RFC4038.

Bob

---

From: Pekka Savola <[email-masked]>
Date: Mon, 21 Mar 2005 12:22:13 +0200 (EET)

> and adding an informational reference to RFC4038.

No objection from me.