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=40juniper....@dmarc.ietf.org> > wrote: > > > 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 > > > -----Original Message----- > > From: Tom Herbert <t...@herbertland.com> > > Sent: Wednesday, May 8, 2019 3:17 PM > > To: Ron Bonica <rbon...@juniper.net> > > Cc: Bob Hinden <bob.hin...@gmail.com>; Ole Trøan > > <otr...@employees.org>; SPRING WG <spring@ietf.org>; IPv6 List > > <i...@ietf.org> > > Subject: Re: SRv6 Network Programming: ENH = 59 > > > > On Wed, May 8, 2019 at 11:55 AM Ron Bonica <rbon...@juniper.net> wrote: > > > > > > 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, > > > > 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 > > > > > > > > > > > > > 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 > -------------------------------------------------------------------- > 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
