Re: [conex] Length of conex-destopt?
Bob Briscoe <bob.briscoe@bt.com> Wed, 08 October 2014 08:04 UTC
Return-Path: <bob.briscoe@bt.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 14BB11A00BA for <conex@ietfa.amsl.com>; Wed, 8 Oct 2014 01:04:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.386
X-Spam-Level:
X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, 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 0Rt4qCz-6lp3 for <conex@ietfa.amsl.com>; Wed, 8 Oct 2014 01:04:17 -0700 (PDT)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A321A00B6 for <conex@ietf.org>; Wed, 8 Oct 2014 01:04:16 -0700 (PDT)
Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 8 Oct 2014 09:04:14 +0100
Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 8 Oct 2014 09:04:14 +0100
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Wed, 8 Oct 2014 09:04:08 +0100
Received: from BTP075694.jungle.bt.co.uk ([10.109.156.157]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s98845KE010957; Wed, 8 Oct 2014 09:04:05 +0100
Message-ID: <201410080804.s98845KE010957@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 08 Oct 2014 09:04:05 +0100
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <E87B771635882B4BA20096B589152EF62889F968@eusaamb107.ericss on.se>
References: <201410062206.s96M6VGI003992@bagheera.jungle.bt.co.uk> <E87B771635882B4BA20096B589152EF62889F968@eusaamb107.ericsson.se>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_1104828330==.ALT"
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Archived-At: http://mailarchive.ietf.org/arch/msg/conex/eCvQ7px9LqCq9oOqOlFTkGmsct4
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 08:04:22 -0000
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 > >-----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 <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 ________________________________________________________________ Bob Briscoe, BT
- [conex] Length of conex-destopt? Bob Briscoe
- Re: [conex] Length of conex-destopt? Suresh Krishnan
- Re: [conex] Length of conex-destopt? Bob Briscoe