Re: One socket per AF (Was: 6to4 using ::FFFF:0000:0000/96...)

[Rémi Després <remi.despres@free.fr>]

Christian Huitema wrote :
> > In the different view, letting applications to have only one socket
> >  interface is *simpler* than obliging them to know whether the IP 
> > layer works in IPv4 or IPv6.
Right. Let's continue to clarify the issue.


> Most "simple programming" is achieved using high level constructs 
> such as RPC or Web interfaces. The fraction of programs written on 
> the "socket" API tend to be written by sophisticated developers who 
> like "bare to the metal" constructs.
In my view, that's indeed appropriate.

But IMO conformance of dual stacks to RFC 2553 sec 3.7 doesn't make them
less "bare to the metal" (it just says that a v4 destination has to be 
handled by the v4 stack if there is one operational, even if this v4 
destination is presented in 128 bit format.)

> But even if a single listening was a goal,
In my reading of RFC 2553-3.7, this *was* a goal, and a good one.

> it can be achieved without messing with address format,
For an IPv6-only application, listening for an address without being 
concerned whether the remote host is IPv4 only, as RFC 2553-3.7 permits, 
isn't IMO "messing with address formats".

On the opposite, obliging an IPv6-only application to handle in any way 
the v4 Address Family is IMU mixing levels.
Permitting to express a 32 bit address in a 128 bit format is after all 
a simple idea.

> simply by avoiding early binding of the socket to a specific address 
> type, and then using specific addresses in their native formats 
> whenever necessary.
Yes it works but, again, these applications can hardly be considered as 
IPv6-only.(To be *really IPv6-only*, applications do need RFC 2553-3.7 
conformance of dual stacks.)
Note that applications that have this behavior, and with it work on dual 
stacks that don't conform to 2553-3.7, can keep this behavior when their 
stack is patched to conform.

In summary, dual stacks that don't conform to RFC2553-3.7 should be 
corrected :
 1. No adverse effect is predictible, on any existing application.

 2. Some weird phenomena as observed recently would no longer appear.

 3. The bottom line will be that:
- Server applications that have IPv4 sockets, or that have unspecified
address family sockets, will receive IPv4 addresses on them.
- Server applications that only have IPv6 sockets will receive IPv4
addresses in mapped format (without having to recognize them).
- Client applications that, on IPv6 sockets to dual stacks, use remote 
host addresses that happen to be IPv4 addresses automatically activate 
the IPv4 part of their dual stacks.

This seems to me the right logic to have.
Changing that would be a step backward.


Rémi