Re: [conex] Length of conex-destopt?

Suresh Krishnan <suresh.krishnan@ericsson.com> Wed, 08 October 2014 03:01 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0672A1A9033 for <conex@ietfa.amsl.com>; Tue, 7 Oct 2014 20:01:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ovr8EkcOFjZj for <conex@ietfa.amsl.com>; Tue, 7 Oct 2014 20:01:30 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 547A51A02FC for <conex@ietf.org>; Tue, 7 Oct 2014 20:01:29 -0700 (PDT)
X-AuditID: c618062d-f79206d0000014d2-be-543452196c81
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id BC.91.05330.91254345; Tue, 7 Oct 2014 22:50:34 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Tue, 7 Oct 2014 23:01:19 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: "bob.briscoe@bt.com" <bob.briscoe@bt.com>
Thread-Topic: Length of conex-destopt?
Thread-Index: AQHP4bHNddcZg8ThkUOnRaQaZjnH+5wlhOAh
Date: Wed, 08 Oct 2014 03:01:19 +0000
Message-ID: <E87B771635882B4BA20096B589152EF62889F968@eusaamb107.ericsson.se>
References: <201410062206.s96M6VGI003992@bagheera.jungle.bt.co.uk>
In-Reply-To: <201410062206.s96M6VGI003992@bagheera.jungle.bt.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_E87B771635882B4BA20096B589152EF62889F968eusaamb107erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXSPn65UkEmIweX5rBbT139htDh07Sej xYbVU1gcmD3avkxm8liy5CeTx7EPX9kCmKO4bFJSczLLUov07RK4Ml43fGYqaJzIWLFs1zKm BsbTVV2MnBwSAiYSZ+6dYoOwxSQu3FsPZHNxCAkcZZS4c2sBC4SzjFHiUnM3C0gVG1DHhp2f mUBsEQFdiVuvXjCC2MwCORJPnt4AmyQsoCrx7/R6qBo1iZvf57NA2EYSOxZ/B7NZBFQkJr/8 yA5i8wr4SjxqPQhkcwAtc5KYtgSshFPAWeLqlo1gJYxAx30/tYYJYpW4xK0n85kgjhaQWLLn PDOELSrx8vE/VoiafInJy9cxQowXlDg58wnLBEaRWUjaZyEpm4WkDCKuI7Fg9yc2CFtbYtnC 18ww9pkDj5mQxRcwsq9i5CgtTi3LTTcy2MQIjKljEmy6Oxj3vLQ8xCjAwajEw7vghlGIEGti WXFl7iFGaQ4WJXHeWbXzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwbv27r95y56+7pe7X ls1z3SacPVHGU9D9htPWEqs/fGm/Mxecm1J/lsvdxrBeeM+R3SVJzC/jor5vvFbxICAz+/wk UYn0k68vPRJqkAq3mXD2u/OmWtEIlX/NS75/edL397PWI7dvQs4+tmUC0ivSfZ+/l2Z+Lr3R wn2bVIpz5csNjaXBG98sVGIpzkg01GIuKk4EAFlGfkKKAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/conex/dZ1O9iygu7LGlN7U7DS5wZG6WAM
Cc: "conex@ietf.org" <conex@ietf.org>
Subject: Re: [conex] Length of conex-destopt?
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex/>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Oct 2014 03:01:33 -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 [bob.briscoe@bt.com]
Received: Monday, 06 Oct 2014, 6:06PM
To: Suresh Krishnan [suresh.krishnan@ericsson.com]
CC: Mirja KUEHLEWIND [mirja.kuehlewind@tik.ee.ethz.ch]; ConEx IETF list [conex@ietf.org]
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
    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