Subject: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt

From: Behcet Sarikaya <[email-masked]>
Date: Sun, 23 Jul 2000 21:51:20 +0900

Hi Jari and Charlie,
  I have some questions on this I-D:
The method is based on advertizing regional care-of addresses to MNs
that
can do a regional BU taking one of them as its alternate care-of address
and thereafter using this address
in the visited domain. This means that the data is continously tunneled
from GMA to MN as long as MN stays in the
domain (sounds like HAWAII in which MN is given an IPv4 address in the
domain, doesn't it?).
So address autoconfiguration at each access router and its associated BU
traffic are compromised with MIPv4 like tunneling.
This same idea can also be found in the I-D by Karim.
Can you provide some clarification on this?
Has this I-D been submitted to IETF?

Regards,
--
Behcet

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 23 Jul 2000 09:13:57 -0700

Hello Behcet,

Here are some answers to your questions.

> domain

Yes, the data _can_ be tunneled to the mobile node as long as
it stays in the domain, from a particular GMA.

> (sounds like HAWAII in which MN is given an IPv4 address in the
> domain, doesn't it?).

The idea of tunneling from a root foreign agent, gateway foreign agent,
gateway mobility agent, etc. is not at all unique to HAWAII.

> traffic are compromised with MIPv4 like tunneling.

How do you mean compromised?  Address autoconfiguration is done
at every access router, binding updates are performed, and I suppose
it is true that MIPv6 tunneling is "like" MIPv4  tunneling.  Compromised
usually means accepting something less than desired.  What better
solution would you like to see?

> Can you provide some clarification on this?

Similar ideas have been popping up with regularity for years.
Our goal is to find some solution that is not encumbered with
intellectual property, so it is perfectly natural that we would
work with ideas that have been around for years.  Isn't this
a good thing?

> Has this I-D been submitted to IETF?

Yes.

Regards,
Charlie P.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 24 Jul 2000 10:29:52 +0900

Hi Charlie,

  Thanks for your clarifications.

By compromise I meant "replaces" or "optimizes".

I thought that a persistent tunnel would be against MIPv6

philosophy of design.

  More importantly, in case of MIPv4, I think it is clear that

regional registrations would lead to performance improvement. I could

not yet see how this would be the case for MIPv6.

What do you think?

Regards,

--
Behcet

---

From: "Jari T. Malinen" <[email-masked]>
Date: Sun, 23 Jul 2000 22:34:47 -0700

Hi, Bechet,

thanks for your comments,

Behcet Sarikaya wrote:

> that can do a regional BU taking one of them as its alternate care-of address

This IPv6-specifc design uses the general idea of IPv4 regional registrations
with a stationary care-of-address, but with the following distinctions to the
designs of HAWAII or Karim's I-D:

-  HA does not need to be regional-aware (or MAP-aware) as in Karim's
    I-D. The first packets from CN via HA to MN are re-capsulated at GMA
    via possible lower regional routers down to MN's autoconfigured on-link CoA.
    MN can recognize it needs to send a BU to CN from an encapsulated packet
    from CN, encapsulator being the access router. After MN sent a BU with
    alternate CoA to CN, this can start sending route-optimized packets to MN
    via GMA. Inner packet AH is not touched in intermediate routers.
    Packets are forwarded locally in the visited domain and not from HA.
    We can thus do without using an additional routing header with tunneling.

- In our design, most of the data packets are neither tunneled nor
   host-routed (note also that signaling is not tunneled).
   Route-optimized packets towards the MN are forwarded in a special
   way based only on the regional binding cache. Normal processing of
   source-routed packets is skipped if there is a regional binding cache
   entry for the route-optimized home address in the regional CoA router
   receiving the packet. Only IPhdr destination is changed, AH prevails.
   The packet is then just forwarded to the lower CoA as seen in the
   regional binding cache.  Thus, no extra routing state is needed.
   This is much simpler than in Karim's proposal and is quite different
   from IPv4-solutions. Universal route optimization as provided in basic
   Mobile IPv6 is not compromized. Such route optimization is not
   even possible in IPv4 due to its legacy CNs.

- When MN changes link and gets a new address by autoconfiguration
   it performs a regional binding update. This updates the lower CoA as
   seen by GMA or a lower crossover router. The regional binding cache
   can thus direct packets to the new direction, i.e. MN's ability to move is
   not compromized despite the use of address autoconfiguration.
   Those packets that were able to get past the crossover after MN started
   moving and before the crossover received a new regional BU can sometimes
   go to the MN via the simultaneous connection through the old on-link CoA.
   This amounts to no duplication of data packets (bicasting), just a careful
   switching of MN's default route from the old access router to the new one.
   Or, data packets can be buffered by the old router when no simultaneous
   connection is possible, e.g. in "hard handoff" conditions.

- Buffering was provided as one component of the handoff framework where
   our Mobile IPv6 regional registrations is another. Thus, this draft separates
   the problem of location update localization from the handoff state transition
   management.

The smooth handoff framework design, as described by the documents at

http://www.iprg.nokia.com/~charliep/txt/regreg6/regreg6.txt
http://www.iprg.nokia.com/~charliep/txt/smoothv6/smoothv6.txt
http://www.iprg.nokia.com/~charliep/txt/mobilebuf/buffer6.txt
http://www.iprg.nokia.com/~charliep/txt/rohc/hc-ho-draft.txt

> Has this I-D been submitted to IETF?

Yes, with the same procedure & boilerplate as draft-haverinen-reg-paging-00.txt,
Fri Jul/14/00. Curiously, no I-D-Action message resulted.

> Regards,

Best Regards,

-Jari

---

From: Claude Castelluccia <[email-masked]>
Date: Mon, 24 Jul 2000 17:31:52 +0200

Hi Jari,

Your  "Mobile IPv6 Regional Registrations" proposal has a lot of simillarities with
our HMIPv6
proposal (the ID that will be presented in Pittsburg is available on
http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-hmipv6-00.txt
but I am sure
you know our work since you were at IPCN...).
FYI a FreeBSD implementation of HMIPv6 is available since April 2000 on
http://www.inrialpes.fr/planete.

One difference  that I see between our proposals is that in HMIPv6 a MH  configures
its GCoA (this is what you
call regional CoA) by itself
(we make full use of IPv6 functionalties). The access router only advertises the
subnet prefix address of the
MS (this is what you call MGA) instead of a long list of  IPv6 addresses.
Since these router adv. are sent frequently, our proposal  results in a better
utilization of the wireless ressources....

Beside that autoconfiguration solves a lot of problem. In your scheme when a
MH gets a Regional CoA from the
router adv. ,this address has to be removed from the advertised list otherwise you
will have address collision.
This implies to have a protocol between the MGA and the access routers  and results
in higher  registration and
handoff delays..
In HMIP, since the GCoA is build by concatening the MS prefix and EUI64, address
collision is very unlikely
(but the MS verifies the unicity of the address by performing a DaD on its link).
Why don't you use the nice IPv6  autoconfiguration capability?

I have another question: why does a mobile host  send its regionalized BU to the
access router instead of sending it
directly to the closed Regional MA as we do (the RMA address could be advertised in
the router adv.)?
This would  provide more flexibility in the deployement of the Regional-aware
routers (they don't have to be on a tree anymore)...

regards,

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: Gopal Dommety <[email-masked]>
Date: Mon, 24 Jul 2000 09:07:51 -0700

Hello:

On similar lines, we have submitted a draft
(draft-dommety-mobileip-lma-ipv6.txt) on July 14th.
I did not go through the new drafts by Charlie to know the differences. I
did go through the
draft-soliman-mobileip-hmipv6-00.txt. The LMA Draft does talk about the
similarities and
differences between these two drafts.

I am appending the draft below.

Thanks
Gopal

At 05:31 PM 7/24/00 +0200, Claude Castelluccia wrote:
>Hi Jari,
>
>Your  "Mobile IPv6 Regional Registrations" proposal has a lot of
>simillarities with our HMIPv6
><http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-hmipv6-00.txt>http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-hmipv6-00.txt
>but I am sure
><http://www.inrialpes.fr/planete>http://www.inrialpes.fr/planete.
>
>One difference  that I see between our proposals is that in HMIPv6 a
>MH  configures its GCoA (this is what you
>(we make full use of IPv6 functionalties). The access router only
>advertises the subnet prefix address of the
>Since these router adv. are sent frequently, our proposal  results in a
>better utilization of the wireless ressources....
>
>Beside that autoconfiguration solves a lot of problem. In your scheme when
>a MH gets a Regional CoA from the
>router adv. ,this address has to be removed from the advertised list
>otherwise you will have address collision.
>This implies to have a protocol between the MGA and the access
>routers  and results in higher  registration and
>handoff delays..
>In HMIP, since the GCoA is build by concatening the MS prefix and EUI64,
>address collision is very unlikely
>I have another question: why does a mobile host  send its regionalized BU
>to the access router instead of sending it
>directly to the closed Regional MA as we do (the RMA address could be
>advertised in the router adv.)?
>This would  provide more flexibility in the deployement of the
>Regional-aware routers (they don't have to be on a tree anymore)...
>
>regards,
>
>Claude.
>
>
>
>"Jari T. Malinen" wrote:
>>Hi, Bechet,
>>
>><http://www.iprg.nokia.com/~charliep/txt/regreg6/regreg6.txt>http://www.iprg.nokia.com/~charliep/txt/regreg6/regreg6.txt
>>
>><http://www.iprg.nokia.com/~charliep/txt/mobilebuf/buffer6.txt>http://www.iprg.nokia.com/~charliep/txt/mobilebuf/buffer6.txt
>>
><http://www.inrialpes.fr/planete/>http://www.inrialpes.fr/planete/

INTERNET DRAFT                                        Gopal Dommety, Cisco
Category: Standards Track
Title: draft-dommety-mobileip-lma-ipv6-00.txt         Madhavi Subbarao, Cisco
                                                       Raj Patil, Nokia
July 2000

Expires  December 2000

                         Local Mobility Agents in IPv6
                    draft-dommety-mobileip-lma-ipv6-00.txt

Status of this Memo

    This document is a submission by the mobile-ip Working Group of the
    Internet Engineering Task Force (IETF).  Comments should be submitted
    to the [email-masked] mailing list.

    Distribution of this memo is unlimited.

    This document is an Internet Draft and is in full conformance with
    all provisions of Section 10 of RFC2026. Internet Drafts are working
    documents of the Internet Engineering Task Force (IETF), its areas,
    and working groups. Note that other groups may also distribute
    working documents as Internet Drafts.

    Internet Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time. It is inappropriate to use Internet Drafts as reference
    material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

Abstract

  Mobile  IPv6 is better  integrated into  IPv6, thereby  obviating the
need for Foreign Agents  (FA) in IPv6 [5]. In IPv6 most if  not all of the
functions  of the Mobile-IPv4  FA [1] are  assumed by  other parts  of the
Mobile-IPv6  architecture.   Specifically,  all  routers  send  Router
Advertisements and the MN does  its own detunneling and Routing Header
processing.

This draft proposes the concept of Local Mobility Agents (LMA)in
Mobile IPv6 Architecture.  LMA is an optional entity.  The main
advantage is that it enables the feasibility of fast handoffs. The
other advantage is Authentication in Local Domain. The other reason
is that in any commercial operators network you will need a
controlling element for mobile users/stations.

1. Introduction

  Mobile  IPv6 is better  integrated into  IPv6, thereby  obviating the
need for Foreign Agents  (FA) in IPv6. In IPv6 most if  not all of the
functions  of the Mobile-IPv4  FA are  assumed by  other parts  of the
Mobile-IPv6  architecture.   Specifically,  all  routers  send  Router
Advertisements and the MN does  its own detunneling and Routing Header
processing.

This  draft introduces the  concept of  Local  Mobility Agents  (LMA)in
Mobile  IPv6  Architecture.  LMA  is  an  optional  entity.  The  main
advantage of  having LMA  is that it  enables the feasibility  of fast
handoffs  (Similar  to  the   proposal  [4].  The  other  advantage  is
Authentication in Local Domain (Similar to the proposal [14]).

In wide area deployment, the handoff latencies of the current mobileip
could be high. In a mobile  environment, it is very important to limit
the delay experienced  in communication when a mobile  moves from base
station\access point  to another.  Introduction of LMA  in Mobile IPv6
Architecture enables fast handoffs.

1.1 Problem Description

Mobility agents similar to Foreign  Agents in Mobile IPv4 do not exist
in Mobile  IPv6. Although  there is  no need for  such agents  for the
operation  of mobile  IP, in  certain  scenarios they  help solve  the
problem of  Fast Handoffs  and provide a  agent for  Authentication in
local Domain. Other advantages will be discussed later.

A) Handoff: When  a Mobile moves from one subnet  to another the break
in  communication  perceived by  the  user has  to  be  low.  This  is
especially important  for voice applications. Having  a Local Mobility
Agent provides an advantage due to the following reasons:

         1. It    provides   an   option    of   using    LMACoA   (LMA
CareofAddress).  This  eliminates one  round trip  if  using DHCPv6 [6]  or
Autoconfiguration [11] (more than one round trip?) to obtain the COA.

         2. It  introduces  the   possibility  of  performing  handoffs
locally by  performing quick  rerouting. Examples of  such mechanisms
are Local Anchoring [15], Regionalized Tunnels [12], and Proactive
Handoffs[13].
         NOTE:  Fast Handoff  in  the case  where  L2 permits  wireless
  access to  more than one access  point can be  done with simultaneous
  bindings. So, might not need LMAs for this case.

B) Authentication in the local Doamin.  The Mobile has to authenticate to
the Foreign Domain.

C) Other  potential advantages:

2. Solution

2.1 Network Model

The network model being considered is illustrated in Fig 1.

    +----------------------------------+                 +----------------+
    |                        Visited   |                 |                |
    |                        Network   |                 |                |
    |                                  |                 |                |
    |  +------+             +-------+  |                 |    +------+    |
    |  |      |             |       |  |                 |    |      |    |
    |  |  MN  |-------------|  LMA  |-------------------------|HA/CN |    |
    |  |      |             |       |  |                 |    |      |    |
    |  +------+             +-------+  |                 |    +------+    |
    |                                  |                 |                |
    |                                  |                 +----------------+

    |                       +-------+  |
    |                       |  LMA  |  |
    |                       |       |  |
    |                       |       |  |
    |                       +-------+  |
    +----------------------------------+

                         Fig 1: Network Model

An optional entity referred to as LMA has a link layer connectivity to
the Mobile. It is also possible to have an additional LMA without link
layer connectivity to the mobile (Similar to Anchor FA [15] or GFA [12] in
IPv4 or MAP in IPv6).  There are procesing differences between the LMA
if it has link layer connectivity  to the Mobile and the LMA that does
not.

2.2 Enhancements

The neighbor  discovey is proposed to  be enhanced to  send the LMACoA
(Care Of Address) in the router Advertisement message.  Binding Update
is proposed to be enhanced to be  able to send a Binding Update to the
LMA  which is then  relayed to  the destination.  This is  a one-phase
approach by which bindings at the  LMA and the HA/CN can be updated in
one phase. It is also possible  to have a Two-Phase Binding Update. In
this  approach  a Binding  Update  is first  sent  to  the LMA  (Local
Mobility Agent) and Once the Binding Update is accepted by the LMA the
Mobile can  send Biding  updates to HA  (and possibly  CNs). Two-Phase
Binding update may incur higher latency than the one-phase.

2.2.1 Neighbour Discovery Extension

    The LMAs send router advertisements with this following new option.
This is borrowed from Agent Advertisement of Mobile IPv4.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     |        Sequence Number        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Binding      Lifetime      |                  reserved     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                      LMA CoA                                  +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   More LMA Care of Addresses                  |
    +                                                               +

    Fields:

        Type            Message type. To be assigned.

        Length          8-bit unsigned  integer.  The  length in  bytes
                        of the option (including the type and length fields).

       Sequence Number

                The  count of Agent  Advertisement messages  sent since
                the agent  was initialized (Similar  to Sequence number
                in Mobile IPv4).

       LMA CoA  is the address of the  LMA that this mobile  can use as
CoA in its  Binding update. Currently all the LMA  CoA have link layer
connectivty to the Mobile.

TBW (To be Worked on) If there are multiple LMAs on the Link.

2.2.2 Binding Update and Binding Update Acknowledge Usage

In this proposal the Binding Updates are encapsulated Since AH and ESP
are used for Authentication in Mobile IP v6, the actual binding update
between the Mobile Node and  the HA/CN will be encapsulated in binding
update sent  to the LMA.  (Note: only one  binding update needs  to go
through this way,rest  of then can go  to the CNs with the  LMA CoA as
the CoA in the Binding Updte).

                             +----------------------------------//-----+
                             | Original |                              |
                             |          |   Original Packet Payload    |
                             | Header
                             | w BU DH  |                              |
                             +----------------------------------//-----+
                              < Binding Update  between MN and HA/CN  >
                                               |
                                               v
        <Tunnel IPv6 Headers> <       Original Packet                 >
        <with BU DH>
       +---------+ - - - - - +-------------------------//--------------+
       | IPv6    | IPv6      |                                         |
       |         | Extension | Original Packet with Binding Update     |
       | Header  | Headers   |                                         |
       +---------+ - - - - - +-------------------------//--------------+
        <   Binding Update with  the original binding update Tunneled >

            BU: Binding Update
            DH: Destination Header

NOTE: The  Original Binding  Update that is  encapsulated is  a entire
Binding Update  with all the  necessary extensions [5]. Similar  to the
Binding Update Binding Update Acknowledge can also be Tunneled.

   Using this  tunnenling mechanisim a static/dynamic  hierarchy can be
created as required [12][15].

3 Processing Considerations

3.1 Mobile Node

The Mobile Node behaves like a  regular IPv6 mobile IP node when using
the  CoA,ie., Thee Mobile  Node uses  the LMA  CoA as  the CoA  in the
Binding Update. The  Variation is that the CoA is  not a Colocated CoA
but LMA CoA.

The Mobile  Node learns of the  LMA CoA either by  listining to Router
Advertisements or performs Router Solicitation as specified in [].

The Mobile node Sends two Binding Updates one encapsulated in another.

Mobile Node  receives Packets from the  LMA with a  routing header and
Destination  set   to  LMA  CoA   (This  is  a  departure   from  IPv6
Specification).   (In  order to  stay within  the IPv6  specification
tunneling can  be performed.  This  adds an overhead of  an additional
IPv6 header Overhead.)

3.2 Local Mobility Agent

3.2.1 LMA with Link Layer connectivity

Flow with LMA with Link Layer Connectivity

Option 1:

     MN     Advertisement   LMA                     HA/CN
     |<--------------------- |                       |
     | Binding Update        |                       |
     |---------------------->|  Binding Update       |
     |                       |---------------------->|
     |                       |                       |
     |                       |                       |
     |                       |  Binding Ack          |
     |  Binding Ack          |<----------------------|
     |<----------------------|                       |

Option 2:

     MN     Advertisement   LMA                     HA/CN
     |<--------------------- |                       |
     | Binding Update        |                       |
     |---------------------->|  Binding Update       |
     |                       |---------------------->|
     |                       |                       |
     |  Binding Ack          |                       |
     |<----------------------|                       |
     |<----------------------------------------------|

Option 2 will result in lower  latency. In this option, if the Binding
Update Ack  for the encapsulated BU  is received, then  the MN assumes
that the  Binding Update Ack for the  outer BU has been  send but lost
(Can  we ignore  and  assume that  it has  be  received -  Is there  a
security Hole - Do we want to give this as an option in the BU).

If  the First Ack  (for BU  between MN  and LMA)  is received  but the
second Ack  (for BU between  MN and HA/LMA/CN)  is lost then  only the
second BU is sent.

The LMA will send periodic router advertisements as defined in Section
2.2.1 to facilitate neighbor discovery.   If the LMA receives a router
solication  message,   it  will  respond  by  sending   a  LMA  router
advertisement.

When the LMA  receives a Binding Update from a MN,  it checks that the
proper authentication  is present.   If the update  is valid,  the LMA
strips off the tunnel headers and forwards the internal Binding Update
packet to the HA.  It enters the binding update request in its pending
binding update table.

LMA relays the packet  to the
  mobile node.  If the LMA receives the packet
  sends it to the mobile much like a FA in Mobile IPv4
  Architecture.

3.2.2 LMA with out link Layer connectivity

Tunnels the  packet to  the registered CoA  in the Binding  Update. It
additionally  authenticates  the Binding  updates  and sends  tunneled
Binding  Updates/Acknowledgements. This  operation is  similar  to the
operation of  a HA  in IPv6  (The other alternative  is to  change the
Routing Header and  the Destination Header - Need  to Reassemble as IP
Sec assumes a certain  order of the headers).

3.3 Home Agent

Th Home Agent is a regular IPv6 Home Agent.

3.4 Correspondent Node

The Correspondent node also behaves like a regular IPv6 node.

4 How Existing Handoff Proposals for IPv4 apply to IPv6

   To Be Discussed Later

5. How Local Authentication can be performed in IPv6

    To Be Discussed Later

6. Synergies and differences between MAP [4] and this draft

The approach described herein does not require the MN to obtain a
co-located CoA (using either DHCP or Autoconfiguration).  The MN registers
back with the HA using the LMA CoA, and anchors with the LMA as it moves in
foreign domains.  Hence, the latency involved with the MN acquiring a
co-located CoA is avoided.

Since the Binding Update is forwarded to the HA/CN directly by the LMA,
the delay in the MN waiting for a Binding Acknowledgement from the LMA and then
registering back with the HA/CN using the LMA CoA is also avoided.

The reduction in latency will aid in the efficiency of fast handoffs.

6. Security Considerations

Security associations  as specified in [5]  as used to  protect all the
binding update and reply mesages.

7. IANA Considerations

8. References

   [1] C. Perkins.  IP Mobility Support.  Request for Comments
         (Proposed Standard) 2002, Internet Engineering Task Force,
         October 1996.

   [2] S. Deering.  ICMP Router Discovery Messages.  Request for
         Comments (Proposed Standard) 1256, Internet Engineering Task
         Force, September 1991.

   [3] E. Gustafsson, et. al.  Mobile IP Regional Tunnel Management.
       draft-ietf-mobileip-reg-tunnel-01.txt, August 1999.

   [4] H.  Soliman and K. El  Malki, Hierarchical Mobile  IPv6 and Fast
   Handoffs. draft-soliman-mobileip-hmipv6-00.txt, June 2000.

   [5] D. Johnson and C. Perkins, "Mobility Support in IPv6",
          draft-ietf-mobileip-ipv6-10.txt, February 2000.

     [6] Jim Bound and Charles Perkins.  Dynamic Host Configuration
         Protocol for IPv6 (DHCPv6), February 1999.  Work in progress.

     [7] Alex Conta and Stephen Deering.  Generic packet tunneling in
         IPv6 specification.  RFC 2473, December 1998.

     [8] Alex Conta and Stephen Deering.  Internet Control Message
         Protocol (ICMPv6) for the Internet Protocol version 6 (IPv6)
         specification.  RFC 2463, December 1998.

     [9] Stephen E. Deering and Robert M. Hinden.  Internet Protocol
         version 6 (IPv6) specification.  RFC 2460, December 1998.

    [10] Thomas Narten, Erik Nordmark, and William Allen Simpson.
         Neighbor Discovery for IP version 6 (IPv6).  RFC 2461, December
         1998.

    [11] Susan Thomson and Thomas Narten.  IPv6 stateless address
         autoconfiguration.  RFC 2462, December 1998.

    [12] Eva Gustafsson, et. al.  Mobile IP Regional Tunnel Management.
         draft-ietf-mobileip-reg-tunnel-01.txt, August 1999.

    [13] J. Kempf, P. Calhoun, and C. Pairla, Foreign Agent Assisted Hand-off,
         draft-calhoun-mobileip-proactive-fa-01.txt, June 2002

    [14] N.  Asokhan   et.   al,  AAA   for   IPv6  Network   Access,
         draft-perkins-aaav6-00.txt, March 2000.

    [15]  G. Dommety  and T.  Ye, "Local  and Indirect  Registration for
         Anchoring Handoffs",
         draft-dommety-mobileip-anchor-handoff-01.txt(work  in
         progress), July 2000.

Dommety                                                 [Page 4]

Internet Draft

Authors Information

    Gopal Dommety
    Cisco Systems, Inc.
    170 West Tasman Drive
    San Jose, CA 95134
    e-mail: [email-masked]

Notes:

1. Do we need other options of IPv4 adv

2. How does IPv6 MN IP address

3. Do we use constant Src address for IP

4. Route Processing

5. IPv4 tunnels

6. How does the IPv6 Binding update sent?

Appendix:

Three options of sending Binding Updates.

1. Sequential Bindings (Similar to MAP[4])

     MN     Advertisement   LMA                     HA/CN
     |<--------------------- |                       |
     | Binding Update        |                       |
     |---------------------->|
     |  Binding Ack          |
     |<----------------------|                       |

     |---------------------------------------------->|
     |<----------------------------------------------|

The Problem in this case is the Latency.

2. Relay Bindings

     MN     Advertisement   LMA                     HA/CN
     |<--------------------- |                       |
     | Binding Update        |                       |
     |---------------------->|  Binding Update       |
     |                       |---------------------->|
     |                       |                       |
     |                       |                       |
     |                       |  Binding Ack          |
     |  Binding Ack          |<----------------------|
     |<----------------------|                       |

     In this  case MN  sends a binding  update to  LMA and LMA  sends a
     Binding update to HA/CN on behalf  of MN. If the Binding Update is
     required to be Acknowledged, LMA waits  for the BU ack and once it
     receives  it  the  ACK  for   the  Original  BU  from  the  MN  is
     Acked. Security  might be  a problem in  this case, since  the LMA
     sends the Binding Update on the MN's behalf.

3. Encapsulated Binidngs

     MN     Advertisement   LMA                     HA/CN
     |<--------------------- |                       |
     | Binding Update        |                       |
     |---------------------->|  Binding Update       |
     |                       |---------------------->|
     |                       |                       |
     |                       |                       |
     |                       |                       |
     |  Binding Ack          |                       |
     |<----------------------|                       |
     |<----------------------------------------------|

In   this  case   MN  sends   a  BU   to  LMA   with  a   MN-HA/CN  BU
encapsulated. Once the  LMA authenticates the MN, the  LMA relays tthe
BU to HA.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 25 Jul 2000 15:26:51 +0900

Hi Claude,

>Beside that autoconfiguration solves a lot of problem. In your scheme
when a MH gets a Regional CoA from the
>This implies to have a protocol between the MGA and the access routers
and results in higher  registration and
>handoff delays.
I think the same problem exists in mipv4. It is OK, as long as MGA and
FA associate the addresses with the correct and unique
home address.

A comment on your terminology, please change MS it is a widely used
acronym for Mobile Station in cellular networks
(like BS for Base Station, MS for Mobile Station). Also change MH to MN.

>In HMIP, since the GCoA is build by concatening the MS prefix and
EUI64, address collision is very unlikely
>(but the MS verifies the unicity of the address by performing a DaD on
its link).
What if MN moves to GMA link?

Regards,

--
Behcet

---

From: Claude Castelluccia <[email-masked]>
Date: Tue, 25 Jul 2000 11:02:36 +0200

Hi Behcet and thanks for your reply.

Behcet Sarikaya wrote:

> I think the same problem exists in mipv4.

I don't think so. In the regional regist. draft for IPv4, all MNs will use
the  same GCoA that is
in fact the address of the GFA.

In IPv6 (or at least in our proposal), each MN has a different and unique
GCoA (Global CoA).
All these GCoA however belong to the MGA subnet. As a result, since the
GCoA are
different than the MGA address, the MGA can be changed dynamically and
transparently to the HA and CNs
(the MN advertise their GCoA, not the GFA address...). We argue this is
more flexible and robust (for ex.
MGA can be replaced transparently if it crashes., additional MGAs can be
deployed for scalability purpose...)...

> (like BS for Base Station, MS for Mobile Station). Also change MH to MN.

thanks. I'll try to find a better  terminology.

> What if MN moves to GMA link?

 Very good question. There are 2 actually 2 answers:
1- the simplest solution is to prohibit MNs on the GMA link  ...
2-  if MNs are allowed on the GMA link they must then use regular MIPv6 on
this link (we of course allow that).

BTW  the Mobility Network in our a draft is just a "concept" to define a
separate address space for the MNs,
it does not  actually have to be implemented as a LAN.

regards,

Claude.

--

---

From: "Jari T. Malinen" <[email-masked]>
Date: Tue, 25 Jul 2000 12:36:31 -0700

Hi, Claude,

Thanks for your comments, and sorry for not being able to communicate more with
you on the interesting work that you have been providing. Our approach was to get
a simpler, efficient, and secure solution. I think we don't lose too much,
see my comments embedded below..

Claude Castelluccia wrote:

> our HMIPv6 proposal (the ID that will be presented in Pittsburg is available on
> but I am sure you know our work since you were at IPCN...).
> its GCoA (this is what you call regional CoA) by itself
> subnet prefix address of the MS (this is what you call MGA) instead of a long list of
> IPv6 addresses.
> utilization of the wireless ressources...

In fact, you can do quite a small advertisement with our approach. You have the
regional CoA in the advertisement and the access router address in the IPhdr.
In the network-controlled crossover router selection you only need to know the
regional CoA.
The access router knows how to advertise regional addresses (and other capabilities)
so it is naturally regional-aware. The handoff state management, which is
an access router issue, when combined with the IPv6 regional registrations as
in our framework, will make this even more natural.

> MH gets a Regional CoA from the router adv. ,this address has to be removed from
> the advertised list otherwise you will have address collision.
> in higher  registration and handoff delays..

The situation is better since we can share the regional CoA thanks to the regional-
aware data routing (we have the home address as regional forwarding key). We have a
rather fast operation when we don't need to reconfigure a regional-aware CoA at all
under normal operation.

> collision is very unlikely (but the MS verifies the unicity of the address by
> performing a DaD on its link). Why don't you use the nice IPv6  autoconfiguration
> capability?

This is for efficiency reasons, if the GCoA does not usually need to be configured
at all, no delay occurs. However, your comment brings to mind that renumbering
should cause reconfiguration of access router advertisements.
At this moment we limited hierarchy reconfiguration (dynamic knowledge of regional
care-of-addresses, children, and father) out of scope, however. This can be done
with a separate protocol extension for these hopefully infrequent events, including
renumbering.

> access router instead of sending it directly to the closed Regional MA as we do
> (the RMA address could be advertised in the router adv.)?

A region is naturally a hierarchy and in our model the network decides on the
crossover router (the highest guy changing its binding cache and answering to
this BU) thus distributing the signalling load down to the hierarchy. The
communication path per mobile at a time is usually a tree because the root is
anchored, anyway, however, the global structure can be more generic, once you
use many GMAs and MN-controlled selection.

> >    switching of MN's default route from the old access router to the new one.>