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

From: Fernando Gont <[email-masked]>
Date: Mon, 05 Apr 2004 23:01:02 -0300

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: [email-masked] || [email-masked]