Yifan Xu writes: > James Carlson wrote: > > Sebastien Roy writes: > >> I don't see anything above describing why vrrpd needs to be the thing > >> that forges these RA messages. Any adequately privileged application is > >> able to forge RA messages, and in.ndpd is well-positioned to do that > >> since it consumes all of the required RA configuration that is contained > >> in /etc/inet/ndpd.conf. In order for vrrpd to do anything useful, it > >> would need to parse /etc/inet/ndpd.conf (just like in.ndpd), reply to > >> router solicitations (just like in.ndpd), and all of that would be a lot > >> of complex and duplicate code. > >> > Using in.ndp to send RA messages has a slight difference. The > source IP address of the messages will be the link-local address > of the interface, instead of the proxied IP address.
See RFC 2461 section 4.2: the source address on an IPv6 Router Advertisement message *must* be a link-local address configured on the interface. In general, IPv6 uses link-locals when talking about interior gateway protocol routes (such as routes from OSPF and Router Discovery). It intentionally doesn't use globals. However, it's a bigger problem for IPv4. Those ICMP Router Discovery messages need to be sent with the right source address, because link-locals aren't used for routing in IPv4. > That works > for forwarding packets. But I am not sure whether it conforms > the standard strictly. The RFC requires a master "Must send ND > Router Advertisement for the virtual router".** If this statement > could be comprehended as we don't have to use the virtual IP > for Router Advertisement, then I agree we should use in.ndpd > instead of creating duplicated code. It's a good question. I *think* that as long as the virtual IP address is a link-local (which it probably should be if you're using VRRP for ordinary routing purposes), then you should use that as the source. If it's not link-local for some reason, then you MUST NOT use it as the source. However, that just begs other questions. In particular: what exactly will be in this RA message that you plan to send? Unless you read the same files that in.ndpd reads, there's no way for you to know what the contents should be. For what it's worth, the VRRP I-D that you're reading (vrrp-unified-spec) is weird in that it goes into extreme detail on IPv6 issues (section 8.2.2), but completely ignores the identical IPv4 issues. I think it's necessary to take it with a grain of salt. (I'll see if I can't get clarification from the author.) > > The implication of all of this is that implementing the "forward only" > > semantics of VRRP merely by installing a proxy ARP/ND entry is > > probably not sufficient to get robust behavior. This really does need > > to look and act like a regular interface in terms of sending packets, > > but one where most local reception is inhibited. > > > > One way to avoid using proxy ARP/ND is to apply an ipfilter "block out" > rule implicitly for each virtual IP to help realize this "forward only" job. > That should work but it makes things a bit complicated. A non-accept > mode VRRP configuration needs to have dependency on ipfilter and the > auto-applied rules would be visible through ipf interface. That's one possibility. Another might be to put the existing IFF_NOLOCAL flag to some good use or invent a new interface flag. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
