On Tue, 3 Aug 2004, Erik Nordmark wrote: > Two comments: > 1. The term "local address resolution" isn't defined so I doubt the > above text suggestion clearly communicates what you want to say.
Right. Maybe just remove "local" then, making it a bit more ambiguous but more accurate? :-) The ICMP indication of address resolution failure SHOULD be treated as a hard error [RFC1122]. > 2. I can see this as useful when there is an alternative (which is your > motivation), but I'm concerned that treating it as a hard failure when there > is no alternative is detrimental. But if ND resulution fails, is it probable that it's going to be fixed any time soon? If the app just aborts if net connectivity is down, the user can try again soon? At least to me, timely notification of a serious network error that's blocking my access is a good thing. > Another approach would be to attack the more general issue, which I would > state as "when there are alternatives, treat soft errors and an indication > to try an alternative". But I fail to see how the code would know if there are actually implementations. Two subsequent ND requests or ND+ARP are independent of each other.. -- 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 --------------------------------------------------------------------
