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

Bob Hinden <bob.hinden@gmail.com> Tue, 10 December 2019 21:45 UTC

Return-Path: <bob.hinden@gmail.com>
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 741361201EF; Tue, 10 Dec 2019 13:45:59 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 7d24SZBZg6qQ; Tue, 10 Dec 2019 13:45:57 -0800 (PST)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 E3B9512018D; Tue, 10 Dec 2019 13:45:56 -0800 (PST)
Received: by mail-wr1-x42a.google.com with SMTP id z3so21833343wru.3; Tue, 10 Dec 2019 13:45:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1mUwwBqRClyNTVspuETaerSmk3+fps7mldGcRbCkLGs=; b=C3+UUu55UvIiNrfu/witK1PxnDhMtpAk2m7PRjp2oPhe5YbMKtdD+llAIqycbI+d9k UOPuadUrM6iy6lFrqcN5IOspaVHKG10bgPq0zMZxQOAMV53YrsjeFyDw0P9Sg7MF0O+5 D2aEeitaWjJ/aXfTM2dmAu4BW4PugLXgqSKP/sUgVhXkc/wp/qX06rsKZH+rhWvjeCRL qorx8Ni+HAY6+uf2SMZX/XsoBfOZGeHblA99Me+BHyrkFf5G8sjxYA0WKOAR7zb/s2L/ 3/XoumxRVsyQVQMK5RmaRL4CD0VaYTThui72Y6L6ASIuRXvLftQ2OB7rnb83zsE6/WOo uTQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1mUwwBqRClyNTVspuETaerSmk3+fps7mldGcRbCkLGs=; b=UqH3TVeDamAUlCWuDWmoSL0FlG2rk/8Ioeu1iB7IKkX3afOLwjsrbN+7ViqwNaT/Xd R8WSwdEwhYNtRqfWdhU6B/120AOkFeH9iiielOWMBUfhwgFUZvVMI/CsbnPWT+PRSU6S QPxQawPUdKAPanOYNxQKMgbHnYX9k4HpY2LkbrsLibgrT7MB7JvF451nK2OIaQcfH9PC lOZI939Mya+Q+DPq36MVevQf4DQajD9y5wOnynsKFdsM0KkmGP5hGVykH7jD3+JJ5zPw QLuF9qc9zpSv0VFrC04mMTaGEcm7cwqVWcuZ5YSNiwJDuAVK43vFIv2yZHrK5QimuG+P SNcw==
X-Gm-Message-State: APjAAAWao+ahZYmyVFIKoXkOVkoxqgtbAGdg0w5f1dFGKT3SnNBdsDwS yGTkqp3yQHRrNliFKCNZPyQ=
X-Google-Smtp-Source: APXvYqwSMIZ4PluIdO/qCGdwAqSORLNZqQenc9oTd7QCHq4j715gFGL8FUhltDERDOcYVD/Z7CqK3Q==
X-Received: by 2002:adf:8bde:: with SMTP id w30mr5502064wra.124.1576014355415; Tue, 10 Dec 2019 13:45:55 -0800 (PST)
Received: from [192.168.161.159] ([209.97.127.10]) by smtp.gmail.com with ESMTPSA id z4sm4728094wme.17.2019.12.10.13.45.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Dec 2019 13:45:54 -0800 (PST)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <93EAADC7-A4C4-4690-9DEB-27A1F44F4B56@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_66367927-1908-4B89-B893-5174F5903F1B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 10 Dec 2019 13:45:48 -0800
In-Reply-To: <CAOj+MMGuParGLAA9_2n1zihGjJsKHr+NOK3EXP3j87ibXqmhmQ@mail.gmail.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, Erik Kline <ek.ietf@gmail.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan <suresh.krishnan@gmail.com>, draft-voyer-6man-extension-header-insertion <draft-voyer-6man-extension-header-insertion@ietf.org>, Fernando Gont <fernando@gont.com.ar>, Brian Carpenter <brian.e.carpenter@gmail.com>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
To: Robert Raszuk <robert@raszuk.net>
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>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/w2jUjPR_dTRJTiBsfBSwwc-r1OA>
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 21:45:59 -0000

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



> 
> 
> If there were no resolution to the insertion question vis a vis RFC 8200, then would it then suffice to recommend that ingress nodes should include some padding for these non-SR midpoints to play with (iff. the network has such midpoints), and otherwise abide by RFC 8200?
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring