Re: [spring] Question about SRv6 Insert function

Mark Smith <> Sat, 31 August 2019 06:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C7111200A3; Fri, 30 Aug 2019 23:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Status: No, score=-0.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kcUcINQCSPLA; Fri, 30 Aug 2019 23:29:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B6769120059; Fri, 30 Aug 2019 23:29:16 -0700 (PDT)
Received: by with SMTP id 97so6191113otr.4; Fri, 30 Aug 2019 23:29:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zdtcGdlFE2EwoM9eYbzlSUf+eFZmQVr9nAv/NjO3J9M=; b=XHnwMiYfBKK0utvnP6e1vyQwM6Q5LG8gUCguIN3/czmX1nyLUx6ZQ/r7WU5iF4i+ij DGlMa9mG/uTOyXyh1p7loyH96VHPlcDnxMqv+hi0qMLJnK3DOZkecXQNDgW9btZr3AQ9 lUwQAAnD3EzRqmKR29OdFfP7f35mUpGq8p50U0vLUdQAFXM3WuXzUbMINdjPhgL5OO2f 3opCNlONHJGXItdBt+xUMe8cZ1BcXjfDfvVvNX+PXwUlJxXescvYzxgUo9Z+maWUyAQ6 5Jfgd7nCwtHKJfFzXdrt+dKjE6aJGOv91BnDzEcX8CzyzUtx/lVJxlKOdMwPWsegh3y6 JQJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zdtcGdlFE2EwoM9eYbzlSUf+eFZmQVr9nAv/NjO3J9M=; b=jEeL3YZqmyVkvGprwLtIOCvpkfkO6VlSMBWV1BGRy/tddmcJ76sbpJt03y+kY/srTH igKk8o9Ujd9ucOzKR1DfS4zLRTiKcSclCVCHpc8Z+zt0WBdDM2wb0N8XCpTKnuF+ghsC dD1bV/K4epYJKacH4XnAY4aV5JFQLdqKqAt1iWsaZ0GgVe+DQiSOLzpZkAAs718iLIQW nzJ9iJCfALcY9oZ7wjBO1BEmKQIYuy/rZ19mzz8xSDmZg3b4TDyDq5n9POd1NPpSbpgA 2vNqm8O89+taonLqJp1u5uTRgqOCw/B42MKE+bAlDI1KbaUdhpS+8wqIRxkes4SZE61L jwsQ==
X-Gm-Message-State: APjAAAXxf9KECUpOT/xs2QQocrGhLByRl6Z4Qg47uMA3PvR+dD3dUdw5 XIBc6v30yjl89K46AFrfhbXkKnP9QACBJqUvvKM=
X-Google-Smtp-Source: APXvYqyHqh+j7veEDqnWIbaqIVO5rA3vXBlJY9O3E+ctgnHRfXkAWP0nd089HwcQx7aOcgXGrAt0yrJ7W7UMEfg6xTg=
X-Received: by 2002:a9d:4801:: with SMTP id c1mr15639507otf.94.1567232956103; Fri, 30 Aug 2019 23:29:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Sat, 31 Aug 2019 16:28:49 +1000
Message-ID: <>
To: Ole Troan <>
Cc: li zhenqiang <>, draft-voyer-6man-extension-header-insertion <>, "" <>, "" <>, draft-ietf-spring-srv6-network-programming <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [spring] Question about SRv6 Insert function
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 31 Aug 2019 06:29:18 -0000

Hi Ole,

On Fri, 30 Aug 2019 at 20:25, Ole Troan <> wrote:
> > End.B6.Insert specified in draft-ietf-spring-srv6-network-programming-01 will insert a new SRH in the received IPv6 packet, which results in two SRHs in one IPv6 packet. It is contradict with RFC8200 that says Each extension header should occur at most once, except for the Destination Options header.
> >
> > In draft-voyer-6man-extension-header-insertion-06, an intermediate node executes the insert function to implement a sub-50 milliseconds FRR operation upon link failure. It is contradict with RFC8200 that says Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet’s delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.
> I think how you look at the host stack may influence how you view these restrictions.
> Take the example of GSO where an application asks the NIC to do TCP segmentation on its behalf. Or IPsec inserts headers at L3.
> Likewise the originator of a packet could "offload" this function further down the stack or even to another entity. Bump in the stack, Bump in the wire.

I don't think bump-in-the-wire applies.

The trouble with a bump-in-the-wire scenario is that it is IP level
anonymous modification of packets at the IP layer. There is no
attribution in the packet of the device that performed the
modification. That lack of attribution is the thing that causes PMTUD,
IPsec etc. to fail. It makes troubleshooting much harder if the
troubleshooter is distant from the anonymous modification device.

The IPsec RFC seems to recognise this, and says that if
bump-in-the-wire device is used for more than one host (implied by
"router" or "firewall"), then the BITW implementation must act as an
IPsec gateway, meaning IPsec tunnel mode, and therefore there is BITW
device attribution through the outer encapsulating IP header's source

RFC 4301:

"When supporting a single
      host, it may be quite analogous to a BITS implementation, but in
      supporting a router or firewall, it must operate like a security

So "anonymous" BITW is limited to 1:1 with a host. That means that the
single host's IP address is acting as a proxy for the single-host
serving BITW device. Although PMTUD or IPsec would still fail, at
least troubleshooting would be easier because the BITW device would be
directly in front of the single host it is acting for.

I would be sure that the SR expectation is that there isn't going to
be a single BITW device per host performing EH insertion, 1:1, and
wouldn't accept that sort of constraint.

I think EH insertion is actually worse than NAT. In NAT, in the inside
to outside direction, the source address of the packet is overstamped
with the NAT device's own IP address.

If you're troubleshooting NAT on the inside, you can fairly easily
identify the NAT device because it's a local network device, and
likely at the network boundary. If you're troubleshooting on the
outside, then the NAT device is unambiguously identified by the source
address of the packets it is modifying.

I think Bump-in-the-Stack would comply with RFC 8200 because the bump
is in the stack of the host that originated the packet. So the source
IP address in the packet is identifying both the host and the bump in
the host, even though it may be a shim between the host's normal IP
stack and a link-layer device driver. In a bump-in-the-stack
implementation, the bump is not anonymous, nor is it ambiguous.