Hello Pascal,
You have to admit that the word "legacy" in previous emails was open to
ambiguity.
So let's define "old-legacy" to mean RFC 6775, and "new-legacy" to mean
rfc6775-update-only. With that terminology, I will re-write my earlier
comment.
On 5/21/2018 11:31 AM, Pascal Thubert (pthubert) wrote:
Hello Charlie;
Le 21 mai 2018 à 19:36, Charlie Perkins <[email protected]
<mailto:[email protected]>> a écrit :
Hello Pascal,
I have some follow-up comments interspersed below.
On 5/21/2018 10:18 AM, Pascal Thubert (pthubert) wrote:
Hello Charlie :
This is not simple and I hope the list comes in and helps. The
reason for proposing the text below is to enable future codes to be
backward compatible with this spec.
My suggestion also allows future codes to be backward compatible, right?
I do not understand that; how would a node that implements this spec
process a code of 10?
In other words, how should we design variable-length ROVR fields so that
a new-legacy node can skip past unrecognized Codes for DAR and DAC but
still process their options? In addition, I think we want to obey the
constraint that old-legacy nodes can still interact with CodePfx=0 DAR
and DAC with ROVRs of 64 bits.
If you agree with this reformulation, then I think the answer is clearly
to define some length bits somewhere.
As currently proposed, we only need two length bits. But maybe future
messages will need longer verifications. With three length bits, we get
twice as many Codes and still very sufficient length signifiers. Maybe
we could have 64, 128, 192, 256, 512, 1024, 2048, rsvd.
I also think it is better to be explicit, and call the new field
"CodeSz" or something like that so that it is very clearly not a
"subtype" field.
If it were not needed to process options for these ICMP types, then I
think the ICMP length in the next header field would suffice.
Another possibility would be to reserve some initial bits of the ROVR
field itself to indicate the length of the ROVR. Old-legacy nodes
would still discard new DAR and DAC messages with a ROVR that was too
long. New-legacy nodes would know to check the first three or four bits
of the field for the length of the ROVR. But I did not think this all
the way through yet.
Regards,
Charlie P.
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
