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

[Bob Hinden <[e-mail]>]

Ole,

> On May 8, 2019, at 11:13 AM, Ole Troan <[e-mail]> 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