On Wednesday 29 October 2003 22:03, Pekka Savola wrote: > 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.
Ok I understand that. > 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? Yes I do. > 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? Uhmmm let me think for a while, ok ? :-) > 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. For example, your fridge wants to talk with the scheduler to ask for more food. The oven, which is sending RAs, is turned off. This will cause no communication at all. I prefer 3 seconds of delay. I'm the auto-communication kind of man. I don't intend to make you laugh but I think I will have to get some information about the zero-conf WG's jobs before going on this discussion, because I thought that this feature was a GOOD THING. > 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). This is the common case nowadays. When I connect to Internet at home with my dial up provider, I've got IPv4 and also a link-local address and I've never experienced any problem at all. > 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. Absolutely agreed. > > 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. -- JFRH -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
