Ole, > On May 8, 2019, at 11:13 AM, Ole Troan <[email protected]> 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://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml 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 [email protected] https://www.ietf.org/mailman/listinfo/spring
