Hi, 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 [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
