On 09/08/2016 01:16 PM, Robert Moskowitz wrote: > This is more to implementors or people that understand network stacks... > > We provided in 7401 a Next Header field as all good IPv6 payloads are > suppose to do. But we really have not used it in front of 'real' IPv6 > payloads like ESP, TCP, UDP, or IPnIP. Or have we and I have just > missed it?
The HICCUPS RFC describes a use of it. https://tools.ietf.org/html/rfc6078 > > Anyway this is for faster mobility; looking at 5206-bis and IF the > payload is small enough to fit in a HIP UPDATE, to send the Mobility > UPDATE along with the actual first data from the moving host. > > This question is primarily 'will the stack handle this'? That is, HIP > gets to payload first. If validates the UPDATE, changes the necessary > bindings the either: > > pushes a revised frame without the HIP UPDATE back into the IP > interface > or sends the Next Header off to where it belongs. > > I am not a person that has dealt with the insides of the OS(s) to know > how this would be done or if it is really practical. The data plane for HIP-supported sessions can be implemented in userspace or kernel (reusing kernel IPsec handling). If purely userspace (all packets are shunted to userspace) it seems like it would not be terribly difficult to do. If kernel space handling such as Linux XFRM, I'm guessing that a stack modification would be needed. > > Oh, and what is the length of the basic HIP UPDATE in 5206-bis? I can > do my best calculation in a bit, but if someone has it... HIP header 40 bytes ESP_INFO 16 bytes LOCATOR_SET (minimal) ~32 bytes SEQ parameter 8 bytes so on the order of 96 bytes; more if more than one locator involved > > thanks > > Bob > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
