Subject: [mobile-ip] further edits in 241...

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Feb 2003 02:04:49 +0200

Here's a few additional responses. One potentially
significant issue at the end of the e-mail, about which
addresses are intercepted by home agents.

 > 9.1 Conceptual Data Structures
 >
 >    IPv6 nodes with route optimization support maintain a Binding Cache
 >    of bindings for other nodes.  A separate Binding Cache SHOULD be
 >    maintained by each IPv6 node for each of its IPv6 addresses.
 >
 > ==> s/addresses/unicast routable addresses/ ...?

Right.

 >    o  A flag indicating whether or not this Binding Cache entry is a
 >       home registration entry.
 >
 > ==> is this applicable for MN's, CN's or HA's only?

Added "(applicable only on nodes which support home agent
functionality)".

 >    o  The Payload Proto field MUST be IPPROTO_NONE (59 decimal).
 >       Otherwise, the node MUST discard the message and SHOULD send ICMP
 >       Parameter Problem [14], Code 0, to the Source Address of the
 >       packet.
 >
 >    o  The checksum must be verified as per Section 6.1.  Otherwise, the
 >       node MUST silently discard the message.
 >
 > ==> is it important in which order these rules are processed?  One could
 > argue checksum verification should go first.

Moved.

 > 9.4.3 Sending Home Test Messages
 >
 >    The correspondent node creates a home keygen token and uses the
 >    current nonce index as the Home Nonce Index.  It then creates a Home
 >    Test message (Section 6.1.5) and sends it to the mobile node at the
 >    latter's home address.  Note that the Home Test message is always
 >    sent to the home address of the mobile node, even when there is an
 >    existing binding for the mobile node.
 >
 > ==> the last sentence seems to make no sense.  If there would be an existing
 > binding, it would still be sent to the home address!  Is the intention to
 > say _which_ home address Home Test will be sent to, in case a binding has
 > one and the Home Init Test has another as source address?  Or should the
 > discussion have been under care-of test message?

You are right. Added "... without route optimization".

 >    o  L=1: Defend both the given non link-local unicast (home) address
 >       and the derived link-local.
 >
 > ==> note, I don't believe it's stated anywhere what this "derivation" is;
 > its apparent intention is clear though.

Yes. Add "The link-local address is derived by replacing, the subnet
prefix in the mobile node's home address with the link-local prefix."

 >    packets on the home link addressed to the mobile node's home address.
 >
 > ==> this is different what it says in the first paragraph of this section.
 > Addressed to the MN != w/ MN's home address.  The former implies also
 > capturing link-local packets, the latter not.  Are link-local unicast
 > messages (like NUD) captured?  Make it clearer!

Section 10.4.1 seems outdated with respect to the L bit and
with respect to the requirements in 10.4.2. In particular,
10.4.2 requires ICMP to be sent for packets addressed to the
mobile node's link-local address. This appears to be hard
unless the home agent is also intercepting packets on this
address. I have added the following text to the beginning
of Section 10.4.1 and replaced "home address" with "address"
throughout the rest of the section.

    ... home agent sends a NA ... If the Link-Layer Address
    Compatibility~(L) flag has been specified in the Binding Update,
    the home agent MUST do the same for the link-local address of the
    mobile node.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 20 Feb 2003 09:39:57 +0200 (EET)

Only two cases left.

> You are right. Added "... without route optimization".

This wasn't yet in the latest draft on the web, but I guess it's ok (the 
proposal sounds a bit out-of-place or perhaps I'm not putting it in the 
right place).
 
>     the home agent MUST do the same for the link-local address of the

Ok -- this is one issue that seemed confusing to me when reading the
draft.  It was not clear to me which packets would be captured, whether
"Home Address" of the MN would also include it's LL address, etc. (the
beginning of 4.1 doesn't suggest so, at least.)  This might have to be
stated more explicitly in the introductory chapters (like 4.1).  If LL
messages are not proxied/captured, this might lead to problems (if not
now, in the future).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Feb 2003 11:27:13 +0200

Pekka Savola wrote:

>>You are right. Added "... without route optimization"
> 

Look at the web now at
http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html#txing-hot

 > this is one issue that seemed confusing to me when reading the

The packets are now intercepted, but of course the next section says
that they will not be forwarded to the mobile node but rather an ICMP
is generated. Home address does not include the LL address, so 4.1 is
correct. But if you specify L=1 in your Binding Update, then the
home agent will defend your LL, intercept your LL traffic, and generate
ICMPs out of it. I don't think we want to pass link-local traffic to
the mobile node.

Jari