Subject: RFC 2553 bind semantics harms the way to AF independence

From: [email-masked]
Date: Fri, 22 Jun 2001 11:29:57 -0300

RFC 2553 bind semantics harms the way to AF independence
                                      
                              Horacio J. Peña
   
   RFC 2553 enforces the IPv4 mapped on IPv6 model for bind(2). This has
   had some very useful short term results, but harms very badly the way
   to AF independence, a goal that in my opinion we should try to reach.
   
                                 Main premise
                                       
   This paper is based on the premise that it's better writing AF
   independent programs than IPv6 centric ones.
   
   The basis for this is that we don't believe IPv6 is the
   cure-everything protocol and that any time in the future (probably in
   the far future) there would be a new transition from IPv6 to some
   other protocol. And we should do our best so that when that happens
   those who have to make that transition work can do it as easily as
   possible.
   
   We're experiencing the IPv4 to IPv6 transition, and it's painful.
   There's too much work to do, and the porting of the applications is
   responsible for much of that pain.
   
   Yes, porting an application is not so hard. But when you have so many,
   there is a problem. How many times have we heard that the IPv6
   adoption is so slow because there is no support on the clients? How
   easier would have been getting that support if no change to the
   applications had have to be done? I believe that the answer is ``lots
   easier''. Porting the applications to use the AF independent way will
   make future transitions very much easier. I believe that's desired.
   
                            What does RFC 2553 says
                                       
   Note: I'm talking about ``RFC 2553'' but meaning ``RFC 2553 and
   successors'', so i'll quote rfc2553bis-03 draft, not the RFC.
   
     Because of the importance of providing IPv4 compatibility in the
     API, these extensions are explicitly designed to operate on
     machines that provide complete support for both IPv4 and IPv6. A
     subset of this API could probably be designed for operation on
     systems that support only IPv6. However, this is not addressed in
     this memo.
     
   (from ``2. Design Considerations'')
   
   I.e., RFC 2553 applies to dual stack hosts.
   
     Applications may use PF_INET6 sockets to open TCP connections to
     IPv4 nodes, or send UDP packets to IPv4 nodes, by simply encoding
     the destination's IPv4 address as an IPv4-mapped IPv6 address, and
     passing that address, within a sockaddr_in6 structure, in the
     connect() or sendto() call. When applications use PF_INET6 sockets
     to accept TCP connections from IPv4 nodes, or receive UDP packets
     from IPv4 nodes, the system returns the peer's address to the
     application in the accept(), recvfrom(), or getpeername() call
     using a sockaddr_in6 structure encoded this way.
     
   (from ``3.7 Compatibility with IPv4 Nodes'')
   
     5.3 IPV6_V6ONLY option for AF_INET6 Sockets
     
     This socket option restricts AF_INET6 sockets to IPv6
     communications only. As stated in section <3.7 Compatibility with
     IPv4 Nodes>, AF_INET6 sockets may be used for both IPv4 and IPv6
     communications. Some applications may want to restrict their use of
     an AF_INET6 socket to IPv6 communications only. For these
     applications the IPV6_V6ONLY socket option is defined. When this
     option is turned on, the socket can be used to send and receive
     IPv6 packets only. This is an IPPROTO_IPV6 level option. This
     option takes an int value. This is a boolean option. By default
     this option is turned off.
     
   This implies that when binding an INET6 socket to a port (without
   specifying an address to bind to) it will hear the IPv4 requests too
   unless the IPV6_V6ONLY option is set.
   
   That is done using the IPv4-mapped IPv6 addresses.
   
                            How to program a server
                                       
   Let me digress a bit now. I'll show how a server is programmed in IPv4
   only programs, in IPv6 centric ones, and in the AF independent way, so
   the rest of this paper can be understood.
   
IPv4 server

int listenfd, connfd;
struct sockaddr_in cliaddr, servaddr;
socklen_t clilen;

listenfd = socket(AF_INET, SOCK_STREAM, 0);

if(listenfd < 0)
   die();

memset(&servaddr, 0, sizeof(servaddr));
servaddr.sin_family = AF_INET;
servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
servaddr.sin_port = htons(1000);

if(bind(listenfd, &servaddr, sizeof(servaddr)) != 0)
   die();

if(listen(listenfd, 10) != 0)
   die();

connfd = accept(listenfd, (struct sockaddr *) &cliaddr, &clilen);

if(connfd < 0)
   die();

/* do something with connfd */

   This does work only with IPv4 connections, if anyone tries to connect
   to that box at the tcp port 1000 by IPv6 it will not connect.
   
IPv6 centric server

int listenfd, connfd;
struct sockaddr_in6 cliaddr, servaddr;
socklen_t clilen;

listenfd = socket(AF_INET6, SOCK_STREAM, 0);

if(listenfd < 0)
   die();

memset(&servaddr, 0, sizeof(servaddr));
servaddr.sin6_family = AF_INET6;
servaddr.sin6_addr = in6addr_any;
servaddr.sin6_port = htons(1000);

if(bind(listenfd, &servaddr, sizeof(servaddr)) != 0)
   die();

if(listen(listenfd, 10) != 0)
   die();

connfd = accept(listenfd, (struct sockaddr *) &cliaddr, &clilen);

if(connfd < 0)
   die();

/* do something with connfd */

   Almost no changes from the IPv4 only server. Accepts both IPv4 and
   IPv6 connections. But it is not going to work in OS with IPv6 support
   compiled out (it is not going to work even for IPv4)
   
AF independent server

int listenfds[MAX_AF], connfd;
struct addrinfo hints, *res, *ressave;
struct sockaddr_storage ss;
socklen_t sslen;
int n, i, m;
fd_set fdset;

memset(&hints, 0, sizeof(hints));
hints.ai_flags = AI_PASSIVE;
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;

if(getaddrinfo(NULL, "1000", &hints, &res) != 0)
   die();

ressave = res;

for(n = 0; (n < MAX_AF) && res ; res = res->ai_next) {
        listenfds[n] = socket(res->ai_family, res->ai_socktype,
                    res->ai_protocol);
        if(listenfds[n] < 0)
          continue; /* libc supports protocols that kernel don't */

        if(bind(listenfds[n], res->ai_addr, res->ai_addrlen) != 0)
      die();

        if(listen(listenfds[n], 10) != 0)
      die();
        n++;
        }

freeaddrinfo(ressave);

m = 0;
FD_ZERO(&fdset);
for(i = 0; i < n; i++) {
        FD_SET(listenfds[i], &fdset);
        m = MAX(listenfds[i]+1,m);
        }

if(select(m, &fdset, NULL, NULL, NULL) < 0)
   die();

for(i = 0; i < n; i++) {
        if(FD_ISSET(listenfds[i], &fdset)) {
                sslen = sizeof(ss);
                connfd = accept(listenfds[i], (struct sockaddr*) &ss, &sslen);
                break;
                }
        }

if(connfd < 0)
   die();

/* do something with connfd */

   Lots harder...
   
A comment

   But that's not all.
   
   Nor the IPv6 centric nor the AF independent way work as cleanly as I
   presented them. The IPv6 centric way dies on OS where the IPv6 support
   is not compiled, so when programming the IPv6 centric way you should
   check if the socket call fails and then fall back to work as a pure
   IPv4 server (ie, duplication of code)
   
   And about the AF independent way... I'll talk about the problems it
   has on the following sections of this paper.
   
   But, even if both ways worked so great as the previous sections would
   make you believe, while the AF independent way is harder to do, it's a
   once in the life change, while the IPv6 centric way would have to be
   modified if any time in the future you want to handle anything that
   cannot be mapped to IPv6.
   
   End of the digression. Let's go back to RFC 2553.
   
                           RFC 2553 implementations
                                       
   We classify the RFC 2553 implementations by how they implement the
   bind semantics.
   
The non compliant ones

   These systems consider IPv4 and IPv6 as different protocols, so they
   don't let the IPv4 mapping to IPv6 work.
   
   The AF independent way works great. The IPv6 centric way works only
   for IPv6 connections and the INET6 sockets never catch an IPv4
   connection.
   
   OpenBSD, NetBSD (by default) and MSR stack for Windows are some of the
   non compliant implementations.
   
The buggy ones

   Warning: I talk about ``buggyness'' just about the issue on topic, the
   systems I qualify as ``buggy'' are the best I've worked with. And I
   like the ``buggy'' stacks better than the ``correct'' ones where
   trying to work without depending on AF is really hard.
   
   Moderns IPv4 stacks consider INADDR_ANY as meaning ``every address'',
   and not ``default for not bound addresses'', so they don't allow
   binding to an specific address when the wildcard address is bound in
   the same port. That is to avoid letting applications ``steal''
   connections from other ones. The same way it shouldn't be allowed to
   ``steal'' the IPv4 connections from the IPv6 wildcard. Allowing that
   should be considered a bug.
   
   That behaviour lets the IPv6 centric way work ok, and the AF
   independent way work ok too. But it has a bug.
   
   FreeBSD, NetBSD (optionally) and BSDI has that buggy behaviour.
   Probably most propietary implementations do too.
   
Compliant, non-buggy, but unworkable

   Warning: I amn't saying that Linux has not bugs. I'm just talking
   about bind semantics in this paper.
   
   That's Linux. Linux complies with the RFC letting the IPv6 sockets
   catch IPv4 connections, has not the bug mentioned before, but it is
   impossible to work with in an AF independent fashion.
   
   When doing the socket/bind/listen loop, the IPv4 bind call will fail
   because there is an IPv6 socket bound to the IPv6 wildcard address, so
   you should ignore bind errors, or croak only if none of the bind calls
   worked, but that will be the same that ignoring bind errors if a new
   protocol that has no mapping to the others exists. Ignoring these
   errors is a Bad Thing.
   
Conclusion: there's no good implementations of RFC 2553

   If my classification is not exhaustive and there is a non-buggy, fully
   compliant implementation of the RFC 2553 bind semantics that doesn't
   cause problems to programs written in an AF independent way, I'd be
   very pleased to know them and learn how they have avoided all that
   problems. But I believe that the cause is that the RFC is not very
   good on that point and should have more work done on that.
   
   Until then I can just suggest several possible ways of solving this
   problem.
   
                              Possible solutions
                                       
   Any of the following possible solutions is good enough for me, being
   my objective to be able to program portable, AF-independent programs
   without having to add special cases for IPv6 (nor any other protocol,
   I'm an application programmer, I shouldn't care about what is running
   the network), something I cannot do now because the Linux way of
   implementing bind.
   
   I believe IPv4 mapped addresses will be deprecated sooner or later
   because IPv4 itself will be deprecated. And I believe that maybe now
   is the time to start that deprecation, not by disallowing them right
   now, but by allowing the existence of systems where the IPv4 and IPv6
   stacks are isolated (like OBSD and Windows) That's what I call for,
   but any of the other possible solutions will be enough for me.
   
Deprecate IPv4 mapped addresses

   Maybe the time for IPv4 mapped addresses is over, maybe that was a
   good mechanism to get things to start rolling but it's time to grow up
   and left them.
   
   Itojun has mentioned in their ipv6-transition-abuse draft many other
   problems that the IPv4 mapped addresses have.
   
   But, there is too much work done in the IPv6 centric way, so maybe it
   isn't prudent to throw them all at once.
   
Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option

   Then the IPv6 sockets would have to be explicitly allowed to accept
   IPv4 connections. So the programs that use the IPv6 centric way have
   to be modified a bit, but the buggy implementations and the unworkable
   one could be corrected without losing features. Just making
   IPV6_V6ONLY default to on would have the same results.
   
More magic to getaddrinfo

   Take the Linux approach as the good one (it's the only compliant and
   non buggy -again, talking just about the issue on topic, i won't judge
   the general buggyness of any stack here), add a bit more (yet more!)
   of magic to getaddrinfo so it only returns the INET wildcard sockaddr
   when the kernel has no support for IPv6, and then the buggy stacks
   could be corrected with no loss of features and the unworkable one
   would get workable.
   
Add a provision for double stack implementations

   RFC 2553 targets the dual stack systems, where there is one stack that
   implements both IPv4 and IPv6 protocols.
   
   If the RFC had a little comment telling that there is allowed to have
   systems with two isolated stacks, and that the IPv4 to IPv6 mapping
   may be absent on these systems, the non compliant implementations
   would become compliant and we would have some implementations
   compliant, non buggy and easy to work with AF-independently.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 22 Jun 2001 23:48:37 +0900

>   IPV6_V6ONLY default to on would have the same results.

	I really love to see this happen (polarity change is enough).
	also, if IPv4 mapped address support becomes optional (explicitly)
	to OS implementers it would be much better.

	However, we need to be careful - after looking into IPV6_V6ONLY (or
	IPV6_ACCEPTV4MAPPED) more closer, I came to realize some mess in
	setsockopt(2) behavior.

	for example:
	- A issues bind(:: port 80).  as IPV6_V6ONLY is turned on, it grabs
	  IPv6 traffic only.
	- B issues bind(0.0.0.0 port 80).  it grabs IPv4 traffic only.
	- now, turn off IPV6_V6ONLY on A.  what should happen?
	  (1) check if there's anyone listening to 0.0.0.0 port 80.  since
	  there is B, the setsockopt should fail.
	  (2) doesn't matter.  if there's B, IPv4 traffic goes into B as
	  B gives better match than A to any IPv4 traffic.
	  btw, there's no spec talks about how traffic should be routed
	  to which socket!

	there are A LOT of combinations we need to think about.

>   could be corrected with no loss of features and the unworkable one

	please clarify.  are you suggesting that, for getaddrinfo(3) AI_PASSIVE
	case:
	- on platforms that makes :: and 0.0.0.0 conflict on bind(2),
	  dual stack kernel config: getaddrinfo(3) returns :: only.
	  IPv6 only kernel config: getaddrinfo(3) returns :: only.
	  IPv4 only kernel config: getaddrinfo(3) returns 0.0.0.0 only.
	  this case includes linux.
	- on platforms that makes :: and 0.0.0.0 do not conflict on bind(2),
	  dual stack kernel config: getaddrinfo(3) returns :: and 0.0.0.0.
	  IPv6 only kernel config: getaddrinfo(3) returns :: only.
	  IPv4 only kernel config: getaddrinfo(3) returns 0.0.0.0 only.
	  this case includes OpenBSD, NetBSD, FreeBSD.

	or are you suggesting something else?  note that getaddrinfo(3) cannot
	look at IPV6_V6ONLY status on socket, so we cannot implement behavior
	depending on IPV6_V6ONLY status.

itojun

---

From: [email-masked]
Date: Fri, 22 Jun 2001 13:49:10 -0300

¡Hola!

 
> 	there are A LOT of combinations we need to think about.

My opinion on this is that IPV6_V6ONLY should be allowed to change only if
no bind or connect has been called on that socket.

> 	  this case includes OpenBSD, NetBSD, FreeBSD.

That's exactly what I was talking about. It's for me the least desired of
the proposed solutions, but it's enough for my purposes.

> itojun

					HoraPe
---
Horacio J. Peña
[email-masked]
[email-masked]
[email-masked]
[email-masked]

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 23 Jun 2001 03:38:47 +0900

>the proposed solutions, but it's enough for my purposes.

	if so, you will have problem in linux case...  i guess it is not the
	best route to change getaddrinfo(3) like above.  i guess it better to
	ignore certain error results.

	for example: on linux system, if you would like to turn IPV6_V6ONLY
	option on, you can only accept IPv6 traffic with getaddrinfo(3) loop.

itojun

-- the loop fails to accept IPv4 traffic on linux.
hints.ai_flags = AI_PASSIVE;
getaddrinfo(NULL, "80", &hints, &res0);
for (res = res0; res; res = res->ai_next) {
	s[i] = socket();
	if (res->ai_family == AF_INET6)
		setsockopt(s[i], IPV6_V6ONLY, on);

	bind(s[i]);
	listen(s[i]);
	i++;
}

---

From: [email-masked]
Date: Fri, 22 Jun 2001 16:38:57 -0300

¡Hola!

> 	ignore certain error results.

Yes, I agree that that's not the better solution, but if no one of the others
is accepted, that's just enough to solve my problems (it will generate anothers
and add complexity to something that's enough complex right now too)

> 	option on, you can only accept IPv6 traffic with getaddrinfo(3) loop.

If that changes were done, turning IPV6_V6ONLY on would not be frequently done.

					HoraPe
---
Horacio J. Peña
[email-masked]
[email-masked]
[email-masked]
[email-masked]

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 23 Jun 2001 04:42:03 +0900

>If that changes were done, turning IPV6_V6ONLY on would not be frequently d=
>one.

	if you want to see IPv4 traffic on AF_INET socket (so that we don't
	get confused by bogus source address, and generating bogus traffic
	when responding) you will want to do IPV6_V6ONLY.

itojun

---

From: [email-masked]
Date: Fri, 22 Jun 2001 16:51:25 -0300

¡Hola!

> 	when responding) you will want to do IPV6_V6ONLY.

Yes, maybe a flag telling that the old behaviour should be used would be need
to be added too.

					HoraPe
---
Horacio J. Peña
[email-masked]
[email-masked]
[email-masked]
[email-masked]

---

From: Mauro Tortonesi <[email-masked]>
Date: Sat, 23 Jun 2001 13:27:23 +0200 (CEST)

>         if(listen(listenfds[n], 10) != 0)

i am afraid i don't understand this portion of code. is getaddrinfo
expected to return one-and-only-one ready-to-be-bound address for
every AF when called with flag AI_PASSIVE set? there's nothing in
the drafts that states this:

   The AI_PASSIVE flag in the ai_flags member of the hints structure
   specifies how to fill in the IP address portion of the socket address
   structure. If the AI_PASSIVE flag is specified, then the returned
   address information must be suitable for use in binding a socket for
   accepting incoming connections for the specified service (i.e. a call
   to bind()). In this case, if the nodename argument is null, then the
   IP address portion of the socket address structure will be set to
   INADDR_ANY for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6
   address. If the AI_PASSIVE bit is not set, the returned address
   information must be suitable for a call to connect( ) (for a
   connection-mode protocol) or for a call to connect(), sendto() or
   sendmsg( ) (for a connectionless protocol).  In this case, if the
   nodename argument is null, then the IP address portion of the socket
   address structure will be set to the loopback address.  This flag is
   ignored if the nodename argument is not null.

from what i can guess, instead, the expected behaviour for getaddrinfo in
this case (AI_PASSIVE, AF_UNSPEC and SOCK_STREAM set) is to return a
ready-to-be-bound ::1 (ipv6) address. am i wrong?

if so, your code (which is truly AF-indipendent) is not RFC2553-compliant.
or better, the API specified by RFC2553 is not AF-indipendent.

>    IPv4 server (ie, duplication of code)

duplication of code is (and - if we're not gonna change the API draft in a
significant way - will always be) inevitable. there are MANY problems in
handling both ipv6 and ipv4 (or better, ipv4-mapped) traffic with a single
AF_INET6 socket, and most of them are related to security.

moreover, all the ipv6 compliant code that i have seen until now is full
of preprocessor switches like:

#ifdef INET6
/* code that handles both ipv6 and ipv4 */
/* this code is expected to make a heavy use of get{name,addr}info
 * and to avoid inet_{ntop,pton} when possible.
 */
#else
/* ipv4-only (traditional) code */
/* this code is expected to make heavy use of gethostby{name,addr}
 * inet_{ntoa,aton} etc...
 */
#endif

this is NOT AF-indipendent programming, as you have correctly pointed out.
that's the point. RFC2553 focuses only on ipv6 and ipv4, and its main
purpose is to extend the BSD API in order to make the transition to
ipv6 as painless as possible.

unfortunately, it has completely missed the point. by stating that it's
possible to receive ipv4 traffic with AF_INET6 sockets, RFC2553 has
introduced a BIG number of special cases which the programmers must
handle.

programming ipv6-compliant software in the RFC2553-compliant way is
quite a nightmare. if you have some experience in porting apps to ipv6
under linux (which is, as you state, a RFC2553-compliant OS), you sure
know what i am talking about.

>    good on that point and should have more work done on that.

you are absolutely right.

>                               Possible solutions

[...]

>    good mechanism to get things to start rolling but it's time to grow up

i would be the best thing to do, IMHO. if we wish to achieve true
AF-indipendence, we have to cut all the relationships between different
AF. AF_INET6 sockets shouldn't have any relation with AF_INET sockets.
it should't be possible to receive ipv4 traffic on a AF_INET6 socket.

>    problems that the IPv4 mapped addresses have.

that's another reason for removing IPv4 mapped addresses.

>    isn't prudent to throw them all at once.

i do not agree here. IPv4 mapped addresses should be deprecated and put in
disuse as soon as possible.

>    IPV6_V6ONLY default to on would have the same results.

no. all of this should also be deprecated, IMHO. AF_INET6 sockets should
be IPV6_V6ONLY and there shouldn't be any chance to change this behaviour.

>    could be corrected with no loss of features and the unworkable one

i don't understand you here. for a true AF-indipendent programming style,
getaddrinfo should return a ready-to-be-bound address for every AF.
for all those addresses, it should be possible to call bind without any
conflicts.

>    compliant, non buggy and easy to work with AF-independently.

that's nonsense. compliant stacks would not be AF-independent, but
quasi-compliant stacks would be.

IMHO, a best choice would be to re-define the behaviour of AF_INET6
sockets in order to cut all the relationships with ipv4.
AF-indipendence would be a great achievement.

-- 
Aequam memento rebus in arduis servare mentem...

Mauro Tortonesi			[email-masked]
Ferrara Linux User Group	http://www.ferrara.linux.it
Project6 - IPv6 for Linux	http://project6.ferrara.linux.it

---

From: Mauro Tortonesi <[email-masked]>
Date: Sat, 23 Jun 2001 13:29:20 +0200 (CEST)

> the proposed solutions, but it's enough for my purposes.

this should be the correct behaviour, IMHO.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 23 Jun 2001 13:42:33 +0200

In your previous mail you wrote:

                                 Horacio J. Peña

=> I understand your concern but this is a matter of taste and RFC 2553
chose one flavour. The basic issue is whether IPv6/AF_INET6 is a new
protocol/separate address family or not.
Obviously you'd prefer the split space model but RFC 2553 specifies a
merged space model, i.e. "IPv6 is not a new protocol, IPv6 is a new
version of the IP protocol". Of course one version must be represented in
the other so IPv4 is injected into IPv6 as mapped addresses. There are
pros and cons but RFC 2553 (and its revision which should be published soon)
makes the support of this mandatory.
You can just believe that AF_INET should be obsolete ASAP (this is not yet
the case but is a reasonable target, isn't it?)

Regards

[email-masked]

PS: the technical part was already discussed in the V6ONLY thread...

---

From: Francis Dupont <[email-masked]>
Date: Sat, 23 Jun 2001 14:35:23 +0200

=> I disagree. There is *no* security issue with IPv4-mapped addresses
as soon as one doesn't forget them.

=> no, there are some codes which are written without switches.
Of course they work only on systems where IPv6 is fully integrated.

=> I have ported many applications to IPv6 on BSD systems without
the problems you seemed to have encountered...

Regards

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sun, 24 Jun 2001 00:41:11 +0900

>as soon as one doesn't forget them.

	you were very lucky.  there are real attack scenarios, of course
	depending on configurations/stack implementations. 
	- if you implement from RFC2553/RFC2765 straight you will implement
	  a vulnerable implementation.
	- you can't assume programmers to be clever enough to check IPv4 mapped
	  address right.  the point of IPv4 mapped address support is to
	  decrease porting cost, into as simple as s/AF_INET/AF_INET6/ and
	  s/gethostbyname/gethostbyname2/.  if you did that, you will
	  get a likely-to-vulnerable userland code.  if you are careful
	  enough to put IN6_IS_ADDR_V4MAPPED everywhere, why not rewriting
	  it to use getaddrinfo(AI_PASSIVE) and multiple sockets?
	  so "as soon as ..." looks to me too optimistic.

	the following is KAME v6test configuration file that generates
	certain packets.  the following URL an (expired) draft on this problem.
http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-01.txt
	let me know if you know of of realworld implementation that are
	vulnerable (i believe there are a lot).  hope TAHI test to cover
	these cases :-)

itojun

#	$KAME: transition-abuse.conf,v 1.12 2001/06/23 15:40:30 itojun Exp $

# for more details/discussions, see
# http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-01.txt

# abuse of IPv4 mapped address.  under the following conditions:
# - the victim kernel stack does not check against IPv4 mapped address on
#   IPv6 native packet
# - the victim node runs udp echo service (inetd) on AF_INET6 socket
# the victim node can generate IPv4 broadcast responses mistakenly,
# leading to DoS.
#
# the example also tries bypass access controls and attack inside the firewall
# from outside (works nicer when 9.0.0.1 is an IPv4 firewall).
#
# you can attack any udp services by the same way.  udp echo service works the
# best for bad guys (or the worst for victims) since udp packet format is
# common to IPv4 and IPv6, and echo service is common for IPv4 and IPv6.
# therefore, the broadcast response will call for more responses (assumption:
# inetd does not check udp source port).
#	attacker -> victim: from ::ffff:10.255.255.255 to ::ffff:9.0.0.1
#	victim -> broadcast: from 9.0.0.1 to 10.255.255.255
#	more response: from many guys to 9.0.0.1
#
# RFC2553 does NOT comment on this case.  also, if the victim node supports
# SIIT (RFC2765) environment, the kernel stack is unable to filter out
# the packet.
#
# to protect your implmentation from the attack, there are multiple ways.
# the author recommends to implement the first three items at least:
# 1. do not support IPv4 mapped address on AF_INET6 API (not compatible with
#    RFC2553 section 4.2).
# 2. implement 2553bis-03 IPV6_V6ONLY socket option, and make the default value
#    to on (the default value suggested by the document is "off").
#    this has almost the same effect as the first bullet (if userland
#    code changes IPV6_V6ONLY manually, you will become vulnerable again
#    depending on userland program).   the change will make your stack
#    incompatible with 2553bis-03 section 4.2.  
# 3. drop any IPv6 native packet with IPv4 mapped address (incompatible with
#    RFC2765).
# 4. on EVERY userland application check the IPv6 source address, if it
#    embeds bad IPv4 address (impossible in reality, as it's hard to know what
#    is "bad" address, and there are millions of coders in different places)
#
# of course, KAME is not affected.  the implementation status differs
# between *BSD base systems (due to policy differences in *BSD).
# - KAME/OpenBSD: (1) and (3) - always safe
# - KAME/NetBSD: (2) and (3) - safe as long as userland programmer does
#	not change IPV6_V6ONLY
# - KAME/FreeBSD and KAME/BSDI: (3) - subject to API complications

# 00:28:37.148869 ::ffff:10.255.255.255.7 > ::ffff:9.0.0.1.7:  [udp sum ok] udp 0 (len 8, hlim 255)
# 			 6000 0000 0008 11ff 0000 0000 0000 0000
# 			 0000 ffff 0aff ffff 0000 0000 0000 0000
# 			 0000 ffff 0900 0001 0007 0007 0008 ebd0

v4mapped1:\
	:ip6-v4mapped1:udp1:
ip6-v4mapped1:\
        :ip6_flow#0:ip6_plen=auto:ip6_nxt=auto:ip6_hlim#255:\
        :ip6_src="::ffff:10.255.255.255":\
	:ip6_dst="::ffff:9.0.0.1":
udp1:\
	:udp_sport#7:udp_dport#7:

# one more abuse of IPv4 mapped address.
# bad guy pretends that the traffic is from the machine itself.
# if the victim node re-selects source address on the first udp echo response,
# we will see infinite IPv4 echo traffic on loopback interface
#
# note: most of recent BSD inetd rejects udp echo with source port = 7,
# so they are safe.  however, it is still true that we can bypass access
# control like this.

# 00:28:51.286261 ::ffff:127.0.0.1.7 > ::ffff:9.0.0.1.7:  [udp sum ok] udp 0 (len 8, hlim 255)
# 			 6000 0000 0008 11ff 0000 0000 0000 0000
# 			 0000 ffff 7f00 0001 0000 0000 0000 0000
# 			 0000 ffff 0900 0001 0007 0007 0008 77ce

v4mapped2:\
	:ip6-v4mapped2:udp1:
ip6-v4mapped2:\
        :ip6_flow#0:ip6_plen=auto:ip6_nxt=auto:ip6_hlim#255:\
        :ip6_src="::ffff:127.0.0.1":\
	:ip6_dst="::ffff:9.0.0.1":

# abuse of IPv4 compatible address (auto tunnel).  under the following
# conditions:
# - the victim kernel stack supports auto tunnel
# the victim node will generate IPv4 broadcast responses, leading to DoS.
#
# the example also tries bypass access controls and attack inside the firewall
# from outside (works nicer when 9.0.0.1 is an IPv4 firewall).
#
# with other IPv6 source address, bad guys can attack other IPv4 victim nodes
# anonymously.  however, IPv4 packet will always be tunnelled IPv6 packet
# (ip.ip_p == 41), therefore there will be no further traffic amplicfication.
#
# RFC2883 has a comment for embedded broadcast/multicast case, however,
# the set of rules does not make a perfect protection.
#
# KAME is not affected, since it does not support auto tunnels and it drops
# packets with IPv4 compatible address.

# 00:29:02.702670 ::10.255.255.255 > ::9.0.0.1: icmp6: echo request (len 8, hlim 255)
# 			 6000 0000 0008 3aff 0000 0000 0000 0000
# 			 0000 0000 0aff ffff 0000 0000 0000 0000
# 			 0000 0000 0900 0001 8000 6bbd 0000 0000

v4compat:\
	:ip6-v4compat:icmp6echo:
ip6-v4compat:\
        :ip6_flow#0:ip6_plen=auto:ip6_nxt=auto:ip6_hlim#255:\
        :ip6_src="::10.255.255.255":\
	:ip6_dst="::9.0.0.1":
icmp6echo:\
        :icmp6_type=echo:icmp6_code#0:icmp6_cksum=auto:icmp6_id#0:\
	:icmp6_seq#0:

# abuse of 6to4.  under the following conditions:
# - the victim node is configured as an 6to4 relay
# the victim node will generate IPv4 broadcast responses, leading to DoS.
#
# with other IPv6 source address, bad guys can attack other IPv4 victim nodes
# anonymously.  however, IPv4 packet will always be tunnelled IPv6 packet
# (ip.ip_p == 41), therefore there will be no further traffic amplicfication.
#
# 6to4 RFC suggests checks against embedded broadcat addresses, but it
# does not work in reality.  for example, 9.0.0.1 has no idea about topology
# within 16.0.0.0/8 topology, and has no idea about IPv4 broadcast address
# assignments.
# because of this, the following example tries to generate a packet to
# 16.255.255.255 by using 9.0.0.1 (6to4 relay) as trampoline, and hide the
# identity of the real attacker.
# if the admin at 16.0.0.0/8 is careful enough to drop directed broadcasts,
# the scenario does not work.
#
# 6to4 RFC has a comment for embedded broadcast/multicast case, as well as
# private address cases.  so if an implementation follows the suggestion,
# there is less chance for vulnerability.  but - beware, "less" chance, not
# "no" chance.  you are still vulnerable to some of the scenarios.
#
# KAME is not affected, as long as you don't configure your machine as 6to4
# relay.  if you configure KAME as 6to4 relay, you are vulnerable to some
# of the attack scenarios.

# 00:28:25.121083 2002:10ff:ffff::1 > 2001:900:1::1: icmp6: echo request (len 8, hlim 255)
# 			 6000 0000 0008 3aff 2002 10ff ffff 0000
# 			 0000 0000 0000 0001 2001 0900 0001 0000
# 			 0000 0000 0000 0001 8000 25b8 0000 0000

stf:\
	:ip6-stf:icmp6echo:
ip6-stf:\
        :ip6_flow#0:ip6_plen=auto:ip6_nxt=auto:ip6_hlim#255:\
        :ip6_src="2002:10ff:ffff::1":\
	:ip6_dst="2001:0900:0001::1":

# homework: try using these addresses in extension headers (routing header,
# home address option, whatever) and come up with more complex attack scnearios.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Mauro Tortonesi <[email-masked]>
Date: Sat, 23 Jun 2001 21:03:45 +0200 (CEST)

> => no, there are some codes which are written without switches.

of course there are. RFC 2553 has been written in order to minimize the
need for those switches.

> Of course they work only on systems where IPv6 is fully integrated.

i don't think so. switches are necessary in many cases (especially when
you want the same code to work on a traditional ipv4 system that uses
gethostby{name,addr} and on a new ipv6-compliant system which uses
get{addr,name}info).

> the problems you seemed to have encountered...

it depends from the application and the policy of the programmer.
i prefer not to modify existing ipv4 code (for compatibility with older
systems), so i generally use A LOT of switches. i also try to be careful
when handling common ipv6/ipv4 cases, and this make my work a little
harder.

i have seen that many programmers find difficult the process of porting
their apps to ipv6. i think that we should write a small informational
document that explains how to write good ipv6-compliant code.
itojun's "Implementing AF-indipendent apps" is a very good document.
however, it is obsolete and it doesn't give many informations.

---

From: [email-masked]
Date: Sun, 24 Jun 2001 04:25:55 +0900

>document that explains how to write good ipv6-compliant code.

	we really need to convince random book authors to update their
	programming examples, from gethostbyname() to getnameinfo()...

>however, it is obsolete and it doesn't give many informations.

	it is a bit dated, but the content should be still valid.
	do you have any suggestions for improvements?

itojun

---

From: Francis Dupont <[email-masked]>
Date: Sun, 24 Jun 2001 15:12:54 +0200

> Of course they work only on systems where IPv6 is fully integrated.
   
   i don't think so.

=> but we are sating the same thing. Perhaps we have different meanings
for "integration"?

   switches are necessary in many cases (especially when
   you want the same code to work on a traditional ipv4 system that uses
   gethostby{name,addr} and on a new ipv6-compliant system which uses
   get{addr,name}info).

   
=> I have the opposite policy so results are different. My target is
integrated systems where IPv6 is *not* optional, no more than IP is!

=> I have done one but it is more than obsolete now. But my target
is not AF-independence, it is IP version independence, even if a true
AF independence (i.e. codes which can work with ISO CLNP) is a plus.

Regards

PS: codes full of switches are at least unreadable...

---

From: Pekka Savola <[email-masked]>
Date: Sun, 24 Jun 2001 17:03:19 +0300 (EEST)

> integrated systems where IPv6 is *not* optional, no more than IP is!

That is a longer term goal.  Currently that only works in closed
environments.

From my viewpoint, the applications wrt. ipv6 support can be split into a
few categories:

 1) no ipv6 support
 2) ipv6 support togglable at compile time; if you use the app on
ipv4-only system, it won't even run (or ipv4 features don't work properly)
[for example xinetd]
 3) ipv6 support togglable at compile time; if you use the app on
ipv4-only system, ipv4 features work
 4) ipv6 support detected/configured at runtime

I don't consider applications to be integrated properly unless 4) applies.
I get the impression you are doing mostly 2).  As ipv4 isn't going away
any time soon, except in some closed environments like 3G mobile phones,
you have to be able to deal with all kinds of situations.

As said, I don't think this works yet in real life (consider: OS
distributions), and is counter-productive for the spread of IPv6 as
distributions cannot ship ipv6 ready apps just in case unless they're 3)
or 4) (because that'd hurt the operation of production software).

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Francis Dupont <[email-masked]>
Date: Sun, 24 Jun 2001 18:51:19 +0200

=> I disagree about the closed environments, this works everywhere but
this is very interesting only in environments where IPv6 is common.

   few categories:
   
    1) no ipv6 support

=> I support 4) only for some applications which are critical in case of
a crash (the kind of applications which are statically linked).

   I get the impression you are doing mostly 2).

=> more than 2), the IPv6 support is not togglable!

   As ipv4 isn't going away
   
=> as an IPv6 application is IPv4 capable on a RFC 2553 compliant system
I don't understand your concern.

=> my target is not the same, you want to provide an optional IPv6 support
(so 3) or 4) are needed), I want to provide an integrated IPv6 support
so the IPv6 support is *not* optional, there is only a possibility to
disable it for disaster recovery (because I run the code on the same
system I develop it, I don't use the traditional/expensive way with
two boxes).

Regards

---

From: Pekka Savola <[email-masked]>
Date: Sun, 24 Jun 2001 20:16:19 +0300 (EEST)

> this is very interesting only in environments where IPv6 is common.

These environments aren't that common, and unlikely to get so very soon
(speaking from OS perspective).

Currently systems are often ipv4 only.  One day they just don't magically
turn into ipv6 only boxes.  Dual stack is the way the world is going
towards.

> system I develop it, I don't use the traditional/expensive way with

Wanna bet your target isn't the most common case?

There's no way there's going to be a flag day when people just magically
get IPv6 enabled operating systems and never want to disable the support
again.

The transition process will be long, and API's and implementations will
have to cope with the fact.

3G, home gadgets etc. aside where there exists no ipv4 implementation (or
no implementation at all), you have like:

- Windows
- Linux
- {Free,Open,Net}BSD
- MacOS (=> FreeBSD)

I dare say these are at least 99% of potential IPv6 end-user systems.

End-users are the ones that will create the critical mass for IPv6, so
their needs must be looked after.

In corporate environments, you might also have, in addition to above,
systems like:

- Solaris, Tru64, HP-UX, AIX, etc. *UX
- Cisco, etc. router products (if not replaced with e.g. BSD)

All of these have existing, _working_ IPv4 network implementation.  No one
is going to just completely replace ipv4 with ipv6 one nice afternoon.  It
_will_ be necessary for the vendors to ship applications and code which
works in dual-stack configurations, and on systems where people are at
different stages in ipv4 -> ipv6 transition.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 25 Jun 2001 03:18:21 +0900

>system I develop it, I don't use the traditional/expensive way with

	for this part, people have different requirements depending on their
	standpoints.  for example, for *BSD-integrated KAME systems, it was
	strict requirement that we can let people happily replace IPv4/v6 dual
	stack kernel with IPv4-only kernel, without requiring recompilation of
	userland programs.  therefore, we decided we shouldn't use AF_INET6
	hardcoded, we should be using getaddrinfo loop instead.

	{Free,Net,Open}BSD ships compiled kernel binary with IPv6 support by
	default, which is good.  however, there are people who are doing
	embedded IPv4-only router product and such.  if we use AF_INET6
	hardcoded into uersland binaries, they will be in trouble.

	you may still be able to provide AF_INET6 socket layer, without
	IPv6 code, but it looked too hairy to me.

itojun

---

From: Francis Dupont <[email-masked]>
Date: Sun, 24 Jun 2001 20:33:03 +0200

=> I can't see where/when I said I'd like to get IPv6 only boxes ASAP?

   All of these have existing, _working_ IPv4 network implementation.  No one
   is going to just completely replace ipv4 with ipv6 one nice afternoon.

=> I don't want to replace IPv4 by IPv6 next month, I want to get
dual stacks as default ASAP. RFC 2553 is for dual stacks and
dual stack is the main transition tool.
 You can run IPv6 only systems if you want, there is no market for them
today and in general they are dual stack systems with IPv4 not configured
(which is a bit different than disabled). I have some of them for DSTM
demos (a case where the difference is important :-).
 The question is whether you believe in IPv6 or not: to ship systems
with optional IPv6 (i.e. dual stack) support is not a positive answer.

Regards

PS: (again) IPv6 is not a new protocol, IPv6 is the new version of IP.
If you believe in this (stronger than IPv6 itself) then you can really
understand the dual stack model (the integrated dual version model).
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Sun, 24 Jun 2001 22:19:00 +0300 (EEST)

> => I can't see where/when I said I'd like to get IPv6 only boxes ASAP?

If you port applications to ipv6-only system, it usually implies you
might want to actually use them too.  If application is ipv6-only, the
only way user cannot set the hell on loose is by shipping them in
ipv6-only system :-).

> dual stack is the main transition tool.

On dual stacks, user can usually disable ipv6. Examples of this are Linux
or BSD which nowadays ship ipv6-enabled by default.  However, some users
can turn it off intentionally or unitentionally.  As Itojun pointed out,
recompiling the user space is not usually an option.

So, porting applications so that they can handle both gracefully is the
way it should be done for about 5+ next years.

IMO, this must be kept in mind when defining the API's.

---

From: Jim Bound <[email-masked]>
Date: Sun, 24 Jun 2001 22:29:59 -0400 (EDT)

If you want to port in an IPv4 and IPv6 independent manner you will use
the tools as currently specified.  There is not protocol that will matter
besides IPv4 and IPv6 for at least the next 10 years.  The debate is not
technical but where the future will be.  This makes it hard.  API folks
have debated this the answer is as is specified now.

/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])

---

From: Jim Bound <[email-masked]>
Date: Sun, 24 Jun 2001 22:42:30 -0400 (EDT)

Hear Say, Hear Say,

Unless your going to name sources don't use them in debate.

Here is one that does use the RFC 2553 model as ISV.  Netscape.

Here are a list of vendors that support the merge Francis spoke of with
shipping products:

Solaris
HP-UX
IBM AIX
Compaq True64 UNIX
Compaq OpenVMS for TCP/IP

Also Netbsd and FreeBSD uses the model in 2553 since it was defined.

What programmers in what organizations are you talking about?

thanks

/jim

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 25 Jun 2001 14:24:34 +0900

>>>>> On Sun, 24 Jun 2001 22:42:30 -0400 (EDT), 
>>>>> Jim Bound <[email-masked]> said:

> Also Netbsd and FreeBSD uses the model in 2553 since it was defined.

Just to make it sure, if you mean "accepting IPv4 packets on an
AF_INET6 socket as IPv4-mapped IPv6 addresses" by "the model in
2553", Solaris does not follow the model, AFAIK.  Also, NetBSD disable
the model by default.

...however, those corrections do not affect the main stream of this
discussion.  We've fully, fully discussed this (in the apifolks list),
and have seen so many different views, and, as a consequence, could
not reach consensus on a single unified behavior.  Sad to say this,
but I don't think we'll be able to force vendors a particular behavior
based on a particular view of the model, like "the correct thing is to
deprecate IPv4-mapped IPv6 addresses"...

So, IMHO, the only feasible thing we can do now is to accept the
differences of various implementations, and make a guidance of how to
deal with the differences with a minimum effort.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 25 Jun 2001 14:37:05 +0900

>>>>> On Fri, 22 Jun 2001 16:51:25 -0300, 
>>>>> [email-masked] said:

> Yes, maybe a flag telling that the old behaviour should be used would be need

Then we'll see unreadable conditionals or ifdef tricks.  I'd rather
prefer just skipping possible errors against multiple calls of bind(2)
for each addrinfo element returned by getaddrinfo(3), as itojun
suggested.  If we take this approach, though, then we'll need one
constraint of getaddrinfo(3); it should return the AF_INET6 wildcard
address before the AF_INET one on those stacks that do not allow
conflict of an AF_INET6 wildcard socket and an AF_INET one.
(Otherwise, the already bound AF_INET socket would reject binding the
AF_INET6 one, and we would not receive IPv6 packets.)

					JINMEI, Tatuya

---

From: Mauro Tortonesi <[email-masked]>
Date: Mon, 25 Jun 2001 15:50:10 +0200 (CEST)

> understand the dual stack model (the integrated dual version model).

right. but this is not the real problem. the real problem is if
AF_INET6 family should be a catch-all extension of AF_INET or if
they should be an unrelated, being AF_INET6 a totally different type of
socket from AF_INET.

i vote for the second option.

---

From: Mauro Tortonesi <[email-masked]>
Date: Mon, 25 Jun 2001 15:44:38 +0200 (CEST)

> => but we are sating the same thing. Perhaps we have different meanings

maybe i have not well understood what you've written, or, more probably,
i haven't explained myself very well.

i was trying to say this:

RFC 2553 has been written in order to minimize the need for compile-time
switches. however, i don't think that we should focus on that minimization,
but instead on the definition of an API extension that can lead to
easier porting procedures.

as itojun has explained us, IPv4 mapped addresses present us many security
problems that the developers will have to handle. unspecified behaviour
for bind(2) - read my answer to itojun - will eventually produce platform
specific code.

RFC2553 does not address these problems. in the long run, this policy will
cause many headaches to the developers. so, minimization of the compile
time switches is not an absolute (or good-in-itself) target to be reached.

the solution for this problems may be reached, IMHO, by making the two
socket families AF_INET and AF_INET6 indipendent (orthogonal).

> integrated systems where IPv6 is *not* optional, no more than IP is!

we have different policies.

> AF independence (i.e. codes which can work with ISO CLNP) is a plus.

why don't you give us the url? it may be interesting.

> PS: codes full of switches are at least unreadable...

i don't think so. as soon as my patch for oftpd is integrated you'll
have one example. for now, refer to USAGI's inetd from netkit-base.
i find that the code is quite readable.

---

From: Mauro Tortonesi <[email-masked]>
Date: Mon, 25 Jun 2001 16:05:34 +0200 (CEST)

> deprecate IPv4-mapped IPv6 addresses"...

then why bothering to write RFC2553? if any ISV can do what he wants it
has been only a useless effort.

your arguments don't seem to have moche sense to me. rather, the
discussion should be re-opened and, as a result, a new proposed
standard should be produced.

> deal with the differences with a minimum effort.

this would be a BIG mistake, IMVHO. it is imperative to produce
a standard for BSD socket extensions, or we can forget the word
"code portability" for the next 50 years...

---

From: Mauro Tortonesi <[email-masked]>
Date: Mon, 25 Jun 2001 15:58:11 +0200 (CEST)

> What programmers in what organizations are you talking about?

i will not name any software here. for you, it will be enough to say
that i have seen a lot of not-very-well-ported opensource software.

---

From: Mauro Tortonesi <[email-masked]>
Date: Mon, 25 Jun 2001 15:15:22 +0200 (CEST)

> 	programming examples, from gethostbyname() to getnameinfo()...

how can you expect them do so, when there's so much difference between
the behaviour of the various TCP/IPv6 stacks?

HoraPe has explained us that on *BSD systems, you can have two different
sockets (one for AF_INET and one for AF_INET6) bound on the same port.
in this way you can use an af-indipendent programming style.
this is not true with linux. you have to use a single AF_INET6 socket
and listen on both incoming ipv4 and ipv6 connections.

draft-ietf-ipngwg-rfc2553bis-03.txt does not specify a specific behaviour
for bind. it's left to the implementors. i'd really like to know the
reason for doing so. IMVHO, this is a problem, because it will lead
developers to write platform-specific code and technical writers to
produce misinformation.

IMHO, draft-ietf-ipngwg-rfc2553bis-03.txt should specify what is the
correct behaviour for bind(2). i vote for the *BSD one: by having two
different sockets binding indipendently one from the other, we can
get rid of all the problems given by IPv4-mapped IPv6 address, and
have true af-indipendence. the IPV6-ONLY option and IPv4-mapped IPv6
address should not be deprecated, but their use should be unrecommended.
this policy would lead to the best result with only minor changes in the
draft and in the existing ipv6 implementations.

however, it's not so simple. in this way we have two indipendent protocol
families AF_INET and AF_INET6 (i would define them orthogonal), so
we should modify the behaviour of getaddrinfo.

in fact, when called with AI_PASSIVE flag set and AF_UNSPEC protocol
family, in a both ipv4- and ipv6-compliant system, getaddrinfo should
return two different results (::1 for ipv6 and 127.0.0.1 for ipv4).
moreover, calling getaddrinfo with AF_UNSPEC protocol family should
produce a result that's the sum of the results of two getaddrinfo
calls (one for AF_INET and one for AF_INET6).

getnameinfo does not need to be modified.

> 	do you have any suggestions for improvements?

some code examples would be useful. the paper doesn't explain how to
handle IPv4-mapped IPv6 address and the IPV6_ONLY option, for example.
however, as you have already said, the real problem is that there is
not a "Unix Network Programming"-like reference book covering ipv6
socket programming.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 25 Jun 2001 23:35:06 +0900

>the behaviour of the various TCP/IPv6 stacks?

	yes, that is the issue.  i was trying to suggest example be using
	getaddrinfo(3) loop, which should work for the most cases.
	if OS designers are sane enough to design bind(2) behavior and
	getaddrinfo(3) behavior with care, getaddrinfo(3) loop has a good
	chance to work in many cases.
	we need to document platform differences, of course.

	for exaplme, for server side, assume that the goal is to accept both
	IPv4 and IPv6 traffic.
	- if getaddrinfo(3) returns :: and 0.0.0.0, the code will work
	  for the following cases:
		bind(2) in any order is permitted, traffic accepted as
		necessary
		bind(2) of 0.0.0.0 prohibited after ::, AF_INET6 socket
		grabs IPv4 traffic
	  but not for the following case:
		bind(2) of 0.0.0.0 prohibited after ::, AF_INET6 socket
		does not grab IPv4 traffic (seems very broken to me)
	- if getaddrinfo(3) returns :: only, it will work for the following
	  cases:
		AF_INET6 socket grabs IPv4 traffic
	  but not for the following cases:
		AF_INET6 socket does not grab IPv4 traffic (getaddrinfo seems
		broken to me on this platform)

	(note to OS imlementers - so getaddrinfo(3) behavior has to be
	carefully designed consdidering your bind(2) and IPv4 mapped addr
	behavior!)

>draft and in the existing ipv6 implementations.

	I have been trying SO HARD to suggest it in api discussion group (which
	is a small group of people who contributed 2553bis-03 updates), but
	was rejected.  it is a holy war where there's no end.  one side
	advocates AF_INET6 only world, one side advocates AF_INET6/AF_INET
	splitted socket (or at least make the default behavior so).
	I'm of course in the second camp.

	in fact, as far as i understand, there's no good standard document
	on bind(2) interaction between two IPv4 sockets.  so defining it
	for IPv4/v6 interaction would be a big task.

>getnameinfo does not need to be modified.

	it is what i have been believed, but there are people believing in
	different behavior.

>handle IPv4-mapped IPv6 address and the IPV6_ONLY option, for example.

	aha, I was biased to independent AF_INET/AF_INET6 implementation ;-)
	as IPV6_V6ONLY support is still rare, not sure if it worth document it.
	thanks anyways.

itojun

---

From: [email-masked]
Date: Mon, 25 Jun 2001 13:26:17 -0300

¡Hola!

> besides IPv4 and IPv6 for at least the next 10 years.

10 years? If we're thinking so short-term something is bad. And if in 10
years there are other protocols we'll be better going full speed to the
AF independence.

I wasn't thinking myself being involved with future transitions, but
maybe my children or grandchildren will (and i'm not even married yet,
maybe my grandchildren get old enough to be involved with that in 50
years from now)

> The debate is not
> technical but where the future will be.  This makes it hard. 

The question is "Will IPv6 work forever?", if the answer is yes, then there
is nothing to talk about, if the answer is no (and I think that way) then
we should try to help the next transitions to be easier, using what we have
learned now.

Now we need to port several thousands of applications, in 50 years there will
be tens of thousands. If my grandchildren will be there, I'd like they could
work with the interesting stuff (designing the protocol, implementing the
stacks) and not with the boring, almost mechanical tasks (changing all INET6
for INET10)

We cannot think for only 10 years, 10 years is almost the time we've spent by now
in the IPv4 -> IPv6 transition, and it is just starting (ok, maybe now things
go faster and it will be complete in 5 years more, but yet we're at the start)
It's unwise to look so little in the future.

> API folks

It seems from the discussion that there is not a real consensus, but just a
"that's how it is being done, don't change it".

For the ones who prefer to just look a few years in the future, I'll say let
the IPv4 mapping enabled, but that should be done in a way that doesn't
generates problems for the people that prefer to look further.

So, while things don't change, there is a problem. And that problem ought to
be solved. I've proposed several ways to solve it and allow more choices to
the programmers and OS implementors.

					HoraPe
---
Horacio J. Peña
[email-masked]
[email-masked]
[email-masked]
[email-masked]

---

From: [email-masked]
Date: Mon, 25 Jun 2001 14:08:57 -0300

¡Hola!

> the drafts that states this:

That's not specified, as far as I can tell. It must return all the
sockaddr's to bind to. If with just one sockaddr is enough that could
be correct. But it's implemented normally as you described.

> ready-to-be-bound ::1 (ipv6) address. am i wrong?

It should be :: (ANY), not ::1 (loopback) and that could be done that way
if all the AFs can be mapped to IPv6, but if there are no mappable protocols
it should return the list.

> or better, the API specified by RFC2553 is not AF-indipendent.

I don't understand that.

> AF_INET6 socket, and most of them are related to security.

Yes, that's one of the things why I dislike programming for IPv6.

>  * inet_{ntoa,aton} etc...

That shouldn't be that way. If we wanted to handle old systems with no
get{name,addr}info support that should be tested by configure (or something
like that) and not based on INET6 (BTW, I prefer to write a little wrapper
around gethostby*, instead of the #ifdef's)

> introduced a BIG number of special cases which the programmers must

Yes, and I want to make that optional, so the special cases are not needed.

> know what i am talking about.

Yes, that's what has led me to work on this draft.

> it should't be possible to receive ipv4 traffic on a AF_INET6 socket.

I'd like to do that too, but there is yet too much work done based on
that mapping, so it's not reasonable to expect that being possible.

> disuse as soon as possible.

I'd like that, but that's just impossible.

> for all those addresses, it should be possible to call bind without any

I'm proposing as a (very undesirable) solution that getaddrinfo worked as
you explained before.

> quasi-compliant stacks would be.

I like better the noncompliant systems, but standard compliance is too
important to discard it. So I hope to change the standard to accept
the actually noncompliant behaviour.

					HoraPe
---
Horacio J. Peña
[email-masked]
[email-masked]
[email-masked]
[email-masked]

---

From: [email-masked]
Date: Mon, 25 Jun 2001 14:12:29 -0300

¡Hola!

> as soon as one doesn't forget them.

The problem is that not forgeting them means the same amount of work that doing
the port in the AF independent way. So the benefits of the IPv4-mapped addresses
(easy porting) get lost.

					HoraPe
---
Horacio J. Peña
[email-masked]
[email-masked]
[email-masked]
[email-masked]

---

From: [email-masked]
Date: Mon, 25 Jun 2001 14:19:09 -0300

¡Hola!

> however, it is obsolete and it doesn't give many informations.

It's not obsolete, but it's too terse. I've started working on a more
extense tutorial, but I've been with too much work and never ended it.
(and I don't even remember where the draft is)

					HoraPe
---
Horacio J. Peña
[email-masked]
[email-masked]
[email-masked]
[email-masked]

---

From: [email-masked]
Date: Mon, 25 Jun 2001 14:21:44 -0300

¡Hola!

> we should modify the behaviour of getaddrinfo.

No change to getaddrinfo is needed.

> calls (one for AF_INET and one for AF_INET6).

That's exactly how getaddrinfo works.

					HoraPe
---
Horacio J. Peña
[email-masked]
[email-masked]
[email-masked]
[email-masked]

---

From: [email-masked]
Date: Mon, 25 Jun 2001 14:39:23 -0300

¡Hola!

> 	I'm of course in the second camp.

So, it's a holy war, and no consensus has been achieved. Could we at least
allow both styles to work? Right now, that it isn't possible.

> 	for IPv4/v6 interaction would be a big task.

Maybe we should start writing that document? (although I see working for IPv4
a waste of time and effort)

					HoraPe
---
Horacio J. Peña
[email-masked]
[email-masked]
[email-masked]
[email-masked]

---

From: [email-masked]
Date: Mon, 25 Jun 2001 14:40:47 -0300

¡Hola!

> AF independence (i.e. codes which can work with ISO CLNP) is a plus.

When we get IPv10, will you prefer to change all your INET6 for INET10,
or just let the AF independent code do that by itself?

					HoraPe
---
Horacio J. Peña
[email-masked]
[email-masked]
[email-masked]
[email-masked]

---

From: [email-masked]
Date: Mon, 25 Jun 2001 14:47:49 -0300

¡Hola!

> => more than 2), the IPv6 support is not togglable!

In the "real world" you cannot say that. People will want to disable IPv6
for a long time.

> system I develop it, I don't use the traditional/expensive way with

The same.

					HoraPe
---
Horacio J. Peña
[email-masked]
[email-masked]
[email-masked]
[email-masked]

---

From: [email-masked]
Date: Mon, 25 Jun 2001 14:45:04 -0300

¡Hola!

> with optional IPv6 (i.e. dual stack) support is not a positive answer.

The problem is that IPv6 support will be optional for a long time, so
crossing that as not an option is not going to work.

> understand the dual stack model (the integrated dual version model).

I won't enter into that discussion...

					HoraPe
---
Horacio J. Peña
[email-masked]
[email-masked]
[email-masked]
[email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 26 Jun 2001 02:59:44 +0900

>>>>> On Mon, 25 Jun 2001 16:05:34 +0200 (CEST), 
>>>>> Mauro Tortonesi <[email-masked]> said:

> standard should be produced.

I admit I'm too pessimistic.  I of course agree that it would be great
if we could get a consensus on a single behavior by the reopened
discussion.  However, I would just like to point out that all the
discussion so far has already been raised, and the fact was that those
argument could not convince the people who have other opinions.
Itojun's bugtraq report is a good summary, but it still basically was
in the past discussion, which, again, could not convince everyone.

Yes, I admit that the fact we once failed on something does not mean
we'll fail in the future.  If you have a good enough point to make a
unified consensus, it would be really great.

> "code portability" for the next 50 years...

Agreed, but that's the reality, unfortunately, as far as I understand
the issue.

Sorry for the negative opinions.  I do not intend to discourage people
aiming to an ideal goal.  I'll be silent on this particular topic...

					JINMEI, Tatuya

---

From: Jim Bound <[email-masked]>
Date: Mon, 25 Jun 2001 23:00:32 -0400 (EDT)

And I have seen a lot of well written code that uses the API as is and
testing in various research centers.

We cannot change the base api for IPv6 every six months because new
programmers want new features.  what we need to do is take what we have
now and see what IEEE did with the latest rev they are working on and be
done with the base api.  then new programmers can add new thingees to it
tomorrow.  

As far as being able to accept v4mapped on AF_INET6 is supported by
Solaris as I said.  This is the view of tomorrow by most server vendors.
It is the default.  If one don't like it set the option to v6only and no
v4mapped will go over AF_INET6 in any manner.

Thats the plan.

thanks

/jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 25 Jun 2001 23:03:13 -0400 (EDT)

AF_INET6 will always permit the catch only model because its been a method
for over 6 years and customers have ported to that model.  We are not
getting rid of it now.  That is not going to happen.  The market has
spoken and the early adopter deployment customers will not have their code
broken.

As far as the default it is you will get v4mapped on AF_INET6 unless you
set v6only sockopt.

It is done it is written.

/jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 25 Jun 2001 23:06:08 -0400 (EDT)

This api is not going to standards track it is in informational RFC ONLY.
The real standard for the API will be done by the IEEE 1003 committee and
we are trying to get them to work with the IETF experts here.

They have adopted 2553-bis-03.txt style.  Its a done deal.

What is open for discussion is the 4+28 split for the sin6_scopeid

/jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 25 Jun 2001 23:19:42 -0400 (EDT)

we do not document product platform differences in the IETF.

but here is how the market will work.

the market picks a market leader.  today that market leader for most of IP
stuff for "Servers" is Sun Microsystems (not all but most if you look at
market share).  For the client its Microsoft.

If Microsoft uses v6only as default and does not adhere to 2553 most
likely thats the way all client apps will code.

If Sun uses v6only as default the same.

The rest of us are debating academics here and the majority of folks
believe the model we have is correct.  

Those viewing the purist API model of Address Family independence believe
IPv4 and IPv6 are separate protocols.  I for one think that is not true
and an error in their model.  IPv6 is an extension to IPv4.  Hence IPv6 AF
should be able to deal with IPv4 notation of IPv6 which is v4mapped.

Some others believe we have to worry about yet another real new protocol
such as OSI in the past.  I think that is nonsense for at least 10 years.
In Internet time 10 years will change so many things the API is the least
of our worries as Internet engineers IMO.

The other problem is some have built a complete dual stack IPv4 and IPv6.
If this was done it was a poor design and coding effort or a hack job to
get it done quick.  They are dead meat with the variant issues such as
crossover in kernel code base suppoting two stacks, code bloat, and all
the things an experienced (at least 10 years of programming) OS network
kernel engineer would not do.  These are just broken and the market will
force them to fix it.  All we ever ask for in any specs in this area is a
dual IP layer.

We should wrap up the 4+28 split merge the text with what IEEE 1003 has
done (which is going to be a lot of work for us authors fyi) and ship this
spec to the market.  

It is in all our interests if we stop this now.  We are at a stalemate and
stalemate means prior art wins IMO and that prior art is what the Base API
spec has preached and delivered for 6 years.

Otherwise we will have a shism here and if you think its bad now imagine
how bad it will be if the UNIX vendors go one way, Microsoft goes another
way, and the public domain stuff goes another way.

Just use 2553-bis-03 and be done with it.

Anyone who can't make it work please send the code that won't work and I
will bet those who support 2553-bis-03 will show you how it works.

But if its just a matter of style then thats another issue.

/jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 25 Jun 2001 23:25:47 -0400 (EDT)

With all due respect I don't care about peoples grandchildren.  I have
been doing this for 25 years.  10 years is tops anything lasts of this
nature.  So I don't care about after 10 years.  

/jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 25 Jun 2001 23:33:45 -0400 (EDT)

mapped addreses permit very large ISVs to treat all addresses as IPv6 and
one code AF.  IPv6.  And large ISVs tell their suppliers what they want
not the other way around.  So if database vendor X (who causes customers
to use computers for their business) tells sun, compaq, ibm, and hp and
others I want you to do it this way.  We will.  v4mapped permits them to
write their app to v6 once and only once.  And most ISVs don't care about
10 years from now.  They care about the $$$$$$ they will make this year
and next year and maybe the next 2 years.  And the most efficient cost of
doing business engineering way to do that.  And that is doing as the style
suggests in 2553-bus-03.  

Now who did we build the api for (we being ipng and IEEE participants)

1.  The goodness and social responsibility of man kind on planet earth.
No.
2.  For the computer science purist.
No.
3.  For the API purist maybe.
No.
4.  For someones grandchildren.
No.
5.  For people that built certain types of stacks.
No.
6.  For ISVs who want the most efficient API possible to support ipv4 and
ipv6 and permit the eventual phase out of IPv4.
Yes.

/jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 25 Jun 2001 23:43:43 -0400 (EDT)

IPv6 is not optional for 3GGP and I hope soon 3GGP2 and that is both sides
of the wireless coin requiring initial steps to IPv6.  If any vendor don't
have IPv6 running in their products this year they will not be permitted
to bid on a large business opportunities.  

/jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 25 Jun 2001 23:47:19 -0400 (EDT)

we did suggest that there be no default for v6only (in fact I suggested
it) and no one on either side wanted that.  thinking was even if one did
not get their choice then its better to have default for the users.

also this is not a holy war.  that was a mis-characterization.

in fact it was about 6 to 3 ratio in favor of v6only not being the
default.  or if there were 9 people only 3 wanted what you want.

/jim

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 26 Jun 2001 12:50:34 +0900

>not get their choice then its better to have default for the users.

	sorry to be picky.  is it correct that "no one on either side wanted
	that"?  Dave Thaler and i preferred "no default" at some point.

>default.  or if there were 9 people only 3 wanted what you want.

	at least the sentence conflict with the above "no one".

itojun

---

From: Jim Bound <[email-masked]>
Date: Tue, 26 Jun 2001 00:00:35 -0400 (EDT)

I know the ip stack inside and out.  if we have to go to IPv10 it will be
a new IP layer protocol and by definition a completely new AF type.
This is not the case for IPv4 and IPv6.  

/jim

---

From: Jim Bound <[email-masked]>
Date: Tue, 26 Jun 2001 00:13:37 -0400 (EDT)

hmmmm

/jim

> 	that"?  Dave Thaler and i preferred "no default" at some point.

I dont recall you responding to Tim, Jack and Eriks mail that no default
was very bad????????????  or Dave...............
 
> 	at least the sentence conflict with the above "no one".

No it does not.  two different cells in the truth table.  First statement
was for ifandonlyif one wanted NO DEFAULT.  But I don't recall yours and
Daves input and I could be mistaken I guess.??????

The second was the actual vote ifandonlyif you do not support the current
style of 2553 for 6 years.  It was only you, and dave and one other and
one person abstained from linux.  Actually it was many more who did not
want the v6only default I was being nice :---)

I just don't want to rehash this again and again.  

/jim

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 26 Jun 2001 13:18:05 +0900

>we do not document product platform differences in the IETF.

	just to be clear:
	i was suggesting to convince *book authors* to write more examples
	that use newer APIs, like getaddrinfo(3).  otherwise university
	students will learn about gethostbyname(3) forever.
	i never suggest IETF to document platform differences.

itojun

---

From: Jim Bound <[email-masked]>
Date: Tue, 26 Jun 2001 00:21:38 -0400 (EDT)

ack...

yes this needs to be fixed soon... sorry I missed that.........

/jim

---

From: Pekka Savola <[email-masked]>
Date: Tue, 26 Jun 2001 08:47:27 +0300 (EEST)

> As far as the default it is you will get v4mapped on AF_INET6 unless you

Wouldn't it be better to have the code potentially broken _now_, when
they're (very) _early adopters_, versus in 2-3 years when *everybody's*
code would break?

There are dangers to being an early adopter.  One of them is having to
rewrite code when it becomes clear that certain method, discovered during
the early adopter phase, is not going to work in the long term.

Better to break 1000 people's code now than 100000's in two years.

Or are we just playing time here?  If we can delay this enough, there's no
way we can get rid of mapped addresses in the next 10 years as it's going
to be used by ported apps more and more...

---

From: Pekka Savola <[email-masked]>
Date: Tue, 26 Jun 2001 09:39:06 +0300 (EEST)

> market share).  For the client its Microsoft.

[ I don't want to start an OS flamewar here (or anywhere else), but I
think this has to be clarified as it is important in your argumentation. ]

I'm sorry, but the above for servers seems to be explainable only by
assuming some interesting definition for "market leader".  Does it have to
be sold for an expensive price to qualify?

I don't have the detailed numbers handy, but a google search pointed to,
for example:

http://news.cnet.com/news/0-1003-200-4979275.html?tag=prntfr
(IDC Server OS market share in 2000)

Windows: 41%
Linux: 27%
Netware: 17%
Unix: 14%
Other: 2%

For example, Linux is about twice as popular as Solaris, HP-UX, Aix,
Tru64, etc. *combined*.

Granted these are for all kinds of servers, but give some figure for
popularity.

For small to medium-sized IP servers, I couldn't find any statistics but
I'd estimate:

40% BSD + Linux
25% Solaris
20% Windows
15% Rest

(personally I've a feeling that BSD+Linux should have a lot higher
percentage, but I tried to be unbiased)

Large IP servers (GB's of memory, etc.) are a small minority of all IP
server and should not spell out the way we're heading.

Lies, damned lies, statistics etc. aside, I think you can _at least_
safely assume that free operating systems are a major, if not dominant,
player in IP server markets.

Please open the windows of your office and look outside :-)

---

From: Robert Elz <[email-masked]>
Date: Tue, 26 Jun 2001 14:26:08 +0700

Date:        Mon, 25 Jun 2001 13:26:17 -0300
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | The question is "Will IPv6 work forever?", if the answer is yes, then there
  | is nothing to talk about, if the answer is no (and I think that way) then
  | we should try to help the next transitions to be easier, using what we have
  | learned now.

Unfortunately this requires crystal ball gazing.

I partly agree with Jim - not where he said that 10 years is nothing
(he seems to have forgotten that the IPv4 API that is being, only partly,
replaced here was invented 20 years ago already...) but do agree that we
cannot possibly plan now to handle the next set of problems.

The API transition for IPv6 largely concerns dealing with the different
address type - if/when we need a new protocol, the least likely thing of
all we have in IPv6 to be worrying about will be the address.

It may be that in some future protocol, applications will be required to
determine and set a flow label for all packets/connections - nothing we're
now defining would have applications doing that (even if we did, we have
no idea what form the flow label of that far future time might be).

Or, it may be that (as was proposed by PIP) applications need to discover and
set the route to the destination, with the "routers" being converted to being
just very fast forwarders, not running any routing algorithms at all.
Since we have no idea how that might be done, or what the result would look
like, we can't plan for that today either.

Of course, since I can imagine both of those already, they're most likely
not going to be the major turning point which requires a new IP level
protocol.   What it would be is likely to be something that now we can't
even guess at.   Given that, how can we possibly design an API today to
handle it?   (Unless we make the API so dumb, that the application gets
no control at all).

But more than that, it is perhaps more likely that the next revolution will
be transport protocol based, and it will be the API that deals with the
transport interface, rather than the part of it that deals with TCP or UDP
(or something entirely new) will be what needs to alter.   That is, perhaps
port numbers will be gone completely from a future transport interface, to
be replaced by something else completely different.   Who knows?

Because of all this, we cannot possibly make an AF independent API that
handles anything more than the protocols that we know of today.  Perhaps
we can also make it adaptable to a few things that we can guess now might
happen in the future (but for any of those that we now think likely, we'd
be better off to simply include them now, and avoid another transition
later - but there seems to be little we can agree on might be needed, beyond
what is in IPv6) so, even that doesn't seem productive.

And then given that, what is needed is to handle what we see as being
important to handle of today's protocols - and that means IPv4 and IPv6.
There's nothing else that almost any code which is going to use this API
is going to deal with (we could add CLNP or something, but the applications
that use CLNP and the applications that use IP are almost a disjoint set,
there's almost nothing to be gained by unifying them).

kre

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Jun 2001 10:15:15 +0200

=> this is Itojun's choice, he mentioned it because he knows
that it is not mine (:-).

=> ah! I understand where we disagree. For me the 5+ next years began
at the end of 1995 so the delay is expired... The IPv4 mapped stuff is
enough in my environment to catch legacy applications.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Jun 2001 10:27:16 +0200

=> I agree with the definition of the model... and any implementation
which doesn't follow it or disables it by default is not compliant.
We can't support every not compliant implementations just because
there are too many ways to be not compliant so your argument (we have
to support everything) is not admissible: AF independent coding style
is perhaps better but we haven't to enforce it.

Regards

---

From: Mauro Tortonesi <[email-masked]>
Date: Tue, 26 Jun 2001 10:18:27 +0200 (CEST)

> be correct. But it's implemented normally as you described.

unfortunately, on linux it's not.

> it should return the list.

of course. it's ::. excuse me.

> > or better, the API specified by RFC2553 is not AF-indipendent.

it was a reference to the AF-indipendent code you have presented in your
paper.

> the actually noncompliant behaviour.

i don't think we will reach consensus about this.

---

From: Mauro Tortonesi <[email-masked]>
Date: Tue, 26 Jun 2001 10:20:56 +0200 (CEST)

> a waste of time and effort)

why not?

---

From: Mauro Tortonesi <[email-masked]>
Date: Tue, 26 Jun 2001 10:13:57 +0200 (CEST)

> 	carefully designed consdidering your bind(2) and IPv4 mapped addr

why don't we include this as a note in RFC2553 addressing implementers?

> 	for IPv4/v6 interaction would be a big task.

i think that without the definition of a single standard behaviour for
bind and getaddrinfo, developers will have big problems writing portable
software.

i propose to add a paragraph to RFC2553 that explains the two allowed
behaviours for getaddrinfo and bind, and defining a constant that
can be examined to know the actual behaviour of our system at compile
time. something like:

#ifdef AF64_ORTHOGONALITY
/* the system behaves like *BSD */
#else
/* the system behaves like linux */
#endif

the same thing can be achieve in a better way if we define a new
read-only socket option:

getsockopt(sock, IPPROTO_IPV6, AF64_ORTHOGONALITY, &value, sizeof(int));

this works at run time.

---

From: Mauro Tortonesi <[email-masked]>
Date: Tue, 26 Jun 2001 10:20:12 +0200 (CEST)

> No change to getaddrinfo is needed.

then both the glibc and the USAGI implementation of getaddrinfo on linux
are broken.

> That's exactly how getaddrinfo works.

not on a rfc2553-compliant system like linux.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Jun 2001 11:23:35 +0200

=> this discussion is about to find a way to solve difference between
compliant stacks...

=> you can use it with the V6ONLY stuff.

=> this is the standard way but with the V6ONLY way you can use the
single socket (my favorite) or the socket per IP version (Itojun's
favorite). The user shall choice his own favorite or the one which
matches the application constraints.

=> oh no! Read the mailing list archive and don't reopen this discussion!
(the conclusion of the discussion is against your proposal which is not
as new as you seem to believe)

=> there is one but it is too old and the author is dead...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Jun 2001 11:26:15 +0200

> understand the dual stack model (the integrated dual version model).
   
   right. but this is not the real problem.

=> this is the real problem: your problem is in fact a consequence.

   the real problem is if

=> and RFC 2553 specifies the first option.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Jun 2001 11:54:57 +0200

=> some of us are old enough or learn by the hard way that to be
convinced to be in possesion of the Truth is not a strong argument.
Please don't reopen this discussion, to flood this mailing list
with boring messages about this won't be a successful strategy (:-).

Regards

---

From: Pekka Savola <[email-masked]>
Date: Tue, 26 Jun 2001 12:58:47 +0300 (EEST)

> => this discussion is about to find a way to solve difference between

Differences between _currently_ compliant stacks aren't the big issue
here.  Compliancy is specifically defined, and if a stack is compliant
there should be no interoperability problems.

Rather, what should be labeled as "compliant" and what not is what this is
about.

I doubt there's going to be "rough consensus" on this subject (AAAA vs A6
take two, anyone), so would it be possible to define two possible methods,
and easy means how the application developer could find out which his OS's
prefer and one that best suits his interests?

This way both parties _might_ be happy and we could end this and move on.
Else this very issue keeps popping up all the time and the API will be in
limbo forever.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Jun 2001 12:14:16 +0200

The problem is that not forgeting them means the same amount of
   work that doing the port in the AF independent way. So the benefits of
   the IPv4-mapped addresses (easy porting) get lost.
   
=> be serious, not all applications need access control (at least
clients don't need it and they represent more than 50%).
Not everything is like inetd or BIND...

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Jun 2001 12:18:46 +0200

=> I can't see a problem before IPv16 (:-)

PS: (silly?) suggession: remove AF_INET6 and use AF_INET for IP with
any version with injection of small address spaces in the larger one?
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Jun 2001 12:22:16 +0200

=> if you believe this you should spend more time on a NAT-friendly API (:-)

PS: don't be afraid, jump into the IPv6 world!

---

From: Markku Savela <[email-masked]>
Date: Tue, 26 Jun 2001 13:31:58 +0300

I just want to inject another viewpoint to this Unix-centric
discussion. I'm trying to specify how the IPv6 affects the socket API
in EPOC OS, and this is how it works (to bind a server socket):

   RSocketServ iSS; // Socket server handle (EPOC specific)
   RSocket iSocket; // Socket (roughly same as Unix)
   ...

   // Open Socket to be used for TCP
   TInt err = 
     iSocket.Open(
       iSS,              // socket server handle
       KAfInet,          // Protocol Family = INET
       KSockStream,      // Stream Socket
       KProtocolInetTcp  // TCP protocol
       );
   ... 
   TInetAddr addr;       // declare equivalent of sock_addr
   addr.SetPort(80);     // define port of the address

   // addr.SetAddress(KInetAddrAny);   // Listen only IPv4
   // addr.SetAddress(Kinet6AddrNone); // Listen only IPv6
   // addr.SetFamily(0); // default, listen IPv4 and IPv6

   err = iSocket.Bind(addr);
   ...
   err = iSocket.Listen(100);

For the rest of the code, it really doesn't matter whether bind was
IPv4 only, IPv6 only or allow both. (Except that with the first
variant, returned addresses are of KAfInet family, and for latter two,
address family is KAfInet6 and IPv4 is represented as IPv4-mapped.)

The key difference to the Unix is that, the existing address class
(TInetAddr) that is being used by IPv4 applications, is large enough
to hold also IPv6 addresses. Thus, with some reservations, existing
IPv4 application binaries have high probability of working as is also
with IPv6 connections (WEB browser being one example of such
applications).

IPv4 (as IPv4 mapped) is a subset of IPv6. As to issues like
src="::ffff:10.255.255.255", you have to handle this in IPv4 only
world, the same applies to IPv6. If your application doesn't want to
do these checks and if they are required, then it can refuse to anser
to all IPv4 or set this IPv6ONLY flag?

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 26 Jun 2001 14:23:39 +0200 (CEST)

> 	to OS implementers it would be much better.

In hindsight I agree that the default should have been different - forcing
applications to explicitly request use of IPv4-mapped addresses on AF_INET6
sockets.
But I suspect that folks have different opinions on the cost of changing
the default at this point in time :-(

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 26 Jun 2001 14:30:05 +0200 (CEST)

Jinmei,

> 2553", Solaris does not follow the model, AFAIK.  Also, NetBSD disable

What aspect of this do you believe is not there is Solaris?
Solaris by default accepts IPv4 packets on an AF_INET6 socket bound to
in6addr_any, so there must be some sutble detail that you're referring to.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Tue, 26 Jun 2001 15:41:51 +0300 (EEST)

> the default at this point in time :-(

What do you suspect the cost would be in 2-3 years?

I don't think the _current_ amount of IPv6 applications is that huge.
Almost all of these are simple tools by OS vendors, or open source.  I
don't think the change would be too big _now_, especially if the change
was detected by people who don't necessarily read RFC's (e.g. compilation
fail => forced to look at issue and spend an hour thinking about it).

IMO, we haven't passed the point of no return yet.  In 2-3 years we have.
And hindsight then won't be fun.

---

From: Mauro Tortonesi <[email-masked]>
Date: Tue, 26 Jun 2001 11:25:47 +0200 (CEST)

> to be used by ported apps more and more...

i think pekka is right here. unfortunately, as jim has pointed out, the
game may be already over now.

---

From: Mauro Tortonesi <[email-masked]>
Date: Tue, 26 Jun 2001 11:21:33 +0200 (CEST)

> As far as the default it is you will get v4mapped on AF_INET6 unless you

ok, but a good working of v6only sockopt can be obtained only if bind
and getaddrinfo behave like on *BSD. that's the point.

---

From: Mauro Tortonesi <[email-masked]>
Date: Tue, 26 Jun 2001 11:33:57 +0200 (CEST)

> AF_INET6 one, and we would not receive IPv6 packets.)

good idea. at least this behaviour for getaddrinfo (returning first :: and
then 0.0.0.0) could be specified. jim, what do you think?

---

From: Pekka Savola <[email-masked]>
Date: Tue, 26 Jun 2001 19:47:21 +0300 (EEST)

> the default at this point in time :-(

Another point here is security, especially if overloading mapped addresses
is allowed to continue (SIIT).

10 years ago all Unix vendors shipped about all services enabled by
default.  At some point people began to realize that it's an endless
battle if users/application writers must take full care of that.  So, wise
vendors have changed the default from "enable everything" to "enable
what's needed".  Some haven't gotten it yet, or depend too heavily on old
cruft, and are afraid to (possibly) break some customers who might
actually be running obscure_serviced.

I just hope we won't be doing the same mistake here.

---

From: Mauro Tortonesi <[email-masked]>
Date: Tue, 26 Jun 2001 18:58:48 +0200 (CEST)

> => you can use it with the V6ONLY stuff.

yes, but on rfc2553-compliant system you cannot have both an AF_INET
and an AF_INET6 socket listening on the same port.

> matches the application constraints.

the user can't choose anything! if he wants to listen both ipv4 and ipv6
traffic, he has to use an AF_INET6 socket with V6ONLY turned off.
no other choice.

---

From: Mauro Tortonesi <[email-masked]>
Date: Tue, 26 Jun 2001 19:40:29 +0200 (CEST)

> convinced to be in possesion of the Truth is not a strong argument.

i have always believed to be quite reasonable. i am certainly not in
posses of the Truth. no one is.

i have only said that it would be nice to have the possibility, for
the developer, of having two sockets (one AF_INET and the other AF_INET6)
listening on the same port traffic of two different protocols.

> with boring messages about this won't be a successful strategy (:-).

i have a deep respect for you and jim, who have ideas which are different
from mine. given this, don't you think that maybe this is a discussion
that could lead to interesting results?

we have only to keep the discussion within boundaries (i don't like
flame wars).

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 27 Jun 2001 07:57:34 +0900

>and an AF_INET6 socket listening on the same port.

	(just a picky comment)  RFC2553 does not talk about the behavior
	when try to bind(2) to both :: and 0.0.0.0 on the same port.  some
	systems reject bind(2) to 0.0.0.0, some does not.

itojun

---

From: Jim Bound <[email-masked]>
Date: Tue, 26 Jun 2001 23:50:33 -0400 (EDT)

I was directly speaking of implementations that make billions of dollars.
That is not Linux or BSD.

/jim

---

From: Jim Bound <[email-masked]>
Date: Wed, 27 Jun 2001 00:11:32 -0400 (EDT)

> in6addr_any, so there must be some sutble detail that you're referring to.

So does Compaq T64 UNIX.  

The point is that we are both shipping products that code is be developed
on.  That customers plan on using.  

I am not hearing strong enough arguments to break existing products on an
API that has 6 years and at least 100's of man years invested in the
design and the model for programming. From very bright people who have
written this code and shipped it into production operating systems. Thats
running code test par excellence in this community.  Also I have not heard
one ISV complain about the defaults.

I still think we made the correct decision.  I wish I could capture a 2
hour conversation Jack and I had on this and we both wrote our versions of
the code real time in a room.  Both presented all the arguments many we
are hearing now.  What the bottom line is thats supports the model in 2553
is that IPv6 is not an orthogonal address family to IPv4 but an extension.
The conceptual model of AF independence is an illusion if one considers
the transitions ISVs will have to define.  Some will force V6ONLY and we
added that option.  But the default is to treat IPv4 and IPv6 as a
cohesive abstraction that can be programmed inline once using only
AF_INET6.  The other view can be supported but yes to use it one must do a
setsockopt in the code.

I think we made the correct decision in 1995.

/jim

---

From: Jim Bound <[email-masked]>
Date: Wed, 27 Jun 2001 00:13:08 -0400 (EDT)

We have passed the point of no return as far as real products are
concerned.  A patch will not work on the OS's.  Nor is it justified.

/jim

---

From: Jim Bound <[email-masked]>
Date: Wed, 27 Jun 2001 00:19:30 -0400 (EDT)

this api was always based on bsd and still is.

/jim

---

From: Jim Bound <[email-masked]>
Date: Wed, 27 Jun 2001 00:45:43 -0400 (EDT)

> and an AF_INET6 socket listening on the same port.

Sure you can.  By using V6ONLY.  Thats the point of the option.  It is
just you must set it via setsocopt.

With V6ONLY you should be able to bind 0.0.0.0, 23 and bind ::,23 one
using AF_INET and the other AF_INET6.

Any IPv4 addreses entering the system will not be permitted to reach any
AF_INET6 socket.

This permits the shared port space model.
 
> traffic, he has to use an AF_INET6 socket with V6ONLY turned off.

That is correct because its not the default.

/jim

---

From: Jim Bound <[email-masked]>
Date: Wed, 27 Jun 2001 00:46:41 -0400 (EDT)

and it should not but an implementation that does not permit this is not
optimal.  we cannot force this behavior on implementors either.  thats why
it is not in 2553.

/jim

---

From: Jim Bound <[email-masked]>
Date: Wed, 27 Jun 2001 00:57:14 -0400 (EDT)

I "think" this is supported now.........but I need to check......

/jim

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Jun 2001 09:48:13 +0300 (EEST)

> optimal.  we cannot force this behavior on implementors either.  thats why

The API is informational document anyway.  It would be nice is this kind
of implementation gotcha's would be noted (no need to force a "proper"
behaviour) so all people would realize a possible problem area. :-)

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 27 Jun 2001 17:35:16 +0900

>>>>> On Tue, 26 Jun 2001 14:30:05 +0200 (CEST), 
>>>>> Erik Nordmark <[email-masked]> said:

> in6addr_any, so there must be some sutble detail that you're referring to.

Umm, then I may have misunderstood a former discussion about itojun's
very 1st bindtest questionnaire (around August 2000).  Perhaps I
misunderstood the fact that Solaris supported separate port space for
IPv4 and IPv6.  Sorry, I should've been more careful when talking
about others' implementation.

By the way, I'm still collecting the differences among implementations
(see the attached message, and the latest version contains a test to
see which type of socket accepts which type of pakcets.)  Could
someone try the test on Solaris (and of course other implementations
that has not been tested), and send the result to me, please?  Then
I'll never misunderstand such fundamental point.

					JINMEI, Tatuya

Subject: questionnaire: bind(2) (and IPV6_V6ONLY) behavior
From: JINMEI Tatuya / 神明達哉<[email-masked]>
To: [email-masked], [email-masked]
Date: Wed, 09 May 2001 08:24:43 +0900

Hello, (sorry for cross-posting).

I'm now looking at how each IPv6 implementation is friendly with
bind9, especially on the bind(2) system call ordering issues.

As the first step, I'd like to collect differences among
implementations using some test scripts.  So, if you have time, could
you spend some time to do the test on your system(s)?

The test tool is freely available at the following URL:

  http://orange.kame.net/dev/cvsweb.cgi/kame/kame/kame/bindtest/

and the results so far at

  http://www.kame.net/newsletter/20010504/

Here is a step by step instruction of the test:
- compile bindtest (see Makefile)
- run test.sh like this:
	% sh test.sh myplatform.txt
- send myplatform.txt to me, with exact indication of OS name/version
  number/build date/whatever

I hear that some systems have already supported a new IPv6 socket
option "IPV6_V6ONLY".  I'm particularly interested in the results on
such systems (the latest test.sh contains some tests with the option).

We'll basically put the results on the URL above, so that everyone can
refer to it.  If you can do tests but do not want to make the result
open, please explicitly say so when sending the result.

Thanks in advance,

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 27 Jun 2001 17:46:52 +0900

>>>>> On Tue, 26 Jun 2001 10:27:16 +0200, 
>>>>> Francis Dupont <[email-masked]> said:

> is perhaps better but we haven't to enforce it.

I don't oppose to your opinion above, but I don't intend to force
application programmers to be friendly with the "non-compliant"
systems.

I just want to understand the differences among the implementations on
the standpoint that
- there are surely "non-compliant" systems.
- they (the developers of the systems) have their own policy not to be
  compliant (e.g. security issues), and will never change their policy.
- still, I have to write some applications including these
  "non-compliant" systems for various reasons such as users' requests.

Perhaps the message of mine above sounded too strong, but I don't
intend to force my opinion on others as an admissible one.  I just
described the current reality, and am wondering how I can deal with
the differences as a single programmer who has to write code for both
"compliant" and "non-compliant" systems.

					JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 27 Jun 2001 17:17:19 +0200 (MEST)

> about others' implementation.

Solaris does effectively have a separate port space for IPv4 and IPv6
as well as supporting IPv4-mapped addresses on AF_INET6 sockets.

   Erik

---

From: Jim Bound <[email-masked]>
Date: Wed, 27 Jun 2001 14:42:21 -0400 (EDT)

I think having an appendix with issues and documenting them makes sense
too.

/jim

---

From: Mauro Tortonesi <[email-masked]>
Date: Thu, 28 Jun 2001 11:22:40 +0200 (CEST)

> 	systems reject bind(2) to 0.0.0.0, some does not.

ok. i will try to explain better my thoughts.

i don't want to change RFC2553. i think that V6ONLY is a very good feature
and may be sufficient to achieve a good af-indipendence. however, this
moves the focus on the behaviour of bind and getaddrinfo (which is not
described in detail in RFC2553 - i suppose because there is no consensus).

some implementations of bind(2) allow binding of 0.0.0.0 and :: address
on the same port, and some do not. i think that this may be a problem for
the developers which are working in multi-platform environments.

i'd really like to minimize the negative effect of this behaviour, but i
understand that there is not much that can be done about this.

i hope that we will come to a *BSD-like de-facto standard for the
behaviour of bind and getaddrinfo, but i wonder if having no standard
is even worse than having a bad standard (linux-like).

---

From: Mauro Tortonesi <[email-masked]>
Date: Thu, 28 Jun 2001 11:38:54 +0200 (CEST)

> optimal.  we cannot force this behavior on implementors either.  thats why

can't RFC2553 say something like "a good implementation SHOULD allow
binding of AF_INET and AF_INET6+V6ONLY on the same port"? such a
recommendation would not be a bad thing.

---

From: Mauro Tortonesi <[email-masked]>
Date: Thu, 28 Jun 2001 11:35:53 +0200 (CEST)

> using AF_INET and the other AF_INET6.

RFC2553 does not state this behaviour. in fact many implementations do
not allow to do this.

can you explain better? let's take two sockets, an AF_INET and an
AF_INET6+V6ONLY one. can i bind them on the same port only if i
bind first to 0.0.0.0 and then to ::? or is it also correct to bind
first to :: and then to 0.0.0.0?

RFC2553 is silent about this.

---

From: David Terrell <[email-masked]>
Date: Thu, 28 Jun 2001 12:59:50 -0700

> That is not Linux or BSD.

With all due respect, when you're talking about implementor eyeballs,
a huge percentage of unix server implementors learn based on whatever
linux supports, because that's what they have to play with when
they're learning something new.  And BSD is also very significant
in this rather powerful niche.  Both specifically because of their
price and because having the source available is a powerful learning
aid.

-- 
David Terrell           |  "Please note that calling an attacker
[email-masked]            |  'lame' is not an approved security method."
http://wwn.nebcorp.com/ |    - Benjy Feen
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jim Bound <[email-masked]>
Date: Fri, 29 Jun 2001 23:32:47 -0400 (EDT)

Hi Mauro,

Sorry for late response.  Also I could be out of it till July 16th going
on the road to do edu, evangelize, and meet offline with seriously
deploying IPv6 enterprises for a few weeks for Ipv6 Forum and U.S.
customer of IPv6.  But will try to check mail.  Don't wait for me to keep
talking...............if I don't respond I will if I have to when I get
back.......its good for engineers to go on the road once in awile and eat
their own dog food so they know if it still tastes good and has
nourishment :-----)

> RFC2553 does not state this behaviour. in fact many implementations do

That is unfortuneate.  I will make sure this is added to the IPv6 test
suites at UNH and ETSI and ask folks at Sun to test for this at
Connectathon.  KAME should be pretty much ready to test this too.

> RFC2553 is silent about this.

As I think I said before?

Consensus was to keep RFC 2553 silent about this on purpose.

You can bind either way as they will be treated as two distinct addresses
spaces within the IP protocol suite.

So 0.0.0.0,23  and ::,23 is fine because they are different address space
now if V6ONLY option is set.

I am thinking if others agree we could write all this up in appendix of
RFC2553+++bis+IEEE update....................

regards,
/jim

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 30 Jun 2001 12:34:05 +0900

>Connectathon.  KAME should be pretty much ready to test this too.

	http://www.kame.net/dev/cvsweb.cgi/kame/kame/kame/bindtest/
	checks this case.

itojun