Subject: IPv6 Address Architecture update question

From: Bob Hinden <[email-masked]>
Date: Mon, 31 Jan 2005 04:48:36 -0800

Hi,

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

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.

Thanks,
Bob

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

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 31 Jan 2005 14:24:46 +0100

> textual representation (section 2.2, 3.).

In http://www.ietf.org/rfc/rfc2373.txt it is section 2.5.4.
Or am I looking at the wrong document? :)

<SNIP>

> specification.

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. Both OS's nowadays have a bind-ipv6-only flag or
similar, but many applications rely on this behaviour in that they
either bind to the IPv6 any or the IPv4 any address (0.0.0.0).

Removing it, thus would mean that all these applications are broken and
need to be updated, which actually is true, having that programs should
use multiple sockets and use getaddrinfo() to figure out the correct
sockets to bind on. This has some programming overhead though and as
many people are lazy they did not do it.

The mixing of the stacks, thus having IPv6 also accept IPv4 connections,
did have some negative side effects for the applications that did/do
support getaddrinfo() type binding and bind to multiple sockets, as they
would first bind to IPv6 any, after which they bind to IPv4 any which
would fail with socket already in use, giving an error message that is
not entirely true.

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

The various Operating Systems that support this should be thought the
same tricks too of course...

>   This includes would it break other documents that refer to 

At least RFC3484 has a short section (3.3) on it, though it mentions
handling them as 'global scope', which is basically the default case,
for address selection.

Greets,
 Jeroen

---

From: Bob Hinden <[email-masked]>
Date: Mon, 31 Jan 2005 05:41:05 -0800

Jeroen,

>Or am I looking at the wrong document? :)

Right it's section 2.5.4 in RFC2373.  The section changed a little in the 
new draft.

>many people are lazy they did not do it.

I am not sure they would be broken.  They would be doing something in 
addition to what is in the new RFC.

In any case, thanks for the comments.

Bob

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 31 Jan 2005 11:39:45 -0500

> addition to what is in the new RFC.

They should not be removed from a new version of the spec without a mention 
in the newer version about *why* they were removed.

If we do not have consensus in this WG about why we want to remove them, we will
cause eternal confusion for OS and application implementors downstream.

(And I'm actually aware of at least one feature in the solaris IP stack which is 
supposedly available for UDP/IPv4 traffic through AF_INET6 sockets which is not 
conveniently available through AF_INET sockets.  Long story ...)

						- Bill

---

From: Markku Savela <[email-masked]>
Date: Mon, 31 Jan 2005 19:22:57 +0200

> From: Bill Sommerfeld <[email-masked]>
> 
> They should not be removed from a new version of the spec without a
> mention in the newer version about *why* they were removed.

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

> (And I'm actually aware of at least one feature in the solaris IP
> stack which is supposedly available for UDP/IPv4 traffic through
> AF_INET6 sockets which is not conveniently available through AF_INET
> sockets.  Long story ...)

Just for information comment: not all IPv6/IPv4 is Unix related. For
example, Symbian IPv6/IPv4 implemets only *PROTOCOL FAMILY* PF_INET,
with two address families AF_INET ja AF_INET6. All sockets are basicly
opened for PF_INET (= AF_INET), and will work just fine with IPv4 or
IPv6 without any problems for applications (applications don't need to
care!).

---

From: Pekka Savola <[email-masked]>
Date: Mon, 31 Jan 2005 23:49:50 +0200 (EET)

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

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

However, what I think Bob was referring to was the use of 
IPv4-compatible IPv6 addresses (::1.2.3.4), and refocusing the section 
(2.5.5 in rfc3513) to be about the mapped addresses.

I suggest just simply removing compatibles.  Those who are interested 
of them can always look back at RFC3513.

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