Re: late question/comment on vrrp-unified-spec-02: IPv4equivalence

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  

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 
> Sent: Wednesday, November 05, 2008 22:44
> To: Stephen Nadas
> Cc: James Carlson; [email protected]; 
> [email protected]; [email protected]
> Subject: Re: [VRRP] late question/comment on 
> vrrp-unified-spec-02: IPv4equivalence
> 
>  20081103 23:18, Stephen Nadas :
> > 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.  
> 
> [It's strange that I didn't get Jim's original email, 
> although I subscribed to [email protected]. 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
> 
> > 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 protected]]
> >> Sent: Thursday, October 30, 2008 14:28
> >> To: Stephen Nadas
> >> Cc: [email protected]
> >> 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 protected]>
> >> 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 protected]
> > https://www.ietf.org/mailman/listinfo/vrrp
> 
> 
_______________________________________________
vrrp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/vrrp