Re: [6lo] Future extensibility for the DAR/DAC

[Michael Richardson <[e-mail]>]

Pascal Thubert (pthubert) <[e-mail]> wrote:
    > As written a non-zero split-code is ignored, and a legacy node can
    > still parse the ROVR correctly when a future node uses a non-zero
    > split-code.
    
    > If we do not split the code, the legacy node cannot parse the message
    > at all if the code is not one of the listed ones, since it cannot
    > fathom the size of the ROVR.
    
    > Also, if all ROVR sizes are still supported in the future, the addition
    > of a new code will in fact cause the addition of as many codes as there
    > are ROVR sizes. 

    > All in all I favor the proposed text that splits the ICMP code.

    > What do others think?

I am having difficulties understanding the constraints of the problem space.

I think that some of the difficulty (and apathy) is because perhaps there
isn't that much DAR/DAC code out there which we need to be compatible with.
Or the people who maintain that code aren't here.

    > Code:           The ICMP Code as defined in [RFC4443].  With this
    > specification, the ICMP Code for Duplicate Address
    > Messages is split in 2 fields, the Code Prefix and
    > the Code Suffix, each a 4-bits field.  The Code
    > Prefix MUST be set to zero by the sender and MUST be
    > ignored by the receiver.  A non-null value of the
    > Code Suffix indicates support for this specification.
    > It MUST be set to 1 when operating in a backward-
    > compatible mode with a ROVR size of 64 bits.  It MAY
    > be 2, 3 or 4, denoting a ROVR size of 128, 192, and
    > 256 bits, respectively.

I'm not really sure I understand how this enables backwards compatibility.
It seems that a sender needs to know that the receiver is old, is that
correct?

    > As it stands in RFC 6775 update, the fact that the DAR and DAC messages
    > are in fact extended DAR and DAC is indicated by the ICMP code of 1.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [