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

From: "Roy Brabson" <[email-masked]>
Date: Wed, 27 Jun 2001 09:22:26 -0400

From my reading of 2553bis, there seem to be at least two ways this
can be implemented (not counting the semantic changes being proposed):

- The IPv4 address space is part of (a subset of, actually) the IPv6
  address space.  With this approach, 0.0.0.0 can be thought of as a
  more specific address in the combined address space than the IPv6
  unspecified address ::.  If an application binds to ::, then it will
  receive all traffic (IPv4 and IPv6).  Only if IPV6_V6ONLY is set
  will it not receive IPv4 traffic.

  A second application can bind to a specific IPv6 address (say fec0::1)
  and begin to receive traffic for that specific IPv6 address while all
  other IPv6 traffic is received by the application which bound to ::.

  In the same manner, a second application can bind to 0.0.0.0 and it will
  begin to receive all IPv4 traffic, while the IPv6 traffic continues to
  be received by the initial application.  This happens irrespective of
  whether IPV6_V6ONLY is set. The basic rationale behind this is 0.0.0.0
is,
  when encoded in IPv6 format (::ffff:0.0.0.0), is a more specific address
  than ::, much in the same way that fec0::1 was in the example above, and
  should be treated in the same way.

- The IPv4 address space is separate from the IPv6 address space.  When an
  application binds to ::, it is the equivalent of binding to the IPv6
  unspecified address and the IPv4 equivalent, 0.0.0.0.

  As before, a second application can bind to a specific IPv6 address (say
  fec0::1) and begin to receive traffic for that specific IPv6 address
  while all other IPv6 traffic is received by the application which bound
  to ::.

  However, a second application can only bind to 0.0.0.0 if the first
  application has set IPV6_V6ONLY.  This is because the first application
  is already (conceptually) listening on 0.0.0.0.

2553 doesn't seem to specify which is the correct behavior.  We've
implemented the second approach, and it sounds like several others
(Jim included if I'm reading it right) have as well.

Roy

On Wednesday, 06/27/2001 at 12:45 AST, Jim Bound <[email-masked]>
wrote:
> > > => 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.
>
> 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.

--------------------------------------------------------------------
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: Vladislav Yasevich <[email-masked]>
Date: Wed, 27 Jun 2001 10:23:23 -0400

I tried to resist jumping in here, but I guess it's time...

1.  Protocol independance is an extremely rare ideal (I
would not call it a myth precisely).  Having ported a bunch
of simple and complex application, I can say now that only
about 5% of them were really protocol independent.  Most
apps do all sorts of loging, setting socket options, etc...
that is really difficult to not have even one
	if (af == AF_INET)
	...
	else if (af == AF_INET6)
	....

If you have even one of these, you loose protocol independence,
so the ideal goes out the window.

2.  All the talk about specifying bind() constraints should not
be specified in RFC.  It may be considered as an Appendix, but it
is very difficult to get all of the behavior from all different systems.
Jinmey's collection of results from the bind test program Kame guys
have created shows a lot of different way of doing this.  Documenting
this would be nightmare.

3.  As Tim already pointed out, changing polarity of V6ONLY would
break some things.  A quick glance through my code shows at lest 10 apps
that would have to be ported again (for the 5th time).  As an implementor,
NO THANKS.

I am in the camp of people who think the currenlty specified
behavior should be kept.  It works and allows flexibility to
try for protocol independence (which will be hard to achieve in
complex applications even if polarity of V6ONLY changes).

I personally prefere a single socket approach to writing apps.

-vlad

P.S.
I have actually once implemented once the 0.0.0.0 and :: on the
same port without any socket options.  This worked for a while
untill we put a load on the system though port-trollers.  This 
cause all sort of havok as these port-torllers started stealing
traffic from applications that did not have 2 sockets and expected
V4 traffic on V6 wildcard.  I don't know if anyone else has
seen this.
++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tel: (603) 884-1079
Compaq Computer Corp.		Fax: (435) 514-6884
110 Spit Brook Rd ZK03-3/T07
Nashua, NH 03062
--------------------------------------------------------------------
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: Thu, 28 Jun 2001 01:49:23 +0900

>so the ideal goes out the window.

	i'm just curious, but how come did you get so many "if-else" clause?
	for example, i grepped through the source code like "grep -l AF_INET".
	in some of NetBSD source code I had on my laptop.
	- finger, fingerd: totally AF independent
	- ftp, ftpd: AF dependent (PORT, PASV or EPRT, EPSV)
	- telnet, telnetd: AF dependent, but not the fundamental part
		(source routing for client side, IP_TOS setting for daemon side)
	- tftp, tftpd: tftp is clean.  in tftpd there's one switch statement,
	  which can easily be avoided by getaddrinfo/getnameinfo (will do).

	since it is a bit off-topic, please respond privately if you prefer.

itojun