< draft-ietf-mip4-dsmipv4-05.txt   draft-ietf-mip4-dsmipv4-06.txt >
Network Working Group G. Tsirtsis Network Working Group G. Tsirtsis
Internet-Draft V. Park Internet-Draft V. Park
Intended status: Standards Track Qualcomm Intended status: Standards Track Qualcomm
Expires: April 5, 2008 H. Soliman Expires: August 16, 2008 H. Soliman
Elevate Technologies Elevate Technologies
October 3, 2007 February 13, 2008
Dual Stack Mobile IPv4 Dual Stack Mobile IPv4
draft-ietf-mip4-dsmipv4-05.txt draft-ietf-mip4-dsmipv4-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 5, 2008. This Internet-Draft will expire on August 16, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This specification provides IPv6 extensions to the Mobile IPv4 This specification provides IPv6 extensions to the Mobile IPv4
protocol. The extensions allow a dual stack node to use IPv4 and protocol. The extensions allow a dual stack node to use IPv4 and
IPv6 home addresses as well as to move between IPv4 and dual stack IPv6 home addresses as well as to move between IPv4 and dual stack
network infrastructures. network infrastructures.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Implicit and Explicit Modes . . . . . . . . . . . . . . . 5 2.3. Implicit and Explicit Modes . . . . . . . . . . . . . . . 5
3. Extension Formats . . . . . . . . . . . . . . . . . . . . . . 6 3. Extension Formats . . . . . . . . . . . . . . . . . . . . . . 6
3.1. IPv6 Prefix Extension . . . . . . . . . . . . . . . . . . 6 3.1. IPv6 Prefix Request Extension . . . . . . . . . . . . . . 6
3.2. IPv6 Code Extension . . . . . . . . . . . . . . . . . . . 7 3.2. IPv6 Prefix Reply Extension . . . . . . . . . . . . . . . 7
3.3. IPv6 Tunneling Mode Extension . . . . . . . . . . . . . . 8 3.3. IPv6 Tunneling Mode Extension . . . . . . . . . . . . . . 8
4. Mobile IP Registrations . . . . . . . . . . . . . . . . . . . 10 4. Mobile IP Registrations . . . . . . . . . . . . . . . . . . . 10
4.1. Registration Request . . . . . . . . . . . . . . . . . . . 10 4.1. Registration Request . . . . . . . . . . . . . . . . . . . 10
4.2. Registration Reply . . . . . . . . . . . . . . . . . . . . 10 4.2. Registration Reply . . . . . . . . . . . . . . . . . . . . 10
4.3. Home Agent Considerations . . . . . . . . . . . . . . . . 11 4.3. Home Agent Considerations . . . . . . . . . . . . . . . . 11
4.3.1. IPv6 Packet Processing . . . . . . . . . . . . . . . . 12 4.3.1. IPv6 Packet Processing . . . . . . . . . . . . . . . . 12
4.3.2. Processing intercepted IPv6 Packets . . . . . . . . . 12 4.3.2. Processing intercepted IPv6 Packets . . . . . . . . . 12
4.3.3. IPv6 Multicast Membership Control . . . . . . . . . . 14 4.3.3. IPv6 Multicast Membership Control . . . . . . . . . . 14
4.4. Foreign Agent Considerations . . . . . . . . . . . . . . . 14 4.4. Foreign Agent Considerations . . . . . . . . . . . . . . . 15
4.5. Mobile Node Considerations . . . . . . . . . . . . . . . . 15 4.5. Mobile Node Considerations . . . . . . . . . . . . . . . . 15
4.6. Dynamic IPv6 Prefix allocation . . . . . . . . . . . . . . 17 4.6. Dynamic IPv6 Prefix allocation . . . . . . . . . . . . . . 17
4.6.1. Mobile IP Style Address Allocation . . . . . . . . . . 17 4.6.1. Mobile IP Style Address Allocation . . . . . . . . . . 17
4.7. Deregistration of IPv6 Prefix . . . . . . . . . . . . . . 18 4.7. Deregistration of IPv6 Prefix . . . . . . . . . . . . . . 18
4.8. Registration with a private CoA . . . . . . . . . . . . . 18 4.8. Registration with a private CoA . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Change history . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Change history . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Changes from v04 to v05 . . . . . . . . . . . . . . . . . 21 7.1. Changes from v04 to v05 . . . . . . . . . . . . . . . . . 21
7.2. Changes from v03 to v04 . . . . . . . . . . . . . . . . . 21 7.2. Changes from v03 to v04 . . . . . . . . . . . . . . . . . 21
7.3. Changes from v02 to v03 . . . . . . . . . . . . . . . . . 21 7.3. Changes from v02 to v03 . . . . . . . . . . . . . . . . . 21
7.4. Changes from v01 to v02 . . . . . . . . . . . . . . . . . 21 7.4. Changes from v01 to v02 . . . . . . . . . . . . . . . . . 21
7.5. Changes from v00 to v01 . . . . . . . . . . . . . . . . . 22 7.5. Changes from v00 to v01 . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
9. Normative References . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 27
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
Mobile IPv4 [RFC3344] allows a mobile node with an IPv4 address to Mobile IPv4 [RFC3344] allows a mobile node with an IPv4 address to
maintain communications while moving in an IPv4 network. maintain communications while moving in an IPv4 network.
Extensions defined in this document allow a node that has IPv4 and Extensions defined in this document allow a node that has IPv4 and
IPv6 addresses [RFC2460] to maintain communications with any of its IPv6 addresses [RFC2460] to maintain communications through any of
addresses while moving in IPv4 or dual stack networks. its addresses while moving in IPv4 or dual stack networks.
Essentially, this specification separates the Mobile IPv4 signaling Essentially, this specification separates the Mobile IPv4 signaling
from the IP version of the traffic it tunnels. Mobile IPv4 with the from the IP version of the traffic it tunnels. Mobile IPv4 with the
present extensions remains a signaling protocol that runs over IPv4, present extensions remains a signaling protocol that runs over IPv4,
and yet can set-up any combination of IPv4 and/or IPv6 over IPv4 and yet can set-up both IPv4 and IPv6 tunnels over IPv4.
tunnels.
The aim is two-fold: The aim is two-fold:
On one hand, Mobile IPv4 with the present extensions becomes a On one hand, Mobile IPv4 with the present extensions becomes a
useful transition mechanism, allowing automated but controlled useful transition mechanism, allowing automated but controlled
tunneling of IPv6 traffic over IPv4 tunnels. Dual stack nodes in tunneling of IPv6 traffic over IPv4 tunnels. Dual stack nodes in
dual stack home networks can now roam to and from legacy IPv4 dual stack home networks can now roam to and from legacy IPv4
networks, while IPv4 mobile nodes and networks can migrate to IPv6 networks, while IPv4 mobile nodes and networks can migrate to IPv6
without changing mobility management, and without upgrading all without changing mobility management, and without upgrading all
network nodes to IPv6 at once. network nodes to IPv6 at once.
skipping to change at page 5, line 15 skipping to change at page 5, line 15
2.2. Non-Goals 2.2. Non-Goals
a. The solution does not provide support for IPv6 care-of address a. The solution does not provide support for IPv6 care-of address
registration registration
2.3. Implicit and Explicit Modes 2.3. Implicit and Explicit Modes
As defined in NEMO [RFC3963], this specification also supports two As defined in NEMO [RFC3963], this specification also supports two
modes of operation; the implicit mode and the explicit mode. modes of operation; the implicit mode and the explicit mode.
In the implicit mode, the mobile node does not include a IPv6 Prefix In the implicit mode, the mobile node does not include any IPv6
Extensions in the Registration Request. The home agent can use any Prefix Request extensions in the Registration Request. The home
mechanism (not defined in this document) to determine the IPv6 agent can use any mechanism (not defined in this document) to
Prefix(es) owned by the mobile node and to set up forwarding for determine the IPv6 Prefix(es) owned by the mobile node and to set up
these prefixes. In this mode of operation all traffic to and from forwarding for these prefixes. In this mode of operation all traffic
the IPv6 prefixes MUST be encapsulated over the IPv4 tunnel between to and from the IPv6 prefixes MUST be encapsulated over the IPv4
the mobile node's IPv4 home address and the IPv4 address of the home tunnel between the mobile node's IPv4 home address and the IPv4
agent, and as such it is transparent to any foreign agent in the address of the home agent, and as such it is transparent to any
path. This IPv4 tunnel is established by mechanisms that are out of foreign agent in the path. This IPv4 tunnel is established by
the scope of this document on both the mobile node and home agent mechanisms that are out of the scope of this document on both the
when operating in the implicit mode. mobile node and home agent when operating in the implicit mode.
In the explicit mode, IPv6 address bindings are signalled explicitly. In the explicit mode, IPv6 address bindings are signalled explicitly.
The mobile node includes one or more IPv6 Prefix extensions in the The mobile node includes one or more IPv6 Prefix Request extensions
Registration Request, while the home agent returns corresponding IPv6 in the Registration Request, while the home agent returns
code extensions to accept/reject the IPv6 bindings. corresponding IPv6 Prefix Reply extensions to accept/reject the IPv6
bindings.
Additionally, in the explicit mode, the mobile node (when co-located Additionally, in the explicit mode, the mobile node (when co-located
mode of operation is used) or the foreign agent (when present) can mode of operation is used) or the foreign agent (when present) can
indicate whether IPv6 traffic should be tunneled to the care-of indicate whether IPv6 traffic should be tunneled to the care-of
address of the home address of the mobile node. address of the home address of the mobile node.
The rest of this specification is primarily defining the explicit The rest of this specification is primarily defining the explicit
mode. mode.
3. Extension Formats 3. Extension Formats
The following extensions are defined according to this specification. The following extensions are defined according to this specification.
3.1. IPv6 Prefix Extension 3.1. IPv6 Prefix Request Extension
A new skippable extension to the Mobile IPv4 header in accordance to A new skippable extension to the Mobile IPv4 registration request
the short extension format of [RFC3344] is defined here. message in accordance to the short extension format of [RFC3344] is
defined here.
This extension contains a mobile IPv6 network prefix and its prefix This extension contains a mobile IPv6 network prefix and its prefix
length. length.
0 1 2 3 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 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 | | Type | Length | Sub-Type | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Mobile IPv6 Network Prefix + + Mobile IPv6 Network Prefix +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv6 Prefix Extension Figure 1: IPv6 Prefix Request Extension
Type Type
DSMIPv4 Extensions (skippable type range to be assigned by IANA) TBD (DSMIPv4 Extension)(skippable type to be assigned by IANA)
Length Length
18 18
Sub-Type Sub-Type
1 (IPv6 Prefix) 1 ( IPv6 Prefix Request)
Prefix Length Prefix Length
Indicates the prefix length of the prefix included in the Mobile Indicates the prefix length of the prefix included in the Mobile
IPv6 Network Prefix field IPv6 Network Prefix field
Mobile IPv6 Network Prefix Mobile IPv6 Network Prefix
A sixteen-byte field containing the Mobile IPv6 Network Prefix A sixteen-byte field containing the Mobile IPv6 Network Prefix
3.2. IPv6 Code Extension 3.2. IPv6 Prefix Reply Extension
A new skippable extension to the Mobile IPv4 header in accordance to A new skippable extension to the Mobile IPv4 registration reply
the short extension format of [RFC3344] is defined here. message in accordance to the short extension format of [RFC3344] is
defined here.
This extension defines a mobile IPv6 network prefix and its prefix This extension defines a mobile IPv6 network prefix and its prefix
length, as well as a code. length, as well as a code.
0 1 2 3 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 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 | | Type | Length | Sub-Type | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved | | | Prefix Length | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
+ + + +
| | | |
+ Mobile IPv6 Network Prefix + + Mobile IPv6 Network Prefix +
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPv6 Code Extension Figure 2: IPv6 Prefix Reply Extension
Type Type
DSMIPv4 Extensions (skippable type range to be assigned by IANA) TBD (DSMIPv4 Extension)(skippable type to be assigned by IANA)
Length Length
20 20
Sub-Type Sub-Type
2 (IPv6 Code) 2 (IPv6 Prefix Reply)
Code Code
A value indicating the result of the registration request with A value indicating the result of the registration request with
respect to the IPv6 home address registration. See below for respect to the IPv6 home address registration. See below for
currently defined Codes. currently defined Codes.
Prefix Length Prefix Length
Indicates the prefix length of the prefix included in the Mobile Indicates the prefix length of the prefix included in the Mobile
IPv6 Network Prefix field IPv6 Network Prefix field
skipping to change at page 8, line 30 skipping to change at page 8, line 30
1 registration accepted, IPv6 to be tunneled to CoA 1 registration accepted, IPv6 to be tunneled to CoA
8 registration rejected, reason unspecified 8 registration rejected, reason unspecified
9 registration rejected, administratively prohibited 9 registration rejected, administratively prohibited
10 registration rejected, not home subnet 10 registration rejected, not home subnet
11 registration rejected, Duplicate Address Detection failed 11 registration rejected, Duplicate Address Detection failed
Note that a registration reply that does not include an IPv6 code Note that a registration reply that does not include an IPv6 Prefix
extension indicates that the home agent does not support IPv6 Reply extension indicates that the home agent does not support IPv6
extensions and thus has ignored such extensions in the registration extensions and thus has ignored such extensions in the registration
request. request.
3.3. IPv6 Tunneling Mode Extension 3.3. IPv6 Tunneling Mode Extension
A new skippable extension to the Mobile IPv4 header in accordance to A new skippable extension to the Mobile IPv4 registration request
the short extension format of [RFC3344] is defined here. message in accordance to the short extension format of [RFC3344] is
defined here.
By including this extension in a registration request the sender By including this extension in a registration request the sender
indicates that IPv6 traffic can be tunneled to the mobile's CoA. indicates that IPv6 traffic can be tunneled to the mobile's CoA.
0 1 2 3 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 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 | Reserved | | Type | Length | Sub-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv6 Tunneling Mode Extension Figure 3: IPv6 Tunneling Mode Extension
Type Type
DSMIPv4 Extensions (skippable type range to be assigned by IANA)
TBD (DSMIPv4 Extension) (skippable type to be assigned by IANA)
Length Length
2 2
Sub-Type Sub-Type
3 (IPv6 Tunneling Mode) 3 (IPv6 Tunneling Mode)
Reserved Reserved
Set to 0 by the sender, ignored by the receiver Set to 0 by the sender, ignored by the receiver
4. Mobile IP Registrations 4. Mobile IP Registrations
4.1. Registration Request 4.1. Registration Request
A mobile node MAY include one or more IPv6 prefix extensions defined A mobile node MAY include one or more IPv6 Prefix Request extensions
in this specification in a registration request. defined in this specification in a registration request.
A mobile node MAY include exactly one IPv6 tunneling mode extension A mobile node MAY include exactly one IPv6 tunneling mode extension
when it uses the co-located care-of address mode of [RFC3344]. when it uses the co-located care-of address mode of [RFC3344].
When IPv6 prefix and/or IPv6 tunneling mode extensions are used by When IPv6 prefix and/or IPv6 tunneling mode extensions are used by
the mobile IP client, they MUST be placed after the registration the mobile IP client, they MUST be placed after the registration
request header and before the mobile - home authentication extension request header and before the mobile - home authentication extension
so they MUST be included in the computation of any authentication so they MUST be included in the computation of any authentication
extension. extension.
skipping to change at page 10, line 36 skipping to change at page 10, line 36
When the IPv6 tunneling mode extension is used by a foreign agent it When the IPv6 tunneling mode extension is used by a foreign agent it
MUST be placed after the mobile - home authentication extensions and MUST be placed after the mobile - home authentication extensions and
before the foreign - home authentication extension so they MUST be before the foreign - home authentication extension so they MUST be
included in the computation of the foreign - home authentication included in the computation of the foreign - home authentication
extension when one exists. extension when one exists.
4.2. Registration Reply 4.2. Registration Reply
The mechanism described in the specification depends on skippable The mechanism described in the specification depends on skippable
extensions. For that reason, a registration reply that does not extensions. For that reason, a registration reply that does not
include an IPv6 code extension, in response to a registration request include an IPv6 Prefix Reply extension, in response to a registration
that included an IPv6 prefix extension, indicates that the home agent request that included an IPv6 Prefix Request extension, indicates
does not support IPv6 extensions and has ignored the request. 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, If an IPv6 Prefix Reply extension is included in a registration
the extension indicates the success or failure of the IPv6 prefix reply, then the extension indicates the success or failure of the
registration. The IPv6 code extension does not affect in any way the IPv6 prefix registration. The IPv6 Prefix Reply extension does not
code value in the registration reply header but it is superseded by affect in any way the code value in the registration reply header but
it. In other words if the code field in the registration reply it is superseded by it. In other words if the code field in the
header is set to a reject code, then all IPv6 prefix extensions are registration reply header is set to a reject code, then all IPv6
also rejected. If the code field in the registration reply header, Prefix Request extensions are also rejected. If the code field in
however, is set to an accept code, then an IPv6 code extension with a the registration reply header, however, is set to an accept code,
code field set to a reject code, only rejects the binding for the then an IPv6 Prefix Reply extension with a code field set to a reject
specific IPv6 prefix indicated in the same extension. code only rejects the binding for the specific IPv6 prefix indicated
in the same extension.
Note that a rejecting IPv6 code extension has the same effect with Note that a rejecting IPv6 Prefix Reply extension has the same effect
not including such extension at all in the sense that in both cases as not including such an extension at all in the sense that in both
the mobile node and foreign agent must act as if the corresponding cases the mobile node and foreign agent must act as if the
IPv6 prefix extension included in the registration request was corresponding IPv6 Prefix Request extension included in the
rejected. Of course, the inclusion of the IPv6 code extension allows registration request was rejected. Of course, the inclusion of the
the home agent to indicate why a given IPv6 prefix extension was IPv6 Prefix Reply extension allows the home agent to indicate why a
rejected. Consequently, home agent implementations of this given IPv6 Prefix Request extension was rejected. Consequently, home
specification SHOULD include IPv6 code extensions in registration agent implementations of this specification SHOULD include, in the
reply messages, in response to registration request messages included registration reply messages, an IPv6 Prefix Reply extension for each
IPv6 prefix extensions. IPv6 Prefix Request extension included in the corresponding
registration request message. A detailed description of how the
mobile node handles different IPv6 Prefix Reply extension code values
and the absence of IPv6 Prefix Reply extensions is given in
Section 4.5.
4.3. Home Agent Considerations 4.3. Home Agent Considerations
The dual stack home agent defined in this specification is a Mobile The dual stack home agent defined in this specification is a Mobile
IPv4 [RFC3344] Home Agent, in that it MUST operate as defined in IPv4 [RFC3344] Home Agent, in that it MUST operate as defined in
MIPv4 [RFC3344]. In addition to that the following mechanism are MIPv4 [RFC3344]. In addition to that the following mechanism are
defined in this specification. defined in this specification.
For each IPv6 prefix extension included in a valid registration For each IPv6 Prefix Request extension included in a valid
request, a home agent that supports this specification SHOULD include registration request, a home agent that supports this specification
a corresponding IPv6 code extension in the registration reply SHOULD include a corresponding IPv6 Prefix Reply extension in the
message. For each accepted IPv6 prefix the home agent MUST decide registration reply message. The home agent MUST NOT included more
the tunneling mode it is going to use and set the Code field of the than one IPv6 Prefix Reply extension for the same prefix. For each
IPv6 code extension to the appropriate value. The IPv6 prefix field accepted IPv6 prefix the home agent MUST decide the tunneling mode it
of each of the IPv6 code extensions included in the registration is going to use and set the Code field of the IPv6 Prefix Reply
reply MUST match the IPv6 prefix field of an IPv6 prefix extensions extension to the appropriate value. The IPv6 prefix field of each of
the IPv6 Prefix Reply extensions included in the registration reply
MUST match the IPv6 prefix field of an IPv6 Prefix Request extensions
included in the corresponding registration request message. included in the corresponding registration request message.
If the IPv6 home address included in a IPv6 prefix extension is not If the IPv6 home address included in an IPv6 Prefix Request extension
an on-link IPv6 address with respect to the home agent's current is not an on-link IPv6 address with respect to the home agent's
Prefix List or a prefix it is configured to serve, the home agent current Prefix List or a prefix it is configured to serve, the home
MUST reject the IPv6 prefix extension and SHOULD return an IPv6 code agent MUST reject the IPv6 Prefix Request extension and SHOULD return
extension with rejection code "registration rejected, not home an IPv6 Prefix Reply extension with rejection code "registration
subnet" in the registration reply to the mobile node. rejected, not home subnet" in the registration reply to the mobile
node.
When the IPv6 prefix extension contains a /128 IPv6 address and When the IPv6 Prefix Request extension contains a /128 IPv6 address
unless this home agent already has a binding for the given IPv6 and unless this home agent already has a binding for the given IPv6
address indicated, the home agent MUST perform Duplicate Address address indicated, the home agent MUST perform Duplicate Address
Detection [RFC4862] on the mobile node's home IPv6 link before Detection [RFC4862] on the mobile node's home IPv6 link before
returning a registration reply. This ensures that no other node on returning a registration reply. This ensures that no other node on
the home link is using the IPv6 home address. Duplicate address the home link is using the IPv6 home address. Duplicate address
detection is not required when the IPv6 prefix extension contains a detection is not required when the IPv6 Prefix Request extension
prefix. If this Duplicate Address Detection fails for the given IPv6 contains a prefix. If this Duplicate Address Detection fails for the
home address or an associated link local address, then the home agent given IPv6 home address or an associated link local address, then the
MUST reject the IPv6 prefix extensions and SHOULD return a home agent MUST reject the IPv6 Prefix Request extension and SHOULD
registration reply to the mobile node, in which the code field of a return a registration reply to the mobile node, in which the code
corresponding IPv6 code extension is set to "registration rejected, field of the corresponding IPv6 Prefix Reply extension is set to
Duplicate Address Detection failed". "registration rejected, Duplicate Address Detection failed".
When the home agent sends a successful registration reply to the When the home agent sends a successful registration reply to the
mobile node, with the Code field of a corresponding IPv6 code mobile node, with the Code field of a corresponding IPv6 Prefix Reply
extension set to one of the "registration accepted" values, the home extension set to one of the "registration accepted" values, the home
agent assures the mobile node that its IPv6 address(es) will be kept agent assures the mobile node that its IPv6 address(es) will be kept
unique by the home agent for as long as the lifetime is granted for unique by the home agent for as long as the lifetime is granted for
the binding. It also indicates the tunneling mode used i.e., the binding. It also indicates the tunneling mode used i.e.,
tunneling to home address or care-of address, based on the value of tunneling to home address or care-of address, based on the value of
the code field used in the IPv6 code extension. the code field used in the IPv6 Prefix Reply extension.
Note that for IPv6 prefixes (rather than addresses), the home agent Note that for IPv6 prefixes (rather than addresses), the home agent
does not have to perform Duplicate Address Detection. does not have to perform Duplicate Address Detection but it MUST
check that allocated prefixes are not overlapping so that all
addresses under each allocated prefix are allocated only to a single
mobile node at any one time.
4.3.1. IPv6 Packet Processing 4.3.1. IPv6 Packet Processing
Dual stack home agents MUST use Proxy Neighbor Discovery [RFC4861] on Dual stack home agents MUST use Proxy Neighbor Discovery [RFC4861] on
behalf of the nodes they serve. This allows the home agent to behalf of the nodes they serve. This allows the home agent to
receive IPv6 packets addressed to the mobile node's registered IPv6 receive IPv6 packets addressed to the mobile node's registered IPv6
address(es). address(es).
The dual stack home agent MUST act as defined in MIPv6 [RFC3775], In this respect, the dual stack home agent MUST act as defined in
Section 10.4.1. in order to intercept IPv6 packets for the mobile MIPv6 [RFC3775], Section 10.4.1. in order to intercept IPv6 packets
nodes it serves. for the mobile nodes it serves.
The home agent MUST advertise reachability for the registered The home agent MUST advertise reachability for the registered
prefixes as defined in NEMO [RFC3963], section 6.3. prefixes as defined in NEMO [RFC3963], section 6.3.
4.3.2. Processing intercepted IPv6 Packets 4.3.2. Processing intercepted IPv6 Packets
A dual stack home agent that supports the IPv6 extensions defined in A dual stack home agent that supports the IPv6 extensions defined in
this specification, MUST keep track of the following IPv6 related this specification, MUST keep track of the following IPv6 related
state for the mobile nodes it supports, in addition to what state is state for the mobile nodes it supports, in addition to the state
defined in [RFC3344]. defined in [RFC3344].
- Registered IPv6 prefix(es) and prefix length(s) - Registered IPv6 prefix(es) and prefix length(s)
- Tunneling mode for IPv6 traffic: - Tunneling mode for IPv6 traffic:
- Tunnel to IPv4 HoA and accept IPv6 tunneled from IPv4 HoA - Tunnel to IPv4 HoA and accept IPv6 tunneled from IPv4 HoA
- Tunnel to CoA and accept IPv6 tunneled from CoA - Tunnel to CoA and accept IPv6 tunneled from CoA
When IPv6 traffic is encapsulated over the tunnel between the HA and When IPv6 traffic is encapsulated over the tunnel between the HA and
the mobile node's care-off address, the tunneling mechanism used the mobile node's care-off address, the tunneling mechanism used
should be the same with the mechanism negotiated by the Mobile IP should be the same as the mechanism negotiated by the Mobile IP
header as defined in MIPv4 [RFC3344]. In that case, when IPinIP header as defined in MIPv4 [RFC3344]. In that case, when IPinIP
encapsulation is negotiated, IPv6 is tunneled over IPv4 according encapsulation is negotiated, IPv6 is tunneled over IPv4 according
to[RFC4213]. GRE and Minimal Encapsulation techniques also allow to[RFC4213]. GRE and Minimal Encapsulation techniques also allow
tunneling of IPv6 packets by setting the Protocol Type [RFC2784] and tunneling of IPv6 packets by setting the Protocol Type [RFC2784] and
Protocol [RFC2004] fields to appropriate payload type defined for Protocol [RFC2004] fields to appropriate payload type defined for
IPv6 by IANA. When, however, IPv6 traffic is encapsulated over the IPv6 by IANA. When, however, IPv6 traffic is encapsulated over the
tunnel between the HA and the mobile node's home address, IPv6 is tunnel between the HA and the mobile node's home address, IPv6 is
always tunneled over IPv4 according to [RFC4213], no matter what always tunneled over IPv4 according to [RFC4213], no matter what
tunneling mechanism is negotiated in MIPv4 signaling. tunneling mechanism is negotiated in MIPv4 signaling.
A home agent that supports this specification MUST be able to defend A home agent that supports this specification MUST be able to defend
IPv4 and IPv6 packets destined to registered mobile nodes according IPv4 and IPv6 addresses registered by mobile nodes according to
to mechanisms described in MIPv4 [RFC3344] and MIPv6 [RFC3775] mechanisms described in MIPv4 [RFC3344] and MIPv6 [RFC3775]
specifications. specifications.
Tunneling mode selection for IPv6 traffic depends on the following Tunneling mode selection for IPv6 traffic depends on the following
parameters in a successful registration request: parameters in a successful registration request:
1) Registration request is received with one or more IPv6 prefix 1) A registration request is received with one or more IPv6 Prefix
extensions. An IPv6 tunneling mode extension is not included. Request extensions. An IPv6 tunneling mode extension is not
included.
All IPv6 packets destined to the registered IPv6 prefix(es) MUST All IPv6 packets destined to the registered IPv6 prefix(es) MUST
be tunneled by the home agent to the registered IPv4 home address be tunneled by the home agent to the registered IPv4 home address
of the mobile. The home agent first encapsulates the IPv6 packet of the mobile. The home agent first encapsulates the IPv6 packetm
addressed to the mobile node's IPv4 home address, and then tunnels addressing it to the mobile node's IPv4 home address, and then
this encapsulated packet to the foreign agent. This extra level tunnels this encapsulated packet to the foreign agent. This extra
of encapsulation is required so that IPv6 routing remains level of encapsulation is required so that IPv6 routing remains
transparent to a foreign agent that does not support IPv6. When transparent to a foreign agent that does not support IPv6. When
received by the foreign agent, the unicast encapsulated packet is received by the foreign agent, the unicast encapsulated packet is
detunneled and delivered to the mobile node in the same way as any detunneled and delivered to the mobile node in the same way as any
other packet. The mobile node must decapsulate the received IPv4 other packet. The mobile node must decapsulate the received IPv4
packet it receives in order to recover the original IPv6 packet. packet in order to recover the original IPv6 packet.
Additionally, the home agent MUST be prepared to accept reverse Additionally, the home agent MUST be prepared to accept reverse
tunneled packets from the IPv4 home address of the mobile tunneled packets from the IPv4 home address of the mobile
encapsulating IPv6 packets sent by that mobile. encapsulating IPv6 packets sent by that mobile.
2) Registration request is received with one or more IPv6 prefix 2) A registration request is received with one or more IPv6 Prefix
extensions. An IPv6 tunneling mode extension is included. Request extensions. An IPv6 tunneling mode extension is included.
All IPv6 packets destined to the registered IPv6 home address(s) All IPv6 packets destined to the registered IPv6 home address(s)
SHOULD be tunneled by the home agent to the registered care-of SHOULD be tunneled by the home agent to the registered care-of
address of the mobile node. Additionally, the home agent SHOULD address of the mobile node. Additionally, the home agent SHOULD
be prepared to accept reverse tunneled packets from the care-of be prepared to accept reverse tunneled packets from the care-of
address of the mobile encapsulating IPv6 packets sent by that address of the mobile encapsulating IPv6 packets sent by that
mobile. The home agent MAY ignore the presence of the IPv6 mobile. The home agent MAY ignore the presence of the IPv6
tunneling mode extension and act as in case (1) above. tunneling mode extension and act as in case (1) above.
Packets addressed to the mobile node's IPv6 link-local address MUST Packets addressed to the mobile node's IPv6 link-local address MUST
NOT be tunneled to the mobile node. Instead, these packets MUST be NOT be tunneled to the mobile node. Instead, these packets MUST be
discarded and the home agent SHOULD return an ICMPv6 Destination discarded and the home agent SHOULD return an ICMPv6 Destination
Unreachable, Code 3, message to the packet's Source Address (unless Unreachable, Code 3, message to the packet's Source Address (unless
this Source Address is a multicast address). this Source Address is a multicast address).
The home agent SHOULD check that all IPv6 packets received from the The home agent SHOULD check that all inner IPv6 packets received from
mobile node over a tunnel from the home address or the care-of the mobile node over a tunnel with outer source address the home
address, include a source address that falls under the registered address or the care-of address, include a source address that falls
IPv6 prefix(es) for that mobile node. If the source address of a under the registered IPv6 prefix(es) for that mobile node. If the
tunneled packet is not the registered IPv4 care-of address or the source address of the outer header of a tunneled packet is not the
registered IPv4 home addresses, the packet SHOULD be dropped. If the registered IPv4 care-of address or the registered IPv4 home
source address of the encapsulated packet does not match any of the addresses, the packet SHOULD be dropped. If the source address of
the inner header of an tunneled packet does not match any of the
registered home addresses and/or prefixes the packet SHOULD be registered home addresses and/or prefixes the packet SHOULD be
dropped. dropped.
Interception and tunneling IPv6 multicast addressed packets on the Interception and tunneling IPv6 multicast addressed packets on the
home network are only done if the home agent supports multicast group home network is only done if the home agent supports multicast group
membership control messages from the mobile node as described in the membership control messages from the mobile node as described in the
next section. Multicast IPv6 packets addressed to a multicast next section. Multicast IPv6 packets addressed to a multicast
address with link-local scope [RFC4291], to which the mobile node is address with link-local scope [RFC4291], to which the mobile node is
subscribed, MUST NOT be tunneled to the mobile node. These packets subscribed, MUST NOT be tunneled to the mobile node. These packets
SHOULD be silently discarded (after delivering to other local SHOULD be silently discarded (after delivering to other local
multicast recipients). Multicast packets addressed to a multicast multicast recipients). Multicast packets addressed to a multicast
address with a scope larger than link-local, but smaller than global address with a scope larger than link-local, but smaller than global
(e.g., site- local and organization-local [RFC4291], to which the (e.g., site- local and organization-local [RFC4291], to which the
mobile node is subscribed, SHOULD NOT be tunneled to the mobile node. mobile node is subscribed, SHOULD NOT be tunneled to the mobile node.
Multicast packets addressed with a global scope, to which the mobile Multicast packets addressed with a global scope, to which the mobile
skipping to change at page 14, line 43 skipping to change at page 15, line 9
[RFC3775], Section 10.4.3. The only clarification required for the [RFC3775], Section 10.4.3. The only clarification required for the
purpose of this specification is that all MLD [RFC2710] or MLDv2 purpose of this specification is that all MLD [RFC2710] or MLDv2
[RFC3810] messages between the mobile node and the home agent MUST be [RFC3810] messages between the mobile node and the home agent MUST be
tunneled between the mobile node and the home agent, bypassing the tunneled between the mobile node and the home agent, bypassing the
foreign agent. foreign agent.
4.4. Foreign Agent Considerations 4.4. Foreign Agent Considerations
A dual stack foreign agent that supports the IPv6 extensions defined A dual stack foreign agent that supports the IPv6 extensions defined
in this specification MUST keep track of the following IPv6 related in this specification MUST keep track of the following IPv6 related
state for the mobile IP clients it supports in addition to what state state for the mobile IP clients it supports in addition to the state
is defined in [RFC3344]. defined in [RFC3344].
- IPv6 Prefix(es) and Prefix Length(s) - IPv6 Prefix(es) and Prefix Length(s)
- Tunneling mode for IPv6 traffic: - Tunneling mode for IPv6 traffic:
- accept IPv6 encapsulated in IPv4 and reverse tunnel IPv6 - accept IPv6 encapsulated in IPv4 and reverse tunnel IPv6
- IPv6 is tunneled directly to the IPv4 HoA so the foreign agent - IPv6 is tunneled directly to the IPv4 HoA so the foreign agent
will not provide encapsulation/decapsulation services for IPv6 will not provide encapsulation/decapsulation services for IPv6
traffic for this mobile. traffic for this mobile.
When a foreign agent receives a registration request with IPv6 prefix When a foreign agent receives a registration request with IPv6 Prefix
extension(s) it has the following choices: Request extension(s) it has the following choices:
1) Ignore the extension(s). The registration request is forwarded as 1) Ignore the extension(s). The registration request is forwarded as
is to the home agent. is to the home agent.
The foreign agent SHOULD operate according to MIPv4 [RFC3344] The foreign agent SHOULD operate according to MIPv4 [RFC3344]
2) Attach an IPv6 tunneling mode extension to the registration 2) Attach an IPv6 tunneling mode extension to the registration
request sent to the home agent. request sent to the home agent.
The foreign agent MUST be prepared to decapsulate and deliver IPv6 The foreign agent MUST be prepared to decapsulate and deliver IPv6
skipping to change at page 15, line 40 skipping to change at page 16, line 5
mode of operation, the foreign agent MUST NOT include an IPv6 mode of operation, the foreign agent MUST NOT include an IPv6
tunneling mode extension in the registration request messages sent tunneling mode extension in the registration request messages sent
from that mobile node. from that mobile node.
4.5. Mobile Node Considerations 4.5. Mobile Node Considerations
A dual stack mobile node that supports the extensions described in A dual stack mobile node that supports the extensions described in
this document MAY use these extensions to register its IPv6 home this document MAY use these extensions to register its IPv6 home
address(es) and/or prefix(es) while moving between access routers. address(es) and/or prefix(es) while moving between access routers.
The mobile node MAY include one or more IPv6 Prefix extension(s) in The mobile node MAY include one or more IPv6 Prefix Request
the registration request. extension(s) in the registration request.
In this case the mobile MUST take the following action depending on In this case the mobile MUST take the following action depending on
the extensions included in the registration reply it receives in the extensions included in the registration reply it receives in
response to the registration request: response to the registration request:
1) The registration reply does not include any IPv6 code extensions. 1) The registration reply does not include any IPv6 Prefix Reply
extensions.
The mobile node SHOULD assume that the home agent does not support The mobile node SHOULD assume that the home agent does not support
the extensions defined in this specification. The mobile node the extensions defined in this specification. The mobile node
SHOULD continue to operate according to MIPv4 [RFC3344]. SHOULD continue to operate according to MIPv4 [RFC3344].
2) The registration reply includes one or more IPv6 code extensions. 2) The registration reply includes one or more IPv6 Prefix Reply
extensions.
The mobile node MUST match each IPv6 code extension with one of The mobile node MUST match each IPv6 Prefix Reply extension with
the IPv6 prefix extensions earlier included in the corresponding one of the IPv6 Prefix Request extensions earlier included in the
registration request message. corresponding registration request message.
If a matching IPv6 code extension is not included for one or more If a matching IPv6 Prefix Reply extension is not included for one
of corresponding IPv6 prefix extensions included in the or more of corresponding IPv6 Prefix Request extensions included
registration request message, the mobile node SHOULD assume that in the registration request message, the mobile node SHOULD assume
these IPv6 prefixes are rejected. that these IPv6 prefixes are rejected.
For each matching IPv6 code extensions the mobile node MUST For each matching IPv6 Prefix Reply extensions the mobile node
inspect the Code field. If the field is set to a rejection code MUST inspect the Code field. If the field is set to a rejection
then the corresponding IPv6 prefix registration has been rejected. code then the corresponding IPv6 prefix registration has been
If the Code field is set to an acceptance code then the rejected. If the Code field is set to an acceptance code then the
corresponding IPv6 prefix registration has been accepted. corresponding IPv6 prefix registration has been accepted.
If the Code field is set to "0" then the mobile node MUST be If the Code field is set to "0" then the mobile node MUST be
prepared to send/receive IPv6 packets encapsulated in the prepared to send/receive IPv6 packets encapsulated in the
bidirectional tunnel between the home agent address and the bidirectional tunnel between the home agent address and the
registered IPv4 home address of the mobile node. registered IPv4 home address of the mobile node.
If the Code field is set to "1" then the mobile node MUST act as If the Code field is set to "1" then the mobile node MUST act as
follows: follows:
skipping to change at page 16, line 50 skipping to change at page 17, line 17
bidirectional tunnel between the home agent address and its co- bidirectional tunnel between the home agent address and its co-
located care-of address. located care-of address.
The mobile node SHOULD include exactly one IPv6 tunneling mode The mobile node SHOULD include exactly one IPv6 tunneling mode
extension if it uses the co-located care-of address model and it extension if it uses the co-located care-of address model and it
wants to request that IPv6 packets are tunneled to its co-located wants to request that IPv6 packets are tunneled to its co-located
care-of address. If the mobile node uses the co-located care-of care-of address. If the mobile node uses the co-located care-of
address model but it does not include the IPv6 tunneling mode address model but it does not include the IPv6 tunneling mode
extension the home agent will tunnel IPv6 traffic to the mobile extension the home agent will tunnel IPv6 traffic to the mobile
node's home address. The mobile node MUST NOT include an IPv6 node's home address. The mobile node MUST NOT include an IPv6
tunneling mode extension if it uses the care-of address mode of tunneling mode extension if it uses the foreign agent care-of address
operation. Note that if the mobile includes an IPv6 tunneling mode mode of operation. Note that if the mobile includes an IPv6
extension in this case, IPv6 packets could be tunneled to the FA by tunneling mode extension in this case, IPv6 packets could be tunneled
the HA. The FA is then likely to drop them since it may not have to the FA by the HA. The FA is then likely to drop them since it may
appropriate state to process them. not have appropriate state to process them.
4.6. Dynamic IPv6 Prefix allocation 4.6. Dynamic IPv6 Prefix allocation
The dynamic IPv6 prefix allocation described in the following section The dynamic IPv6 prefix allocation described in the following section
reuses the Mobile IPv4 mechanisms defined for IPv4 address reuses the Mobile IPv4 mechanisms defined for IPv4 address
allocation. An implementation can use a different mechanism to allocation. An implementation can use a different mechanism to
dynamically allocate IPv6 addresses in which case once such IPv6 dynamically allocate IPv6 addresses in which case once such IPv6
addresses are allocated, they can be registered using the extensions addresses are allocated, they can be registered using the extensions
and mechanism already described. and mechanism already described.
How a home agent decides to provide, or accept, an IPv6 home address
or prefix for a given mobile node, is out of scope of this
specification. Local configuration or external authorization via an
authorization system e.g., Diameter [RFC3588], or other mechanisms
may be used to make such determination
4.6.1. Mobile IP Style Address Allocation 4.6.1. Mobile IP Style Address Allocation
A mobile node may include one or more IPv6 prefix extensions with the A mobile node may include one or more IPv6 Prefix Request extensions
IPv6 prefix field set to zero. The mobile node MAY set the prefix with the IPv6 prefix field set to zero. The mobile node MAY set the
length field of such extensions to zero or to a length of its choice prefix length field of such extensions to zero or to a length of its
as a hint to the home agent. Such IPv6 prefix extensions indicate choice as a hint to the home agent. Such IPv6 Prefix Request
that the mobile node requests IPv6 address(es) and prefix(es) to be extensions indicate that the mobile node requests IPv6 address(es)
assigned to it by the home agent. and prefix(es) to be assigned to it by the home agent.
A home agent receiving an IPv6 prefix extension with the IPv6 prefix A home agent receiving an IPv6 Prefix Request extension with the IPv6
field set to zero MAY return an IPv6 code extension with the IPv6 prefix field set to zero MAY return an IPv6 Prefix Reply extension
prefix field set to the IPv6 prefix allocated to the mobile node. with the IPv6 prefix field set to the IPv6 prefix allocated to the
The length of that prefix is at the discretion of the home agent. mobile node. The length of that prefix is at the discretion of the
The home agent may take into account the prefix length hint if one is home agent. The home agent may take into account the prefix length
included in the IPv6 prefix extension. hint if one is included in the IPv6 Prefix Request extension.
A mobile node MAY include one or more IPv6 prefix extensions with the A mobile node MAY include one or more IPv6 Prefix Request extensions
IPv6 Prefix field set to ::interface_identifier, where with the IPv6 Prefix field set to ::interface_identifier, where
interface_identifier is the unique layer 2 address of the client. interface_identifier is the unique layer 2 address of the client.
The interface_identifier MUST be less than or equal to 64 bits in The interface_identifier MUST be less than or equal to 64 bits in
length. In this case the prefix length field SHOULD be set to 128. length. In this case the prefix length field MUST be set to 128.
The home agent MAY in this case return an IPv6 Code extension with: The home agent MAY in this case return an IPv6 Prefix Reply extension
with:
- the IPv6 prefix field set to PREFIX:: and the prefix length - the IPv6 prefix field set to PREFIX:: and the prefix length
field set to the desired prefix length value. In this case the field set to the desired prefix length value. In this case the
PREFIX:: subnet is allocated to the mobile node, which should PREFIX:: subnet is allocated to the mobile node, which should
proceed in constructing IPv6 addresses as defined in [RFC4862] proceed in constructing IPv6 addresses as defined in [RFC4862]
- the IPv6 prefix field set to PREFIX::interface_identifier and - the IPv6 prefix field set to PREFIX::interface_identifier and
the prefix length field set to 128. In this case an individual the prefix length field set to 128. In this case an individual
IPv6 address is allocated to the mobile node. IPv6 address is allocated to the mobile node.
skipping to change at page 18, line 17 skipping to change at page 18, line 35
The mobile IP registration lifetime included in the registration The mobile IP registration lifetime included in the registration
request header is valid for all the bindings created by the request header is valid for all the bindings created by the
registration request, which may include bindings for IPv6 address(es) registration request, which may include bindings for IPv6 address(es)
and prefix(es). and prefix(es).
A registration request with a zero lifetime can be used to remove all A registration request with a zero lifetime can be used to remove all
bindings from the home agent. bindings from the home agent.
A re-registration request with non-zero lifetime can be used to A re-registration request with non-zero lifetime can be used to
deregister some of the registered IPv6 prefixes by not including deregister some of the registered IPv6 prefixes by not including
corresponding IPv6 prefix extensions in the registration request corresponding IPv6 Prefix Request extensions in the registration
message. request message.
4.8. Registration with a private CoA 4.8. Registration with a private CoA
If the care-of address is a private address then Mobile IP NAT If the care-of address is a private address then Mobile IP NAT
Traversal as [RFC3519] MAY be used in combination with the extensions Traversal as [RFC3519] MAY be used in combination with the extensions
described in this specification. In that case, to transport IPv6 described in this specification. In that case, to transport IPv6
packets, the next header field of the Mobile Tunnel Data message packets, the next header field of the Mobile Tunnel Data message
header [RFC3519] MUST be set to the value for IPv6." header [RFC3519] MUST be set to the value for IPv6.
5. Security Considerations 5. Security Considerations
This specification operates in the security constraints and This specification operates in the security constraints and
requirements of [RFC3344]. It extends the operations defined in requirements of [RFC3344]. It extends the operations defined in
[RFC3344] for IPv4 home addresses to cover home IPv6 addresses [RFC3344] for IPv4 home addresses to cover home IPv6 addresses
prefixes and provides the same level of security for both IP address prefixes and provides the same level of security for both IP address
versions. versions.
As defined in the security considerations section of RFC3344, ingress As defined in the security considerations section of RFC3344, ingress
skipping to change at page 20, line 7 skipping to change at page 20, line 7
whether the encapsulated (inner) header is IPv4 or IPv6. whether the encapsulated (inner) header is IPv4 or IPv6.
In addition to that, the home agent SHOULD check that the source In addition to that, the home agent SHOULD check that the source
address of the inner header is a register IPv4 or IPv6 home address address of the inner header is a register IPv4 or IPv6 home address
for this mobile node. If that is not the case, the home agent SHOULD for this mobile node. If that is not the case, the home agent SHOULD
silently discard the packet and log the event as a security silently discard the packet and log the event as a security
exception. exception.
6. IANA Considerations 6. IANA Considerations
This specification requires the allocation of a new number for This specification requires the allocation of a new type number for
DSMIPv4 extensions, from the space of numbers for skippable mobility DSMIPv4 extensions, from the space of numbers for skippable mobility
extensions (i.e., 128-255) defined for Mobile IPv4 [RFC3344] at extensions (i.e., 128-255) defined for Mobile IPv4 [RFC3344] at
http://www.iana.org/assignments/mobileip-numbers. http://www.iana.org/assignments/mobileip-numbers.
This specification also creates a new subtype space for the type This specification also creates a new subtype space for the type
number of this extension. The subtype values 1, 2 and 3 are defined number of this extension. The subtype values 1, 2 and 3 are defined
in this specification. in this specification.
Finally, this specification creates a new space for the Code field of
the IPv6 Prefix Reply extension. Values 0, 1, 8, 9, 10, 11 are
defined in this specification. Values 0-7 are reserved for accept
codes and the rest of the values are reserved for reject values.
Similar to the procedures specified for Mobile IPv4 [RFC3344] number Similar to the procedures specified for Mobile IPv4 [RFC3344] number
spaces, future allocations from this number space require expert spaces, future allocations from this number space require expert
review [RFC2434]. review [RFC2434].
7. Change history 7. Change history
NOTE TO RFC EDITOR: Remove section Section 7 before publication. NOTE TO RFC EDITOR: Remove Section 7 before publication.
7.1. Changes from v04 to v05 7.1. Changes from v04 to v05
Corrected nits. Corrected nits.
Added IANA considerations section. Added IANA considerations section.
7.2. Changes from v03 to v04 7.2. Changes from v03 to v04
Clarified that DAD is only needed on IPv6 addresses and not prefixes, Clarified that DAD is only needed on IPv6 addresses and not prefixes,
skipping to change at page 24, line 5 skipping to change at page 24, line 5
Numerous editorial and clarification changes. Numerous editorial and clarification changes.
8. Acknowledgements 8. Acknowledgements
Thanks to Pat Calhoun, Paal Engelstad, Tom Hiller and Pete McCann for Thanks to Pat Calhoun, Paal Engelstad, Tom Hiller and Pete McCann for
earlier work on this subject. Thanks also to Alex Petrescu for earlier work on this subject. Thanks also to Alex Petrescu for
suggesting the use of additional mechanisms for dynamic IPv6 address suggesting the use of additional mechanisms for dynamic IPv6 address
allocation. Special thanks also to Sri Gundavelli and Kent Leung for allocation. Special thanks also to Sri Gundavelli and Kent Leung for
their thorough review and suggestions. their thorough review and suggestions.
9. Normative References 9. References
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 9.1. Normative References
October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP,
revised", RFC 3024, January 2001. revised", RFC 3024, January 2001.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
Network Address Translation (NAT) Devices", RFC 3519, Network Address Translation (NAT) Devices", RFC 3519,
May 2003. May 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005. RFC 3963, January 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
9.2. Informative References
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
Authors' Addresses Authors' Addresses
George Tsirtsis George Tsirtsis
Qualcomm Qualcomm
Phone: +908-947-7059 Phone: +908-947-7059
Email: tsirtsis@qualcomm.com; tsirtsisg@yahoo.com Email: tsirtsis@qualcomm.com; tsirtsisg@yahoo.com
Vincent Park Vincent Park
Qualcomm Qualcomm
skipping to change at page 27, line 7 skipping to change at page 27, line 7
Email: vpark@qualcomm.com Email: vpark@qualcomm.com
Hesham Soliman Hesham Soliman
Elevate Technologies Elevate Technologies
Phone: +614-111-410-445 Phone: +614-111-410-445
Email: hesham@elevatemobile.com Email: hesham@elevatemobile.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 73 change blocks. 
179 lines changed or deleted 222 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/