-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(s2n-quic-core): add L2/L3/L4 inet structs #1638
Conversation
} | ||
} | ||
|
||
impl Vihl { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to explicitly call out any opaque boundaries. E.g. Vihl
represents Version
information in the most significant 4 bits and IHL
is the least significant 4 bits. Although this is pretty easily inferred from the RFC diagram, it's nice to give people help when trying to decipher bit operations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar thing for the Tos
struct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can add some notes
} | ||
} | ||
|
||
define_inet_type!( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm relatively unfamiliar with the ipv4 networking stack, but this type feels particularly dense. It looks like the most significant 3 bits are reserved for reserved
, DF
and more fragments
fields, but the fragment_offset
and set_fragment_offset
aren't immediately clear to me. I can tell you what bits they return, but I don't really understand why they are used for.
} | ||
} | ||
|
||
define_inet_type!( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thing about opaque boundaries (calling out in a comment that the version field is the 4 most significant bits, etc), especially since the RFC diagram doesn't include the field lengths.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, nevermind, it apparently does specify lengths. I just counted that flow label was 20 bits long and assumed that wasn't accurate. So just explicitly calling that out would be nice.
Description of changes:
When using raw sockets or AF_XDP, the userspace is in charge of complete packet construction and parsing. This includes ethernet, IP, UDP, etc.
This change implements decoding/encoding for
Call-outs:
Some things are known to be missing at this point and will be added at a later time:
Testing:
For each of the header formats, I've added:
[0, 1, 2, 3, ...]
)[255, 255, 255, ...]
)By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.