Subject: Re: Q's about VRRPv3 draft

From: Bob Hinden <[email-masked]>
Date: Thu, 28 Feb 2002 19:11:43 -0800

Mark,

Sorry for the very very long delay in responding.

At 04:56 PM 12/13/2001, Smith, Mark wrote:
>Hi Bob,
>
>I've read through your VRRP for IPv6 draft, and have a few questions.
>
>2.5 Efficient Operation over Extended LANs
>
>The description of packets that use the virtual router MAC address as their
>source could be interpreted as being restricted to only the VRRP packets
>issued by the router.
>
>Would it be better to change "1) use the virtual router MAC as the source in
>a packet sent by the Master to trigger station learning" to "1) use the
>virtual router MAC as the source in *all packets* sent by the Master to
>trigger station learning" ?
>
>I've read though this section myself a few times (in both this draft, and
>RFC 2338), and only interpreted it the right way as a final check before
>sending this email.
>
>I would suggest expanding this section (and possibly renaming it) to cover
>all the link layer issues, including virtual router MAC address, source link
>layer address selection, ND neighbour solicitation and advertisement
>procedures, and operation over extended LANs.

Was this issue resolved in the email exchange w/ Danny Mitzel?

>8.2  ND Neighbour Solicitation
>
>'When a VRRP router restarts or boots, it SHOULD not send any ND messages
>with its physical MAC address for the IPv6 address it owns, it should only
>send ND messages that include Virtual MAC addresses.'
>
>I would think that any time (rather an just after restarts or reboots) the
>VRRP master performs a ND neighbour solicitation for one of the VRRP
>protected hosts, it should use the virtual router MAC address for both the
>src MAC address in the link layer header, as well as supplying it in the
>source link-layer address option of the neighbour solicitation packet.

I think this paragraph is talking about the need to deal with restart or 
boot and to make it clear that an implementation shouldn't use it's 
physical MAC address.

How about if I add a new paragraph that talks about when the VRRP router 
sends  an ND neighbor solicitation for a hosts IPv6 address it needs to use 
the virtual MAC address in the source link-layer address option.  I am not 
sure it needs to specify here that the solicitation needs to also have a 
link layer source of the virtual MAC for the reasons Danny Mitzel discussed 
in his replies.

>This also seems to be an vague area in the current IPv4 version of VRRP.
>I've recently worked with an implementation of RFC 2338 where the following
>would happen :
>
>1) The VRRP master would come up.
>2) The first ever packet to be forwarded by the VRRP router was in the VRRP
>router to VRRP protected host direction, which caused the VRRP router to
>issue an ARP for the Host's link layer address. The VRRP router would supply
>it's real MAC address as the link layer source address in the ARP packet.
>3) The host would respond to the ARP, but also add an entry into its own ARP
>cache, with the real MAC address for the VRRP master.
>4) The host would only replace the real MAC address in its ARP cache with
>the virtual VRRP MAC address if its the ARP entry timed out and it issued an
>ARP for the VRRP router, or the VRRP master failed, and the VRRP backup
>route issued a gratuitous ARP as part of its master transition procedure.
>
>I initially though this might be a problem with the implementation, and
>figured I would read through the RFC to find out how things should really
>work. I found that the RFC doesn't seem to specifically cover the case of
>what link layer address the VRRP router should supply when ARPing for a VRRP
>protected host.
>
>Fortunately the gratuitous ARP seems to cover up this flaw , however, the
>single gratuitous ARP could be lost due to a high amount of traffic on the
>network during the master to backup transition.

Do you think this is an issue in the VRRP for IPv6 draft?

Bob

p.s. I hope to get a revised VRRP for IPv6 draft out tomorrow morning.  I 
will at least include the ND solicitation change.