It seems to me that RFC8200 could not be clearer when it states that there is
an order to how extension headers are processed (see [1]) and if a DOH precedes
a routing header then *every* node in the routing header must process the DOH;
which leads me to wonder how a service chain could be supported unless only a
single service is needed in a chain and that service be placed as the last node
in the routing header so that a DOH could be added *after* the routing header
and therefore only be processed by the last node.
[1] RFC8200 section 4.1
note 1: for options to be processed by the first destination that
appears in the IPv6 Destination Address field plus
subsequent destinations listed in the Routing header.
note 3: for options to be processed only by the final destination
of the packet.
** note 1 is for DOH preceding routing header and note 3 is for DOH after
routing header.
Jim
From: spring <spring-boun...@ietf.org> On Behalf Of Robert Raszuk
Sent: Sunday, May 24, 2020 5:03 PM
To: Brian E Carpenter <brian.e.carpen...@gmail.com>
Cc: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org>; spring@ietf.org; 6man
<6...@ietf.org>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?
Hi Brian,
No playing with words intended at all.
But as you very well know half of the room read RFC8200 verbatim to what the
definition of destination node is. Clearly segment endpoint address would be
the "local" destination of the packet when it receives it.
It seems very clear that RFC8200 authors did not expect that packet may have
more then one destination in a domain :) That seems to be a crux.
Let's please do not restart that topic. I asked this question as I am curious
for RbR - how to prevent midpoints to examine DOH if someone would choose to
carry VPN demux label there.
What is there in the packet when packet is received by a segment endpoint
(transit point) to tell - STOP ... this is not a packet for you - skip DOH -
but go and examine other RHs ?
Thank you,
R,
On Sun, May 24, 2020 at 10:54 PM Brian E Carpenter
<brian.e.carpen...@gmail.com<mailto:brian.e.carpen...@gmail.com>> wrote:
Hi Robert,
On 24-May-20 22:22, Robert Raszuk wrote:
> Hi Ron,
>
> I have one small question on the Destination Option Header you keep
> referencing to carry for example VPN demux instructions.
>
> As DOH follows Fragment Header it is indeed inspected before CRH.
>
> So please kindly clarify what is there in the IPv6 packet header which would
> stop each segment endpoint (during the transit over SR anchors) which
> destination is obviously in DA of the arriving packet not to inspect DOH and
> not trying to execute it ?
>
> If you could please also provide reference to RFC8200 defining it..
I think you are playing with words a bit here. 8200 says:
"The Destination Options header is used to carry optional information
that need be examined only by a packet's destination node(s)."
That clearly means that other nodes *do not need* to examine the DOH, so they
can simply skip over it. Because it isn't encrypted, of course they physically
can examine it if they want to waste CPU cycles, but they *do not need* to do
so. Since they are not the destination node, obviously the information in the
DOH is not intended for them. If it isn't obvious that they are not intended to
act on that information, I don't know why we bother to write RFCs at all.
Regards
Brian
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
