Subject: Deprecate the "IPv4-compatible IPv6 address"

From: Bob Hinden <[email-masked]>
Date: Wed, 16 Mar 2005 11:46:24 -0800

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
--------------------------------------------------------------------

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 16 Mar 2005 15:52:28 -0500

Hi Bob,

Should there also be an upate to the IANA considerations section 
asking IANA to list this allocation as deprecated?

Margaret

At 11:46 AM -0800 3/16/05, Bob Hinden wrote:
>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.
>

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 17 Mar 2005 15:55:44 +0900

>>>>> On Wed, 16 Mar 2005 11:46:24 -0800, 
>>>>> Bob Hinden <[email-masked]> said:

> Please review and comment.

It looks fine.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Kurtis Lindqvist <[email-masked]>
Date: Thu, 17 Mar 2005 15:21:11 +0200 (EET)

Bob,

On Wed, 16 Mar 2005, Bob Hinden wrote:
> to verify this consensus on the mailing list

Agree.

 and to review the proposed
> Please review and comment.

Shouldn't we be a bit more explicit on what routers/hosts should do with
these addresses when found?

- kurtis -

---

From: Lowell Gilbert <[email-masked]>
Date: 17 Mar 2005 09:02:51 -0500

> these addresses when found?

We're already allowing for multiple behaviours.  Being more explicit
(about what those behaviours are) could be more confusing than helpful.

---

From: Bob Hinden <[email-masked]>
Date: Thu, 17 Mar 2005 09:32:59 -0800

Margaret,

At 12:52 PM 03/16/2005, Margaret Wasserman wrote:

>Hi Bob,
>
>Should there also be an upate to the IANA considerations section asking 
>IANA to list this allocation as deprecated?

Good question, I had not thought about that.  What is currently listed on 
the IANA pages for IPv6 address space ( 
http://www.iana.org/assignments/ipv6-address-space ) is:

   IPv6 Prefix           Allocation              Reference      Note
   -----------           ----------              ---------      ----
   0000::/8              Reserved by IETF        [RFC3513]      [1]

   ....

   Notes:

   .....

   [1]  The "unspecified address", the "loopback address", and the IPv6
        Addresses with Embedded IPv4 Addresses are assigned out of the
        0000::/8 address block.

Since the part of the address space where these addresses are found is 
already listed as "Reserved by IETF", I don't think any IANA further action 
is required.

What I think is required (not sure if this happens automatically) is for 
the IANA to update the reference to the new RFC number when it is 
published.  I will add that to the IANA considerations section.

Thanks,
Bob

---

From: Bob Hinden <[email-masked]>
Date: Thu, 17 Mar 2005 09:47:40 -0800

Kurtis,

>these addresses when found?

I don't think it is necessary as there wasn't any special handling defined 
in this document for these addresses.  Their handling falls under the 
default rules for global unicast.

Of course, this wasn't the case for site-local where there were special 
handling rules defined that had to be changed (i.e., removed).

Thanks,
Bob

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 19 Mar 2005 12:53:48 +0100

> 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses

[...]

>    |                80 bits               | 16 |      32 bits        |

I think it's important to spell out that IPv4-mapped addresses aren't 
being deprecated, along with a reference to where they're defined.

---

From: Bob Hinden <[email-masked]>
Date: Mon, 21 Mar 2005 09:58:41 -0800

Iljitsch,

>being deprecated, along with a reference to where they're defined.

I am reluctant to have the text describing the IPv4 Mapped addresses say 
they are "not deprecated" because I think it is best to specify what is 
deprecated instead of what is not deprecated.  For example, we only say 
Site-Local is deprecated, we don't say that Link-Local is not deprecated, 
etc., etc.

I can make the IPv4-compatible text clearer about what is being deprecated.

Current text:

    The first termed an "IPv4-compatible IPv6 address" was defined to
    assist in IPv6 transition.  These addresses are now deprecated
    because the current IPv6 transition mechanisms no longer use them.

Proposed text:

    The first termed an "IPv4-compatible IPv6 address" was defined to
    assist in IPv6 transition.  The "IPv4-compatible IPv6 address" are
    now deprecated  because the current IPv6 transition mechanisms no
    longer use them.

Is that OK?

The IPv4-mapped address are defined in the IPv6 Address Architecture (i.e., 
in this document) so adding a reference would be problematic :-)

Bob

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 22 Mar 2005 00:09:29 +0100

> I am reluctant to have the text describing the IPv4 Mapped addresses 
> say they are "not deprecated" because I think it is best to specify 
> what is deprecated instead of what is not deprecated.

:-)

> Is that OK?

This part was never the problem. The problem is that immediately 

>    "IPv4-mapped IPv6 address" and has the format:

Now it doesn't say that IPv4-mapped addresses are also deprecated, but 
I'll promise you that a significant number of people are going to think 
that they are because of apparent guilt by association. The fact that 
the "IPv4-compatible" and "IPv4-mapped" are highly abstract and not 
easy to tell apart for someone new to the material isn't going to help 
either.

> The IPv4-mapped address are defined in the IPv6 Address Architecture 
> (i.e., in this document) so adding a reference would be problematic 
> :-)

Not unless this part constitutes the entire definition. A little 
recursion can work wonders now and then.

---

From: Bob Hinden <[email-masked]>
Date: Mon, 21 Mar 2005 16:43:47 -0800

Iljitsch,

>that they are because of apparent guilt by association. The fact that the 
>"IPv4-compatible" and "IPv4-mapped" are highly abstract and not easy to 
>tell apart for someone new to the material isn't going to help either.

Not to be difficult, but I am not convinced this is a problem and that we 
need to clarify that IPv4-mapped are not deprecated.  Unless others think 
this is important to clarify, I am leaning to keeping the text as is.  If 
you disagree, please suggest text.

>>(i.e., in this document) so adding a reference would be problematic :-)
>
>Not unless this part constitutes the entire definition. A little recursion 
>can work wonders now and then.

That is the "entire definition".  As discussed in an earlier email, a 
reference  is being added to point to RFC4038 that describes usage.

OK?

Thanks,
Bob

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 22 Mar 2005 09:52:20 +0100

Bob,

On 22-mrt-05, at 1:43, Bob Hinden wrote:

>> Now it doesn't say that IPv4-mapped addresses are also deprecated, 
>> but I'll promise you that a significant number of people are going to 
>> think that they are because of apparent guilt by association. The 
>> fact that the "IPv4-compatible" and "IPv4-mapped" are highly abstract 
>> and not easy to tell apart for someone new to the material isn't 
>> going to help either.

> Not to be difficult, but I am not convinced this is a problem and that 
> we need to clarify that IPv4-mapped are not deprecated.

I submit that as someone who has English as a first language (right?) 
and who has been doing this for a long time, your perception of a clear 
standards text isn't the same as someone who is still strugling with 
the language and is new to all of this.

> Unless others think this is important to clarify, I am leaning to 
> keeping the text as is.  If you disagree, please suggest text.

Ok:

2.5.5.1 IPv4-compatible IPv6 addresses

    The first, termed an "IPv4-compatible IPv6 address", was defined to
    assist in the IPv6 transition. The format of "IPv4-compatible IPv6
    address" is:

2.5.5.2 IPv4-mapped IPv6 addresses

2.5.5.3 IPv4-compatible IPv6 address deprecation

    IPv4-compatible IPv6 addresses are now deprecated because the
    current IPv6 transition mechanisms no longer use them. New or
    updated implementations are not required to support this address
    type.  Existing implementations and deployments may continue to
    use these addresses.

With these modifications, it's much less likely that someone will 
assume IPv4-mapped addresses are also deprecated, and the 
IPv4-compatible deprecation shows up in the table of contents so it's 
easier to find.

> reference  is being added to point to RFC4038 that describes usage.

Good to know the art of conciseness isn't lost.  :-)

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 22 Mar 2005 09:34:21 +0100

On 2005-03-17, at 18.47, Bob Hinden wrote:

> I don't think it is necessary as there wasn't any special handling 
> defined in this document for these addresses.  Their handling falls 
> under the default rules for global unicast.

So If I am an application that receives a packet with a deprecated 
IPv4-compatible address, I should just reply? Or do whatever the stack 
implementer have decided?

> Of course, this wasn't the case for site-local where there were 
> special handling rules defined that had to be changed (i.e., removed).

Sure. But I am more worried of creating ambiguity with what 
applications does when receiving IPv4 compatible addresses as source 
addresses. If we are replying to them, we have the-facto not actually 
deprecated them :-)

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 22 Mar 2005 09:30:22 +0100

> (about what those behaviours are) could be more confusing than helpful.

But the behaviour when receiving a deprecated address might be better 
off being consistent?

- - kurtis -

---

From: Markku Savela <[email-masked]>
Date: Tue, 22 Mar 2005 18:35:21 +0200

> From: Kurt Erik Lindqvist <[email-masked]>

There are many other undefined/bad addresses. It is not sensible to
hard code "bogon-filters" to the stack implementations!

Let the stack do whaever it's normal processing logic does, and lets
not make ip4 compatible a special case that must be implemented. (I
currently do nothing specieal with them now either).

---

From: Lowell Gilbert <[email-masked]>
Date: 22 Mar 2005 12:03:48 -0500

> But the behaviour when receiving a deprecated address might be better 

Presumably, yes.  
But it's too late to require that anyway.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 22 Mar 2005 10:03:13 -0800

Kurtis,

>implementer have decided?

These should be treated like all other types of global unicast 
addresses.  There was never any special handling defined for these addresses.

>addresses. If we are replying to them, we have the-facto not actually

I don't think there is any ambiguity.  Except for the addresses called out 
in Section
2.4 Address Type Identification, all addresses are to be treated as global 
unicast.  An application would not know it has received an IPv4 compatible 
address.  Again, very different from site-local where there was special 
handling defined.

The deprecation of IPv4 compatible addresses is to tell people to stop 
using them.  I don't think it makes any sense to add any new rules or 
required actions to enforce this.

Also, if I remember correctly, our reason for deprecating IPv4 compatible 
address is because we aren't using them.  So if we aren't using them, then 
it follows that the likelihood of receiving one is small.  :-)

Bob

>- - kurtis -
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGP 8.1
>
>iQA/AwUBQj/YkaarNKXTPFCVEQKrfACeMjKdDnOLucur2Pi9m014DvCZi6gAoKjA
>4v+eT+DTYivHX7ugXv8ekofR
>=fknb
>-----END PGP SIGNATURE-----

---

From: Bob Hinden <[email-masked]>
Date: Tue, 22 Mar 2005 10:11:48 -0800

Iljitsch,

>I submit that as someone who has English as a first language (right?) and 
>who has been doing this for a long time, your perception of a clear 
>standards text isn't the same as someone who is still strugling with the 
>language and is new to all of this.
>
>>Unless others think this is important to clarify, I am leaning to keeping 
>>the text as is.  If you disagree, please suggest text.
>
>Ok:
>
>With these modifications, it's much less likely that someone will assume 
>IPv4-mapped addresses are also deprecated, and the IPv4-compatible 
>deprecation shows up in the table of contents so it's easier to find.

I like the idea of putting each type of address in a separate section, but 
not so about adding a separate section for the deprecation.  As a 
compromise, how about if I add the separate section for each type and then 
put the deprecation text in the section on IPv4-compatible addresses?   I 
think that will make it very clear which type of address is being deprecated.

I will send to the list a revised section with this and the other agreed 
changes later today.

:-)

Bob

---

From: Lowell Gilbert <[email-masked]>
Date: 22 Mar 2005 18:17:56 -0500

> But it's too late to require that anyway.

Eric Gray has made me aware that I was addressing a different point
than I was following up to.  I apologize and will respond to what was
actually asked...

There is no reason to require different treatment for these addresses
than for the rest of the IETF space.  It would not be harmful to treat
them as "Martian" addresses and require them to be silently dropped
all the time, but doing so would not actually help anything either.

As I see it, the reason to deprecate these addresses is to make the
spec simpler, not more complicated.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 Mar 2005 10:22:15 +0100

On 22-mrt-05, at 19:11, Bob Hinden wrote:

> I like the idea of putting each type of address in a separate section, 
> but not so about adding a separate section for the deprecation.  As a 
> compromise, how about if I add the separate section for each type and 
> then put the deprecation text in the section on IPv4-compatible 
> addresses?   I think that will make it very clear which type of 
> address is being deprecated.

I guess that's good enough.

Iljitsch

---

From: Bob Hinden <[email-masked]>
Date: Wed, 23 Mar 2005 11:25:22 -0800

Iljitsch,

At 01:22 AM 03/23/2005, Iljitsch van Beijnum wrote:
>>addresses?   I think that will make it very clear which type of address 
>>is being deprecated.
>

Thanks,
Bob

---

From: Francis Dupont <[email-masked]>
Date: Sat, 26 Mar 2005 12:04:57 +0100

In your previous mail you wrote:

=> I support the proposal.

Regards

[email-masked]