v6onbydefault-00 comments

[Pekka Savola <pekkas@netcore.fi>]

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

1) I think the document needs to be more specific about the scenarios where
the different issues exist in, and what is the result of the fix (+remainder
issues).  That is, the document should also give a big picture of the
different issues and how they connect with each other.

I'm not sure about the best way to do it, but one thing to consider would be
whether one could try to formulate a brief and concise problem statement
(after the introduction to the issues etc.) of the problem.

2) Should the discussion of AI_ADDRCONFIG go in?  If so, I might be able to
try to hack up some text after done..

3) I don't quite understand the last paragraph of section 2.1:

  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. Such
   applications will obviously be subject to whatever connection delays
   are associated with attempting a connection to an unreachable
   destination.  This is discussed in more detail in the next few
   sections.

==> first, destination address selection is done w/ getaddrinfo(), so if
apps use that (after an added rule), they're OK (so, isn't the meaning of
the first sentence reversed?)

==> isn't the DNS resolver implementation itself quite bit of a special case
here?

==> last, I don't really understand the point about literal addresses; if
the user specifies an address, he gives just one of them.  It either works
or doesn't; there is no selection among them.  If the user gives the IPv6
address, the problem will be in ND, as an already documented problem. 
If the user gives the IPv4 address, it works.

4) This document contains a rather long description of on-link assumption
issues.  Could this be summarized a bit more, inserting a normative
reference to the on-link assumption document?

5) I don't remember that the second paragraph of section 2.2.1 in the onlink
document?  I'm not sure if I understand the problem correctly:

 - if there is an entry in default router list, on-link assumption is not
done, and all the packets w/o more specifics go to the router, and
 - if there is not an entry in the default router list, but there are more
specific routes through a router, the on-link assumption is valid for the
packets which do not match the more specific routes.  

This seems like the desired behaviour.  Did I miss something?

6) Transport protocol robustness section has:

It should abort a
   connection in those states when receiving any ICMPv6 Destination
   Unreachable message.  It should make this distinction when a
   connection is in any other state.

==> shouldn't the should in the last sentence actually be "should not" ?

==> one should maybe consider the other protocols, such as UDP and SCTP here
as well -- or at least list them as items for further study :-)

==> would it make sense to also discuss issues relating to blackhole
problems, i.e., packets getting discarded somewhere without feedback e.g.
using ICMP?  There is pretty much nothing to do then, but that should
probably be mentioned explicitly as an existing problem..

7) 3.2.1 Dealing with Poor IPv6 Network Performance

... one other way to deal with this could be something like:

  Another approach could  be to restrict IPv6 just to a smaller, better
  working address range, e.g., the internal network or nationally
  interconnected networks, but this can't be a long term solution.

  Regardless of whether the user selects a short-term fix to the problem,
  the first imperative should be working on enhancing the performance of 
  IPv6.

8) The application robustness section should probably refer to the
application transition guidelines, as it specifically describes this
problem.  This section can probably be reduced in length a bit.

(note: s/connection results/connection may result)





semi-substantial
----------------

Abstract

   This document discusses problems that can occur when dual stack nodes
   that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4
   and IPv6 environments.  The problems include application connection
   delays, poor connectivity, and network security.  Its purpose is to
   raise awareness of these problems so that they can be fixed or worked
   around.

==> there has been some confusion around this document at some point, so
maybe could try to add something like (+Introduction too):

  The purpose of this document is not to try to specify whether IPv6
  should be enabled by default or not, but to raise the awareness of
  the potential issues involved.

....

   Consider a scenario in which a dual stack system has IPv6 enabled and
   placed on a link with no IPv6 routers.  The system is using IPv6
   Stateless Address Autoconfiguration [AUTOCONF], so it only has a
   link-local IPv6 address configured.  It also has a single IPv4
   address that happens to be a private address as defined in
   [PRIVADDR].

==> it would be useful if one could generalize a bit from this..

   To allow applications to correctly fall back to IPv4 when IPv6   
   packets are destined beyond their allowed scope, the devices
   enforcing the scope boundary should send ICMPv6 Destination
   Unreachable messages back to senders of such packets.  The sender's

==> s/should/must/ ?

  An example of such a situation is a node which obtains IPv4
   connectivity natively through an ISP, but whose IPv6 connectivity is
   obtained through a configured tunnel whose other endpoint is     
   topologically such that most IPv6 communication is done through
   triangular routes.  Operational experience on the 6bone shows that

==> s/triangular routes/triangular IPv4 topology/ ?

   A similar problem could exist for VPN software.  A VPN could protect
   all IPv4 packets but drop all others onto the local subnet
   unprotected.  At least one widely used VPN behaves this way.  This is

==> you use a very unusual meaning for the word "drop". Consider rewording..
:-)

The VPN doesn't
   know about IPv6, so instead of protecting the packets and sending
   them to the remote end of the VPN, it passes such packets in the
   clear to the local network.

==> note that the packets end up in the local network only if there is the
on-link assumption, or someone hijacking the traffic through advertising a
prefix, right?

3.3.1 Mitigating Security Risks

   Establishing a security policy that is the same for IPv4 and IPv6
   would help mitigate this risk.

==> I'd state that a bit differently.  The most important thing is that a
conscious decision has been made about the policy, and the policy is not
breached.  It *could* be OK to specify that IPv6 is different as well.. so
consider rewording to like:

   The security policy must take a stance whether it applies equally 
   to both IPv4 and IPv6 traffic; the most important thing is to be aware of
   the problem.  However, having a similar policy is probably desirable.

5. Security Considerations

   This document raises security concerns in Section 3.3.

==> this needs improvement, but may be good enough for now..

editorial
---------

==> one should probably consider using the compact option of xml2rfc,
especially because the sections at the end are very short.

                     Dual Stack IPv6 on by Default

==> s/Dual/Issues with Dual/ ?

  depends on security policy enforced somewhere else on the network
   (such as from a firewall), then there is potential for new attacks
 
==> s/from/in/


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