Hi Ole,
On Fri, 30 Aug 2019 at 20:25, Ole Troan <otr...@employees.org> 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
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.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
