Personal G. Tsirtsis
H. Soliman
Flarion
Internet Draft
Document: draft-tsirtsis-v4v6-mipv4-00.txt
Expires: January 2003 August 2003
Dual Stack Mobile IPv4
draft-tsirtsis-v4v6-mipv4-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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
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.
<Tsirtsis, Soliman> 1
<Dual Stack Mobile IPv4> <August> <2003>
INDEX
1. Introduction.......................................................3
2. Agent Advertisement................................................3
2.1. Home Agent Considerations........................................4
2.2. Foreign Agent Considerations.....................................4
2.3. Mobile Client considerations.....................................4
3. Extensions Headers.................................................5
3.1. IPv6 Home Address Extension......................................5
3.2. IPv6 Compatibility Extension.....................................5
3.3. IPv6 Code Extension..............................................6
4. Mobile IP Registrations............................................6
4.1. Registration Requests............................................6
4.2. Registration Reply...............................................7
4.3. Home Agent Considerations........................................7
4.4. Foreign Agent Considerations.....................................8
4.5. Mobile Node considerations.......................................9
4.5.1. Foreign Agent Assisted.........................................9
4.5.2. Collocated care-of address....................................10
4.6. Dynamic IPv6 home address.......................................10
4.7. Deregistration of IPv6 home address.............................11
4.8. Registration with a private CoA.................................11
4.8.1. Dual Stack networks with Private IPv4.........................11
5. Applicability and usage scenarios.................................11
5.1. Example usage scenarios.........................................12
5.1.1. Foreign agent with full IPv6 support..........................12
5.1.2. Foreign agent with limited IPv6 support.......................13
5.1.3. Foreign agent refuses to handle IPv6 for mobile...............14
5.1.4. IPv4 only network with foreign agent support..................14
5.1.5. IPv4 only network with no foreign agent support...............15
5.2. Visiting IPv6 ONLY networks.....................................15
6. Security Considerations...........................................16
7. References........................................................16
Author's Addresses...................................................16
<Tsirtsis, Soliman> 2
<Dual Stack Mobile IPv4> <August> <2003>
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 or both
of its addresses while moving in IPv4 or dual stack networks.
Essentially, this specification separates the Mobile IP signaling
version from the IP version of the traffic that it tunnels. Mobile
IPv4 with the present extensions becomes 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 automatic 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 maybe 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. See
section 5 for applicability and usage scenarios.
Note that features like route optimization in Mobile IPv4 will not
be possible with this solution as it still relies on Mobile IPv4
signaling, which does not provide route optimization.
2. Agent Advertisement
A new flag is added to indicate support for IPv6
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 Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |R|B|H|F|M|G|V|T|S|I|A| rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |
A IP Version 6 extensions supported.
<Tsirtsis, Soliman> 3
<Dual Stack Mobile IPv4> <August> <2003>
2.1. Home Agent Considerations
Mobile IPv4 Home Agents that are prepared to support IPv6 for mobile
nodes SHOULD set the A flag.
2.2. Foreign Agent Considerations
Foreign agents that are prepared to support mobile clients with IPv6
home addresses SHOULD set the A flag.
2.3. Mobile Client considerations
A Mobile client that supports the IPv6 extensions described in this
specification should exhibit the following behavior depending on the
A flag setting in Foreign Agent advertisements (FAAs) and home agent
advertisements (HAAs)
A flag NOT SET in HA Advertisement
(HAA A=0, FAA A=0 or A=1)
Mobile clients that receive a home agent advertisement
with no A flag set SHOULD ignore IPv6 extensions in
foreign agent advertisements and SHOULD NOT attempt to use
the IPv6 extensions defined in this specification.
A flag SET in HA and FA advertisements
(HAA A=1, FAA A=1)
Mobile clients that receive a home agent advertisement
with an A flag set or they otherwise know their home agent
supports the extensions defined in this document and they
receive a foreign agent advertisement with an A flag set,
SHOULD attempt to use the extensions defined in this
specification.
A flag SET in HA advertisements but not in FA advertisements
(HAA A=1, FAA A=0)
Mobile clients that receive foreign agent advertisement
with no A flag set MAY attempt to use IPv6 extensions
described in this document provided the are prepared to
use end to end forward and reverse IPv4 tunneling for all
IPv6 traffic between their IPv4 HoA and the IPv4 HA
address.
<Tsirtsis, Soliman> 4
<Dual Stack Mobile IPv4> <August> <2003>
3. Extensions Headers
3.1. IPv6 Home Address 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 the IPv6 Home Address of the mobile IP
client.
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 | IPv6 Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = TBD
Length = 17
Sub-Type = 1 for IPv6 home address
3.2. IPv6 Compatibility Extension
A new skippable extension to the Mobile IPv4 header in accordance to
the short extension format of [MIPv4] is defined here.
This extension indicates that the sender supports the IPv6
extensions specified in this document and defines whether
reverse tunneling is required for IPv6 traffic.
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 |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = TBD
Length = 2
R If SET the FA mandates reverse tunnel for all IPv6 traffic.
<Tsirtsis, Soliman> 5
<Dual Stack Mobile IPv4> <August> <2003>
3.3. 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 provides IPv6 error codes
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 | Code | Rsvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = TBD
Length = 2
Code A value indicating the result of the registration
request with respect to the IPv6 home address
registration
The following values are defined for use as a Code value in the
above extension
0 registration accepted IPv6 to be tunneled to CoA
2 registration accepted IPv6 to be tunneled to HoA
Registration denied by the foreign agent:
64 reason unspecified
65 administratively prohibited
Registration denied by the home agent:
128 reason unspecified
129 administratively prohibited
Note that a registration reply that does not include an IPv6 error
code extension indicates that the home agent does not support IPv6
extensions and thus has ignored such extensions in the registration
reply.
4. Mobile IP Registrations
4.1. Registration Requests
A mobile IP client MAY include an IPv6 home address extension
defined in this specification in a registration request.
<Tsirtsis, Soliman> 6
<Dual Stack Mobile IPv4> <August> <2003>
When IPv6 home address extensions are used 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 mobile client or foreign agent MAY include an IPv6 compatibility
extensions defined in the specification in a registration request.
When IPv6 compatibility extensions 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
the computation of the foreign - home authentication extension when
on exists.
4.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 indicates that the home agent does
not support IPv6 extensions and has ignored the request.
If an IPv6 code extension in included in a registration reply then
said extension indicates the success code=0 or node code!=0 of the
IPv6 registration. The IPv6 code extension DOES NOT affect in any
way the code value in the registration reply header.
An IPv6 code extension is only required when:
- the code in the registration reply header indicates
successful IPv4 registration
- the code in the registration reply header indicates failure
but with a code other than 64, 65, 128, 129. This is done since
the rest of the error codes are independent from the home
address version registered.
4.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
- The mobile node's IPv6 home address
- Tunneling mode for IPv6 traffic:
- Tunnel to IPv4 HoA and accept IPv6 tunneled from IPv4 HoA
- Tunnel to CoA
- Tunnel to CoA and accept IPv6 tunneled from CoA
A home agent that supports this specification MUST be able to
intercept IPv4 and IPv6 packets destined to registered mobile nodes
<Tsirtsis, Soliman> 7
<Dual Stack Mobile IPv4> <August> <2003>
according to mechanisms described in [MIPv4] and [MIPv6]
specifications. All intercepted traffic SHOULD be tunneled to the
registered care-of address or home address of the mobile client in
question according to T flag in 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 was received with an IPv6 home address
extension but no IPv6 compatibility extension was included
The home agent MUST tunnel all IPv6 packets destined to the
registered IPv6 home address 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 the
mobile. Note that in this case the home agent MUST either
accept or reject both IPv4 and IPv6 home addresses.
2) Registration request was received with an IPv6 home address
extension and an IPv6 compatibility extension with R=0
In this case the home agent MUST tunnel all IPv6 packets
destined to the registered IPv6 home address to the registered
care-of address of the mobile.
3) Registration request was received with an IPv6 home address
extension and an IPv6 compatibility extension with R=1
In this case the home agent MUST tunnel all IPv6 packets
destined to the registered IPv6 home address to the registered
care-of address of the mobile. Additionally, the home agent
MUST be prepared to accept reverse tunneled packets from the
care-off address of the mobile encapsulating IPv6 packets sent
by the mobile.
4.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.
- Mobile node's IPv6 home address
- Tunneling mode for IPv6 traffic:
- accept IPv6 encapsulated in IPv4
- accept IPv6 encapsulated in IPv4 and reverse tunnel IPv6
When a foreign agent receives a registration request with an IPv6
home address extension it has the following choices:
<Tsirtsis, Soliman> 8
<Dual Stack Mobile IPv4> <August> <2003>
1) Ignore the extension. The registration request is forwarded as is
with no IPv6 compatibility extension to the home agent.
The foreign agent is not prepared to tunnel/de-tunnel IPv6
traffic for the mobile client and thus IPv6 traffic SHOLD be
tunneled to its IPv4 home address by the home agent as
described in home agent consideration section 4.3.
2) Attach an IPv6 Compatibility extension with R=0 to the
registration request sent to the home agent.
The foreign agent is prepared to decapsulate and deliver to the
mobile IPv6 packets tunneled to the care-off address.
4) Attach an IPv6 Compatibility extension with R=1 to the
registration request sent to the home agent.
The foreign agent is prepared to decapsulate and deliver to the
mobile IPv6 packets tunneled to the care-off address. The
foreign agent also instruct the home agent that all IPv6
traffic from the mobile will be reverse tunneled.
4.5. Mobile Node considerations
A dual stack mobile node that supports the extensions described in
this document MAY use these extensions to maintain connectivity of
both its IPv4 and IPv6 home address while moving between access
routers.
4.5.1. Foreign Agent Assisted
In this case the mobile client will receive a foreign agent
advertisement. According to the A flag setting in this advertisement
the mobile SHOULD exhibit the following behavior:
1) A flag is NOT SET
The mobile client SHOULD include an IPv6 home address extension
in the registration request. In this case the mobile MUST be
prepared to decapsulate IPv6 packets tunneled to its IPv4 home
address by the home agent. In addition it MUST reverse tunnel
all IPv6 traffic to its home agent using its IPv4 home address
as source address of the tunnel.
2) A flag is SET
The mobile client SHOULD include an IPv6 home address extension
in the registration request.
<Tsirtsis, Soliman> 9
<Dual Stack Mobile IPv4> <August> <2003>
4.5.2. Collocated care-of address
In this case the mobile client will not receive a foreign agent
advertisement and will use a collocated care-of address discovered
with the mechanisms outlined in [MIPv4]. Depending on IPv6 support
in the foreign network the mobile SHOULD exhibit the following
behavior (IPv4 support is always assumed in the foreign network):
1) mobile gets a local IPv6 address (native or via ngtrans tools)
The mobile client SHOULD include an IPv6 home address extension
in the registration request. The mobile SHOULD also include an
IPv6 compatibility extension with R=0 to indicate that no
reverse tunneling of IPv6 traffic is required.
2) mobile does not get a local IPv6 address
The mobile client SHOULD include an IPv6 home address extension
in the registration request. The mobile SHOULD also include an
IPv6 compatibility extension with R=1 to indicate that reverse
tunneling of IPv6 traffic is required.
If in either of the cases above the mobile does not include an IPv6
compatibility extension then it SHOULD be prepared to decapsulate
IPv6 packets tunneled to its IPv4 home address by the home agent and
it MUST reverse tunnel all IPv6 traffic to its home agent using its
IPv4 home address as source address of the tunnel.
Note that the local IPv6 address, when available, in the foreign
network is not used in this specification; it is merely an
indication that IPv6 traffic can be sent through the foreign
network.
4.6. Dynamic IPv6 home address
The following options are supported:
-Mobile sends a zero IPv6 home address extension. The home agent
allocates a home address from its subnet and returns it in the same
extension.
-Mobile sends ::EUI64 in an IPv6 home address extension. The home
agent fills in its mobile network prefix and returns PREFIX::EUI64
or just PREFIX:: if it allocates a subnet.
<Tsirtsis, Soliman> 10
<Dual Stack Mobile IPv4> <August> <2003>
4.7. Deregistration of IPv6 home address
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 home address.
A registration request with a zero lifetime can be used to remove
all bindings from the home agent.
4.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.8.1. Dual Stack networks with Private IPv4
This is a special case where the foreign network is dual stack but
it only supports private IPv4.
While in this case Mobile IP NAT traversal [MIPNAT] will also work
it should be possible to do something better. Since the scenario
offers the mobile with access to native IPv6, it should be possible
to further extend Mobile IPv4 to carry IPv6 care-of addresses.
In this case Mobile IP NAT Traversal could be used to send Mobile
IPv4 signaling but the resulting tunnel would be an IPv6 tunnel
(instead of UDP tunnel) between the HA and the mobile's IPv6 CoA
encapsulating both IPv4 and IPv6 traffic destined for the mobile.
While work on these issues could be beneficial, it is also separable
from the basic notion of IPv6 home address support in Mobile IPv4.
For that reason IPv6 care-of address extensions will be examined in
a separate document.
5. Applicability and usage scenarios
This specification makes the following assumptions regarding IPv4
and IPv6 configuration of the various elements.
The home agent is IPv4/v6 dual stack. The home agent supports the
IPv6 extensions defined in this document and supports IPv4 and IPv6
address pools as home addresses. The home agent is able to intercept
and tunnel appropriately all IPv4 and IPv6 packets destined to
registered mobiles.
The mechanisms described in this specification can benefit from an
access routing supporting foreign agent functionality, the
extensions described in this document and being dual stack but they
do not depend on it.
<Tsirtsis, Soliman> 11
<Dual Stack Mobile IPv4> <August> <2003>
Key for the following sections:
MN Mobile Node
CN Corresponding Node
FA Foreign Agent
HA Home Agent
HoA Home Address
CoA Care-off address
SA Source Address
DA Destination address
--> Un-tunneled traffic
==> Tunneled traffic
##> Double-tunneled traffic
5.1. Example usage scenarios
Some examples of how this specification may be used are provided in
this section. This is not an exhaustive list.
In all the examples it is assumed that the mobile and home agent
fully support the extensions described in this document and that the
mobile is dual stack with an IPv4 and an IPv6 home address.
The different examples below examine how the protocol should work
when the support for IPv6 and the extensions described in this
document varies in the access routers the mobile is visiting.
5.1.1. Foreign agent with full IPv6 support
In this case the foreign agent in the foreign network supports IPv6
extensions and enjoys native IPv6 connectivity.
MN receives FAA with A=1
MN sends RREQ(HoA,CoA,IPv6HoA)
FA forwards RREQ(HoA,CoA,IPv6HoA,R=0)
HA returns RREP(Code=0, IPv6Code=0)
HA keeps binding:
IPv6HoA -> IPv4CoA
IPv4HoA -> IPv4CoA
MN sends IPv6 traffic natively
Header SA=IPv6HoA, DA=IPv6CN
FA forwards IPv6 traffic natively
Header SA=IPv6HoA, DA=IPv6CN
HA tunnels all IPv6 traffic to the CoA
Outer Header SA=IPv4HA, DA= IPv4CoA
<Tsirtsis, Soliman> 12
<Dual Stack Mobile IPv4> <August> <2003>
Inner Header (SA=IPv6CN, DA=IPv6HoA)
FA decapsulates and delivers to the mobile.
Header SA=IPv6HoA, DA=IPv6CN
MN FA HA CN
| v6 native | | |
|------------------------------------------------------->|
| | | |
| v6 native | v6 over v4 | IPv6 |
|<----------------------|<======================|<-------|
5.1.2. Foreign agent with limited IPv6 support
In this case the foreign agent in the foreign network supports IPv6
extensions but does not have native IPv6 connectivity and is set up
to reverse all IPv6 traffic to the HA.
MN receives FAA with A=1
MN sends RREQ(HoA,CoA,IPv6HoA)
FA forwards RREQ(HoA,CoA,IPv6HoA,R=1)
HA returns RREP(Code=0, IPv6Code=0)
HA keeps binding:
IPv6HoA <=> IPv4CoA
IPv4HoA -> IPv4CoA
MN sends IPv6 traffic natively
Header SA=IPv6HoA, DA=IPv6CN
FA reverse tunnels IPv6 traffic to HA
Outer Header SA=IPv4CoA, DA=IPv4HA
Inner Header (SA=IPv6HOA, DA=IPv6CN)
HA decapsulates and forwards to the CN
Header SA=IPv6HoA, DA=IPv6CN
HA tunnels all IPv6 traffic to the CoA
Outer Header SA=IPv4HA, DA=IPv4CoA
Inner Header (SA=IPv6CN, DA=IPv6HoA)
FA decapsulates and delivers to the mobile.
Header SA=IPv6HoA, DA=IPv6CN
<Tsirtsis, Soliman> 13
<Dual Stack Mobile IPv4> <August> <2003>
MN FA HA CN
| v6 native | v6 over v4 | IPv6 |
|---------------------->|======================>|------->|
| | | |
| v6 native | v6 over v4 | IPv6 |
|<----------------------|<======================|<-------|
5.1.3. Foreign agent refuses to handle IPv6 for mobile
In this case the foreign agent in the foreign network supports IPv6
extensions but is not prepared to handle IPv6 traffic for the
specific mobile due to policy or other reason.
MN receives FAA with A=1
MN sends RREQ(HoA,CoA,IPv6HoA)
FA forwards RREQ(HoA,CoA,IPv6HoA)
HA returns RREP(Code=0, IPv6Code=2)
This degenerates into the same packet from with case 5.1.4 below
5.1.4. IPv4 only network with foreign agent support
In this case the foreign network is IPv4 ONLY and it does support
foreign agents but no IPv6 or support for IPv6 extensions.
MN receives FAA with A=0
MN sends RREQ(HoA,CoA,IPv6HoA)
FA forwards RREQ as is ignoring IPv6HoA
HA keeps binding:
IPv6HoA <=> IPv4HoA
IPv4HoA -> IPv4CoA
MN tunnels all IPv6 traffic to the HA
Outer Header SA=IPv4HoA, DA=IPv4HA
Inner Header (SA=IPv6HoA, DA=IPv6CN)
HA tunnels all IPv6 traffic to the HoA
Outer Header SA=IPv4HA, DA=IPv4CoA
Inner Header (SA=IPv4HA, DA=IPv4HoA)
Second Inner Header ((SA=IPv6CN, DA=IPv6HoA))
NOTE that this results in double-tunneling
FA decapsulates and delivers to the mobile.
<Tsirtsis, Soliman> 14
<Dual Stack Mobile IPv4> <August> <2003>
Outer Header SA=IPv4HA, DA=IPv4HoA
Inner Header (SA=IPv6CN, DA=IPv6HoA)
MN FA HA CN
| v6 over v4 | | IPv6 |
|==============================================>|------->|
| | | |
| v6 over v4 | v6 over v4 over v4 | IPv6 |
|<======================|<######################|<-------|
5.1.5. IPv4 only network with no foreign agent support
In this case the foreign network is IPv4 ONLY and it neither
supports foreign agents nor IPv6 extensions.
MN discovers collocated CoA
MN sends RREQ(HoA,CoA,IPv6HoA,R=1)
HA keeps binding:
IPv6HoA -> IPv4CoA
IPv4HoA -> IPv4CoA
MN tunnels all IPv6 traffic to the HA
Outer Header SA=IPv4HoA, DA=IPv4HA
Inner Header (SA=IPv6HoA, DA=IPv6CN)
HA tunnels all IPv6 traffic to the CoA
Outer Header SA=IPv4HA, DA=IPv4CoA
Inner Header (SA=IPv6CN, DA=IPv6HoA)
MN HA
| IPv6 over IPv4 |
|======================>|
|<======================|
| |
5.2. Visiting IPv6 ONLY networks
It is clear that the scheme presented in this specification does not
work when a mobile visits an IPv6 ONLY network since there is no way
to send Mobile IPv4 signaling packets.
<Tsirtsis, Soliman> 15
<Dual Stack Mobile IPv4> <August> <2003>
6. 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 home addresses and
should provide the same level of security for both IP versions.
MN - HA security associations are normally based on the mobile's
home address. Since there are now two home addresses (one IPv4 and
IPv6)the NAI extension [NAI] MUST be included in all registration
requests that also include an IPv6 home address extension. The
mobile - home authenticator could then be calculated based on a
secret that is based on the mobile's NAI rather than any specific
home address.
7. 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
[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
Flarion Technologies
Phone: +44-20-88260073
Email1: G.Tsirtsis@Flarion.com
Email2: tsirtsisg@yahoo.com
Hesham Soliman
Flarion Technologies
Phone: +61400500321
E-mail: H.Soliman@Flarion.com
<Tsirtsis, Soliman> 16
<Dual Stack Mobile IPv4> <August> <2003>
<Tsirtsis, Soliman> 17