Subject: RE: Q's about VRRPv3 draft

From: "Smith, Mark - Sydney" <[email-masked]>
Date: Fri, 3 May 2002 08:23:19 +0800

Hi Bob,

Sorry not to get back to you sooner. I've been a bit busy recently preparing
for a product launch. At least I've had plenty of time to think a few things
through.

<snip>

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

I'll do a bit more thinking about this, I thought I needed to get back to
you with something ... I've added a few things below.

> > > >8.2  ND Neighbour Solicitation
>

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

It certainly does. There is a tiny grammar error though - "hosts" probably
should be "host's"

VRRP for IPv4 would also benefit from a paragraph specifying similar

behaviour for ARP.

<snip>

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

Agreed.

> >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) :
> 
> Did you mean a change to RFC 2461?
> 

No, specifically modify the behaviour of ND when being used by VRRP in this
particular case ie. IPv6 VRRP RFC changes an optional MAY into a recommended
SHOULD for this case. I'm presuming it is ok for a more protocol and or
situation specific RFC to change a MAY into a SHOULD - I haven't been
involved in RFC development before so I'm not sure of the rules for these
sorts of situations.

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

Ok.

> >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 ...
> 
> My comments at the end.
> 
> 

<big snip - summary : my suggestion to derive the VRRP link local address
from the VRRP MAC address>

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

I hadn't thought of those things.

I agree with your comments about redirects.

With regards to routing protocols, I don't think they should be using the
VRRP link local address (which, just to clarify for discussion, is the
original pre-VRRP link local address) as either the next hop for dynamically
learnt routes, or as the identifier for the routing protocol's neighbors.

If a routing protocol continues to operate after VRRP has been enabled on a
pair of remote routers, the following issues / problems are likely to occur
:

1) If the now Virtual Router Backups abandon their pre-VRRP link local
address, non-VRRP routers running a dynamic routing protocol will consider
the Virtual Router Backups down. As the Virtual Router Backups don't have
their own unique link local address anymore, they cannot be uniquely
identified on the segement anymore, and therefore they can't participate in
any routing protocols that are running on the segment.

2) If the link local address owner (now the Virtual Router Master) were to
use the VRRP link local address for its participation in a dynamic routing
protocol everthing would probably be OK until a VRRP transition occured.
When a VRRP transition occurs transparently to the dynamic routing protocol,
the dynamic routing protocol will continue to attempt to monitor neighbor
availablity using the VRRP link local address eg OSPF hellos. As these
availability packets are directed towards the link local address of the peer
router, in this case, the new Virtual Router Master, as a former Virtual
Router Backup, must now drop these availablity packets, as per section 6.4.3
- "MUST NOT accept packets addressed to the IPv6 address associated with the
virtual router if it is not the IPv6 address owner."

Note that I think the above problems exist also with the VRRP routers trying
to run a dynamic routing protocol between themselves.

Taking a step back for a moment, I've realised there are two different types
of packet forwarding occuring in an IP(v4,v6) network :

1) Host to Router (ES-IS :-))

2) Router to Router (IS-IS  :-))

VRRP is a solution to providing redundancy for the ES-IS of packet
forwarding. It also performs a form of peer discovery, specifically backups
passively discovering and monitoring the master.

Dynamic routing protocols provide redundancy for IS-IS packet forwarding.
They also perform peer discovery, and due to a further requirement of
discovering the best path through a network, best peer selection.

I suppose what I'm really saying is that VRRP and other dynamic routing
protocols are really solving the same or similar problems, the difference is
whether the nodes involved are a combination of "dumb" (ie hosts, routers
with static routes) and "intelligent" for VRRP, and all intelligent for
dynamic routing protocols.

I think solution for the first type of communcations should try to avoid
impacting the operation of the second type of communications. VRRP today
unfortunately does impact the operations of the second type of
communcations, due to a VRRP backup, now the VRRP master, not responding to
packets if it is not the IP address owner.

If we were to use a separate VRRP link local address, we could then preserve
the original link local addresses, for continued dynamic routing protocol
operation.

ICMP redirects are an issue , as when sending an ICMP redirect, does the
router supply the VRRP link local address as the target or the real link
local address ? I would think if the source address of the packet triggering
the ICMP redirect is onlink, the ICMP redirect would supply the VRRP link
local address as the target, whereas if the source address of the packet
triggering the ICMP redirect is offlink, the ICMP redict would supply the
real link local address of the best router on the forwarding path.

Sorry again for the delay,

Mark.