Subject: Re: [mobile-ip] MIPv6 Draft 18 Comments

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 18 Sep 2002 11:49:26 -0700

Hello Samita,

Samita Chakrabarti wrote:

> 1.
> Section 4. Basic Operation
> 
> It's good add a subsection at the end to describe the two
> modes of operation for clarity :
> 1) MN-CN communication through reverse tunnel via HA
> 2) MN-CN communication using Route Optimization
>    In this section, we can specify that RR procedure
>    is the default RO mechanism defined in this draft.

Done!  Shall I post the text to the list?  It's a bit
long to fit in this point-by-point responsive format...

> 2.
> Since, lifetime field has been changed to
> 16 bit, s/0xffffffff/0xffff

Done!

> 3.
> section 6.1.7 (BU)
> Now that we removed home-address field from the BU
> message and made HAO manadatory for all BUs for
> which src-addr is not home-addr. A line after the
> following paragraph is needed:
> 
> A Binding Update to the home agent MUST include the Home Address
>    destination option if the Source Address field in the IPv6 header is
>    not the home address of the mobile node.
> 
> i,e.
>  A binding Update to the Correspondent node MUST include
> home address option (section 9.4.1) .

Done!

> 3.
> section 6.1.8 indicates that we don't have "no Security
> Association" status code anymore and we have:
> 
> 137   Invalid authenticator
> 
> That suggests Binding Authorization Data Option is manadatory
> for all binding update messages--correct ?
> If that is the case, then that must be specified in 6.1.7
> as well. Otherwise, we need another status error code or
> specification when the HA or CN receives a BU without
> binding authorization data option.

The Binding Authorization contains an authenticator.
If it's invalid, then this status code can deliver the
indication.

> 4.
> 
> 6.1.9
> 
> Status code 1:
> 1   Home Address destination option used without a binding
> Is this still valid ?

Why not?  Isn't that a valid reason to use the Binding Error?

> 5.
> section 8.2 Route Optimization Requirements for All IPv6 Nodes
> 
> It's missing the MN behavior,
> 
> How about adding a text something like this?
> 
> A node that is performing mobile node operation MUST be able to
> process RTHDR_TYPE2 extension header (section 11.2.3 and 6.4).
> All other nodes MUST ignore and drop RTHDR_TYPE2 extensions.

The list of requirements pertains to correspondent nodes.
The requirement you want is that the correspondent node
MUST ignore RTHDR_TYPE2 unless it has transmitted a
Binding Update to the originator of the packet.  It would
be a mistake to drop the packet, though.  The header might
be there for other reasons unrelated to any functionality
of the correspondent node (e.g., it was previously processed
by a mobile router before the mobile router forwarded the
packet to the correspondent node.

> 6.
> section  8.4
> 
> One more requirement to be added:
> 
> - Every home agent MUST support IPSec ESP for protection of
>   packets belonging to Return Routability Procedure (section
> 10.7).

Done!

> 7.
> 
> section 8.5
> 
> Additional requirement:
> 
> -MUST be able to process RTHDR_TYPE2 extension header as defined
>  in 6.4 and 11.2.3

Done!  Good point!

> 8.
> 
> section 9.2.2 , section 9.4.6 needs update as they specify that
> HAO without binding asociation MUST be dropped.

I didn't understand this point.  The mandate is already present in
section 9.2.2, and 9.4.6 is about what happens in the error case.

> 9.
> section 10.3
> 
> remove:
> -  The Refresh field MUST be set to zero.

Done.

> 10.
> section 9.4.1
> s/144/138
> s/145/139
> s/141/135

These have been fixed.

> 11.
> section 10. Home Agent Operation
> 
> Should not we have a section here on "Processing Binding Updates" ?

Sections 10.2 and 10.3 are supposed to cover that, in the
two major cases.

Should they be renamed?  What I did do was to create a new
term for "registration":
        The process during which a mobile node sends a binding update
        to its home agent, causing the home agent to take the actions
        which will enable packets to be forwarded from the mobile node's
        home network to the mobile node's care-of address.

Regards,
Charlie P.

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 20 Sep 2002 17:35:37 -0700 (PDT)

Hello Charlie,

> long to fit in this point-by-point responsive format...

Thanks. Posting the text in the alias perhaps would be nice.

> If it's invalid, then this status code can deliver the

Jari opened iseeue #100 for this set of comments. We discussed :

Rename  137 as :

137     Invalid or missing authenticator

So, it will be perfectly applied to CN case and HA case. Except we discussed
that if HA receives a BU without "any security association" then it should
drop the packet.

> Why not?  Isn't that a valid reason to use the Binding Error?

Draft 17 was mandating that HAO MUST NOT be there when sending BU to
CN. So this error message may be directly applicable. Now we require
HAO with binding updates for CN and HA. So, when a CN and HA receive
a BU, HAO must be there before or after binding happens (first BU and then 
refresh)

But Jari made a suggestion to rename this error code to
" Home Address destination option used without sufficient validation",
which I think makes sense to have specified.

> packet to the correspondent node.

As a CN funtion, there is no use of processing RTHDR_TYPE2 routing
header in the receive side. I am not sure why would mobile router
forward a packet with RTHDR TYPE 2 to a CN which is acting as CN only.

But, folks can argue, that this may be too implementation specific
deetails. I'd like to see a clarification for CN only systems, that
it either ignore RTHDR TYpe 2 ext header upon receiving or it should
drop the packet as it can't process the extension otherwise.

> section 9.2.2, and 9.4.6 is about what happens in the error case.

Issue #100. It's I think the remaining text from draft 17, this needs
to change with the new rule that HAO will always accompany a binding
update.

>         home network to the mobile node's care-of address.

I am not sure I quite follow. Looking at the index, it was not clear that
Home Agent also processes BUs-- so I requested to clarify or rename the
section name.

Thanks very much for taking care of the changes.

-Samita