headers
Hott, Robert W CIV B35-Branch | 1 Jun 2005 18:11
Picon
Favicon

RE: FW: I-D ACTION:draft-ietf-vrrp-ipv4-timers-00.txt

Don,
	Sorry for not commenting on your comments in a timely manner. I have inserted my comments, to your
comments, in-line, below. I agree with each of your comments. There have been other comments on the draft
since your original post that I feel should be considered for both the IPv4 and the IPv6 implementations of
VRRP. Anyway, see my comments below.

Bob Hott

-----Original Message-----
From: Don Provan [mailto:dprovan <at> bivio.net]
Sent: Tuesday, March 01, 2005 18:26
To: Hott, Robert W CIV B35-Branch
Cc: vrrp <at> ietf.org
Subject: RE: [VRRP] FW: I-D ACTION:draft-ietf-vrrp-ipv4-timers-00.txt

I think there needs to be a section on backwards compatibility
specifically pointing out that the protocol version is changing,
so there is no backwards compatibility. I also think such a
section might want to suggest that implementations support a
"version 2 mode" to allow new implementations to be used on
networks with old ones.

<Bob Hott: the question I would have here is, would you want a router to do both versions at the same time? That
is, send two advertisement messages, one for each version?>

If we go with the units being controlled by a flag (i.e., 4.1.1),
did you consider using the high order bit of the existing
interval value? This limits the interval in seconds to 127 and
the interface in centiseconds to 1.27 seconds, but that doesn't
seem like a problem to me. I'm not sure why I like this better;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Don Provan | 1 Jun 2005 19:18
Favicon

RE: FW: I-D ACTION:draft-ietf-vrrp-ipv4-timers-00.txt

> Don,
> 	Sorry for not commenting on your comments in a timely 
> manner.

Bob,

*I* wrote this? ;-)

> <Bob Hott: the question I would have here is, would you want 
> a router to do both versions at the same time? That is, send 
> two advertisement messages, one for each version?>

I just want "reasonable behavior" to be clearly thought out
and explained. I'm not sure I know what that behavior is,
though. My suggestion would be that the recommendation say
that a deployment should never mix the two versions in a
single VR. But that still leaves the question of how a second
generation VRRP implementations should react if it receives a
first generation packet for its VR. Certainly it should raise
a stink, but how should it react in the protocol:

   1. Remove itself from service?
   2. Ignore the packet?
   3. Answer the packet? This basically saying it should send
      two advertisements, one for each version.

I think a case could be made for each of those, and I don't
actually see one that's a clear winner. But I think we should
definitely pick one and proclaim it correct behavior so we
have a reasonable guess at how any given implementation will
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Bates | 4 Jun 2005 00:17
Picon

RE: VRRP for IPv6 questions

Biao,
 
I don't recall seeing a response to your last request.  Using the VR mac to create the link local address seems like a natural fit to me as well.  Two sections of the draft lead me to think that this is not permissible.  In section 6.1 on the topic of IPv6_Addresses it says explicitly "No default."  Also in section 7.4 it says that IPv6 Routers "MUST NOT use the Virtual Router MAC address to create the Modified EUI-64 identifiers."  I think this is meant for IPv6 interface addresses, not virtual router addresses, but this isn't clear to me.
 
Steve
-----Original Message-----
From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On Behalf Of Biao Gao (bigao)
Sent: Wednesday, May 04, 2005 5:29 PM
To: Steve Bates; vrrp <at> ietf.org
Subject: RE: [VRRP] VRRP for IPv6 questions

Thanks to Steve and John for the clarifications.
 
One last note, if the virtual router's link-local address does not have to be one of VRRP router's interface addresses, using VR Mac to form the link-local address seems to be fairly convenient. Any comment?
 
Biao

From: Steve Bates [mailto:Steve.Bates <at> ind.alcatel.com]
Sent: Wednesday, May 04, 2005 3:27 PM
To: Biao Gao (bigao); vrrp <at> ietf.org
Subject: RE: [VRRP] VRRP for IPv6 questions

Biao,
 
You raise some interesting points, including one about the prefix length that I had not considered. 
 
The ability to choose a particular address that can be used to generate the link local address seems to be fairly implementation dependent.  It was fairly easy to do based on RFC 3768 when one had the option of requiring virtual routers to have a matching list of IP addresses, but this may no longer be the case for VRRPv3.
 
Section 7.1 of the current IPv6 draft does not appear to have been updated when the advertisement was modified to include multiple IP addresses.  The draft states that on receipt of an advertisement a VRRP router:
 
      - MAY verify that the IPv6 Address matches the IPv6_Address
        configured for the VRID.
 
One might think that with multiple IP addresses the wording might be more like RFC 3768:
 
   -  MAY verify that "Count IP Addrs" and the list of IP Address
      matches the IP_Addresses configured for the VRID
 
Or else explicitly state that only the first IP address MAY be checked.  In any case, explicit configuration should always be possible.
 
Before today I had assumed that there was nothing to prevent a user from configuring any IP address for the virtual router, and I guess that hasn't changed.  However, based on your question I realize that without a prefix length, it is not practically possible.  It seems that the address must belong to one of the interface' subnets in order to obtain a useful prefix length for the router advertisement.
 
To be an IP address owner all of a virtual router's IP addresses must match it's IP interface addresses, otherwise we run into exactly the problem you point out - several virtual routers claiming to be the owner and sending advertisements with priority 255.  Our experience has been that very few users assign the interface address to the virtual router.  There are probably several reasons: 1) It's easier to keep track of addresses. 2) The owner always preempts the backup and this can lead to problems particularly after a reboot. 3) Ping.
 
Steve


-----Original Message-----
From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On Behalf Of Biao Gao (bigao)
Sent: Tuesday, May 03, 2005 8:53 PM
To: vrrp <at> ietf.org
Subject: [VRRP] VRRP for IPv6 questions

Hi,
 
I have some questions regarding VRRP for IPv6:
 
Since link-local IPv6 address is mandatory in the VRRP advertisement packet, does this imply each virtual router has to be configured a link-local IPv6 address? If this address is automatically generated from an IPv6 address to be backed up, like Steve mentioned, when there are more than one address associated with the virtual router, how do the other routers in the same group know which address to use to generate the link-local address? It seems some explicit configuration has to be done.
 
To configure an IPv6 address for a virtual router, does it have to be in the same subnet of one of interface's IPv6 addresses? If not, what is the prefix length of the subnet?
 
In the draft, the IP address owner is defined to be "The VRRP router that has the virtual router's IP address(es) as real interface address(es)". As there can be multiple IPv6 addresses on an interface and associated with a virtual router, I assume this refers to the link-local address. Then the owner of the link-local address also assumes the ownership for the other addresses in the priority 255 advertisement, and the real owners of these addresses are masked out. Is this kind of configuration valid or not?
 
Any insight into these?
 
Thanks,
 
Biao
 
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |
headers
Biao Gao (bigao | 4 Jun 2005 01:29
Picon
Favicon

RE: VRRP for IPv6 questions

Steve,
 
I think this approach is conceptually clean if you don't need an owner of this VR IP address. My understanding of the sentence in section 7.4 is the same as yours, so this actually ensures no router can own this address. I don't know the rationale behind the "No default" restriction in section 6.1. But I do think using VR mac this way renders easier configuration although this may not be the protocol's concern.
 
Biao

From: Steve Bates [mailto:Steve.Bates <at> ind.alcatel.com]
Sent: Friday, June 03, 2005 3:17 PM
To: Biao Gao (bigao); vrrp <at> ietf.org
Subject: RE: [VRRP] VRRP for IPv6 questions

Biao,
 
I don't recall seeing a response to your last request.  Using the VR mac to create the link local address seems like a natural fit to me as well.  Two sections of the draft lead me to think that this is not permissible.  In section 6.1 on the topic of IPv6_Addresses it says explicitly "No default."  Also in section 7.4 it says that IPv6 Routers "MUST NOT use the Virtual Router MAC address to create the Modified EUI-64 identifiers."  I think this is meant for IPv6 interface addresses, not virtual router addresses, but this isn't clear to me.
 
Steve
-----Original Message-----
From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On Behalf Of Biao Gao (bigao)
Sent: Wednesday, May 04, 2005 5:29 PM
To: Steve Bates; vrrp <at> ietf.org
Subject: RE: [VRRP] VRRP for IPv6 questions

Thanks to Steve and John for the clarifications.
 
One last note, if the virtual router's link-local address does not have to be one of VRRP router's interface addresses, using VR Mac to form the link-local address seems to be fairly convenient. Any comment?
 
Biao

From: Steve Bates [mailto:Steve.Bates <at> ind.alcatel.com]
Sent: Wednesday, May 04, 2005 3:27 PM
To: Biao Gao (bigao); vrrp <at> ietf.org
Subject: RE: [VRRP] VRRP for IPv6 questions

Biao,
 
You raise some interesting points, including one about the prefix length that I had not considered. 
 
The ability to choose a particular address that can be used to generate the link local address seems to be fairly implementation dependent.  It was fairly easy to do based on RFC 3768 when one had the option of requiring virtual routers to have a matching list of IP addresses, but this may no longer be the case for VRRPv3.
 
Section 7.1 of the current IPv6 draft does not appear to have been updated when the advertisement was modified to include multiple IP addresses.  The draft states that on receipt of an advertisement a VRRP router:
 
      - MAY verify that the IPv6 Address matches the IPv6_Address
        configured for the VRID.
 
One might think that with multiple IP addresses the wording might be more like RFC 3768:
 
   -  MAY verify that "Count IP Addrs" and the list of IP Address
      matches the IP_Addresses configured for the VRID
 
Or else explicitly state that only the first IP address MAY be checked.  In any case, explicit configuration should always be possible.
 
Before today I had assumed that there was nothing to prevent a user from configuring any IP address for the virtual router, and I guess that hasn't changed.  However, based on your question I realize that without a prefix length, it is not practically possible.  It seems that the address must belong to one of the interface' subnets in order to obtain a useful prefix length for the router advertisement.
 
To be an IP address owner all of a virtual router's IP addresses must match it's IP interface addresses, otherwise we run into exactly the problem you point out - several virtual routers claiming to be the owner and sending advertisements with priority 255.  Our experience has been that very few users assign the interface address to the virtual router.  There are probably several reasons: 1) It's easier to keep track of addresses. 2) The owner always preempts the backup and this can lead to problems particularly after a reboot. 3) Ping.
 
Steve


-----Original Message-----
From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On Behalf Of Biao Gao (bigao)
Sent: Tuesday, May 03, 2005 8:53 PM
To: vrrp <at> ietf.org
Subject: [VRRP] VRRP for IPv6 questions

Hi,
 
I have some questions regarding VRRP for IPv6:
 
Since link-local IPv6 address is mandatory in the VRRP advertisement packet, does this imply each virtual router has to be configured a link-local IPv6 address? If this address is automatically generated from an IPv6 address to be backed up, like Steve mentioned, when there are more than one address associated with the virtual router, how do the other routers in the same group know which address to use to generate the link-local address? It seems some explicit configuration has to be done.
 
To configure an IPv6 address for a virtual router, does it have to be in the same subnet of one of interface's IPv6 addresses? If not, what is the prefix length of the subnet?
 
In the draft, the IP address owner is defined to be "The VRRP router that has the virtual router's IP address(es) as real interface address(es)". As there can be multiple IPv6 addresses on an interface and associated with a virtual router, I assume this refers to the link-local address. Then the owner of the link-local address also assumes the ownership for the other addresses in the priority 255 advertisement, and the real owners of these addresses are masked out. Is this kind of configuration valid or not?
 
Any insight into these?
 
Thanks,
 
Biao
 
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 3 comments |

Gmane