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?
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.
I don't see how a legacy node can process anything but CodePfx=0/CodeSfx=0.
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.
But, see above. Or, are you referring to a "future legacy" node?
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.
But this is also inherently true if the Code field would be split.
All in all I favor the proposed text that splits the ICMP code.
The split proposal already mandates ignoring all CodePfx values other
than zero. Unless I am missing something, the split takes away future
flexibility but returns no reward for backward compatibility.
Regards,
Charlie P.
What do others think?
Pascal
*From:*6lo <[email protected]> *On Behalf Of *Charlie Perkins
*Sent:* lundi 21 mai 2018 18:40
*To:* [email protected]
*Subject:* Re: [6lo] Future extensibility for the DAR/DAC
Hello folks,
I think it would be better to avoid subdividing the Code field as
shown below. It may seem simple, but the effect would to require 16
subCodes for every future allocated Code, even if completely
unnecessary. Besides that, there is then the complication of
additional registries, review procedure, etc., which may not be needed
for future Codes.
Instead, for the purposes mentioned to enable options, I think it
makes a lot more sense to just allocate a different Code for each
proposed subcase of ROVR field length. As noted below, I think this
would mean 4 codes for DAR and 4 codes for DAC. That is really pretty
straightforward, besides only taking two bits instead of four per ICMP
type.
Regards,
Charlie P.
On 5/4/2018 8:08 AM, Pascal Thubert (pthubert) wrote:
Dear all :
The problem at hand is that the way draft 19 is formulated, the
DAR/DAC messages can never have options. This is barring future
capabilities, in particular using the DAR/DAC over the backbone as
discussed at the last IETF – I still need ot propose text on that.
To address this issue, I suggest that the initial use of the ICMP
code (at some point odd values would mean support to this spec) in
DAR/DAC message is extended so the size of the ROVR field is
clearly indicated in a subfield of the ICMP code.
The proposed change is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |CodePfx|CodeSfx| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Registration Ownership
Verifier ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Registered Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Duplicate Address Messages Format
Modified Message Fields:
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.
Also this means a chnage in the IANA section:
9.2. ICMP Codes
IANA is requested to create 2 new subregistries of the ICMPv6
"Code"
Fields registry, which itself is a subregistry of the Internet
Control Message Protocol version 6 (ICMPv6) Parameters for the ICMP
codes. The new subregistries relate to the ICMP type 157,
Duplicate
Address Request (shown in Table 3), and 158, Duplicate Address
Confirmation (shown in Table 4), respectively. For those ICMP
types,
the ICMP Code field is split in 2 subfields, the "Code Prefix" and
the "Code Suffix". The new subregistries relate to the "Code
Suffix"
portion of the ICMP Code. The range of "Code Suffix" is 0..15
in all
cases. The policy is "IETF Review" or "IESG Approval"
[RFC8126] for
both subregistries. The new subregistries are initialized as
follows:
New Code Suffixes for ICMP types 157 DAR message
+--------------+---------------------------------------+------------+
| Code Suffix | Meaning |
Reference |
+--------------+---------------------------------------+------------+
| 0 | RFC6775 DAR message | RFC
6775 |
| | | |
| 1 | EDAR message with 64bits-long ROVR | This
RFC |
| | field
| |
| | | |
| 2 | EDAR message with 128bits-long ROVR | This
RFC |
| | field
| |
| | | |
| 3 | EDAR message with 192bits-long ROVR | This
RFC |
| | field
| |
| | | |
| 4 | EDAR message with 256bits-long ROVR | This
RFC |
| | field
| |
| | | |
| 5...15 | Unassigned
| |
+--------------+---------------------------------------+------------+
Table 3: New Code Suffixes for the DAR message
New Code Suffixes for ICMP types 158 DAC message
+-------------+----------------------------------------+------------+
| Code Suffix | Meaning |
Reference |
+-------------+----------------------------------------+------------+
| 0 | RFC6775 DAC message | RFC
6775 |
| | | |
| 1 | EDAC message with 64bits-long ROVR | This
RFC |
| | field
| |
| | | |
| 2 | EDAC message with 128bits-long ROVR | This
RFC |
| | field
| |
| | | |
| 3 | EDAC message with 192bits-long ROVR | This
RFC |
| | field
| |
| | | |
| 4 | EDAC message with 256bits-long ROVR | This
RFC |
| | field
| |
| | | |
| 5...15 | Unassigned
| |
+-------------+----------------------------------------+------------+
Table 4: New Code Suffixes for the DAC message
Please let us know if there is an issue with this, cc’ing Adrian
since we discussed this unusual use of the ICMP Code during his
review.
All the best,
Pascal
*From:* 6lo <[email protected]> <mailto:[email protected]>
*On Behalf Of *Pascal Thubert (pthubert)
*Sent:* mercredi 25 avril 2018 11:54
*To:* [email protected] <mailto:[email protected]>
*Subject:* [6lo] Future extensibility for the DAR/DAC
Dear all :
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.
In that case, the size of the message determines the size of the
ROVR field that carries the ex-EUI-64 field, now ROVR field, which
can be extended up to 256 bits for use as a cryptographic proof of
ownership in AP-ND.
Keeping it that way may be problematic if we want to add future
extensions (e.g., options at the end of the message) and stay
backward compatible.
An alternate way is to block 2 bits of the ICMP code and use the
values 0, 1, 2, and 3 denoting a ROVR size of 64, 128, 192 and 256
bits respectively.
Should we / shouldn’t we do that?
Pascal
_______________________________________________
6lo mailing list
[email protected] <mailto:[email protected]>
https://www.ietf..org/mailman/listinfo/6lo
<https://www.ietf.org/mailman/listinfo/6lo>
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
