Re: [Mip4] draft-vaarala-mip4-optudp-00
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mip4] draft-vaarala-mip4-optudp-00



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


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.