Subject: [conex] Length of conex-destopt?

From: Bob Briscoe <[email-masked]>
Date: Mon, 6 Oct 2014 23:06:17 +0100

Suresh,

Is there any reason why the CDO data field is 4 octets long? I think 
it only needs to consume 1 octet.

While I was reviewing conex-destopt I read RFC2460 more carefully 
than I have done before. I realised I had previously misread this 
sentence in <http://tools.ietf.org/html/rfc2460#section-4>Section 4: 
"Each extension header is an integer multiple of 8 octets long".

I thought it meant each option had to end on an 8-octet boundary 
(which is why I specified the 
<https://tools.ietf.org/html/draft-briscoe-conex-re-ecn-tcp-04#section-5.2>re-ECN 
IPv6 option data length as 4-octets - wrongly I now realise). 
However, it merely means that the whole destination options extension 
header must be an integer multiple of 8 octets.

According to <http://tools.ietf.org/html/rfc2460#section-4.2>Section 
4.2, each option within the destopt extension header (e.g. CDO) can 
be any length. Then, if there are more destopts to fit in a packet, 
IPv6 fits them in one after the other, and adds padding at the end of 
all the destopts to pad the whole extension header out to a multiple 
of 8 octets. The IPv6 implementation can also use padding options 
before any dest opts that contain multi-octet fields that need to be 
aligned on natural boundaries.

So the CDO can be only 1 octet long (plus 2 octets for type and 
length) 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
                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    | Opt type = CDO| Opt data len=1|
    +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |X|L|E|C| Resvd |
    +-+-+-+-+-+-+-+-+

Then, if there are no other destopts in a particular packet, IPv6 
would pad it out 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  HdrExtLen=0  | Opt type = CDO| Opt data len=1|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |X|L|E|C| Resvd | PadN type = 1 | Opt data len=1|       0       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where option type 1 is PadN, which in this case uses Opt data length 
= 1, which means there is 1 octet of zero-padding.

On the other hand, if for example a packet needed to contain CDO as 
well as some new destopt called 'NewOpt', assuming NewOpt has been 
defined with an alignment requirement of 4n+2 and an opt data length 
of 6, the destopt extension header would look like this:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  HdrExtLen=1  | Opt type = CDO| Opt data len=1|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |X|L|E|C| Resvd | Pad1 type = 0 | NewOpt type=XX| Opt data len=6|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       NewOpt data field       | PadN type = 1 | Opt data len=0|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Otherwise, with the 6-octet CDO as previously defined, the destop 
extension header would have to be much longer, 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  HdrExtLen=2  | Opt type = CDO| Opt data len=4|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |X|L|E|C|                   Reserved                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | PadN type = 1 | Opt data len=0| NewOpt type=XX| Opt data len=6|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       NewOpt data field       | PadN type = 1 | Opt data len=4|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               0                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Unless I'm wrong, I think we should change conex-destopt. Thoughts?

Bob

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 8 Oct 2014 03:01:19 +0000

Hi Bob,
The reason I made it 4 bytes is for future extensibility and not only for current use. Since we are defining a new kind of option that signals info to the network I thought it would be useful for someone who needs such option in the future to have a few extra bits around as cheap insurance. What do you think?

Thanks
Suresh

-----Original Message-----
From: Bob Briscoe [[email-masked]]
Received: Monday, 06 Oct 2014, 6:06PM
To: Suresh Krishnan [[email-masked]]
CC: Mirja KUEHLEWIND [[email-masked]]; ConEx IETF list [[email-masked]]
Subject: Length of conex-destopt?

Suresh,

Is there any reason why the CDO data field is 4 octets long? I think it only needs to consume 1 octet.

While I was reviewing conex-destopt I read RFC2460 more carefully than I have done before. I realised I had previously misread this sentence in Section 4<http://tools.ietf.org/html/rfc2460#section-4>: "Each extension header is an integer multiple of 8 octets long".

I thought it meant each option had to end on an 8-octet boundary (which is why I specified the re-ECN IPv6 option data length<https://tools.ietf.org/html/draft-briscoe-conex-re-ecn-tcp-04#section-5.2> as 4-octets - wrongly I now realise). However, it merely means that the whole destination options extension header must be an integer multiple of 8 octets.

According to Section 4.2<http://tools.ietf.org/html/rfc2460#section-4.2>, each option within the destopt extension header (e.g. CDO) can be any length. Then, if there are more destopts to fit in a packet, IPv6 fits them in one after the other, and adds padding at the end of all the destopts to pad the whole extension header out to a multiple of 8 octets. The IPv6 implementation can also use padding options before any dest opts that contain multi-octet fields that need to be aligned on natural boundaries.

So the CDO can be only 1 octet long (plus 2 octets for type and length) as follows:

    0                   1                   2                   3

Then, if there are no other destopts in a particular packet, IPv6 would pad it out as follows:

    0                   1                   2                   3

Where option type 1 is PadN, which in this case uses Opt data length = 1, which means there is 1 octet of zero-padding.

On the other hand, if for example a packet needed to contain CDO as well as some new destopt called 'NewOpt', assuming NewOpt has been defined with an alignment requirement of 4n+2 and an opt data length of 6, the destopt extension header would look like this:

    0                   1                   2                   3

Otherwise, with the 6-octet CDO as previously defined, the destop extension header would have to be much longer, as follows:

    0                   1                   2                   3

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 8 Oct 2014 09:04:05 +0100

Suresh,

Yeah, I did think that too, but...

Another (better?) way to do extensibility is to say that the sender 
MUST set the CDO option length = 1 but ConEx-aware nodes MUST accept 
an option length of 1 or longer. However, whatever the length, 
ConEx-aware nodes read the first 4 bits as defined.

Then, if a new spec is ever written, it can define new fields to 
whatever length it needs.

Bob

At 04:01 08/10/2014, Suresh Krishnan wrote:
>Hi Bob,
>The reason I made it 4 bytes is for future extensibility and not 
>only for current use. Since we are defining a new kind of option 
>that signals info to the network I thought it would be useful for 
>someone who needs such option in the future to have a few extra bits 
>around as cheap insurance. What do you think?
>
>Thanks
>Suresh
>
>However, it merely means that the whole destination options 
>extension header must be an integer multiple of 8 octets.
>
>IPv6 fits them in one after the other, and adds padding at the end 
>of all the destopts to pad the whole extension header out to a 
>multiple of 8 octets. The IPv6 implementation can also use padding 
>options before any dest opts that contain multi-octet fields that 
>need to be aligned on natural boundaries.
>