One document matched: draft-damic-netlmm-pmip6-ind-discover-02.txt
Differences from draft-damic-netlmm-pmip6-ind-discover-01.txt
Network Working Group D. Damic
Internet-Draft D. Premec
Intended status: Standards Track B. Patil
Expires: May 22, 2008 M. Sahasrabudhe
Nokia Siemens Networks
S. Krishnan
Ericsson
November 19, 2007
Proxy Mobile IPv6 indication and discovery
draft-damic-netlmm-pmip6-ind-discover-02.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 May 22, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Proxy Mobile IPv6 is a network-based mobility protocol that enabling
mobility management for an IP host as it moves across different
points of attachment within the mobility domain. An IP host whose
mobility is being managed by the network is unaware of the access
Damic, et al. Expires May 22, 2008 [Page 1]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover November 2007
networks capability to do mobility management on its behalf using
Proxy Mobile IPv6. This draft proposes mechanisms by which the host
is informed of Proxy Mobile IPv6 support, as well as how to actively
discover such capability in the network that host attaches to. The
ability of the host to discover or be aware of Proxy Mobile IPv6
support in the access 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 . . . . . . . . . . . . . . . . . . . . . . 5
4.1. PMIP6 indication in the Router Advertisment . . . . . . . 5
4.2. Alternate Prefix Information Option . . . . . . . . . . . 6
4.3. Router Solicitation Client Based Mobility Flag . . . . . . 9
4.4. DHCPv6 extensions . . . . . . . . . . . . . . . . . . . . 10
4.4.1. Home Network Identifier Option . . . . . . . . . . . . 10
4.4.2. Home Network Information Option . . . . . . . . . . . 11
4.4.3. Note on DHCPv4 . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Damic, et al. Expires May 22, 2008 [Page 2]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover November 2007
1. Introduction and Scope
Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] is a network-based
mobility management protocol not requiring any signaling from the
mobile node to enable IP mobility as the node moves and changes its
point of attachment. This feature compleements Mobile IPv6 [RFC3775]
in the scope of providing localized mobility. A Mobile IPv6 capable
host may prefer to not have the network perform mobility management
on its behalf, via Proxy Mobile IPv6, in some scenarios.
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. Two
cases are described below, and a more exhaustive interactions
analysis can be found in:[I-D.giaretta-netlmm-mip-interactions]
o Simultaneous support for different mobility modes:
The operator may need to support mobility services for hosts
without the built-in mobility, as well as those implementing
Mobile IP within the same PMIP6 domain. Discovery of host's and
network's mobility capabilities is necessary in order to
adequately assign and handled services for all designated hosts.
o Session continuation accros different domains:
Mobile node roaming in/out of the PMIP6 domain aims 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 is may either continue by
using 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 to a
host and provide specific configuration parameters to mobile nodes.
The proposal also provides a method where MN can proactively
participate in mobility mode selection by sending the explicit mode
indication.
Damic, et al. Expires May 22, 2008 [Page 3]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover November 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].
PMIP6 prefix
Prefix assigned to the MN while residing within the PMIP6 domain.
The prefix is topologically anchored at the LMA, thus providing IP
session continuity all throughout that LMA domain. Depending on the
mobility scope, this prefix can be assigned by the LMA or some other
mechanism.
Local (on-link) prefix
Topologically correct IPv6 prefix available for address
autoconfiguration within the local domain, for example valid within a
scope of a single AR/MAG.
3. Problem Statement
A host which attaches to a network which is also a PMIP6 domain may
use stateless address autoconfiguration (SLAAC) or DHCPv6 to
configure its addresses. The type of prefix advertised to the host
or configuration parameters returned to it may vary depending on
variables such as policy, host preference, host capability etc.
In case PMIP6 is used as a mechanism for managing 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.
At the point when network allocates the address/prefix for the given
mobile, or the Access Router begins advertising the specific IPv6
prefix information, the network is not aware of the type and
capabilities of the mobile node that is attaching:
NDP and DHCP messages as defined today cannot serve as specific PMIP6
mobility triggers. Furthermore, the profile associated with a user
in AAA in not sufficient for deciding about the mobility protocol for
that MN as the device and terminal capabilities may change. For
example: Profile or policy parameters associated with a subscriber
authorizing PMIP6 service cannot be used in triggering network
mobility since the capability of the host or preference cannot be
determined.
Damic, et al. Expires May 22, 2008 [Page 4]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover November 2007
The AR or MAG in the access network should anticipate different types
of IPv6 mobility services and terminals, and make sure the correct
service is assigned to the mobile node. The network should take into
account mobility preference of the mobile, in case such information
is provided beforehand, in the router solicitation (RS) or a DHCP
request.
Explicit mechanisms and protocol extensions are needed to:
o enable the access network to advertise the PMIP6 support to the MN
o provide the MN with more reliable parameters allowing it to choose
the mobility protocol based on its capabilities or other criteria
o allow MNs to indicate their mobility mode preferences
4. Proposed Solutions
This document proposes extensions to the NDP and DHCPv6 protocols
that may serve as triggers for PMIP6 mobility selection. The
proposed extensions include: a new indication flag in the RA, new
prefix information option for the Router Advertisement, flag
extention to the Router Solicitation messages, as well as
modifications for the related DHCPv6 MIP6 bootstrap extensions.
4.1. PMIP6 indication in the Router Advertisment
As per [I-D.haberman-ipv6-ra-flags-option] the AR may use a new
option to expand the flags field in the Router Advertisement
messages. In case the access network does support PMIP6, new option
may be used to explicitly indicate this capability. By setting the
"N" flag in the RA flag expansion option, AR advertises support for
network-based mobility management, i.e., PMIP6 capability.
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 |N| Bit fields available ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... for assignment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. RA flag expansion option with a PMIP6 indication
Type
Type - 8-bit identifier of the option type
To be assigned by IANA, as indicated by
[I-D.haberman-ipv6-ra-flags-option]
Damic, et al. Expires May 22, 2008 [Page 5]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover November 2007
Length
Length = 1; The length MUST be checked when processing the option
in order to allow for future expansion of this option if the need
arises.
Bits
Router Advertisement bit 8 - the "N" flag
To be assigned by IANA.This bit is set by the AR to indicate the
access network supports network-based mobility management, i.e.,
PMIP6. Other bits are available for further assignment.
4.2. Alternate Prefix Information Option
The AR is allowed to include multiple IPv6 prefixes in the single RA
message where each prefix is contained in an own Prefix Information
Option [RFC4861]. In case the access network supports PMIP6, the AR
MAY chose to simultaneoulsy advertise local on-link IPv6 prefixes, as
well as the individual PMIP6 prefix for that MN. For this specific
case, the two different types of prefixes SHOULD be cleary
differentiated.
The Alternate Prefix Information Option shall provide host with
additional prefix information for the purpose of stateless IPv6
address autoconfiguration. In case the network supports multiple
mobility service types, the AR may provide alternative option to the
mobile node leaving the choice of the mobility service to the
terminal.
In order to make use of the service indication and selection, the MN
has to be enhanced for processing of the new Alternate Prefix
Information option. Mobile nodes that are capable of processing the
Alternate Prefix Information option should use the obtained
information according to internal configuration and policy to decide
whether to configure PMIP6 MN-HoA or MIP6 CoA on its network
interface. Node incapable of understanding the Alternate Prefix
option SHALL ignore it.
The format of the option supports regular operation and backwards
compatibility for all legacy terminals by allowing flexibility in
prefix assignment. Depending on the network policy and capabilities,
the AR can advertise on-link prefixes, or the PMIP6 prefix as default
information within the Prefix Information Option. By specifying the
Prefix Type, the alternative prefix information can then be provided
in the new option.
Damic, et al. Expires May 22, 2008 [Page 6]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover November 2007
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| |Pr.Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Alternate Prefix Information Option
Fields:
Type
8-bit identifier for the Alternate Prefix Information option (to
be assigned by IANA).
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. Use of the flag as defined in [RFC4861]: When
set, indicates 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. .
A
1-bit autonomous address-configuration flag. When set indicates
that this prefix can be used for stateless address configuration
as specified in [RFC4862].
Damic, et al. Expires May 22, 2008 [Page 7]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover November 2007
Prefix Type
4-bit unsigned field. The field indicates the type of the prefix
provided in the payload. Allowed values:
0 On-link IPv6 prefix bound to the first hop AR
1 PMIPv6 prefix anchored at the associated LMA
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 [RFC4862].
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.
A value of all one bits (0xffffffff) represents infinity. See
[RFC4862].
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
IPv6 Prefix
An IPv6 address or a prefix of an IPv6 address. The length of the
prefix is given by the Prefix Length field, and the purpose of the
prefix is defined by the Prefix Type field. A router SHOULD NOT
send a prefix option for the link-local prefix and a host SHOULD
ignore such a prefix option.
Description:
The Alternate Prefix Information option provides host with an
additional prefix information for stateless address
autoconfiguration. Respective of the prefix already provided in the
regular Prefix, this option may contain either the topologically
correct on-link prefix (type set to 0), or the PMIPv6 prefix (type 1)
for the purpose of establishing network-based mobility management.
The option appears in Router Advertisement packets only and MUST be
silently ignored for other messages.
Damic, et al. Expires May 22, 2008 [Page 8]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover November 2007
4.3. Router Solicitation Client Based Mobility Flag
If a mobile node that wishes to do its own mobility signaling enters
a PMIPv6 network it cannot do so since the PMIP domain makes the MN
believe that it is in fact in its home network. This section
describes a mechanism by which a mobile node in a PMIPv6 network can
signal to the PMIPv6 network whether it would like to make use of the
Proxy Mobility service or not. This document modifies the format of
the Router Solicitation Message specified in [RFC4861] to include a
new client based mobility flag. As a result of this the router
solicitation message format will look like the following figure:
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 3. Client based mobility flag in the Router Solicitation
ICMP Fields:
Type 133
Code 0
Checksum
The ICMP checksum. See [RFC4443]
C
If this bit is set, it means that the sending MN would like to
perform its own signaling.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
A mobile node that utilises this mechanism and wants to perform its
own signaling, MUST set the C bit to one. The MAG that receives it
SHOULD respond with a Router Advertisement containing a topologically
Damic, et al. Expires May 22, 2008 [Page 9]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover November 2007
correct prefix for the link (i.e., Not the emulated PMIPv6 prefix).
MNs which are not aware of this specification will not set the C bit
and hence the MAG would provide them with proxy mobility service.
MAGs not aware of this bit when a client sets the C bit to 1 will
ignore it as specified in [RFC4861]. Hence there are no backward
compatibility issues
4.4. 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 PMIP6 protocol
o AR can inform the mobile node of the PMIP6 prefix
o mobile node can inform the AR wheather it should provide a PMIP6
service to it or if the MN prefers to run MIP6 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
(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.4.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 | sequence # | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Home Network Identifier .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Home Network Identifier option format
Damic, et al. Expires May 22, 2008 [Page 10]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover November 2007
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
PMIP6 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 PMIP6 support in the local domain. Alternatively, if the
mobile node wants to inquire about the support for PMIP6 service in a
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 PMIP6 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.4.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.
Damic, et al. Expires May 22, 2008 [Page 11]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover November 2007
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.4.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.
4.4.2.2. Choosing the PMIP mode
If the client decides that it would use PMIP6 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.4.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.
Damic, et al. Expires May 22, 2008 [Page 12]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover November 2007
5. Security Considerations
The mechanisms described in this document use neighbor discovery
messages to communicate mobility preferences and indications between
the MN and the network. An on-link attacker can send spoofed router
advertisements and spoofed router solicitation in order to deny
mobility service to the node. The usage of SEND [RFC3971] could
prevent this from happening.
6. IANA Considerations
The following Extension Types MUST be assigned by IANA:
o PMIP6 "N" indication flag in RA flags expansion option
o Alternate Prefix Information Option type
o Client Based mobility flag for RS message
o DHCPv6 Home Network Information Option (id-type 3 PMIP)
7. Acknowledgements
TBD.
8. References
8.1. Normative References
[I-D.haberman-ipv6-ra-flags-option]
Haberman, B. and R. Hinden, "IPv6 Router Advertisement
Flags Option", draft-haberman-ipv6-ra-flags-option-01
(work in progress), April 2007.
[I-D.ietf-mip6-hiopt]
Jang, H., "DHCP Option for Home Information Discovery in
MIPv6", draft-ietf-mip6-hiopt-08 (work in progress),
November 2007.
[I-D.ietf-netlmm-proxymip6]
Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-07 (work in progress),
November 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Damic, et al. Expires May 22, 2008 [Page 13]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover November 2007
[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.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
8.2. Informative References
[I-D.giaretta-netlmm-mip-interactions]
Giaretta, G., "Interactions between PMIPv6 and MIPv6:
scenarios and related issues",
draft-giaretta-netlmm-mip-interactions-02 (work in
progress), November 2007.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
Authors' Addresses
Damjan Damic
Nokia Siemens Networks
Heinzelova 70a
Zagreb 10000
Croatia
Phone: +385 1 6331 337
Email: damjan.damic.ext@nsn.com
Damic, et al. Expires May 22, 2008 [Page 14]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover November 2007
Domagoj Premec
Nokia Siemens Networks
Heinzelova 70a
Zagreb 10000
Croatia
Phone: +385 1 6105 923
Email: domagoj.premec.ext@nsn.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
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
Damic, et al. Expires May 22, 2008 [Page 15]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover November 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 May 22, 2008 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 09:08:59 |