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

[Charlie Perkins <[e-mail]>]

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 <[e-mail]> *On Behalf Of * Pascal Thubert 
> (pthubert)
> *Sent:* mercredi 25 avril 2018 11:54
> *To:* [e-mail]
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo