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

Ok for me (and same for your other mails). So this is just your text 
suggestion or do you actually have a new draft version out there? I 
don't find a new draft version yet...

Jari

Stephen Nadas wrote:
> 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