On 24/07/2012, at 4:15 PM, Hesham Soliman wrote: > >> I've come across what looks like a bug in the ICMPv6 spec. > > => You mean in 4861 or ICMPv6?
That's what I'm trying to work out, and I could see two potential solutions. > >> Specifically, RFC 4861 says that "A host MUST silently discard any >> received Redirect message that does not satisfy all of the following >> validity checks" amongst which is "The IP source address of the Redirect >> is the same as the current first-hop router for the specified ICMP >> Destination Address." >> >> Unfortunately, there is no way that a router can reliably generate that >> response, if it has more than one link-local address, because the message >> that caused the redirect does not actually contain the router's own >> address, and the router cannot know the content of the host's route table. > > => The router doesn't need to know the host's route table, it knows which > address it included in its RAs, which is what the host records. > I'm not sure why you think that there is no way the router can construct > that message reliably. If it uses the same address it uses for its RAs, it > can construct the message. Ah. Well, that will certainly help, but consider a situation where there are no RAs, or the host has a manual static route. Arguably misconfigured, I know, but if we have that situation a router cannot know what address the host was sending to, only that it is one of its own. For that matter, there may be many RAs being generated through that interface, and do we necessarily know which it was that caused the host/peer to route through us? > >> >> The VRRPv3 spec suggests that the destination MAC address for the packet >> causing the redirect is a sufficient cue, but that cannot be true in the >> presence of multiple link-local addresses, which is guaranteed to happen >> in VRRP (in some cases). >> >> What is the correct method of constructing ICMPv6 redirects in the >> presence of multiple link-locals for the same MAC address? Is it even >> possible without a spec change? > > => You mean multiple LLA's for the same link? The MAC address is not > relevant here, it's about the LLA used on that link. I mean multiple LLAs for the same link. VRRPv3 was suggesting that the destination MAC address might help work out which LLA the host was using. Andrew
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
