Subject: Re: [VRRP] late question/comment on vrrp-unified-spec-02: IPv4 equivalence

From: "Stephen Nadas" <[email-masked]>
Date: Mon, 3 Nov 2008 09:18:15 -0600

Hi James, 

I looked at 3768, which references 1256 as info and only refers to it as
one of several ways a host might get an IPv4 address.  As
vrrp-unified-spec-02 was heavily based on 3768 for its IPv4 sections,
this explains why it doesn't discuss this.  Ignoring unified question
for a moment, it looks to me that a 3768 compliant backup not running
1256 of a (3768 compliant) master that was running 1256 could hose a
1256 client.  

The question is what, if anything, to do?  As editor, first I'd like to
do nothing as 3768 was silent.  Failing that, maybe clone 8.2.3 into
8.1.x and mention possibility of 1256?  My understanding is that editor
is in a "waiting for guidance" mode just now; the vrrp list is silent,
so I've copied the necessary folks.  

Thanks,
Steve 

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]] 
> Sent: Thursday, October 30, 2008 14:28
> To: Stephen Nadas
> Cc: [email-masked]
> Subject: late question/comment on vrrp-unified-spec-02: IPv4 
> equivalence
> 
> I searched the list, and found no mention of this issue.  
> Apologies if my searching-fu is insufficient, and it's 
> already been dealt with, and also because I know that this is 
> an awfully late time to be bringing up a question like this.
> 
> Section 8.2.3 of the I-D goes into detail about handling IPv6 
> Router Advertisements, and that's probably a good thing, but 
> there's no equivalent language for IPv4 in section 8.1.
> 
> IPv4 also has ICMP router discovery, just like IPv6, and it 
> works in much the same way.  A loss of this service would 
> cause an outage for networks reliant on it, just as much as a 
> loss of RA is an outage for IPv6, and even though the 
> fail-over itself "works."  The RDISC entries in existing 
> hosts will age away, and new hosts will be completely in the 
> dark.  Shouldn't the proper operation of RFC 1256 be included?
> 
> In that same vein, it's not actually just ICMP router 
> discovery that may be at issue here.  Different network 
> deployments use different router-to-host signaling mechanisms 
> for basic routing information needed by hosts.  In some 
> cases, for v4 at least, that can be delivered by DHCP.  But 
> in other cases, it might be simple RIP default route 
> advertisements.  It's unclear why, when used as an "output only"
> router discovery mechanism, RIP would be excluded.
> 
> Instead of treating this issue as v6-specific and RDISC-only, 
> might it be better to have a section that explains that all 
> router-to-host configuration signaling needs to be preserved 
> by the current Master?
> (And then, if you like, enumerate some known examples, such 
> as IPv4 and IPv6 RAs.)
> 
> I suspect that naming only IPv6 RAs as an issue could lead to 
> uneven implementation by the unwary.
> 
> -- 
> James Carlson, Solaris Networking              
> <[email-masked]>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 
> 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> 781 442 1677
> 
_______________________________________________
vrrp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vrrp

---

From: "Stephen Nadas" <[email-masked]>
Date: Mon, 3 Nov 2008 10:15:16 -0600

> 
> > The question is what, if anything, to do?  As editor, first 
> I'd like 
> > to do nothing as 3768 was silent.
> 
> By that token, it was also silent about router discovery in 
> an IPv6 environment.

I'm a bit confused here, bcos 3768 was IPv4 only. 

Thanks,
Steve

---

From: Huafeng Lu <[email-masked]>
Date: Thu, 06 Nov 2008 11:43:35 +0800

> 1256 of a (3768 compliant) master that was running 1256 could hose a

[It's strange that I didn't get Jim's original email, although I 
subscribed to [email-masked]. I searched on the email archive, still 
didn't find it, though.]

Hi, Stephen,

Any updates on this issue?

My understanding to this question is that, Jim was talking about the 
mechanism how to prevent the backup from announcing itself as a router. 
vrrp-unified-spec-02 explains in details for IPv6 (not responding to RS, 
not sending RA, not set R flag in NA), but says nothing about IPv4. This 
is strange.

Since the standard (RFC and the draft) doesn't mention it, what should 
people do if we want to implement the VRRP protocol? Logically I'd 
choose to do the similar thing for IPv4 (not responding to IPv4 RS, not 
sending IPv4 RA, as defined in 1256. Did I miss anything?) But will this 
be considered an violation to the standard (since it's not currently 
defined in the standard)? Looks like you agreed to improve the draft to 
include this; when will this happen?

Thanks.
--
Huafeng

---

From: "Stephen Nadas" <[email-masked]>
Date: Thu, 6 Nov 2008 09:53:33 -0600

Hi Huafeng, 

There is discussion at VRRP list on this and other issues as draft is undergoing IESG review and will be updated sometime after that has concluded and any issues have been worked out. 

For updates I suggest checking VRRP list archive. 

Steve  

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, November 05, 2008 22:44
> To: Stephen Nadas
> Cc: James Carlson; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [VRRP] late question/comment on 
> vrrp-unified-spec-02: IPv4equivalence
> 
> > I looked at 3768, which references 1256 as info and only 
> refers to it 
> > as one of several ways a host might get an IPv4 address.  As
> [It's strange that I didn't get Jim's original email, 
> although I subscribed to [email-masked]. I searched on the 
> email archive, still didn't find it, though.]
> 
> Hi, Stephen,
> 
> My understanding to this question is that, Jim was talking 
> about the mechanism how to prevent the backup from announcing 
> itself as a router. 
> vrrp-unified-spec-02 explains in details for IPv6 (not 
> responding to RS, not sending RA, not set R flag in NA), but 
> says nothing about IPv4. This is strange.
> 
> Since the standard (RFC and the draft) doesn't mention it, 
> what should people do if we want to implement the VRRP 
> protocol? Logically I'd choose to do the similar thing for 
> IPv4 (not responding to IPv4 RS, not sending IPv4 RA, as 
> defined in 1256. Did I miss anything?) But will this be 
> considered an violation to the standard (since it's not 
> currently defined in the standard)? Looks like you agreed to 
> improve the draft to include this; when will this happen?
> 
> Thanks.
> --
> Huafeng
> 
> > to do nothing as 3768 was silent.  Failing that, maybe clone 8.2.3 
> > into 8.1.x and mention possibility of 1256?  My 
> understanding is that 
> > editor is in a "waiting for guidance" mode just now; the 
> vrrp list is 
> > silent, so I've copied the necessary folks.
> > 
> > Thanks,
> > Steve
> > 
> already been 
> >> dealt with, and also because I know that this is an 
> awfully late time 
> >> to be bringing up a question like this.
> >>
> >> Section 8.2.3 of the I-D goes into detail about handling 
> IPv6 Router 
> >> Advertisements, and that's probably a good thing, but there's no 
> >> equivalent language for IPv4 in section 8.1.
> >>
> >> IPv4 also has ICMP router discovery, just like IPv6, and 
> it works in 
> >> much the same way.  A loss of this service would cause an 
> outage for 
> >> networks reliant on it, just as much as a loss of RA is an 
> outage for 
> >> IPv6, and even though the fail-over itself "works."  The RDISC 
> >> entries in existing hosts will age away, and new hosts will be 
> >> completely in the dark.  Shouldn't the proper operation of 
> RFC 1256 
> >> be included?
> >>
> discovery that 
> >> may be at issue here.  Different network deployments use different 
> >> router-to-host signaling mechanisms for basic routing information 
> >> needed by hosts.  In some cases, for v4 at least, that can be 
> >> delivered by DHCP.  But in other cases, it might be simple RIP 
> >> default route advertisements.  It's unclear why, when used as an 
> >> "output only"
> >> Instead of treating this issue as v6-specific and 
> RDISC-only, might 
> >> it be better to have a section that explains that all 
> router-to-host 
> >> configuration signaling needs to be preserved by the 
> current Master?
> >> (And then, if you like, enumerate some known examples, 
> such as IPv4 
> >> and IPv6 RAs.)
> >>
> >> I suspect that naming only IPv6 RAs as an issue could lead 
> to uneven 
> >> implementation by the unwary.
> >>
> >> --