Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03

Joe Touch <touch@isi.edu> Thu, 26 May 2016 20:00 UTC

Return-Path: <touch@isi.edu>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129E912D7EE for <int-area@ietfa.amsl.com>; Thu, 26 May 2016 13:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.326
X-Spam-Level:
X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
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 jkQ9Fi3nwV35 for <int-area@ietfa.amsl.com>; Thu, 26 May 2016 13:00:13 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A7112D1AD for <int-area@ietf.org>; Thu, 26 May 2016 13:00:13 -0700 (PDT)
Received: from [128.9.184.137] ([128.9.184.137]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u4QJxdWh026261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 26 May 2016 12:59:40 -0700 (PDT)
To: Tom Herbert <tom@herbertland.com>, "Templin, Fred L" <Fred.L.Templin@boeing.com>
References: <E83B905A-FF6D-4996-B71A-7921DE4B133B@ericsson.com> <CAPt1N1=UTDghtSmw6+x=OQsvkSLHs2Gyi8ZeSK4a2L=bwqK57Q@mail.gmail.com> <CALx6S36rMbOniAKYHifwPE0eQtDg+CwDXwPG02NZ2yVSx5xadg@mail.gmail.com> <cfd23a013e544312b857374933e97106@XCH15-05-05.nw.nos.boeing.com> <CALx6S36SsdTNOT=5VzX27_r=iadONwmz9+qPxPWJ1+f1i25YtA@mail.gmail.com> <f0752fc49e9d44ce9b301c40d4aafc63@XCH15-05-05.nw.nos.boeing.com> <57472576.3040501@isi.edu> <ce3d752685264ce7a7d8f11f189c622c@XCH15-05-05.nw.nos.boeing.com> <57472AD8.1090200@isi.edu> <c0277cce5b744fc6b38638e41845ca5a@XCH15-05-05.nw.nos.boeing.com> <956622dd-93f3-2a9e-51b8-16db1598776e@isi.edu> <CALx6S34vY3-TRiLVCWWSiEJHuOneX=562a+VeuN3VzBBVDB2iw@mail.gmail.com> <574738E0.2050206@isi.edu> <CALx6S34v-Z=nm57NbFQxY7Ju3JaxvADkZXR=Vc-9qWfpD3qpBg@mail.gmail.com> <57473FC5.2000303@isi.edu> <68f9e30c6fc34a42b7b07cb1af46dd39@XCH15-05-05.nw.nos.boeing.com> <CALx6S36ohj2jf1JEzuRHH0WWNKLSLvxrzip9Wr4zt-FXV0L3uA@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <574755AB.3010803@isi.edu>
Date: Thu, 26 May 2016 12:59:39 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <CALx6S36ohj2jf1JEzuRHH0WWNKLSLvxrzip9Wr4zt-FXV0L3uA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/int-area/iPhv9OYGtr_lUZjEF4CYovuqRZM>
Cc: "int-area@ietf.org" <int-area@ietf.org>
Subject: Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 May 2016 20:00:15 -0000

FWIW:

Another caveat about using the header check to avoid the GUE header for
IPv4 and IPv6:

    (A)- looking for only bit 01=1 would expect raw IP encapsulation for
versions 4-7 and 12-15, leaving out 8-11 (of which 10 and 11 are still
possible)

    (B)- looking for either 01, 10, or 11 would allow all future IP
versions but prevent GUE from having versions of its own

Of these two, IMO, (A) is preferable, but I would strongly suggest:

    (C)- match "01" means native IP, supporting only currently-used
versions 4 and 6
    - define "10" and "11" as Reserved for future use

Joe

On 5/26/2016 11:52 AM, Tom Herbert wrote:
> On Thu, May 26, 2016 at 11:35 AM, Templin, Fred L
> <Fred.L.Templin@boeing.com> wrote:
>> Hi Joe and Tom,
>>
>>> -----Original Message-----
>>> From: Joe Touch [mailto:touch@isi.edu]
>>> Sent: Thursday, May 26, 2016 11:26 AM
>>> To: Tom Herbert <tom@herbertland.com>
>>> Cc: Templin, Fred L <Fred.L.Templin@boeing.com>; int-area@ietf.org
>>> Subject: Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03
>>>
>>>
>>>
>>> On 5/26/2016 11:22 AM, Tom Herbert wrote:
>>>> On Thu, May 26, 2016 at 10:56 AM, Joe Touch <touch@isi.edu> wrote:
>>>>> On 5/26/2016 10:52 AM, Tom Herbert wrote:
>>>>>> On Thu, May 26, 2016 at 10:41 AM, Joe Touch <touch@isi.edu> wrote:
>>>>>>> Here's the problem:
>>>>>>>
>>>>>>> The first 4 bits are either part of the GUE header or IPv4 or IPv6.
>>>>>>>
>>>>>>> In the diagrams in draft-ietf-nvo3-gue and RFC791 they're indicated in the
>>>>>>> following bit order: 0,1,2,3
>>>>>>>
>>>>>>> In GUE, these are 0,0,x,x
>>>>>>>
>>>>>>> In IPv4, these are 0,0,1,0
>>>>>>>
>>>>>>> In IPv6, these are 0,1,1,0
>>>>>>>
>>>>>> IPv4 is 0,1,0,0.
>>>>> Not LSB to MSB, which is how both GUE and RFC791 define the header:
>>>>>
>>>> >From RFC791:
>>>>
>>>> "Whenever an octet represents a numeric quantity the left most bit in
>>>> the diagram is the high order or most significant bit.  That is, the
>>>> bit
>>>> labeled 0 is the most significant bit."
>>> Arrgh.
>>>
>>> Yup. OK, so the reason this would work is only because we no longer use
>>> IP versions 0..3.
>>>
>>> Got it.
>> I for one like it, and I am using it in my AERO implementation. As Joe points out
>> however it does not account for fragmentation, identification etc. But, as long
>> as you use it in a carefully controlled environment it should be OK.
>>
>> Can we have this added back to the GUE spec?
>>
> Since it technically defines a new version of GUE and other than the
> two bit version number there is nothing else in common with GUEv0
> format, I would say this should be a new spec (I need to go back and
> see if I wrote it up this in a draft).
>
> Fred, do you have any objective data showing the benefits? I think we
> need something tangible to justify complexity (i.e. burning 25% of the
> GUE version number space  ;-) )
>
> Thanks,
> Tom
>
>> Thanks - Fred
>>
>>> Joe