Fernando,
In order for an IPv6 node to process the SRH (or other routing header) the
address of such router needs to be in the IPv6 Destination Address. Right?
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.
From this text it is clear to me that we can process extension headers when the
packet reaches the node identified in the Destination Address field of the IPv6
header.
From this text it is clear to me that we can delete extension headers when the
packet reaches the node identified in the Destination Address field of the IPv6
header.
Processing at the node identified in the Destination Address field of the IPv6
header has exactly the same treatment in the quote above as deletion at the
node identified in the Destination Address field of the IPv6 header.
This has nothing to do with SRH insertion by a transit node. This was moved to
a separate document and is out of scope of the draft that is being WGLC.
Cheers,
Pablo.
-----Original Message-----
From: ipv6 <ipv6-boun...@ietf.org> on behalf of Fernando Gont
<fg...@si6networks.com>
Date: Thursday, 27 February 2020 at 10:07
To: "bruno.decra...@orange.com" <bruno.decra...@orange.com>, "Eric Vyncke
(evyncke)" <evyncke=40cisco....@dmarc.ietf.org>, Warren Kumari
<war...@kumari.net>, John Leddy <j...@leddy.net>
Cc: SPRING WG List <spring@ietf.org>, "6...@ietf.org" <6...@ietf.org>, Bob
Hinden <bob.hin...@gmail.com>, "Zafar Ali (zali)"
<zali=40cisco....@dmarc.ietf.org>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC -
draft-ietf-spring-srv6-network-programming
Bruno,
On 27/2/20 05:41, bruno.decra...@orange.com wrote:
> Fernando,
>
>> -----Original Message-----
>> From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Fernando Gont
>> Sent: Thursday, February 27, 2020 12:45 AM
>>
>> Hello, Eric,
>>
>> On 26/2/20 20:18, Eric Vyncke (evyncke) wrote:
>>> Writing this without any hat,
>>>
>>> Please note that on the logical side, it still have to be "proven" that
this idea is strictly forbidden by RFC 8200.
>>
>> Here's the proof part:
>>
>> 1) Isn't IPv6 end to end?
>>
>> 2) How do core components of IPv6, such as AH and PMTUD work in the
>> present of intermediate nodes that can add and/or remove arbitrary
>> extension headers?
>>
>> It should be clear from the above that EH insertion/deletion is
forbidden.
>
> This draft does not propose that intermediate node add extension header.
> - If this is not clear to you, please read the draft.
What is this:????
4.16.1. PSP: Penultimate Segment Pop of the SRH
The SRH processing of the End, End.X and End.T behaviors are
modified: after the instruction "S14. Update IPv6 DA with Segment
List[Segments Left]" is executed, the following instructions must be
executed as well:
S14.1. If (Segments Left == 0) {
S14.2. Update the Next Header field in the preceding header to the
Next Header value of the SRH
S14.3. Decrease the IPv6 header Payload Length by the Hdr Ext Len
value of the SRH
S14.4. Remove the SRH from the IPv6 extension header chain
S14.5. }
Isn't this having the penultimate segment fo a packet removing an
extension header for a packet whose Destination Address is not even it's
own?
Doesn't this read a bit as "the router was the DA of the packet, after
you change the DA to that of the next waypoint, if you realize Segments
Left == 0, remove the SRH"?
(which does not even comply with the now infamous "interpretation" of
RFC8200 that if you are the DA, you can add/remove EHs.
> - If it's clear, please let's stick to technical comment on _this_
draft. Bringing irrelevant points to the discussion is really not helping (both
the discussion and the argument).
>
> This draft does not propose that intermediate node add/or remove
arbitrary extension header.
>
> This draft, and more specifically the PSP flavor [1], is about removing
the SRH header by an SR EndPoint.
Seriously?
> - with regards to PMTUD, can you clarify how reducing the size of the
packet break PMTUD? And if there is an impact, let's remember that this is the
source of the packet which instruct the SR EndPoint to remove the SRH.
> - with regards to AH, the SRH specification explicitly states that the
use of SRH with AH by an SR source node is _not_ defined [2].
Do you understand that AH should be usable for all IPv6 traffic?
[....]
>> (that's what Errata's are for, after all... and it should be clear that
>> the EH processing part, overall, needs improvements).
>
> Again, thank you for that, I believe this is useful.
> But while this errata is not reviewed and accepted, RFC 8200 stands as is.
The errata is a clarification, not a change. Of course RFC8200 stands:
EHs are not deleted or added en route to destination.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
