Subject: [mobile-ip] [ISSUE] Design team recommendation: New recommendation on piggybacking

From: [email-masked]
Date: Wed, 27 Feb 2002 18:11:42 -0600

<chair hat off>

>3. RECOMMENDATIONS
>
>The design team recommends the following:
>
>R1. A Separate protocol and/or port should be used for the BR
>     message, all RR messages, BU message and BA message.  This
>     will allow - but not mandate - the use of current IPsec
>     selectors in protecting BUs to the CN and HA, and RR
>     messages via the HA. The value of next protocol = none
>     must be supported by all MIPv6 compliant nodes in these
>     messages.
>

Agree.

>R2. Reserve some space for preference bits in the RR messages
>     1a and 1b, to allow the CN and the MN to describe their
>     preferences. Only the space is reserved, but no meaning
>     is assigned to the bits.
>
>     The potential use of those bits is to allow a CN, for
>     instance, tell the MN that it allows the reception of
>     piggybacked signaling. However, compliant nodes can leave
>     all the bits as zero. This is necessary in order to allow
>     implementations that do not have the API between MIPv6 and
>     IPsec.
>

Can agree with the following change:
Rather than simply reserving space, if the meaning to these bits is
assigned. 

>     There is also other potential use of the bits, e.g.
>     selecting some variants of stronger BU authorization
>     methods, but these are not discussed here.
>
>R3. The above two recommendations should be placed in the
>     MIPv6 RFC. This would allow us to quickly proceed to RFC
>     status by bypassing controversial content, have as simple
>     RFC and implementations as possible, but still allow
>     functionality like piggybacking to be specified without
>     interoperability concerns, and used by all nodes who
>     support it.
>

Agree.

>R4. Separate RFCs would define the use of these bits. For
>     example, their use in piggybacking would need to define
>     the following:
>
>       - Allocate a bit in the reserved space in the RR messages
>         1a/2a, and describe its semantics.
>       - Describe in detail which messages can use piggybacking,
>         if it is allowed, and under which conditions.
>       - Rules for sending the optional payload along.
>       - Rules for receiving the optional payload.
>       - Rules on what to check from the IPsec policy
>         before deciding to use piggybacking.

Same comment as for recommendation R2.

>R5. At a future time, IF IPsec selectors can be extended in
>     some manner, the RFC described under R4 could be updated
>     to extend the rules under which piggybacking is possible
>     i.e. no IPsec checks would be necessary any more.
>

Agree.

-Basavaraj 

</chair hat off>