Adrian,
RFC 8200 recommends extension header order for some very good reasons. And
those reasons are so good, that they go beyond recommendations. For example,
- If the Hop-by-hop extension header does not immediately follow the base IPv6
header, it is likely to be ignored by downstream routers.
- The first Destination Options header (i.e., the one that precedes the Routing
header) is intended to be processed by every node listed in the routing header.
If that Destination Options header does not preceded the routing header, it
will only be processed by the ultimate destination only.
- If the fragment header comes before the Routing header, the first segment
endpoint will either drop or reassemble the packet. Both of these are
undesirable.
Ron
Juniper Internal
-----Original Message-----
From: spring <[email protected]> On Behalf Of Adrian Farrel
Sent: Thursday, May 23, 2019 4:48 AM
To: 'Rajesh M' <[email protected]>; 'Loa Andersson'
<[email protected]>
Cc: 'SPRING WG' <[email protected]>; [email protected]
Subject: Re: [spring] draft-ali-6man-spring-srv6-oam-00
Hi all,
I don't think that a loose statement of recommendation is quite enough.
Trivially, the IPv6 header must come first and the upper layer header must come
last.
I think that although the inclusion of the two destination options headers is
optional, their positions are quite tightly constrained.
Personally, I think this is a good candidate for mandating ordering and
probably using RBNF (RFC 5030) to describe the possibilities.
Thanks,
Adrian
-----Original Message-----
From: ipv6 <[email protected]> On Behalf Of Rajesh M
Sent: 23 May 2019 09:35
To: Loa Andersson <[email protected]>; Robert Raszuk <[email protected]>
Cc: SPRING WG <[email protected]>; [email protected]; [email protected];
[email protected]
Subject: RE: [spring] draft-ali-6man-spring-srv6-oam-00
Yes its just recommended 😊
Juniper Internal
-----Original Message-----
From: Loa Andersson <[email protected]>
Sent: Thursday, May 23, 2019 9:13 AM
To: Rajesh M <[email protected]>; Robert Raszuk <[email protected]>
Cc: [email protected]; SPRING WG <[email protected]>; [email protected];
[email protected]; Ron Bonica <[email protected]>; [email protected];
[email protected]; [email protected]; [email protected]
Subject: Re: [spring] draft-ali-6man-spring-srv6-oam-00
Rajesh,
It seems to me that "it is recommended" indicate that the ordering is
optional/OPTIONAL. Does this document (or your comment) create a MANDATORY
ordering of EH's??
/Loa
On 2019-05-22 22:44, Rajesh M wrote:
> I think as long as we ensure below order it must be OK.
>
> When more than one extension header is used in the same packet, it is
> recommended that those headers appear in the following order:
>
> IPv6 header
>
> Hop-by-Hop Options header
>
> Destination Options header (note 1)
>
> Routing header
>
> Fragment header
>
> Authentication header (note 2)
>
> Encapsulating Security Payload header (note 2)
>
> Destination Options header (note 3)
>
> Upper-Layer header
>
> *From:* Robert Raszuk <[email protected]>
> *Sent:* Wednesday, May 22, 2019 7:55 PM
> *To:* Rajesh M <[email protected]>
> *Cc:* [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]; SPRING WG
> <[email protected]>; Peter Psenak <[email protected]>; Ron Bonica
> <[email protected]>
> *Subject:* Re: [spring] draft-ali-6man-spring-srv6-oam-00
>
> Hi Rajesh,
>
> I think some folks are just confusing "insertion of new EH" from
> "modification of existing EH" ? To me those are completely different
> actions.
>
> And processing of any EH is explicitly allowed by RFC8200 as long as
> dst address in the top v6 header is the processing entity which seems
> to be the case here. Such processing nowhere in RFC8200 seems to be
> prohibited.
>
> Let's also observe that as it is often the case with OEM it is actual
> network elements who act as both src and dst of the end to end OEM
> sessions :).
>
> Thx,
>
> R.
>
> On Wed, May 22, 2019 at 3:56 PM Rajesh M
> <[email protected]
> <mailto:[email protected]>> wrote:
>
> Agreed (cannot claim compliance with RFC8200). Authors please
> comment
>
> Guys in this draft I see that all the example such as ping,
> traceroute to ipv6 address-> use SRH insertion rather than SRH
> encapsulation.This is intentionally done to reduce the packet size
> (since underlying data can be only ipv6) ?
>
> *From:* Mark Smith <[email protected]
> <mailto:[email protected]>>
> *Sent:* Wednesday, May 22, 2019 10:15 AM
> *To:* Rajesh M <[email protected] <mailto:[email protected]>>
> *Cc:* [email protected] <mailto:[email protected]>; [email protected]
> <mailto:[email protected]>; [email protected]
> <mailto:[email protected]>; [email protected]
> <mailto:[email protected]>; [email protected]
> <mailto:[email protected]>; [email protected]
> <mailto:[email protected]>; SPRING WG <[email protected]
> <mailto:[email protected]>>; [email protected] <mailto:[email protected]>;
> Peter Psenak <[email protected] <mailto:[email protected]>>
> *Subject:* Re: draft-ali-6man-spring-srv6-oam-00
>
> EH insertion is not compliant with RFC8200. Equipment doing so
> cannot claim compliance with RFC8200.
>
> On Wed., 22 May 2019, 11:08 Rajesh M,
> <[email protected]
> <mailto:[email protected]>> wrote:
>
> Guys in this draft I see that all the example such as ping,
> traceroute to ipv6 address-> use SRH insertion rather than SRH
> encapsulation.
>
> This is intentionally done to reduce the packet size (since
> underlying data can be only ipv6) ?
>
> Juniper Internal
>
> Juniper Internal
>
> Juniper Internal
>
> *From:* Rajesh M
> *Sent:* Wednesday, April 3, 2019 1:06 PM
> *To:* [email protected] <mailto:[email protected]>;
> [email protected] <mailto:[email protected]>; [email protected]
> <mailto:[email protected]>; [email protected]
> <mailto:[email protected]>; [email protected]
> <mailto:[email protected]>; [email protected]
> <mailto:[email protected]>
> *Cc:* SPRING WG <[email protected] <mailto:[email protected]>>;
> [email protected] <mailto:[email protected]>; Ron Bonica
> <[email protected] <mailto:[email protected]>>
> *Subject:* draft-ali-6man-spring-srv6-oam-00
>
> Please find few comments on this draft
>
> 1. Section 3.1.1 , below must be Ref2
>
> *Ref1*: Hardware (microcode) just punts the packet. Software
> (slow path)
>
> implements the required OAM
>
> mechanism. Timestamp is not carried in the packet forwarded to
> the
>
> next hop.
>
> 2. 4.1.2.2, here it must be N2 (page 10)
>
> If the target SID is not locally programmed, *N4* responses
> with
>
> the ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not
>
> locally implemented (TBA)"); otherwise a success is returned.
>
> 3. 4.1.2.2, here it must be B:4:C52 (page 11)
>
> The ICMPv6 process at node N4
>
> checks if its local SID (*B:2:C31*) is locally programmed or
> not
>
> and responds to the ICMPv6 Echo Request.
>
> 4. 4.3.2.2, here it must be B:4:C52 (page 16)
>
> The traceroute process at
>
> node N4 checks if its local SID (*B:2:C31*) is locally
>
> programmed.
>
> 5) in below two cases is it B5:: or it must be A:5:: ?
>
> > ping A:5:: via segment-list B:2:C31, B:4:C52
>
> Sending 5, 100-byte ICMP Echos to *B5::,* timeout is 2 seconds:
>
> !!!!!
>
> > traceroute A:5:: via segment-list B:2:C31, B:4:C52
>
> Tracing the route to *B5::*
>
> Thanks
>
> Rajesh
>
> Juniper Internal
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected] <mailto:[email protected]>
> Administrative Requests:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=CWy0ai791mYUvfC3B6IE46DSDAOG-FbuEW2lRdgM_6U&s=2ix9kKHToQUM7NsHhHBM_SSVgBdT3cz6d2L0OrXshSo&e=
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
> lman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWz
> oCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=jrfq1dYsfk8_fBqqNN
> S-gdRsYxNXOt7r52G3GHN0iiQ&s=7EDIKybjxRS2y7WsSXf02B7k15AZOccvbTWWcMu0OY
> o&e=>
>
> --------------------------------------------------------------------
>
> _______________________________________________
> spring mailing list
> [email protected] <mailto:[email protected]>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_spring&d=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcW
> zoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=CWy0ai791mYUvfC3B
> 6IE46DSDAOG-FbuEW2lRdgM_6U&s=QWz-MtJwmiTTnDkJ2vbryepA7yAALs_X2LVHmyihE
> 7A&e=
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
> lman_listinfo_spring&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXc
> WzoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=bA6bNX7XD3BHTzuk
> hcoIS-aqZi6dWcnVVdTfYB1goG8&s=fia6hQTqXh09fn6GLOkZIbXdPoNqldBthMQdxAuN
> WxM&e=>
>
>
> _______________________________________________
> spring mailing list
> [email protected]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_spring&d=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcW
> zoCI&r=ijfTaKShbusYK-FOvFGH9IZ538TctoQw-Pljslc0qGA&m=CWy0ai791mYUvfC3B
> 6IE46DSDAOG-FbuEW2lRdgM_6U&s=QWz-MtJwmiTTnDkJ2vbryepA7yAALs_X2LVHmyihE
> 7A&e=
>
--
Loa Andersson email: [email protected]
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=dCPZhZXrhcCILdx4IfTvnoiAs5FZdj1AVV07onkdkmE&s=2TENWO4SdrAao-4yRRUhdg71A9zy2tqIbd2-tFQvzcw&e=
--------------------------------------------------------------------
_______________________________________________
spring mailing list
[email protected]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=dCPZhZXrhcCILdx4IfTvnoiAs5FZdj1AVV07onkdkmE&s=jdLVTMA0RxXuSrrAVbM3Ki35ywj1uAzgEVi-3FFGBGc&e=
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
