Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-intarea-schc-ip-protocol-number

Bob Hinden <bob.hinden@gmail.com> Sat, 10 September 2022 15:38 UTC

Return-Path: <bob.hinden@gmail.com>
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 4735BC152567 for <int-area@ietfa.amsl.com>; Sat, 10 Sep 2022 08:38:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7-GeWbe5C1q for <int-area@ietfa.amsl.com>; Sat, 10 Sep 2022 08:38:07 -0700 (PDT)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82692C1522CA for <int-area@ietf.org>; Sat, 10 Sep 2022 08:38:07 -0700 (PDT)
Received: by mail-ot1-x334.google.com with SMTP id x23-20020a056830409700b00655c6dace73so676326ott.11 for <int-area@ietf.org>; Sat, 10 Sep 2022 08:38:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:from:to:cc:subject:date; bh=Rh1WbSt2ScrwPBpIVQSixlSTeq5oyoEKo/cO405jjsU=; b=oV1c6ejydQKg67oS9xi39FrXUfyvo17fDBzGK2TnFYErLvsK4Iq23/rHuR5WNLw3UN EXPCy6JaBwHM0ef7REQ5g3QwvisD2wqIFVIkcmmx1/btPdmoOmmh8PS4+1MKEJ2waEOX BqGF1BEl1cgkNMomicJtqsVZ3H43bhNTsPSlr4uk+c/acXmLUVN59Fx1eAb0f6VhCxNu rSv5OQI4Fpidfue8MfH9g8xhuSkLj/3e/igYHakF8nC+jBWmBKgSJqDvcVAJylJGkql3 Z9Ef0bkRMcoaI7mSiGBeNF5o7HpnC6/nrYY2JeWU2n0qNHpRgwr7wjSX/+uRyBrJb8Ue of9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=Rh1WbSt2ScrwPBpIVQSixlSTeq5oyoEKo/cO405jjsU=; b=ZKQ7CEcmJhM21+G+Xe7bMMZ+9KXWLxnBi32Z8BdxMw86t+u1UEaesQaNHEir6WkaYK FwJsQlj/34jVsfy2gkb+Ou9vaDFiA5VSBANtAQQEzf3z45eRz7ykt/RXUmNGYnzGWe/D 78s9gqE0C5rbksWNGT5xaLp+xWz64Hk3JImpip7+fCCGSoiKwYCBPOfjcnOv4klDO3+H 0S12S6BDM8cVli533ZlP417PVHQYbK2TJXmMlQtXLD0Iu6MDCcVj4klyAdYqpYz1p2/f Mc2l7cbaJKuHEv6dV9saNEbTqv5eVCjgbPk3NZQNVF7OPvdTom48J7Kg7s4IJX8PHmBk GHew==
X-Gm-Message-State: ACgBeo2FPvUuWURNbSAOCTWlW6ztmlvH73ELOP4CtCtbT5o1DJgTNCwH waBst+sbdJ/3UWhtJ0lmt60=
X-Google-Smtp-Source: AA6agR57PlpHY0IvQTYqC5tR5CgNUmb0cHbqwc8xXIysPH9W5gn+/vfub4Jz7HzZnk/lR2y7wEK94w==
X-Received: by 2002:a9d:7583:0:b0:639:1b2a:17d4 with SMTP id s3-20020a9d7583000000b006391b2a17d4mr7467235otk.164.1662824286654; Sat, 10 Sep 2022 08:38:06 -0700 (PDT)
Received: from smtpclient.apple ([2600:1700:4383:c05f:1070:a6a1:24a9:a29b]) by smtp.gmail.com with ESMTPSA id d23-20020a05683018f700b0063b24357269sm1542186otf.13.2022.09.10.08.38.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Sep 2022 08:38:05 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_87A900EC-032B-4B14-8D72-19C04D3ACB4B"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Bob Hinden <bob.hinden@gmail.com>
In-Reply-To: <2B6EA351-1B1B-488C-A2CC-1ECA95C4AA31@cisco.com>
Date: Sat, 10 Sep 2022 08:38:04 -0700
Cc: Bob Hinden <bob.hinden@gmail.com>, Robert Moskowitz <rgm-ietf@htt-consult.com>, Joel Halpern <jmh.direct@joelhalpern.com>, Internet Area <int-area@ietf.org>
Message-Id: <AFE2ECB0-CE57-4D5E-BF2E-0CCC470F40FB@gmail.com>
References: <165989448256.19592.11033809136170928822@ietfa.amsl.com> <CAF4+nEGvJEcpMWw2z=n_HO2H1wCYOn=7gCv_pKZavJMpuHO-FQ@mail.gmail.com> <CAF4+nEE2TGh74-HY=Ygp9yVphFbXCZZawBxHf4Ta+33uEP977g@mail.gmail.com> <b421494e-21e8-57ed-1aab-4009e445bc7a@htt-consult.com> <CO1PR11MB48810885F2E40649D435759AD8419@CO1PR11MB4881.namprd11.prod.outlook.com> <E6D1BCCD-A8E9-4D9F-99AD-E3A25FC0C4D2@gmail.com> <B1AA0912-9B72-45DC-A9AD-1CFC76104BFB@tzi.org> <8d777d2d-7527-9f13-bccf-e5f98574f70d@htt-consult.com> <543440B2-8530-4A9E-8801-6EEDA8459607@gmail.com> <7D4BF0BE-DD26-4655-A286-7E87E81F1CF3@tzi.org> <4485bfe7-960e-a059-4292-826064e4bc0d@htt-consult.com> <404e48fc-f56f-f64b-f2cb-6b877ec7b4a0@joelhalpern.com> <bf57a5f7-b748-41fd-9bcd-efad8efa653a@htt-consult.com> <a12d574f-2bd3-be9a-b334-b5e1061c78a3@joelhalpern.com> <C7BE947D-FFD9-4E6F-9278-578618CE4BD3@cisco.com> <93601ca5-1548-3635-99d2-a0a60713c7bb@htt-consult.com> <2B6EA351-1B1B-488C-A2CC-1ECA95C4AA31@cisco.com>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/1j3XFif6WETHD5jpU-On8oBn4EA>
Subject: Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-intarea-schc-ip-protocol-number
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Internet Area WG 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: Sat, 10 Sep 2022 15:38:11 -0000

Eric,

Also without any hats, but seems to me there is enough interest in the draft to start an adoption call now.   So I think the adoption call can proceed and these (and other changes) could me made after adoption.

Bob


> On Sep 10, 2022, at 12:06 AM, Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:
> 
> Bob,
> 
> My hat-less reply would be indeed to avoid:
> - SCHC over IP being an IPv6 extension header
> - citing a use case limited to drones (the broader the better)
> - comparing to ESP-diet [1]
> 
> Then, asking the WG chairs to launch the adoption call.
> 
> Regards
> 
> -éric
> 
> [1] with my AD hat, thank you for pointing me to ESP-diet because I was not aware of this other attempt of ipsecme WG to work as the IP layer WG !
> 
> On 09/09/2022, 18:41, "Robert Moskowitz" <rgm-ietf@htt-consult.com> wrote:
> 
>    Do you recommend I submit a -02 ver which is just the -00 (without
>    Extension Header)?  That the wg would then adopt
> 
>    Or wg just adopts -00 and I submit that as wg ver?
> 
>    Bob
> 
> 
>    On 9/9/22 11:34, Eric Vyncke (evyncke) wrote:
>> Without any hat, this proposal does not look like an extension header (i.e., it does not extend the semantic of the IP packet, it 'just' compress it) and looks more like a tunnel/transport header to me.
>> 
>> All in all, it requires an IP protocol number
>> 
>> -éric
>> 
>> On 08/09/2022, 00:25, "Int-area on behalf of Joel Halpern" <int-area-bounces@ietf.org on behalf of jmh.direct@joelhalpern.com> wrote:
>> 
>>     As far as I can tell, SCHC has the same conceptual structure as almost
>>     all of our tunnel protocols.   Which we do not call extension headers.
>>     Sure, they are not really upper layer protocols.  But (although not
>>     described the way John Day does) we understand that "upper" can be
>>     recursion at the same layer.
>> 
>>     If we declare SCHC to be an extension header, I do not know how we
>>     answer the question the next time someone asks us "is this use an upper
>>     layer header or an extension header?"  As long as we provide an ability
>>     to answer that question, I can live with either alternative.
>> 
>>     Yours,
>> 
>>     Joel
>> 
>>     On 9/7/2022 6:05 PM, Robert Moskowitz wrote:
>>> It might be that the datagram can be interrogated for the Next Header
>>> and that MIGHT mean an update to 8200.
>>> 
>>> AH, you can find the NH.  ESP not, as it is in the encrypted part.
>>> 
>>> But it is architecturally wrong to call what ROHC or SCHC as carrying
>>> an upper layer protocol.  They carry what is in our architecture a
>>> Transport Layer protocol, acting in many ways as part of the IP layer
>>> itself...
>>> 
>>> Fun.
>>> 
>>> On 9/7/22 17:35, Joel Halpern wrote:
>>>> My reading of 8200 is that an extension header MUST start with a one
>>>> byte "Next Header" field.  SCHC does not.  Therefore, it is a carried
>>>> / upper layer protocol, not an extension header.  Much like IPv6 (in
>>>> IPv6).  Or UDP (with carrying an application protocol or carrying
>>>> some routing header like GRE, LISP, ...) or ...
>>>> 
>>>> Yours,
>>>> 
>>>> Joel
>>>> 
>>>> PS: I grant we are not fully consistent in this regard.  ESP does not
>>>> have a next-header field.  (AH does).   But if we are going to
>>>> pretend that some headers are extensions headers and some are not, we
>>>> should try to be consistent with the description in 8200 (and 2460).
>>>> 
>>>> On 9/7/2022 4:57 PM, Robert Moskowitz wrote:
>>>>> 
>>>>> 
>>>>> On 9/7/22 16:35, Carsten Bormann wrote:
>>>>>> On 7. Sep 2022, at 22:04, Bob Hinden <bob.hinden@gmail.com> wrote:
>>>>>>> To clarify my question, it only relates to if SCHC should be added
>>>>>>> to the IPv6 Extension Header Types registry.   I continue to think
>>>>>>> that adding it to the IP Protocol Number registry is fine.
>>>>>> I believe the answer should be the same as for 142 (RFC 5858),
>>>>>> which is not in the list.
>>>>>> 
>>>>>> I couldn’t find out quickly what an IPv6 Extension Header Type
>>>>>> is(*), so maybe that is an oversight for 142.
>>>>> 
>>>>> From my limited understanding and which Protocols are listed as
>>>>> Extension Header Types and which not (other than 142), it is a
>>>>> Protocol that transports other Protocols.
>>>>> 
>>>>> Though with that definition, I wonder how HIP got in the list.
>>>>> 
>>>>> It is fun to open a can of worms!
>>>>> 
>>>>>> 
>>>>>> Grüße, Carsten
>>>>>> 
>>>>>> (*) An IP protocol number, apparently.
>>>>>> But what specifically does it make an IPv6 Extension Header Type as
>>>>>> well?
>>>>>> The references given in the registry don’t seem to say.
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Int-area mailing list
>>>>> Int-area@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/int-area
>>> 
>> 
>>     _______________________________________________
>>     Int-area mailing list
>>     Int-area@ietf.org
>>     https://www.ietf.org/mailman/listinfo/int-area
>> 
> 
>