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

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.net@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 <tom@herbertland.com>
> > Sent: Wednesday, May 8, 2019 3:17 PM
> > To: Ron Bonica <rbonica@juniper.net>
> > Cc: Bob Hinden <bob.hinden@gmail.com>; Ole Trøan
> > <otroan@employees.org>; SPRING WG <spring@ietf.org>; IPv6 List
> > <ipv6@ietf.org>
> > Subject: Re: SRv6 Network Programming: ENH = 59
> > 
> > On Wed, May 8, 2019 at 11:55 AM Ron Bonica <rbonica@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.hinden@gmail.com>
> > > > Sent: Wednesday, May 8, 2019 2:45 PM
> > > > To: Ole Trøan <otroan@employees.org>
> > > > Cc: Bob Hinden <bob.hinden@gmail.com>; Ron Bonica
> > > > <rbonica@juniper.net>; Tom Herbert <tom@herbertland.com>; SPRING
> > WG
> > > > <spring@ietf.org>; IPv6 List <ipv6@ietf.org>
> > > > Subject: Re: SRv6 Network Programming: ENH = 59
> > > >
> > > > Ole,
> > > >
> > > > > On May 8, 2019, at 11:13 AM, Ole Troan <otroan@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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------