Re: v6onbydefault-00 comments

[Sebastien Roy <Sebastien.Roy@Sun.COM>]

> 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.

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?).

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

That would be excellent.

> 
> 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?)

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
> here?

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?

> 
> ==> 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.

Ok, that part of the sentence can be yanked.

> 
> 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?

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

> 
> 5) I don't remember that the second paragraph of section 2.2.1 in the onlink
> 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:
> 
>  - 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?

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.

> 
> 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" ?

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.

> 
> ==> 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 :-)

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

> 
> ==> 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..

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

> 
> 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.

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?

> 
>   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.

Indeed.

> 
> 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.

Agreed.

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

O.k.

> 
> semi-substantial
> ----------------
> 
> ==> 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.

Agreed.

> 
>    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..

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

> 
>    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/ ?

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

> 
>   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/ ?

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

> 
>    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.

Yikes.  That sounds better. :-)

> 
> ==> 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?

Right, we should make that clearer.

> 
> 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.

Agreed.

> 
> 5. Security Considerations
> 
>    This document raises security concerns in Section 3.3.
> 
> ==> this needs improvement, but may be good enough for now..

Yes, we're open to suggestions here.

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

Ok, I'll try that.

> 
>                      Dual Stack IPv6 on by Default
> 
> ==> s/Dual/Issues with Dual/ ?

Ok.

> 
>   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/

Ok.

Thank you,
-Seb