Hi, On May 16, 2016, at 11:04 AM, Tal Mizrahi <ta...@marvell.com> wrote: > > Hi Stefano, > > Thanks for the responses. > >> exactly. >> >> Moreover, draft-ietf-6man-segment-routing-header assumes encapsulation >> so clearly there’s no L4 involved here. >> >> s. > > Two questions: > 1. What if the encapsulation is VXLAN? L4 would still be involved, right?
See below. > 2. When you say 'assumes encapsulation', does it mean that a host cannot send > an IPv6 packet with an SRH? The current draft says: > > A Source SR Node can be any node originating an IPv6 packet with its > IPv6 and Segment Routing Headers. This include either: > > A host originating an IPv6 packet. > > An SR domain ingress router encapsulating a received IPv6 packet > into an outer IPv6 header followed by an SRH. > > > > Will appreciate if you can clarify that. ok, two cases: 1. the SRH is inserted at the source. the source originates the packet, the ipv6 header and the SRH. The source computes L4 checksum taking into account the whole IPv6+SRH. Here, theres’ nothing new compared to rfc2460. 2. the SRH is originated by the ingress node of the SR domain. This is done by encapsulating the packet into a outer (additional) ipv6 header followed by an SRH. This is L3 encapsulation and no L4 checksum is involved. When the packet leaves the SR tunnel the outer encapsulation (including the SRH) is removed and the packet continues its journey like nothing happened. s. > > Thanks, > Tal. > >> -----Original Message----- >> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] >> Sent: Monday, May 16, 2016 11:59 AM >> To: Ole Trøan; Tal Mizrahi >> Cc: draft-ietf-6man-segment-routing-hea...@tools.ietf.org; spring@ietf.org; >> 6man WG >> Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing- >> header >> >> >>> On May 15, 2016, at 8:06 PM, otr...@employees.org wrote: >>> >>> Tal, >>> >>>> [Apologies if this issue has been discussed before.] >>>> >>>> According to draft-ietf-6man-segment-routing-header, an ‘SR Segment >> Endpoint Node’ updates the Destination IP address. >>>> Therefore, it must also update the Layer 4 Checksum, right? >>>> >>>> I wonder if there is an upper bound on the size of the SRH. Otherwise, the >> L4 Checksum may be located in a pretty deep location. >>>> Speaking from a chip vendor’s perspective this may be a problem. >>> >>> From RFC2460, RH0: >>> >>> >>> o If the IPv6 packet contains a Routing header, the Destination >>> Address used in the pseudo-header is that of the final >>> destination. At the originating node, that address will be in >>> the last element of the Routing header; at the recipient(s), >>> that address will be in the Destination Address field of the >>> IPv6 header. >>> >>> I would expect SR would work the same. >> >> >> exactly. >> >> Moreover, draft-ietf-6man-segment-routing-header assumes encapsulation >> so clearly there’s no L4 involved here. >> >> s. >> >> >>> >>> Cheers, >>> Ole >>> > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
