Subject: v6onbydefault-00 comments

From: Pekka Savola <[email-masked]>
Date: Sat, 15 Nov 2003 14:23:47 +0200 (EET)

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

---

From: Sebastien Roy <[email-masked]>
Date: Mon, 17 Nov 2003 14:59:31 -0500

> substantial

Agreed.  The introduction section could be more detailed and include a
more general description of the problem statement.  In addition to
that, there needs to be some glue to tie everything together (in a
conclusion section perhaps?).

> try to hack up some text after done..

That would be excellent.

> the first sentence reversed?)

What I meant to say was that all bets are off if applications don't use
destination address selection.  Is that not how you interpreted the
sentence?

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

Maybe, and maybe this is the wrong context to be talking about the
resolver's potential problems.  In any case, shouldn't the resolver be
doing something more useful with that list of server addresses other
than try them in round-robin fashion?  If none of the IPv6 servers are
reachable, should it ever bother trying them?

> If the user gives the IPv4 address, it works.

Ok, that part of the sentence can be yanked.

> reference to the on-link assumption document?

Yes, that was the original intent, but we ran out of time before the
submission deadline.  This will be done in the next version.

> document?

The 2nd paragraph of v6onbydefault's section 2.2.1 wasn't brought over
to the onlinkassumption document.  That was an oversight.

> I'm not sure if I understand the problem correctly:
> 

That's the desired behaviour, but the ND spec never mentions that more
specific routes should ever be considered by hosts.  According to the
conceptual model for hosts in rfc2461, hosts should either consult
their default router list for sending packets off-link, or send
packets on-link.

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

I don't think so.  For example, a connection in ESTABLISHED state
shouldn't be aborted if an ICMPv6 "soft error" is received.  So there
_should_ be a distinction between soft and hard errors for states other
than SYN-SENT.

> as well -- or at least list them as items for further study :-)

Yes, we'll see what we can do here in the next version.

> probably be mentioned explicitly as an existing problem..

Yes, it should be mentioned as this is a common problem (especially
with firewalls).

>   interconnected networks, but this can't be a long term solution.

I'm not sure I completely understand what you mean be "restrict", but
I'll assume for the moment that you mean restrict the addresses
returned by name lookups...  Many enterprise networks already have
neutered DNS deployments where the internal servers only answer to
queries for internal records, so your idea might be doable there.  How
would this be done in an ISP?

>   the first imperative should be working on enhancing the performance of 

Indeed.

> problem.  This section can probably be reduced in length a bit.

Agreed.

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

O.k.

> semi-substantial

Agreed.

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

Yes it would.  The problems aren't specific to this exact scenario.

>    Unreachable messages back to senders of such packets.  The sender's

I agree.  The sentence doesn't really make sense otherwise.

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

How about, "triangular IPv4 paths"?  The word "topologically" already
exists earlier in the sentence.

>    clear to the local network.

Yikes.  That sounds better. :-)

> on-link assumption, or someone hijacking the traffic through advertising a

Right, we should make that clearer.

>    the problem.  However, having a similar policy is probably desirable.

Agreed.

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

Yes, we're open to suggestions here.

> especially because the sections at the end are very short.

Ok, I'll try that.

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

Ok.

>    (such as from a firewall), then there is potential for new attacks

Ok.

Thank you,
-Seb

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Nov 2003 00:48:52 +0200 (EET)

Thanks for the quick replies, Sebastien.  A few additional comments inline 
to the open issues..

> destination address selection.  Is that not how you interpreted the

Not really.. maybe try rewording to something like:

   Applications which do not use getaddrinfo() for name resolution would 
   naturally not profit from such rules, but such applications must 
   implement similar mechanisms to get destination address selection in 
   the first place.  One special case is the DNS stub resolver.

   When using a single address, whether obtained from DNS or as a literal 
   address, there is no ordering to be done even if it was possible, and
   either the session suffers from delays trying to connect to an 
   unreachable destination or it works. This is discussed in more detail 
   in the next few sections.
   
... might need tuning, but maybe closer how I read that paragraph?
 
> reachable, should it ever bother trying them?

It would certainly make sense to keep some kind of cache about DNS server 
addresses to avoid timeouts when one of them is out, but that's probably 
outside of the scope of this document (if I understood you correctly)..

> their default router list for sending packets off-link, or send

Whoops.  OK, maybe it's worth stating here explicitly.  Are you subscribed 
to IPv6 WG list, and would like to file an issue for revising in 2461bis ?

> _should_ be a distinction between soft and hard errors for states other

Oh.  I read the "distinction" differently, referring to the previous 
sentence.  Consider rewording for clarity?

> would this be done in an ISP?

DNS-based scoping is one approach.. but probably criticized by many.

What I had in mind was that if ICMPv6 unreachable would abort a 
connection, it would be enough to just not have a default route in the 
ISP's backbone -- every connection inside the ISP would work just fine, 
those trying the other addresses would go as far as the backbone, would 
get an ICMP error, and would get aborted.

If I'd have to deploy v6 in "semi-production" fashion inside a v6 
enterprise, that's how I'd probabyl do it.  Just use v6 for internal 
communications where it works fine..

> exists earlier in the sentence.

OK.