[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 a different view, which IMHO is right, what RFC 2535 says makes
sense, is indeed simple, and is not magic.
What about KISS? The current specification of ::FFFF:0:0/96 is
essentially that of a "magic value".
The API also provides a different type of compatibility: the ability
for IPv6 applications to interoperate with IPv4 applications. This
feature uses the IPv4-mapped IPv6 address format defined in the IPv6
addressing architecture specification . This address format
allows the IPv4 address of an IPv4 node to be represented as an IPv6
address. The IPv4 address is encoded into the low-order 32 bits of
the IPv6 address, and the high-order 96 bits hold the fixed prefix
0:0:0:0:0:FFFF. IPv4- mapped addresses are written as follows:
These addresses can be generated automatically by the
getipnodebyname() function when the specified host has only IPv4
addresses (as described in Section 6.1).
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.>>>
Since applications *MAY* use PF_INET6 to send packets to IPv4 nodes
(IPv4 meaning here "IPv4-only"), dual stacks *SHOULD* better send these
packets in IPv4 when IPv4 link interfaces are available: if sent in
IPv6, they are likely to find no paths to their destinations; in IPv4
they would normally reach their destinations.
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.
According to some, whenever that magic value is encountered,
something extraordinary shall happen, such > as switching to a different network level protocol. This is a recipe
for trouble, because it breaks the "keep it simple" rule.
What we have for every other address prefix is simple. V6 packets are
sent using V6, and the outgoing interfaces are chosen according to V6
routing rules. In a host, the header of incoming V6 packet is
checked, and unicast packets are rejected if the particular
destination address is not recognized as a valid address for the
receiving interface. In a router, packets are routed according to
routing tables, and if no route is configured packets are dropped.
Some routers may also perform ingress filtering. Anything more
complex than is guaranteed to cause problems.
In my understanding all of this is right.
It would need however to be completed by something about v4-v6 coexistence.
What about something like: <<<
Packets the source or destination of which is IPv4 only must be: (1) in
IPv4 on links that are IPv4-only or IPv4 and IPv6; (2) in IPv6 on
IPv6-only links, with IPv4 addresses in mapped format.>>>
Note that, to route IPv6 packets the destination of which is mapped
IPv4, the 0::/64 routing prefix should not be artificially considered as
invalid by routers.
The typical case where this is useful is within multi-subnet sites where
there are IPv6 only hosts, and where access to the IPv4 Internet is via
CPEs that support NATv6-v4. >>>
I think that Itojun was right, and we should simply deprecate the
Have you a reference where he suggests to go that far?
In Itojun's document I know,
the proposal, in 2003, was to avoid mapped addressses "on the wire"(not
at socket interfaces).
As far as I know, this document became obsolete without Itojun himself
insisting on the subject.
While it identifies some threats in some configurations, it doesn't
conflict, in my undersatnding, with mapped addresses on the wire in some
other useful ones.
One of these other configurations happens to be very pertinent (and IMHO
completely Kiss :-) ) for IPv6-only client hosts to be able to reach