Internet DRAFT - draft-yang-softwire-netlmm-v4netlmm6v4
draft-yang-softwire-netlmm-v4netlmm6v4
MIP6 Working Group P. Yang
Internet-Draft H. Deng
Expires: December 21, 2006 Hitachi (China)
June 19, 2006
IPv4/netlmm6/IPv4
draft-yang-softwire-netlmm-v4netlmm6v4-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
NETLMM6 may be widely deployed in the 3G network. But currently,
most of the mobile hosts are IPv4 nodes without any Mobile IPv4/IPv6
stacks. This document proposes the solution to enable the IPv4 hosts
to obtain the network connection and set up IPv4 sessions over
NETLMM6 network. Extensions and option are added to proxy Mobile
IPv6 allowing for single IPv4 stack hosts to access kind of IPv6
network. The IPv4 Address could be maintained constantly in the
domain of NETLMM6.
Yang & Deng Expires December 21, 2006 [Page 1]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. conventions used in this document . . . . . . . . . . . . . . 6
3. overview of this solution . . . . . . . . . . . . . . . . . . 7
3.1. definition of the messages . . . . . . . . . . . . . . . . 7
3.1.1. Proxy BU for IPv4 Mobile Station . . . . . . . . . . . 7
3.1.2. Proxy BA for IPv4 Mobile Station . . . . . . . . . . . 8
3.1.3. IPv4 Home Address (HoA) option . . . . . . . . . . . . 8
3.2. registration procedure . . . . . . . . . . . . . . . . . . 9
3.3. error code . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. packet forwarding . . . . . . . . . . . . . . . . . . . . 12
4. mobile station consideration . . . . . . . . . . . . . . . . . 13
4.1. Address configuration . . . . . . . . . . . . . . . . . . 13
5. Dual-stack Mobility Proxy Agent consideration . . . . . . . . 14
5.1. maintenance of the visitor list . . . . . . . . . . . . . 14
5.2. DHCP consideration . . . . . . . . . . . . . . . . . . . . 15
5.3. ARP consideration . . . . . . . . . . . . . . . . . . . . 15
5.4. ICMP consideration . . . . . . . . . . . . . . . . . . . . 15
6. Dual-stack Local Mobility Anchor Point consideration . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Yang & Deng Expires December 21, 2006 [Page 2]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
1. Introduction
Mobile IPv6 protocol [RFC3775] enables mobile stations to move within
the IPv6 Internet while persisting the retaining the reachability and
session continuity.
However, there are many devices which do not have mobile IP
functionality and could not support IPv4/IPv6 dual stack. For
instance, currently most of the cellular phone or WLAN phone could
only support IPv4 stack without mobile IP functions. With the growth
of IPv6 network deployment, it is possible to assume that IPv4 mobile
stations will need the internet access through NETLMM6 network.
In Softwire [Dawkins06], there is the transition requirement on IPv4
accross IPv6 network. IPv4 hosts connectivity over IPv6 network is
one of the important scenarios for traversal of networks with
differing address familities. The solution in this document enables
IPv4 hosts to access kind of IPv6 network. At the edge of the IPv6
network, the dual-stack mobility proxy agent (DMPA) is responsible
for the network access registration and packet forwording of the IPv4
hosts. The IPv4 hosts will be kept intact.
And, Enabling unmodified mobile nodes is one of the targets of
Localized obility Management (NETLMM)[Kempf06b]. This could be able
to help the service providers to support as many customers as
possible. The other benefits includes decreasing the Update latency,
saving the Signaling overhead over the air, Protecting the location
privacy of mobile hosts.[Kempf06] The solution in this document could
support the roaming of unmodified IPv4 mobile nodes within the
localized Mobile IPv6 domain.
Proxy Mobile IPv6 [PMIP6] provides the solution to support the
unmodified IPv6 mobile nodes within NETLMM domain. This specifiction
extends Proxy Mobile IPv6 to enable the unmodified IPv4 mobile
stations to access the NETLMM domain by introducing a dual-stack
mobility proxy agent (DMPA). Figure1 shows an example of providing
the network access to IPv4 Mobile stations in IPv6 NETLMM domain.
Similar to Proxy Mobile IPv6, DMPA will register to Dual-stack Local
Mobility Anchor Point (DLMAP),which functions as a local Home Agent,
on behalf of mobile stations. A IPv4 over IPv6 tuunel is set up
between DMPA and LMAP for traffic from and to the mobile stations.
DMPA should support IPv4/IPv6 dual stack and be responsible for the
network access of IPv4 mobile station. LMAP should support IPv4/IPv6
dual stack to intercept data traffic for a Mobile Station.
Yang & Deng Expires December 21, 2006 [Page 3]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
+----------+
| IPv4 Host|
+----------+
Internet |
-------------------------+-----------------------------------------
NETLMM domain +----+ | +----+
|AAA |-----|DHCP|
+----+ | +----+
|
/ \
/ | \
/ | \
/ | \
/ | \
/ | \
+-----+ +-----+ +-----+
|DLMAP| |DLMAP| |DLMAP|
+-----+ +-----+ +-----+
/ \ / \ / \
/ \ / \ / \
+-----+ +-----+ +-----+ +-----+
|DMPA | |DMPA | |DMPA | |DMPA |
+-----+ +-----+ +-----+ +-----+
/ \ / \ / \ / \
/ \ / \ / \ / \
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
|BS| |BS| |BS| |BS| |BS| |BS| |BS| |BS|
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
| |
/:\ /:\
: :
: :
+-------+ +-------+
|IPv4 MS| |IPv4 MS|
+-------+ +-------+
Figure 1: IPv4 Mobile stations in NETLMM domain
After mobile station has successfully registered on DLMAP, All the
packets sent to the mobile node's IPv4 home address should be
intercepted by DLMAP and be tunneled to DMPA. DMPA will decapsulate
the IPv6 tunnel packet and send the inner IPv4 packet to the mobile
station directly. The mobile station does not need to do any tunnel
encapsulation or decapsulation to send/receive IPv4 packets.
In this solution, mobile station's upper layer can not detect its
movement. DMPA shall register the location on DLMAP, which makes the
Yang & Deng Expires December 21, 2006 [Page 4]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
mobile station believe that it remains on the same network.
Yang & Deng Expires December 21, 2006 [Page 5]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
2. conventions used in this document
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [RFC2119].
The following new terminology and abbreviations are introduced in
this document and all the other general mobility related terms as
defined in [RFC3775] and [PMIP6].
Dual-stack Mobility Proxy Agent (DMPA)
The dual stack Mobile IPv6 function that offers proxy mobility
services for IPv4 mobile stations.
Mobile Station
Any IPv4 node that has the ability to access to different
networks. It does not have mobile IP protocol stack.
Dual-stack Local Mobility Anchor Point (DLMAP)
The dual-tack mobile IP entity which functions as a local Home
Agent to intercept data traffic for both IPv4 and IPv6 Mobile
Station.
IPv4 Home Address Option
The Mobile IPv6 option that indicate the IPv4 home address of the
MS to DMPA and DLMAP.
Yang & Deng Expires December 21, 2006 [Page 6]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
3. overview of this solution
In the case of mobile IPv6 network in picture 1, DMPA coule be
deployed on BS or AR. In the meanwhile, the BS/AR could provide the
IPv6 access as well with dual stack support. But, it is out of the
scope of this document. The picture below depicts the both cases:
VAAA <========================>HAAA
// \\
DMPA@BS: MS <--(IPv4)--> BS/DMPA <======(MIPv6)=========> DLMAP
VAAA<==============>HAAA
// \\
DMPA@AR: MS <-(IPv4)-> BS <-(IPv4)-> AR/DMPA <===(MIPv6)===> DLMAP
Figure 2: DMPA location cases
3.1. definition of the messages
This section defines the extensions and options to the Proxy MIPv6
messages.
3.1.1. Proxy BU for IPv4 Mobile Station
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|V| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Just like [PMIP6], int this solutions the P bit should be set to 1 to
indicate that Proxy MIPv6 is used. A new bit, the 'V' bit is added
to the Proxy BU message. This 'V' bit indicates that the
registration is for IPv4 MS only. When a DMPA sends a proxy BU to
DLMAP, the V bit MUST be set to 1 make the DLMAP knows that this
registration is a proxy registration on behalf of an IPv4 MS. When V
bit is set to 1, DLMAP SHALL NOT set up MIPv6 binding entry upon
receiving the proxy BU even if the home address options [RFC3775] is
included. When the V bit is set to 0, the binding update message
with IPv4 home address option could register the dual-stack MS to
DLMAP [Soliman].
Yang & Deng Expires December 21, 2006 [Page 7]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
3.1.2. Proxy BA for IPv4 Mobile Station
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|V| Resv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'V' bit is set to 1 only if the corresponding proxy binding
update has the IPv4 MS flag set to 1. The P flag SHOULD be 1 for
IPv4 MS registration.
3.1.3. IPv4 Home Address (HoA) option
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 # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD.
Sequence number This sequence is corresponding to the IPv4
MS. DLMAP is repsonsible to maintain the
order of the IPv4 MS's registration. It
SHOULD be assigned by DLMAP and shared
between DMPA and DLMAP for registered IPv4
MS.
IPv4 Home Address This address could be public or private
unicast IPv4 address for MS. When IPv4 HoA
is assigned by DLMAP dynamically, this
SHOULD be 0.0.0.0 in Proxy BU
If each DMPA works independently the registration from previous DMPA
may cause the problem of "out of order". In order to maintian the
right sequence order, DLMAP assigns a sequence number to DMPA in the
Proxy BA, when DMPA registers for the first time on behalf of one
IPv4 MS. Then subsequent proxy BU for the IPv4 MS could contain the
Yang & Deng Expires December 21, 2006 [Page 8]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
right sequence. The sequence number in the MIPv6 BU header is
corresponding to the DMPA.
3.2. registration procedure
In this solution, mobile station could do roaming in the mobile IPv6
network without any mobility related signaling.
The picture below shows the sequence of steps when mobile station
attachs to the mobile IPv6 network.
MS DMPA VAAA DLMAP HAAA
| IPv4 Access | | | |
| to DMPA | | | |
1) x-------------x | | |
| | AAA Request | |
2) | o---------->| | |
| | o------------------------->|
| | | | o MS Auth
| | | AAA Reply |
| | |<-------------------------o
3) | |<----------o | |
| | | | |
| o DMPA Get | | |
| Auth Success| MS Profile| | |
4) x-------------x | | |
| | | | |
| | Proxy MIP6 BU with | |
| | IPv4 HoA option | |
5) | o---------------------->| |
| | | | |
| | | o Binding Cache|
| | | | update |
| | Proxy MIP6 BA with | |
| | IPv4 HoA option | |
6) | |<----------------------o |
| | | | |
| | If code is success | |
| o in BA, set up tunnel | |
| | between DMPA and DLMAP| |
| | | | |
7) | |<----------o | |
| | | | |
Figure 6: network access call flows
The control flows after MS attached to DMPA includes:
Yang & Deng Expires December 21, 2006 [Page 9]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
- network access authentication
1) mobile station attachs to the network
2) DMPA sends the AAA request to the HAAA server via VAAA server
3) HAAA does the network accesss authentication and sends the MS
profile to DMPA by AAA reply (In this case, network
authentication is assumed to be success).
4) network access authentication success. MS could do the address
acquisition.
- Proxy mobile IPv6
5) When mobile station's address acquisition is detected, the Proxy
binding update message with IPv4 HoA option is sent to DLMAP.
The 'P' bit and 'V' bit MUST be set to 1. On DLMAP, the related
Binding Cache Entry (BCE) is updated according as the NAI
information in the Mobile Node Identifier Option[Patel05].
6) DLMAP sends the Proxy BA with IPv4 HoA option to DMPA.
7) If the proxy BA received by DMPA contains successful code, the
tunnel is set up between DLMAP and DMPA.
The following figure shows the procedure when MS handover from old
DMPA (oDMPA) to new DMPA (nDMPA).
Yang & Deng Expires December 21, 2006 [Page 10]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
MS oDMPA nDMPA DLMAP
| IPv4 move | | |
| to nDMPA | | |
1)x-------------------------x |
| | | Proxy MIP6 BU with |
| | | IPv4 HoA option |
2)| | o------------------------->|
| | | |
| | | oBCE
| | | |update
| | Proxy Binding Revocation with |
| | IPv4 HoA option |
3)| |<-------------------------------------o
| | | |
|Remove visit o | |
|Entry for MS | | |
| | Proxy Binding Revocation Ack. with |
| | IPv4 HoA option |
4)| o------------------------------------->|
| | | Proxy MIP6 BA with |
| | | IPv4 HoA option |
5)| | |<-------------------------|
| | | |
| | o set up tunnel between |
| | | nDMP and DLMAP |
Figure 7: call procedures during handover
The control flows include:
1) MS moves to nDMPA after successful network access authentication
2) nDMPA send the proxy BU with IPv4 HoA option on behalf of MS.
'P' bit and 'V' bit are both set to be 1. DLMAP SHOULD check the
BCE. If the BCE with oDMPA exists, the proxy binding revocation
message should be sent to oDMPA. The IPv4 HoA option should be
included in this revocation message[Haley05].
3) Upon receiving the proxy binding revocation message, oDMPA
removes the visiting entry for the IPv4 MS.
4) The acknowledgement is sent by oDMPA for the revocation.
Yang & Deng Expires December 21, 2006 [Page 11]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
5) Then, DLMAP sends the Proxy BA with the IPv4 HoA option to the
nDMPA.
3.3. error code
This sub-section defines the status code values in the proxy BA
message for this solution
142: IPv4 Home Address unavailable
143: Invalid IPv4 address
3.4. packet forwarding
All the IPv4 packets from the MS to the other IPv4 hosts will be sent
as normal IPv4 packets setting the source address to the HoA and the
destination address to the other host's IPv4 address. The default
gateway for the MS will always be the DLMAP's IPv4 address. The ARP
Entry for DLMAP address is a pseudo DLMAP MAC address.
DMPA MUST be able to intercept all IPv4 packets sent from the MS and
forward them to DLMAP by via the IPv6 tunnel.
DLMAP MUST be able to decapsulate the IPv6 tunnel packets received on
its IPv6 stack and transfer the inner IPv4 packets from MS to its
IPv4 stack. Then the IPv4 packets could be sent to other IPv4 hosts.
DLMAP MUST be able to intercept all the IPv4 packets to registered
IPv4 MS on its IPv4 stack. The IPv4 packets then SHOULD be
transfered to the IPv6 stack and sent out the DMPA/DLMAP tunnel
created for supporting the MS.
In DMPA, the tunneled packets are received by the IPv6 stack. The
inner IPv4 packets are extracted and sent out to MS by the IPv4 stack
of DMPA.
Yang & Deng Expires December 21, 2006 [Page 12]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
4. mobile station consideration
In this solution, the MS would work as a normal IPv4 host. It should
have the behavior consistent with the base IPv4 specification
[RFC2119].
When the MS access the network and attaches to the DMPA for the first
time, it could present its identity in the form of NAI to the network
during the network access authentication.
When MS moves to new DMPA of the same DLMAP domain, the IP address
MUST be retained unchanged, which makes the MS believe that it is on
the same link as the home link. The MS may detect its movement in
the Link layer. The network side (DMPA) SHOULD process the DHCP, ARP
and ICMP behavior of MS to deceive the upper link that MS is still on
the same link.
If MS moves to the DMPA of the different domain with another DLMAP,
it need the mobile IP stack to support the handover across domains.
4.1. Address configuration
The IPv4 HoA could be manuely configured in MS. When MS access to
the network for the first time, it could use DHCP to obtain an IPv4
HoA from the home network.
If PPP [RFC1331] is used for MS, the network access authentication
could be done during LCP. After the authentication, the NAS (here is
DMPA) will send the proxy BU with IPv4 HoA option to DLMAP. After
receiving the successful proxy BA with IPv4 HoA option, the NAS will
notify MS the HoA using IPCP [RFC1332]
Yang & Deng Expires December 21, 2006 [Page 13]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
5. Dual-stack Mobility Proxy Agent consideration
In the MIPv6 network, DMPA works as the mobile nodes. It sends the
proxy BU with IPv4 HoA option to DLMAP to set up the tunnel for MS.
In order to providing the mobility service to IPv4 MS, DMPA MUST at
least support IPv4 stack.
Upon sending the proxy BU message to DLMAP, DMPA should at least know
the following information of MS profile:
- NAI of MS
- the IPv6 address of DLMAP
- the authentication credentials
- the IPv4 default gateway address (optional)
This profile could be gained by the ways described in [PMIP6].
DMPA MUST perform the tunnel capsulation/decapsulations for the IPv4
packets from/to MS as described in section 4.4.
5.1. maintenance of the visitor list
All the DMPA MUST maintain a visitor list for all the served IPv4 MS.
Every list entry is for one MS and should have following items:
- The NAI of the MS. This is provided by MS and used for MS
profile downloading
- MAC address of MS
- HoA of MS
- Source address of the tunnel, which is a routable IPv6 address in
DMPA
- Destination address of the tunnel, which is a routable IPv6
address of DLMAP
- psudo MAC address or common MAC address shared by all the DMPA in
the same field. This is used to handle the ARP request message
from MS
Yang & Deng Expires December 21, 2006 [Page 14]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
- Address of MS's default gateway. This is used to handle the ICMP
query message from MS
- The sequence number of MS. This is assigned by DLMAP in proxy BA
and used for the right order of the MS related proxy MIPv6
messages
5.2. DHCP consideration
This solution allows for the normal IPv4 operation of MS using the
standard DHCP to configure the IP address.
When MS attachs to the network and trigger the DHCP, MPA tunnels the
DHCP message to DLMAP in IPv4 in IPv6 tunnel. DLMAP will carry out
the DHCP relay in this case. Upon receiving the DHCP ack message
tunneled from DLMAP, DMPA will send the proxy BU message to set up
the routing for MS. After the IP address configuration, MS could
send the DHCP request message to DHCP server directly for IP address
renewal. The IP-IP tunnel between DMPA and DLMAP will be used for
the routing of the DHCP messages exchanged between MS and DHCP
server.
5.3. ARP consideration
In the IEEE 802 type access networks, the host sends ARP request for
other hosts and default gateway on its attached links. The host will
maintain the ARP entries for delivery of the packets to the links.
In this solution, the default gateway of MS is the IPv4 address of
DLMAP DMPA will intercept the packets from MS to DLMAP.
In MS, the ARP entries for default gateway and other hosts could be
set to be a common MAC address for all the DMPA in current domain.
If DMPA is on BS, the ARP entries on MS could be set as a psudo MAC
that is never be used.
If DMPA is on AR, BS could modify the destination MAC address from MS
properly to reach DMPA.
All the ARP entries for the default gateway nad other hosts
5.4. ICMP consideration
As described in [RFC0792], the MS may send ICMP query message to the
default gateway. The TTL of this ICMP message is 1. This is to
ensure that the default gateway is still reachable on the link. DMPA
should give a echo of this ICMP query to the MS served by it.
Yang & Deng Expires December 21, 2006 [Page 15]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
6. Dual-stack Local Mobility Anchor Point consideration
In addition to the home agent specification in [RFC3775] and [PMIP6],
DLMAP MUST be able to process the proxy BU with 'V' bit and IPv4 HoA
option and generate the proxy BA with 'V' bit set to 1 and IPv4 HoA
option.
When the DLMAP receives a proxy BU with IPv4 HoA option, it should
follow all the required steps in [RFC3775] and [PMIP6], in addition,
the following checks MUST be done:
- If the 'V' bit is set to 1 and the IPv4 HoA option has a valid
unicast IPv4 address, DLMAP must check that this address is
allocated to the MS.
- If the 'V' bit is set to 1 and the IPv4 HoA option has the all 0
address, DLMAP should allocate a valid IPv4 HoA to MS. If the it
is not available, DLMAP should send the error code to DMPA.
- If the proxy BU is accepted, DLMAP must create the binding cache
entry for the MS's IPv4 HoA. The destination address of the
tunnel should be stored as the Care-of Address (CoA) of the MS.
This could be obtained from the source address field in the IPv6
header of proxy BU or by the alternate Care-of Address option
[RFC3775] if present. A sequence number MUST be assigned to this
MS.
- After building the entry for MS, DLMAP must create a proxy BA
message to DMPA. The 'V' bit should be set to 1. The IPv4 HoA
option MUST be included with the HoA and assigned sequence number
inside.
If the 'V' bit is set to 1, DLMAP must not create the IPv6 binding
cache entry even if the proxy BU contains the IPv6 Home Address
option [RFC3775]. Given the NAI of MS, DLMAP MUST be able to find
the IPv4 home address of the MS and store it in the binding cache
entry. This address could be static or dynamically assigned.
Upon the receiving of the proxy BU from DMPA, the DLMAP look up the
BCE by NAI. If BCE exists, DLMAP will compare the sequence number
between the one in IPv4 HoA option and BCE. it the value in the
option is zero or greater than or equal to the one in BCE, DLMAP will
accepts this registration. In the IPv4 HoA option of the proxy BA
reply, DLMAP will include a sequence number that is one greater than
the larger value of either the BCE or proxy binding BU. If the
registration is denied, DLMAP sends the error code "administratively
prohibited" (129).
Yang & Deng Expires December 21, 2006 [Page 16]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
Upon the receiving of the proxy BU from DMPA, the DLMAP look up the
BCE by NAI. If BCE exists and the address of the DMPA is different
from the one in BCE, DLMAP will send the proxy binding revocation
message to the old DMPA and update the BCE with the IPv6 address of
the new DMPA.
When building the proxy BA message, DLMAP should follow the rules in
[RFC3775] and [PMIP6]. The routing heaader MUST always contain the
IPv6 address of DMPA as described in [RFC3775].
After the MS's IPv4 HoA has successfully registered in DLMAP, all the
packets destinated to MS's IPv4 HoA MUST intercepted by DLMAP. They
are encapsulated in the IPv6 tunnel between DLMAP and DMPA and sent
out to DMPA.
Because MS and other hosts use the IPv4 address for communication,
the route optimization [RFC3775] method will not be used in this
solution.
Yang & Deng Expires December 21, 2006 [Page 17]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
7. Security Considerations
This solution introduces new mobility funtion, DMPA. Network Access
Authentication and authorization MUST be done prior to the proxy
binding messages. DMPA does the proxy MIPv6 registration on behalf
of MS, so the security association should be set up between DLMAP and
DMPA for securing the signaling. MS's identity, NAI is used during
network authentication and proxy MIPv6 registration. Therefore, in
order to authenticate the IPv4 HoA of MS, DLMAP MUST store the IPv4
HoA corresponding to the NAI of MS. The message MUST be pretected by
IPsec or using an Authentication Option [Patel05b].
Yang & Deng Expires December 21, 2006 [Page 18]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
8. IANA Considerations
This document defines one new flag 'V' to the binding update and
binding acknowledgement messages. This flag should be allocated from
the same space used by the flags in binding update and binding
acknowledgement messages in [RFC3775].
This document defines one option, IPv4 HoA option. It is a mobility
option as defined in the base IPv6 specification [RFC2460]. The IANA
should assign a value for the type value of this option.
This document defines one new status code to binding acknowledgement
message. This flag should be allocated from the same space used by
the binding acknowledgement message status codes in [RFC3775].
9. Reference
[Dawkins06]
Dawkins, Ed., S., "Softwire Problem Statement", May 2006,
<draft-ietf-softwire-problem-statement-02.txt (work in
progress)>.
[Haley05] Haley, B. and S. Gundavelli, "Mobility Header Signaling
Message", Oct 2005,
<draft-haley-mip6-mh-signaling-01.txt(work in progress)>.
[Kempf06] Kempf, J., "Problem Statement for Network-based IP Local
Mobility", Jul 2006,
<draft-ietf-netlmm-nohost-ps-03.txt(work in progress)>.
[Kempf06b]
Kempf, J., Leung, K., and al. et, "Goals for Network-based
Localized Mobility Management (NETLMM)", Apr 2006,
<draft-ietf-netlmm-nohost-req-01.txt(work in progress)>.
[PMIP6] Gundavelli, S. and K. Leung, "Localized Mobility
Management using Proxy Mobile IPv6", Nov 2005,
<draft-gundavelli-netlmm-mip6-proxy-00.txt (work in
progress)>.
[Patel05] Patel, A. and al. et, "Mobile Node Identifier Option for
MIPv6", Sep 2005, <draft-ietf-mip6-mn-ident-option-03
(work in progress)>.
[Patel05b]
Patel, A. and al. et, "Authentication Protocol for Mobile
IPv6", Sep 2005,
<draft-ietf-mip6-auth-protocol-07.txt(work in progress)>.
Yang & Deng Expires December 21, 2006 [Page 19]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC1331] Simpson, W., "The Point-to-Point Protocol (PPP) for the
Transmission of Multi-protocol Datagrams over Point-to-
Point Links", RFC 1331, May 1992.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[Soliman] Soliman, H. and G. Tsirtsis, "Dual Stack Mobile IPv6",
Jul 2005, <draft-soliman-v4v6-mipv4-02.txt (work in
progress)>.
Yang & Deng Expires December 21, 2006 [Page 20]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
Authors' Addresses
Peng Yang
Hitachi (China)
Beijing Fortune Bldg. 1701
5 Dong San Huan Bei-Lu
Chao Yang District
Beijing 100004
China
Email: pyang@hitachi.cn
Hui Deng
Hitachi (China)
Beijing Fortune Bldg. 1701
5 Dong San Huan Bei-Lu
Chao Yang District
Beijing 100004
China
Email: hdeng@hitachi.cn
Yang & Deng Expires December 21, 2006 [Page 21]
Internet-Draft IPv4/netlmm6/IPv4 June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Yang & Deng Expires December 21, 2006 [Page 22]
