Subject: IPv6 Options alignment and padding problem //RE: [2nd] Working Group Last Call for draft-ietf-6man-mtu-option-06

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wed, 18 Aug 2021 09:59:39 +0000

Hi WG,

I do not object the last call after re-reading the document.

However, it reminds me a question about the alignment of IPv6 Option fields in HBH/DOH.

RFC8200 says:
   Each extension header is an integer multiple of 8 octets long, in
   order to retain 8-octet alignment for subsequent headers.  Multi-
   octet fields within each extension header are aligned on their
   natural boundaries, i.e., fields of width n octets are placed at an
   integer multiple of n octets from the start of the header, for n = 1,
   2, 4, or 8.

The option defined in this document has a field of 15 bits, and another field of 1 bits, meaning that forwarding plane can parse an option to every bit.
What's the significance of alignment requirement for the "multi-octet fields" to be on their "natural boundaries" !?

Also, there are many other examples showing the discomfort of the alignment rule:
1. RFC6971 The IP_DFF option has a field of 2 octets, but it does not aligned on the "natural boundaries". 
2. RFC4782 the Quick-Start option has a field of 31 bits. RFC6621 the SMF_DPD option has a field of 31 bits.
3. RFC6788 the Line_Id Option has field of variable-length.
4. RFC6744 the ILNP Nonce option has field of TLV, and gives a different approach to self-align within the Option.
5. RFC8200 example 2 and 3 in Appendix A show that, the alignment rule are causing problems to use more than one Paddings!

IMHO the alignment requirement in RFC8200 need to be revised.

Regards,
Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, August 18, 2021 3:12 PM
To: 6man WG <[email-masked]>
Cc: Gorry (erg) <[email-masked]>; 6man Chairs <[email-masked]>
Subject: [2nd] Working Group Last Call for draft-ietf-6man-mtu-option-06

Just a reminder of the WGLC for the MTU option.
Thanks for the comments so far.

Are there anyone who would volunteer to do a very thorough review as part of the WGLC as well?

Best regards,
Ole, co-chair 6man.

This message starts a new two week 6MAN Working Group Last Call on advancing:

  Title           : IPv6 Minimum Path MTU Hop-by-Hop Option
  Authors         : Robert M. Hinden
                    Godred Fairhurst
  Filename        : draft-ietf-6man-mtu-option-06.txt
  Pages           : 19
  Date            : 2021-08-07

https://datatracker.ietf.org/doc/draft-ietf-6man-mtu-option/

as an Experimental Track document.

Substantive comments and statements of support for publishing this document should be directed to the [email-masked] mailing list. Editorial suggestions can be sent to the author.

This last call will end on 23 August 2021.

Thanks,
Ole

---

From: [email-masked]
Date: Wed, 18 Aug 2021 12:35:20 +0200

Jingrong,

> What's the significance of alignment requirement for the "multi-octet fields" to be on their "natural boundaries" !?

The option consist of two 16 bit octets. So it is naturally aligned on a 16 bit boundary.
You are right though, it should have specified that in the document. An alignment of 2n presumably.

The whole HBH header has to be a length of multiples of 8. And aligned on a 64 bit boundary.
The HBH header with only the MTU option will have to have two bytes of padding.

> IMHO the alignment requirement in RFC8200 need to be revised.

I'm not sure I see what problem you are alluding to.
The alignment requirements for the container headers and for the options inside are two separate things.

Now that said, the benefits of having the IPv6 headers 64 bit aligned are questionable, but so would likely relaxing them at this point...

Best regards,
Ole

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wed, 18 Aug 2021 12:25:23 +0000

Hi Ole,

<xjr>
I only see the problem of "options alignment", and don't see the problem of "container header alignment (of 8 bytes or 64 bit )".

Each "container header" has a "Ext Hdr Len" field which requires to be the length of the header in 8-octet units and not including the first 8 octets. So the "container header alignment (of 8 bytes)" requirement is solid.

My question is about IPv6 options alignment and padding problem, that is the following sentence in RFC8200:
   Multi-octet fields within each extension header are aligned on their
   natural boundaries, i.e., fields of width n octets are placed at an
   integer multiple of n octets from the start of the header, for n = 1,
   2, 4, or 8.

What I would like to relax is the alignment requirement of the "multi-octet fields" above, not the container header. Some typical reasons: 

(1) draft-ietf-6man-mtu-option-06 has two "non Multi-octet fields" ---- a field of 15-bit, and a field of 1-bit. 
  There are many other examples of "non Multi-octet fields" in an IPv6 option.
  They make the alignment requirement to "multi-octet fields" meaningless, because forwarding plane should be able to parse an option to every bit (think about those non Multi-octet fields).

(2) RFC6971 The IP_DFF option has a field of 2 octets (the Sequence Number field), but it is not aligned on the "natural boundaries". Please find "IPv6 DFF Header" in the rfc.

Thanks
Jingrong

---

From: [email-masked]
Date: Wed, 18 Aug 2021 14:38:44 +0200

Jingrong,

>  They make the alignment requirement to "multi-octet fields" meaningless, because forwarding plane should be able to parse an option to every bit (think about those non Multi-octet fields).

For the MTU option an implementation could access these fields as two aligned 16 bit values.
Then mask out the 15-bit and 1-bit sub-fields.

> (2) RFC6971 The IP_DFF option has a field of 2 octets (the Sequence Number field), but it is not aligned on the "natural boundaries". Please find "IPv6 DFF Header" in the rfc.

RFC8200 has this as a may:
   Individual options may have specific alignment requirements, to
   ensure that multi-octet values within Option Data fields fall on
   natural boundaries.

Best regards,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Wed, 18 Aug 2021 11:02:11 -0700

> > (2) RFC6971 The IP_DFF option has a field of 2 octets (the Sequence Number field), but it is not aligned on the "natural boundaries". Please find "IPv6 DFF Header" in the rfc.
Ole,

The reason for the convention to align fields to their natural
alignment is to make it easy on host CPUs when accessing the fields.
Most modern CPU architectures can handle unaligned accesses
efficiently, however there are still architectures in deployment, such
as Sparc, that take a software trap on unaligned accesses-- very
costly for performance. While it's good practice to try to align
individual fields, IMO it is still quite important to ensure that
various headers are aligned to at least 32 bits, lest some
implementations would have serious performance issues processing a
whole bunch of unaligned protocol fields.

Tom

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Thu, 19 Aug 2021 01:52:55 +0000

Hi Ole, WG,

<xjr>
I think my problem has been solved.
The "may" sentence shows that the alignment requirement of multi-octet field is not mandatory, but optional.
No need to revise RFC8200 about the alignment requirement of multi-octet field.

This also explains:
1) RFC8200 Appendix A "These guidelines are based on the following assumptions... any multi-octet fields be aligned on their natural boundaries".
2) RFC6971 doesn't align its multi-octet field.
3) Many (Most!) RFCs and drafts don't have align requirement of multi-octet field in its option design. The alignment requirement none is explicitly claimed in Pad0/PadN in RFC8200.

Appreciate very much for the discussion to make this clear. 

Regards,
Jingrong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 18, 2021 8:39 PM
To: Xiejingrong (Jingrong) <[email-masked]>
Cc: 6man WG <[email-masked]>; Gorry (erg) <[email-masked]>; 6man Chairs <[email-masked]>
Subject: Re: IPv6 Options alignment and padding problem //RE: [2nd] Working Group Last Call for draft-ietf-6man-mtu-option-06

Jingrong,

Best regards,
Ole

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Thu, 19 Aug 2021 02:36:59 +0000

Hi Tom,

While it's good practice to try to align individual fields
<xjr> Agreed. Bottom line a multi-octet field should be on octet-boundary (bitposition-0/8/16/24).
If a multi-octet field is designed at bitposition-1/2/3/4/5/6/7, I think it is very strange and very unlikely to happen.

IMO it is still quite important to ensure that various headers are aligned to at least 32 bits
<xjr> That is perfect if an option is designed to be used exclusively (HBH/DOH carrying only this option). 
However, if an option is designed to be used cooperatively with other options, then it may be a good balance to align to 8 bits (comparing to example 2 and 3 in RFC8200 Appendix A).

Regards,
Jingrong