Subject: [mobile-ip] AD review commments on draft-ietf-mobileip-ipv6-19.txt

From: Thomas Narten <[email-masked]>
Date: Mon, 11 Nov 2002 16:31:19 -0500

The WG has requested that this document be advanced. I have reviewed
the document and have a number of comments on it. Many are
editorial/clarification type questions, which will be sent in a
separate note. Here are some of the more general comments I have. My
sense is that based on the number of comments and issues, this
document is not ready for IETF LC yet. On the other hand, I don't see
any real show stoppers, and I've been told that a revised version can
be produce fairly quickly, once there is agreement on the needed
edits.

I'm not comfortable with text in the document that are basically
modifications to ND that are not critical to basic MIP. Some
modifications are clearly critical (new message options, etc.) But
there are also a number of changes to the ND spec that are of broader
applicability than to just mobile nodes. In particular, there is text
along the lines of

  - one MAY skip DAD, if one feels like it
  - one can send messages more frequently than called for in the ND spec
  - one need not delay as long as the ND spec calls for when waiting
    to send RS
  - run DAD in parallel with using the address (optimistic DAD)
  - etc.
  
See Section 7, and 7.5-7.6 in particular. But the spec also includes
language that says if DAD fails, one should generate a new IID and try
again. (Section 7.7)

Most, if not all of these changes have not been reviewed by the IPv6
WG, AFAIK. I see two ways of handling this:

a) point the IPv6 WG to the document and ask them to
   comment/review. But I suspect that this will not be a short
   discussion.

b) Pull much or all of this text out of the MIP spec, put it in a
   separate ID, and then run it through the process separately (i.e,
   don't hold up the MIP spec). I don't think these changes are
   critical to MIP in a normative sense. They are optimizations that
   will make MIP work better. I think we can target getting a
   separate document in about 6 months.

After some preliminary discussion with the MIP and IPv6 chairs, the
latter approach seems to be the preferred one.

Section 11.6 and 11.7 talk about when to invoke RR and send BUs. Some
of the SHOULD-like text seems premature and even maybe
contradictory. I think this text should be reworked to be generally
more conservative about when to invoke, and be prefaced with a big
note saying that we need more experience in determining when to
initiate RO and when to just go through the HA, and that
implementations are encouraged to experiment and report results. Note
that no all communication benefits from RO (but this section doesn't
seem to mention this). Thus, it seems prudent to delay RO to cases
where it appears that a significant amount of communication will take
place. I.e., connections that last more than a few seconds, etc. But
we don't have experience with heuristics yet. Thus, some
experimentation and learning is needed. Right now text like:

>    In
>    particular, the mobile node SHOULD initiate a return routability
>    procedure in response to receiving a packet that meets all of the
>    following tests:

which basically says one should always initiate RR if one starts
conversing with a CN. This seems too aggressive (and unnecessary).

The current semantics of the "D" bit seem to imply that the MN tells
the HA when to invoke DAD.

>    mobile node's recent Binding Update was accepted by the home agent,
>    and the lifetime for that Binding Update has not yet expired, the
>    mobile node SHOULD NOT set the Duplicate Address Detection (D) bit in
>    the new Binding Update; the home agent will already be defending the
>    home address(es) of the mobile node and does not need to perform DAD
>    again.

Seems like the semantics here may not be ideal? Are the semantics "do
DAD right now" or are they "Do DAD at all times, including now if you
haven't recently"?  Seems complicated to have the MN set DAD
sometimes, but sometimes not. It might be better for the the MN to
just say "I expect you to do DAD" and let the HA decide when it needs
to run DAD proactively as opposed to just respond to NS's for the MN.

>     -  The Home Agent Addresses field SHOULD contain one global IP
>        address for each home agent currently listed in this home agent's
>        own Home Agents List (Section 10.1).  However, if this home
>        agent's own global IP address would be placed as the first entry
>        in the list (as described below), then this home agent SHOULD NOT

The HA discovery process seems to have taken some architectural short
cuts in that it only returns one global address of each HA. In IPv6,
if a node has mulitple IPv6 addresses, other protocols return them
all. Seems shortsighted to limit the HA discovery protocol to
returning only one address per HA.

Also, does MIP work properly of if a MN uses DHCP (as opposed to
stateless addrconf?).

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

Site-local wording may have some problems here, since there is no
way of knowing what site a node is currently on. Right? Also, MAY
language above seems wrong. If you are on a home link, you
autoconfigure them all you don't MAY the site-local ones.

>     -  While not at its home link, the mobile node MUST NOT use its home
>        address (or the home address destination option) in Neighbor
>        Discovery messages on the visited link.  The mobile node also
>        MUST NOT use its home address when communicating with link-local
>        or site-local peers on the visited link, if the scope of the home
>        address is larger than the scope of the peer's address.

this business about special-casing SL handling seems problematic. How
do you know if you are communicating with a SL address on the local
site or the home site? You MUST use ND to do address resolution on the
local link. The above ie equivalent to saying you can't use SL
addresses when roaming...

>    (after delivering to other local 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 be tunneled to the mobile node by default.  This behavior MUST

How does a HA know which mcast group a MN has joined? I see nothing
that indicates the MN runs MLD back to the home link. Seems like the
spec needs to have text about running MLD.

Thomas

---

From: "James Kempf" <[email-masked]>
Date: Fri, 15 Nov 2002 00:29:39 -0800

I agree.

            jak

----- Original Message ----- 
From: "Brett Pentland" <[email-masked]>
To: <[email-masked]>
Cc: "Thomas Narten" <[email-masked]>
Sent: Tuesday, November 12, 2002 7:49 PM
Subject: Re: [mobile-ip] AD review commments on draft-ietf-mobileip-ipv6-19.txt

> This suggestion to pull the performance optimisations out of the base
> spec and put them into a separate document sounds like a sensible idea,
> especially if they are going to be the really contentious items that
> slow down the progress of the base document.
> 
> There have been a number of optimisations discussed on the list in
> addition to those that are in the MIPv6 draft:
> 
> Optimistic DAD -
> <http://www.ietf.org/internet-drafts/draft-moore-ipv6-optimistic-dad-00.txt>
> Fast router advertisements - 
> <http://www.ietf.org/internet-drafts/draft-mkhalil-ipv6-fastra-02.txt>
> Fast router discovery with AP notification - 
> <http://www.ietf.org/internet-drafts/draft-jinchoi-l2trigger-fastrd-01.txt>
> Duplicate Address Detection Optimization using IPv6 Multicast Listener
> Discovery - 
> <http://www.ietf.org/internet-drafts/draft-daley-ipv6-mcast-dad-01.txt>
> 
> to name a few that leap to my mind (there are probably others)
> 
> This optimisation document sounds like a good place to consolidate these
> techniques, explain their relationships and debate their relative
> merits.
> 
> Any thoughts?
> Brett.
> 
> 
> Thomas Narten wrote:
> > 
> <snip>

---

From: "JinHyeock Choi" <[email-masked]>
Date: Fri, 15 Nov 2002 19:14:56 +0900

I agree to pull the 'performance optimization' out of base spec and 
put them into a separate document. It will speed up the process. 
But it will be tricky to decide which features are to be removed.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 15 Nov 2002 21:24:12 +0200

I agree.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 15 Nov 2002 21:21:33 +0200

Folks,

I have broken up Thomas' comments into individual issues at
http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html
so that it will be easier for us to keep track of their status and
resolutions. And then to issue #163:

> spec needs to have text about running MLD.

I agree. MLD needs to be run, otherwise this can't be achieved.
Actually, Section 11.3.5 (the mobile node side) already talks about
tunneling multicast group membership control protocol. Do you
want MLD explicitly mentioned or is it enough if we just add
to Section 10.4.2 that "The home agent MUST be capable of
receiving tunneled multicast group membership control
information from the mobile node in order to determine
which groups the mobile node has subscribed to."?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 15 Nov 2002 21:36:23 +0200

>   - one MAY skip DAD, if one feels like it

I agree that optimistic DAD and other potentially interesting
features should be removed from the spec and dealt with in a
general manner in IPv6.

Proposed text is removing the fifth paragraph from 11.5.2.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 15 Nov 2002 21:31:26 +0200

> modifications to ND that are not critical to basic MIP. Some
...
> language that says if DAD fails, one should generate a new IID and try

Yes, indeed. At first, this seemed like a critical thing to achieve.
This is because the current ND specifications specify a very drastic
action, namely disabling the interface and waiting for reconfiguration.

However, after some discussion I now realize that this is perhaps a
more general problem in IPv6 specifications. Mobile nodes are particularly
vulnerable to this problem, e.g., through malicious attackers doing it
on purpose. But the same situation can also happen even for stationary
nodes. For instance, an attacker could see over unprotected WLAN when
a node comes up and tries to do DAD, and then by responding the node
can be disabled.

It is also true that we have a working group, SEND, to deal with this
and other issues related to IPv6 control functionality. It's better
to deal with this problem there in a general way.

Proposed text is removing all of Section 7.7.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 15 Nov 2002 22:15:03 +0200

> to run DAD proactively as opposed to just respond to NS's for the MN.

The current draft puts the responsibility of keeping track about DAD needs
to the mobile node. Looking back, it probably wasn't the right thing to
do. For one thing, the mobile node then needs to be aware when to do it
and when not and a bit is needed. More seriously, the home agent could
reboot and the MN, unaware of this, could be sending a re-registration
BU with D=0...

So, my proposal is that we remove the D bit from the BU completely and
require HAs to always do DAD except for two cases: (1) not for de-regs
and (2) if the HA already had a binding for this particular address and
it has been defending it then DAD is skipped as well.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 15 Nov 2002 16:32:50 -0800

> it has been defending it then DAD is skipped as well.

this is fine with me.

Vijay

---

From: Vladislav Yasevich <[email-masked]>
Date: Mon, 18 Nov 2002 10:36:23 -0500

I am not sure I understand the issue here...

HA discovery protocol provides a list of global HA addresses to
the mobile node.  That list is generated by each HA and is based
on all of the RAs with 'H' bit set and  Prefix Info options with
the 'R' bit set that were seen on the "home" link.

If there are multiple prefixes (prefix info options) advertised by
a home agent on the home link, there is nothing stopping that HA from
setting the 'R' bit for each prefix.  This will result in multiple
addresses being added to the Home Agent List.

So what am I missing...

-vlad

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

---

From: Thomas Narten <[email-masked]>
Date: Mon, 25 Nov 2002 16:10:10 -0500

> which groups the mobile node has subscribed to."?

The wording  just needs to make it clear that MNs are expected to run
MLD, and if there are any particular issues with tunneling MLD
messages, the details are made clear.

For example, are there any issue with having the MN source MLD packets
with a LL address? Does the HA expect the source address of packets
from the MN to not include LLs? 

Thomas