>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
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 PROTECTED]
--------------------------------------------------------------------
