Some comments on draft-ietf-v6ops-v6onbydefault-01.txt

[Fernando Gont <fernando@gont.com.ar>]

Hi all,

I've had a look on draft-ietf-v6ops-v6onbydefault-01.txt , and have some 
comments on it.

In section 2, it says:

"  An application on this system is trying to communicate with a
   destination whose name resolves to public and global IPv4 and IPv6
   addresses.  The application uses an address resolution API that
   implements the destination address selection mechanism described in
   Default Address Selection for IPv6 [ADDRSEL].  The application will
   attempt to connect to each address returned in order until one
   succeeds. "

I think this para provides a hint on where the problem really lays. An 
application wants to use a service, not a specific node or a specific 
attachment point. Therefore, it shouldn't be involved in selecting the node 
or the network interface on which the server is provided.


In section 2.1, it says:

"  Fixing the destination address selection mechanism by adding such a
   rule is only a mitigating factor if applications use standard name
   resolution API's that implement this mechanism, and these
   applications try addresses in the order returned.  This may not be an
   acceptable assumption in some cases, as there are applications that
   use hard coded addresses and address search orders (DNS resolver is
   one example), and/or literal addresses passed in from the user."

I'm aware of this. However, I'd not say it's good practice to do this. So, 
well, if you have problems (delays, performance, whatever), for using a 
hard-coded address (for example), well, you should not be doing it!


In section 2.3, it says:

"  When the unreachability of a destination is obviated by the reception
   of an ICMPv6 destination unreachable message, the transport layer
   should make it possible for the application to deal with this by
   failing the connection attempt, passing ICMPv6 errors up to the
   application, etc... "

This one has to do with what I pointed out above: Should an application 
programmer be concerned with a (probably transient) error at the network layer.
Should, for example, a database programmer be knowledgeable on this stuff 
(i.e., at this level of detail)?


In section 2.3.2, it says:


"2.3.2 UDP Implications

   As noted in [HOSTREQS] section 4.1.3.3, UDP implementations MUST pass
   to the application layer all ICMP error messages that it receives
   from the IP layer.  As a result, proper handling destination
   unreachability by UDP applications is the responsibility of the
   applications themselves."

Note that, IIRC, the socket API pass ICMP errors only on *connected* sockets.



In section 3.2, it says:

"3.2 Poor IPv6 Network Performance

   Most applications on dual stack nodes will try IPv6 destinations
   first by default due to the Default Address Selection mechanism
   described in [ADDRSEL].  If the IPv6 connectivity to those
   destinations is poor while the IPv4 connectivity is better (i.e., the
   IPv6 traffic experiences higher latency, lower throughput, or more
   lost packets than IPv4 traffic), applications will still communicate
   over IPv6 at the expense of network performance.  There is no
   information available to applications in this case to advise them to
   try another destination address."

IMHO, this has to do with the design decisions of IPv6 (and IPv4). There's 
no knowledge about "nodes". So you cannot infer, from two IP addresses, if 
they correspond to the same node, or to two different nodes.

If there was a concept of "node", then this stuff would be handled by the 
network layer, in a transparent way.

So, strictly speaking, I don't think you need to address this issue. It has 
to do with the architecture itself, not with dual stacks or whatever.

There's a good theoretical discussion of this in RFC 1498. I think it 
provides very useful insights on all of the above stuff.

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org