Subject: [mobile-ip] Proposals for resolution of Issue #94

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 17 Oct 2002 15:02:14 -0700

Hello again,

Issue #94 raises questions about addressability of mobile nodes.
Here is the URL for the issue text:
    http://www.piuha.net/~jarkko/publications/mipv6/issues/issue94.txt

Here are some proposed resoutions:

1. Insert the definition:

      unicast routable address
                  An identifier for a single interface such that
                  a packet sent to it from another IPv6 subnet is
                  delivered to the interface identified by that
                  address.  Accordingly, a unicast routable address must
                  have either a global or site-local scope (but not
                  link-local).

2. Eliminate references in 5 or 6 places of the specification
   to "illegal" addresses, preferring to indicate the legal addresses
   (typically, "unicast routable addresses").

3. Specify that only a unicast routable address is allowable
   in a type-2 routing header.

4. (as discussed also for Issue #95) Specify that a home address
   MUST be a unicast routable address.

5 (from the issue text). 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.

As always, comments are most welcome.  If this is acceptable,
I'll produce sample text tomorrow for the new paragraph in
section 4.

Regards,
Charlie P.

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 18 Oct 2002 15:07:04 +0200

Sounds good, Charlie.

-gabriel

-- 
Gabriel Montenegro (Sun Microsystems Laboratories, Europe)
180, Avenue de l'Europe          Email: [email-masked]
ZIRST de Montbonnot              Mobile: +33 673 99 56 62
38334 Saint Ismier CEDEX, France
Office: +33 476 18 80 45 (sun internal: x38045)
Fax:    +33 476 18 88 88

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 22 Oct 2002 16:02:13 -0700

Hello folks,

Since there has not been any discussion to suggest that the
previous proposals are flawed, I am going to update the
specification accordingly.  See comments inline for details.

There is one issue which may need further comment, although
I thought it had already been decided.  The question is
whether a mobile node with only a site-local address is allowed
to roam to a new site and get a global care-of address.  The
tunneling might still work.  Nevertheless, I thought
that this behavior had been prohibited, and I worded the
paragraph below with that in mind.  I can just as easily
change it to lift the prohibition if that is desired.

Otherwise, I will consider the issue to be closed after the
specification has been updated according to the proposal,
and including the new subsection.

Regards,
Charlie P.

=======================================================================

>    in a type-2 routing header.

I changed instances of "Routing Header" to be "routing header"
while looking through the text for this task.

>   home agent will not reach its destination.

Here is some proposed text to become the last subsection of Section 4:

   Site-Local Addressability 

   Mobile nodes are free to move from site to site, but the use of  
   site-local addresses must be carefully managed.  When a mobile node
   or home agent address is site-local, then Mobile IP messages using
   those address MUST stay completely within the site.  Thus, a mobile
   node MAY use a site-local home address for roaming within a site, but
   not for roaming to another site.  This is true even though the mobile
   node may be able to obtain a globally addressable care-of address at
   the new site.

   If a mobile node or home agent has a global IPv6 address available,
   it SHOULD be selected for use with Mobile IP signaling, in order to
   make the greatest chance for success in case the mobile node might
   move to a different site.
   
   Operations affecting multi-sited IPv6 nodes are not completely
   understood, especially operations involving mobility management.
   For this reason, home agents SHOULD NOT be multi-sited.  Similarly,
   particular network interfaces of mobile nodes SHOULD NOT be
   multi-sited.  On the other hand, for mobile nodes, different
   interfaces of the same mobile node MAY have site-local addresses from
   different sites.

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 23 Oct 2002 12:23:39 +0200

Hi Charlie,

 > change it to lift the prohibition if that is desired.

Hmm... doesn't seem like this tunneling is allowed to work.
 From draft-ietf-ipngwg-scoping-arch-04.txt:

"   A node that receives a packet addressed to itself and containing a
    Routing Header with more than zero Segments Left [RFC 2460, section
    4.4] first checks the scope of the next address in the Routing Header.
    If the scope of the next address is smaller than the scope of the
    original destination address, the node MUST discard the packet.
    Otherwise, it swaps the original destination address with the next
    address in the Routing Header.  Then the above forwarding rules apply
    as follows:

            o The zone of the new destination address is determined by
               the scope of the next address in the Routing Header and
               arrival interface of the packet.  The next-hop interface
               is chosen just like the first bullet of the rules above.

            o After the next-hop interface is chosen, the zone of the
               source address is considered just like the second bullet
               of the rules above.

This check about the scope of the next address ensures that when a
packet arrives at its final destination, if that destination is link-
local then the receiving node can know that the packet originated on-
link.  Similarly, if the destination is site-local then the receiving
node can know that the packet originated within the site.  And, as a
result, this will help the receiving node send a "response" packet with
the final destination of the received packet as the source address
without breaking its source zone. "

The spirit of the above would apply as well to type 2 routing headers (because
SegmentsLeft == 1).

Perhaps we should explicitly clarify that this rule applies
to type 2 routing headers as well.

-gabriel

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Wed, 23 Oct 2002 21:58:42 +0900 (JST)

>    move to a different site.

I agree.
    
>    interfaces of the same mobile node MAY have site-local addresses from

I don't understand the above paragraph.  By definition, an interface
cannot belong to multiple zones with the same scope.  I think the
situation said in the second sentence never happen.

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Wed, 23 Oct 2002 22:06:07 +0900 (JST)

> Hmm... doesn't seem like this tunneling is allowed to work.

I think Charlie is talking about bi-directional (encapsulated)
communication, not route optimized (routing header) communication.

If we use bi-directional tunnel, we can use a site-local home address
with some restrictions as described in the section 11 of
scoping-arch-04.

---
Keiichi SHIMA

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 23 Oct 2002 17:02:24 +0200

Keiichi SHIMA / ??? wrote:
> From: gabriel montenegro <[email-masked]>
> 

But how does the BA get back to the MN from the HA?

-gabriel

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 23 Oct 2002 08:58:23 -0700

Hello Keiichi,

> communication, not route optimized (routing header) communication.

Yes, I did mean encapsulation in the above.

> with some restrictions as described in the section 11 of

I will be happy to rewrord the paragraph to permit this if
there is no objection.

However, as Gabriel points out, that still does not permit
route optimization unless we also relax the rule on routing
headers.

Regards,
Charlie P.

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Thu, 24 Oct 2002 14:12:42 +0900 (JST)

> But how does the BA get back to the MN from the HA?
 
Ah, I have missed it.  You are right.  Currently, we can't forward the
BA from the HA because it breaks the zone boundary.

Umm, I perfer to keep current text, not to relax the rule of the
routing header processing.

---
Keiichi SHIMA