Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6
draft-ietf-vrrp-unified-spec-05

[Ballot comment]
The first sentence in the definition of virtual router master (section 1.6) ends with
" or and answering ND requests for these IPv6 address(es)."

"or and" needs to be replaced by one of the following: "or", "and", "and/or"

[Ballot comment]
I think the new version is a significant improvement, and I have
decided to clear the ND and virtual MAC related parts of my Discuss.
However, I still think there's something wrong with some of the
text, e.g.,

Requirement to send router advertisements is in 6.4.2 but not in 6.4.3, why?

In Section 6.4.3, the Accept_Mode flag is only checked in the IPv6 branch of the code, is this correct?

In Section 6.4.3, I don't understand how there's first a MUST statement on responding to Neighbor Solicitations, and then two steps later a conditional statement based on the value of Accept_Mode, again on the the same thing, responding to NSes.

[Ballot discuss]
This is a well written specification, and I'm prepared to ballot
Yes on it. However, there were three issues (1 left) that deserve some
discussion and probably small modifications are needed before
this can happen. Two of the issues relate to apparently missing
information, and one may be either a simple mistake or I misunderstood
something.

>In the context of IPv6 operation, if SEcure Neighbor Discovery (SEND)
>[RFC3791] is deployed, VRRP authentication could be usefully added,
>because misconfiguration of secrets will not be an issue.  Routers
>with different secrets will have different IPv6 addresses, and
>therefore there will be no issue with multiple masters with the same
>IPv6 (and MAC) addresses.  Also, SEND will prevent malicious routers
>from sending misleading ND messages.

Hmm. As an author of RFC 3971 it is not quite clear to me what you
mean above. First of all, no "secrets" are involved in RFC 3971,
only key pairs for CGA addresses. Secondly, it is not required for
routers to employ the CGA part of SEND; in most cases I would expect
the configuration of certificates for prefix::1 or something like
that.

Thirdly, I do not understand why there is no issue, because the
backup taking over, because then the backup has to authoratively
sign the NAs and RAs it is sending, for the primary's address.
If the "trust anchor and cga" mode from RFC 3971 is used, the
private key would have to be shared, or this would not work at
all. And private key sharing is not necessarily a good idea.

I would recommend saying this:
- VRRP is compatible with "trust anchor" and "trust anchor or cga" modes
  of SEND
- The configuration needs to give the two routers the same
  prefix delegation in the certificates
- But still, the routers should have their own key pairs

(Further modes are possible when the CSI WG gets some work done.)

[Ballot comment]
Christian Vogt's review:

- The document uses the acronym "IPvX" in order to refer to both/either
  IP version.  Since IPvX might be confused with the more prevalent
  acronym IPX for Novell's Internetwork Packet Exchange protocol, I
  would replace the occurrences of IPvX with either "IPv4 or IPv6", or
  simply with "IP".

- In the figures illustrating sample configurations in section 4, it is
  not clear which IP address labels denote a host's own IP address vs.
  which denote the IP address of the router that a host is using.
  Both is currently denoted "IPvX A" in the figure.  Suggest
  distinguishing the two types of labels more clearly.

[Ballot discuss]
This is a well written specification, and I'm prepared to ballot
Yes on it. However, there were three issues that deserve some
discussion and probably small modifications are needed before
this can happen. Two of the issues relate to apparently missing
information, and one may be either a simple mistake or I misunderstood
something.

I would like to talk about these on the call or with the authors.

> Accept_Mode  Controls whether a virtual router in Master
>              state will accept packets addressed to the
>              address owner's IPvX address as its own if it
>              is not the IPvX address owner.  Default is
>              False.
>
>              Note: IPv6 Neighbor Solicitations and
>              Neighbor Advertisements should not be dropped
>              when Accept_Mode is False.
>
>...
>
>Compute and join the Solicited-Node multicast address
>[RFC4291] for the IPv6 address(es) addresses associated with
>the Virtual Router.

Are these the only messages that should not be dropped?! What
about:

- RA/RS
- MLD
- CPS/CPA (RFC 3971)
- IGMP

Is the idea that you actually do stop responding to RA/RS, and that by
this hosts should migrate to to use the remaining router natively,
rather than the remaining router as a backup for the dead one? If yes,
say so.

MLD is generally sent to multicast addresses, but RFC 3810 Section
5.1.15 also talks about a MUST requirement for a router to
accept unicasted MLD. How is this accommodated in VRRP?

What about the SEND certificate retrieval messages CPS/CPA? Lets
say the primary router died just when a host had found it, but
had not had time to ask for CPS/CPA. What will happen?

>In the context of IPv6 operation, if SEcure Neighbor Discovery (SEND)
>[RFC3791] is deployed, VRRP authentication could be usefully added,
>because misconfiguration of secrets will not be an issue.  Routers
>with different secrets will have different IPv6 addresses, and
>therefore there will be no issue with multiple masters with the same
>IPv6 (and MAC) addresses.  Also, SEND will prevent malicious routers
>from sending misleading ND messages.

Hmm. As an author of RFC 3971 it is not quite clear to me what you
mean above. First of all, no "secrets" are involved in RFC 3971,
only key pairs for CGA addresses. Secondly, it is not required for
routers to employ the CGA part of SEND; in most cases I would expect
the configuration of certificates for prefix::1 or something like
that.

Thirdly, I do not understand why there is no issue, because the
backup taking over, because then the backup has to authoratively
sign the NAs and RAs it is sending, for the primary's address.
If the "trust anchor and cga" mode from RFC 3971 is used, the
private key would have to be shared, or this would not work at
all. And private key sharing is not necessarily a good idea.

I would recommend saying this:
- VRRP is compatible with "trust anchor" and "trust anchor or cga" modes
  of SEND
- The configuration needs to give the two routers the same
  prefix delegation in the certificates
- But still, the routers should have their own key pairs

(Further modes are possible when the CSI WG gets some work done.)

[Ballot discuss]
I have reviewed draft-ietf-vrrp-unified-spec-02. Overall, the document
looks good, but I have the following concerns that I'd like to discuss
before recommending approval of the document:

The security considerations text basically says security doesn't have
to be considered here because an attacker can cause havoc with ARP
anyway. I don't think this is fully accurate description.  Many
networks with untrusted hosts use switch security features that
prevent hosts from bringing down the network with spoofed ARP packets
(somewhat similar to what SAVI WG is working on). While compromising
one of the switches or routers would still cause damage, compromised
or malicious ordinary hosts (attached to switch ports where these
features are enabled) can't do that much.

The other reason for removing cryptographic authentication of VRRP
messages is said to be misconfigured secrets (which obviously does
cause problems -- but on the other hand, this situation should be
detected very quickly). If it's indeed the case that cryptographic
per-message authentication isn't a good solution to securing VRRP, at
the very least the document should discuss other possible mechanisms.
Perhaps e.g. filtering mechanisms in switches, configured on per-port
basis, could provide some protection? Or could this somehow leverage
the existing mechanisms for ARP?


An additional question about Section 7.4: I'm slightly confused by the
text here -- does every router create its own link-local address (in
which case failover is visible to hosts in this subnet), or do they
share the same link-local address? The 1st paragraph says "They MUST
NOT use the Virtual Router MAC address to create the Modified EUI-64
identifiers", but the 3rd paragraph talks about "using the VRRP MAC in
the formation of these link local addresses" -- are these
contradicting each other, or am I just misunderstanding how this
works?

[Ballot comment]
Christian Vogt's review:

- The document uses the acronym "IPvX" in order to refer to both/either
  IP version.  Since IPvX might be confused with the more prevalent
  acronym IPX for Novell's Internetwork Packet Exchange protocol, I
  would replace the occurrences of IPvX with either "IPv4 or IPv6", or
  simply with "IP".

- In the figures illustrating sample configurations in section 4, it is
  not clear which IP address labels denote a host's own IP address vs.
  which denote the IP address of the router that a host is using.
  Both is currently denoted "IPvX A" in the figure.  Suggest
  distinguishing the two types of labels more clearly.

[Ballot discuss]
This is a well written specification, and I'm prepared to ballot
Yes on it. However, there were three issues that deserve some
discussion and probably small modifications are needed before
this can happen. Two of the issues relate to apparently missing
information, and one may be either a simple mistake or I misunderstood
something.

I would like to talk about these on the call or with the authors.

> Accept_Mode  Controls whether a virtual router in Master
>              state will accept packets addressed to the
>              address owner's IPvX address as its own if it
>              is not the IPvX address owner.  Default is
>              False.
>
>              Note: IPv6 Neighbor Solicitations and
>              Neighbor Advertisements should not be dropped
>              when Accept_Mode is False.
>
>...
>
>Compute and join the Solicited-Node multicast address
>[RFC4291] for the IPv6 address(es) addresses associated with
>the Virtual Router.

Are these the only messages that should not be dropped?! What
about:

- RA/RS
- MLD
- CPS/CPA (RFC 3971)
- IGMP

Is the idea that you actually do stop responding to RA/RS, and that by
this hosts should migrate to to use the remaining router natively,
rather than the remaining router as a backup for the dead one? If yes,
say so.

MLD is generally sent to multicast addresses, but RFC 3810 Section
5.1.15 also talks about a MUST requirement for a router to
accept unicasted MLD. How is this accommodated in VRRP?

What about the SEND certificate retrieval messages CPS/CPA? Lets
say the primary router died just when a host had found it, but
had not had time to ask for CPS/CPA. What will happen?

>7.4. IPv6 Interface Identifiers
>
>IPv6 Routers running VRRP MUST create their Interface Identifiers in
>the normal manner (e.g., RFC2464 "Transmission of IPv6 Packets over
>Ethernet").  They MUST NOT use the Virtual Router MAC address to
>create the Modified EUI-64 identifiers.
>
>...
>
>If there are several VRRP routers, it is cumbersome for the operator to
>configure the same VRRP protected link-local address on all of them.
>An implementation might choose simplify this for the operator by
>using the VRRP MAC in the formation of these link local addresses.

Isn't the former MUST NOT instruction contradictory with the
guidance in the latter paragraph? Or am I missing something
obvious?

>In the context of IPv6 operation, if SEcure Neighbor Discovery (SEND)
>[RFC3791] is deployed, VRRP authentication could be usefully added,
>because misconfiguration of secrets will not be an issue.  Routers
>with different secrets will have different IPv6 addresses, and
>therefore there will be no issue with multiple masters with the same
>IPv6 (and MAC) addresses.  Also, SEND will prevent malicious routers
>from sending misleading ND messages.

Hmm. As an author of RFC 3971 it is not quite clear to me what you
mean above. First of all, no "secrets" are involved in RFC 3971,
only key pairs for CGA addresses. Secondly, it is not required for
routers to employ the CGA part of SEND; in most cases I would expect
the configuration of certificates for prefix::1 or something like
that.

Thirdly, I do not understand why there is no issue, because the
backup taking over, because then the backup has to authoratively
sign the NAs and RAs it is sending, for the primary's address.
If the "trust anchor and cga" mode from RFC 3971 is used, the
private key would have to be shared, or this would not work at
all. And private key sharing is not necessarily a good idea.

I would recommend saying this:
- VRRP is compatible with "trust anchor" and "trust anchor or cga" modes
  of SEND
- The configuration needs to give the two routers the same
  prefix delegation in the certificates
- But still, the routers should have their own key pairs

(Further modes are possible when the CSI WG gets some work done.)

[Ballot comment]
1. Appendix B and part of Appendix C excepting the part refering to changes from RFC 3768 should be dropped at publication.

2. Another feature that at least one vendor implements is so-called Backup VRRP router passive ARP learning.  This is very useful, because otherwise when you switch from active to backup, the backup doesn't know ARP bindings for IP addresses and this increases the time needed to converge.  (The same feature should apply to ND I think) This would seem to be something that could be worth adding or at least discussing in the spec.

[Ballot discuss]
(revised DISCUSS including input from OPS-DIR review by Pekka Savola)

1. The version management and transition plan for VRRP is unlear to me. The Introduction section mentions that this is 'version three (3) of the protocol and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and on draft-ieft-vrrp-ipv6-spec-08.txt'. However RFC 3768 does not make the claim to be VRRPv2, itlooks like this terminology was decided later and is defined here for the first time. On the other hand draft-ieft-vrrp-ipv6-spec-08.txt which VRRPv3 is based upon is just an informative reference and is actually an expired I-D? Should not this document update RFC 3768, and should not at least part of the migration and coexistence issues in Appendix A be moved to the Operational Issues section?

2. I do not understand what is the logic of including a section 9 'Operation over FDDI, Token Ring, and ATM LANE' in this document. Has anybody heard about a deployment of any of these layer 2 networks lately, and with VRRP atop of them?

3. Accept_Mode defaulting to false seems unrealistic at least in deployments I've seen.  Using accept-data config knob seems very common. Unless enable Accept_Mode, when the virtual address moves to the Backup, the virtual address no longer responds to ping; I've also seen an implementation to reject pings to the virtual IP when it's in Master mode, but this seems like an implementation bug if so (I'd like a confirmation if this is the case).

In any case, this restriction makes troubleshooting and deployment a pain; hosts and management systems often ping the gateway address to see if the network is working, and this kills that assumption.

Unless the WG has recently discussed and reached consensus that Accept_Mode should still default to false, I'd consider revisiting this position.

[Ballot discuss]
I'm holding this DISCUSS mostly until the issues raised in
Mark Handley's tsv-dir review have been addressed.

One further point:

Section 11., paragraph 0:
> 11.  Intellectual Property Rights Claimed

  DISCUSS-DISCUSS: Is there a specific reason why the usual
  boilerplate text isn't sufficient for this document?

[Ballot comment]
Section 1., paragraph 2:
>    Comments are solicited and should be addressed to the working group's
>    mailing list at vrrp@ietf.org and/or the editor.

  Remove.


Section 5.2.9., paragraph 4:
>    This field contains either one or more IPv4 addresses or one or more
>    IPv6 addresses, that is, IPv4 and IPv6 MUST NOT both be carried in
>    one IPvX Address field.

  You probably want to add that a VRRP packet sent over IPv4 MUST
  contain IPv4 addresses in this field and a VRRP packet sent over IPv6
  MUST contain IPv6 addresses. (In other words v6-in-v4 and vice versa
  is not allowed.)


Section 6.4., paragraph 0:
> 6.4.  State Descriptions

  Throughout this section, I find the abbreviated text in the pseudocode
  comments (//) hard to read. Given that the pseudocode itself is in
  English, why not merge the comments with the code and remove them?
  Also, the bullets in the pseudocode use different symbols (-+*@),
  which is confusing to follow.


Section 9., paragraph 0:
> 9.  Operation over FDDI, Token Ring, and ATM LANE

  Agree with Dan that this section doesn't seem to matter much. Move to
  appendix?

[Ballot comment]
Vijay K. Gurbani made the following suggestions in his Gen-ART
  Review.  They should be considered by the authors.

  Summary: This draft is ready for publication as a Proposed
  Standard.  Some feedback that will hopefully make the dratf
  more readable follows.

  - S1.1
  s/"IPv4" or "IPv6", in text/"IPv4" or "IPv6".  In this text/

  - S1.6
  In the definition of "VRRP Router",
  s/participate in one/participate as one/

  - S4.1
  For either the IPv6 case or the IPv4 case, when Rtr2 transitions
  to being the Master, is its priority changed to 255?  Or does the
  priority remain 100, thus allowing Rtr1 to come back up at some
  later time and reclaim its role as Master?

  - S4.2
  s/figure),,/figure),/

  - S5, second paragraph
  Do you mean "encapsulated in IPv4 packets" instead of
  "encapsulated in IP packets"?

  - S5.1
  The figure in S5.1 starts with a PDU layout of "Version",
  "Type", ...  However, the text right underneath the figure talks
  in terms of IPv4 (and later, IPv6) source/destination addresses
  and other characteristics.  The PDU fields of "Version", "Type"
  et al. are not discussed until S5.2.

  Thus, IMHO there is a disconnect between the figure in S5.1 and
  the subsequent sub-sections that are supposed to explain the
  fields in the PDU contained in the figure.  Is this intentional?

  - S6
  In the definition of "Priority", how does the reader rank the
  number indicating priority; i.e., the higher the number, the higher
  the priority?  Or are they related inversely?  I believe it is
  the former from reading the draft (i.e., higher the number, the
  higher the priority); but an explicit sentence may not hurt.

[Ballot discuss]
1. The version management and transition plan for VRRP is unlear to me. The Introduction section mentions that this is 'version three (3) of the protocol and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and on draft-ieft-vrrp-ipv6-spec-08.txt'. However RFC 3768 does not make the claim to be VRRPv2, itlooks like this terminology was decided later and is defined here for the first time. On the other hand draft-ieft-vrrp-ipv6-spec-08.txt which VRRPv3 is based upon is just an informative reference and is actually an expired I-D? Should not this document update RFC 3768, and should not at least part of the migration and coexistence issues in Appendix A be moved to the Operational Issues section?

2. I do not understand what is the logic of including a section 9 'Operation over FDDI, Token Ring, and ATM LANE' in this document. Has anybody heard about a deployment of any of these layer 2 networks lately, and with VRRP atop of them?

IANA Last Call comments:

QUESTION: Should we add a reference to this document for the
following existing assignments:

- IPv4 Multicast address 224.0.0.18 (section 5.1.1.2)
- IPv4 protocol number 112 (section 5.1.1.4)
- IPv6 next header protocol number 112 Reference? (Section 5.1.2.4)

Action #1
Upon approval of this document, the IANA will make the following
assignment in the "Link-Local Scope" registry at
http://www.iana.org/assignments/ipv6-multicast-addresses

FF02:0:0:0:0:0:0:TBD (12 is requested) Virtual Router Redundancy v3
[RFC-vrrp-unified-spec-02]


Action #2:
Upon approval of this document, the IANA will make the following
assignments in the "IANA ETHERNET ADDRESS BLOCK - UNICAST USE"
registry at
http://www.iana.org/assignments/ethernet-numbers

OLD:
Dotted Decimal Description Reference
----------------------- ------------------------------- ---------
000.001.000-000.001.255 Virtual Router Redundancy (VRRP) [RFC3768]

NEW
Dotted Decimal Description Reference
----------------------- ------------------------------- ---------
000.001.000-000.001.255 IPv4 Virtual Router Redundancy (VRRP) [RFC3768]
000.002.000-000.002.255 IPv6 Virtual Router Redundancy (VRRP)
[RFC-vrrp-unified-spec-02]