Please clear draft-ietf-vrrp-unified-spec number 2

Hi Jari,

Regarding this discuss, will the below clear it (I hope so as it's based on your suggestion :-)

Thanks,
Steve

Discuss:

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

Text added at end of section 9:

   In the context of IPv6 operation, if SEcure Neighbor Discovery (SEND)
   is deployed, VRRP is s compatible with the "trust anchor" and "trust
   anchor or cga" modes of SEND [RFC3971].  The (SEND) configuration
   needs to give the master and backup routers the same prefix
   delegation in the certificates so that master and backup routers
   advertize the same set of subnet prefixes.  However, the master and
   backup routers should have their own key pairs to avoid private key
   sharing.

_______________________________________________
vrrp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/vrrp