Subject: Question about SRv6 Insert function

From: li zhenqiang <[email-masked]>
Date: Fri, 30 Aug 2019 09:52:45 +0000

Hello all,

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.

Best Regards,
Zhenqiang Li
________________________________
[email-masked]

---

From: Ole Troan <[email-masked]>
Date: Fri, 30 Aug 2019 12:24:16 +0200

> 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 RFC820…

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.

Best regards,
Ole

---

From: Ron Bonica <[email-masked]>
Date: Fri, 30 Aug 2019 17:24:50 +0000

Li,

In the scenarios that you mention, below, SRv6 nodes have the following options:

  1.  To prepend and IPv6 header, with its own SRH
  2.  To insert an SRH, as described below

Option 1 is in keeping with the word and spirit of RFC 8200. As you point out, Option 2 contradicts RFC 8200.

So, we should probably explore the motivation for Option 2). If the motivation is not sufficient, we should probably standardize on Option 1.

                                                                                                               Ron

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of li zhenqiang
Sent: Friday, August 30, 2019 5:53 AM
To: draft-voyer-6man-extension-header-insertion <[email-masked]>; draft-ietf-spring-srv6-network-programming <[email-masked]>; [email-masked]; [email-masked]
Subject: [spring] Question about SRv6 Insert function

Hello all,

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.

Best Regards,
Zhenqiang Li
________________________________
[email-masked]<mailto:[email-masked]>

---

From: Mark Smith <[email-masked]>
Date: Sat, 31 Aug 2019 16:28:49 +1000

Hi Ole,

> 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
address.

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
      gateway."

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.

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 31 Aug 2019 17:02:54 +0300

Folks,

There was a very significant discussion during the IETF LC to make it
crystal clear that IPv6 EHs cannot be inserted. This is clearly codified
in RFC8200.

Are the two documents referenced bellow going against the RFC8200 standard?

Thanks,
Fernando

On 30/8/19 12:52, li zhenqiang wrote:
> Hello all,
> 
> 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.
> 
> Best Regards,
> Zhenqiang Li
> ------------------------------------------------------------------------
> [email-masked]
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Sat, 31 Aug 2019 17:09:53 +0300

On 30/8/19 20:24, Ron Bonica wrote:
> Option 1 is in keeping with the word and spirit of RFC 8200. As you
> point out, Option 2 contradicts RFC 8200.
> 
>  
> 
> So, we should probably explore the motivation for Option 2). If the
> motivation is not sufficient, we should probably standardize on Option 1.

My argument would be:
Folks would do whatever they please with 1). If somehow they feel the
need to do 2), they should *refrain from even suggesting it*, post an
internet draft that proposes to update RFC8200 to allow for the
insertion of EHs, wait for that to be adopted and published, and only
then suggest to do EH insertion.

P.S.: Given the amount of discussion there has been on this topic in the
context of RFC8200, I'd like to hope that there's no draft-ietf document
suggesting EH-insertion or, if there is, the relevant ADs and chairs
make sure that's not the case anymore.

Thanks!

Cheers,