Subject: Proposed "IPv4-compatible IPv6" Deprecation text

From: Bob Hinden <[email-masked]>
Date: Tue, 22 Mar 2005 15:49:09 -0800

Hi,

Here is what I hope is the final text that specifies the deprecation of the 
"IPv4-compatible IPv6 address".  Included below are the revised sections 
"IPv6 Addresses with Embedded IPv4 Addresses" and "IANA Consideration".

Please review.  I hope to submit an update draft tomorrow.

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.

2.5.5.1 IPv4-Compatible IPv6 Address

    The first termed an "IPv4-compatible IPv6 address" was defined to
    assist in IPv6 transition.  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.

    The "IPv4-compatible IPv6 address" is 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.

2.5.5.2 IPv4-Mapped IPv6 Address

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

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

-----------------------------------------------------------------------

4. IANA Considerations

    The "IPv4-compatible IPv6 address" is deprecated by this document.
    The IANA should continue to list the address block containing this
    address as "Reserved by IETF" and not reassigned it for any other
    purpose.

    Update the references for the IPv6 Address Architecture in the IANA
    registries to this RFC when published.

------------------------------------------------------------

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

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 22 Mar 2005 14:00:44 -1000 (HST)

>     type.  Existing implementations and deployments may continue to use

Can we just drop that last sentence altogether as it seems somewhat
contrary to the rest of the paragraph?

---

From: "timothy enos" <[email-masked]>
Date: Wed, 23 Mar 2005 00:20:43 -0500

It seems good to keep the last sentence, as we don't want to risk
breaking existing implementations. The same basic logic applies to why
existing implementations are allowed to continue using site-local
unicast addresses even though they were formally deprecated in RFC 3879.

Best regards,

Tim Enos
1Sam16:7

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Antonio Querubin
Sent: Tuesday, March 22, 2005 7:01 PM
To: Bob Hinden
Cc: [email-masked]
Subject: Re: Proposed "IPv4-compatible IPv6" Deprecation text

---

From: "EricLKlein" <[email-masked]>
Date: Wed, 23 Mar 2005 11:15:26 +0200

> contrary to the rest of the paragraph?

I tend to agree. If we are explicitly telling them to stop using them, then 
it seems to  be over kill to tell them that they can continue to use them.

Eric

---

From: Colm MacCarthaigh <[email-masked]>
Date: Wed, 23 Mar 2005 09:45:07 +0000

Just grammar ...

>    assist in IPv6 transition.  The format of "IPv4-compatible IPv6

everywhere else you use "an" before "IPv4-compatible IPv6 address", 
might be due here :)

>    current IPv6 transition mechanisms no longer use them.  

them -> it. 

>    address as "Reserved by IETF" and not reassigned it for any other

reassigned -> reassign

-- 
Colm MacCárthaigh                        Public Key: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Mar 2005 16:01:05 +0100

It's OK in my personal opinion, but I wouldn't object to removing
the "may continue to use" sentence if that is the consensus.

    Brian

Bob Hinden wrote:
> Hi,
> 
> Here is what I hope is the final text that specifies the deprecation of 
> the "IPv4-compatible IPv6 address".  Included below are the revised 
> sections "IPv6 Addresses with Embedded IPv4 Addresses" and "IANA 
> Consideration".
>

---

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

Antonio,

>contrary to the rest of the paragraph?

I don't have a strong opinion and would be happy to remove it.  I will plan 
to do that unless I hear lots of disagreement.

Bob

---

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

> I don't have a strong opinion and would be happy to remove it.  I will 
> plan to do that unless I hear lots of disagreement.

Is there a place where it is explained what "deprecate" means in the 
IETF context? Looking the word up in the dictionary won't help people 
who don't understand it...

---

From: Baker Fred <[email-masked]>
Date: Wed, 23 Mar 2005 14:10:32 -0800

> who don't understand it...

I believe it is generally used as defined in RFC 1158:

3.1.  Deprecated Objects

    In order to better prepare implementors for future changes in the
    MIB, a new term "deprecated" may be used when describing an object.
    A deprecated object in the MIB is one which must be supported, but
    one which will most likely be removed from the next version of the
    MIB (e.g., MIB-III).

In other words, something that is deleted from a specification is 
something that someone might immediately re-use with different 
semantics. That is an interoperability nightmare. So when we remove 
something from a specification, we generally do so by saying "this is 
defined, but should not be used".

In this context, it would be that the usage would be explicitly 
recommended against, but the definition left in place in the form of an 
IANA reservation of the structure so that it would not be re-used. 
Things that understand it will understand it, and things that don't 
won't, but nobody gets confused.