![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Hi Sami, On Tuesday, 10 Feb 2004, sami.vaarala@iki.fi wrote: > Here's a small strawman draft regarding MIPv4 overhead optimization: > > http://www.ietf.org/internet-drafts/draft-vaarala-mip4-optudp-00.txt > > The draft applies when the MN sends most of its traffic to > *one* particular CN, in which case overhead to that particular > CN can be optimized. The mechanism applies at least to the > case where MIPv4 provides mobility for IPsec tunneling - > e.g. the normal IPsec-over-MIPv4 situation. It might also > apply to some VoIP scenarios. Quite interesting, and still straightforward. Comments after a swift read-through: In section 2.3, Optimized UDP Tunnel Reply Extension, I think it would be good to have an explicit flag to indicate acceptance or rejection of optimized tunnelling, rather than letting presence/ absence of the extension itself indicate this. To support legacy HAs you still need to handle absence as a no to optimization, though. Having an explicit flag is 1) cleaner, and 2) if there in the future would be more than one optimization possibilities, it would be nice if a HA could indicate that Yes, it understands optimization, but No, it won't accept the particular one proposed in the RRQ. In section 5, Security Considerations, it is not immediately obvious to me what you mean when you say the "inner" IPv4 header can be easily tampered with - in the optimized case there is no inner IPv4 header, no? In section 6, Alternatives, New message type - I don't see any benefit from this Multiple preferred CNs - possible, but should maybe be left as a later exercise, once there is some experience with this implementation? In that case, an index into a list of CNs would be more appropriate than a set of bits, though. FA support - Mixed feelings. It's needed in order to be a complete solution, at the same time as FA deployment seems to be negligible. Best, Henrik
Attachment:
pgp00080.pgp
Description: PGP signature