One document matched: draft-damic-netlmm-pmip6-ind-discover-00.txt
Network Working Group D. Damic
Internet-Draft D. Premec
Intended status: Standards Track B. Patil
Expires: December 9, 2007 M. Sahasrabudhe
Nokia Siemens Networks
June 7, 2007
Proxy Mobile IPv6 indication and discovery
draft-damic-netlmm-pmip6-ind-discover-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 9, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Proxy Mobile IPv6 is a network-based mobility protocol and is able to
manage the mobility of an IP host as it moves across different points
of attachment within the mobility domain. The IP host whose mobility
is being managed by the network is unaware of the existence of Proxy
Mobile IPv6 in the network or mobility being managed on its behalf.
This draft proposes mechanisms by which the host is informed of proxy
Damic, et al. Expires December 9, 2007 [Page 1]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
mobile IPv6 support in a network that it attaches to as well as the
ability for the host to discover such capability in the attached
network. The ability of the host to discover or be aware of proxy
mobile IPv6 support in the network enables better decision making in
terms of the type of mobility protocol used for IP mobility.
Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Router Advertisment extension . . . . . . . . . . . . . . 5
4.2. Router Solicitation extension . . . . . . . . . . . . . . 7
4.3. DHCPv6 extensions . . . . . . . . . . . . . . . . . . . . 8
4.3.1. Home Network Identifier Option . . . . . . . . . . . . 9
4.3.2. Home Network Information Option . . . . . . . . . . . 10
4.3.3. Note on DHCPv4 . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Damic, et al. Expires December 9, 2007 [Page 2]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
1. Introduction and Scope
Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] is a network-based
mobility management protocol in which the host is not involved in any
signaling to enable IP mobility as it moves and changes its point of
attachment. This feature complements the mobility protocols such as
Mobile IPv6 [RFC3775] in which the host is involved in mobility
management. On the other hand, nodes that are capable for mobility
management themselves (i.e., implement the MIP6 functionality in the
IP stack) might not require such kind of service.
PMIP6 protocol as specified in [I-D.ietf-netlmm-proxymip6] is
applicable within the scope of a single PMIP6 domain. However
deployment scenarios may include a broader scope than a single
domain.
Scenarios where mobility is managed by the network are usually
referred as running in Proxy MIP (PMIP) mode. Analogously, when
mobile nodes manage mobility themselves we are talking about host-
based mobility. There are several scenarios in which host-based
Mobile IP and proxy MIP support co-exist in the same network. For
example:
o Different mobility modes within a single PMIP6 domain:
In case of nomadic users, the network needs to provide mobility
services simultaneously for nodes with and those without the
built-in mobility support. Each mobility mode, either PMIP6 or
host-based MIP6, needs to be individually recognized and
appropriately handled by the network.
o Session continuation accros different domains:
Mobile node roaming in/out of the PMIP6 domain needs to continue
the ongoing session either retaining or substituting the assigned
mobility mode. For example, MN running a MIP6 session in the
network moves to a PMIP6-enabled domain. Depending on the
privileges and policies, the session should either continue with
the host-based mobility, or the network would take over the
mobility management and begin handling the MN in the PMIP6 mode.
Existing IPv6 mechanisms, such as Neighbor Discovery protocol (NDP)
or DHCPv6, are currently insufficient for the purpose of mobility
mode detection or capability negotiation. This document proposes
means by which the network can indicate its PMIP6 capabilities and
provide specific configuration parameters to mobile nodes. The
proposal also provides a method by which the MN can proactively
choose the mobility management scheme.
Damic, et al. Expires December 9, 2007 [Page 3]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Problem Statement
In the PMIP6 domain MN may use stateless address autoconfiguration
(SLAAC) or DHCPv6 to configure its addresses. The address
configuration parameters provided to the MN MAY be different in cases
when supporting PMIP6 or host-based MIP6.
In case PMIP is used as a mechanism for global mobility or for
emulating the home link to the MN, the network obtains the home
prefix for the MN and provides the same to the MN. Prefix is
assigned to the MN for the entire session, and must be consistently
advertised throughout the entire PMIP6 domain.
For MIP6 capable nodes it is sufficient to supply any globallly
routable local prefix (address) that MN will use to configure the
care-of address (CoA) on its interface.
The AR or MAG in an access network should be able to interpret the
mobility preference and capability of the host via either the router
solicitation (RS) or DHCP request received from the MN. NDP and DHCP
messages cannot be used as specific mobility triggers. The Profile
associated with a user in AAA for example cannot really be used as an
indication about the mobility protocol to be used for a host as the
device and capability may change. For example: information that
subscriber is allowed PMIP6 does not provide indication on what kind
of terminal subscriber is actually using (does it implement MIP6), or
is it aiming to utilize host-based mobility.
Explicit mechanisms and protocol extensions are needed to:
o enable the access network to advertise the PMIP6 feature or
function to hosts
o provide the host with more reliable parameters allowing it to
choose the mobility protocol based on its capabilities or other
criteria
o allow MNs to signal their mobility mode preferences
4. Proposed Solutions
This document proposes extensions to the NDP and DHCP protocols that
may serve as triggers for PMIP6 mobility selection. These extensions
Damic, et al. Expires December 9, 2007 [Page 4]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
include: a new flag in the RA Prefix Information Option, a new option
for the Router Solicitation message, and new options for the DHCP
messages.
4.1. Router Advertisment extension
The AR can include multiple on-link prefixes in one RA message, where
each individual prefix is contained in the Prefix Information Option.
In case the access network does support PMIP6, the AR could advertise
this capability in the RA messages it sends. Within its domain, the
AR may advertise PMIP6 prefixes as default. In some occasions along
with the specific PMIP6 prefix, the advertised prefix list should
include local scope IPv6 prefix(es) as well.
In order to specifically indicate a PMIP6 local prefix, the AR should
set a specific "P" flag in the Prefix Information Option header.
When this flag is set, it indicates network supporting PMIP6 is
providing additional prefix with a local scope validity.
Mobile nodes which are capable of processing the extended Prefix
Information option can configure their care-of address using this
prefix, and thereby continue with host-based mobility management
while roaming through the PMIP6 domain.
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 | Prefix Length |L|A|P|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Prefix Information Option containing PMIP6 flag
Fields:
Damic, et al. Expires December 9, 2007 [Page 5]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
Type 3
Length 4
Prefix Length
8-bit unsigned integer. The number of leading bits in the Prefix
that are valid. The value ranges from 0 to 128.
L
1-bit on-link flag. When set, indicates that this prefix can be
used for on-link determination. When not set the advertisement
makes no statement about on-link or off-link properties of the
prefix. For instance, the prefix might be used for address
configuration with some of the addresses belonging to the prefix
being on-link and others being off-link
A
1-bit autonomous address-configuration flag. When set indicates
that this prefix can be used for autonomous address configuration
as specified in [RFC2462].
P
1-bit PMIP6 local-prefix flag. When set indicates the option
contains a PMIP6 local prefix, valid for configuration of a
local IPv6 address or a MIP6 CoA.
Reserved1
6-bit unused field. It MUST be initialized to zero by the sender
and MUST be ignored by the receiver.
Valid Lifetime
32-bit unsigned integer. The length of time in seconds (relative
to the time the packet is sent) that the prefix is valid for the
purpose of on-link determination. A value of all one bits
(0xffffffff) represents infinity. The Valid Lifetime is also used
by [RFC2462].
Preferred Lifetime
32-bit unsigned integer. The length of time in seconds (relative
to the time the packet is sent) that addresses generated from the
prefix via stateless address autoconfiguration remain preferred
Damic, et al. Expires December 9, 2007 [Page 6]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
[RFC2462]. A value of all one bits (0xffffffff) represents
infinity. See [RFC2462].
Reserved2
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Prefix
An IP address or a prefix of an IP address. The Prefix Length
field contains the number of valid leading bits in the prefix.
The bits in the prefix after the prefix length are reserved and
MUST be initialized to zero by the sender and ignored by the
receiver. A router SHOULD NOT send a prefix option for the link-
local prefix and a host SHOULD ignore such a prefix option. In
case "P" flag has been set, the Prefix field contains the PMIP6
HNP.
Description:
The Prefix Information option provide hosts with on-link prefixes and
prefixes for Address Autoconfiguration. In case "P" flag is set, the
option provides the HNP for PMIP6 MN-HoA Address Autoconfiguration.
The Prefix Information option appears in Router Advertisement packets
and MUST be silently ignored for other messages.
4.2. Router Solicitation extension
Mobile node aware of different mobility modes may explicitly request
a specific mobility service using a new Mobility Mode option in the
RS message.
Routers in the network not supporting PMIP6 or unable to process this
option must ignore it. Otherwise the AR will acquire the PMIP6 HNP
for the mobile node, and provide it in the responding RA using the
extended Prefix Information option.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |P| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pad ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Damic, et al. Expires December 9, 2007 [Page 7]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
Figure 2. Mobility Mode option for RS
Type
8-bit identifier for the Mobility Mode option (to be assigned by
IANA)
Length
8-bit unsigned integer. The length of the option in octets
(including the type and length fields)
Flags
8-bit field containing flags set by MN to negotiate on the
mobility service type.
The most significant bit in this field is labled as PMIP6 "P"
flag. It is set by MN when explicitly requesting PMIP6 mobility
from the network.
Reserved
8-bit field reserved for future use.
Pad
Variable-length field. This field is used to align the option
into units of 8 octets.
4.3. DHCPv6 extensions
This section describes how a mobile node can use DHCP [RFC3315] to
detect that it is located in the PMIP domain and to inform the AR of
its preference to use PMIP6 or host-based MIP6 as a mobility
management protocol.
By using DHCP, mobile node and the AR are able to exchange following
information:
o AR can let the mobile node know that the access network supports
the PMIP protocol
o AR can inform the mobile node of the PMIP prefix
o mobile node can inform the AR wheather it should provide a PMIP
service to it or if the MN prefers to run MIP by itself
Draft [I-D.ietf-mip6-hiopt] defines new DHCPv6 options used to
facilitate bootstraping of a MIP6 based mobility service. One of the
options introduced by the draft is a Home Network Identifier option
Damic, et al. Expires December 9, 2007 [Page 8]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
(OPTION_MIP6-HNID) by which the mobile node can request information
about the home network and indicate its preference for the location
of the HA: in the visited network or in the target network.
4.3.1. Home Network Identifier Option
The Home Network Identifier option is extended with an additional
code to allow the mobile node to explicitely request information
about the availability of the PMIP service at its current point of
attachment.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_MIP6-HNID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id-type | reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Home Network Identifier .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Home Network Identifier option format
option-code
OPTION_MIP6-HNID (TBD)
option-len
Total length of the option in octets
id-type
The type of Home Network Identifier:
0 Visited domain (local ASP)
1 The target network
2 No preference
3 PMIP domain
When the mobile node wants to learn if the access network supports
PMIP service, it SHALL include Home Network Option setting the id-
type field to 3. When the id-type is set to 3, the Home Network
Identifier field MAY be set to 0 if the mobile node wants to learn
about the PMIP support in the local domain. Alternatively, if the
mobile node wants to inquire about the support for PMIP service in a
Damic, et al. Expires December 9, 2007 [Page 9]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
particular network, the mobile node MAY set the Home Network
Identifier field to the network realm as FQDN.
The mobile node can learn information about a particular network type
by sending separate Information Request messages with different id-
types. If the mobile node wants to acquire the information about the
visited network, target network and the PMIP domain in a single
message exchange, it MAY include several Home Network Identifier
options in the reguest message. There may be several Home Network
Identifier options with the id-type 1 and/or 3 in a single message.
4.3.2. Home Network Information Option
Draft [I-D.ietf-mip6-hiopt] defines a new DHCPv6 option Home Network
Information option. This option is used by the DHCP server to convey
to the mobile node information about inquired network(s). The
information provided could be a home subnet prefix (one or more),
home agent address(es) and home agent FQDN(s). There is a separate
suboption for each type of information provided (prefix, home agent
address and home agent FQDN).
If the id-type field of the Home Network Identifier option indicates
the network which is not supported by this access network or if the
mobile node is not authorized for the requested network, the DHCP
server's reponse SHALL include the Home Network Information option
with the option-len set to zero.
If the mobile node inquiered information about the PMIP domain, the
relevant information about the PMIP domain will be provided in the
Home Network Information option. In this case the only relevant
information is prefix. Since in PMIP mode the mobile node does not
interact with the home agent directly, home agent's address and FQDN
SHALL not be provided to the mobile node.
If the access network wants to force the PMIP mode for the mobile
node, it MAY respond to both visited domain and target domain(s)
inquieris with a Home Network Information option containing the
0-length data.
4.3.2.1. Avoiding the premature prefix advertisment
When the netlmm domain supports the DHCP extensions specified here,
the AR may want to defer advertisment of the prefix until both the
mobile node and network have exchanged their capabilites and
preferences for a mobility management mode. This can be achived by
setting the 'M' or 'O' flag in Router Advertisment message forcing
the mobile node to use DHCP. In this way the AR can delay the prefix
advertisment until the DHCP exchange is completed.
Damic, et al. Expires December 9, 2007 [Page 10]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
4.3.2.2. Choosing the PMIP mode
If the client decides that it would use PMIP service offered by the
access network, it SHALL send the (additional) Information Request
message containing Home Network Information sub-option with the Home
Network Information field containing the PMIP network prefix.
4.3.3. Note on DHCPv4
Home Network Identifier option and Home Network Information option
defined for DHCPv6 could be adopted, with some modifications, for
DHCPv4. This would enable the single stack IPv4 host to become aware
of the PMIP service support by the access network. Wheather the
approach of adopting the DHCPv6 options for DHCPv4 is feasible in
this particular case is for futher study.
The IPv4 host would include the Home Network Identifier option,
indicating its preferences, in the DHCPDISCOVER message. DHCPOFFER
message would include Home Network Information option indicating the
network type(s) supported by the access network and authorized for
the mobile node. The mobile node would indicate its choice in the
DHCPREQUEST message by including the Home Network Information option
with the id-type field set to the selected network type.
5. Security Considerations
TBD.
6. IANA Considerations
The following Extension Types MUST be assigned by IANA: TBD.
7. Acknowledgements
TBD.
8. Normative References
[I-D.ietf-mip6-hiopt]
Jang, H., "DHCP Option for Home Information Discovery in
MIPv6", draft-ietf-mip6-hiopt-03 (work in progress),
May 2007.
[I-D.ietf-netlmm-proxymip6]
Damic, et al. Expires December 9, 2007 [Page 11]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
S. Gundavelli et al., "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-00 (work in progress),
April 2007.
[RFC2023] Haskin, D. and E. Allen, "IP Version 6 over PPP",
RFC 2023, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Authors' Addresses
Damjan Damic
Nokia Siemens Networks
Zagrebacka 145a
Zagreb 10000
Croatia
Phone: +385 1-6331-337
Email: damjan.damic@siemens.com
Damic, et al. Expires December 9, 2007 [Page 12]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
Domagoj Premec
Nokia Siemens Networks
Zagrebacka 145a
Zagreb 10000
Croatia
Phone: +385 1-6105-923
Email: domagoj.premec@siemens.com
Basavaraj Patil
Nokia Siemens Networks
6000 Connection Drive
Irving, TX 75039
US
Phone:
Email: basavaraj.patil@nsn.com
Meghana Sahasrabudhe
Nokia Siemens Networks
313 Fairchild Drive
Mountain View, CA 94043
US
Phone:
Email: meghana.sahasrabudhe@nsn.com
Damic, et al. Expires December 9, 2007 [Page 13]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Damic, et al. Expires December 9, 2007 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 09:09:39 |