comments on roy-v6ops-v6onbydefault-01

[Pekka Savola <pekkas@netcore.fi>]

Hi authors, the rest of the WG,

Thanks for putting together this document, and revising it extensively.  I 
believe it's of excellent quality and very important for the WG.  
Hopefully we'll have good discussion on this (and other operational 
aspects) in the second v6ops session in Vienna.

I've some comments on the draft. Four generic notes first:

- Sections 2.1 and 2.2 cover two rather interrelated problems.  There seems
to be some overlapping text, and I keep thinking of ways to handle/organize
these two that would seem a bit more fluent (even though it's rather good as is).

- Section 2.2 (and the last paragraph of 2.2.1) bashes the "all destinations
are on link by default" Neighbor Discovery rule pretty extensively, and I
agree with it.  However, I imagine there are legitimate reasons why people
thought it was a good idea.  We should get some idea of the tradeoffs (even
though they would not belong to this particular document -- see below).

- In Section 2 in particular, you bring out one example of default address
selection failing.  It would be very useful to try to analyze whether this
might happen in some other cases as well, and if not, state so explicitly. 
That way we can get the issues in the right proportions.  

It might also be interesting to know if there are any issues with
destination address selection in systems that don't (yet) impletement it
as specified in RFC3484 (it's more difficult than doing src address
selection..).  We're an operations WG after all ;-)

- There are some suggested modifications e.g. to ND, but there are no firm
conclusions section at least -- which would bring these points together, and
discuss pros and cons of these proposals.  Of course, one could argue that
these are out of scope of this document, and we should write (or urge ipv6
wg to do that) a short separate I-D on the pros and cons of such
modifications.

(I.e. it would be nice if it would be very explicit what we'd like to
do with to fix these issues -- if we know that yet)

substantial
-----------

   The Default Address Selection for IPv6 [ADDRSEL] destination address
   selection mechanism could save the application a few useless
   connection attempts by placing the IPv4 addresses in front of the
   IPv6 addresses.  This would be desired since all IPv6 destinations in
   this scenario are unreachable (there's no route to them), and the
   system's only IPv6 source address is inadequate to communicate with
   off-link destinations even if it did have an off-link route.

==> the comment (there's no route to them) is incorrect:
there _is_ a route to them -- the mandated
default IPv6 route pointing to the Ethernet interface!

Now, after thinking a bit this seems like a tricky issue, and we have to
be sure the terminology and the context is clear.  At least some
implementations add a default route of a very low metric (overridden by
everything else) to point to Interfaces like this.  Maybe some other
implementations do this differently?

The destinations are still unreachable, though -- but the reason is that
the Neighbor Discovery will fail to those addresses (note: this is much
worse than having no (effective) route at all, because it incurs a longer 
timeout).

   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 having trouble with about "address search orders (DNS resolver is
one example)".  Isn't destination address selection implemented in the
getaddrinfo which acts as an intermediary to the entries returned by the DNS
resolver?  AFAICS, if applications use standard name resolution API's, there
is no problem.  If they implement their own hacks (including the address
ordering), there are likely to be problems.

Or am I just misunderstanding the point here?

2.3 Transport Protocol Robustness

==> this section discusses transport protocols in general for one paragraph,
and dedicates the rest to TCP.  Should UDP discussed explicitly (it may 
be that there are fewer issues with UDP, though)?

3.2.1 Dealing with Poor IPv6 Network Performance

   There are few options from the end node's perspective.  One is to
   configure each node to prefer IPv4 destinations over IPv6.  If hosts
   implement the Default Address Selection for IPv6 [ADDRSEL] policy
   table, IPv4 mapped addresses could be assigned higher precedence,
   resulting in applications trying IPv4 for communication first. This
   has the negative side-effect that these nodes will almost never use  
   IPv6 unless the only address published in the DNS for a given name is
   IPv6, presumably because of this phenomenon.

   Disabling IPv6 on the end nodes is another solution. The idea would
   be that enabling IPv6 on dual stack nodes is a manual process that
   would be done when the administrator knows that IPv6 connectivity is
   adequate.

==> another solution could be inserting such preference for IPv4, but
giving even higher preference to _some_ IPv6, e.g. the site's own /48
prefix, the ISP's prefix, or whatever seems to be topologically
reasonable.

(Actually, one could possibly implement this by the more specific routes
and preferences thing, if it would be possible to disable the default 
route configuration phase based on some toggle.  But I'm not sure if this 
is the right approach.)

The problem here is that currently this seems to be a on/off thing; either *all*
(or at least a significant number of them) destinations that are used 
should be good enough, or no support at all can be enabled.   We need to fix
this, make it easier to adjust the preferences to a bit more fine-grained
than a binary toggle.

3.3.1 Mitigating Security Risks

==> please add a sentence or two on how you think the VPN software should
react in this case.  Deny unknown protocols by defaul unless there is a
configuration option to let them be?

5. Security Considerations

   This document raises security concerns in Section 3.3.

==> still, could you try to summarize the issues in section 3.3 in one or
two short paragraphs?  I think that would be a good practice.

editorial
---------

    It begins in Section 2 by examining problems within IPv6

==> s/It/This memo/

   succeeds.  Since the system has no off-link IPv6 routes, the optimal
   scenario would be if the IPv4 addresses returned were ordered before 
   the IPv6 addresses.  The following sections describe where things can

==> s/has no off-link IPv6 routes/has only on-link IPv6 connectivity/ 

   address.  Since [ADDRSEL] considers private addresses (as defined in
   [PRIVADDR]) of site-local scope,

==> s/considers/considers to be/ ?

 It is therefore important that the system quickly    
   determine that the IPv6 destination is unreachable so that the
   application can try the IPv4 destination.

==> s/try/fall back and try/ (it's already rather clear, but just to drive
the point home, as there are also issues with that fallback in the
applications side..)

   on-link until at least address resolution has failed, which is no    
   less than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER), plus

==> that's four seconds (first try, wait a second, plus 3 retransmissions,
after each 1 second delay [nowhere it is defined how long you have to wait
after the last retransmission, but I assume RETRANS_TIMER is a safe value]).
(same for 45 -> 60 seconds)

   If hosts need to communicate with on-link destinations, then then
   they need to be explicitly configured to have on-link routes for 
   those destinations.

==> reword this slightly and/or combine with the earlier paragraph so that
it is clear that this paragraph would be applicable in the scenario if the
onlink rule would be removed from the Neighbor Discovery.

   One problem is that default routes are not special.  The on-link
   assumption as stated in [ND] would have a host assume that all
   destinations are on-link when its default router list is empty.
   Clearly it shouldn't make this assumption if it has an off-link route
   that covers the destination and that route isn't a default route.
   The absence of a default route does not mean that destinations are   
   not reachable through more specific routes.

==> one might clarify even a bit further that this may be the case e.g. 
when a host is explicitly configured to have routes to only a specific 
set of addresses (e.g. the /48 prefix of the site).  We certainly have done
so as (one) security mechanism in IPv4 for e.g. backup and NFS servers.

   traffic), IPv6 packets could go through the network untouched if
   tunneled over a transport layer.  This could open the host to direct

==> s/layer/protocol, such as UDP/

   A similar problem could exist for VPN software.  A VPN could protect
   all IPv4 packets but drop all others onto the local subnet
   unprotected.

==> reword "drop all others .." slightly, e.g. "but not understand anything
about other protocols, and leave them send them on to the local subnet
unprotected."

   Enabling IPv6 on a dual stack node is only useful if applications
   that support IPv6 on that node properly cycle through addresses
   returned from name lookups and fall back to IPv4 when IPv6
 
==> s/cycle/loop/ (cycle is fine too, but loop is what I've heard the most
often and it's better to try to use the same terminology)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings