Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

Robert Raszuk <robert@raszuk.net> Tue, 10 December 2019 22:05 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFA6120220 for <spring@ietfa.amsl.com>; Tue, 10 Dec 2019 14:05:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 06s6TfQCddw6 for <spring@ietfa.amsl.com>; Tue, 10 Dec 2019 14:05:56 -0800 (PST)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 D04F812018D for <spring@ietf.org>; Tue, 10 Dec 2019 14:05:55 -0800 (PST)
Received: by mail-qt1-x82d.google.com with SMTP id z15so4305525qts.5 for <spring@ietf.org>; Tue, 10 Dec 2019 14:05:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OMyA8GEaeJZ9vx7ZbeY3QgDdqNS/+slf19IvZ3Kp0Ss=; b=efp4yatrWM8+oDgaJiQQIytbwTjR4b4XlB6qWIkGHPrZrqAmkB+EQjh1Wbu55i8OKu qQagHNDsdTgYsAG1NDyUF6v36Spg+O0Qv42hNU0APbUdbYULCKu8lajra8b6+eeooEuu J588L0rKwPIEhySDHEkfsNbzd4cMPCFJ7g8+sN/J/A8QK9MLrXjb+cSOCSTFbZ0GxiGQ dW4WWVwk/iTRcs2lf7dbfnsOyEn3l0mYSDKOHrefgMT4FRe8p93XE/2/C3zqXr3u2Rs3 ZlRBs3aTwHEzoL9oisO0fdmbJCb6Hk8dNVGPxXyJtCVPukkfimJjfs8Jfc6hom3peLYH /dnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OMyA8GEaeJZ9vx7ZbeY3QgDdqNS/+slf19IvZ3Kp0Ss=; b=KOv9AteLFS9f+6ME/a5hfBxH1WvFI+ihcVMJ7hb+5maemVluVhor/17fSaQJyBcKgE J3eVUqN1InJjOun3AZv/oMJrLnxQsIqNmJ8bXJo9U39T0mFUBdb5Dvwy4AwLc1xaPk1h TghemvztKWGCrhLKrLdgAFIJM+CDVWFm2a+B26ZNO7+oD1ROStVYXUBLalmWEDU7Ay0w EwrJgRirIMW5uGdwD91HE0NfmI+kRIzbl0eJGgfWkZuIxTUYtfgZ8e2xTUVOIPXOZRvl ma8bGz+ngzwUaqwcyOCvld//ZgAhgLOFA/lFdIkERO/5T2UWldxlFju3F8qICv3T5kgV aYSQ==
X-Gm-Message-State: APjAAAUqks6In9Ae3cAnWtCkJFkKrt466o0qz5WdAHBYw5F38WI/40Uy 1N5XixR6I4+VyUMnimnte4xthwg0lPtdGxBZtpXCAw==
X-Google-Smtp-Source: APXvYqy3CeoG2GTmNON7YnS3/Fzx5piTmKH6TN+2MCQeXs7YQNyH7v8cLNbCLcQZUf2Xe1xDU2mYBi13oHOHZ0gezMI=
X-Received: by 2002:aed:3fb7:: with SMTP id s52mr44718qth.311.1576015554857; Tue, 10 Dec 2019 14:05:54 -0800 (PST)
MIME-Version: 1.0
References: <HK0PR03MB3970C6DCC635E7CD802D65FDFCBD0@HK0PR03MB3970.apcprd03.prod.outlook.com> <BYAPR05MB54636A2332FED916A26A6F14AEBD0@BYAPR05MB5463.namprd05.prod.outlook.com> <3e31873a-278a-2154-0e71-4d820bba323d@gont.com.ar> <4012D854-2F10-4476-951D-FFFE73C5083C@gmail.com> <cb2f56f8-acdc-d68d-0878-9609cb3d7b1b@gont.com.ar> <28214_1567694772_5D711FB4_28214_238_1_53C29892C857584299CBF5D05346208A48BFA9F3@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <129bbb32-0f14-b799-430c-8f76fb6b1279@gont.com.ar> <1824_1575998223_5DEFD30F_1824_112_1_53C29892C857584299CBF5D05346208A48D24EBD@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <4384c08a-65f5-dbfb-85c7-8365feba9662@gmail.com> <CAOj+MME1+JXth8m4U_E5R6VLvurVR_y_DQvOBy7JmGxHZp7T=Q@mail.gmail.com> <CAMGpriV8BFjOed_-QJYEZc_BANvEuc1hRgYjSdaVUYygVzPj+Q@mail.gmail.com> <CAOj+MMHCA+=9zv_UJAF3gC6R1TWKb6LQJxaGsrRa0N7Amdxrww@mail.gmail.com> <CAMGpriWbz3Gf2UcNDigRVo8gEssdaL6HnH2_6Ln050gQFbFDYQ@mail.gmail.com> <CAOj+MMGuParGLAA9_2n1zihGjJsKHr+NOK3EXP3j87ibXqmhmQ@mail.gmail.com> <93EAADC7-A4C4-4690-9DEB-27A1F44F4B56@gmail.com>
In-Reply-To: <93EAADC7-A4C4-4690-9DEB-27A1F44F4B56@gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 10 Dec 2019 23:05:44 +0100
Message-ID: <CAOj+MMFUxiaMcxz93CPGS0N3-rHHPnAytNdoUUSXu-xbT7Uygw@mail.gmail.com>
To: Bob Hinden <bob.hinden@gmail.com>
Cc: "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004ee453059960b7c1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/_Chhy1lryZ_YsTdJQONhYVQoRRo>
Subject: Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2019 22:05:58 -0000

> Other EH’s allow for different forms of modification, for example SRH
allows for TLV modification, see Section 2.1.

Section 2.1 talks about segment endpoint and that is where IPv6 outer
header destination address matches the node address doing the modification.
If you stating that it can be modified by any via node - that's pretty
cool.

Regarding Hop-by-Hop - of course.

For Destination Options to allow to define fields which can be modified by
non outer IPv6 destination network elements - good to know.

Thx,
R.


On Tue, Dec 10, 2019 at 10:45 PM Bob Hinden <bob.hinden@gmail.com> wrote:

> Robert,
>
> > On Dec 10, 2019, at 12:42 PM, Robert Raszuk <robert@raszuk.net> wrote:
> >
> >
> > The issue is that RFC8200 forbids even modification to any EH unless the
> node is a destination node in top most IPv6 header.
>
> I don’t think that is true.   The options in the Hop-by-Hop Options header
> and the Destination Options Header allow the definition of options that
> support modifications.   See Section 4.2, specifically:
>
>    The third-highest-order bit of the Option Type specifies whether or
>    not the Option Data of that option can change en route to the
>    packet's final destination.  When an Authentication header is present
>    in the packet, for any option whose data may change en route, its
>    entire Option Data field must be treated as zero-valued octets when
>    computing or verifying the packet's authenticating value.
>
>        0 - Option Data does not change en route
>        1 - Option Data may change en route
>
> Other EH’s allow for different forms of modification, for example SRH
> allows for TLV modification, see Section 2.1.
>
> Bob
>
>