Re: [dhcwg] Follow on I-D to RFC7227 (Guidelines for Creating New DHCPv6 Options)

[[e-mail]]

Hi Bernie, all,

Thank you for bring this to the list.

I do think that it is good to have some guidelines for these options to ensure consist option designs.

In one of the documents I'm editing, our initial approach was to consider the length fields themselves as fixed data and then place them first, then followed by the actual variable data. However, I do think Bernie made some good points in favor of 3.A.

Initial design

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       OPTION_V6_DNR           |         Option-length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         ADN Length            |     Addresses Length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   authentication-domain-name                  ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                        ipv6-address(es)                       ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
~                 Service Parameters (SvcParams)                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Updated if we proceed with 3.A

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       OPTION_V6_DNR           |         Option-length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         ADN Length            |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
~                   authentication-domain-name                  ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Addresses Length          |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
~                        ipv6-address(es)                       ~
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
~                 Service Parameters (SvcParams)                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I don't think there is much cost between count and length for fixed length data.

Cheers,
Med

De : dhcwg [mailto:[e-mail]] De la part de Bernie Volz (volz)
Envoyé : vendredi 30 avril 2021 17:26
À : [e-mail]
Objet : [dhcwg] Follow on I-D to RFC7227 (Guidelines for Creating New DHCPv6 Options)

Hi:

This is with WG co-chair Hat OFF.

RFC7227 did not cover structured options, i.e., those that carry a number of data items (fragment types as per RFC7227) and especially where more than one data item is variable in length (or an array/list of a fixed length type).

Therefore, I'm wondering if perhaps an additional I-D (or a 7227-bis) that would provide guidance on how these options should be constructed? I have wondered about this for a while, but a (off list) request from another WG about a potential new option caused me to initiate this query.

This advice might be:
1)      When an option consists of multiple "fragment types" where all fragment types are fixed in size, these can simple be constructed by concatenating the fixed length types.
2)      When an option consists of multiple "fragment types" where all but one are fixed in size, the variable sized item should be placed last as then the option-length - the fixed sizes determined its length (examples of this include the IA_NA and IA_PD, IAADDR and IAPREFIX, options - where the variable part is the encapsulated options).
3)      When an option consists of multiple "fragment types" where more than one is variable in size, is thus the real open question as to how best to format that. This would be the main focus of the document.

For (3), there are two basic formats to consider:
A)     For all variable length "fragment types" (except potentially the last), use a length + data encoding. Thus, if you had a string followed by a list of (v6) addresses followed by some "binary" data, this might be:
a.       Length of string in octets (assume 2-octets length)
b.      <length> octets of the string
c.       Length of list of addresses (for v6 addresses, this must be a multiple of 16) (assume 2-octets length)
d.      <length> octets of the addresses
e.      <length> octets of binary data -- length here is option-length - 2 + (length of string) + 2 + (length of list of addresses).
B)      Use some kind of structure that provides the "fixed" fields followed by the data. In the example in (A), this would be:
a.       Length of string in octets (assume 2-octets length)
b.      Length of list of addresses
c.       <length> octets of the string
d.      <length> octets of the list of addresses
e.      <length> octets of the binary data (length here is same for (A) case).

There's also a question as to whether for an array (list) of fixed length values, whether a length or count is better (of course, one can easily be converted to the other). I prefer a length as that is more consistent; but this is something to discuss too.

I personally prefer 3.A. is it makes creating a parser (text to binary; or vice versa) for option data much easier and definitions (to the parser) simpler. But often people prefer format (B) to make it (somewhat) quicker to find any particular data in an option. Case 3.A. requires a bit more processing to find (e) as the field (c) is not at a fixed offset (and also requires validating that (a) does not exceed the option length before accessing (c)). But I think that cost is minimal these days.

Note that while some may say that 3.B. has the data "better" aligned, but that is not true as DHCPv6 options inside the packet are byte aligned and thus one can never assume that the length fields are indeed aligned on a 16-bit boundary.

The guidance for 3.A. is easy to document in terms of rules and for parsers to handle with really no specialized code (as long as the parser knows the order of the fragment types, the fragment type, and if fixed length fragment type if it is an array):
1)      When all data items each fit into a single instance of fixed length fragment types, the option should just be these fragment types concatenated.
2)      When all but one of the data items is variable length or is an array (list) of fixed length fragment types, place the variable item at the end (and the option length minus the fixed length items determine its length).
3)      When multiple data items are variable length and/or arrays, prefix each of these (except the last in the option) with a length field; the length of the last variable length data item in the option can be determined by subtracting the sum of the size of the fixed length items, the lengths, plus 2 times the number of length fields.

Anyway, I'm raising this to the WG to see:
-          What thoughts people may have on which format we should promote (if any)
-          Whether people feel that a document that provides this guidance is useful for future option definitions (we obviously cannot change what already exists)
-          And if so, whether a new document or a 7227-bis are best way forward

So if you have thoughts, please post them to the list.

Depending of feedback, I may start an individual submission draft.

-          Bernie Volz


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.