Subject: Re: IPv6 Address Architecture update question

From: Antonio Querubin <[email-masked]>
Date: Mon, 31 Jan 2005 11:04:59 -1000 (HST)

On Mon, 31 Jan 2005, Bob Hinden wrote:

> I am working on an update to the IPv6 address architecture.  In doing this
> I am working through the comments on the previous draft.  One comment made
> was to remove Section 2.5.5 "IPv6 Addresses with Embedded IPv4 Addresses"
> from the document.  This would include removing the special case in the
> textual representation (section 2.2, 3.).
>
> I would like to solicit the working group's thoughts on this.  I don't have
> a strong opinion one way or another.  It's not clear it has ever been that
> useful and add a certain degree of complexity.  On the other hand, it
> appears in  several places in the document and requires some careful
> editing :-)

IPv4-mapped addresses facilitate an important interoperability mechanism
in the socket API (RFC 3493, section 3.7).  While it's probably not a good
idea to transmit these addresses on the wire, I think the API still needs
a way to represent IPv4 addresses in a way that preserves compatibility
between IPv6 and IPv4 hosts.  Removal just makes transition all the more
time-consuming and difficult for software developers.

I'd rather see clarification of the use of embedded addresses in the
document rather than complete removal.  Ie. add a statement to the effect
of 'Embedded addresses are intended for internal representation only'.

Antonio Querubin
Pacific LightNet Communications / Hawaii OnLine
System Administrator
[email-masked]   (808) 791-2898

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

---

From: Colm MacCarthaigh <[email-masked]>
Date: Tue, 1 Feb 2005 10:41:26 +0000

> time-consuming and difficult for software developers.

Removal and formal deprecation would simplify life for software
developers. As it currently stands some platforms now make it
deliberately difficult (e.g. openbsd) to use this transition mechanism
and others impossible (Win32). 

Until recently some platforms (Linux for example) didn't support the
IPV6_V6ONLY socket option, at all, but a deprecation might speed up
transition to a single means of listening for packets. Currently the
logic is somewhat convoluted, see

 http://svn.apache.org/viewcvs.cgi/apr/apr/trunk/network_io/unix/sockaddr.c?view=markup

For an impression of complexity of interoperability support right now.
Personally I like IPv4-mapped address sockets, but enough people havn't
been convinced and many have intractable positions regarding their
security. They are *never* going to form the basis of a useful
transition mechanism now, all software - if it's going to be in anyway
portable and useful - simply has to support IPV6_V6ONLY sockets
aswell, and include all of that logic.

We might aswell rid developers of the burden of having to cope with
mapped-address sockets aswell.

So:

	if has_v6only is true then
		listen(::)
		listen(0.0.0.0)
		use_[select|poll|kqueue|whatever]_loop()
	else
		listen(::)

just becomes:

	listen(::)
	listen(0.0.0.0)
	use_[select|poll|kqueue|whatever]_loop()

It may not look like much of a saving there, but it is definitely less
complication. In Apache httpd and apr, it would easily lead less than
half the ammount of code currently needed for dealing with IPv6.  Don't
forget there are other simplifications benefited, not using mapped
addresses means that developers don't have to be paranoid about mapping
::ffef:1.1.1.1 to an IPv4 container for checking ACL's, DNS and so on
(see apr_getnameinfo for the workarounds needed for more buggy platforms
in this regard).

Anyway, in summary, removal would in my opinion actually make transition
much easier for software developers, not harder. Don't let the
superficial ease of the mapped-address API fool you :)

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

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 01 Feb 2005 11:50:37 +0100

On Tue, 2005-02-01 at 10:41 +0000, Colm MacCarthaigh wrote:
> developers.

I support this argument in favor of removing mapped addresses.

> 	use_[select|poll|kqueue|whatever]_loop()

Replace the listen(::) + listen(0.0.0.0) with a getaddrinfo() info loop
and I completely agree ;)

Greets,
 Jeroen

---

From: Bob Hinden <[email-masked]>
Date: Tue, 01 Feb 2005 04:27:11 -0800

Hi,

In response to my question about keeping the "IPv6 Addresses with Embedded 
IPv4 Addresses" (e.g., compatible and mapped) I heard the following:

"I think that at least all the BSD's and most Linuxes are using this.
They allow binding on :: (IPv6 any) and also accept IPv4 connections on
the same socket, which are then represented in netstat etc
as ::ffff:1.2.3.4.", "IMO the section can be removed and programmers need 
to be learned the correct thing for which I always very inclined to point 
people to Eva's excellent document at 
http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html and/or 
draft-ietf-v6ops-application-transition-02.txt"

"They should not be removed. Implementations already support it, removing 
would just create confusion. I don't see any harm in keeping it in."

"helps with porting applications" and "dropping this section will create 
confusion and chaos for the already ported applications"

"Among other things, this would break the just published full
Standard for URIs (RFC 3986).", "I suspect some people have used the 
::10.1.2.3 format to carry IPv4 addresses in an IPv6 container, simply for 
convenience. I think this is very convenient and should be available.",
" otoh the ::FFFF:10.1.2.3 format seems useless to me."

"IPv4-mapped addresses facilitate an important interoperability mechanism
in the socket API (RFC 3493, section 3.7).", "the API still needs
a way to represent IPv4 addresses in a way that preserves compatibility
between IPv6 and IPv4 hosts.  Removal just makes transition all the more
time-consuming and difficult for software developers.

"rather see clarification of the use of embedded addresses in the
document rather than complete removal.  Ie. add a statement to the effect
of 'Embedded addresses are intended for internal representation only'."

"It is clear that the mapped addresses are widely used and useful, and a 
lot of people have raised their concerns about removing that.", "I suggest 
just simply removing compatibles."

"Removal and formal deprecation would simplify life for software 
developers.", "We might as well rid developers of the burden of having to 
cope with mapped-address sockets as well.", "Anyway, in summary, removal 
would in my opinion actually make transition much easier for software 
developers, not harder. Don't let the superficial ease of the 
mapped-address API fool you :)"

My take of this is that they should remain in the IPv6 address 
architecture.  There is current usage and removing them would break other 
specifications.

Thanks,
Bob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Feb 2005 15:00:12 +0100

> architecture.  There is current usage and removing them would break other 

So then let me add another voice for deprecation. My experience is
that the precise behaviour of these mapped addresses is pretty hard
to predict in practice and that makes code maintenance more costly.
My observation is that mapped addresses initially look appealing, 
but they turn out to be problematic later and I have now given up
on using them.

If these addresses are kept in the document, I think there should 
be a clear warning attached about using them.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 01 Feb 2005 15:14:45 +0100

> IPv4 Addresses" (e.g., compatible and mapped) I heard the following:
<SNIP>

> architecture.  There is current usage and removing them would break other 

Maybe it should be at least be noted in the document that one should not
use them. Thus that applications should be using multiple sockets, one
for IPv4 and one for IPv6 and one for whatever follows.
"forcing"/telling programmers to do it the getaddrinfo() can only be
good IMHO. Also when we change to IPv7 or anything else in the future.

Greets,
 Jeroen

---

From: Markku Savela <[email-masked]>
Date: Tue, 1 Feb 2005 16:36:18 +0200

> From: Jeroen Massar <[email-masked]>

> Thus that applications should be using multiple sockets, one

I strongly object to this. There are other socket api's which don't
have the Unix inherited drawbacks. For such, the recommendation is
exactly the opposite: the same socket works just fine for IPv4 and
IPv6, and in unifying the application code to work for both, IPv4
mapped address format is very useful tool.

There is no reason for application to care at all whether actual
connection is over IPv4 or IPv6.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 01 Feb 2005 15:45:35 +0100

> mapped address format is very useful tool.

Any documentation on this ? I do know RFC3493, not any others.

> connection is over IPv4 or IPv6.

There is, these are different protocols, how else are you going to
address which host you are going to connect to?

For instance www.kame.net port 80 results in different answers over IPv6
than the one on IPv4...

If you are talking about wrappers, then these are most likely wrapping
around the above already anyway, thus it matter than?

Greets,
 Jeroen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Feb 2005 16:00:13 +0100

> mapped address format is very useful tool.

On those other socket APIs, does code which uses two sockets work
or not?

/js

---

From: Colm MacCarthaigh <[email-masked]>
Date: Tue, 1 Feb 2005 15:04:09 +0000

> connection is over IPv4 or IPv6.

There are plenty of reasons. Logging, resolving addresses, applying
application-level access control, application-level virtual hosting, to
name but a few. 

But ignoring this, there are platforms on which IPv4-mapped addresses
will never work. So far it looks like there is a serious consolidation
towards there being no platforms on which both IPv4-only and IPv6-only
sockets won't work.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 1 Feb 2005 17:39:15 +0200 (EET)

On Tue, 1 Feb 2005, Bob Hinden wrote:
> My take of this is that they should remain in the IPv6 address architecture. 
> There is current usage and removing them would break other specifications.

I would agree with that conclusion for mapped addresses, but I have 
heard NO ONE explicitly saying anything about the usefulness of 
compatible addresses.

Thus my take is that compatibles should be removed, and some kind of 
warning/reference text added to the mapped addresses. 
draft-ietf-v6ops-application-transition-03 (soon to be RFC) discusses 
some of this.

-- 
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: [email-masked] (Christian Weisgerber)
Date: Tue, 1 Feb 2005 17:06:46 +0000 (UTC)

Jeroen Massar <[email-masked]> wrote:

> I think that at least all the BSD's and most Linuxes are using this.
> the same socket,

OpenBSD doesn't allow this.  FreeBSD and NetBSD don't by default, but
it can be enabled there.

-- 
Christian "naddy" Weisgerber                          [email-masked]

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 1 Feb 2005 10:45:07 -1000 (HST)

> OpenBSD doesn't allow this.  FreeBSD and NetBSD don't by default, but

It's OS version dependent.  For example FreeBSD 4.x enables mapped
addresses by default whereas FreeBSD 5.x turns it off by default.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 2 Feb 2005 10:04:12 +0900 (JST)

> Since I expect this is widely implemented, please be sure to report any 
> problem that might occur if this is to be removed from the 
> specification.  This includes would it break other documents that refer to 
> the IPv6 address architecture specification.
> 
> The plan is to submit the updated draft for Draft Standard.  In general 
> removing things that are not found to be useful is OK when going to Draft 
> standard.

	I support the removal of section 2.5.5 and section 2.2(3).
	IPv4 compatible address is not used any more as auto tunnel went away.
	my position on IPv4 mapped address is described in the following
	documents:
		draft-cmetz-v6ops-v4mapped-api-harmful-01.txt
		draft-itojun-v6ops-v4mapped-harmful-02.txt

itojun

---

From: Bob Hinden <[email-masked]>
Date: Tue, 01 Feb 2005 23:45:55 -0800

Pekka,

At 07:39 AM 02/01/2005, Pekka Savola wrote:
>I would agree with that conclusion for mapped addresses, but I have heard 
>NO ONE explicitly saying anything about the usefulness of compatible addresses.

With the email received after yours, I think it is clear there is not a 
consensus to remove either the IPv4 compatible or mapped addresses from the 
IPv6 address architecture.  I think your email helped to clarify this.

Thanks,
Bob

---

From: Tim Chown <[email-masked]>
Date: Wed, 2 Feb 2005 15:47:10 +0000

> draft-ietf-v6ops-application-transition-03 (soon to be RFC) discusses 

Hi Pekka,

I thought compatibles had (or were) being removed.  That's why all reference
to them was removed from the new transition mechanisms RFC update?  See
section 9 of draft-ietf-v6ops-mech-v2-06.txt.   If we're doing a u-turn on
that, we should catch it in this draft too.

The docs at http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html and as
draft-ietf-v6ops-application-transition-03.txt (not -02!) show good 
practice.   Has the application-transition draft been last called yet?  
Could we get it pushed and cited here in this RFC update?

I didn't realise mapped was disabled on so many systems, very interesting.
I am indifferent on mapped addresses; they clearly have use, and are being 
used, but it's not a wholly 'clean' solution for some of the reasons posted
here and were we to start again...

I think Itojun's mapped-on-the-wire-harmful draft is also good to cite,
but that seems unlikely to ever complete?

-- 
Tim

---

From: "Jeff W. Boote" <[email-masked]>
Date: Thu, 03 Feb 2005 16:26:42 -0700

> OpenBSD doesn't allow this.  FreeBSD and NetBSD don't by default, but

OpenBSD doesn't allow it? An application can't even explicitly set 
IPV6_BINDV6ONLY to false? That is simply broken in my opinion.

Forcing a server to do a select after accept when the developer has already gone 
to the trouble of dealing with multiple address families using the available 
address macros is not right. I realize there are security concerns involved, but 
there are also performance concerns. Lets not force additional system calls when 
they are not needed! I'm all for warning developers about the possible problems, 
but I see no reason to limit the functionality.

Note that this argument is for mapped addresses, I don't see the same reason to 
keep compatible addresses.

jeff

---

From: Pekka Savola <[email-masked]>
Date: Mon, 7 Feb 2005 09:47:14 +0200 (EET)

Now that the thread has quieted down..

> that, we should catch it in this draft too.

Totally agree, of course.  Including them here just adds confusion 
because the readers think that is another addressing format they will 
have to remember.

> Could we get it pushed and cited here in this RFC update?

Application-transition was approved about 3-4 months ago, and is very 
soon to become RFC, and could be cited here as an informative 
reference.

draft-ietf-v6ops-application-transition-03.txt also discusses briefly 
the tradeoffs that the app writer has to make regarding portability 
because the mapped addresses are not available on all the platforms.

---

From: [email-masked] (Christian Weisgerber)
Date: Mon, 7 Feb 2005 15:40:24 +0000 (UTC)

Jeff W. Boote <[email-masked]> wrote:

> > OpenBSD doesn't allow this.
> 
> IPV6_BINDV6ONLY to false?

Correct, and the omission is intentional.

> That is simply broken in my opinion.

I understand that there are many people with sharply diverging
strong opinions on this.  I'm merely reporting a fact.