Subject: comments on roy-v6ops-v6onbydefault-01

From: Pekka Savola <[email-masked]>
Date: Sun, 13 Jul 2003 15:54:48 +0300 (EEST)

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

---

From: Alain Durand <[email-masked]>
Date: Mon, 14 Jul 2003 04:55:14 -0700

On Sunday, July 13, 2003, at 05:54 AM, Pekka Savola wrote:

> Thanks for putting together this document, and revising it extensively

Thank you for reading it carefully.

> .  I

We have been trying to find a better way without much success. 
Suggestions welcome.

> though they would not belong to this particular document -- see below).

Yes. I talked about this with Erik Nordmark, we have to build a case 
that present
both the useful side and the harmful sides of this on-link assumption.
For now, it seems the the useful side is pretty narrow. We will do that
in the next revision of the draft (or in a separate draft)
> That way we can get the issues in the right proportions.

The default address selection rules are so complex that is is difficult 
to
do a full analysis. We stumbled on this one while doing real deployment.

> destination address selection in systems that don't (yet) implement it

Well, we first discovered the issue on a system that was not (yet) 
implementing
the default address selection. But as this is (was) not standardized 
anywhere,
I'm not sure if there is any value in analyzing this any further...

> wg to do that) a short separate I-D on the pros and cons of such

This is by design. We first would like to report to the ops community 
that
there are serious problems. One we will agree on that, it will be time
to make recommendations.

> do with to fix these issues -- if we know that yet)

I'll suggest to ways to go forward during the meeting.

> substantial

You're right. Text need to be clarified a bit.
> be that there are fewer issues with UDP, though)?

Good point. We made some measurement with UDP, it is not as severe as 
TCP
but it is far from acceptable.

> prefix, the ISP's prefix, or whatever seems to be topologically

If and only if there is a simple way to express the list of "reachable" 
prefixes...
Then you have the issue to distribute that list to all the internal 
nodes... tricky.
For example, in our deployment, we use a number (10-20) /48 6to4 
derived prefixes
and the list keep expanding.

> this, make it easier to adjust the preferences to a bit more 

I'm not sure how to achieve this.... See previous comment.

> configuration option to let them be?

It is not clear at all to me what should be done.  One could sent all 
unknown packets
either to the bit bucket or to the other side of the VPN... Not sure 
which is best.

> two short paragraphs?  I think that would be a good practice.
ok for next revision. Thanks again for the detailed review.

	- Alain.