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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 May 2018 15:08:47 +0000

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-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: mercredi 25 avril 2018 11:54
To: [email-masked]
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

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 21 May 2018 09:40:11 -0700

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 May 2018 17:18:38 +0000

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.
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?

Pascal

From: 6lo <[email-masked]> On Behalf Of Charlie Perkins
Sent: lundi 21 mai 2018 18:40
To: [email-masked]
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.

       0                   1                   2                   3

   Modified Message Fields:

9.2.  ICMP Codes

All the best,

Pascal
From: 6lo <[email-masked]><mailto:[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: mercredi 25 avril 2018 11:54
To: [email-masked]<mailto:[email-masked]>
Subject: [6lo] Future extensibility for the DAR/DAC

Dear all :

Pascal

6lo mailing list

[email-masked]<mailto:[email-masked]>

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 21 May 2018 10:36:51 -0700

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-masked]> *On Behalf Of *Charlie Perkins
> *Sent:* lundi 21 mai 2018 18:40
> *To:* [email-masked]
> *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 
>     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.
>
>        |              | field                                
>        |              | field                                
>        |              | field                                
>        |              | field                                
>        | 5...15       | Unassigned                           
>        |             | field                                 
>        |             | field                                 
>        |             | field                                 
>        |             | field                                 
>        | 5...15      | Unassigned                            
>     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-masked]> <mailto:[email-masked]>
>     *On Behalf Of *Pascal Thubert (pthubert)
>     *To:* [email-masked] <mailto:[email-masked]>
>     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.
>
>     extensions (e.g., options at the end of the message) and stay
>     backward compatible.
>
>     [email-masked] <mailto:[email-masked]>
>
>     https://www.ietf..org/mailman/listinfo/6lo
>     <https://www.ietf.org/mailman/listinfo/6lo>
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 May 2018 18:31:48 +0000

Hello Charlie;

Le 21 mai 2018 à 19:36, Charlie Perkins <[email-masked]<mailto:[email-masked]>> a écrit :

Hello Pascal,

I do not understand that; how would anode that implements this spec process a code of 10?

Yes! By legacy I mean a node that implements this spec; facing anode that implements a future spec and needs new codes

True; I m saying that not splitting makes believe there is a saving when in fact there is none but obfuscation

The split proposal already mandates ignoring all CodePfx values other than zero.

No! It is ignored by a receiver implementing this spec. If the future requires an option or something that can be ignored by legacy node that only knows this spec, the split format enables to provide a code to indicate the option and still provide the length of the ROVR in a backward compatible fashion.

Unless I am missing something, the split takes away future flexibility but returns no reward for backward compatibility.

Not splitting does that since a node implementing this spec could not compute the length of the ROVR field for a new code.

The goal of the split is exactly to solve that issue; it enables to use new code prefixes as long as they can be ignored when received by a legacy node.

Does it make more sense now?

Pascal

Regards,
Charlie P.

What do others think?

Pascal

From: 6lo <[email-masked]><mailto:[email-masked]> On Behalf Of Charlie Perkins
Sent: lundi 21 mai 2018 18:40
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [6lo] Future extensibility for the DAR/DAC

Hello folks,

Regards,
Charlie P.

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

   Modified Message Fields:

9.2.  ICMP Codes

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

Dear all :

Pascal

6lo mailing list

https://www.ietf..org/mailman/listinfo/6lo<https://www.ietf.org/mailman/listinfo/6lo>

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 21 May 2018 14:50:23 -0700

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-masked] 
> <mailto:[email-masked]>> a écrit :
>
>> Hello Pascal,
>>
>>> 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.
>>>
>>
> 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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 22 May 2018 05:38:37 +0000

Hello Charlie:

You have to admit that the word "legacy" in previous emails was open to ambiguity.

Yes :)
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.

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?

Yes; there is no room for that field and even the ROVR type is somewhat lacking

  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.

Well, old legacy Ignore the ICMP code so that much is not a requirement. But then they support only ROVR size of 64 bits.
The situation of a legacy can be discovered with our spec and there is always the fallback situation of avoiding new incompatible stuff.

If you agree with this reformulation, then I think the answer is clearly to define some length bits somewhere.

Yes, and even better would have been more room for a ROVR type too.

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.

This is why I carved 4 bits, yes.

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.

Maybe a future non compatible format will use it differently in a situation with no new legacy device. I’d prefer indicating both; it is a sub code and it indicates the ROVR size.

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.

Agreed but an option is already coming up for using DAR DAC on the backbone. Anyway an inextensible message would be a great waste of ICMP space.

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.

But old legacy will set those bits randomly. And then we have alignment problems. I proposed the subcode as a last resort...

Take care,

Pascal

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 22 May 2018 07:49:54 -0700

Hello Pascal,

Seems we are mostly in agreement.  But see below...

On 5/21/2018 10:38 PM, Pascal Thubert (pthubert) wrote:

>> 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.
>>
>
> But old legacy will set those bits randomly. And then we have 
> alignment problems. I proposed the subcode as a last resort...

I don't think it's a problem for old legacy.  New-legacy 6LR should 
detect old-legacy 6LN and maintain legacy-ness as part of the 
registration state.  ROVR would have sizes of 61, 125, 189, or 253 
bits.  Again, not a problem, and alignment is not an issue.

Plus as a bonus we get to have our Code back as a normal Code field.

It just needs to be checked that new-legacy 6LR can detect old-legacy 6LN.

Regards,
Charlie P.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 May 2018 11:19:54 -0400

> 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. 

    > 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.

    > be 2, 3 or 4, denoting a ROVR size of 128, 192, and

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-masked]  http://www.sandelman.ca/        |   ruby on rails    [