Subject: [mobile-ip] Last Call: Mobility Support in IPv6 to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 23 Jan 2003 10:48:43 -0500

The IESG has received a request from the IP Routing for Wireless/Mobile 
Hosts Working Group to consider Mobility Support in IPv6 
<draft-ietf-mobileip-ipv6-20.txt> as a Proposed Standard.  

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
[email-masked] or [email-masked] mailing lists by 2003-2-6.

Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-20.txt

---

From: Pekka Savola <[email-masked]>
Date: Fri, 24 Jan 2003 16:07:57 +0200 (EET)

Hello,

Hmm.. I sent a huge message full of comments (total size 46K) on the list:

Date: Fri, 24 Jan 2003 10:50:00 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mobile-ip] Last Call: Mobility Support in IPv6 to Proposed
    Standard

It has not yet arrived.

Has this been thrashed, waiting approval due to the size, or whatever?

I don't think lists should have this kind of posting limit, if so... or at 
least, knock it up to 75K or whatever.

-- 
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: Pekka Savola <[email-masked]>
Date: Fri, 24 Jan 2003 10:50:00 +0200 (EET)

Hello,

> [email-masked] or [email-masked] mailing lists by 2003-2-6.

I had hoped to complete the reading and commentary before the last call 
and the publication of -20, but didn't manage to do so, unfortunately.  
The spec is so long :-/.

Anyway, below are the comments I wrote down during the read.  I tried to 
put them down to separate categories, but the line between them is quite 
flaky.  Don't chew too long on them, there are probably lots of bugs in 
the comments -- if in doubt, ask or ignore :-)

I don't think this is ready yet to be published, probably like 2-3 rounds 
is still required (not that those rounds couldn't be done pretty quick if 
so).

...

The big picture
===============

 1) When reading the spec, Dynamic Home Agend Address Discovery mechanism
and Mobile Prefix Advertisements struck as something that have come in as
a feature creep at some point.  The main point of these mechanisms seems
to be to cope with changing the IP addresses or changes in topology of the
home agents/home link.  This doesn't seem to be a required base feature of
the protocol to me -- useful in some ways due to mobility, of course, but
not required.  Off-band reconfiguration would be entirely ok for now too.

If these bring complexity, they could be removed to their own specs and/or
simplified here.  Reconfiguration of the home link is not an easy issue!

(one particular issue that struct me as "Oh no!" in mobile prefix
advertisements was the aggregation/data collection of advertisements by the
home agent.  Was it ever considered that MN could be required to have HA to
more than one HA on the same link (if more than one are present?)

 2) I find the special NS (sect 7.5) hack disturbing.  I'm not entirely sure
why this is needed, and why it couldn't be worked around.  I recall that
this is needed in some special cases such as returning home while home agent
is being booted and there are multiple home agents or something.  Call that
rare?  Of course, nicer ways to deal with this would maybe be possible, like
specifying which data must (or must not be) preserved across reboots, or
generating an RFC3041 address for the returning MN which would be used for
sending a BU signalling "hello, I'm back!".

Major issues
============

1)

   When the mobile node has received both the Home and Care-of Test
   messages, the return routability procedure is complete.  As a result
   of the procedure, the mobile node has the data it needs to send a
   Binding Update to the correspondent node.  The mobile node hashes the
   tokens together to form a 20 octet binding key Kbm:

       Kbm = SHA1 (home keygen token | care-of keygen token)

==> a hash of 128 bits generates a 160-bit key?  Is this enough entropy for
this algorithm??  Perhaps this is ok (I don't know how well those hashing
algorithms work with this little input), but if so, the reasoning 
should be mentioned explicitly somewhere (e.g. security considerations?)

   In this case, the care-of keygen token is not used.
   Instead, the binding management key is generated as follows:

       Kbm = SHA1(home keygen token)

==> 64 bits -> 160 bits, see above

2)

   The Alternate Care-of Address option is valid only in Binding Update.
   The Alternate Care-of Address field contains an address to use as the
   care-of address for the binding, rather than using the Source Address
   of the packet as the care-of address.

==> One should consider having a better roadmap of different care-of address
usage scenarios.  To me, this ACoA option seemed a bit puzzling at least.

3)

   The Source Address of the Home Agent Address Discovery Request
   message packet is typically one of the mobile node's current care-of
   addresses.  At the time of performing this dynamic home agent address
   discovery procedure, it is likely that the mobile node is not
   registered with any home agent.  Therefore, neither the nature of the
   address nor the identity of the mobile node can be established at
   this time.  The home agent MUST then return the Home Agent Address
   Discovery Reply message directly to the Source Address chosen by the
   mobile node.

==> issues about possible subnets where prefixlen is longer than 64, as
noted by draft-savola-ipv6-127-prefixlen-04.  Should there be an explicit
restriction (somewhere) to use DHAAD only if the prefix length is 64?

4)

8.2 IPv6 Nodes with Support for Route Optimization

   Nodes that implement route optimization are a subset of all IPv6
   nodes on the Internet.  The ability of a correspondent node to
   participate in route optimization is essential for the efficient
   operation of the IPv6 Internet, for the following reasons:

==> should there also be a section why route optimization is non-essential
or bad, for balance?

and:

   o  Reduced network load across the entire Internet, as mobile devices
      begin to predominate.  At the time this is being written, laptop
      computers already outsell desktops and wireless telephones far
      outsell laptops.

==> I'm not sure if the last sentece is relevant to a technical
specification.

5) something about upper-case keywords..

   o  The node MUST allow route optimization to be administratively
      enabled or disabled.  The default SHOULD be enabled.

==> is MUST a bit strong (e.g. consider appliances that may not have any
config knobs).  Perhaps a reword: "If node defaults to enabling route
optimization, there MUST be a way to administratively disable it", though
I'm not sure if that's optimal either.

   o  Every IPv6 router SHOULD be able to send an Advertisement Interval
      option (Section 7.3) in each of its Router Advertisements [12], to
      aid movement detection by mobile nodes (as in Section 11.5.1).
      The use of this option in Router Advertisements MUST be
      configurable.

==> as above, I personally like a MUST but it seems a bit strong, for _all_
routers..?

   o  Every IPv6 router SHOULD be able to support sending unsolicited
      multicast Router Advertisements at the faster rate described in
      Section 7.6.  The use of this faster rate MUST be configurable.

==> see above

   o  Filtering routers SHOULD support different rules for type 0 and
      type 2 routing headers (see Section 6.4) so that filtering of
      source routed packets (type 0) will not necessarily limit Mobile
      IPv6 traffic which is delivered via type 2 routing headers.

==> I'd reword this as "Routers supporting filtering packets with routing
headers SHOULD support different ...".

   o  The node MUST support receiving a Binding Error message (Section
      11.3.6).

   o  The node SHOULD support receiving ICMP errors (Section 11.3.5).

==> I find it strange that this is a SHOULD for mobile nodes, but a feature
that will be used by most IPv6 nodes -- it's a MUST, no debate about it!

   Binding Error messages are subject to rate limiting in the same
   manner as is done for ICMPv6 messages [14].

==> should there be a SHOULD/MUST keyword here?

   Packets addressed to
   the mobile node's site-local address SHOULD NOT be tunneled to the
   mobile node by default, but this behavior MUST be configurable to
   enable it; currently, the exact definition and semantics of a "site"
   and a site-local address are incompletely defined in IPv6, and this
   default behavior might change at some point in the future.

==> MUST for a config knob like this seems too harsh a requirement to me,
a required knob to enable site-locals?  Come on..

   multicast recipients).  Multicast packets addressed to a multicast
   address with scope larger than link-local but smaller than global
   (e.g., site-local and organization-local [3]), to which the mobile
   node is subscribed, SHOULD NOT be tunneled to the mobile node by
   default.  This behavior MUST be configurable to allow it to be
   enabled.  

==> again, a rather harsh requirement.

      such queries will generally have a lower overhead than using the
      mobile node's home address, since no extra options need be used in
      either the query or its reply.  Such packets can be routed
      normally, directly between their source and destination without
      relying on Mobile IPv6.  If application running on the mobile node
      has no particular knowledge that the communication being sent fits
      within this general type of communication, however, the mobile
      node SHOULD NOT use its care-of address as the source of the
      packet in this way.

==> I don't think it is appropriate to use upper-case normatives for
specification when MIPv6 usability is concerned (esp. SHOULD NOT); 
thus remove the caps?

   For packets received by the first of these methods, the mobile node
   MUST check that the IPv6 source address of the tunneled packet is the
   IP address of its home agent.  In this method the mobile node SHOULD
   also send a Binding Update to the original sender of the packet, as
   described in Section 11.7.2, subject to the rate limiting defined in
   Section 11.8.  

==> as previously stated, I find it unacceptable to specify this "SHOULD do
RO" in upper-caps.  Reverse tunneling can be totally OK.  People will start
doing RO if it makes sense for them, period -- no spec forcing is necessary.

   On some types of network interfaces, the mobile node MAY also
   supplement this monitoring of Router Advertisements, by setting its
   network interface into "promiscuous" receive mode, so that it is able
   to receive all packets on the link, including those not addressed to
   it at the link layer (i.e., disabling link-level address filtering).
   The mobile node will then be able to detect any packets sent by the
   router, in order to detect reachability from the router.  This use of
   promiscuous mode may be useful on very low bandwidth (e.g., wireless)
   links, but its use MUST be configurable on the mobile node since it

==> the MUST requirement needs re-phrasing.  "If it is enabled by defaults,
its use MUST be configurable..." ?

6)

   to the Source Address.  Unlike the treatment of regular packets, this
   addressing procedure does not use information from the Binding Cache.
   However, a routing header is needed in some cases.  If the Source
   Address is the home address of the mobile node, i.e., the Binding
   Update did not contain a Home Address destination option, then the
   Binding Acknowledgement MUST be sent to that address, and the routing
   header MUST NOT be used.  Otherwise, the Binding Acknowledgement MUST
   be sent using a type 2 routing header which contains the mobile
   node's home address.

==> the latter case seems strange.  Consider e.g. a BU with HAO option for
which CN replies with BA expired nonces (or something like that), 
what use is it to use routing header to send that back to the MN?  
Rather, it could be much more robust to
just by default push everything to the home address, and have them reverse
tunneled to the MN.

7)

   Regardless of the setting of the Acknowledge (A) bit in the Binding
   Update, the home agent MUST return a Binding Acknowledgement to the
   mobile node, constructed as follows:

==> there seem to be some confusion throughout the draft on when exactly
BA's are sent.  This surely does not reflect to the general overview in the
first chapters ("if requested").  Some roadmap should be nice?

   o  The state of any retransmissions needed for this Binding Update,
      if the Acknowledge (A) bit was set in this Binding Update.  This
      state includes the time remaining until the next retransmission
      attempt for the Binding Update, and the current state of the
      exponential back-off mechanism for retransmissions.

==> not necessarily a question to be answered here, but is this
retransmission mechanism also valid for other kind of BU's which MUST be
acknowledged (like home registrations, IIRC) -- ie, ones where BA should be
received?

8)
   As described in Section 11.4.1, a mobile node attempts dynamic home
   agent address discovery by sending an ICMP Home Agent Address
   Discovery Request message to the Mobile IPv6 Home-Agents anycast
   address [16] for its home IP subnet prefix.  A home agent receiving
   such a Home Agent Address Discovery Request message that is serving
   this subnet SHOULD return an ICMP Home Agent Address Discovery Reply
   message to the mobile node, with the Source Address of the Reply
   packet set to one of the global unicast addresses of the home agent.

==> this, or section 11.4.1 does not discuss the security implications (or
lack thereof) by enabling unchecked DHAAD from everywhere for all subnets
you can guess. This is briefly noted in the security considerations though.
Could be a useful feature for mapping Home agents/network infrastructure 
in the Internet, one packet per subnet only.

9)
[...]
   o  Among home agents with equal preference, their IP addresses in the
      Home Agent Addresses field SHOULD be listed in an order randomized
      with respect to other home agents with equal preference, each time
      a Home Agent Address Discovery Reply message is returned by this
      home agent.

   o  If more than one global IP address is associated with a home
      agent, these addresses SHOULD be listed in a randomized order.

==> these 3 bullets seem rather redundant optimizations to me.  A MN cannot
depend on them being done (SHOULD's), so it must implement same preference
ordering functions itself anyway!  This seems only useful when the number of
used items exceed MTU, and in that case, even simpler clipping could be
used.

10)

11.5 Movement

11.5.1 Movement Detection

==> one thing that may have to be considered is, when MN moves on to a new
link, or detects it's also on range of a different link, should it re-perform
DAD for _already existing_ addresses?  If so, on which addresses (probably
link link-locals/site-locals would be enough).
This is a new situation brought by movement.

11)

   If the mobile node wants to ensure that its new care-of address has
   been entered into a correspondent node's Binding Cache, the mobile
   node MAY request an acknowledgement by setting the Acknowledge (A)
   bit in the Binding Update.  In this case, however, the mobile node
   SHOULD NOT continue to retransmit the Binding Update once the
   retransmission timeout period has reached MAX_BINDACK_TIMEOUT.

   The mobile node SHOULD create a Binding Update as follows:

==> Shouldn't this be a MUST (or remove upper case normative completely)?  
Or can you create it differently?  Note that this list does not restrict 
any additional options.  If not,
you could separate the cases "this is how BU MUST be created" and "this is
why BU should be sent at all if to be created".

12)

   The vulnerabilities for off-path attackers are the same as in regular
   IPv6.  Those nodes that are not on the path between the home agent
   and the correspondent node will not be able to receive the probe
   messages.

==> the last sentence is not entirely accurate.  Was it really meant to say that
probe messages cannot be received unless you're on path HA<->CN, 
_not_ MN<->HA _or_ MN<->CN (care-of test init could be considered as a probe
IMO).

Substantial/semi-editorial issues
=================================

   o  In Mobile IPv6, the mobile node does not have to tunnel multicast
      packets to its home agent.

==> this is not really true anymore.

   o  The dynamic home agent address discovery mechanism in Mobile IPv6
      returns a single reply to the mobile node.  The directed broadcast
      approach used in IPv4 returns separate replies from each home
      agent.

==> btw, does directed broadcast approach in v4 even work if "no ip
directed-broadcast" or the like has been configured?

   While a mobile node is attached to some foreign link away from home,
   it is also addressable at one or more care-of addresses.  A care-of
   address is an IP address associated with a mobile node that has the
   subnet prefix of a particular foreign link.  The mobile node can
   acquire its care-of address through conventional IPv6 stateless or
   stateful auto-configuration mechanisms.  

==> manual configuration is probably also okay..?

   A Binding Update may also be used to delete a previously established
   binding by setting the care-of address equal to the home address
   (Section 6.1.7).  

==> according to section 6.1.7, deletion can also happen if lifetime is set
to zero, and then Kbm is calculated as follows.

      *  Source Address = care-of address

      *  Destination Address = correspondent

      *  Parameters:

         +  home address (within the Home Address destination option or
            in the Source Address)

==> above it says "Source Address = care-of address" so "or in the Source
Address" looks redundant?

   response.  However, the correspondent node MUST NOT accept nonces
   beyond MAX_NONCE_LIFE seconds (see Section 12) after the first use.
   As the difference between these two constants is 30 seconds, a
   convenient way to enforce the above lifetimes is to generate a new
   nonce every 30 seconds.  

==> is it appropriate to discuss the difference between two constants
defined in section 12 _here_?  (ie. if they're changed in sect 12, the
difference may not be 30 seconds anymore.) 
It seems good for clarity at least..

      following the Mobility Header.  Uses the same values as the IPv6
      Next Header field [11].

      This field is intended to be used by a future specification of
      piggybacking binding messages on payload packets (see Appendix
      B.1).  Implementations conforming to this specification SHOULD set
      the payload protocol type to IPPROTO_NONE (59 decimal).

==> Shouldn't this be better named "Next Header"?  (Possibly remove the
discussion about piggy-backing too)

      The pseudo-header contains IPv6 header fields, as specified in
      Section 8.1 of RFC 2460 [11].  The Next Header value used in the
      pseudo-header is TBD <To be assigned by IANA>.  The addresses used
      in the pseudo-header are the addresses that appear in the Source
      and Destination Address fields in the IPv6 packet carrying the
      Mobility Header.  Note that the procedures described in Section
      11.3.1 apply even for the Mobility Header. 

==> s/procedures/procedures of sending packets while away from home/ for
readability?  or if the subsequent sentences describe it adequately, then
replace e.g. s/Mobility Header. If/Mobility Header: if/ or the like.

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  Contains zero or
      more TLV-encoded mobility options.  The encoding and format of
      defined options are described in Section 6.2.  The receiver MUST
      ignore and skip any options which it does not understand.

==> I'm all for simplicity for now, but does this provide enough flexibility
for the future?  That is, should one define the option types like with
destination options that some values would be skipped and ignored, some not?
In the former case, introduction of widely used mobility options would
probably require some kind of acknowledgement messages if you cannot be sure
the options were understood...

                        , the protocol used for establishing the IPsec
      security associations between the mobile node and the home agent
      does not survive movements.  It may then have to be rerun.  (Note
      that the IPsec security associations themselves are expected to
      survive movements.) If manual IPsec configuration is used, the bit
      MUST be set to 1.

      This bit is valid only in Binding Updates sent to the home agent.
      Correspondent nodes MUST ignore this bit.

==> and MN's MUST NOT send it CN's (must seems like a slight overkill
though), right?  (not sure if it's worth noting it here, though.)

      *  Binding Authorization Data option

      *  Nonce Indices option.

      *  Alternate Care-of Address option

   If no options are present in this message, 4 bytes of padding is
   necessary and the Header Len field will be set to 1.

==> uhh, in above it said that it must always contain one or more options,
and the sentence above is useless?

   Lifetime

      The granted lifetime, in time units of 4 seconds, for which this
      node SHOULD retain the entry for this mobile node in its Binding
      Cache.  A value of all one bits (0xffff) indicates infinity.

      The value of this field is undefined if the Status field indicates
      that the Binding Update was rejected.

==> whole lifetime field in ack seems redundant to me, especially now that
in most cases BU's aren't even acknowledged.  If BU's would be typically
acknowledged, this could be useful to indicate when to resend the BU for
long connections (if CN's typically have shorter lifetimes for bindings
than as limit requested in BU).

Or, can CN still send a BA even if not requested by A-bit in BU?  If so, the
text in 5.2.6 should perhaps be updated a bit; it gave me the impression
that BA would be sent basically only if requested by A-bit..

So, with current BU lifetime semantics, this seems a bit redundant.. but I
guess it's no big deal as BA's aren't sent that often..

      *  Binding Authorization Data option

      *  Binding Refresh Advice option

   If no options are present in this message, 4 bytes of padding is
   necessary and the Header Len field will be set to 1.

==> yet again, above it says one or more options are present..

   Status

      8-bit unsigned integer indicating the reason for this message.
      The following values are currently defined:

           1 Unknown binding for Home Address destination option

           2 Unrecognized MH Type value

==> tlv notation would be better if 2) is common because then redundant Home
Address is tranmitted?  On the other hand, otherwise you'd probably require
extra padding for 1).

   The first 96 bits from the MAC result are used as the Authenticator
   field.  Note that, if the message is sent to a destination which is
   itself mobile, the "final dest" address may not be the address found
   in the Destination Address field of the IPv6 header; instead the
   address of the true destination (e.g., its home address) should be
   used.

==> refer to section XXX on destination address selection?

6.2.5 Alternate Care-of Address

   The Alternate Care-of Address option has an alignment requirement of
   8n+6.  Its format is as follows:

==> is this alignment requirement expression format commonplace?  It wasn't
100% intuitive to me at least.

   IPv6 requires that options appearing in a Hop-by-Hop Options header
   or Destination Options header be aligned in a packet so that
   multi-octet values within the Option Data field of each option fall
   on natural boundaries (i.e., fields of width n octets are placed at
   an integer multiple of n octets from the start of the header, for n =
   1, 2, 4, or 8) [11].  The alignment requirement [11] for the Home
   Address option is 8n+6.

==> this notation has already been used a few times in previous option
types, move it there? (see above.)

   Home agents MUST include the Source Link-Layer Address option in all
   Router Advertisements they send.

==> an addional sentence/reference justifying this would be nice.

   Any IPv6 node may at any time be a correspondent node of a mobile
   node, either sending a packet to a mobile node or receiving a packet
   from a mobile node.  There are no Mobile IPv6 specific MUST
   requirements for such nodes, and basic IPv6 techniques are
   sufficient.  If a mobile node attempts to set up route optimization
   with a node with only basic IPv6 support, an ICMP error will signal
   that the node does not support such optimizations, and communications
   will flow through the home agent.

==> has this kind of signalling been tested?  does it work?  
Add a reference to 10.3.5?

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/ ...?

   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?

   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.

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?

   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.

   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!

10.3.2 Primary Care-of Address De-Registration

==> would it be useful to say here that this is only(?) used when the MN
returns home.  It would make some of the later comments easier to
understand.

   o  The Key Management Mobility Capability (K) bit is set or reset,
      and actions based on its value are performed as described in the
      previous section.  The mobile node's home address is used as its
      new care-of address.

==> the last sentence seems quite confusing.  care-of address for the
purposes of what? (but see above)

   However, packets addressed to the mobile node's link-local address
   MUST NOT be tunneled to the mobile node.  Instead, such a packet MUST
   be discarded, and the home agent SHOULD return an ICMP Destination
   Unreachable, Code 3, message to the packet's Source Address (unless
   this Source Address is a multicast address).  

==> some of this text should be moved up to 10.4.1 at least, if not also
earlier.

   All MLD packets are sent directly between the mobile node and the
   home agent.  Since these packets all contain a link-local source
   address, 

==> this is not true when bootstrapping: the source can also be the
unspecied address, as described in draft-ietf-magma-mld-source; but this
doesn't really matter (just being pedantic :-).

   o  The tunnel entry point is the primary care-of address as
      registered with the home agent and the tunnel exit point is the
      home agent.

   o  When a home agent decapsulates a tunneled packet from the mobile
      node, the home agent MUST verify that the Source Address in the
      tunnel IP header is the mobile node's primary care-of address.
      Otherwise any node in the Internet could send traffic through the
      home agent and escape ingress filtering limitations.

==> there seems to be some overlap with the last two bullets?

      Prefix Information option has the autonomous address configuration
      (A) flag set and the prefix length is valid for address
      autoconfiguration on the home subnet, add these advertisements and
      preserve the on-link (L) flag value.  Clear the Router Address (R)
      flag and zero the interface-id portion of the prefix field to
      prevent mobile nodes from treating another router's interface
      address as belonging to the home agent.  Treat the lifetimes of
      these prefixes as decrementing in real time, as defined in Section
      6.2.7 of RFC 2461 [12].

==> what's meant by "prevent mobile nodes ..." sentence?  I believe the
prefix information in RA's already have the interface ID part set to 
zero..?

   Each Binding Update List entry conceptually contains the following
   fields:

   o  The IP address of the node to which a Binding Update was sent.  If
      the Binding Update was successfully received by that node (e.g.,
      not lost by the network), a Binding Cache entry may have been
      created or updated based on this Binding Update.  The Binding
      Cache entry may still exist, if that node has not deleted the
      entry before its expiration for some reason.

==> how is other than the first sentence relevant for the Binding Update List? 
Should be tailed down a bit, it seems to me.

   For packets sent by a mobile node while it is at home, no special
   Mobile IPv6 processing is required.  Likewise, if the mobile node
   uses any address other than any of its home addresses as the source
   of a packet sent while away from home no special Mobile IPv6
   processing is required.  In either case, the packet is simply
   addressed and transmitted in the same way as any normal IPv6 packet.

==> this paragraph is unnecessary, considering the paragraph title ("away
from home") but I guess ok for clarity.

   Direct Delivery

==> IMO the title is misleading ("Route Optimization"?) 
and this subsection does not mention binding updates at all..!

      This manner of delivering packets does not require going through
      the home network, and typically will enable faster and more
      reliable transmission.  

==> I would not say "faster" here, not at all.  In the long term, yes, but
otherwise no.

      This is the mechanism which tunnels the packets via the home
      agent.  It isn't as efficient as the above mechanism, but is
      needed if there is no binding yet with the correspondent node.
      Specifically:

      *  The packet is sent to the home agent using IPv6 encapsulation
         [15].

==> this does not give any references to the packet inside the
encapsulation.

      processing is performed on the packet, initializing the
      Authentication Data in the IPsec header.  The AH authentication
      data MUST be calculated as if the following were true:

      *  the IPv6 source address in the IPv6 header contains the mobile
         node's home address,

      *  the Home Address field of the Home Address destination option
         (Section 6.3) contains the new care-of address.

==> to be clear, does this require special case processing in IPsec code for
Mobile IPv6?  Is this feature already in IPsec specs?  Should be clearer.

   o  This allows, but does not require, the receiver of the packet
      containing a Home Address destination option to exchange the two
      fields of the incoming packet, simplifying processing for all
      subsequent packet headers.  However, such an exchange is not
      required, as long as the result of the authentication calculation
      remains the same.

==> I don't quite get what this says.  I don't see how authentication
calculation could be the same in cases that 1) src=A, hao=B, and 2) src=B,
hao=A.  That would be a big bug?

[...]
   o  The Home Address field in the routing header is one of the node's
      home addresses, if the segments left field was 1.  Thus, in
      particular the address field is required to be a unicast routable
      address.

   Once the above checks have been performed, the node swaps the IPv6
   destination field with the Home Address field in the routing header,
   decrements segments left, and resubmits the packet to IP for
   processing the next header.  

==> I'd recommend removing the special casing for "segments left = 0 when
receiving -implementations" from the two bullets above, 
as it finally all breaks down here -- segments left=255 due to wrapping?

   node must join that multicast group.  One method by which a mobile
   node MAY join the group is via a (local) multicast router on the
   foreign link being visited.  In this case, the mobile node MUST NOT
   use its home address or the Home Address destination option when
   sending MLD packets [17]

==> s/[17]/[17]./
==> also, in that case, I don't think MN should use HAO when sending
_actual_ multicast packets either _anymore_ using a _local_ multicast router.. 
 Just better to phase it is "MUST use its care-of address [...]".

   If, after a mobile node transmits a Home Agent Address Discovery
   Request message to the Home Agents Anycast address, it does not
   receive a corresponding Home Agent Address Discovery Reply message
   within INITIAL_DHAAD_TIMEOUT (see Section 12) seconds, the mobile
   node MAY retransmit the same Request message to the same anycast
   address.  This retransmission MAY be repeated up to a maximum of
   DHAAD_RETRIES (see Section 12) attempts.  Each retransmission MUST be
   delayed by twice the time interval of the previous retransmission.

==> hey come on, if anybody didn't reply at first, do you really think they
would for the 5th time?  If this is really needed, make that e.g. 2-3
retransmissions and delay of 30 sec (to cope with reboots if that's deemed
necessary), possibly except the first retransmission.

   As described in Section 4, in order to form a new care-of address, a
   mobile node MAY use either stateless [13] or stateful (e.g., DHCPv6
   [29]) Address Autoconfiguration.  If a mobile node needs to send
   packets as part of the method of address autoconfiguration, it MUST
   use an IPv6 link-local address rather than its own IPv6 home address
   as the Source Address in the IPv6 header of each such
   autoconfiguration packet.

==> note that, in the first DAD packet, source can also be the unspecified
address.

11.5.4 Returning Home

   A mobile node detects that it has returned to its home link through
   the movement detection algorithm in use (Section 11.5.1), when the
   mobile node detects that its home subnet prefix is again on-link.

==> is a router advertisement received through a VPN to the home link
considered being home?

   A mobile node that initiates a return routability procedure MUST send
   (in parallel) a Home Test Init message and a Care-of Test Init
   messages.  However, if the mobile node has recently received one or
   both home or care-of keygen tokens, and associated nonce indices for
   the desired addresses, it MAY reuse them.  Therefore, the return
   routability procedure may in some cases be completed with only one
   message pair.  It may even be completed without any messages at all,
   if the mobile node has a recent home keygen token and and has

==> please define "recent", I believe there are even constants for that
somewhere!

      previous home agent is still defending the existing binding.
      Therefore, mobile nodes that use home agent address discovery
      SHOULD ensure information about their bindings is not lost,
      de-register before losing this information, or use small
      lifetimes.

==> a possible fix here would be be the secondary HA's reporting back this
defending is being in progress by home agent X, so MN would know that it
should contant HA X.  But I'm not sure if it's worth the complexity now..

17. Acknowledgements

   We would like to thank the members of the Mobile IP and IPng Working
   Groups for their comments and suggestions on this work.  We would
   particularly like to thank (in alphabetical order) Fred Baker
   (Cisco), Josh Broch (Carnegie Mellon University), Samita Chakrabarti

==> typically, I don't think organizations are acknowledged in the IETF like
this, but I'm ok with it.

Trivial editorial issues
========================

   security association

      An IPsec security association is a simplex "connection" that
      affords security services to the traffic carried by it.  Security
      services are afforded to a security association by the use of the
      AH and ESP protocols.

==> "afford" sounds strange to me, reword?

   destination option

      Destination options are carried by the IPv6 Destination Options
      extension header.  Destination options include optional
      information that need be examined only by the IPv6 node given as
      the destination address in the IPv6 header, not by other
      intermediate routing nodes.  Mobile IPv6 defines one new
      destination option, the Home Address destination option (see
      Section 6.3).

==> "other intermediate routing nodes" is an ambiguous referral ("other,
intermediate nodes"?).

4.1 Basic Operation

   A mobile node is always expected to be addressable at its home
   address, whether it is currently attached to its home link or is away
   from home.  The "home address" is an IP address assigned to the
   mobile node within its home subnet prefix on its home link.  

==> home subnet prefix and home link definitions are circular; only one
req'd?

   Bindings established with correspondent nodes using keys created by
   way of the return routability procedure MUST NOT exceed
   MAX_RR_BINDING_LIFE seconds (see Section 12).

==> s/LIFE/LIFETIME/, and the same for other variables ending with _LIFE ?

   outer IP address corresponds to the current location of the mobile
   node (Binding Updates sent to the home agents are secure).  The home
   agent identifies the mobile node through the source address of the
   inner packet.(Typically, this is the home address of the mobile node,

==> s/.(/. (/

      There MAY be additional information, associated with this Binding
      Refresh Request message, that need not be present in all Binding

==> s/,//

   Key Management Mobility Capability (K)

      If this bit is reset

==> "reset" is perhaps a bit unoptimal wording, "cleared"/"zero"? (similar
in a few other places of the document)

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  Contains one or
      more TLV-encoded mobility options.  The encoding and format of
      defined options are described in Section 6.2.  The receiver MUST
      ignore and skip any options which it does not understand.

==> s/Contains/It contains/ (same for a few other places)

   Reserved

      32-bit reserved field.  Initialized to zero for transmission, and
      ignored on reception.

==> different wording for MBZ as previous definitions, not that it matters
that much..

Internet-Draft              Mobility Support in IPv6        January 2003

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

==> figures should not be split to two pages, but I guess there's not much
to be done about it (except when at rfc editor)

8.4 IPv6 Home Agents

   In order for a mobile node to operate correctly while away from home,
   at least one IPv6 router on the mobile node's home link must function

==> circular definition again, but may be ok for clarity?

   o  Every home agent SHOULD support sending ICMP Mobile Prefix
      Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix
      Solicitations (Section 6.7).  This behavior MUST be configurable,
      so that home agents can be configured to avoid sending such Prefix
      Advertisements according to the needs of the network
      administration in the home domain.

==> s/This behaviour/If supported, this behaviour/ ?

   of its care-of address.  When calculating authentication data in a
   packet that contains a type 2 routing header, the correspondent node
   MUST calculate the authentication data as if the following were true:
   The routing header contains the care-of address, the destination IPv6
   address field of the IPv6 header contains the home address, and the
   Segments Left field is zero.  The IPsec Security Policy Database look
   MUST based on the mobile node's home address.

==> s/look/lookup/ (or look up)

   o  L=0:  Defend the given address.

==> s/  / /

   o  Cookie values used the Home Test Init and Care-of Test Init
      messages.

==> s/used/used in/ ?

      *  The Source Address in the tunnel packet is the primary care-of
         address as registered with the home agent.

      *  The Destination Address in the tunnel packet is the home
         agent's address.

==> add here, at the end, something like "Then, the home agent will pass the
encapsulated packet to the correspondent node."

11.3.3 Receiving Packets While Away from Home

   While away from home, a mobile node will receive packets addressed to
   its home address, by one of three methods:

   o  Packets sent by a correspondent node that does not have a Binding
      Cache entry for the mobile node, will be tunneled to the mobile
      node via its home agent.

==> reword for clarity, e.g.: "... for the mobile node, will be sent to the
home address, captured by the home agent and tunneled to the mobile node."

   prefix.  As described in Section 10.5, the home agent on its home
   link that receives this Request message will return an ICMP Home
   Agent Address Discovery Reply message, giving the global unicast IP
   addresses for the home agents operating on the home link

==> s/link/link./

   If the mobile node has a current registration with some home agent on
   its home link (the Lifetime for that registration has not yet

==> s/on its home link// (seems redundant by the definition of home agent)

   expired), then the mobile node MUST attempt any new registration
   first with that home agent.  If that registration attempt fails
   (e.g., times out or is rejected), the mobile node SHOULD then
   reattempt this registration with another home agent on its home link.

==> s/on its home link// (as above)

   The mobile node SHOULD also mark its link-local address as tentative,
   and follow standard Duplicate Address Detection procedures[13].

==> s/[13]/ [13]/

   to learn the home agent's link-layer address, since the home agent
   will be currently configured to intercept packets to the mobile
   node's home address for Duplicate Address Detection (DAD).  In

==> s/for/using/

   The mobile node then sends its Binding Update using the home agent's
   link-layer address, instructing its home agent to no longer serve as
   a home agent for it.  By processing this Binding Update, the home

==> s/using/to/ or if that's not the intent, clarify!

   This procedure also protects against Denial-of-Service attacks in
   which the attacker pretends to be a mobile, but uses the victim's
   address as the care of address.  This would cause the correspondent
   node to send the victim some unexpected traffic.  The procedure
   defends against these attacks by requiring at least passive presence
   of the attacker at the care-of address or on the path from the
   correspondent to the care of address.  Normally, this will be the
   mobile node.

==> s/care of/care-of/ (and elsewhere if applicable)?

   just the interception of a few packets, whereas in regular IPv6 it is
   necessary to intercept every packet.  The effect of the attacks is
   the same regardless of the method, however.  In any case, the most
   difficult task attacker faces in these attacks is getting to the
   right path.

==> s/getting to/getting on/ ?

15.4.4 Return Routability Replays

   The return routability procedure also protects the participants
   against replayed Binding Updates.  The attacker is unable replay the
   same message due to the sequence number which is a part of the
   Binding Update.  It is also unable to modify the Binding Update since
   the MAC would not verify after such modification.

==> reword "would not verify" -- "verification would fail" ?

A

---

From: Jari Arkko <[email-masked]>
Date: Sat, 25 Jan 2003 03:03:39 +0200

Hello Pekka and thanks for your in-depth review!

Just a few quick comments below. For the rest, your e-mail has
been filed as issues 232 through . (I'm hoping that folks can
use an Subject line when discussing the individual items
so its easier to track which issue we are discussing.)

* The special case NS hack is being discussed in another thread,
   and that is filed as an issue #218. I believe folks are
   coming up with a potentially less hackish solution for this.

* The 160/128 bit entropy issue: I don't think entropy has been
   a consideration in making the Kbm 20 bytes. Rather, where
   Kbm is used (HMAC_SHA1) you can give a 20 byte input. RFC
   2104 allows smaller lengths as well, but I'm not sure it
   increases the security; it might even lower it. But yes,
   the true entropy is what originally came into the system.
   I still think we should not explicitly make the values
   shorter. But did you want an explanation somewhere about
   the implications of the size of the original inputs?

* Appliances that don't have config knobs: I agree.

* Route BAs via home agent: I think we need them to go
   directly to the sender. Otherwise, after a movement,
   it is very hard to see an error response. Or?

* Retransmissions and mandatory BAs -- I think you are
   right, both A=1 and mandatory BA case needs to have
   retransmission rules and state.

* DHAAD security considerations. I think we have discussed
   this in the past.

* Movement detection DAD & old addresses. I think all addresses
   have to be DADed per existing RFCs, if we have indeed
   seen a movement.

Jari

---

From: Pekka Savola <[email-masked]>
Date: Sat, 25 Jan 2003 07:35:26 +0200 (EET)

Hello,

I've continued the commentary of these issues under specific threads (Cc:  
only mobile-ip).

Below just a few really brief summaries..

>    coming up with a potentially less hackish solution for this.

Good.
 
>    the implications of the size of the original inputs?

In short: yes. :-)
 
>    it is very hard to see an error response. Or?

HA should always have the up-to-date location.  This seems like an issue 
only if network latency of MN->HA is greater than MN->CN->HA.
 
>    retransmission rules and state.

Ok.
 
> * DHAAD security considerations. I think we have discussed

I hope some of that would have ended up in sec cons then ;-).
 
>    have to be DADed per existing RFCs, if we have indeed

Perhaps not all -- globals are supposed to be globals and perhaps DAD for
them is a bit of a cornercase.

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 25 Jan 2003 06:13:48 +0100 (CET)

>    it is very hard to see an error response. Or?

Also, to avoid reflection attacks it makes sense sending the BA to the
IP source address in the BU.

>    retransmission rules and state.

That looks odd - typically protocols only need the "request" retranmitted.
Having retransmit timers on a "reply" might cause confusion when the "request"
is also being retransmitted.
In this particular case, for A=1 the BU will be retransmitted when the
MN doesn't receive a BA.
For error BAs presumably what caused the BU to be sent (e.g. receiving
packets tunneled from the HA) will sooner or later result in a new BU
(because the first BU was not accepted) which will cause the same error
i.e. a new BA.
Isn't that sufficient?

  Erik

---

From: Jari Arkko <[email-masked]>
Date: Sun, 26 Jan 2003 03:09:43 +0200

> (because the first BU was not accepted) which will cause the same error

Yes.

I don't think we can have the retransmission rules depend on
something that only the peer can know -- such as if an error
happens. However, we do have the rule that all BUs from a HA
will be acked. This is something that the mobile node knows:
if I'm sending a BU to a HA, I should expect an ack. But
looking at the spec, we *do* require the (A) bit to be set
for those. So the current text appears fine after all?

Jari