One document matched: draft-wakikawa-nemo-v4tunnel-00.txt
MIP6 Working Group Ryuji Wakikawa
INTERNET DRAFT Keio Univ./WIDE
Category: Personal Carl E. Williams
10 Jun 2004 KDDI Labs USA
Keisuke Uehara
Keio Univ./WIDE
IPv4 Care-of Address Registration
draft-wakikawa-nemo-v4tunnel-00.txt
Status of This Memo
This document is a submission to the MIP6 Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the mip6@ietf.org (mobile-ip@sunroof.eng.sun.com) 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 its 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
On the Internet, two different IP protocols are deployed such as
IPv4 [8] and IPv6 [2]. The Mobile IPv6 Router uses the basic NEMO
protocol [3] which is IPv6 protocol specific. During the early
period of time that IPv6 transition is occurring it is very likely
that a Mobile IPv6 router will move to an IPv4 only access network.
When this occurs the Mobile IPv6 Router will no longer be able to
operate using the basic NEMO protocol. There has already been some
earlier work to provide IPv6 capability over an IPv4 access network
for a Mobile IPv6 Router [see [10] [11]]. This draft provides a
capability by to maintain IPv6 connectivity for the Mobile IPv6
R. Wakikawa et.al. Expires 10 Dec 2004 [Page 1]
Internet Draft The Basic Nemo on IPv4 10 Jun 2004
Router via its Home Agent with IPv4-in-IPv6 encapsulation with no
special boxes to be deployed elsewhere in the network.
Contents
Status of This Memo 1
Abstract 1
1. Introduction 3
2. Terminology 3
3. Protocol Overview 4
4. Mobile IPv6 Extensions 5
4.1. IPv4 Care-of Address sub-option . . . . . . . . . . . . . 5
4.2. Binding Update . . . . . . . . . . . . . . . . . . . . . 6
4.3. Binding Acknowledgment . . . . . . . . . . . . . . . . . 7
5. Home Agent Address Discovery 7
6. IPv4 Care-of Address Registration 8
6.1. Sending Binding Update . . . . . . . . . . . . . . . . . 8
6.2. Receiving Binding Update . . . . . . . . . . . . . . . . 9
6.3. Sending Binding Acknowledgment . . . . . . . . . . . . . 10
6.4. Receiving Binding Acknowledgment . . . . . . . . . . . . 10
6.5. IPv4 forwarding Setup . . . . . . . . . . . . . . . . . . 10
7. Applicability to Mobile IPv6 11
References 11
Authors' Addresses 12
R. Wakikawa et.al. Expires 10 Dec 2004 [Page 2]
Internet Draft The Basic Nemo on IPv4 10 Jun 2004
1. Introduction
The basic NEMO protocol [3] is currently being standardized at IETF
and is ready for the deployment phase with high interest on the
Internet.
However, the current Internet is based on both IPv4 and IPv6 network
and we cannot assume that IPv6 networks will be deployed everywhere.
To provide the functionality of a Mobile IPv6 Router in a wireless
system, IPv6 support is required in the architecture of the wireless
access networks. This is because the Mobile IPv6 is not protocol
independent. IPv6 was designed with an integrated support for Mobile
IP as native IPv6 feature. As such Mobile IPv6 and the Basic NEMO
protocol for Mobile Routers is designed to use the rich feature set
of IPv6; hence, there exist a tight coupling of mobility signaling
and IPv6 used in the media plane.
Operation of Mobile IPv6 Router would not be guaranteed since that
also depends on the IPv6 capabilities of the networks the Mobile
IPv6 Router is visiting i.e.: a Mobile IPv6 Router attempting to
connect via a IPv4 only network would not be able to maintain IPv6
connectivity.
There are earlier works at the IETF MIP6 working group such as ``
Dual Stack Mobile IPv6``[10] and ``Doors'' [11]. The features of
this proposal are listed below:
- using variety of tunnels between Mobile Router and Home Agent.
Possible tunnel types are IPv4-IPv6, and UDP/IPv4-IPv6 for NAPT
address.
- Doing de-registration for regular binding when a Mobile Router
visits an IPv4 network. This leads an advantage of reducing
tunnel header between Mobile Router and Home Agent [1] [5] [3],
which is not negligible.
2. Terminology
Home Agent IPv4 Address
A Home Agent MUST have an IPv4 global address for IPv4
care-of address registration.
IPv4 Care-of Address
is an IPv4 address. This address is acquired by a Mobile
Router through any address configuration mechanism such as
DHCP, when the Mobile Router visits an IPv4 only network.
R. Wakikawa et.al. Expires 10 Dec 2004 [Page 3]
Internet Draft The Basic Nemo on IPv4 10 Jun 2004
IPv4 Care-of Address Registration
A Mobile Router registers its IPv4 Care-of address bound
to the IPv6 Home Address to a Home Agent.
IPv4 Forwarding
IPv4 forwarding for all Mobile Network Prefixes of the
basic NEMO protocol. The IPv4 forwarding is enable to
minimalizes tunnel overhead of IPv6-IPv6 [1] encapsulation
for packets meant for Mobile Network Prefixes.
3. Protocol Overview
When a Mobile Router visits an IPv4 only network, it uses IPv4
address as its Care-of address to tunnel packets between the Mobile
Router and the Home Agent. This operation is called IPv4 Care-of
Address Registration.
While a Mobile Router lives in IPv6 network, it acquires Home Agent
IPv4 addresses with extended Dynamic Home Agent Address Discovery
operations. Whenever the Mobile Router moves into an IPv4 only
network, it gets an IPv4 address and sends an extended Binding
Update with new IPv4 Care-of Address sub-option to the Home Agent
IPv4 address by using IPv4-in-IPv6 encapsulation. In the outer
IPv4 header, the source address is a Mobile Router's IPv4 Care-of
address and the destination address is the Home Agent IPv4 address.
In the inner IPv6 header, the source address is a Mobile Router's
Home Address and the destination address is Home Agent address. The
Binding Update requests to delete the regular binding cache for the
Mobile Router. But then, IPv4 address is stored in the IPv4 Care-of
Address sub-option and can be used to setup IPv4 forwarding on behalf
of regular forwarding on the basic NEMO protocol. The Mobile Router
MUST NOT set zero lifetime in the Binding Update, but it MUST set the
lifetime for the IPv4 Care-of Address. The Mobile Router creates
Binding Update with 'I' flag set and processes IPsec for the Binding
Update as described in [5].
When the Home Agent receives the Binding Update, it first disables
or removes the regular binding cache and sets up IPv4 forwarding
which is an IPv4-IPv6 tunnel for the Mobile Router's Home Address and
Mobile Network Prefixes. This draft supports various kinds of tunnel
methods such as Generic IP Encapsulation [9], GRE tunneling [4],
IPsec tunneling [7] [6], and UDP tunneling for NAPT address. These
tunnel method is specified in the IPv4 Care-of Address sub-option.
The Home Agent MUST reply a Binding Acknowledgment with an IPv4
Care-of Address sub-option to the Mobile Router's IPv4 Care-of
address by using IPv4 forwarding.
R. Wakikawa et.al. Expires 10 Dec 2004 [Page 4]
Internet Draft The Basic Nemo on IPv4 10 Jun 2004
After getting successful Binding Acknowledgment, the Mobile Router
forwards all packets meant to the Internet from its Mobile Networks
to Home Agent IPv4 address by using IPv4-in-IPv6 encapsulation.
Without our proposal, the double encapsulation such as
IPv4-in-IPv6-in-IPv6 tunnel is occurred. By using IPv4
forwarding, the basic NEMO protocol can reduce one IPv6 header which
is used for regular forwarding.
4. Mobile IPv6 Extensions
4.1. IPv4 Care-of Address sub-option
The IPv4 Care-of Address sub-option is included in Binding Update and
Binding Acknowledgment.
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 = TBD | Length = 4 |
+-+-+-+-+-----------------------+-------------------------------+
|I|R|S|U| Reserved | Port Number |
+-+-+-+-+-----------------------+-------------------------------+
| IPv4 Care-of Address |
+---------------------------------------------------------------+
Type
Type value for Binding Unique Identifier will be assigned
later.
Length
The value MUST be always 4.
Flag
Generic IP in IP Encapsulation tunnel (I) Flag
When this flag is set, the home agent MUST use
Generic Encapsulation tunneling for IPv4-IPv6
encapsulation.
GRE tunnel (R) Flag
When this flag is set, the home agent MUST use GRE
tunneling for IPv4-IPv6 encapsulation.
R. Wakikawa et.al. Expires 10 Dec 2004 [Page 5]
Internet Draft The Basic Nemo on IPv4 10 Jun 2004
IPsec tunnel (S) Flag
When this flag is set, the home agent MUST use IPsec
tunneling for IPv4-IPv6 encapsulation.
UDP tunnel (U) Flag
When this flag is set, the home agent MUST use the
Port value for UDP tunneling to go through NAPT.
Reserved
Reserved field must be set with all 0.
Port Number
A port number which is used for UDP-IP tunnel to traverse
NAPT.
IPv4 Care-of Address
The IPv4 Care-of Address field contains an IPv4 address of
a mobile router.
4.2. Binding Update
If a mobile node wants to register IPv4 care-of addresses which would
be bound to a IPv6 home address, mobile node MUST set 'I' flag and
include a IPv4 Care-of Address sub-option.
When a mobile router sends a Binding Update with I flag set, the
source address of IPv6 header is the Home Address of the mobile
router. The Binding Update is always encapsulated by IPv4 to Home
Agent IPv4 Address.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|R|I| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 support flag (I)
This flag is used for IPv4 care-of address registration.
R. Wakikawa et.al. Expires 10 Dec 2004 [Page 6]
Internet Draft The Basic Nemo on IPv4 10 Jun 2004
Reserved
Reserved field is reduced to 11 bits.
Lifetime
Lifetime for IPv4 Care-of Address stored in a IPv4 Care-of
Address sub-option.
4.3. Binding Acknowledgment
The message format of Binding Acknowledgment is not changed,
but operations listed below are added for IPv4 care-of address
registration.
If a Binding Update has 'I' flag and an IPv4 Care-of Address
sub-option is present, a receiver node MUST reply a Binding
Acknowledgment containing an appropriate IPv4 Care-of Address
sub-option. If the requesting tunnel method is not supported by a
Home Agent, the Home Agent MUST reply with the status code ``Tunnel
Method is not valid''. In such case, the Home Agent can set the flag
of tunnel methods which Home Agent currently support. This is useful
when a Mobile Router decides the tunnel method from available methods
at a Home Agent.
This document defines a new number for 'I' flag handling.
TBD Tunnel Method is not valid
When a receiver is somehow legacy Home Agent and can not process an
IPv4 Care-of Address sub-option, it de-registers the binding and
returns a Binding Acknowledgment to the Home Address. However,
the legacy Home Agent can not resolve Neighbor Discovery Cache
for the Home Address and can not send it to the link, because the
sender (i.e. Mobile Router) is not at the home link. In such
case, the sender (i.e. Mobile Router) can not receive the Binding
Acknowledgment at the visiting network. If the Mobile Router can not
receive any Binding Acknowledgment after sending multiple Binding
Updates with an IPv4 Care-of Address sub-option, it MUST stop IPv4
Care-of Address Registration. Note that, Mobile Router basically
does not send such Binding Updates to legacy Home Agent because
of extended Home Agent Address Discovery mechanism described in
Section 5.
5. Home Agent Address Discovery
A Mobile Router MUST acquire Home Agent IPv4 address. Dual Stack
Mobile IPv6[10] has already proposed mechanism for this. However,
R. Wakikawa et.al. Expires 10 Dec 2004 [Page 7]
Internet Draft The Basic Nemo on IPv4 10 Jun 2004
this draft is not aimed to use an IPv4 Home Address on Mobile Router,
we slightly extended the Dynamic Home Agent Address Discovery.
When a Mobile Router requests lists of Home Agents, it sends Dynamic
Home Agent Address Discovery Request to Home Agent anycast address.
In that time, the Mobile Router can set ``I'' flag in the message.
The Home Agent who received the request with I flag set MUST contain
Home Agent IPv4 address if its available.
It is important to acquire Home Agent's IPv4 addresses from IPv6
network. When a Mobile Router moves to IPv4 only network, it can't
acquire Home Agent addresses from IPv4 network.
A Mobile Router maintain the Home Agent's IPv4 address as same as
Home Agent IPv6 address in the home agent list.
6. IPv4 Care-of Address Registration
6.1. Sending Binding Update
When a Mobile Router lost its IPv6 Care-of Address at a visiting
network, it can register available IPv4 addresses as its IPv4 Care-of
Address to a Home Agent.
The packet sent from a Mobile Router is shown in Figure 1.
From the view of the Basic Nemo Protocol, this Binding Update is
treated as de-registration Binding Update. A Mobile Router sets I
flag in the Binding Update with an IPv4 Care-of Address sub-option
in the Binding Update and tunnels the Binding Update to a Home Agent
IPv4 address. Although the Mobile Router sets its Home Address
as the Source Address field of the inner IPv6 header, it MUST set
appropriate lifetime value to the Lifetime filed of Binding Update.
The Mobile Router MUST NOT set zero lifetime for the IPv4 Care-of
Address Binding Update.
IPv4 header IPv6 Header HoA Dest Option Mobility Header
+---------------+---------------+-----------+------------------------+
| SRC: IPv4-CoA | SRC: MR-HoA | MR HoA | Binding Update w/ |
| DST: IPv4-HA | DST: HA | | I flag and sub-options |
+---------------+---------------+-----------+------------------------+
Figure 1: Binding Update for IPv4 Care-of Address
R. Wakikawa et.al. Expires 10 Dec 2004 [Page 8]
Internet Draft The Basic Nemo on IPv4 10 Jun 2004
The following sub-options are required for IPv4 Care-of Address
registration
- Alternate Care-of Address Sub-option
set a Mobile Router's Home Address
- IPv4 Care-of Address Sub-option
set a Mobile Router's Care-of Address
- Mobile Network Prefix Sub-option
set a Mobile Router's Mobile Network Prefix
6.2. Receiving Binding Update
If a Binding Update does not contain an IPv4 Care-of Address
sub-option and it does not have 'I' flag set, the processing of
the Binding Update is same as [5]. But if the receiver maintains
IPv4 forwarding, it MUST discards the IPv4 forwarding and creates a
binding cache entry for the new IPv6 Care-of Address as described
in [5] and [3].
On the other hand, if a Binding Update contains an IPv4 Care-of
Address sub-option, or 'I' flag set, a receiver node MUST operate
additional validations as follows.
- If the Binding Update has 'I' flag at the Flag field, an IPv4
Care-of Address sub-option MUST be present in Mobility options
field of the Binding Update. Otherwise, the receiver node MUST
silently drop the Binding Update.
- If the lifetime field of the Binding Update is set to zero, the
receiver MUST ignore the Binding Update. When the I flag is set,
the lifetime field indicates the lifetime value for IPv4 Care-of
Address.
- If the requested tunnel type is not supported by the
receiver node, the Binding Update is discarded and a Binding
Acknowledgment with [TBD] (Tunnel method is not valid) MUST be
replied to the sender Mobile Router.
After successfully processing the Binding Update, the Home Agent
MUST create IPv4 forwarding for the Mobile Router's Home Address and
the Mobile Network Prefixes. The Home Agent MUST returns a Binding
Acknowledgment with the correspondent IPv4 Care-of Address sub-option
to the Mobile Router.
R. Wakikawa et.al. Expires 10 Dec 2004 [Page 9]
Internet Draft The Basic Nemo on IPv4 10 Jun 2004
6.3. Sending Binding Acknowledgment
Whenever a Home Agent sends a Binding Acknowledgment for IPv4 Care-of
Address registration, it MUST contain the received IPv4 Care-of
Address sub-option.
Only when the Home Agent sends a Binding Acknowledgment with status
code [TBD] (Tunnel method is not valid) set, it SHOULD modified the
Flag field of IPv4 Care-of Address sub-option according to supporting
tunnel methods by the Home Agent. After receiving the Binding
Acknowledgment, the Mobile Router MAY retry to create IPv4 forwarding
according to supported tunnel method.
6.4. Receiving Binding Acknowledgment
When a Mobile Router receives a Binding Acknowledgment, it MUST
verify whether the Binding Acknowledgment has an IPv4 Care-of Address
sub-option or not. If the sub-option is not available, it can retry
sending a Binding Update with an IPv4 Care-of Address sub-option.
However, the Mobile Router SHOULD stop sending the Binding Update
at some point, because the Home Agent MAY NOT support IPv4 care-of
Address Registration.
Once a Mobile Router receives Binding Acknowledgment with a
successful status code, it MUST creates IPv4-IPv6 tunnel with its
Home Agent IPv4 address. The tunnel source address is a IPv4 Care-of
Address of Mobile Router and the tunnel destination address is a Home
Agent IPv4 address. All packets originated from a Mobile Network is
routed to the tunnel using the tunnel method which is recorded into
the Flag field of the IPv4 Care-of Address sub-option.
If a Mobile Router receives the status code [TBD] (Tunnel Method is
not valid), it MUST re-select the tunnel method from the received
IPv4 Care-of address sub-option and re-registers its IPv4 Care-of
Address to the Home Agent.
6.5. IPv4 forwarding Setup
When a Home Agent processes a Binding Update successfully, it setup
IPv4 forwarding according to the Flag field of IPv4 Care-of Address
sub-option.
There are several types of tunnel such as GRE tunnel, Generic
Encapsulation (IPv4-IPv4) tunnel, IPsec tunnel, UDP-IPv4 tunnel for
NAPT.
R. Wakikawa et.al. Expires 10 Dec 2004 [Page 10]
Internet Draft The Basic Nemo on IPv4 10 Jun 2004
When IPsec tunnel is selected, the Home Agent MUST establish Security
Association with the Mobile Router. When UDP tunnel flag is set, the
Home Agent creates UDP-IPv4 tunnel with the specified port number in
the IPv4 Care-of Address sub-option.
Mobile Router also setup IPv4 forwarding after accepting a Binding
Acknowledgment with success status code. The procedure to setup IPv4
forwarding is same as Home Agent.
7. Applicability to Mobile IPv6
Our mechanism can be applied to Mobile IPv6 as well. However, Mobile
IPv6 uses Proxy Neighbor Discovery to intercept packets at the Home
Agent. Therefore, after de-registering the regular binding cache
entry, the Home Agent still defends the Home Address to intercept
packets meant for the Home Address by Proxy Neighbor Discovery. Once
the Home Agent intercept packets by Proxy Neighbor Discovery, the
Home Agent forwards packets to Mobile Node's IPv4 Care-of Address by
IPv4 forwarding.
For the Correspondent Node, the Mobile Node MUST de-register its
binding cache by sending a Binding Update via Home Agent. The Mobile
Node tunnels the Binding Update to Home Agent IPv4 address by IPv4
forwarding and the Home Agent deliver the Binding Update to each
Correspondent Node. It means route optimization can not be used
while the Mobile Node locates in IPv4 network.
References
[1] A. Conta and S. Deering. Generic Packet Tunneling in IPv6
Specification. Request for Comments (Proposed Standard) 2473,
Internet Engineering Task Force, December 1998.
[2] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6)
Specification. Request for Comments (Draft Standard) 2460,
Internet Engineering Task Force, December 1998.
[3] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert. Nemo
Basic Support Protocol (work in progress). Internet Draft
(draft-ietf-nemo-basic-support-02), Internet Engineering Task
Force, December 2003.
[4] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing
Encapsulation (GRE). Request for Comments (Informational) 1701,
Internet Engineering Task Force, October 1994.
R. Wakikawa et.al. Expires 10 Dec 2004 [Page 11]
Internet Draft The Basic Nemo on IPv4 10 Jun 2004
[5] D. Johnson, C. Perkins, and J. Arkko. Mobility
support in IPv6 (work in progress). Internet Draft,
(draft-ietf-mobileip-ipv6-24.txt), Internet Engineering Task
Force, June 2003.
[6] S. Kent and R. Atkinson. IP Encapsulating Security Payload
(ESP). Request for Comments (Proposed Standard) 2406, Internet
Engineering Task Force, November 1998.
[7] S. Kent and R. Atkinson. Security Architecture for the Internet
Protocol. Request for Comments (Proposed Standard) 2401,
Internet Engineering Task Force, November 1998.
[8] J. Postel. Internet Protocol. Request for Comments (Standard)
791, Internet Engineering Task Force, September 1981.
[9] W. Simpson. IP in IP Tunneling. Request for Comments
(Informational) 1853, Internet Engineering Task Force, October
1995.
[10] T. Soliman and G. Tsirtsis. Dual Stack Mobile IPv6 (work in
progress). Internet Draft (draft-soliman-v4v6-mipv4-00.txt),
Internet Engineering Task Force, August 2003.
[11] P. Thubert, P. Molteni, and P. Wetterwald. IPv4 traversal for
MIPv6 based Mobile Routers (work in progress). Internet Draft
(draft-thubert-nemo-ipv4-traversal-01.txt), Internet Engineering
Task Force, May 2003.
Authors' Addresses
Ryuji Wakikawa
Keio University and WIDE
5322 Endo Fujisawa Kanagawa
252 JAPAN
Phone: +81-466-49-1394
EMail: ryuji@sfc.wide.ad.jp
Fax: +81-466-49-1395
Carl E. Williams
KDDI Labs USA
Palo Alto, CA 94301
USA
Phone: +1.650.279.5903
EMail: carlw@kddilabs.com
R. Wakikawa et.al. Expires 10 Dec 2004 [Page 12]
Internet Draft The Basic Nemo on IPv4 10 Jun 2004
Keisuke Uehara
Keio University and WIDE
5322 Endo Fujisawa Kanagawa
252 JAPAN
Phone: +81-466-49-1394
EMail: kei@wide.ad.jp
Fax: +81-466-49-1395
R. Wakikawa et.al. Expires 10 Dec 2004 [Page 13]
Internet Draft The Basic Nemo on IPv4 10 Jun 2004
Full Copyright Statement
``Copyright (C) The Internet Society (year). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.''
``This document and the information contained herein are provided
on an ``AS IS'' basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.''
(See RFC 3667 sections 5.4 and 5.5.)
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
R. Wakikawa et.al. Expires 10 Dec 2004 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 13:34:40 |