> On May 16, 2016, at 8:21 AM, Tal Mizrahi <[email protected]> wrote: > > Hi Ole, > > Thanks for the prompt response. > > It would be helpful if the authors added a comment about the L4 Checksum to > the current draft, even though this functionality was defined in RFC 2460.
please read carefully draft-ietf-6man-segment-routing-header. The model described assumes encapsulation of the original packet into an outer ipv6 header followed by a SRH. When the packet leaves the SR tunnel there are no traces of segment routing whatsoever. L4 clearly does not apply here, it’s basic tunneling. s. > > Best regards, > Tal. > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> Sent: Sunday, May 15, 2016 9:07 PM >> To: Tal Mizrahi >> Cc: [email protected]; [email protected]; >> 6man WG >> Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing- >> header >> >> 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. >> >> Cheers, >> Ole > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
