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 > -----Original Message----- > From: Bob Hinden <bob.hin...@gmail.com> > Sent: Wednesday, May 8, 2019 2:45 PM > To: Ole Trøan <otr...@employees.org> > Cc: Bob Hinden <bob.hin...@gmail.com>; Ron Bonica > <rbon...@juniper.net>; Tom Herbert <t...@herbertland.com>; SPRING WG > <spring@ietf.org>; IPv6 List <i...@ietf.org> > Subject: Re: SRv6 Network Programming: ENH = 59 > > Ole, > > > On May 8, 2019, at 11:13 AM, Ole Troan <otr...@employees.org> wrote: > > > > Ron, > > > >> <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. > > > > It's a fairly precious name space though. > > 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 > > Seems like a lot left. Plus there are many that are clearly not used > anymore, so > there isn’t a shortage. > > > > > 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? > > Look at the the registry, it looks to me we have already > > 97 ETHERIP Ethernet-within-IP Encapsulation [RFC3378] > > 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 > > > > > > > > Cheers, > > Ole _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring