[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 3: on link assumption considered harmful


Combining this, and the comment from the AI_ADDRCONFIG thread, and adding 
v6ops in the Cc:..

On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote:
> You will have to give me other arguments to kill the on-link assuption.

You seem to have some scenarios in mind where you think these are useful.  
Please elaborate.

Remember that the removing the on-link assumption mostly helps in 
deployments where there is no IPv6 connectivity at all.. i.e., you're 
probably not experiencing these personally :-).  But those are very 
probably nasty for folks who might have dual-stack on by default, but 
without connectivity.

More inline..

On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote:
> "The problems of this assumption are discussed in section 3
> of Alain's draft. The draft suggests that this assumption
> should be removed from ND specs. Here is the suggestion:
> [snipped but it's read as..."remove" and "remove"...]
> This seems like a reasonable suggestion, any objections?"
> As I've already said, I think that on-link communications might
> be a useful thing to have.

You realize, of course, that the document does not try to restrict on-link 
communications at all?

It just recommends that if you don't have a default route, don't assume
everybody in the Internet is reachable on-link.  This seems rather
reasonable in almost all cases, because you generally *can't* expect
anything like that.  You expect that the prefixes you have the addresses
from are on-link (which continue to work without any problems), and that's
it :-)

> > - impacts on address selection (section 3.1)
> So let's go to fix address selection instead of removing
> a nice feature.

Again, do you have scenarios in mind where this feature would be useful?

The document doesn't (yet :-) tease out the different problems as well as
it could, but this isn't just a thing that can be fixed by a simple
default address selection modification.  

For example, if your first-hop router crashes *), but you still have a
global IPv6 address, and you perform a DNS lookup over IPv4, and get A and
AAAA responses back from the DNS, the on-link assumption would make you
try to perform a TCP connect() using the IPv6 address.  Obviously, this
will cause long timeouts until the router comes back up and replaces the
default route.

*) here are actually two cases: the default route is removed (e.g. it
times out), which is a clear case of an on-link assumption problem, and
when default route persists but the next-hop is considered unreachable by
NUD (which also triggers the on-link assumption, AFAIR -- but not sure;  
also not sure how fast NUD will work on the default router's nexthop..).

The more obvious problem you may not be seeing is when an implementation 
has enabled dual-stack but does not have IPv6 connectivity at all (i.e., 
only the link-local addresses).  However, due to the onlink assumption, it 
tries to reach every IPv6 destination directly on its interfaces.  I fail 
to see any justification for this.  Such addresses need not come through 
default address selection.

The clearer issue with default address selection (really, destination
address selection, which isn't really implemented that much yet!) is when
the the scopes are mismatching.

The fix should probably be applied in both, the default address selection
(by clarifying what "avoid unusable destinations" should entail) and
RFC2461bis, but the latter is more timely and more important.

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

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6