Subject: [mobile-ip] Mipv6 issue #155: editorials

From: Jari Arkko <[email-masked]>
Date: Wed, 11 Dec 2002 23:46:52 +0200

I have taken in account the editorial comments from Thomas.
See for the issue file #155 for details:

   http://www.piuha.net/~jarkko/publications/mipv6/issues/issue155.txt

but in the following I will list the most important ones. There
are a few not-so-editorial issues embedded here again so do
take a look below for the most important ones. These include
prefix handling clarifications, preference default value changes,
and so on.

 > >       Home Agent Preference
 > >
 > >          16-bit signed, two's complement integer.  The preference for
 >
 > Don't see two's complement used that much in on-the-wire
 > fields... Sure you want to do this, as opposed to making this
 > unsigned?

I guess the intent was to allow for the situation when you don't get
this preference. This would be 0. My preference is to use unsigned and
set the default preference to 32768. Text changed.

 > >     1. The home agent examines the value of the Single Address Only (S)
 > >        bit in the received Binding Update.  If this bit is nonzero, the
 > >        next step is carried out only for the individual home address
 > >        specified for this binding.  If, instead, this bit is zero, then
 > >        the next step is carried out for one address for each one of the
 > >        subnet prefixes currently considered by the home agent to be
 > >        on-link the mobile node.  Each address is formed by replacing,
 > >        in turn, the configured subnet prefix in the mobile node's home
 > >        address.  For this purpose, the set of on-link prefixes includes
 > >        both the link-local and site-local prefix.
 >
 > the "generate an address for this prefix" bit in the prefix option
 > seems to be ignored with the wording above (and used throughout). Is
 > this just an oversight? I.e., one only generates address if the option
 > has the right bits set to 1.

Yes, this should be fixed. Changed text for 10.3.1: "If the Single
Address Only~(S) bit in the Binding Update is zero, the home agent
creates Binding Cache entries for each of possibly several home
addresses. The set of such home addresses is formed by replacing the
routing prefix for the given home address with the following set of
other prefixes. The prefixes must be for the mobile node's home link,
suitable for autonomous address configuration, and be supported by the
home agent processing the Binding Update."

Changed text for 10.4.1: "If, instead, this bit is zero, then the next
step is carried out for each of possibly several home addresses
described in Section 10.3.1.  For this purpose, the set of
on-link prefixes includes both the link-local and site-local prefix."

 > >     -  The IP addresses in the Home Agent Addresses field SHOULD
 > >        be listed in order of decreasing preference values, based
 > >        either on the respective advertised preference from a Home
 > >        Agent Information option or on the default preference of 0 if
 > >        no preference is advertised (or on the configured home agent
 > >        preference for this home agent itself).
 >
 > SHOULD should be MUST?? The protocol should require that MNs try in
 > order, which means the provided order needs to match the requested
 > preferences. Why would this be a SHOULD?

MUST is better. Changed.

 > A lot of the > 128 codes are hard errors. Saying 'delete" the BUL
 > seems insufficient the MN needs to keep state that no more BUs are to
 > be sent. Either forever, or for a very very long time (long enough
 > that its probably better to just say forever, modulo cache cleanup
 > issues).

We have a mark-the-entry approach already in section 11.3.4. Perhaps
that could be employed here as well.

Change:

	the mobile node MUST delete the corresponding Binding Update List
	entry, and it MUST also stop retransmitting the Binding Update.

=>

	the mobile node SHOULD record in its Binding Update List that future
         Binding Updates SHOULD NOT be sent to this destination.

 > >       DHAAD_RETRIES            3 retransmissions
 >
 > Seems pretty low. 4 transmissions and you lose?

Yeah. Perhaps we could increase it to 4. I'm not sure doing
much more makes sense. On wireless, connectivity problems could
last very long. For 100% reliability, the mobile node should ask
the info.

Changed text: 4 retransmissions

 > Note: MN->home subnet initial RTTs above are 5, 2 and 1. Seems pretty
 > arbitrary to me...

Here I agree. How about BU = 1 s, "management" messages are, say, 3 s?

Changed text:
	INITIAL\_DHAAD\_TIMEOUT		\> 3 seconds			\\

	INITIAL\_SOLICIT\_TIMER		\> 3 seconds			\\

	PREFIX\_ADV\_TIMEOUT		\> 3 seconds			\\

 > > 8.1. All IPv6 Nodes
 > >
 > >    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 requirements
 > >    for such nodes, and standard IPv6 techniques are sufficient.
 >
 >
 > Would be good to say (here?) how a node that does MIP RO determines
 > that a CN doesn't do any MIP extensions. I assume there is a parameter
 > problem type error, and that the MN needs to respect that response?

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

 > >    of its care-of address.  Assuming there are no additional routing
 > >    headers in this packet beyond those needed by Mobile IPv6, the mobile
 > >    node sets the fields in the packet's IPv6 header and routing header
 > >    as follows:
 >
 > This description seems overly prescriptive about internal
 > implementation details. I think it would be better to somehow say
 > these are the conceptual steps, rather than implying this is what
 > implementations do. There are other ways of creating the correct
 > on-the-wire packet.

Corrected, new text: "
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 consultation MUST based
on the IP the mobile node's home address.

For instance, assuming there are no additional routing headers in this
packet beyond those needed by Mobile IPv6, the correspondent node could set
the fields in the packet's IPv6 header and routing header as follows:

-	The Destination Address in the packet's IPv6 header
	is set to the mobile node's home address (the original
	destination address to which the packet was being sent).

-	The routing header is initialized to contain a single route
	segment, containing the mobile node's care-of address
	copied from the Binding Cache entry.
	The Segments Left field is, however, temporarily set to zero.

The IP layer will insert the routing header before performing IPsec
processing. Once all IPsec processing has been performed, the node
swaps the IPv6 destination field with the Home Address field in the
routing header, sets the Segments Left field to one, and sends the
packet. This ensures the AH calculation is done on the packet in the
form it will have on the receiver after advancing the routing header."

 > >    to the correspondent node.  If the correspondent node receives
 > >    persistent ICMP Destination Unreachable messages after sending
 > >    packets to a mobile node based on an entry in its Binding Cache, the
 > >    correspondent node SHOULD delete this Binding Cache entry.
 >
 >
 > I wonder if more guidance here is useful. It might make more sense to
 > not discard the entry, but to send both ways. Or do something else
 > less drastic than delete the entry. But this can probably be added
 > later easily, so maybe best to just leave this for now. Or add some
 > words saying more experience is needed here in order to learn what
 > works well.

I'd leave this as is for now. Perhaps we will someday have a way
to know whether a ICMP unreachable is authentic or not.

 > >    If the Source Address field of the IPv6 header that carried the
 > >    Binding Update does not contain a unicast address, the Binding
 > >    Acknowledgement MUST NOT be sent, and the Binding Update packet MUST
 > >    be silently discarded.  Otherwise, the acknowledgement MUST be sent
 > >    to the Source Address.  Unlike the treatment of regular packets, this
 > >    addressing procedure does not use information from the Binding Cache.
 > >
 > >    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.
 >
 >
 > These two paragraphs are odd. The first one says "don't use the
 > Binding Cache". the second one says use routing header. But the
 > routing header is only used in conjunction with the BC. So I think
 > some more words might be appropriate here...

Right. New text:

    If the Source Address field of the IPv6 header that carried the
    Binding Update does not contain a unicast address, the Binding
    Acknowledgement MUST NOT be sent, and the Binding Update packet
    MUST be silently discarded. Otherwise, the acknowledgement MUST be
    sent 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.

 > >    A mobile node on a remote network SHOULD autoconfigure all of the
 > >    global IP addresses, which it would autoconfigure if it were attached
 > >    to its home network and which are from prefixes served by home
 > >    agents.  Site-local addresses MAY be autoconfigured if the mobile
 > >    node is roaming in a network on the same site as its home addresses.
 > >    Site-local addresses and addresses not served by a home agent MUST
 > >    NOT be autoconfigured, since they are unusable in the remote network.
 >
 >
 > The wording would be much better if it were:
 >
 >  the messages relayed to the MN are the ones learned via ND on the
 >  home link. The prefix options are processed as defined in ND (no
 >  SHOULD about whether  to do this...)

The whole paragraph has been replaced by "The messages relayed to the
mobile node are the ones learned via Neighbor Discovery on the home
link. The prefix options are processed as defined
in~\cite{rfc2461,rfc2462}."

 > >     -  The mobile node MAY choose to directly use one of its care-of
 > >        addresses as the source of the packet, not requiring the use
 > >        of a Home Address option in the packet.  This is particularly
 > >        useful for short-term communication that may easily be retried
 > >        if it fails.  An example of this type of communication might
 > >        be DNS queries sent by the mobile node [27, 28].  Using the
 >
 >
 > actually, DNS queries may be a bad example, if two-faced DNS is
 > used...
 >
 > This document should say that which address to  use is a topic of
 > future work, as the choices of appropriate address may be application
 > specific. APIs will need to be developed to give applications better
 > control over which addresses to use by default....

Right. New text " The choice of the most efficient communications
method is application specific, and outside the scope of this
specification. The APIs necessary for controlling the choice are also
out of scope."

 > >    Since the router SHOULD be sending periodic unsolicited multicast
 > >    Router Advertisements, the mobile node will have frequent opportunity
 > >    to check if it is still reachable from its default router, even
 > >    in the absence of other packets to it from the router.  If Router
 >
 >
 > not true. there gap between advertisement can be very long. like 30
 > minutes.

Reworded: "Since the router sends periodic unsolicited multicast
Router Advertisements, the mobile node will have an opportunity to
check if it is still reachable from its default router, even in the
absence of other packets to it from the router."

 > >    by the new router.  A mobile node MAY form a new primary care-of
 > >    address at any time, except that it MUST NOT do so too frequently.
 >
 > Now there is a useful MUST NOT... (not).

Ok, deleted. New text "A mobile node MAY form a new primary care-of
address at any time, but a mobile node MUST NOT send a Binding Update
about a new care-of address to its home agent (which is required to
register the new address as its primary care-of address) more often
than once per \verb|MAX_UPDATE_RATE| seconds."

 > >    After the Mobile Node sends the Binding Update, the Home Agent MUST
 > >    remove the Proxy Neighbor Cache entry for the Mobile Node and MAY
 > >    learn its link-layer address based on the link-layer packet or cached
 > >    information, or if that is not available, it SHOULD send a Neighbor
 > >    Solicitation with the target address equal to the Binding Update's
 > >    source IP address.  The Mobile Node MUST then reply with a unicast
 >
 >
 > why say anything about the LL address? Why doesn't normal ND just
 > handle this transparently? (especially if the MN does normal ND before
 > sending the BU to the HA.)

Actually, the home agent section already deals sufficiently with this.
We can delete the home agent actions from here. Changed text: "After
the Mobile Node sends the Binding Update, it MUST be prepared to reply
to Neighbor Solicitations from its home agent. The replies MUST be
sent using a unicast Neighbor Advertisement to the home agent's
link-layer address."

 > >    Neighbor Advertisement to the Home Agent with its link-layer address.
 > >    While the Mobile Node is waiting for a Binding Acknowledgement, it
 > >    MUST NOT respond to any Neighbor Solicitations for its Home Address
 > >    other than those originating from the IP address to which it sent the
 > >    Binding Update.
 >
 >
 > I'm also not sure this is really needed.

I guess the intention is to not confuse others with conflict NAs.
However, if we just returned home then no traffic is getting through
before we succeed in the BU anyways... maybe it doesn't matter. Let's
remove it

 > >    As the set of on-link subnet prefixes on the home link changes over
 > >    time, the home agent changes the set of home addresses for this
 > >    mobile node for which it is serving as the home agent.
 >
 >
 > I hope this means that the MN changes the address it is using and
 > tells the HA about this. NOt that the HA just does this directly.

Yes.

I just deleted the sentence alltogether. This is described elsewhere.

 > >    routability procedure.  The mobile node MAY also choose to either
 > >    ignore the Binding Refresh Request or to delete its binding from the
 > >    sender of the Binding Refresh Request.  Note that the mobile node
 > >    SHOULD NOT respond Binding Refresh Requests from previously unknown
 > >    correspondent nodes due to Denial-of-Service concerns.
 >
 >
 > Why would the MB delete an existing binding when it is asked to
 > refresh it? I can understand that a MN can always delete an entry at
 > any time, but having words suggesting this  is OK in response to this
 > message seems rather odd.

I agree.  Let's remove that. New text: "When a mobile node receives a
packet containing a Binding Refresh Request message and there already
exists a Binding Update List entry for the source of the Binding
Refresh Request, it MAY start a return routability procedure. The
mobile node MAY also choose to ignore the Binding Refresh
Request. Also, the mobile node can at any time delete its binding from
a correspondent node."

 > >       INITIAL_BINDACK_TIMEOUT  1 second
 >
 > Why one second, when default timeout for finding HAs is 2? Seems inconsistent

BUs need to be done quickly, whereas startup procedures such as
DHAAD and administrative tasks like MPA can take longer. BU delays
are now

 > >       INITIAL_DHAAD_TIMEOUT    2 seconds
 > >       INITIAL_SOLICIT_TIMER    2 seconds
 > >       MAX_ADVERT_REXMIT        3 transmissions
 >
 >
 > isn't this the same as MAX_NEIGHBOR_ADVERTISEMENT in the ND spec? Why
 > have a different constant  here? Seems like normal ND rules could be used.

Yes it is. Use MAX_NEIGHBOR_ADVERTISEMENT only, and remove
MAX_ADVERT_REXMIT.

 > >        routability procedure the easiest route for attackers.  For this
 > >        reason, this specification should have a protection mechanism for
 > >        selecting between return routability and potential other future
 > >        mechanisms.
 >
 >
 > But it doesn't ...

Yeah. I think we have given up on this even we still believe it would
have been justified; the proposals didn't fly in the IETF. Text removed.

 > >    We also require that all implementations MUST allow route
 > >    optimization to be administratively enabled or disabled.  The default
 > >    SHOULD be enabled.
 >
 >
 > Is similar  text also given elsewhere (I don't recall seeing it). If
 > its only in the security considerations section, an implementor may
 > miss doing this...

Ok. Let's put this also in the requirements section. To the CN and the
MN sections:

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

And then we leave only this in Section 14: "We also require that all
implementations be capable of administratively disabling route
optimization."

---

From: Brian Haley <[email-masked]>
Date: Wed, 11 Dec 2002 17:56:47 -0500

> set the default preference to 32768. Text changed.

Why would we set the default to 32768 and not leave it 0?

While I was thinking about it, I checked the draft for other possibly
anomolies with structure definitions:

Binding Update
      Sequence #

         A 16-bit number used by the receiving node to sequence Binding
         Updates and by the sending node to match a returned Binding
         Acknowledgement with this Binding Update.

Shouldn't this be:

	16-bit unsigned integer.  The number used by the receiving...

-Brian

---

From: Jari Arkko <[email-masked]>
Date: Thu, 12 Dec 2002 11:15:51 +0200

By the way, the issue file for 155 is now at the issue site, I forgot
to copy it there yesterday. So if you looked yesterday, look again...
sorry.

> Why would we set the default to 32768 and not leave it 0?

I think Thomas wanted to get two's complement away and I agree
with him. Then its another issue what the default is. I guess
the original intention was to make sure that there'd be values
under and over the default one. I really don't see a huge benefit
for that myself. So I could agree with default 0 as well. Maybe
that looks cleaner too.

> 	16-bit unsigned integer.  The number used by the receiving...

Right, thanks!

Jari

---

From: Brian Haley <[email-masked]>
Date: Thu, 12 Dec 2002 12:09:01 -0500

> for that myself. So I could agree with default 0 as well. Maybe

Ok, I see now what you were trying to do, the default would be
the middle of the range and you could configure your HA to be
better or worse than this if necessary.  I tried to find some
precedence in other docs but couldn't, maybe someone else does
though?

-Brian

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 12 Dec 2002 13:43:37 -0500

> for that myself. So I could agree with default 0 as well. Maybe

If you wanted that, why not specify this as a signed integer with
the default of 0?

I guess a precendence of -25 sounds odd, but so does the default of 32768...

-vlad

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: Jari Arkko <[email-masked]>
Date: Thu, 12 Dec 2002 22:30:33 +0200

> If you wanted that, why not specify this as a signed integer with

This was what draft 19 said, but a two's complement integer on
the wire looks a bit funny to some people...

> precedence in other docs but couldn't, maybe someone else does

If the format is unsigned, default 0, and higher values mean
better then all the home agents with the default are the last
ones in priority. Some special ones can be marked as higher
priority.

I think this more than sufficient. Therefore I like the unsigned,
default 0 approach. Its simple too.

Jari