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

[Charlie Perkins <[e-mail]>]

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 <[e-mail]> *On Behalf Of *Charlie Perkins
> *Sent:* lundi 21 mai 2018 18:40
> *To:* [e-mail]
> *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 <[e-mail]> <mailto:[e-mail]>
>     *On Behalf Of *Pascal Thubert (pthubert)
>     *Sent:* mercredi 25 avril 2018 11:54
>     *To:* [e-mail] <mailto:[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] <mailto:[e-mail]>
>
>     https://www.ietf..org/mailman/listinfo/6lo
>     <https://www.ietf.org/mailman/listinfo/6lo>
>
>
>
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo