Subject: [mobile-ip] draft 18 comments

From: Brian Haley <[email-masked]>
Date: Mon, 15 Jul 2002 18:09:40 -0400

Hi,

I have a few comments on the sections of draft 18 I've read so far,
as well as some typos.

-Brian

4.5. Conceptual Data Structures

  "... The contents of all of a node's Binding Cache entries are
           cleared when it reboots. ..."

This isn't necessarily the case if we use nonvolatile storage as
Section 10.2 suggests.

6.1.1. Format

   The Mobility Header is identified by a Next Header value of TBD in
   the immediately preceding header, and has the following format:

Can we assign an interim "Next Header" value so we'll be able to test
interoperability at ETSI, even if we don't put it in the draft right now?
IANA has 55 for "IP Mobility", but I didn't think Mipv4 used a protocol number?

6.1.8. Binding Acknowledgement (BA) Message

   The Binding Acknowledgement is sent to the source address of the
   Binding Update message, regardless of whether the Binding Update
   succeeded or failed.  No Routing Headers are added to the message.

Section 9.4.4 describes when and how to send a BAck to a MN, this
paragraph should probably be removed.

6.1.9. Binding Error (BE) Message

What should the Home Address field be set to if the error status is 2,
the unspecified address?  Maybe section 9.4.6 should clarify this, instead
of putting it in both 9.2.1 and 9.2.2.

Section 9.2.1 applies to all Mipv6 nodes, not just CNs, so it should
probably be moved elsewhere.  It also doesn't say what to do if the
checksum is invalid, I'm assuming you drop the packet.  There was
also a typo (Next Header -> Payload Proto) and some duplicated
text (Subsequent checks...).  Here's a possible rewrite:

9.2.1. Processing Mobility Header (MH) Messages

   All IPv6 nodes MUST observe the following rules when processing
   Mobility Header messages:

    1. The "MH type" field MUST be a known type (Section 6.1), else the
       node SHOULD issue a Binding Error message to the packet's Source
       Address with Status field set to 2, subject to rate limiting in
       the same manner as is done for ICMPv6 messages [14].

    2. The "Payload Proto" field MUST be NO_NXTHDR (59 decimal).

    3. The checksum MUST be verified as per Section 6.1.1.

   Any Mobility Header packet which fails to satisfy all of these rules
   MUST be silently discarded.

   Subsequent checks depend on the particular Mobility Header message,
   as specified in Sections 9.3 and 9.4.

(I also shortened this last paragraph since it seemed redundant)

And maybe the rate limiting piece I added should be in the Binding
Error section since there is more than one place that talks about
sending BEs.

And what do we do if the length isn't even enough to cover the type
or checksum fields?

    4. The "Header Len" field MUST meet the minimum length requirements
       of a Mobility Header (which unfortunately doesn't end on an 8-octet
       boundary), which is one (1)?  I.E. if "Header Len" is zero what
       do we do, ICMP message?

9.3.1. Receiving Home Test Init Messages

    -  The Header Extension Length field MUST be greater than or equal
       to the length specified in Section 6.1.3.

should be:

    -  The MH "Header Len" field MUST be greater than or equal to the
       length specified in Section 6.1.3.

Section 9.3.2 needs a similar change.

9.4.1. Receiving Binding Updates

    -  The Header Len field in the Binding Update option is greater than
       or equal to the length specified in Section 6.1.7.

There is no "Header Len" field in the BU any more, it's in the MH:

    - The MH "Header Len" field MUST be greater than or equal to the
      length specified in Section 6.1.7.

Typos:

  6.1.2, "Binding Requests sent" -> "Binding Refresh Requests sent"

  7.1, H-bit section - "Mobile IP home agent" -> "Mobile IPv6 home agent"

  9.2.2, 3rd para, 1st sentence - "nodes" -> "node"

  11.2.1 - "Mobile IP" -> "Mobile IPv6", 4 times

  11.2.2 - "Mobile IP" -> "Mobile IPv6", 2 times

---

From: Brian Haley <[email-masked]>
Date: Wed, 17 Jul 2002 10:07:59 -0400

>        boundary), which is one (1)?  I.E. if "Header Len" is zero what

I was a little in error here, each section (9.3.1, 9.3.2, etc.) has a length check

rule, but the HoTI/CoTI sections (9.3.1/9.3.2) don't say what to do with the
packet if the length is incorrect.  Text like this should be place in those
sections:

  Any HoTI/CoTI which fails to satisfy all of these tests  MUST be
  silently ignored, and the packet carrying the HoTI/CoTI MUST be discarded.

-Brian

---

From: Brian Haley <[email-masked]>
Date: Wed, 17 Jul 2002 11:28:09 -0400

>        2. The "Payload Proto" field MUST be NO_NXTHDR (59 decimal).

And to follow myself up once again, this protocol constant is usually
referred to as IPPROTO_NONE.  This should be changed in Section 6.1.1
as well.

-Brian

---

From: Jari Arkko <[email-masked]>
Date: Fri, 26 Jul 2002 14:23:45 +0300

> This isn't necessarily the case if we use nonvolatile storage as

Yes. I propose to remove the text in 4.5.

> IANA has 55 for "IP Mobility", but I didn't think Mipv4 used a protocol number?

I'm fine with this, but I don't know the history behind 55. Anyone?

If we can confirm this value can be used, we can take it immediately

to the draft as well.

> paragraph should probably be removed.

Right. This has already been noted in issue #65.

> of putting it in both 9.2.1 and 9.2.2.

Yes. I propose to add the following paragraph to 9.4.6:

     The Home Address field in the Binding Error message MUST be copied
     from the Home Address field in the Home Address destination option of
     the offending packet, or set to the unspecified address if no
     such option appeared in the packet.

Also, there seems to be overlap between sections 9.4.6 and 9.2.2. on
detecting the HAO error and on using rate limitation.

> text (Subsequent checks...).  Here's a possible rewrite:

Agree about the problems. We should probably have a
section in the draft that deals with general rules
that apply to all nodes. This could go in there.

> (I also shortened this last paragraph since it seemed redundant)

Looks good. We may treat BE rate limitation in 9.4.6.

> Error section since there is more than one place that talks about

Ah, you noticed this too...

> And what do we do if the length isn't even enough to cover the type

We need an additional check:

     0. The "Header Len" field MUST be non-zero.

> Section 9.3.2 needs a similar change.

Right.

>       length specified in Section 6.1.7.

Yes.

Thanks again for your feedback.

Jari