Pascal Thubert (pthubert) <[email protected]> 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 [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
