On 07-May-19 12:20, Mark Smith wrote: > > > On Tue., 7 May 2019, 06:14 Stewart Bryant, <stewart.bry...@gmail.com > <mailto:stewart.bry...@gmail.com>> 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=40juniper....@dmarc.ietf.org <mailto:40juniper....@dmarc.ietf.org>> > 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 > > spring@ietf.org <mailto:spring@ietf.org> > > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > spring mailing list > spring@ietf.org <mailto:spring@ietf.org> > https://www.ietf.org/mailman/listinfo/spring > > > -------------------------------------------------------------------- > 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
