Subject: [mobile-ip] the remaining parts for issue 241

From: Jari Arkko <[email-masked]>
Date: Fri, 21 Feb 2003 00:07:35 +0200

Here are responses to the remaining parts of Pekka's editorial/
semi-editorial comments. The full discussion is reflected on the
issue web site.

I think we were done with the discussion of the previous
comments, please speak up if you disagree or if you see
something wrong below.

Again, I have taken in account the comments except in few
special cases. And I want to thank Pekka again for his
very valuable review.

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

Done.

 >    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!

Changed.

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

Yes. I put in a SHOULD.

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

Perhaps. Not sure I see what the disadvantages are, beyond the pretty
optimal max 1.5 RTT exchange. Note that 802 link detection, link
authentication, cipher negotiation, IPv6 parameter detection, & other
tasks currently take a *huge* amount of time. But this isn't related
to route optimization, its related to movements (and is hopefully
getting better).

I added: "These effects combine to enable much better performance and
robustness for communications between mobile nodes and IPv6
correspondent nodes.  Route optimization introduces a small amount of
additional state for the peers, some additional messaging, and upto
1.5 roundtrip delays before it can be turned on. However, it is
believed that the benefits far outweight the costs in most
cases. Section 11.3.1 discusses how mobile nodes may avoid route
optimization for some of the remaining cases, such as very short-term
communications."

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

Removed.

 >    o  In Mobile IPv6, the mobile node does not have to tunnel multicast
 >       packets to its home agent.
 >
 > ==> this is not really true anymore.

Strictly speaking, MIPv6 nodes can use multicast on the visited
link with care-of addresses... but this isn't news so I deleted
the item.

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

I guess not. I'm not sure we should discuss that in this text, though.
Not edited.

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

No. Its for the care-of address. There was a feature in the spec
previously that said that you could have manually configured care-of
addresses for different links. But we removed this; it really isn't
practical if you think about it. In any case, I softened the language
to "... conventional IPv6 mechanisms, such as stateless ...".

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

This has already been fixed as a part of another issue. Just a reference
to 6.1.7 remains.

 >       *  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?

Ah I see. Changed to "(within the Home Address destination option
if different from the Source Address)

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

Hmm... maybe not? Section 12 is for *constants* while section 13
is for configuration variables. The note would have just one
audience -- the guy who updates the RFC. Not edited.

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

Uh... the name was a deliberate attempt to make it clear that you can't
just chain these headers like some other extension headers can. I removed
the piggybacking text and referred to a "future extension" instead.

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

I added "procedures of calculating upper layer checksums while away
from home".

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

All the future cases we have looked at have found the current scheme
sufficient. For instance, an option which really needs to be
understood could be specified so that it must be copied to the
response. Nodes that don't do this didn't support the option.

Not edited.

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

Added ", and MUST be cleared in other Binding Updates"

 >       *  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?

Should have been zero or more. Fixed.

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

It has been updated due to some other comments.

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

BAs are likely to be sent most of the time; for home registrations
they are always sent and for CN registrations I suspect doing them is
a good tradeoff against having to lose packets if the BU was lost.

In any case, we need a lifetime field in the Ack because the peer
can return a smaller lifetime than we requested.

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

Should have been zero or more. Fixed.

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

This is an issue we discussed at length half a year ago. We finally
agreed on this format. But yeah, there are tradeoffs. Not very important
ones, however, imho. Not edited.

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

No such place -- this is the definitive section for this stuff.  But I
agree that the "e.g." is pretty vague. Corrected to the form: "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 home address
form the Home Address destination option should be used."

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

Not for me either at first sight, but see RFC 2460... not edited, this
appears commonplace in IPv6.

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

Yes. Moved.

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

Yes. Added "This simplifies the process of returning home, as
discussed in Section 11.5.4."

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

I'm 100% sure it works. Here's the argument: in order to set-up
route optimization you have to get HOTs and COTs. If the CN
doesn't answer you are not going to get them. And if you
don't have route optimization set up, you will be doing
bidirectional tunneling. It works.

However, the ICMP erros are less of a sure thing. You might
not get them (policy at the peer) or your implementation might
not support acting upon them. Anyways, the reference has been
added.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Feb 2003 08:32:35 +0200 (EET)

Seems OK to me, thanks.

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