Subject: [mobile-ip] MIPv6 Draft 18 Comments

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 9 Aug 2002 11:35:36 -0700 (PDT)

Better late than never :-)

Draft 18 is more organized than draft 17. Thanks for adding sections
on node requirements for supporting RO to make things clear.

The following are my comments (some of them may be already
mentioned by the previous reviewers):

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.

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

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) .

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.

4.

6.1.9

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

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.

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).

7.

section 8.5

Additional requirement:

-MUST be able to process RTHDR_TYPE2 extension header as defined
 in 6.4 and 11.2.3

8.

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

9.
section 10.3

remove:
-  The Refresh field MUST be set to zero.
10.
section 9.4.1
s/144/138
s/145/139
s/141/135

Perhaps there are more cases throughout the document.

11.
section 10. Home Agent Operation

Should not we have a section here on "Processing Binding Updates" ?

-Samita

---

From: Jari Arkko <[email-masked]>
Date: Tue, 20 Aug 2002 15:20:13 +0300

>    is the default RO mechanism defined in this draft.

Agreed. (I'll group this and the following items under
a new issue #100.)

> 16 bit, s/0xffffffff/0xffff

Yes.

> home address option (section 9.4.1) .

Ok, this is being discussed separately. I think we are leaning
towards having a HAO always.

> for all binding update messages--correct ?

Not quite. BAD (!) options are mandatory for CN binding updates,
but not for HA binding updates.

> binding authorization data option.

My suggestion is to rename 137 as "Invalid or missing authenticator",
which would cover the case where BAD wasn't included in a BU to a
CN.

> 1   Home Address destination option used without a binding

I think it is still valid, but a more proper name would perhaps
be "Home Address destination option used without sufficient validation",
the validation mechanisms being (1) existing binding or (2) use of
IPSec.

Note that this issue is separate from the discussion of whether or
not the HAO and the IPsec validation are mandatory. (Whether or not
they are, it is still possible that someone sends an unauthenticated
HAO without a binding.)

> All other nodes MUST ignore and drop RTHDR_TYPE2 extensions.

Hmm... ok, but the purpose of this section was to list only requirements
for CNs. A CN can also be an MN at the same time. How about

    Unless the correspondent node is also acting as a mobile node,
    it MUST ignore Type 2 Routing headers and drop all packets
    that it has received with such headers.

We should also change:

    The following requirements apply to all nodes that support route
    optimization:

to

    The following requirements apply to all correspondent nodes that support route
    optimization:

I'll put this under issue #101.

>   packets belonging to Return Routability Procedure (section

Yes.

> -MUST be able to process RTHDR_TYPE2 extension header as defined

Yes. "RTHDR_TYPE2 extension header" => "Type 2 Routing header"

> HAO without binding asociation MUST be dropped.

Yes. Back to issue #100.

> -  The Refresh field MUST be set to zero.

Right.

> Perhaps there are more cases throughout the document.

Yes (see also issue 91).

> Should not we have a section here on "Processing Binding Updates" ?

Isn't 10.2 & 10.3 just that? Or would you like a different name?

Jari