Re: [spring] SRv6 Network Programming: ENH = 59

[Brian E Carpenter <[e-mail]>]

On 07-May-19 12:20, Mark Smith wrote:
> 
> 
> On Tue., 7 May 2019, 06:14 Stewart Bryant, <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     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]]
> 
> 
> 
> 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 06/05/2019 16:54, Bob Hinden wrote:
>     > Ron,
>     >
>     >> On May 5, 2019, at 5:47 PM, Ron Bonica <rbonica=[e-mail] <mailto:[e-mail]>> 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?
>     >
>     > 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
>     >
>     > _______________________________________________
>     > spring mailing list
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/spring
>     >
> 
>     _______________________________________________
>     spring mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/spring
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>