[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: One socket per AF (Was: 6to4 using ::FFFF:0000:0000/96...)
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.
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".
it can be achieved without messing with address format,
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
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
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.