Subject: RE: Q's about VRRPv3 draft

From: "Smith, Mark - Sydney" <[email-masked]>
Date: Mon, 4 Mar 2002 11:30:15 +0800

Hi Bob,

Comments embedded below ...

> -----Original Message-----
> From: Bob Hinden [mailto:[email-masked]]
> Sent: Friday, 1 March 2002 14:12
> To: Smith, Mark - Sydney
> Cc: [email-masked]
> Subject: Re: Q's about VRRPv3 draft
> 
> 
> 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?
> 

Yes, Danny explained why this section only specified using the VRRP MAC
address as the source for VRRP announcements only, rather than all packets
coming from the VRRP router.

I would wonder if there was any value in adding some text to a both the IPv6
VRRP draft you are working on and maybe a later IPv4 VRRP RFC to explain
this a bit further, to save people getting confused like I did.

> >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.
> 

Yes, I agree about adding a paragraph regarding filling the source
link-layer address option with the virtual MAC address in a ND solicitation.
I think this will help clear up one of the corner cases that isn't covered
in RFC 2338 for the IPv6 version of VRRP. At a later date, I would suggest
the IPv4 VRRP RFC is reviewed to cover this as well.

I also agree, for the same reasons Danny discussed, it is not necessary that
the ND solicitation use the virtual MAC address as its link layer source
address.

I'm wondering if any of the rules in the neighbor solicitation section (ie.
7.2.2) of RFC 2461 need to be changed or modified in this IPv6 VRRP RFC to
suit VRRP operation.

Specifically, I'm wondering if there would be value in changing MAY to
"SHOULD NOT" in the following paragraph, in the IPv6 VRRP RFC (re-written
etc of course) :

"On unicast solicitations, an implementation MAY omit the Source Link-Layer
Address option. The assumption here is that if the sender has a peer's
link-layer address in its cache, there is a high probability that the peer
will also have an entry in its cache for the sender. Consequently, it need
not be sent."

The case I'm thinking of is :

1) A non-VRRP router is configured to become a VRRP master, and VRRP starts
operating. The link local IPv6 address assigned to this router is now the
Virtual  Router Master link local IPv6 address.
2) The new Virtual Router Master issues an unsolicited ND Neighbor
Advertisement, as per the Initialize / Priority = 255 state
3) As there is only a single unsolicited ND Neighbor Advertisement, the some
of the end-nodes miss it due to a busy network.

If these end-nodes have an entry in the new VRRP Virtual Router Master's
Neighbor Cache, the VRRP Virtual Router Master may perform neighbor
unreachability detection using unicast solicitations. In this case, I would
suggest the Source Link-Layer Address option SHOULD be supplied, containing
the VRRP Virtual MAC address.

My example is based on the assumption that the link local IPv6 address was
previously used as a router address (and is likely to be in the end-nodes'
neighbor cache), and is now being used as the VRRP Virtual Master address.
What has really happened during the transition from normal router to VRRP
Virtual Router Master has been a change between the link local IPv6 address
and the link layer address mapping. Obviously the intention of the
unsolicited ND Neighbor Advertisement is to update the end-nodes' neighbor
cache with the new link layer address for the (now) VRRP link local IPv6
address.

Hmmm, I've just had a further thought ...

I think there could value in deriving the VRRP link local IPv6 address from
the VRRP virtual mac address (contrary to section 7.4 of your draft). I
think there could be the following benefits :

1) The above case doesn't happen, as the VRRP link local IPv6 address didn't
exist on the network before VRRP was switched on. There would not be any
invalid neighbor cache entries in the end-nodes. The unsolicitied ND
Neighbor Advertisement at Virtual Router Master initialisation would be
unnecessary.

2) Enabling VRRP on a router would be simpler, as you wouldn't have to
manually configure the VRRP Virtual Router link local IPv6 address. Enabling
VRRP and specifying the Virtual Router ID would be all that is required. 

In the case were a non-VRRP router transitions to a VRRP Virtual Master (ie.
my example above), during the transition, it would :

1) withdraw itself as a candidate default router, for its pre-VRRP link
local address, via an unsolicited router advertisement.
2) advertise itself as a candidate default router, for the VRRP link local
address.
3) for all traffic sent to the pre-VRRP link local address that is not
directed for the router itself, issue a ICMP redirect towards the new VRRP
link local address. 

The pre-VRRP link local address would still be valid, but only for traffic
directed towards the router itself eg management etc.

Using a virtual VRRP link local address means the VRRP router cannot
determine whether it should be the preferred Virtual Router Master or not by
checking the interface assigned IPv6 address. Manually setting the VRRP
priority to 255 would indicate master preference. Additionally, a priority
of 255 would indicate whether the router should respond to packets address
to the router or not (ie section 6.4.2 point 4 vs 6.4.3 point 6).

I think that manually enabling VRRP, setting the Virtual Router ID and
optionally setting the priority is less error-prone than enabling VRRP,
setting the Virtual Router ID, and manually specifying the virtual router
link local address, as per the current VRRP model. 

I would guess that in the case of IPv4 VRRP, the reason a virtual IP address
was abandoned (I discovered comments in the vrrp mail archives suggesting
the v1 used a virtual address, but the archives didn't seem to go back far
enough to explain why it a virtual router IP address was moved away from),
was it saved a (usually public) IP address, and it wasn't necessary for the
protocol to work. 

We don't have to worry about wasting public IPv6 addresses, and I think at
the cost of an additional IPv6 link local address, we might be able to make
a IPv6 VRRP administrators life a bit easier.

BTW, some of my understanding of IPv6 might be a bit wrong, it just works
for me in the lab ( :-) ), and I usually spend all my days thinking about
IPv4 and IPsec VPNs.

> >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?

The paragraph you are going to add regarding a VRRP router sending a
neighbor solicitation with the Source Link-Layer Address option containing
the Virtual MAC address would arguably mean the unsolicited ND neighbor
announcement is not necessary at all. So this problem would disappear.

> 
> 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.
> 
> 

Thanks,
Mark.
--
WORLDCOM. THE BEST COMMUNICATION SERVICES IN THE WORLD. 
       -- Based on World Communications Association 2001 Award
For more information, visit www.worldcom.com/asiapacfic
-----------------------------------------------------------------
This communication contains information which is confidential and 
may also be privileged.  It is for the exclusive use of the 
intended recipient(s).  If you are not the intended recipient(s), 
please note that any distribution, copying or use of this 
communication or the information in it is strictly prohibited.  
If you have received this communication in error, please notify 
the sender immediately and then destroy any copies of it.

---

From: Bob Hinden <[email-masked]>
Date: Fri, 15 Mar 2002 11:51:58 -0800

Mark,

>Hi Bob,Comments embedded below ...

Yes, quite a few :-)

>this a bit further, to save people getting confused like I did.

Care to suggest some text?  I submitted a new VRRP (for IPv4) draft so the 
other clarifications could included in a new RFC.  This could be added as well.

>the IPv4 VRRP RFC is reviewed to cover this as well.

I added text to the new VRRP for IPv6 draft.  Does this suffice?

>7.2.2) of RFC 2461 need to be changed or modified in this IPv6 VRRP RFC to

In general, I don't think it is good to try to change neighbor discovery to 
suit VRRP.  It is preferable to have VRRP operation without changes to the 
hosts.

>"SHOULD NOT" in the following paragraph, in the IPv6 VRRP RFC (re-written

Did you mean a change to RFC 2461?

>of the end-nodes miss it due to a busy network.

This is the start up case.  Even if the unsolicited advertisement is 
missed, the end-nodes will later time out the old entry and get a new 
one.  The worst worst case is that if the current master (owner) fails 
after turning on VRRP, the backups should also send an unsolicited ND 
advertisement.  In the worst worst worst case, this is missed and the 
end-nodes eventually will re-solicit for the masters IPv6 address and start 
using the new master.

Overall this doesn't seem like a big problem to me.  Also, once we get some 
implementation experience with VRRP for IPv6 we can see if this is a problem.

>Hmmm, I've just had a further thought ...

My comments at the end.

>a IPv6 VRRP administrators life a bit easier.

VRRP uses the routers IP addresses to allow routing protocols to continue 
to be used and enable redirects.  If one were to use virtual IP addresses 
then these capabilities need to be disabled.

We are not using global scope Ipv6 addresses her in any case, so that's not 
an issue.  IPv6 does allow a node to have multiple link local address on a 
single interface, but I am not sure if anyone has implemented or tested 
it.  It should work, but....

Your comments about making an administrators life easier is a good one.  I 
would suspect the way this would be configured is by cutting and pasting 
the neighbor routers link-local addresses from a status output (e.g., show 
ipv6 neighbors or something similar).  I hope this isn't too 
difficult.  Similar things will probably have to be done to configure 
routing protocols.

>for me in the lab ( :-) ), and I usually spend all my days thinking about

Cool!

.....

>announcement is not necessary at all. So this problem would disappear.

Good.

Thanks,
Bob