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