Subject: IPv4 compatible deprecation? (addr-arch-v4)

From: Tim Chown <[email-masked]>
Date: Tue, 18 Nov 2003 10:24:53 +0000

Hi,

A discussion on v6ops made me realise that while I thought we were
deprecating IPv4 compatible addresses, this actually isn't the case.
I have a feeling many people have assumed their use is "deprecated"
but this isn't formally documented?

IPv4 compatibles have now been removed from the latest update of the
Basic Transition Mechanisms document that is just going through v6ops:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-01.txt

If we want to deprecate IPv4-compatible addressing, then we need to look 
at section 2.5.5 of the addressing architecture document that was
re-released with site local updates last month:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-00.txt

We should catch this one while the text is being updated for site locals.
We would presumably update the text in a similar way to the site local
text update to section 2.5.7.

If a separate deprecation document is required as per site local deprecation
I would be happy to author/help on that.   For reference, the site local 
deprecation is defined here:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-site-local-01.txt

This deprecation would not affect mapped addresses.

Tim

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Nov 2003 12:31:09 +0200 (EET)

> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-00.txt
[...]
> I would be happy to author/help on that.

I don't think compatible addresses are as contentious as site-local 
addresses, so I believe we can do without a separate deprecation document 
:-)

-- 
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: Tim Chown <[email-masked]>
Date: Tue, 18 Nov 2003 10:38:36 +0000

> addresses, so I believe we can do without a separate deprecation document 

I agree, but

a) It's a question we have to ask

b) We might want to look back in 4-5 years to check why we did it.

It would only be a one-pager, almost... :)

Tim

---

From: Brian Haberman <[email-masked]>
Date: Tue, 18 Nov 2003 06:10:17 -0500

[wg co-chair hat off]

What about their use in the basic socket API (rfc 3493)?

Brian

---

From: Tim Chown <[email-masked]>
Date: Tue, 18 Nov 2003 11:27:19 +0000

Good point, section 6.2 would need massaging on the next update of this spec.

I'll run a check against other documents.

Tim

---

From: Stig Venaas <[email-masked]>
Date: Tue, 18 Nov 2003 12:33:52 +0100

> I'll run a check against other documents.

I don't think RFC 3493 is a problem. I had a quick look, and all I can
find is that if getnameinfo() is passed a compatible address, it's
supposed to extract the IPv4 address and do a lookup on that.

That it describes what should happen when passed a compatible address,
doesn't prevent deprecating it I think. Don't think it needs to be
updated.

Stig

---

From: "EricLKlein" <[email-masked]>
Date: Tue, 18 Nov 2003 15:27:27 +0200

> doesn't prevent deprecating it I think. Don't think it needs to be

My concern is what happens when it is passed an RFC1918 site local address
(10..., 127... etc) these should not be passing these on, the look for these
should be hardcoded to not route them. Otherwise we will have many leaks
onto the public network.

Eric