Re: [VRRP] draft-ietf-vrrp-unified-spec-03.txt

["Stephen Nadas" <[e-mail]>]

Hi Mukesh, 

Here's what I did, wrt checking IPv6 interop between (A)
draft-ietf-vrrp-ipv6-spec-08.txt and (B) draft-ietf-vrrp-unified-03.txt
(actually pre-04 which numbered all these steps - but otherwise this is
same as -03 for this purpose).   

Following the rest of this discussion in detail depends on looking at
the attachments. 

I looked at sections 6.4.1 (init) , 6.4.2 (backup)  , 6.4.3 (master),
7.1(recv) & 7.2(transmit).  I labeled all the IPv6 and IPVx (i.e., 4 and
6 steps in common) as follows: 

	- by section: i-init, b-backup, m-master, r-recv, t-transmit, 
	- then by "6" for (A) and "u" for (B) 
	- and then with an alphanumeric as an id 

(so m63 is master state's 3rd step in (A) and mu3 is master state's 3rd
step in (B); step mub is 11th master state step in unified, etc.).
Things that don't line up/or may need something changed are labeled XXX.


Differences: 

6.4.1 (init) 
      sections are same but perhaps for editorial changes. 

6.4.2 (backup) 
      unified adds a step between "bum" and "bun" that recomputes
Master_Down_Interval.  I think this went in as byproduct of Mark
Handley's review note:
http://www.ietf.org/mail-archive/web/vrrp/current/msg01003.html
 
      otherwise sections are same but perhaps for editorial changes. 

6.4.3 (master) 

      1) unified  missed a step between "m63/m64" that said "MUST
respond to ND rtr solicits"  - this appears to be an editor goof and
should be added to unified.         

      2) Unified added a step (635) between steps "mu3" and "mu4" that
says "if accept mode is false: MUST NOT drop IPv6 Neighbor Solicits and
N. Adverts."  Editorially it looks like that maybe better placed in
w/step (650).    

      3) Unified added 2 steps in between "muo" and "mup" to recompute
skew and master_down_interval.  See Mark Handley's note:
http://www.ietf.org/mail-archive/web/vrrp/current/msg01003.html

      otherwise sections are same but perhaps for editorial changes. 

7.1 recv 
    softened step "r68" into "ru8" and removed "r69" and "r6a" based on
Don Provan's note, which says it copied wrrp list, but I can't see in
archive.  Anyway it is attached. 

    otherwise sections are same but perhaps for editorial changes. 

7.2 transmit 
    sections are same but perhaps for editorial changes. 
    
    editorially, "XXX" and "tu2" are same and should be pulled outside
of the if.


I think unified fixes some small things.  Maybe I'm missing something
basic, but I think IPv6 implementations would interop w/unified
implementations without issues.  There could be some issues where
unified has fixed something but (A) would have these issues too. 


Steve 



   

SJN> -----Original Message-----
SJN> From: Stephen Nadas 
SJN> Sent: Tuesday, July 14, 2009 6:36 PM
SJN> To: 'Mukesh Gupta'; Pekka Savola
SJN> Cc: [e-mail]; [e-mail]; 
SJN> [e-mail]; [e-mail]; [e-mail]; Christian 
SJN> Vogt; Jari Arkko; [e-mail]; 
SJN> [e-mail]; 
SJN> [e-mail]; [e-mail]
SJN> Subject: RE: draft-ietf-vrrp-unified-spec-03.txt 
SJN> 
SJN> SJN> That's a good point.  Steve, could you please check 
SJN> the differences 
SJN> SJN> between the v6 parts of this spec and the 
SJN> vrrp-ipv6-spec and see if 
SJN> SJN> both the version will be interoperable or not?  If 
SJN> there are enough 
SJN> SJN> differences, we might have to increment the version 
SJN> number in this 
SJN> SJN> spec :(
SJN> 
SJN> I am thinking we didn't change any of the IPv6 (at least 
SJN> intentionally) but I will check and get back.  
SJN> 
SJN> Steve 

--- Begin Message ---

I have to admit, I don't recall why I'm being singled out for these
questions. Did I rewrite this at some point or something? I have to
admit, I've always found myself at odds with this part of the spec
because it always seems as if my philosophy is much more liberal than
the original intent. But I'll do my best to answer, anyway...

"1) the check that the _local router_ isn't the IPvX address owner need
not say anything about _Priority 255_.  Right?"

I assume the intent was to reinforce that priority 255 *means* "owner".
I agree that "priority 255" makes one think of the packet rather than
the interface, but I don't think it's entirely wrong since we do, in
fact, signify ownership only by assigning 255 as our priority on the VR.
But it is redundant, and you can remove it if you feel that redundancy
causes confusion. 

"That is confusing and
afaict irelevant (If I get an adv for an address I own I must drop  &
shld log)"

I'm not sure what you're confused about. The owner should always
ignore any attempts by someone else to control the VR, and that
appears to be what the paragraph is saying.

"2) I am confused about the check that the packet came from the address
owner.  (Why can't I can get an adv from a master who is not the address
owner, eg a dfferent backup for a down master address owner.)"

My interpretation is that the original intent was that advertisements
from owners should be given special attention because they are assumed
to be more correct than any other information, including the local
configuration. Any other non-owner master might be configured worse
than us, but the owner's configuration is assumed to be golden.

"Is this latter a stand alone check that is really needed? (or maybe
some
text that has just been carried along?)  it doesn't seem to have
anything to do with the preceding MAY (which seems to be essence of
Mark's comment.)"

As I recall, originally the ``MAY verify that "Count IPvX Addrs" and the
list of IPvX Address matches the IPvX Address(es) configured for the
VRID''
was a MUST, and that's probably where the "MUST drop" came from. I think
the idea was that we should ignore advertisements from routers with a
misconfiguration of the IP addresses unless it was the owner, in which
case we should consider ourselves wrong.

I've always felt that there was a latent flaw in the VRRP design that
called for it to distrust any other router except the owner. I believe
this was a mistaken attempt at security, but we've subsequently rejected
VRRP security itself as counter-productive, and I think we need to
extend this to these consistency checks. In this section, I think that
means only reporting any inconsistent configurations but always continue
with normal advertisement processing rather than ever dropping an
advertisement because it differs from the one we would send.

-don

-----Original Message-----
From: Stephen Nadas [mailto:[e-mail]] 
Sent: Monday, April 06, 2009 3:12 PM
To: Don Provan
Cc: [e-mail]; [e-mail]
Subject: May, should, must confusing section 7.1 vrrp 

Hi Don, 

I'm trying, once again, to clean this up.   Been busy elsewhere... 

Mark H. pointed out: 

> Section 7.1:
> 
> - MAY verify that "Count IPvX Addrs" and the list of IPvX Address
>       matches the IPvX Address(es) configured for the VRID
> 
>    If the above check fails, the receiver SHOULD log the event and MAY
>    indicate via network management that a misconfiguration 
> was detected.
>    If the packet was not generated by the address owner (Priority does
>    not equal 255 (decimal)), the receiver MUST drop the packet,
>    otherwise continue processing.
> 
> This combination of MAY, SHOULD and MUST is confusing.  Also 
> it's not clear if the second "If" is conditional on the first 
> "If".  It seems like you may have a mandatory action that you 
> can't do unless you do an optional action.
> 

So I agree it's confusing.  The text (from rfc, and -v6 and from
combined) all say the same.  In particular the immediately prior text
isn't much better: 

      - MUST verify that the VRID is configured on the receiving
        interface and the local router is not the IPv6 Address owner
        (Priority equals 255 (decimal)).

   If any one of the above checks fails, the receiver MUST discard the
   packet, SHOULD log the event and SHOULD indicate via network
   management that an error occurred.

      - MAY verify that the IPv6 Address matches the IPv6_Address
(As above...)

So here's my questions: 

1) the check that the _local router_ isn't the IPvX address owner need
not say anything about _Priority 255_.  Right?  That is confusing and
afaict irelevant (If I get an adv for an address I own I must drop  &
shld log)  

2) I am confused about the check that the packet came from the address
owner.  (Why can't I can get an adv from a master who is not the address
owner, eg a dfferent backup for a down master address owner.)  

Is this latter a stand alone check that is really needed? (or maybe some
text that has just been carried along?)  it doesn't seem to have
anything to do with the preceeding MAY (which seems to be essence of
Mark's comment.) 

Thanks,
Steve 

       

--- End Message ---