Daniel Roesen | 15 Apr 2011 10:57
Picon

RFC5798 requires usage of RAs?

Hi,

JUNOS (Juniper router firmware) issues warnings when committing config
changes, noting that RAs are not configured for an interface where VRRP
for IPv6 is configured:

vrrpd[15299]: %CONFLICT-0-WARNING: 'router-advertisement' is not configured
for interface ge-9/2/2.662

RFC5798 states:

6.4.3.  Master
...
         (630) ++ MUST send ND Router Advertisements for the virtual
         router.

That makes no sense to us when RAs are generally not used on the
segment, and hosts are manually configured to point to the VRRP virtual
address as default gateway. We do not want to use RAs in some scenarios
at all.

I've found an older posting on this list, where someone raised the same
question (Q-2):
http://www.ietf.org/mail-archive/web/vrrp/current/msg00763.html

John Cruz' answer seems to clarify, but noone seemed to have envisioned
that the spec lingo actually motivates vendors to assume RAs as being
mandatory when implementing VRRPv6... :-/

RFC5798 states in the introductory section about IPv6 (1.3):
(Continue reading)

Stephen Nadas | 28 Apr 2011 17:36
Picon
Favicon

Re: RFC5798 requires usage of RAs?

Hi Daniel, 

Sorry for the delay.  I think the spec language could be better- 
(630) etc probably should have said something more like 

"if ND RAs are in use, MUST send ND Router Advertisements for the virtual router. 

Thanks,
Steve 

-----Original Message-----
From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On Behalf Of Daniel Roesen
Sent: Friday, April 15, 2011 4:57 AM
To: vrrp <at> ietf.org
Subject: [VRRP] RFC5798 requires usage of RAs?

Hi,

JUNOS (Juniper router firmware) issues warnings when committing config changes, noting that RAs are not
configured for an interface where VRRP for IPv6 is configured:

vrrpd[15299]: %CONFLICT-0-WARNING: 'router-advertisement' is not configured for interface ge-9/2/2.662

RFC5798 states:

6.4.3.  Master
...
         (630) ++ MUST send ND Router Advertisements for the virtual
         router.

(Continue reading)

Daniel Roesen | 28 Apr 2011 19:19
Picon

Re: RFC5798 requires usage of RAs?

Hi,

On Thu, Apr 28, 2011 at 11:36:44AM -0400, Stephen Nadas wrote:
> Sorry for the delay.  I think the spec language could be better- 
> (630) etc probably should have said something more like 
> 
> "if ND RAs are in use, MUST send ND Router Advertisements for the virtual router. 

Indeed. Thanks for the confirmation.

My understanding of IETF procedures is, that an Errata submission would
be possible, valid way to unambiguate that language - which is advisable
to prevent further implementation confusion.

Shall I go ahead and draft up an erratum or do you want to take up
on that yourself?

Best regards,
Daniel

--

-- 
CLUE-RIPE -- Jabber: dr <at> cluenet.de -- dr <at> IRCnet -- PGP: 0xA85C8AA0
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

Stephen Nadas | 28 Apr 2011 19:48
Picon
Favicon

Re: RFC5798 requires usage of RAs?

If you have cycles to propose text, that would be helpful, IMO. 
Thanks,
Steve  

-----Original Message-----
From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On Behalf Of Daniel Roesen
Sent: Thursday, April 28, 2011 1:20 PM
To: vrrp <at> ietf.org
Subject: Re: [VRRP] RFC5798 requires usage of RAs?

Hi,

On Thu, Apr 28, 2011 at 11:36:44AM -0400, Stephen Nadas wrote:
> Sorry for the delay.  I think the spec language could be better-
> (630) etc probably should have said something more like
> 
> "if ND RAs are in use, MUST send ND Router Advertisements for the virtual router. 

Indeed. Thanks for the confirmation.

My understanding of IETF procedures is, that an Errata submission would be possible, valid way to
unambiguate that language - which is advisable to prevent further implementation confusion.

Shall I go ahead and draft up an erratum or do you want to take up on that yourself?

Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr <at> cluenet.de -- dr <at> IRCnet -- PGP: 0xA85C8AA0 _______________________________________________
(Continue reading)


Gmane