Subject: SRv6 Network Programming: ENH = 59

From: Ron Bonica <[email-masked]>
Date: Mon, 6 May 2019 00:47:23 +0000

Folks,

According to Section 4.4 of draft-ietf-spring-srv6-network-programming-00, when processing the End.DX2 SID, the Next Header must be equal to 59. Otherwise, the packet will be dropped.

In the words of the draft, "We conveniently reuse the next-header value 59 allocated to IPv6 No Next Header [RFC8200].  When the SID corresponds to function End.DX2 and the Next-Header value is 59, we know that an Ethernet frame is in the payload without any further header."

According to Section 4.7 RFC 8200, " The value 59 in the Next Header field of an IPv6 header or any  extension header indicates that there is nothing following that header.  If the Payload Length field of the IPv6 header indicates the presence of octets past the end of a header whose Next Header field contains 59, those octets must be ignored and passed on unchanged if the packet is forwarded."

Does the WG think that it is a good idea to reuse the Next Header value 59? Or would it be better to allocate a new Next Header value that represents Ethernet?

                                                          Ron

Juniper Internal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 5 May 2019 20:55:25 -0400

Using "No next header" to mean "next header Ethernet" seems to me to be 
flat wrong.

This also brings up another problem.  Having the SID specify the next 
header, over-riding the next header value, seems to me to be a recipe 
for fragility, likely leading to mis-implementation.

Yours,
Joel

On 5/5/19 8:47 PM, Ron Bonica wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Mark Smith <[email-masked]>
Date: Mon, 6 May 2019 10:57:43 +1000

> Using "No next header" to mean "next header Ethernet" seems to me to be

+1

It fails "truth in advertising" and "the principle of least surprise".

---

From: Tom Herbert <[email-masked]>
Date: Sun, 5 May 2019 18:10:43 -0700

On Sun, May 5, 2019, 5:47 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> Folks,
>
> According to Section 4.4 of draft-ietf-spring-srv6-network-programming-00,
> when processing the End.DX2 SID, the Next Header must be equal to 59.
> Otherwise, the packet will be dropped.
>
> In the words of the draft, "We conveniently reuse the next-header value 59
> allocated to IPv6 No Next Header [RFC8200].  When the SID corresponds to
> function End.DX2 and the Next-Header value is 59, we know that an Ethernet
> frame is in the payload without any further header."
>
> According to Section 4.7 RFC 8200, " The value 59 in the Next Header field
> of an IPv6 header or any  extension header indicates that there is nothing
> following that header.  If the Payload Length field of the IPv6 header
> indicates the presence of octets past the end of a header whose Next Header
> field contains 59, those octets must be ignored and passed on unchanged if
> the packet is forwarded."
>
> Does the WG think that it is a good idea to reuse the Next Header value
> 59? Or would it be better to allocate a new Next Header value that
> represents Ethernet?
>

Tom,

There's already ETHERIP number (97). Why not use that?

Tom

---

From: Xiejingrong <[email-masked]>
Date: Mon, 6 May 2019 01:15:05 +0000

Hi Tom,

Number 97 is a choice but it has 2 bytes wasting.

Jingrong

From: ipv6 [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: Monday, May 06, 2019 9:11 AM
To: Ron Bonica <rbonica=[email-masked]>
Cc: SPRING WG <[email-masked]>; 6man <[email-masked]>
Subject: Re: SRv6 Network Programming: ENH = 59

On Sun, May 5, 2019, 5:47 PM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
Folks,

Tom,

Tom

                                                          Ron

Juniper Internal

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Sun, 5 May 2019 18:19:02 -0700

> Number 97 is a choice but it has 2 bytes wasting.
Jingrong,

To the contrary, those two bytes are critical, they maintain proper
alignment of network and transport layers. Ask the SPARC engineers about
how much fun it is to deal with unaligned network headers! ;-)

Tom

>
> Jingrong
>
>
>
> *From:* ipv6 [mailto:[email-masked]] *On Behalf Of *Tom Herbert
> *Sent:* Monday, May 06, 2019 9:11 AM
> *To:* Ron Bonica <rbonica=[email-masked]>
> *Cc:* SPRING WG <[email-masked]>; 6man <[email-masked]>
> *Subject:* Re: SRv6 Network Programming: ENH = 59
>
>
>
>
>

---

From: Mark Smith <[email-masked]>
Date: Mon, 6 May 2019 11:32:33 +1000

> Does the WG think that it is a good idea to reuse the Next Header value 59? Or would it be better to allocate a new Next Header value that represents Ethernet?

Perhaps I'm not understanding the question, however isn't there
effectively already an NH value that can represent and carry Ethernet
(and other link-layer type frames) - GRE?

Yes GRE adds a bit of overhead, but however you get all of what it
already supports then. (Perhaps it could be useful to be able to carry
MPLS over SR between MPLS islands during a transition to SR, and that
would be an example of what you get if using GRE.).

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Mon, 6 May 2019 11:37:27 +1000

> Number 97 is a choice but it has 2 bytes wasting.

It seems strange to me that as bandwidth is constantly getting
cheaper, people seem to be trying harder and harder to use less of it.
The trade-off is increased code complexity and CPU at each of the hops
at the end of the links.

It is has been my understanding that bandwidth has been getting
cheaper faster than CPU for quite a number of years, has that flipped
around?

> On Sun, May 5, 2019, 5:47 PM Ron Bonica <rbonica=[email-masked]> wrote:
>
> Folks,
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Ron Bonica <[email-masked]>
Date: Mon, 6 May 2019 02:44:15 +0000

Hi Tom,

Ethernet Over IP (97) was created by RFC 3378. It indicates that the next header is an Ethernet over IP encapsulation header (see Figure 1 of RFC 3378). That is different from an actual Ethernet header.

In SRv6, the next header is an Ethernet header.

                                                            Ron

Juniper Internal
From: Tom Herbert <[email-masked]>
Sent: Sunday, May 5, 2019 9:11 PM
To: Ron Bonica <[email-masked]>
Cc: SPRING WG <[email-masked]>; 6man <[email-masked]>
Subject: Re: SRv6 Network Programming: ENH = 59

Tom,

Tom

                                                          Ron

Juniper Internal

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=VHfLHsRn-F8Sn5PP4Vafdu1dtqICcokvsJR7LpaTyEA&s=LUmcAoIURT-jloWOvQ-hF5toj17pXSOaS8EnbCx5CHs&e=>
--------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Mon, 6 May 2019 02:49:00 +0000

Mark,

As the header chain (including encapsulations) get longer, the packet becomes less ASIC friendly.

Allocating a new Next Header value for Ethernet may be less painful than introducing a new encapsulation.

                                                       Ron

Juniper Internal

> -----Original Message-----
> From: Mark Smith <[email-masked]>
> Sent: Sunday, May 5, 2019 9:37 PM
> To: Xiejingrong <[email-masked]>
> Cc: Tom Herbert <[email-masked]>; Ron Bonica
> <[email-masked]>; SPRING WG <[email-masked]>; 6man
> <[email-masked]>
> Subject: Re: [spring] SRv6 Network Programming: ENH = 59
> 
> It seems strange to me that as bandwidth is constantly getting cheaper, people
> seem to be trying harder and harder to use less of it.
> The trade-off is increased code complexity and CPU at each of the hops at the
> end of the links.
> 
> It is has been my understanding that bandwidth has been getting cheaper
> faster than CPU for quite a number of years, has that flipped around?
> 
> 
> >
> > Jingrong
> >
> >
> >
> > On Sun, May 5, 2019, 5:47 PM Ron Bonica
> > According to Section 4.7 RFC 8200, " The value 59 in the Next Header field of
> an IPv6 header or any  extension header indicates that there is nothing
> following that header.  If the Payload Length field of the IPv6 header indicates
> the presence of octets past the end of a header whose Next Header field
> contains 59, those octets must be ignored and passed on unchanged if the
> packet is forwarded."
> >
> > Does the WG think that it is a good idea to reuse the Next Header value 59?
> Or would it be better to allocate a new Next Header value that represents
> Ethernet?
> >
> >
> >
> > Tom,
> >
> >
> >
> > Administrative Requests:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_ipv6&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzo
> > CI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=c3_vQkaWUv9VrZu2hHe
> > xkrpuWDPuNaF_aDmPsT-
> K5v4&s=xMl4vY3Oo9yoWumPFQIkAs4LDEgbsazb28zbejhHM9w
> > &e=
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_spring&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcW
> > zoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=c3_vQkaWUv9VrZu2h
> > HexkrpuWDPuNaF_aDmPsT-
> K5v4&s=yCRyw1w61_gizFeEYqfNsMjzIFPqI1pSUdqeNS6nQ
> > o0&e=

---

From: Tom Herbert <[email-masked]>
Date: Sun, 5 May 2019 20:09:33 -0700

> As the header chain (including encapsulations) get longer, the packet becomes less ASIC friendly.
Ron,

I'm dubious that just a two byte header for EtherIP or four byte
header will be a problem especially in light of the fact that segment
routing header is already adding significantly to packet overhead with
an arbitrary list of sixteen byte quantities.

Tom

---

From: Mark Smith <[email-masked]>
Date: Mon, 6 May 2019 13:32:16 +1000

Hi Ron,

> Allocating a new Next Header value for Ethernet may be less painful than introducing a new encapsulation.

That's fair.

I think sometimes it may not be clear what to optimise for and when.

To me SR seems to be both about replacing MPLS for packet forwarding
across the network, and also possibly performing host functions on a
packet as it traverses the network, meaning processing the contents of
packets past the IP header at various hops during the packet's trip.

I've got used to thinking of the decapsulation of packets at a tunnel
end-point as being host processing because it is processing the packet
beyond the outer IP header, and that then suggests to me to try to be
general if possible rather than optimise for one or a small set of
cases.

Regards,
Mark.

---

From: Ron Bonica <[email-masked]>
Date: Mon, 6 May 2019 14:26:30 +0000

Tom,

Likewise, how painful would it be to allocate a new next-hop type?

                                                      Ron

Juniper Internal

> Sent: Sunday, May 5, 2019 11:10 PM
> Cc: Mark Smith <[email-masked]>; Xiejingrong
> <[email-masked]>; SPRING WG <[email-masked]>; 6man
> <[email-masked]>
> I'm dubious that just a two byte header for EtherIP or four byte header will be
> a problem especially in light of the fact that segment routing header is already
> adding significantly to packet overhead with an arbitrary list of sixteen byte
> quantities.
> 
> Tom
> 
> > > The trade-off is increased code complexity and CPU at each of the
> > > hops at the end of the links.
> > >
> > > > According to Section 4.4 of
> > > > draft-ietf-spring-srv6-network-programming-00,
> > > allocated to IPv6 No Next Header [RFC8200].  When the SID
> > > corresponds to function End.DX2 and the Next-Header value is 59, we
> > > know that an Ethernet frame is in the payload without any further
> header."
> > > >
> > > an IPv6 header or any  extension header indicates that there is
> > > nothing following that header.  If the Payload Length field of the
> > > IPv6 header indicates the presence of octets past the end of a
> > > header whose Next Header field contains 59, those octets must be
> > > ignored and passed on unchanged if the packet is forwarded."
> > > >
> 59?
> > > Or would it be better to allocate a new Next Header value that
> > > represents Ethernet?
> > > >
> > > >
> > > >
> > > > Tom,
> > > >
> > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > -- IETF IPv6 working group mailing list [email-masked]
> > > > Administrative Requests:

---

From: Tom Herbert <[email-masked]>
Date: Mon, 6 May 2019 08:50:40 -0700

Ron,

Relative to using an existing protocol number it is painful. If this
is an assigned Internet protocol number then the implication is that
it can be used as next header value of any protocol, not just the
narrow use case of segment routing. That requires changes to host
implementation, middelbox and routers (e.g will packets containing the
new protocol number even be forwarded?), tooling, security, etc. Also,
as I pointed out, if this breaks the traditional four byte aligment of
IP protocols then that will adversely impact performance on some CPU
architectures (definitely has been a problem on SPARC, some uncommon
cases in x86, and it looks like it might be an issue for ARM also).
The performance hit can be substantial especially if a software trap
must be taken on every unaligned access.

Tom

> > > > > --

---

From: Bob Hinden <[email-masked]>
Date: Mon, 6 May 2019 08:54:16 -0700

Ron,

> On May 5, 2019, at 5:47 PM, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Folks,
> 

IMHO, it is a bad idea to reuse the Next Header value 59.  Better to allocate a new next header value.

Further, this proposed redefining of the “No Next Header” would require updating RFC8200.  I don’t see that in this draft.

Bob

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 6 May 2019 21:14:26 +0100

I agree that implicit payload identity is a bad idea.

If the payload is Ethernet, then the IANA Protocol Number Registry 
suggests that 22 is allocated for that purpose:

22	

XNS-IDP	XEROX NS IDP

["The Ethernet, A Local Area Network: Data Link Layer and Physical Layer 
Specification", AA-K759B-TK, Digital Equipment Corporation, Maynard, MA. 
Also as: "The Ethernet - A Local Area Network", Version 1.0, Digital 
Equipment Corporation, Intel Corporation, Xerox Corporation, September 
1980. And: "The Ethernet, A Local Area Network: Data Link Layer and 
Physical Layer Specifications", Digital, Intel and Xerox, November 1982. 
And: XEROX, "The Ethernet, A Local Area Network: Data Link Layer and 
Physical Layer Specification", X3T51/80-50, Xerox Corporation, Stamford, 
CT., October 1980.][[XEROX]]

- Stewart

---

From: Mark Smith <[email-masked]>
Date: Tue, 7 May 2019 10:20:09 +1000

> CT., October 1980.][[XEROX]]

That's an unusual specification reference, because XNS Internet Datagram
Protocol is not Ethernet. It's the layer 3 protocol Xerox invented, and the
ancestor of Novell's IPX.

According to RFC 1764, "The PPP XNS IDP Control Protocol (XNSCP)", the XNS
spec is

Xerox, "Internet Transport Protocols", January 1991, Order No. XNSS 029101.

Regards,

Mark.

> draft-ietf-spring-srv6-network-programming-00, when processing the End.DX2
> SID, the Next Header must be equal to 59. Otherwise, the packet will be
> dropped.
> >>
> >> In the words of the draft, "We conveniently reuse the next-header value
> 59 allocated to IPv6 No Next Header [RFC8200].  When the SID corresponds to
> >> According to Section 4.7 RFC 8200, " The value 59 in the Next Header
> field of an IPv6 header or any  extension header indicates that there is
> nothing following that header.  If the Payload Length field of the IPv6
> header indicates the presence of octets past the end of a header whose Next
> Header field contains 59, those octets must be ignored and passed on
> unchanged if the packet is forwarded."
> >>
> > Further, this proposed redefining of the “No Next Header” would require
> updating RFC8200.  I don’t see that in this draft.
> >
> > Bob
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 May 2019 13:29:58 +1200

On 07-May-19 12:20, Mark Smith wrote:
> 
> 
> On Tue., 7 May 2019, 06:14 Stewart Bryant, <[email-masked] <mailto:[email-masked]>> wrote:
> 
> That's an unusual specification reference, because XNS Internet Datagram Protocol is not Ethernet. It's the layer 3 protocol Xerox invented, and the ancestor of Novell's IPX.

Correct. I'm sure that 22 must have been intended for XNS-in-IP. Also, those references are to what we knew as DIX Ethernet (Digital-Intel-Xerox) which preceded 802.1 by a few years.

Protocol 97 looks closer:
97 ETHERIP Ethernet-within-IP Encapsulation [RFC3378]
It does require an extra 16-bit "EtherIP" header.

That would be much better than abusing No Next Header, which means what it says.

   Brian
 
> According to RFC 1764, "The PPP XNS IDP Control Protocol (XNSCP)", the XNS spec is
> 
> Xerox, "Internet Transport Protocols", January 1991, Order No. XNSS 029101.> 
> 
> Regards,
> 
> Mark.
> 
> 
> 
> 
> 
> 
> 
> 
> 
>     - Stewart
> 
> 
>     >> On May 5, 2019, at 5:47 PM, Ron Bonica <rbonica=[email-masked] <mailto:[email-masked]>> wrote:
>     >>
>     >> Folks,
>     >>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 7 May 2019 07:08:48 +0000

Hi Ron,

We use the next header value 59 to identify at the receiver that there is no other kind of Internet Protocol beneath to be processed. 
Note that we are *not* using 59 to identify the fact that it is an ethernet header (i.e. other non Internet-Protocols would also use the 59 to identify that no further IP header processing has to be performed). The SID identifies that an Ethernet header follows the IPv6 extension headers.

Thanks,
Pablo.

-----Original Message-----
From: ipv6 <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Date: Monday, 6 May 2019 at 02:48
To: SPRING WG <[email-masked]>, 6man WG <[email-masked]>
Subject: SRv6 Network Programming: ENH = 59

    Folks,

    

                                                              Ron

    Juniper Internal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 7 May 2019 09:39:26 -0400

That is not what Next-Header means.
Even with this explanation, it is clear that 59 is NOT the right value 
for the next header.

Yours,
Joel

---

From: Mark Smith <[email-masked]>
Date: Wed, 8 May 2019 00:04:55 +1000

> Even with this explanation, it is clear that 59 is NOT the right value

If the SID value isn't a reserved for this purpose, permanent and globally
unique value, how would a troubleshooting tool like Wireshark know to
decode the Ethernet packet after the no next header?

Any capex cost savings from not encoding this information in the packet
will be eliminated by the opex costs of increased time to resolve faults
and the corresponding negative reputation with customers consequences.

The more obvious it is how something works, the quicker and easier it is to
fix when it breaks. This is the really the principle of least astonishment.

https://en.m.wikipedia.org/wiki/Principle_of_least_astonishment?wprov=sfla1

Regards,
Mark.

> > We use the next header value 59 to identify at the receiver that there
> is no other kind of Internet Protocol beneath to be processed.
> > Note that we are *not* using 59 to identify the fact that it is an
> ethernet header (i.e. other non Internet-Protocols would also use the 59 to
> identify that no further IP header processing has to be performed). The SID
> identifies that an Ethernet header follows the IPv6 extension headers.
> >
> > Thanks,
> > Pablo.
> >
> >      In the words of the draft, "We conveniently reuse the next-header
> value 59 allocated to IPv6 No Next Header [RFC8200].  When the SID
> corresponds to function End.DX2 and the Next-Header value is 59, we know
> that an Ethernet frame is in the payload without any further header."
> >
> >      According to Section 4.7 RFC 8200, " The value 59 in the Next
> Header field of an IPv6 header or any  extension header indicates that
> there is nothing following that header.  If the Payload Length field of the
> IPv6 header indicates the presence of octets past the end of a header whose
> Next Header field contains 59, those octets must be ignored and passed on
> >      Does the WG think that it is a good idea to reuse the Next Header
> value 59? Or would it be better to allocate a new Next Header value that
> represents Ethernet?
> >
> >                                                                Ron
> >
> >
> >      Juniper Internal
> >

---

From: Tom Herbert <[email-masked]>
Date: Tue, 7 May 2019 07:17:42 -0700

On Tue, May 7, 2019 at 7:05 AM Mark Smith <[email-masked]> wrote:
> If the SID value isn't a reserved for this purpose, permanent and globally unique value, how would a troubleshooting tool like Wireshark know to decode the Ethernet packet after the no next header?
>
> Any capex cost savings from not encoding this information in the packet will be eliminated by the opex costs of increased time to resolve faults and the corresponding negative reputation with customers consequences.
>
> The more obvious it is how something works, the quicker and easier it is to fix when it breaks. This is the really the principle of least astonishment.
>
There are already many IP protocols that allow encpasulation of non-IP
protocols. The aforementioned GRE and EtherIP, but also MPLS also (as
well as UDP variants of these in GRE/UDP, MPLS/UDP).

If this is just encapsulating Ethernet then the correct type is
EtherIP "EtherIP: Tunneling Ethernet Frames in IP Datagrams"
(RFC3378). EtherIP has a two byte encapsulation header, but really its
primary purpose is to align the Ethernet payload (e.g. it could be an
IP protocol) to four bytes as stated in the RFC "The 16-bit header
field provides memory alignment advantages in some implementation
environments." AFAICT lignment is still relevant on

> Mark
>> Administrative Requests: https://www..ietf.org/mailman/listinfo/ipv6

---

From: Tom Herbert <[email-masked]>
Date: Tue, 7 May 2019 07:24:30 -0700

> environments." AFAICT lignment is still relevant on

That is aligment is still relevant on modern CPU architectures (e.g.
ARM, RISC-V).

I also believe that concerns that the additional two byte header is
not hardware friendly are unwarranted. Parsing buffers, cache lines,
etc. are typically sized to power of two bytes. So if a packet with an
encapsulated Ethernet header may have length 4N + 2, and parsing
bufferor cache line size of 4M. If the packet fits into the parsing
buffer then 4N + 2 <= 4m=M. But then adding an additional two bytes
for EtherIP still keeps the packet in the parsing buffer range since
4N + 2 + 2 <= 4M also.

Tom

---

From: Ron Bonica <[email-masked]>
Date: Tue, 7 May 2019 17:04:23 +0000

Pablo,

I am not sure that your use of this field is in accordance with Section 4.7 of RFC 8200.

                                                                    Ron

Juniper Internal

> From: Pablo Camarillo (pcamaril) <[email-masked]>
> Sent: Tuesday, May 7, 2019 3:09 AM
> To: Ron Bonica <[email-masked]>; SPRING WG <[email-masked]>; 6man
> WG <[email-masked]>
> We use the next header value 59 to identify at the receiver that there is no
> other kind of Internet Protocol beneath to be processed.
> Note that we are *not* using 59 to identify the fact that it is an ethernet
> header (i.e. other non Internet-Protocols would also use the 59 to identify that
> no further IP header processing has to be performed). The SID identifies that
> an Ethernet header follows the IPv6 extension headers.
> 
> Thanks,
> Pablo.
> 
>     According to Section 4.4 of draft-ietf-spring-srv6-network-programming-
> 00, when processing the End.DX2 SID, the Next Header must be equal to 59.
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6S
> cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=YOpkfRdJqwMPig1QVXflyp_jPXFxMtT_wCSFm0
> 9x7uQ&s=dwc4VotN_cH4V8ncfopG-fNWOmJVYzMQLduXjOLwIWM&e=

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 May 2019 08:53:13 +1200

> I am not sure that your use of this field is in accordance with Section 4.7 of RFC 8200.

The language is quite subtle, in fact, so I'm not sure either. However, the doubt can easily be resolved by using protocol number 22, which appears to be intended exactly for this purpose.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Wed, 8 May 2019 12:36:53 +0200

> The language is quite subtle, in fact, so I'm not sure either. However, the doubt can easily be resolved by using protocol number 22, which appears to be intended exactly for this purpose.

I spent some time yesterday digging into history and intent.
As far as I could find from the ipng mailing list, the idea was suggested in November 1994. The use case was to be able to signal end to end with extension headers, so the No next header value was a way of signalling termination of the chain.
There was a lot of support for using the value 0, but there was an argument made that comparing a the next header field against the constant 0 was faster than comparing it to another constant (really?). So that number went to HBH.

The allocation was done by IANA in February 95 and the 4.7 text was included in the first draft published March 17:
https://tools.ietf.org/html/draft-ietf-ipngwg-ipv6-spec-01

There is no discussion on the mailing list that I can find about additional data after the last header.
I vaguley recall having a discussion at some IETF about this, but I can't recall the conclusion.
Given the text on "must forward", I think it was intended as an extension mechanism / scratch space.

Cheers,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Wed, 8 May 2019 07:57:02 -0700

> Given the text on "must forward", I think it was intended as an extension mechanism / scratch space.
Ole,

This situation sounds very similar to the "surplus space" in UDP where
the IP length and UDP length differ such that there are bytes in the
IP packet following the UDP headers. While RFC768 implicitly defined
the surplus space, no use or requirements about what it contains were
ever specified. Now there is an attempt to define these bytes in UDP
(draft-ietf-tsvwg-udp-options).

I believe a reasonable interpretation of "No next header" is that the
trailing bytes contain something not describable by a standard
protocol number, but the bytes should be allowed to contain data of
interest to the receiver. So the bytes need to be interpreted by other
means. This is in fact how we are using protocol number 59 in GUE when
the GUE payload is a fragment or has been transformed, e.g. by
encryption. The payload cannot simply be parsed as an IP protocol.
Information in the GUE header indicates how the payload is
interpreted, and we use No-next-header to ensure that intermediate
devices don't try to parse the payload.

So I think the use of No-next-header in segment routing would be
consistent with this interpretation, however, in this case the data
being carried in the payload is describable by an existing protocol
number, namely ETHERIP (protocol 97), so using No-next-header seems
like unnecessary complexity.

Tom

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 May 2019 01:48:21 +1000

> like unnecessary complexity.

Here's what RFC8200 says:

"The value 59 in the Next Header field of an IPv6 header or any
   extension header indicates that there is nothing following that
   header."

The etymology of "nothing" is "no thing", so there is to be no thing
following the No Next Header EH.

It also says,

"If the Payload Length field of the IPv6 header indicates the
   presence of octets past the end of a header whose Next Header field
   contains 59, those octets must be ignored and passed on unchanged if
   the packet is forwarded."

Processing values in those bytes is obviously not ignoring them.

"passed on unchanged if the packet is forwarded." is really a
redundant statement, as IPv6 forwarding isn't looking at any EH other
than Hop-by-Hop. Passing on unchanged is implicit in IPv6 forwarding
being intentionally oblivious to packet payloads.

This second statement seems to really be text on how to treat an error
in the Payload Length field value when it points past the end of the
packet. There could be invalid bytes there because of Ethernet padding
of frames up to 64 octets.

Regards,
Mark.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 8 May 2019 09:24:41 -0700

Mark,

Right, so the first clause say that the No-next-header means there's
nothing beyond the header, but the second clause says that if there is
something beyond the header it's ignored. So "nothing" can actually be
"something" which seems to be contradiction. In practice, this sounds
like a wonderful opportunity for a covert channel. I would hope that a
receiver of packet with No-next-header followed by a 1000 bytes of
"nothing" views the packet with suspicion!

> being intentionally oblivious to packet payloads.

Correct intermediate node processing isn't relevant to this
discussion, but host processing is.

> of frames up to 64 octets.
I don't believe that is correct. Ethernet padding would not be
accounted for in IP Payload Length. If the Payload Length extends
beyond the header containing No-next-header then, barring a corrupted
packet, it is the sender that the packet containing data beyond
No-next-header. The question is why would they do this? Yes, sending
such a packet is not prohibited so by robustness principle we need to
accept it, but from a security standpoint if there is no useful
purpose to have bytes beyond No-next-header then shouldn't we expect
the packet be dropped instead of blindly accepted?

Tom

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 8 May 2019 17:32:16 +0100

On 08/05/2019 17:24, Tom Herbert wrote:
I would hope that a
> "nothing" views the packet with suspicion!

No, surely you would just assume it's Ethernet and forward it straight 
onto some unsuspecting LAN without further thought.

- Stewart

---

From: Bob Hinden <[email-masked]>
Date: Wed, 8 May 2019 09:41:31 -0700

Tom,

> On May 8, 2019, at 9:24 AM, Tom Herbert <[email-masked]> wrote:
> 

It’s also a great mechanism to tickle buffer overflow bugs.   I agree that packets like this are suspect, and this is also another good reason to not use “No-Next-Header” in SRv6 network programming.

Bob

---

From: Ron Bonica <[email-masked]>
Date: Wed, 8 May 2019 17:18:20 +0000

<adding the SPRING mailing list, because this is a SPRING draft>

Folks,

Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-00 define a set of SIDs that have the following things in common:

- they are consumed by the egress node (SL == 0)
- they tell the egress node how to forward the payload into a VPN

If the payload is IPv4, the next-header value in the SRH must be IP4 (value 4).
If the payload is IPv6, the next-header value in the SRH must be IPv6 (value 41).
If the payload is Ethernet, the next-header value in the SRH must be No Next Header (value 59).

In the interest of consistency, we should probably allocate a new next-header value for Ethernet and use it.

                                                                              Ron

Non-Juniper

> From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
> Sent: Wednesday, May 8, 2019 12:42 PM
> To: Tom Herbert <[email-masked]>
> Cc: IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
> It’s also a great mechanism to tickle buffer overflow bugs.   I agree that
> packets like this are suspect, and this is also another good reason to not use
> “No-Next-Header” in SRv6 network programming.
> 
> Bob
> 
> Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-
> AWF2EfpHcAwrDThKP8&m=bmZxS1Pe-
> kZHulP5IPA1JPe52WUCDjqLHl0HWAnSazo&s=3N9-
> vv5gp4IjVHnDWJjKOQoLllRYO38bbwWNiuQJVok&e=

---

From: Ole Troan <[email-masked]>
Date: Wed, 8 May 2019 20:13:40 +0200

Ron,

> In the interest of consistency, we should probably allocate a new next-header value for Ethernet and use it.

It's a fairly precious name space though.
What would a general IP stack do with an Ethernet frame? It's kind of a neat feature that "IP processing terminates here".
Or are we going to specify Ethernet over IP?

Cheers,
Ole

---

From: Sander Steffann <[email-masked]>
Date: Wed, 8 May 2019 20:34:42 +0200

Hi,

> Or are we going to specify Ethernet over IP?

The next-header should identify what follows, so that anybody parsing the packets knows what to expect. Using "No Next Header" should mean "nothing follows". Once we start using No-next-header for "some stuff may follow" it will become very hard to make sense of packets. Overloading the meaning of no-next-header will only create confusion. What when someone starts using it for "encrypted stuff follows"? How do we distinguish between "payload is ethernet" and "payload is encrypted"?

The whole point of these identifies is to tell the reader what the meaning is of what follows. Using value 59 like this looks like "when we say 'no-next-header' we actually mean 'ethernet' (probably)". That's just bad engineering, and reminds me of MPLS implementations that tried to guess what the payload was by looking at the first nibble (if it's 4 then it's probably an IPv4 packet, if it's a 6 then it's probably IPv6 and otherwise we treat it as ethernet). That kind of worked until MAC addresses starting with 4 and 6 started to be used... Let's not make such mistakes again and put proper labels on our payloads.

Cheers,
Sander

---

From: Tom Herbert <[email-masked]>
Date: Wed, 8 May 2019 11:44:15 -0700

Ole,

Ethernet over IP is already specified in RFC3378 and protocol number
97 is assigned to encapsulate Ethernet frames in IP. The only change
required in the spring draft is:

If the payload is Ethernet, the next-header value in the SRH must be
EtherIP (value 97).

Tom

---

From: Bob Hinden <[email-masked]>
Date: Wed, 8 May 2019 11:45:19 -0700

Ole,

> On May 8, 2019, at 11:13 AM, Ole Troan <[email-masked]> wrote:
> 
> Ron,
> 

According to https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

143-252		Unassigned

Seems like a lot left.  Plus there are many that are clearly not used anymore, so there isn’t a shortage.

> Or are we going to specify Ethernet over IP?

Look at the the registry, it looks to me we have already

From the abstract:

   EtherIP tunnels Ethernet and IEEE 802.3 media access
   control frames in IP datagrams so that non-IP traffic can traverse an
   IP internet.  

This be appropriate for SRv6 network programming.

Bob

---

From: Ron Bonica <[email-masked]>
Date: Wed, 8 May 2019 18:49:53 +0000

Ole,

If you want to conserve space in the registry, you can do one of the following:

- Update RFC 8200, redefining value 59 to mean "VPN Payload - type unspecified"
- Update RFC 8200, redefining value 59 to mean "IP Processing Stops Here"
- Allocate a new type called "VPN Payload - type unspecified"
- Allocate a new type called "IP Processing Stops here"

                                                              Ron

Non-Juniper

> From: Ole Troan <[email-masked]>
> Sent: Wednesday, May 8, 2019 2:14 PM
> Cc: Bob Hinden <[email-masked]>; Tom Herbert
> <[email-masked]>; SPRING WG <[email-masked]>; 6man WG
> <[email-masked]>
> > Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-
> 00 define a set of SIDs that have the following things in common:
> >
> What would a general IP stack do with an Ethernet frame? It's kind of a neat
> feature that "IP processing terminates here".

---

From: Ron Bonica <[email-masked]>
Date: Wed, 8 May 2019 18:55:44 +0000

Bob,

The value 97 is tempting, but it already has a meaning that is slightly different from what the authors of draft-ietf-spring-srv6-network-programming intend. According to RFC 3378, a value of 97 means that the next header will be as depicted in Figure 2 of RFC 3378.

                                                     Ron

Non-Juniper

> From: Bob Hinden <[email-masked]>
> Sent: Wednesday, May 8, 2019 2:45 PM
> To: Ole Trøan <[email-masked]>
> Cc: Bob Hinden <[email-masked]>; Ron Bonica
> <[email-masked]>; Tom Herbert <[email-masked]>; SPRING WG
> <[email-masked]>; IPv6 List <[email-masked]>
> According to https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.iana.org_assignments_protocol-2Dnumbers_protocol-
> 2Dnumbers.xhtml&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=ZtmZfCpk7bYpJSSTREggt8Xm8yHpWgrVBTFHi5a
> UtW4&s=Qir8baDHTQf5RGhmFCDSbGShFV8dE_dqL1reoBpkiUE&e=
> 
> 143-252		Unassigned
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 8 May 2019 12:17:27 -0700

Ron,

The spring draft states:

"If the outer header is pushed without SRH, then the DA must be a SID
of type End.DX2, End.DX2V, End.DT2U or End.DT2M and the next-header
must be 59 (IPv6 NoNextHeader).  The received Ethernet frame follows
the IPv6 header and its extension headers."

That describes Ethernet over IP encapsulation.

RFC3378 states:

"EtherIP datagrams contain a 16-bit header and a variable-length
encapsulated Ethernet or IEEE 802.3 frame that immediately follows IP
fields."

That also describes Ethernet in IP encapsulation. The only difference
is the presence of the two byte EtherIP header. As already mentioned
this is important for maintaining alignment of the encapslated
Ethernet payload, and is otherwise inconsequential overhead.

So I don't see why EtherIP won't work here. Can you please clarify your concern?

Tom

---

From: Ole Troan <[email-masked]>
Date: Wed, 8 May 2019 21:33:25 +0200

Ron,

> If you want to conserve space in the registry, you can do one of the following:

I don't think I said I wanted to conserve space outright.
But it is an 8-bit number space, so clearly if anyone wants more bits than that, they cannot rely on the protocol field.
Note I'm arguing this purely on principle, I don't know the network programming use case.
It is also a name space shared by both IPv4 and IPv6, and would this mean we were going to define next headers that were only valid after an SRH header?

Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 8 May 2019 21:37:47 +0200

Sander,

> The whole point of these identifies is to tell the reader what the meaning is of what follows. Using value 59 like this looks like "when we say 'no-next-header' we actually mean 'ethernet' (probabl…

That is not correct in the general.
E.g. you could  use a control protocol or some other mechanism to signal the required information.
I think in the "Patterns of Networking" J Day proposes a scheme without demuxing on protocol/ports (but the details elude me at the moment).

Cheers,
Ole

---

From: Ron Bonica <[email-masked]>
Date: Wed, 8 May 2019 19:38:38 +0000

Ole,

Whatever we decide, I will use the same value in draft-bonica-6man-vpn-dest-opt.

                                                              Ron

Juniper Internal

> Sent: Wednesday, May 8, 2019 3:33 PM
> It is also a name space shared by both IPv4 and IPv6, and would this mean we
> were going to define next headers that were only valid after an SRH header?
> 
> Ole
> 
> >
> >>> Sections 4.4 through 4.12 of
> >>> draft-ietf-spring-srv6-network-programming-
> >>> If the payload is IPv4, the next-header value in the SRH must be IP4
> >>> (value
> >> 4).
> >>> If the payload is IPv6, the next-header value in the SRH must be
> >>> IPv6 (value
> >> 41).
> >>> No Next
> >> Header (value 59).
> >>> In the interest of consistency, we should probably allocate a new
> >>> next-
> >> header value for Ethernet and use it.
> >>
> >> What would a general IP stack do with an Ethernet frame? It's kind of
> >> a neat feature that "IP processing terminates here".

---

From: Ron Bonica <[email-masked]>
Date: Wed, 8 May 2019 19:44:12 +0000

Tom,

If the authors of the network programming draft are willing to impose the two-byte header between the SRH and the Ethernet frame, 97 works.

I will let them speak for themselves regarding there willingness to do so.

                                                                  Ron

Juniper Internal

> Sent: Wednesday, May 8, 2019 3:17 PM
> Cc: Bob Hinden <[email-masked]>; Ole Trøan
> <[email-masked]>; SPRING WG <[email-masked]>; IPv6 List
> <[email-masked]>
> > The value 97 is tempting, but it already has a meaning that is slightly
> different from what the authors of draft-ietf-spring-srv6-network-
> programming intend. According to RFC 3378, a value of 97 means that the
> next header will be as depicted in Figure 2 of RFC 3378.
> >
> 
> Ron,
> 
> The spring draft states:
> 
> "If the outer header is pushed without SRH, then the DA must be a SID of type
> End.DX2, End.DX2V, End.DT2U or End.DT2M and the next-header must be 59
> (IPv6 NoNextHeader).  The received Ethernet frame follows the IPv6 header
> and its extension headers."
> 
> encapsulated Ethernet or IEEE 802.3 frame that immediately follows IP fields."
> 
> That also describes Ethernet in IP encapsulation. The only difference is the
> presence of the two byte EtherIP header. As already mentioned this is
> important for maintaining alignment of the encapslated Ethernet payload, and
> is otherwise inconsequential overhead.
> 
> > > >> If the payload is IPv4, the next-header value in the SRH must be
> > > >> IP4 (value
> > > 4).
> > > >> If the payload is Ethernet, the next-header value in the SRH must
> > > >> be No
> > > Next Header (value 59).
> > > >>

---

From: Ole Troan <[email-masked]>
Date: Wed, 8 May 2019 21:47:36 +0200

Hi Ron,

> Whatever we decide, I will use the same value in draft-bonica-6man-vpn-dest-opt.

Ah, right. Because in your proposal the VPN Context Information contains the forwarding instructions?
Seems a little underspecified in the draft, or am I missing something?
And that is information signalled separately?

Cheers,
Ole

---

From: Ron Bonica <[email-masked]>
Date: Wed, 8 May 2019 20:37:51 +0000

Ole,

Inline....

                Ron

Juniper Internal

> Sent: Wednesday, May 8, 2019 3:48 PM

Yes.

> Seems a little underspecified in the draft, or am I missing something?

Standby for an update on the draft....

> And that is information signalled separately?

Yes. Standby for that draft, too.

                                             Ron
> >> But it is an 8-bit number space, so clearly if anyone wants more bits
> >> than that, they cannot rely on the protocol field.
> >> It is also a name space shared by both IPv4 and IPv6, and would this
> >> mean we were going to define next headers that were only valid after an
> SRH header?
> >>
> >> Ole
> >>
> >>>
> >>>>> be No Next
> >>>> What would a general IP stack do with an Ethernet frame? It's kind
> >>>> of a neat feature that "IP processing terminates here".

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 May 2019 18:25:01 +1000

> ><snip>

> "nothing" views the packet with suspicion!

Of course. Anything that appears in a frame or packet that is beyond
what is after the IPv6 header's payload length field says is an
opportunity for a covert channel.

> discussion, but host processing is.

I mentioned it as a possible reason for the forwarding unchanged text.

I wouldn't be surprised if the text was in response to somebody asking
whether, during forwarding, should devices be purposely performing
packet payload sanitisation or not by following EH chains and
validating them? They'd be a lot slower if they did.

> accounted for in IP Payload Length.

Not intentionally.

Say the actual IPv6 packet length is 40 bytes (i.e. fixed header by
itself, NH = 59). Due to an error, say a bit flip in memory or
off-by-one, the Payload Length is set to 1 rather than 0. Since the
actual entire IPv6 packet size is < 46 bytes, Ethernet padding will
add another 6 bytes to the 40, rounding the Ethernet payload up to the
minimum of 46 bytes.

At the receiver, one of those Ethernet padding bytes is now part of
the IPv6 packet according to the Payload Length. However, when the NH
value of 59/No Next Header value is processed at the final
destination, "those octets must be ignored", so the invalid padding
byte is discarded.

>If the Payload Length extends
> No-next-header. The question is why would they do this?

Covert channel could be the only other reason.

> Yes, sending

Security and robustness can be in conflict.

Robustness is "can you make it work", security is "should you make it work".

As RFC8200 says to ignore those octets, and doesn't say to drop the
packet if there are extra octets, then robustness would seem to be the
winner in this case.

Regards,
Mark.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 9 May 2019 10:05:26 +0100

> It's a fairly precious name space though.

Agreed, it has to last for the entire lifetime of the Internet.

Indeed, I wonder if we should do what we did with MPLS reserved/special 
purpose labels and create an extension mechanism now rather than when
we actually run out of space. That way less critical applications
can use the less convenient longer identifier.

> Or are we going to specify Ethernet over IP?

Looking at NH=97 there seems to be an existing solution in place that 
exactly addresses the need for carrying Ethernet over IP, so I don't see 
why that is not used. It is only 16 bits and a single check to confirm 
the version, and if implementers and operators are convinced that the IP 
address is sufficiently safe as a check, then it is only two extra bytes 
to write on transmit and two bytes to skip receive.

The extra bits that NH=97 has reserved may also be useful in the long 
term. For example it seems likely that an OAM/ACH mechanism will 
eventually be needed at this encapsulation layer (just as it was 
eventually needed with the Ethernet over MPLS pseudowire). It would be 
hard to retrofit an OAM indicator with NH=59, but trivial with NH=97.
So trivial in fact, I suspect that it ought be considered as part of the 
initial specification.

I suspect that we will be far more likely regret this use of 59 in the 
long term than we will regret changing to 97 at this early stage.

- Stewart

---

From: Ole Troan <[email-masked]>
Date: Thu, 9 May 2019 11:12:47 +0200

> On 9 May 2019, at 11:05, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 
> Indeed, I wonder if we should do what we did with MPLS reserved/special purpose labels and create an extension mechanism now rather than when
> Looking at NH=97 there seems to be an existing solution in place that exactly addresses the need for carrying Ethernet over IP, so I don't see why that is not used. It is only 16 bits and a single check to confirm the version, and if implementers and operators are convinced that the IP address is sufficiently safe as a check, then it is only two extra bytes to write on transmit and two bytes to skip receive.
> 
> The extra bits that NH=97 has reserved may also be useful in the long term. For example it seems likely that an OAM/ACH mechanism will eventually be needed at this encapsulation layer (just as it was eventually needed with the Ethernet over MPLS pseudowire). It would be hard to retrofit an OAM indicator with NH=59, but trivial with NH=97.
> So trivial in fact, I suspect that it ought be considered as part of the initial specification.
> 
> I suspect that we will be far more likely regret this use of 59 in the long term than we will regret changing to 97 at this early stage.

But it’s not that nh=59 can be used to imply that Ethernet follows. That would be very bad. 

It’s that ip processing stops here. 

Then if the two ends have agreed the meaning of the remaining payload and how to process it, that’s fine. If that signaling is in-band e.g in a particular SID or out-of-band, the principle is the same. 

Cheers,
Ole

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 9 May 2019 10:43:51 +0100

> The whole point of these identifies is to tell the reader what the meaning is of what follows. Using value 59 like this looks like "when we say 'no-next-header' we actually mean 'ethernet' (probabl…

Exactly.

The exception that allowed Ethernet Pseudowires (PW) to run without the 
PW control word was introduced because some hardware could not process 
the control word at the time of initial roll-out. This led
to many complexities over the development life of PWs.

Eventually PALS had requests from both the operator community and the 
IEEE to address this problem which is why the latest RFC produced by the 
PALS WG is:

"Recommendation to Use the Ethernet Control Word"
https://datatracker.ietf.org/doc/rfc8469/

Referring back to the email I just sent earlier, a consequence of 
allowing Ethernet to run without the control word was significant 
complexity around PW OAM. OAM was also something that we did not 
originally think would be needed when we started the PW design around 
the year 2000, but we soon found out that it was an integral part of PW 
operations.

With NH=97 you have the bits that you need to introduce the essential 
characteristics of a control word - version and some bits for an 
associated channel identifier. The ACH identifier space available is 
much less in NH=97 than in the PW Control Word. However so far there 
have only been 24 channels (plus 8 Experimental Channels) allocated for 
use with Ethernet over MPLS PWs, so it ought to be possible to provide 
all of the support services needed in the 16 bits available in NH=97 
rather than requiring the 32 bits we used in PWs.

https://www.iana.org/assignments/g-ach-parameters/g-ach-parameters.xhtml

Of course if it turns out that 16 bits is not enough, then NH=97 has
a version field which allows the seamless introduction of new features
without needing a new NH type provided the version field check is
mandatory in the first version of the Standard.

- Stewart (PWE3 and then PALS chair)

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 9 May 2019 12:17:34 +0100

> Then if the two ends have agreed the meaning of the remaining payload and how to process it, that’s fine. If that signaling is in-band e.g in a particular SID or out-of-band, the principle is the s…

Yes, but experience suggests that having no control word and no ability 
to retrofit one is a long term problem waiting to happen.

Stewart

---

From: Ole Troan <[email-masked]>
Date: Thu, 9 May 2019 13:29:39 +0200

> Yes, but experience suggests that having no control word and no ability to retrofit one is a long term problem waiting to happen.

I think this is a philosophical debate.
Does a packet have to be entirely self-describing or can a end-point learn how to interpret part of a packet out-of-band.

Personally I think there is a use of nh=59 to end IP processing and allow further payload.
If this particular mechanism is a good use for this particular use case of SR, I have no opinion.

Cheers,
Ole

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 9 May 2019 07:58:17 -0400

I think it is equally important to note that given an existing way of 
encapsulating Ethernet in IP, one ought to have a good reason for 
creating a different one.  There is no indication that this use case 
needs anything different than next-header 97.

And Ole, no next-header does not, as far as I can tell from 8200 and its 
predecessors mean "the end of IP processing."

Yours,
Joel

On 5/9/19 7:17 AM, Stewart Bryant wrote:
>>>>> draft-ietf-spring-srv6-network-programming-00 define a set of SIDs 
>>>>> that have the following things in common:
>>>>>
>>>>> IP4 (value 4).
>>>>> IPv6 (value 41).
>>>>> be No Next Header (value 59).
>>>>>
>>>>> next-header value for Ethernet and use it.
>>> Indeed, I wonder if we should do what we did with MPLS 
>>> reserved/special purpose labels and create an extension mechanism now 
>>> rather than when
>>> exactly addresses the need for carrying Ethernet over IP, so I don't 
>>> see why that is not used. It is only 16 bits and a single check to 
>>> confirm the version, and if implementers and operators are convinced 
>>> that the IP address is sufficiently safe as a check, then it is only 
>>> two extra bytes to write on transmit and two bytes to skip receive.
>>>
>>> eventually needed with the Ethernet over MPLS pseudowire). It would 
>>> be hard to retrofit an OAM indicator with NH=59, but trivial with NH=97.
>>> I suspect that we will be far more likely regret this use of 59 in 
>>> the long term than we will regret changing to 97 at this early stage.
>>
>> Then if the two ends have agreed the meaning of the remaining payload 
>> and how to process it, that’s fine. If that signaling is in-band e.g 
>> in a particular SID or out-of-band, the principle is the same.
>

---

From: Ole Troan <[email-masked]>
Date: Thu, 9 May 2019 14:36:54 +0200

> I think it is equally important to note that given an existing way of encapsulating Ethernet in IP, one ought to have a good reason for creating a different one.  There is no indication that this use case needs anything different than next-header 97.
> 
> And Ole, no next-header does not, as far as I can tell from 8200 and its predecessors mean "the end of IP processing."

Huh? What do you think it means then?

Btw, here is the original request for the no-next-header:

Date: Mon, 28 Nov 1994 14:46:50 +1100
Message-Id: <[email-masked]>
From: Robert Elz <[email-masked]>
Sender: [email-masked]
Precedence: bulk
Reply-To: [email-masked]

If I wanted to send an IP6 packet without any TCP, UDP, ICMP,
or similar, data, just, say, end to end options, or something,
which may be useful for sopme purpose or other in the futuew,
what do I stick in the next header field?

The length from the packet header will indicate that there's
nothing after the last processed header, but just sticking in
a random "next header" value and relying on the length field
seems wrong to me.

Alternatively, can someone say that its illegal to not have
one of the transport level protocols in every IP6 packet,
and will be for all (relevant) time?

kre

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 9 May 2019 08:45:48 -0400

No next header means exactly what the original request, and the 
documentation, says.  There is nothing in the packet past this IP 
header.  It does not mean that there is some next header defined by some 
other context.

Yours,
Joel

---

From: Ole Troan <[email-masked]>
Date: Thu, 9 May 2019 14:52:40 +0200

Joel,

> No next header means exactly what the original request, and the documentation, says.  There is nothing in the packet past this IP header.  It does not mean that there is some next header defined by some other context.

Why allow for payload to follow and a "must" requirement to forward it, unless as a future extension point.

And kre also alludes to a "or something" and "other in the future"...

It certainly does not mean nothing is past this IP header. Nor does it mean that there is some next header defined by some other context.
It is an extension point. If people found some use for that, what's the harm? That middle boxes get confused? Isn't that a feature? ;-)

Cheers,
Ole

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 9 May 2019 08:56:06 -0400

Two separate things.
First, it clearly is not just about IP processing or we would have no 
next-headers for TCP, UDP, or tunnels.  Which we do.
Second, we have a value that means that Ethernet Follows.  So clearly it 
is no-header is no for the Ethernet case.
Finally, since we have a value thaqt means Ethernet, why would we 
instead stretch some other value to sometimes mean Ethernet.

While there may have been some thought that it might be an extension 
mechanism, I have never read it as meaning that, and I have never seen a 
case where we would want to use "no-next-header" to mean "next header of 
some other kind."

Since we don't need it for this case, I guess we can disagree about 
whether in theory some other case might be allowed.

Yours,
Joel

---

From: Ron Bonica <[email-masked]>
Date: Thu, 9 May 2019 14:10:50 +0000

Ole,

That's fine, but which ever way the debate ends, the draft should be consistent. IMHO, the two ways to achieve consistency are:

- Sections 4.4 - 4.12 all use 59
- Sections 4.4-4.12 all use something other than 59

                                                                          Ron

Non-Juniper

> Sent: Thursday, May 9, 2019 7:30 AM
> To: Stewart Bryant <[email-masked]>
> Cc: Ron Bonica <[email-masked]>; SPRING WG <[email-masked]>; Bob
> Hinden <[email-masked]>; 6man WG <[email-masked]>
> >>> I suspect that we will be far more likely regret this use of 59 in the long
> term than we will regret changing to 97 at this early stage.
> and how to process it, that’s fine. If that signaling is in-band e.g in a particular
> SID or out-of-band, the principle is the same.
> >
> > Yes, but experience suggests that having no control word and no ability to
> retrofit one is a long term problem waiting to happen.
> 
> Does a packet have to be entirely self-describing or can a end-point learn how
> to interpret part of a packet out-of-band.
>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 9 May 2019 08:16:39 -0700

Mark,

Sure, but the Payload Length field isn't only field that can be
corrupted. Maybe a next-hdr field flips from TCP to no-next-header. So
now the receiver does see the thousand byte byte packet with
no-next-header. There is no way to distinguish between this case and
someone using the bytes as a covert channel. But, in practice
distinguishing the two cases really doesn't matter-- there's currently
no legitimate use case for data after no-next-header, so it shouldn't
be surprising if firewalls were to simply drop packets that have any
data following no-next-header. In the current definition of
no-next-hdr probably no one will complain about this, but when someone
does define a legitimate use case they'll probably be unhappy to see
the network dropping packets.

Tom

---

From: "john leddy.net" <[email-masked]>
Date: Thu, 9 May 2019 21:08:34 -0400 (EDT)

Should the NextHeader values be a union of all the Link layer protocol types over IPv6, Ethertypes, IP Protocols, Next Headers and Well known ports - maybe, but it seems tough to get into 8 bits...

Thank the stars that all those application guys use the well known ports for the correct protocols or the Internet would fall apart.  Can you imagine running HTTP over a random port - or even more laughable something other than HTTP over port 80. Heresy!

How would you know what header it is?

John

> On May 8, 2019 at 3:44 PM Ron Bonica <rbonica=[email-masked]> wrote:
> 
> 
> Tom,
> 
> > > > > of a neat