[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 :

What about KISS? The current specification of ::FFFF:0:0/96 is
essentially that of a "magic value".
In a different view, which IMHO is right, what RFC 2535 says makes sense, is indeed simple, and is not magic. 
<<<
   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 [2].  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:

      ::FFFF:<IPv4-address>

   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. 


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.
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. 


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
::FFFF:0:0/96 prefix.

Have you a reference where he suggests to go that far?

In Itojun's document I know,
http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-00,
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 IPv4-only servers. 


Rémi