On Wed, 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. > 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?
Ole, Ethernet over IP is already specified in RFC3378 and protocol number 97 is assigned to encapsulate Ethernet frames in IP. The only change required in the spring draft is: If the payload is Ethernet, the next-header value in the SRH must be EtherIP (value 97). Tom > > Cheers, > Ole _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
