Internet DRAFT - draft-tsirtsis-v4v6-mipv4
draft-tsirtsis-v4v6-mipv4
Personal G. Tsirtsis
H. Soliman
V. Park
Internet Draft Qualcomm
Document: draft-tsirtsis-v4v6-mipv4-01.txt
Expires: November 2006 April 2006
Dual Stack Mobile IPv4
draft-tsirtsis-v4v6-mipv4-01.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 max 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 October 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
<Tsirtsis, Soliman, Park> 1
<Dual Stack Mobile IPv4> <April> <2006>
Abstract
This specification provides IPv6 extensions to the Mobile IPv4
[MIPv4] protocol. The extensions allow a dual stack node to use IPv4
and IPv6 home addresses as well as move between IPv4 and dual stack
network infrastructures.
INDEX
1. Introduction.......................................................3
1.1. Goals............................................................3
1.2. Non-Goals........................................................3
2. Extension Formats..................................................4
2.1. IPv6 Prefix Extension............................................4
2.2. IPv6 Code Extension..............................................5
2.3. IPv6 Tunneling Mode Extensions...................................6
3. Mobile IP Registrations............................................7
3.1. Registration Requests............................................7
3.2. Registration Reply...............................................8
3.3. Home Agent Considerations........................................8
3.4. Foreign Agent Considerations....................................10
3.5. Mobile Node considerations......................................10
3.6. Dynamic IPv6 Prefix allocation..................................12
3.7. Deregistration of IPv6 Prefix...................................13
3.8. Registration with a private CoA.................................13
4. Security Considerations...........................................13
5. References........................................................13
Author's Addresses...................................................14
<Tsirtsis, Soliman, Park> 2
<Dual Stack Mobile IPv4> <April> <2006>
1. Introduction
Mobile IPv4 [MIPv4] allows a mobile node with an IPv4 address to
maintain communications while moving in an IPv4 network.
Extensions defined in this document allow a node that has IPv4 and
IPv6 [IPv6] addresses to maintain communications with either any of
its addresses while moving in IPv4 or dual stack networks.
Essentially, this specification separates the Mobile IPv4 signaling
from the IP version of the traffic that it tunnels. Mobile IPv4 with
the present extensions remains a signaling protocol that runs over
IPv4, and yet can set-up any combination of IPv4 and/or IPv6 over
IPv4 tunnels.
The aim is two-fold:
On one hand, Mobile IPv4 with the present extensions becomes a
powerful transition mechanism, allowing automated but controlled
tunneling of IPv6 traffic over IPv4 tunnels. Dual stack nodes in
dual stack home networks can now roam to and from legacy IPv4
networks, while IPv4 mobile nodes and networks can migrate to IPv6
without changing mobility management, and without upgrading all
network nodes to IPv6 at once.
On the other hand, and more importantly, it allows dual stack mobile
nodes and networks to utilize a single protocol for the movement of
both IPv4 and IPv6 stacks in the network topology.
Note that features like Mobile IPv6 [MIPv6] style route optimization
will not be possible with this solution as it still relies on Mobile
IPv4 signaling, which does not provide route optimization.
1.1. Goals
i) The solution supports the registration of IPv6 address(es)
and/or prefix(s) in addition to regular IPv4 home address
registration
ii) The solution supports dynamic IPv6 address(s)/prefix(s)
allocations
iii) The solution supports the above registrations with and without
FA support
1.2. Non-Goals
<Tsirtsis, Soliman, Park> 3
<Dual Stack Mobile IPv4> <April> <2006>
i) The solution does not provide support for IPv6 care-of address
registration
2. Extension Formats
The following extensions are defined according to this
specification.
2.1. IPv6 Prefix Extension
A new skippable extension to the Mobile IPv4 header in accordance to
the short extension format of [MIPv4] is defined here.
This extension contains a mobile IPv6 network prefix and its
prefix length.
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 | Sub-Type | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Mobile IPv6 Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
DSMIPv4 Extensions (skippable type range to be assigned by
IANA)
Length
20
Sub-Type
1 (IPv6 Prefix)
Prefix Length
<Tsirtsis, Soliman, Park> 4
<Dual Stack Mobile IPv4> <April> <2006>
Indicates the prefix length of the prefix included in the
Mobile Network IPv6 Prefix Field
Mobile IPv6 Network Prefix
A sixteen-byte field containing the Mobile IPv6 Network Prefix
2.2. IPv6 Code Extension
A new skippable extension to the Mobile IPv4 header in accordance to
the short extension format of [MIPv4] is defined here.
This extension defines a mobile IPv6 network prefix and its
prefix length, as well as a code.
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 | Sub-Type | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ Mobile IPv6 Network Prefix +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
DSMIPv4 Extensions (skippable type range to be assigned by
IANA)
Length
22
Sub-Type
2 (IPv6 Prefix Acknowledgment)
Code
<Tsirtsis, Soliman, Park> 5
<Dual Stack Mobile IPv4> <April> <2006>
A value indicating the result of the registration
request with respect to the IPv6 home address
registration
Prefix Length
Indicates the prefix length of the prefix included in the
Mobile Network IPv6 Prefix Field
Mobile IPv6 Network Prefix
A sixteen-byte Mobile IPv6 Network Prefix.
Reserved
Set to 0 by the sender, ignored by the receiver
The following values are defined for use as a Code value in the
above extension
0 registration accepted, IPv6 to be tunneled to HoA
1 registration accepted, IPv6 to be tunneled to CoA
8 reason unspecified
9 administratively prohibited
Note that a registration reply that does not include an IPv6 code
extension indicates that the home agent does not support IPv6
extensions and thus has ignored such extensions in the registration
reply.
2.3. IPv6 Tunneling Mode Extension
A new skippable extension to the Mobile IPv4 header in accordance to
the short extension format of [MIPv4] is defined here.
This presence of this extension in a registration request
message indicates that the sender supports the IPv6 extensions
specified in this document.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<Tsirtsis, Soliman, Park> 6
<Dual Stack Mobile IPv4> <April> <2006>
| Type | Length | Sub-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
DSMIPv4 Extensions (skippable type range to be assigned by
IANA)
Length
4
Sub-Type
3 (IPv6 Tunneling Mode Extension)
Reserved
Set to 0 by the sender and ignored y the receiver.
3. Mobile IP Registrations
3.1. Registration Requests
A mobile IP client MAY include one or more IPv6 prefix extensions
defined in this specification in a registration request.
A mobile IP client MAY include exactly one IPv6 tunneling mode
extension when it uses the collocated care-of address mode.
When IPv6 prefix and/or IPv6 tunneling mode extension are used by
the mobile client, they MUST be placed after the registration
request header and before the mobile - home authentication extension
so they MUST be included in the computation of any authentication
extension.
A foreign agent MAY include an IPv6 tunneling mode extension defined
in the specification in a registration request when the care-of
address mode of operation is used.
When IPv6 tunneling mode extension are used they MUST be placed
after the mobile - home authentication extensions and before the
foreign - home authentication extension so they MUST be included in
<Tsirtsis, Soliman, Park> 7
<Dual Stack Mobile IPv4> <April> <2006>
the computation of the foreign - home authentication extension when
one exists.
3.2. Registration Reply
The mechanism described in the specification depends on skippable
extensions. For that reason a registration reply that does not
include an IPv6 code extension, in response to a registration
request that included an IPv6 prefix extension, indicates that the
home agent does not support IPv6 extensions and has ignored the
request.
If an IPv6 code extension is included in a registration reply then,
said extension indicates the success or failure of the IPv6 prefix
registration. The IPv6 code extension does NOT affect in any way,
the code value in the registration reply header.
Note that a negative IPv6 code extension has the same effect with
not including such extension at all in the sense that in both cases
the mobile client and foreign agent must act as if the corresponding
request of Ipv6 prefix registration was rejected. Of course negative
IPv6 code extension allows the home agent to indicate why a given
request was rejected.
3.3. Home Agent Considerations
A dual stack home agent that supports the IPv6 extensions defined in
this specification, MUST keep track of the following IPv6 related
state for the mobile IP clients it supports, in addition to what
state is defined in [MIPv4], section 3.8.1
- Registered IPv6 prefix(es) and prefix length(s)
- Tunneling mode for IPv6 traffic:
- Tunnel to IPv4 HoA and accept IPv6 tunneled from IPv4 HoA
- Tunnel to CoA and accept IPv6 tunneled from CoA
If the tunnel for IPv4 traffic terminates at a different point than
the tunnel for IPv6 traffic (mobile client's CoA vs HoA), both
tunnels MUST use the tunneling mechanism negotiated by the Mobile IP
header as defined in [MIPv4].
A home agent that supports this specification MUST be able to
intercept IPv4 and IPv6 packets destined to registered mobile nodes
according to mechanisms described in [MIPv4] and [MIPv6]
<Tsirtsis, Soliman, Park> 8
<Dual Stack Mobile IPv4> <April> <2006>
specifications. All intercepted traffic SHOULD be tunneled to the
registered care-of address or home address of the mobile client in
question according to the tunneling mode selected for IPv6 traffic.
Tunneling mode selection for IPv6 traffic depends on the following
parameters in a successful registration request:
1) Registration request is received with one or more IPv6 prefix
extensions. An IPv6 tunneling mode extension is not included.
All IPv6 packets destined to the registered IPv6 prefix(es)
MUST be tunneled by the home agent to the registered IPv4 home
address of the mobile. Additionally, the home agent MUST be
prepared to accept reverse tunneled packets from the IPv4 home
address of the mobile encapsulating IPv6 packets sent by that
mobile.
2) Registration request is received with one or more IPv6 prefix
extensions. An IPv6 tunneling mode extension is included.
All IPv6 packets destined to the registered IPv6 home
address(s) SHOULD be tunneled by the home agent to the
registered care-of address of the mobile client. Additionally,
the home agent SHOULD be prepared to accept reverse tunneled
packets from the care-of address of the mobile encapsulating
IPv6 packets sent by that mobile. The home agent MAY ignore the
presence of the IPv6 tunneling mode extension and act as in
case (1) above.
The home agent SHOULD check that all IPv6 packets received from the
mobile client over a tunnel from the home address or the care-of
address, include a source address that falls under the registered
IPv6 prefix(es) for that mobile client.
For each IPv6 prefix extensions included in a valid registration
request, a home agent that supports this specification SHOULD
include a corresponding IPv6 code extension. For each accepted IPv6
prefix the home agent MUST decide the tunneling mode used according
to this section and set the Code field of the IPv6 code extension to
the appropriate value. The omission of a given code extension is
equivalent to the rejection of the corresponding IPv6 prefix
extension. The IPv6 prefix field of each of the IPv6 code
extensions included in the registration reply MUST match a
corresponding IPv6 prefix field of the IPv6 prefix extension
included in the corresponding registration request message.
<Tsirtsis, Soliman, Park> 9
<Dual Stack Mobile IPv4> <April> <2006>
3.4. Foreign Agent Considerations
A dual stack foreign agent that supports the IPv6 extensions defined
in this specification MUST keep track of the following IPv6 related
state for the mobile nodes it supports in addition to what state is
defined in [MIPv4], section 3.7.1.
- IPv6 Prefix(es) and Prefix Length(s)
- Tunneling mode for IPv6 traffic:
- accept IPv6 encapsulated in IPv4 and reverse tunnel IPv6
When a foreign agent receives a registration request with IPv6
prefix extension(s) it has the following choices:
1) Ignore the extension(s). The registration request is forwarded as
is with no IPv6 tunneling mode extension to the home agent.
The foreign agent SHOULD operate according to [MIPv4]
2) Attach an IPv6 tunneling mode extension to the registration
request sent to the home agent.
The foreign agent MUST be prepared to de-capsulate and deliver
IPv6 packets, in addition to the IPv4 packets, sent to it in
the home agent to foreign agent tunnel for that mobile client.
The foreign agent MUST be prepared to receive IPv6 packets from
the mobile client, in addition to IPv4 packets. All IPv6
traffic MUST be reverse tunneled to the home agent by the
foreign agent irrespectively from the reverse tunneling setting
negotiated for IPv4 packets by mechanisms in [REVTUN]
If the foreign agent sets the R flag included in the mobility agent
advertisement [MIPv4] and a mobile client uses the collocated
address model, the foreign agent MUST NOT include an IPv6 tunneling
mode extension in the registration request messages sent from that
mobile client.
3.5. Mobile Node considerations
A dual stack mobile node that supports the extensions described in
this document MAY use these extensions to register its IPv6 home
address(es) and/or prefix(es) while moving between access routers.
<Tsirtsis, Soliman, Park> 10
<Dual Stack Mobile IPv4> <April> <2006>
The mobile client MAY include one or more IPv6 Prefix extension(s)
in the registration request.
In this case the mobile MUST take the following action depending on
the extensions included in the registration reply it receives in
response to the registration request:
1) The registration reply does not include any IPv6 code extensions.
The mobile client SHOULD assume that the home agent does not
support the extensions defined in this specification. The
mobile client SHOULD continue to operate according to RFC3344.
2) The registration reply includes one or more IPv6 code extensions.
The mobile client MUST match each IPv6 code extension with one
of the IPv6 prefix extensions earlier included in the
corresponding registration request message.
If a matching IPv6 code extension is not included for one or
more of corresponding IPv6 prefix extensions included in the
registration request message, the mobile client SHOULD assume
that these IPv6 prefixes are rejected.
For each matching IPv6 code extensions the mobile client MUST
inspect the Code field. If the field is set to a rejection code
then the corresponding IPv6 prefix registration has been
rejected. If the field is set to an acceptance code then the
corresponding IPv6 prefix registration has been accepted.
If the Code field is set to "0" then the mobile client MUST be
prepared to send/receive IPv6 packets encapsulated in the
bidirectional tunnel between the home agent address and the
registered IPv4 home address of the mobile client.
If the Code field is set to "1" then the mobile client MUST act
as follows:
If the care-of address mode is used, the mobile client
MUST be prepared to send/receive IPv6 traffic on its
interface natively, unless reverse tunnel has been
negotiated in which case both IPv4 and IPv6 traffic MUST
be reverse tunneled according to [REVTUN].
<Tsirtsis, Soliman, Park> 11
<Dual Stack Mobile IPv4> <April> <2006>
If the collocated care-of address mode is used, the
mobile client MUST be prepared to send/receive IPv6
packets over the bidirectional tunnel between the home
agent address and its collocated care-of address.
The mobile client SHOULD include exactly one IPv6 tunneling mode
extension if it uses the collocated care-of address model and if it
wants to request that IPv6 packets are tunneled to its collocated
care-of address. If the mobile client uses the collocated care-of
address model but it does not include the IPv6 tunneling mode
extension the home agent will tunnel IPv6 traffic to the mobile
client's home address.
3.6. Dynamic IPv6 Prefix allocation
A mobile client MAY include one or more IPv6 prefix extensions with
the IPv6 prefix field set to zero. Such IPv6 prefix extensions
indicate that the mobile client requests IPv6 prefix(es) to be
assigned to it by the home agent. The mobile client MAY set the
prefix length field of such extensions to zero or to a length of its
choice as a hint to the home agent.
A home agent receiving an IPv6 prefix extension with the IPv6 prefix
field set to zero MAY return an IPv6 Code extension with the IPv6
prefix field set to the IPv6 prefix allocated to the mobile client.
The length of that prefix is at the discretion of the home agent.
The home agent MAY take into account the prefix length hint if one
is included in the IPv6 prefix extension.
For stateless auto-configuration of addresses [AUTO], a mobile
client MAY include one or more IPv6 prefix extensions with the IPv6
Prefix field set to ::interface_identifier. Such IPv6 prefix
extensions indicate that the mobile client requests IPv6 address(es)
to be assigned to it by the home agent. The prefix length field in
such an extension SHOULD be set to either 64 or 128.
The home agent MAY in this case return an IPv6 Code extension with:
- the IPv6 prefix field set to PREFIX:: and the prefix length
field set to 64.
- the IPv6 prefix field set to PREFIX::interface_identifier
and the prefix length field set to 128.
<Tsirtsis, Soliman, Park> 12
<Dual Stack Mobile IPv4> <April> <2006>
3.7. Deregistration of IPv6 Prefix
The mobile IP registration lifetime included in the registration
request header is valid for all binding created by the registration
request, which may include bindings for an IPv6 Prefix(es).
A registration request with a zero lifetime can be used to remove
all bindings from the home agent.
A re-registration request with non-zero lifetime can be used to
deregister some of the registered IPv6 prefixes by not including
corresponding IPv6 prefix extensions in the registration request
message.
3.8. Registration with a private CoA
If the care-of address is a private address then Mobile IP NAT
Traversal as described in [MIPNAT] MAY be used in combination with
the extensions described in this specification.
4. Security Considerations
This specification operates in the security constraints and
requirements of [MIPv4]. It extends the operations defined in
[MIPv4] for IPv4 home addresses to cover IPv6 prefixes and provides
the same level of security for both IP versions.
5. References
[AUTO] S. Thomson, T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC2462
[IPv6] S. Deering and B. Hinden, "Internet Protocol version 6
(IPv6) specification", RFC 2460
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MIPNAT] H. Levkowetz, S. Vaarala, " Mobile IP Traversal of
Network Address Translation (NAT) Devices", RFC3519
[MIPv4] C. Perkins, "Mobility Support for IPv4", RFC3344
<Tsirtsis, Soliman, Park> 13
<Dual Stack Mobile IPv4> <April> <2006>
[MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support
in IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003.
[NAI] P.Calhoun, C. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC2794
[REVTUN] G. Montenegro, "Reverse Tunneling for Mobile IP,
revised", RFC3024
Author's Addresses
George Tsirtsis
Qualcomm Inc
Phone: +908-947-7059
Email1: tsirtsis@qualcomm.com
Email2: tsirtsisg@yahoo.com
Hesham Soliman
Qualcomm Inc
Phone: +61400500321
E-mail: hsoliman@qualcomm.com
Vincent Park
Qualcomm Inc
Phone: +908-947-7084
E-mail: vpark@qualcomm.com
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.
<Tsirtsis, Soliman, Park> 14
<Dual Stack Mobile IPv4> <April> <2006>
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 (2005). 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.
<Tsirtsis, Soliman, Park> 15
