[spring] Requiring Tunneling - subject change

[Joel Halpern <[e-mail]>]

Robert, as far as I can tell, you are asking for a different change than 
any of the other proposals.  If I understand, you are proposing that 
even end hosts inside an SRv6 domain should encapsulate the underlying 
IPv6 packet.  In order to help the chairs keep track, and tell if there 
are other folks who also support such a change, I have changed the 
subject line and ask that if there is more to say, people use this 
subject line.

I look forward to comments from folks beyond Tom and Robert on this subject.

Yours,

Joel M. Halpern

On 3/28/2024 11:40 AM, Robert Raszuk wrote:
> Hi Tom,
>
> Not really.
>
> RFC8200 defines an exception which is tunneling and says:
>           As an exception to the default behavior, protocols that use UDP
>           as a tunnel encapsulation may enable zero-checksum mode for a
>           specific port (or set of ports) for sending and/or receiving.
>           Any node implementing zero-checksum mode must follow the
>           requirements specified in "Applicability Statement for the Use
>           of IPv6 UDP Datagrams with Zero Checksums" [RFC6936  <https://datatracker.ietf.org/doc/html/rfc6936>].
>
> So in practice if we always tunnel SRv6 there is no issue.
>
> Even Andrew agreed with that :)
>
> Cheers,
> Robert
>
> On Thu, Mar 28, 2024 at 4:36 PM Tom Herbert <[e-mail]> wrote:
>
>     On Thu, Mar 28, 2024 at 7:46 AM Robert Raszuk <[e-mail]>
>     wrote:
>     >
>     > Hi Tom,
>     >
>     > > because of SRH
>     >
>     > Ok I buy this that there are devices which do check checksum and
>     are not final destination of the packets  ... I was more talking
>     about plain forwarding devices (aka P routers). Then I doubt
>     firewalls would be sitting in the core of the networks.
>     >
>     > But let me come black to what I believe is the main disconnect.
>     >
>     > Why SRH would cause an issue ? I think there is claimed issue
>     *ONLY* with SRv6 packets which are not encapsulated - call it raw
>     - sent by the hosts which talk SRv6 and sent with more then one
>     SID/uSID which may get swapped on the way.
>     >
>     > Because only in those cases the destination address will be
>     changing while checksum of the tunnel header will not be zero.
>     >
>     > So what we should I think discuss are really B.1 and B.2.2 cases.
>
>     Robert,
>
>     The scenario that I'm talking about is really simple, and it's not
>     specific to segment routing.  If someone sends a TCP in an IPv6 packet
>     with no routing header then the convention is that the TCP checksum is
>     valid end to end. So if the addresses are changed in flight, like in
>     NAT, then we expect that some part of the packet covered by the
>     checksum is adjusted to offset the change. If a packet is sent in
>     segment routing without an SRH with EtherType 0x86DD then it IS an
>     IPv6 packet to the network so all the conventions and requirements of
>     IPv6 should be applied. IMO, if SRv6 can't maintain these conventions
>     and requirements then it should fork from IPv6 and use a different
>     EtherType.
>
>     Tom
>
>     >
>     > Francois, Pablo - could you comment on this how often do we see
>     those type of SRv6 deployments ? And also could you comment if
>     operator who enables SRv6 in the first place sees those checksum
>     errors how difficult is to address it ?
>     >
>     > Thx,
>     > Robert
>     >
>     >
>     > On Thu, Mar 28, 2024 at 3:29 PM Tom Herbert
>     <[e-mail]> wrote:
>     >>
>     >> On Thu, Mar 28, 2024 at 6:26 AM Robert Raszuk
>     <[e-mail]> wrote:
>     >> >
>     >> > Hi Alvaro,
>     >> >
>     >> > On this specific topic I think you have flatted it a bit too
>     much.
>     >> >
>     >> > These are apparently the options on the table:
>     >> >
>     >> > A) Original packet get's encapsulated with IPv6 header
>     >> >
>     >> >       A.1 SHR is added to it
>     >> >
>     >> >              A.1.1. Regular SIDs are used
>     >> >              A.1.2  Compresses SIDs are used
>     >> >
>     >> >       A.2 SRH is not added to it
>     >> >
>     >> >              A.2.1. Regular SID is used as destination
>     >> >              A.2.2  Compresses SIDs are used in a container
>     >> >              A.2.3  Compresses SID is used
>     >> >
>     >> > B) Original packet get's send from SRv6 host (without
>     encapsulation)
>     >> >
>     >> >     B.1 SHR is added to it
>     >> >
>     >> >              B.1.1. Regular SIDs are used
>     >> >              B.1.2  Compresses SIDs are used
>     >> >
>     >> >       B.2 SRH is not added to it
>     >> >
>     >> >              B.2.1. Regular SID is used as destination
>     >> >              B.2.2  Compresses SIDs are used in a container
>     >> >              B.2.3  Compresses SID is used
>     >> >
>     >> > So within all checksum related discussions so far it seems
>     that the only concern is about B.2.2 and perhaps B.1 however folks
>     did state that if there is SRH added there is no issue so I am not
>     sure how the presence of SRH fixes it.
>     >> >
>     >> > Maybe there was some assumption that presence of SRH mandates
>     encapsulation, but I do not believe this is the case for native
>     SRv6 hosts.
>     >> >
>     >> > All in all I think it should be no business for transit nodes
>     to verify packet's upper layer checksum. I do not know if there is
>     any RFC which would describe what is an expected behavior for
>     transit nodes or even say that they MAY do it.
>     >>
>     >> Robert,
>     >>
>     >> I can go further than that. I believe that intermediate nodes
>     have no
>     >> business parsing into the transport layer, and yet firewalls do
>     that
>     >> all the time even though there is no standard RFC on it (I've asked
>     >> for someone to formalize the requirements of firewalls, but to no
>     >> avail). Validating the checksum in flight is an instance of
>     this, and
>     >> there are devices that commonly do this in deployment. Protocol
>     >> specific checksum offload in NICs is one example. Also, if
>     someone is
>     >> seeing checksum failures in their network, an obvious action is to
>     >> sample packets from routers in the path and look at the traces.
>     If the
>     >> checksum is incorrect on the wire because of SRH then the operator
>     >> sees a whole bunch of checksum errors at the router, but has no
>     way to
>     >> distinguish those packets that are actually good from those
>     that are
>     >> bad.
>     >>
>     >> It's a long established convention in IP that the transport
>     checksum
>     >> is maintained to be correct on the wire-- this is done in NAT by
>     >> adjusting the checksum directly, there's also checksum neutral NAT
>     >> that adjusts another part of the IPv6 header to keep the transport
>     >> layer checksum correct. IMO, deviating from this convention is
>     risky,
>     >> not just to SRH packets but that can have collateral damage like
>     >> breaking the user's ability to debug bad links as I described
>     above.
>     >>
>     >> Tom
>     >>
>     >> >
>     >> > Kind regards,
>     >> > Robert
>     >> >
>     >> >
>     >> >
>     >> > On Thu, Mar 28, 2024 at 1:06 PM Alvaro Retana
>     <[e-mail]> wrote:
>     >> >>
>     >> >> Focusing on the C-SID draft, some have suggested requiring the
>     >> >> presence of the SRH whenever C-SIDs are used. Please discuss
>     whether
>     >> >> that is the desired behavior (or not) -- please be specific when
>     >> >> debating the benefits or consequences of either behavior.
>     >> >>
>     >> >> Please keep the related (but independent) discussion of
>     requiring the
>     >> >> SRH whenever SRv6 is used separate. This larger topic may impact
>     >> >> several documents and is better handled in a different
>     thread (with
>     >> >> 6man and spring included).
>     >> >>
>     >> >> Thanks!
>     >> >>
>     >> >> Alvaro
>     >> >> -- for spring-chairs
>     >> >>
>     >> >>
>     --------------------------------------------------------------------
>     >> >> IETF IPv6 working group mailing list
>     >> >> [e-mail]
>     >> >> Administrative Requests:
>     https://www.ietf.org/mailman/listinfo/ipv6
>     >> >>
>     --------------------------------------------------------------------
>     >> >
>     >> >
>     --------------------------------------------------------------------
>     >> > IETF IPv6 working group mailing list
>     >> > [e-mail]
>     >> > Administrative Requests:
>     https://www.ietf.org/mailman/listinfo/ipv6
>     >> >
>     --------------------------------------------------------------------
>