Hi, > 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?
The next-header should identify what follows, so that anybody parsing the packets knows what to expect. Using "No Next Header" should mean "nothing follows". Once we start using No-next-header for "some stuff may follow" it will become very hard to make sense of packets. Overloading the meaning of no-next-header will only create confusion. What when someone starts using it for "encrypted stuff follows"? How do we distinguish between "payload is ethernet" and "payload is encrypted"? The whole point of these identifies is to tell the reader what the meaning is of what follows. Using value 59 like this looks like "when we say 'no-next-header' we actually mean 'ethernet' (probably)". That's just bad engineering, and reminds me of MPLS implementations that tried to guess what the payload was by looking at the first nibble (if it's 4 then it's probably an IPv4 packet, if it's a 6 then it's probably IPv6 and otherwise we treat it as ethernet). That kind of worked until MAC addresses starting with 4 and 6 started to be used... Let's not make such mistakes again and put proper labels on our payloads. Cheers, Sander
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
