Re: v6onbydefault-00 comments

[Pekka Savola <pekkas@netcore.fi>]

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

On Mon, 17 Nov 2003, Sebastien Roy wrote:
> >   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?

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

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

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

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 ?

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

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

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

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

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

OK.

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