Sander, > > 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.
That is not correct in the general. E.g. you could use a control protocol or some other mechanism to signal the required information. I think in the "Patterns of Networking" J Day proposes a scheme without demuxing on protocol/ports (but the details elude me at the moment). Cheers, Ole _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
