Subject: mobility support based on e2e model

From: Fumio Teraoka <[email-masked]>
Date: Fri, 08 Dec 2000 15:06:52 +0900

In the last slot of the thursday ipng session of the Dan Diego
IETF meeting, we give a short talk on "LIN6: Mobility Support
in IPv6 based on End-to-End Communication Model".

i-d is available at the following URL:

   ftp://ftp.csl.sony.co.jp/CSL/tera/draft-teraoka-mobility-lin6-00.txt

LIN6 has several advantages in comparison with Mobile IPv6 as
follows:

   o  LIN6 has no header overhead because it does not use any extension
      headers of IPv6 while Mobile IPv6 uses the Destination Options
      Header for the Home Address Option and the Routing Header.

   o  LIN6 is more fault tolerant than Mobile IPv6.  In Mobile IPv6, the
      Home Agent cannot be replicated to the subnet other than the home
      link of the mobile node.  LIN6 introduces the Mapping Agent which
      can be replicated anywhere in the Internet.

   o  LIN6 keeps end-to-end communication model, that is, LIN6 does not
      use any packet intercepter/forwarder such as the Home Agent of
      Mobile IPv6.  There is no tunneling in LIN6.

Fumio Teraoka
Sony Computer Science Labs., Inc.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 08 Dec 2000 15:59:10 +0900

>   ftp://ftp.csl.sony.co.jp/CSL/tera/draft-teraoka-mobility-lin6-00.txt

	the draft needs to answer number of (IMHO critical) questions,
	including the following.  correct me if i'm wrong about these.
	caveat: i have never used LIN6 myself.

itojun

- scalability.  how will we assign LIN6-ID to people?  if we do it in
  hierarchical manner, what is the expected H ratio for LIN6-ID assignment
  under EUI64/MAC prefix 00-01-4a?  how many nodes are to be supported by
  48bit (or 24bit?) open space in LIN6-ID?
- lack of extensibility in LIN6-ID.  once we ship LIN6 products with
  hardcoded LIN6-ID EUI64/MAC prexix 00-01-4a, we cannot introduce any
  new LIN6-ID prefix.
- header processing order when we use IPsec with LIN6 packet.  we need
  something like draft-ietf-mobileip-ipv6-13.txt section 10.2.  for example,
  - should we lookup SAs with LIN6 generalized ID, or LIN6 address?
  - when should we apply mapping?  is it before AH crypto checksum
    computation or afterwards?
  - processing order in ipsec tunnel cases can be more trickier than
    mobile-ip6 case.
- what are we supposed to do with routing header and other address-in-header?
- apparently we must not advertise LIN6 prefix using RA.
- suppose we have a LIN6-enabled http client, and a LIN6-enabled http
  server.  how can the server send a reply to the client?
  the server will see, on the wire, the following packet:
	src = (network prefix for client, LIN6 ID for client)
	dst = (network prefix for server, LIN6 ID for server)
  tcp layer then sees:
	src = (LIN6 prefix, LIN6 ID for client)
	dst = (LIN6 prefix, LIN6 ID for server)
  tcp layer will reply to the packet with:
	src = (LIN6 prefix, LIN6 ID for server)
	dst = (LIN6 prefix, LIN6 ID for client)
  now, how can the server map (LIN6 prefix, LIN6 ID for client),
  into (network prefix for client, LIN6 ID for client)?
  note that Mapping Agent cannot be used, as we need to know the FQDN
  of the client to know the Mapping Agent for the client.
  if we need to cache every mapping we have seen in inbound processing,
  we need to mention how we need to update Mapping Cache, in
  section 7.2.
  (also note that, the server will never be able to recover the mapping if
  Mapping Cache entry is lost/purged due to starvation, as the server do not
  necessarily have the FQDN of the client!)
- what is the recommended Mapping Cache size?  apparently we need to
  keep the number of possible Mapping Cache entries larger than the number
  of TCP connections.
- behavior of nodes if there's no reachability to the Mapping Agents.
- details about the patent (section 8) and licensing twists.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Fumio Teraoka <[email-masked]>
Date: Fri, 08 Dec 2000 18:52:38 +0900

Itojun,

Thank you for your prompt comments.

>   hardcoded LIN6-ID EUI64/MAC prexix 00-01-4a, we cannot introduce any

00-01-4a is used for just a test of LIN6 on the current IPv6
backbone. Any EUI64 can be used as LIN6-ID. Method for notifying
new OUI for LIN6-ID is under discussion.

>   - should we lookup SAs with LIN6 generalized ID, or LIN6 address?

LIN6 generalized ID.

>     computation or afterwards?

after AH calculation.

>- what are we supposed to do with routing header and other address-in-header?

further study.

>- apparently we must not advertise LIN6 prefix using RA.

That's right.

>   server.  how can the server send a reply to the client?

CN (server) will learn the MA address for MN (client) by reverse
lookup with the generalized ID of MN, and then CN (server) will
learn the current network prefix of MN (client) by query to the MA.
CN does not need to know the FQDN of MN.

>- behavior of nodes if there's no reachability to the Mapping Agents.

further study.

>- details about the patent (section 8) and licensing twists.

futher study :P

Fumio Teraoka

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 09 Dec 2000 01:48:51 +0900

>new OUI for LIN6-ID is under discussion.

	and how do you plan to handle the assignment?
	note that, (1) there are devices without MAC/EUI64 number, (2) there
	are ethernet cards shipped with unique/local bit set to "local" on MAC
	address, (3) there are multiple ethernet cards shipped with exactly
	the same MAC address.  we can't rely upon its worldwide uniqueness.

>CN does not need to know the FQDN of MN.

	how can we manage the reverse lookup table?  it looks close to
	impossible to handle reverse DNS delegation for generalized ID.

itojun

---

From: Fumio Teraoka <[email-masked]>
Date: Sat, 09 Dec 2000 20:54:12 +0900

>         and how do you plan to handle the assignment?

LIN6-ID should be allocated by registries as IP addresses.

>         impossible to handle reverse DNS delegation for generalized ID.

For reverse lookup, LIN6-ID should have hierarchical structure.
If we use upper 24 bits of EUI-64 for hierarchical structure,
we can support 2^48 (= 2.8x10^13) nodes by a single EUI-64. If the
half of the 48-bit space is practically available, 1.4x10^13 nodes
can be supported by a single EUI-64. If a single EUI-64 space is
exhausted, another EUI-64 can be allocated.

Fumio Teraoka

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sun, 10 Dec 2000 00:55:30 +0900

>exhausted, another EUI-64 can be allocated.

	if we do hierarchical LIN6-ID assignment, allocation efficiency will
	follow RFC1715 H-ratio.  if we annotate the table in RFC1715 section 3
	for 48bit case, it should be like follows ("half of the 48-bit space
	is available" looks too optimistic).

	thank you for all the clarifications.

itojun

		    Pessimistic (0.14)     Optimistic (0.26)

      32 bits             3 E+4 (!)           2 E+8
      48 bits		  5 E+6		      3 E+12	<--
      64 bits             9 E+8               4 E+16
      80 bits           1.6 E+11            2.6 E+20	<-- RFC has a typo
     128 bits             8 E+17              2 E+33

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 13 Dec 2000 10:40:39 +0859 ()

itojun;

> 	follow RFC1715 H-ratio.

No, not at all. ID space needs no hierarchy for routing nor allginment
for CIDR.

The space will have a few levels of organizaional hierarchy (say,
country/local_goverment/site). In each level, assignments can be
tighntly packed and returned ID may be filled.

All such points were discussed in my draft <draft-ohta-ipv6-addr-arch-00.txt>
in March 1995.

							Masataka Ohta

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 13 Dec 2000 16:19:16 +0900

>tighntly packed and returned ID may be filled.

	well, if you assign it hierarchical manner, you cannot pack it that
	well.  imagine:
	- a company asks for IDs,
	- one-layer-up entity assigns it 8 bit space (for 256 machines),
	- the company actually has only 200 machines and 56 IDs are wasted.
	the situation looks exactly the same as the current IPv4 assignment.

itojun

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 13 Dec 2000 19:35:40 +0859 ()

itojun;

> 	- a company asks for IDs,

OK.

> 	- one-layer-up entity assigns it 8 bit space (for 256 machines),

Huh?

> >No, not at all. ID space needs no hierarchy for routing nor allginment

There is no need to make the figure a power of 2.

> 	- the company actually has only 200 machines and 56 IDs are wasted.

If the company request 200 IDs, the one-layer-up entity can delegate
exactly 200 IDs.

Or, if the the one-layer-up entity think 200/256 large enough (I think
this is the case), it can delegate 256 IDs.

> 	the situation looks exactly the same as the current IPv4 assignment.

No.

Read the following sentense, again and again.

> >No, not at all. ID space needs no hierarchy for routing nor allginment
                                                               ^^^^^^^^^^
> >for CIDR.
   ^^^^^^^^^

							Masataka Ohta

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 14 Dec 2000 00:17:11 +0900

>this is the case), it can delegate 256 IDs.

	well, think about reality.  can you really handle ID assignment
	requests, if they do not ask for ID by bulk?  it was my mistake that
	I implied 2^n boundary, it was not my intention.  what I was trying to
	mean was that there will be lots of wasted space.

itojun

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 14 Dec 2000 02:34:42 +0859 ()

itojun;

> 	requests, if they do not ask for ID by bulk?

The reality is that we have a lot of IDs (social security number in
US, for example) assigned individually.

As I mentioned, a local goverment would ask country for IDs by bulk.

>  it was my mistake that

Where can I see "lots of wasted space" in your example?

If you are saying an abstract nonsense that any scheme can be used unwisely
to waste a lot of space, you are right.

							Masataka Ohta

---

From: "Faisal Al-Jundi" <[email-masked]>
Date: Wed, 13 Dec 2000 16:43:13 +0400

Hi,

I'm new here.

I just want to ask a question.

All of us know that all networking companies running to wireless technology,
and as I understand there is lot of electronic machines will have IPv6
address in the future like TV, ....etc. and the most important is the Future
GSM, if all mobiles have IPv6 address so we can not think about hierarchy
levels at all. Also PALM. because if I travel with my mobile from one
country to another, I need a roaming in current technology, but in the
future there is no roaming I think there will be like just register this
IPv6 address with Telco. company in the  country i went and it maybe
automatically because of new features in the IPv6 [auto addressing]!!.

I just ask because I dont have a complete answer for this.

Regards

Faisal Al-Jundi

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Masataka Ohta
Sent: Wednesday, December 13, 2000 2:37 PM
To: Jun-ichiro itojun Hagino
Cc: Fumio Teraoka; [email-masked]
Subject: Re: mobility support based on e2e model

itojun;

OK.

Huh?

No.

                                                               ^^^^^^^^^^
   ^^^^^^^^^

							Masataka Ohta

---

From: Hiroshi ESAKI <[email-masked]>
Date: Thu, 14 Dec 2000 03:01:57 +0900

Hi, 
just a clarification, regarding the I-D 
(draft-teraoka-mobility-lin6-00.txt), though we will try
to mention briefly in the presentation on Thu session. 
LIN6 is not only focusing on the wireless and mobility, 
rather trying to solve some technological issues (e.g.,
multihoming) around us. 
regards,
Hiroshi Esaki

> > >No, not at all. ID space needs no hierarchy for routing nor allginment

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

Hiroshi ESAKI, Ph.D 
 Associate Professor, Information Technology Center,
 University of Tokyo,  
 2-11-16 Yayoi, Bunkyo-ku, 
 Tokyo, 113-8658, Japan. 
 Email   [email-masked] 
 TEL: +81-3-5684-7303 
 FAX: +81-3-5684-7775 
 http://www.itc.u-tokyo.ac.jp 
 http://hiroshi1.nc.u-tokyo.ac.jp/hiroshi/index.html