Subject: [mobile-ip] closing issue 94: Unclear text about address suitable for RH

From: gabriel montenegro <[email-masked]>
Date: Thu, 10 Oct 2002 18:44:51 +0200

This is an attempt to close issue 94 ("Unclear text
about address suitable for RH"):

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

It must be closed in order to issue revision 19 of the MIPv6 draft.

BACKGROUND
===========
This issue is about specifying the addresses allowable for
inclusion within the routing header (type 2) defined in the
MIPv6 spec.

Jari Arkko summarized the issue as follows:

   [...] It is unnecessary to refer to other documents for the
   allowable addresses. We can simply list them in our document.
   Two alternative ways to do this:

   1) List the illegal address types, [...]

   2) List the legal address types, [...]

   I'm concerned that we might miss something by picking the first
   scheme. And what if there are new address types in the future?

Option #2 above is perfectly ok, and is, in fact the more prudent
course of action (notice the parallel between approaches #1 and #2,
with negative and positive firewall rules, respectively).

ANALYSIS
========
It seems more prudent to list the addresses that we know today
are valid and legal for inclusion in RH type 2 headers, implying
that those not explicitly listed are not currently supported.

It seems like the main question to resolve is:

a) What are the valid types of addresses usable as home addresses?

Given that home addresses are what populate routing headers
(type 2) as well as home-address options, once "a" is answered,
we will then have the answers for "b" and "c" below:

b) What are the valid types of addresses for inclusion in home
address options?

c) What are the valid types of addresses for inclusion in type
2 routing headers?

If in the future there are more such legal addresses, then
a separate document will specify such behavior. Notice that
one such current effort is under way via the following draft:
draft-haberman-ipv6-anycast-rr-00.txt.

To find out the types of addresses usable for MIPv6 tunneling
(or HAO or RHtype2) we could look at the IPv6 tunneling draft
(draft-ietf-ipv6-tunnel-v02-00.txt). It allows any "one of the
valid IPv6  unicast addresses" to be used in routing headers. This
implies link local as well, which is allowed as well by rfc2460
for inclusion in routing headers (type 0).

However, link-local addresses are not allowed by the MIPv6
specification. This can be inferred from the "home address"
definition in section 3.2, as well as from the first paragraph
of section 4.1:

      home address An IP address assigned to a mobile node, used as the
                permanent address of the mobile node.  This address is
                within the mobile node's home link.  Standard IP routing
                mechanisms will deliver packets destined for a mobile
                node's home address to its home link.

The requirement is that packets addressed to the home address
of the mobile node will be deliverable via "standard IP routing
mechanisms".  This precludes link-local addresses (which are not
routable), leaving two types of unicast addresses: global and
site-local. The preference is dictated by the default address
selection mechanism (draft-ietf-ipv6-default-addr-select-09.txt):
global before site-local.

PROPOSAL
========

1. The MIPv6 specification will list the legal address types
usable by mobile nodes as home addresses, which at the moment
include *routable* *unicast* addresses (in order of preference):

	- global unicast addresses
	- site-local unicast addresses

This order of preferences is compatible with the
default address selection mechanism specified in
draft-ietf-ipv6-default-addr-select-09.txt.  "Routable" implies
that these addresses are reachable from beyond their immediate link
(so link-local are excluded). This will be further clarified in
section 3.2 (entry for "home address"), and in section 4.1. A
more formal specification will be added as a small section at
the beginning of section 11 (a new 11.1). This will contain some
of the same language as the definition in section 3.2 with the
addition of the above listed valid types and their preference.
This is the section that will be referenced whenever valid address
types are clarified for either the type 2 routing header or the
home-address option.

2. Since the addresses used in routing headers (type 2) are
mobile node home addresses, these dictate the valid types for
the latter. Accordingly, whenever the specification defines the
legal types of addresses for inclusion in routing headers (type
2), it will do so by reference to the relevant section on valid
address types for home addresses (new section 11.1).

3. Since the addresses used in home address options are mobile
node home addresses, these dictate the valid types for the latter.
Accordingly,  whenever the specification defines the legal types
of addresses for inclusion in home address options, it will do
so by reference to the relevant section on valid address types
for home addresses (new section 11.1).

4. The specification will document in section 4 that site-local
addresses should only be used within sites that do not have
global addresses (perhaps because they are disconnected from the
Internet). In such a network, MIPv6 will support mobility within
the site. If at any point the mobile node is able to roam beyond
its local site, MIPv6 does not and cannot provide transparent
communications. In this case, for example, a binding update sent
from a site-local addressed mobile node to a site-local addressed
home agent will not reach its destination.

-gabriel

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 10 Oct 2002 13:48:04 -0400

Gabriel

Minor nit:

 > global before site-local.

The addr selection draft actually prefers site-locals over
globals by default.  This has been the source of heart-burn to
me for a while now.  So, saying that propsal follows the
recomendation of that draft is not correct.

Having said that, I support the address prefrence from
this proposal.

-vlad

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

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 11 Oct 2002 00:17:42 +0200

> recomendation of that draft is not correct.

I see it does! I had read it the other way around for some reason
(wishful thinking?). Doesn't really matter for *this* recommendation,
we'll just delete this reference to the addr selection draft.
It does make you wonder about the addr-selection draft,
and after reviewing the  the ipv6 archive I see this rule has been controversial.

> Having said that, I support the address prefrence from

Cool.

-gabriel