FWIW, my general concern with this service is that lacks a version identifier, and cannot be extended to support such an identifier for bare IP packets as payloads, as encouraged by RFC7605 Section 7.5
At a minimum, one of the first fields after the "Version 0" format identifier (a name which is confusing, for this reason) needs to be a version field, so that future variants of this service will not need a new port assignment. Joe On 5/25/2017 12:07 PM, Joe Touch wrote: > > > > On 5/25/2017 11:47 AM, Tom Herbert wrote: >>> You can't put bare Ethernet inside GUE. You need to use EtherIP - >>> exactly because it has a 16-bit field, of which only the first 4 bits >>> are (already) defined. >>> >>> My point is that EtherIP burns 16 bits vs bare Ethernet, but those 16 >>> bits allow it to be mapped to one of the IP versions (you picked IPv5). >>> The same trick works for UDP and TCP - just pick a different 16 bit >>> pattern for each one. >>> >> Inserting two bytes before the TCP header breaks four byte alignment >> of the header which is a bigger hit than the benefit of saving two >> bytes. A nice side effect of the two byte header in EtherIP is that it >> aligns the Ethernet payload (e.g. an IP header) to four bytes. >> Maintaining this four byte alignment is still important to some CPU >> architectures most notably Sparc, but can even be problematic to x86 >> under certain circumstances. >> >> Tom > Sure - I'm not sure the 4-byte penalty is worth avoiding any nearly > any case, frankly -- even for IP. > > Joe
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
