draft-ietf-netlmm-proxymip6-15.txt   draft-ietf-netlmm-proxymip6-16.txt 
NETLMM WG S. Gundavelli (Editor) NETLMM WG S. Gundavelli (Editor)
Internet-Draft K. Leung Internet-Draft K. Leung
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: November 17, 2008 V. Devarapalli Expires: November 22, 2008 V. Devarapalli
Wichorus Wichorus
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
B. Patil B. Patil
Nokia Siemens Networks Nokia Siemens Networks
May 16, 2008 May 21, 2008
Proxy Mobile IPv6 Proxy Mobile IPv6
draft-ietf-netlmm-proxymip6-15.txt draft-ietf-netlmm-proxymip6-16.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 40 skipping to change at page 1, line 40
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 November 17, 2008. This Internet-Draft will expire on November 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
Network-based mobility management enables IP mobility for a host Network-based mobility management enables IP mobility for a host
without requiring its participation in any mobility related without requiring its participation in any mobility related
signaling. The Network is responsible for managing IP mobility on signaling. The Network is responsible for managing IP mobility on
skipping to change at page 2, line 38 skipping to change at page 2, line 38
5.3.4. Binding Lifetime Extension (After handoff) . . . . . . 24 5.3.4. Binding Lifetime Extension (After handoff) . . . . . . 24
5.3.5. Binding De-Registration . . . . . . . . . . . . . . . 24 5.3.5. Binding De-Registration . . . . . . . . . . . . . . . 24
5.3.6. Constructing the Proxy Binding Acknowledgement 5.3.6. Constructing the Proxy Binding Acknowledgement
Message . . . . . . . . . . . . . . . . . . . . . . . 25 Message . . . . . . . . . . . . . . . . . . . . . . . 25
5.4. Multihoming Support . . . . . . . . . . . . . . . . . . . 27 5.4. Multihoming Support . . . . . . . . . . . . . . . . . . . 27
5.4.1. Binding Cache entry lookup considerations . . . . . . 28 5.4.1. Binding Cache entry lookup considerations . . . . . . 28
5.5. Timestamp Option for Message Ordering . . . . . . . . . . 33 5.5. Timestamp Option for Message Ordering . . . . . . . . . . 33
5.6. Routing Considerations . . . . . . . . . . . . . . . . . . 36 5.6. Routing Considerations . . . . . . . . . . . . . . . . . . 36
5.6.1. Bi-Directional Tunnel Management . . . . . . . . . . . 36 5.6.1. Bi-Directional Tunnel Management . . . . . . . . . . . 36
5.6.2. Forwarding Considerations . . . . . . . . . . . . . . 37 5.6.2. Forwarding Considerations . . . . . . . . . . . . . . 37
5.7. Local Mobility Anchor Address Discovery . . . . . . . . . 38 5.6.3. ECN Considerations for Proxy Mobile IPv6 Tunnels . . . 38
5.7. Local Mobility Anchor Address Discovery . . . . . . . . . 39
5.8. Mobile Prefix Discovery Considerations . . . . . . . . . . 39 5.8. Mobile Prefix Discovery Considerations . . . . . . . . . . 39
5.9. Route Optimization Considerations . . . . . . . . . . . . 39 5.9. Route Optimization Considerations . . . . . . . . . . . . 40
6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 39 6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 40
6.1. Extensions to Binding Update List Entry Data Structure . . 40 6.1. Extensions to Binding Update List Entry Data Structure . . 41
6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 41 6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 42
6.3. Supported Access Link Types . . . . . . . . . . . . . . . 42 6.3. Supported Access Link Types . . . . . . . . . . . . . . . 42
6.4. Supported Address Configuration Modes . . . . . . . . . . 42 6.4. Supported Address Configuration Modes . . . . . . . . . . 43
6.5. Access Authentication & Mobile Node Identification . . . . 43 6.5. Access Authentication & Mobile Node Identification . . . . 44
6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 43 6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 44
6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 44 6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 45
6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 45 6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 45
6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 46 6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 46
6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 46 6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 46
6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 54 6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 55
6.9.3. Default-Router . . . . . . . . . . . . . . . . . . . . 55 6.9.3. Default-Router . . . . . . . . . . . . . . . . . . . . 56
6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 56 6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 56
6.9.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . 56 6.9.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . 57
6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 57 6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 58
6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 58 6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 59
6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 58 6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 59
6.10.3. Local Routing . . . . . . . . . . . . . . . . . . . . 59 6.10.3. Local Routing . . . . . . . . . . . . . . . . . . . . 60
6.10.4. Tunnel Management . . . . . . . . . . . . . . . . . . 59 6.10.4. Tunnel Management . . . . . . . . . . . . . . . . . . 60
6.10.5. Forwarding Rules . . . . . . . . . . . . . . . . . . . 59 6.10.5. Forwarding Rules . . . . . . . . . . . . . . . . . . . 60
6.11. Supporting DHCPv6 based Address Configuration on the 6.11. Supporting DHCP based Address Configuration on the
Access Link . . . . . . . . . . . . . . . . . . . . . . . 61 Access Link . . . . . . . . . . . . . . . . . . . . . . . 62
6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 63 6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 64
6.13. Mobile Node Detachment Detection and Resource Cleanup . . 63 6.13. Mobile Node Detachment Detection and Resource Cleanup . . 64
6.14. Allowing network access to other IPv6 nodes . . . . . . . 64 6.14. Allowing network access to other IPv6 nodes . . . . . . . 65
7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 64 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 66
7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 64 7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 66
7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 65 7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 67
8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 66 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 67
8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 66 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 68
8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 68 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 69
8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 69 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 71
8.4. Handoff Indicator Option . . . . . . . . . . . . . . . . . 70 8.4. Handoff Indicator Option . . . . . . . . . . . . . . . . . 72
8.5. Access Technology Type Option . . . . . . . . . . . . . . 71 8.5. Access Technology Type Option . . . . . . . . . . . . . . 73
8.6. Mobile Node Link-layer Identifier Option . . . . . . . . . 73 8.6. Mobile Node Link-layer Identifier Option . . . . . . . . . 75
8.7. Link-local Address Option . . . . . . . . . . . . . . . . 74 8.7. Link-local Address Option . . . . . . . . . . . . . . . . 76
8.8. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 75 8.8. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 77
8.9. Status Values . . . . . . . . . . . . . . . . . . . . . . 75 8.9. Status Values . . . . . . . . . . . . . . . . . . . . . . 77
9. Protocol Configuration Variables . . . . . . . . . . . . . . . 77 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 79
9.1. Local Mobility Anchor - Configuration Variables . . . . . 77 9.1. Local Mobility Anchor - Configuration Variables . . . . . 79
9.2. Mobile Access Gateway - Configuration Variables . . . . . 78 9.2. Mobile Access Gateway - Configuration Variables . . . . . 80
9.3. Proxy Mobile IPv6 Domain - Configuration Variables . . . . 79 9.3. Proxy Mobile IPv6 Domain - Configuration Variables . . . . 81
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81
11. Security Considerations . . . . . . . . . . . . . . . . . . . 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 82
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 81 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 83
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 83
13.1. Normative References . . . . . . . . . . . . . . . . . . . 82 13.1. Normative References . . . . . . . . . . . . . . . . . . . 84
13.2. Informative References . . . . . . . . . . . . . . . . . . 82 13.2. Informative References . . . . . . . . . . . . . . . . . . 84
Appendix A. Proxy Mobile IPv6 interactions with AAA Appendix A. Proxy Mobile IPv6 interactions with AAA
Infrastructure . . . . . . . . . . . . . . . . . . . 84 Infrastructure . . . . . . . . . . . . . . . . . . . 86
Appendix B. Routing State . . . . . . . . . . . . . . . . . . . . 84 Appendix B. Routing State . . . . . . . . . . . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 87
Intellectual Property and Copyright Statements . . . . . . . . . . 87 Intellectual Property and Copyright Statements . . . . . . . . . . 89
1. Introduction 1. Introduction
IP mobility for IPv6 hosts is specified in Mobile IPv6 [RFC-3775]. IP mobility for IPv6 hosts is specified in Mobile IPv6 [RFC-3775].
Mobile IPv6 requires client functionality in the IPv6 stack of a Mobile IPv6 requires client functionality in the IPv6 stack of a
mobile node. Exchange of signaling messages between the mobile node mobile node. Exchange of signaling messages between the mobile node
and home agent enables the creation and maintenance of a binding and home agent enables the creation and maintenance of a binding
between the mobile node's home address and its care-of-address. between the mobile node's home address and its care-of-address.
Mobility as specified in [RFC-3775] requires the IP host to send IP Mobility as specified in [RFC-3775] requires the IP host to send IP
mobility management signaling messages to the home agent, which is mobility management signaling messages to the home agent, which is
skipping to change at page 6, line 41 skipping to change at page 6, line 41
The local mobility anchor views this address as the Care-of The local mobility anchor views this address as the Care-of
Address of the mobile node and registers it in the Binding Cache Address of the mobile node and registers it in the Binding Cache
entry for that mobile node. When the transport network between entry for that mobile node. When the transport network between
the mobile access gateway and the local mobility anchor is an IPv4 the mobile access gateway and the local mobility anchor is an IPv4
network and if the care-of address that is registered at the local network and if the care-of address that is registered at the local
mobility anchor is an IPv4 address, the term, IPv4-Proxy-CoA is mobility anchor is an IPv4 address, the term, IPv4-Proxy-CoA is
used, as specified in [ID-IPV4-PMIP6]. used, as specified in [ID-IPV4-PMIP6].
Mobile Node's Home Network Prefix (MN-HNP) Mobile Node's Home Network Prefix (MN-HNP)
This is the prefix that is assigned to a given interface of a The MN-HNP is a prefix assigned to the link between the mobile
mobile node and is always present in the Router Advertisement node and the mobile access gateway. More than one prefix can be
messages that the mobile node receives on any of the access links assigned to the link between the mobile node and the mobile access
in that Proxy Mobile IPv6 domain. There can also be multiple home gateway, in which case, all of the assigned prefixes are managed
network prefixes assigned to a given interface of a mobile node as a set associated with a mobility session. The mobile node
and in which case all of those assigned prefixes will still be
managed as part of one mobility session. The mobile node
configures its interface with one or more addresses from its home configures its interface with one or more addresses from its home
network prefix(es). If the mobile node connects to the Proxy network prefix(es). If the mobile node connects to the Proxy
Mobile IPv6 domain through multiple interfaces, simultaneously, Mobile IPv6 domain through multiple interfaces, simultaneously,
each of the attached interfaces will be assigned a unique set of each of the attached interfaces will be assigned a unique set of
home network prefixes and all the prefixes assigned to a given home network prefixes and all the prefixes assigned to a given
interface of a mobile node will be managed under one mobility interface of a mobile node will be managed under one mobility
session. Additionally, in some configurations the assigned prefix session. Additionally, in some configurations the assigned prefix
can be of 128-bit prefix length. Ex: Home network prefixes P1, P2 can be of 128-bit prefix length. Ex: Home network prefixes P1, P2
assigned to interface I1 will be managed under one mobility assigned to interface I1 will be managed under one mobility
session and prefixes P3, P4, P5 assigned to interface I2 of the session and prefixes P3, P4, P5 assigned to interface I2 of the
skipping to change at page 8, line 45 skipping to change at page 8, line 44
Proxy Binding Acknowledgement (PBA) Proxy Binding Acknowledgement (PBA)
A binding registration reply message sent by a local mobility A binding registration reply message sent by a local mobility
anchor in response to a Proxy Binding Update request message that anchor in response to a Proxy Binding Update request message that
it received from a mobile access gateway. it received from a mobile access gateway.
Per-MN-Prefix & Shared-Prefix Models Per-MN-Prefix & Shared-Prefix Models
The term, Per-MN-Prefix model, is used to refer to an addressing The term, Per-MN-Prefix model, is used to refer to an addressing
model where there is an unique network prefix assigned for each model where there is a unique network prefix or prefixes assigned
node. The term, Shared-Prefix model, is used to refer to an for each node. The term, Shared-Prefix model, is used to refer to
addressing model where the prefix is shared by more than one node. an addressing model where the prefix(es) are shared by more than
This specification supports the Per-MN-Prefix model and does not one node. This specification supports the Per-MN-Prefix model and
support the Shared-Prefix model. does not support the Shared-Prefix model.
Mobility Session
In the context of Proxy Mobile IPv6 specification, the term
mobility session refers to the creation or existence of state
associated with the mobile node's mobility binding on the local
mobility anchor and on the serving mobile access gateway.
DHCP
Throughout this document, the acronym DHCP refers to DHCP for
IPv6, as defined in [RFC-3315].
ALL_ZERO & NON_ZERO ALL_ZERO & NON_ZERO
Protocol message fields initialized with value 0 in each byte of Protocol message fields initialized with value 0 in each byte of
the field. Ex: An 8-byte link-layer identifier field with the the field. Ex: An 8-byte link-layer identifier field with the
value set to 0 in each of the 8 bytes, or an IPv6 address with the value set to 0 in each of the 8 bytes, or an IPv6 address with the
value 0 in all of the 16 bytes. Conversely, the term NON_ZERO is value 0 in all of the 16 bytes. Conversely, the term NON_ZERO is
used to refer to any value other than an ALL_ZERO value. used to refer to any value other than an ALL_ZERO value.
3. Proxy Mobile IPv6 Protocol Overview 3. Proxy Mobile IPv6 Protocol Overview
This specification describes a network-based mobility management This specification describes a network-based mobility management
protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6
skipping to change at page 10, line 46 skipping to change at page 10, line 46
If the network determines that the network-based mobility management If the network determines that the network-based mobility management
service needs to be offered to that mobile node, the network will service needs to be offered to that mobile node, the network will
ensure that the mobile node using any of the address configuration ensure that the mobile node using any of the address configuration
mechanisms permitted by the network will be able to obtain the mechanisms permitted by the network will be able to obtain the
address configuration on the connected interface and move anywhere in address configuration on the connected interface and move anywhere in
that Proxy Mobile IPv6 domain. The obtained address configuration that Proxy Mobile IPv6 domain. The obtained address configuration
includes the address(es) from its home network prefix(es), the includes the address(es) from its home network prefix(es), the
default-router address on the link and other related configuration default-router address on the link and other related configuration
parameters. From the perspective of the mobile node, the entire parameters. From the perspective of the mobile node, the entire
Proxy Mobile IPv6 domain appears as a single link, the network Proxy Mobile IPv6 domain appears as a single link, the network
ensures that the mobile node believes it is always on the same link ensures that the mobile node does not detect any change with respect
where it obtained its initial address configuration, even after to its layer-3 attachment even after changing its point of attachment
changing its point of attachment in that network. in the network.
The mobile node may be an IPv4-only node, IPv6-only node or a dual The mobile node may be an IPv4-only node, IPv6-only node or a dual
IPv4/IPv6 node. Based on what is enabled in the network for that IPv4/IPv6 node. Based on what is enabled in the network for that
mobile node, the mobile node will be able to obtain an IPv4, IPv6 or mobile node, the mobile node will be able to obtain an IPv4, IPv6 or
dual IPv4/IPv6 addresses and move anywhere in that Proxy Mobile IPv6 dual IPv4/IPv6 addresses and move anywhere in that Proxy Mobile IPv6
domain. However this specification only supports IPv6 address domain. However this specification only supports IPv6 address
mobility and when the transport network is IPv6 network. The support mobility and when the transport network is IPv6 network. The support
for IPv4 addressing or IPv4 transport network is specified in the for IPv4 addressing or IPv4 transport network is specified in the
companion document [ID-IPV4-PMIP6]. companion document [ID-IPV4-PMIP6].
skipping to change at page 15, line 16 skipping to change at page 15, line 16
identify the corresponding mobility session for which the binding identify the corresponding mobility session for which the binding
update request was received and once it accepts the request will wait update request was received and once it accepts the request will wait
for certain amount of time for allowing the mobile access gateway on for certain amount of time for allowing the mobile access gateway on
the new link to update the binding. However, if it does not receive the new link to update the binding. However, if it does not receive
any binding update request within that given amount of time, it will any binding update request within that given amount of time, it will
delete the binding cache entry. delete the binding cache entry.
The mobile access gateway on the new access link upon detecting the The mobile access gateway on the new access link upon detecting the
mobile node on its access link will signal the local mobility anchor mobile node on its access link will signal the local mobility anchor
for updating the binding state. Once that signaling is complete, the for updating the binding state. Once that signaling is complete, the
mobile node will continue to receive the Router Advertisements serving mobile access gateway will send the Router Advertisements
containing its home network prefix(es) that were assigned to that containing the mobile node's home network prefix(es) and this will
mobility session, making it believe it is still on the same link and ensure the mobile node will not detect any change with respect to its
it will be able to use the same address configuration on the new layer-3 attachment of its interface.
access link.
4. Proxy Mobile IPv6 Protocol Security 4. Proxy Mobile IPv6 Protocol Security
The signaling messages, Proxy Binding Update and Proxy Binding The signaling messages, Proxy Binding Update and Proxy Binding
Acknowledgement, exchanged between the mobile access gateway and the Acknowledgement, exchanged between the mobile access gateway and the
local mobility anchor MUST be protected using end-to-end security local mobility anchor MUST be protected using end-to-end security
association(s) offering integrity and data origin authentication. association(s) offering integrity and data origin authentication.
The mobile access gateway and the local mobility anchor MUST The mobile access gateway and the local mobility anchor MUST
implement IPsec for protecting the Proxy Mobile IPv6 signaling implement IPsec for protecting the Proxy Mobile IPv6 signaling
skipping to change at page 19, line 23 skipping to change at page 19, line 23
its mobility session is the key for locating a Binding Cache entry in its mobility session is the key for locating a Binding Cache entry in
all cases except when there has been an handoff of the mobile node's all cases except when there has been an handoff of the mobile node's
session to a new mobile access gateway and that mobile access gateway session to a new mobile access gateway and that mobile access gateway
is unaware of the home network prefix(es) assigned to that mobility is unaware of the home network prefix(es) assigned to that mobility
session. In such handoff cases, the Binding Cache entry can be session. In such handoff cases, the Binding Cache entry can be
located under the considerations specified in Section 5.4.1. located under the considerations specified in Section 5.4.1.
5.2. Supported Home Network Prefix Models 5.2. Supported Home Network Prefix Models
This specification supports the Per-MN-Prefix model and does not This specification supports the Per-MN-Prefix model and does not
support the Shared-Prefix model. As per the Per-MN-Prefix model, a support the Shared-Prefix model. As per the Per-MN-Prefix model,
prefix assigned to a mobile node is for that mobile node's exclusive home network prefix(es) assigned to a mobile node are for that mobile
use and no other node shares an address from that prefix (other than node's exclusive use and no other node shares an address from that
the Subnet-Router anycast address [RFC-4291] which is used by the prefix (other than the Subnet-Router anycast address [RFC-4291] which
mobile access gateway hosting that prefix on that link). is used by the mobile access gateway hosting that prefix on that
link).
There may be more than one prefix assigned to a given interface of There may be more than one prefix assigned to a given interface of
the mobile node and all of those assigned prefixes are unique to that the mobile node and all of those assigned prefixes are unique to that
mobile node and all are part of one mobility session. If the mobile mobile node and all are part of one mobility session. If the mobile
node attaches to the Proxy Mobile IPv6 domain through multiple node attaches to the Proxy Mobile IPv6 domain through multiple
interfaces and simultaneously, each of the attached interfaces will interfaces and simultaneously, each of the attached interfaces will
be assigned one or more unique prefixes and all of the assigned be assigned one or more unique prefixes and all of the assigned
prefixes to a given interface will be managed under a different prefixes to a given interface will be managed under a different
mobility session. mobility session.
skipping to change at page 22, line 35 skipping to change at page 22, line 35
1. If there is at least one instance of Home Network Prefix option 1. If there is at least one instance of Home Network Prefix option
present in the Proxy Binding Update request with the prefix value present in the Proxy Binding Update request with the prefix value
set to ALL_ZERO, the local mobility anchor MUST allocate one or set to ALL_ZERO, the local mobility anchor MUST allocate one or
more home network prefix(es) to the mobile node and assign it to more home network prefix(es) to the mobile node and assign it to
the new mobility session created for the mobile node. The local the new mobility session created for the mobile node. The local
mobility anchor MUST ensure the allocated prefix(es) is not in mobility anchor MUST ensure the allocated prefix(es) is not in
use by any other node or mobility session. The decision on how use by any other node or mobility session. The decision on how
many prefixes to be allocated for the attached interface, can be many prefixes to be allocated for the attached interface, can be
based on a global policy or a policy specific to that mobile based on a global policy or a policy specific to that mobile
node. However, when stateful address autoconfiguration using node. However, when stateful address autoconfiguration using
DHCPv6 is supported on the link, considerations from Section 6.11 DHCP is supported on the link, considerations from Section 6.11
MUST be applied for the prefix assignment. MUST be applied for the prefix assignment.
2. If the local mobility anchor is unable to allocate any home 2. If the local mobility anchor is unable to allocate any home
network prefix for the mobile node, it MUST reject the request network prefix for the mobile node, it MUST reject the request
and send a Proxy Binding Acknowledgement message with Status and send a Proxy Binding Acknowledgement message with Status
field set to 130 (Insufficient resources). field set to 130 (Insufficient resources).
3. If there are one or more Home Network Prefix options present in 3. If there are one or more Home Network Prefix options present in
the Proxy Binding Update request (with each of the prefixes set the Proxy Binding Update request (with each of the prefixes set
to a NON_ZERO value), the local mobility anchor before accepting to a NON_ZERO value), the local mobility anchor before accepting
skipping to change at page 25, line 25 skipping to change at page 25, line 25
session with the lifetime value of greater than zero, and if session with the lifetime value of greater than zero, and if
that request is accepted, then the Binding Cache entry MUST that request is accepted, then the Binding Cache entry MUST
NOT be deleted, but must be updated with the newly accepted NOT be deleted, but must be updated with the newly accepted
registration values and additionally the wait period should be registration values and additionally the wait period should be
ended. ended.
* By the end of this wait period, if the local mobility anchor * By the end of this wait period, if the local mobility anchor
did not receive any valid Proxy Binding Update request for did not receive any valid Proxy Binding Update request for
this mobility session, then it MUST delete the Binding Cache this mobility session, then it MUST delete the Binding Cache
entry and remove the routing state created for that mobility entry and remove the routing state created for that mobility
session. session. The local mobility anchor can potentially reassign
the prefix(es) associated with this mobility session to other
mobile nodes.
5.3.6. Constructing the Proxy Binding Acknowledgement Message 5.3.6. Constructing the Proxy Binding Acknowledgement Message
o The local mobility anchor when sending the Proxy Binding o The local mobility anchor when sending the Proxy Binding
Acknowledgement message to the mobile access gateway MUST Acknowledgement message to the mobile access gateway MUST
construct the message as specified below. construct the message as specified below.
IPv6 header (src=LMAA, dst=Proxy-CoA) IPv6 header (src=LMAA, dst=Proxy-CoA)
Mobility header Mobility header
- BA /* P flag must be set to value of 1 */ - BA /* P flag must be set to value of 1 */
skipping to change at page 38, line 33 skipping to change at page 38, line 33
Forwarding Packets Sent by the Mobile Node: Forwarding Packets Sent by the Mobile Node:
o All the reverse tunneled packets that the local mobility anchor o All the reverse tunneled packets that the local mobility anchor
received from the mobile access gateway, after removing the tunnel received from the mobile access gateway, after removing the tunnel
header MUST be routed to the destination specified in the inner header MUST be routed to the destination specified in the inner
packet header. These routed packets will have the source address packet header. These routed packets will have the source address
field set to the mobile node's home address. Considerations from field set to the mobile node's home address. Considerations from
[RFC-2473] MUST be applied for IPv6 decapsulation. [RFC-2473] MUST be applied for IPv6 decapsulation.
5.6.3. ECN Considerations for Proxy Mobile IPv6 Tunnels
This section describes how the ECN information needs to be handled by
the mobility agents at the tunnel entry and exit points. The ECN
considerations for IP tunnels are specified in [RFC-3168] and the
same considerations apply to Proxy Mobile IPv6 tunnels (using IPv6-
in-IPv6 encapsulation mode). Specifically the full-functionality
option MUST be supported. The relevant ECN considerations from [RFC-
3168] are summarized here for convenience.
Encapsulation Considerations:
o If the Explicit Congestion Notification (ECN) field in the inner
header is set to ECT(0) or ECT(1), where ECT stands for ECN-
Capable Transport (ECT), the ECN field from the inner header MUST
be copied to the outer header. Additionally, when payload
protection using IPsec is enabled for the mobile node's data
traffic, the ECN considerations from [RFC-4301] MUST be applied.
Decapsulation Considerations:
o If the Explicit Congestion Notification (ECN) field in the inner
header is set to ECT(0) or ECT(1), and if the ECN field in the
outer header is set to Congestion Experienced (CE), then the ECN
field in the inner header MUST be set to CE. Otherwise, the ECN
field in the inner header MUST NOT be modified. Additionally,
when payload protection using IPsec is enabled for the mobile
node's data traffic, the ECN considerations from [RFC-4301] MUST
be applied.
5.7. Local Mobility Anchor Address Discovery 5.7. Local Mobility Anchor Address Discovery
Dynamic Home Agent Address Discovery (DHAAD), as explained in Section Dynamic Home Agent Address Discovery (DHAAD), as explained in Section
10.5 of [RFC-3775], allows a mobile node to discover all the home 10.5 of [RFC-3775], allows a mobile node to discover all the home
agents on its home link by sending an ICMP Home Agent Address agents on its home link by sending an ICMP Home Agent Address
Discovery Request message to the Mobile IPv6 Home-Agents anycast Discovery Request message to the Mobile IPv6 Home-Agents anycast
address, derived from its home network prefix. address, derived from its home network prefix.
The DHAAD message in the current form cannot be used in Proxy Mobile The DHAAD message in the current form cannot be used in Proxy Mobile
IPv6 for discovering the address of the mobile node's local mobility IPv6 for discovering the address of the mobile node's local mobility
skipping to change at page 43, line 7 skipping to change at page 43, line 38
Proxy Mobile IPv6 domain. Typically, these configuration settings Proxy Mobile IPv6 domain. Typically, these configuration settings
will be based on the domain wide policy or based on a policy specific will be based on the domain wide policy or based on a policy specific
to each mobile node. to each mobile node.
When stateless address autoconfiguration is supported on the access When stateless address autoconfiguration is supported on the access
link, the mobile node can generate one or more IPv6 addresses from link, the mobile node can generate one or more IPv6 addresses from
the hosted prefix(es) by standard IPv6 mechanisms such as Stateless the hosted prefix(es) by standard IPv6 mechanisms such as Stateless
Autoconfiguration [RFC-4862] or Privacy extensions [RFC-4941]. Autoconfiguration [RFC-4862] or Privacy extensions [RFC-4941].
When stateful address autoconfiguration is supported on the link, the When stateful address autoconfiguration is supported on the link, the
mobile node can obtain the address configuration from the DHCPv6 mobile node can obtain the address configuration from the DHCP server
server located in the Proxy Mobile IPv6 domain, by standard DHCPv6 located in the Proxy Mobile IPv6 domain, by standard DHCP mechanisms,
mechanisms, as specified in [RFC-3315]. The obtained address(es) as specified in [RFC-3315]. The obtained address(es) will be from
will be from its home network prefix(es). Section 6.11 specifies the its home network prefix(es). Section 6.11 specifies the details on
details on how this configuration can be achieved. how this configuration can be achieved.
Additionally, other address configuration mechanisms specific to the Additionally, other address configuration mechanisms specific to the
access link between the mobile node and the mobile access gateway may access link between the mobile node and the mobile access gateway may
also be used for delivering the address configuration to the mobile also be used for delivering the address configuration to the mobile
node. This specification does not modify the behavior of any of the node. This specification does not modify the behavior of any of the
standard IPv6 address configuration mechanisms. standard IPv6 address configuration mechanisms.
6.5. Access Authentication & Mobile Node Identification 6.5. Access Authentication & Mobile Node Identification
When a mobile node attaches to an access link connected to the mobile When a mobile node attaches to an access link connected to the mobile
skipping to change at page 44, line 30 skipping to change at page 45, line 13
messages exchanged with the local mobility anchor. messages exchanged with the local mobility anchor.
o The mobile access gateway MUST be able to identify the mobile node o The mobile access gateway MUST be able to identify the mobile node
by its MN-Identifier and it MUST be able to associate this by its MN-Identifier and it MUST be able to associate this
identity to the point-to-point link shared with the mobile node. identity to the point-to-point link shared with the mobile node.
6.7. Home Network Emulation 6.7. Home Network Emulation
One of the key functions of a mobile access gateway is to emulate the One of the key functions of a mobile access gateway is to emulate the
mobile node's home network on the access link. It must ensure, the mobile node's home network on the access link. It must ensure, the
mobile node believes it is still connected to its home link or on the mobile node does not detect any change with respect to its layer-3
link where it obtained its initial address configuration after it attachment even after it changes its point of attachment in that
moved into that Proxy Mobile IPv6 domain. Proxy Mobile IPv6 domain.
For emulating the mobile node's home link on the access link, the For emulating the mobile node's home link on the access link, the
mobile access gateway must be able to send Router Advertisement mobile access gateway must be able to send Router Advertisement
messages advertising the mobile node's home network prefix(es) messages advertising the mobile node's home network prefix(es)
carried using the Prefix Information option(s) [RFC-4861] and with carried using the Prefix Information option(s) [RFC-4861] and with
other address configuration parameters consistent with its home link other address configuration parameters consistent with its home link
properties. Typically, these configuration settings will be based on properties. Typically, these configuration settings will be based on
the domain wide policy or based on a policy specific to each mobile the domain wide policy or based on a policy specific to each mobile
node. node.
skipping to change at page 45, line 14 skipping to change at page 45, line 46
lifetime value for the advertised prefix(es) to any chosen value at lifetime value for the advertised prefix(es) to any chosen value at
its own discretion. An implementation MAY choose to tie the prefix its own discretion. An implementation MAY choose to tie the prefix
lifetime to the mobile node's binding lifetime. The prefix lifetime lifetime to the mobile node's binding lifetime. The prefix lifetime
can also be an optional configuration parameter in the mobile node's can also be an optional configuration parameter in the mobile node's
policy profile. policy profile.
6.8. Link-Local and Global Address Uniqueness 6.8. Link-Local and Global Address Uniqueness
A mobile node in the Proxy Mobile IPv6 domain, as it moves from one A mobile node in the Proxy Mobile IPv6 domain, as it moves from one
mobile access gateway to the other, will continue to detect its home mobile access gateway to the other, will continue to detect its home
network and thus believe it is still on the same link. Every time network and does not detect a change of layer-3 attachment. Every
the mobile node attaches to a new link, the event related to the time the mobile node attaches to a new link, the event related to the
interface state change will trigger the mobile node to perform DAD interface state change will trigger the mobile node to perform DAD
operation on the link-local and global address(es). However, if the operation on the link-local and global address(es). However, if the
mobile node is DNAv6 enabled, as specified in [ID-DNAV6], it may not mobile node is DNAv6 enabled, as specified in [ID-DNAV6], it may not
detect the link change due to DNAv6 optimizations and may not trigger detect the link change due to DNAv6 optimizations and may not trigger
the duplicate address detection (DAD) procedure for its existing the duplicate address detection (DAD) procedure for its existing
addresses, which may potentially lead to address collisions after the addresses, which may potentially lead to address collisions after the
mobile node's handoff to a new link. mobile node's handoff to a new link.
The issue of address collision is not relevant to the mobile node's The issue of address collision is not relevant to the mobile node's
global address(es). Since the assigned home network prefix(es) are global address(es). Since the assigned home network prefix(es) are
skipping to change at page 55, line 17 skipping to change at page 56, line 8
on the access link. This will ensure the mobile node on the link on the access link. This will ensure the mobile node on the link
uses the advertised MTU value. The MTU value SHOULD reflect the uses the advertised MTU value. The MTU value SHOULD reflect the
tunnel MTU for the bi-directional tunnel between the mobile tunnel MTU for the bi-directional tunnel between the mobile
access gateway and the local mobility anchor. Considerations access gateway and the local mobility anchor. Considerations
from Section 6.9.5 SHOULD be applied for determining the tunnel from Section 6.9.5 SHOULD be applied for determining the tunnel
MTU value. MTU value.
6.9.3. Default-Router 6.9.3. Default-Router
In Proxy Mobile IPv6, the mobile access gateway is the IPv6 default- In Proxy Mobile IPv6, the mobile access gateway is the IPv6 default-
router for the mobile node on the access link, as it is the entity router for the mobile node on the access link. However, as the
that sends the Router Advertisements on the access link. However, as mobile node moves from one access link to another, the serving mobile
the mobile node moves from one access link to another, the serving access gateway on those respective links will send the Router
mobile access gateway on those respective links will send the Router
Advertisement messages. If these Router Advertisements are sent Advertisement messages. If these Router Advertisements are sent
using a different link-local address or a different link-layer using a different link-local address or a different link-layer
address, the mobile node will always detect a new default-router address, the mobile node will always detect a new default-router
after every handoff. For solving this problem, this specification after every handoff. For solving this problem, this specification
requires all the mobile access gateways in the Proxy Mobile IPv6 requires all the mobile access gateways in the Proxy Mobile IPv6
domain to use the same link-local and link-layer address on any of domain to use the same link-local and link-layer address on any of
the access links where ever the mobile node attaches. These the access links where ever the mobile node attaches. These
addresses can be fixed addresses across the entire Proxy Mobile IPv6 addresses can be fixed addresses across the entire Proxy Mobile IPv6
domain and all the mobile access gateways can use these globally domain and all the mobile access gateways can use these globally
fixed address on any of the point-to-point links. Additionally, this fixed address on any of the point-to-point links. Additionally, this
skipping to change at page 56, line 47 skipping to change at page 57, line 37
4. If the Timestamp based scheme is in use, the retransmitted Proxy 4. If the Timestamp based scheme is in use, the retransmitted Proxy
Binding Update messages MUST use the latest timestamp. If the Binding Update messages MUST use the latest timestamp. If the
Sequence number scheme is in use, the retransmitted Proxy Binding Sequence number scheme is in use, the retransmitted Proxy Binding
Update messages MUST use a Sequence Number value greater than Update messages MUST use a Sequence Number value greater than
that used for the previous transmission of this Proxy Binding that used for the previous transmission of this Proxy Binding
Update message, just as specified in [RFC-3775]. Update message, just as specified in [RFC-3775].
6.9.5. Path MTU Discovery 6.9.5. Path MTU Discovery
For getting optimal throughput, it is required that the routed It is important that mobile node, mobile access gateway, and local
packets between the local mobility anchor and the mobile access mobility anchor have a correct understanding of MTUs. When the
gateway are sent in the largest size and without fragmentation. If mobile node uses the correct MTU, it can send packets that do not
the mobility entities are aware of the Path MTU (PMTU) between exceed the local link MTU and do not cause the tunneled packets from
themselves, it can be used for determining the Tunnel Path MTU and the mobile access gateway to be fragmented. This is important both
also for advertising this value as the link MTU on the access link from the perspective of efficiency, as well as preventing hard-to-
shared with the mobile node. The following are some of the diagnose MTU problems. The following are some of the considerations
considerations related to Path MTU discovery. related to Path MTU discovery.
o The local mobility anchor and mobile access gateway MAY use the o The local mobility anchor and mobile access gateway MAY use the
Path MTU Discovery mechanisms as specified in [RFC-1981] and [RFC- Path MTU Discovery mechanisms as specified in [RFC-1981] or in
4821]. for determining the Path MTU (PMTU) for the path between [RFC-4821] for determining the Path MTU (PMTU) for the (LMA-MAG)
themselves. paths. The specific discovery mechanism to be used in a given
deployment can be configurable.
o The local mobility anchor and the mobile access gateway MAY use o The mobility entities MUST implement and SHOULD support ICMP-based
any standard application probes for determining the PMTU. The Path MTU discovery mechanism as specified in [RFC-1981]. However,
specifics details related to the type of traffic that can be used this mechanism may not work correctly if the Proxy Mobile IPv6
for the PMTU discovery is outside the scope of this document. network does not deliver or process ICMP Packet Too Big messages.
o If there is an administratively configured PMTU value for the path o The mobility entities MAY implement Packetization Layer Path MTU
between the local mobility anchor and the mobile access gateway, discovery mechanisms as specified in [RFC-4821] and use any
the dynamic discovery of PMTU is not required. application traffic as a payload for the PMTU discovery. Neither
the Proxy Mobile IPv6 protocol or the tunnel between the mobile
access gateway and local mobility agent can easily be used for
this purpose. However, implementations SHOULD support at least
the use of an explicit ICMP Echo Request/Response for this
purpose.
o The IPv6 tunnel MTU for the established tunnel between the local o The mobility entities MAY choose to perform Path MTU discovery for
mobility anchor and the mobile access gateway can be computed all the (LMA-MAG) paths at the boot time and may repeat this
based on this Path MTU value, as specified in Section 6.7 of [RFC- operation periodically to ensure the Path MTU values have not
changed for those paths. If the dynamic PMTU discovery mechanisms
fail to determine the Path MTU, an administratively configured
default value MUST be used.
o The IPv6 tunnel MTU for an established tunnel between the local
mobility anchor and the mobile access gateway MUST be computed
based on the determined Path MTU value for that specific path and
the computation should be as specified in Section 6.7 of [RFC-
2473]. 2473].
o The mobile access gateway SHOULD use this determined tunnel Path o The mobile access gateway SHOULD use the determined tunnel Path
MTU value (for the tunnel established with the mobile node's local MTU value (for the tunnel established with the mobile node's local
mobility anchor) as the MTU value in the MTU option that it sends mobility anchor) as the MTU value in the MTU option that it sends
in the Router Advertisements on the access link shared with the in the Router Advertisements on the access link shared with the
mobile node. mobile node.
o If the mobile access gateway detects a change in MTU value for any
of the paths (LMA-MAG) and at any point of time, the corresponding
tunnel MTU value MUST be updated to reflect the change in Path MTU
value. The adjusted tunnel MTU value SHOULD be notified to the
impacted mobile nodes by sending additional Router Advertisement
messages. Additionally, the adjusted tunnel MTU value MUST be
used in all the subsequent Router Advertisement messages as well.
6.10. Routing Considerations 6.10. Routing Considerations
This section describes how the mobile access gateway handles the This section describes how the mobile access gateway handles the
traffic to/from the mobile node that is attached to one of its access traffic to/from the mobile node that is attached to one of its access
interfaces. interfaces.
Proxy-CoA LMAA Proxy-CoA LMAA
| | | |
+--+ +---+ +---+ +--+ +--+ +---+ +---+ +--+
|MN|----------|MAG|======================|LMA|----------|CN| |MN|----------|MAG|======================|LMA|----------|CN|
skipping to change at page 61, line 18 skipping to change at page 62, line 28
traffic. However, when using IPv4 transport, the format of the traffic. However, when using IPv4 transport, the format of the
packet is as described in [ID-IPV4-PMIP6]. packet is as described in [ID-IPV4-PMIP6].
IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */ IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */
ESP Header in tunnel mode /* ESP Header */ ESP Header in tunnel mode /* ESP Header */
IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */ IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */
Upper layer protocols /* Packet Content*/ Upper layer protocols /* Packet Content*/
Figure 15: Tunneled Packet from MAG to LMA with Payload Protection Figure 15: Tunneled Packet from MAG to LMA with Payload Protection
6.11. Supporting DHCPv6 based Address Configuration on the Access Link 6.11. Supporting DHCP based Address Configuration on the Access Link
This section explains how Stateful Address Configuration using DHCPv6 This section explains how Stateful Address Configuration using DHCP
support can be enabled in a Proxy Mobile IPv6 domain. It also support can be enabled in a Proxy Mobile IPv6 domain. It also
identifies the required configuration in DHCP and mobility identifies the required configuration in DHCP and mobility
infrastructures for supporting this address configuration mode and infrastructures for supporting this address configuration mode and
also identifies the protocol interactions between these two systems. also identifies the protocol interactions between these two systems.
o For supporting Stateful Address Configuration using DHCP, the DHCP o For supporting Stateful Address Configuration using DHCP, the DHCP
relay agent [RFC-3315] service MUST be configured on all the relay agent [RFC-3315] service MUST be supported on all the mobile
mobile access gateways in the Proxy Mobile IPv6 domain. Further, access gateways in the Proxy Mobile IPv6 domain. Further, as
as specified in Section 20 of [RFC-3315], the DHCP relay agent specified in Section 20 of [RFC-3315], the DHCP relay agent should
should be configured to use a list of destination addresses, which be configured to use a list of destination addresses, which MAY
MAY include unicast addresses, the All_DHCP_Servers multicast include unicast addresses, the All_DHCP_Servers multicast address,
address, or other addresses as required in a given deployment. or other addresses as required in a given deployment.
o The DHCP infrastructure needs to be configured with different IPv6 o The DHCP infrastructure needs to be configured to assign addresses
prefix groups, each group MUST represent a link in that Proxy from each of the prefixes assigned to a link in that Proxy Mobile
Mobile IPv6 domain on which those respective prefixes are hosted. IPv6 domain. The DHCP relay agent indicates the link to which the
In essence the DHCP infrastructure is aware of all the links in mobile node is attached by including an IPv6 address from any of
that domain along with the associated IPv6 prefixes with each one the prefixes assigned to that link in the link-address field of
of those links. This configuration requirement is identical to the Relay Forward message. Therefore, for each link in the Mobile
the fixed infrastructure configuration except with the key IPv6 domain, the DHCP infrastructure will:
difference that these links are mobile in nature, a link along
with its prefixes associated with a given mobile node and a mobile * be configured with a list of all of the prefixes associated
access gateway pair at a point of time may be associated with a with that link;
different mobile access gateway and mobile node pair at a later
point of time. However, from the perspective of the DHCP server, * identify the link to which the mobile node is attached by
this aspect of prefix mobility will not be visible to it. looking up the prefix for the link-address field in the Relay
Forward message in the list of prefixes associated with each
link
* assign to the host an address from each prefix associated with
the link to which the mobile node is attached.
This DHCP infrastructure configuration requirement is identical
with other IPv6 networks; other than receiving DHCP messages from
a mobile node through different relay agents (MAGs) over time, the
DHCP infrastructure will be unaware of the mobile node's
capability with respect to mobility support.
o The local mobility anchor needs to have the same awareness with o The local mobility anchor needs to have the same awareness with
respect to the links along with the associated prefixes in a Proxy respect to the links along with the associated prefixes in a Proxy
Mobile IPv6 domain. When a local mobilty anchor assigns Mobile IPv6 domain. When a local mobility anchor assigns
prefix(es) to a mobile node, it MUST assign all the prefixes prefix(es) to a mobile node, it MUST assign all the prefixes
associated with a given link and all of those assigned prefixes associated with a given link and all of those assigned prefixes
will remain as the home network prefixes for that mobile node will remain as the home network prefixes for that mobile node
through out the life of that mobility session. The serving mobile through out the life of that mobility session. The serving mobile
access gateway that hosts these prefixes is physically connected access gateway that hosts these prefixes is physically connected
to that link and can function as the DHCP relay agent. This to that link and can function as the DHCP relay agent. This
common understanding between DHCP and mobility entities about all common understanding between DHCP and mobility entities about all
the links in the domain along with the associated prefixes, the links in the domain along with the associated prefixes,
provides the required coordination for allowing mobility entities provides the required coordination for allowing mobility entities
to perform prefix assignment dynamically to a mobile node and to perform prefix assignment dynamically to a mobile node and
still allowing DHCP infrastructure to perform address assignment still allow the DHCP infrastructure to perform address assignment
for that mobile node only from its home network prefixes. for that mobile node only from its home network prefixes.
o When a mobile node sends a DHCP request message, the DHCP relay o When a mobile node sends a DHCP request message, the DHCP relay
agent function on the mobile access gateway will set the link- agent function on the mobile access gateway will set the link-
address field in the DHCP message to an address in the mobile address field in the DHCP message to an address in the mobile
node's home network prefix (any one of the mobile node's home node's home network prefix (any one of the mobile node's home
network prefixes assigned to that mobile node's attached network prefixes assigned to that mobile node's attached
interface). The address can be generated as per [RFC-4862] by interface). The mobile access gateway can generate an
combining that mobile node's home network prefix and its own autoconfiguration address from one of the mobile node's home
interface identifier on that access link shared with the mobile network prefixes [RFC-4862] and can use this address link-address
node, so as to provide a hint to the DHCP Server for the link option, so as to provide a hint to the DHCP Server for the link
identification. The DHCP server on receiving the request from the identification. The DHCP server on receiving the request from the
mobile node, will allocate addresses from all the prefixes mobile node, will allocate addresses from all the prefixes
associated with that link (identified using the link-address field associated with that link (identified using the link-address field
of the request). of the request).
o Once the mobile node obtains address(es) and moves to a different o Once the mobile node obtains address(es) and moves to a different
link and sends a DHCP request (at any time) for extending the DHCP link and sends a DHCP request (at any time) for extending the DHCP
lease, the DHCP relay agent on the new link will set the prefix lease, the DHCP relay agent on the new link will set the link-
hint in the DHCP message to one of the mobile node's home network address field in the DHCP Relay Forward message to one of the
prefixes. The DHCP server will identify the client from the mobile node's home network prefixes. The DHCP server will
Client-DUID option and will identify the link from the link- identify the client from the Client-DUID option and will identify
address option present in the request and will allocate the same the link from the link-address option present in the request and
address(es) as before. will allocate the same address(es) as before.
o The DHCP based address configuration is not recommended for
deployments where the local mobility anchor and the mobile access
gateway are located in different administrative domains. For this
configuration to work, all the mobile access gateways in the Proxy
Mobile IPv6 domain should be able to ensure that the DHCP request
messages from a given mobile node anchored on any of the access
links in that domain, will always be handled by the same DHCP
server or by a server from the same group of coordinated DHCP
servers serving that domain.
o The DHCP infrastructure should be configured to offer low address o For correct operation of the model of network-based mobility
lease reclaiming the address even after the local mobility anchor management in which the host does not participate in any mobility
deletes the mobile node's binding cache entry. It is recommended management, the mobile node MUST always be assigned an identical
that the configured lease time be lower than the accepted binding set of IPv6 addresses regardless of the access link to which the
lifetime for any mobility binding. mobile node is attached. For example, the mobile access gateways
in the Proxy Mobile IPv6 domain should be configured so that DHCP
messages from a mobile node will always be handled by the same
DHCP server or by a server from the same group of coordinated DHCP
servers serving that domain. DHCP based address configuration is
not recommended for deployments in which the local mobility anchor
and the mobile access gateway are located in different
administrative domains.
6.12. Home Network Prefix Renumbering 6.12. Home Network Prefix Renumbering
If the mobile node's home network prefix(es) gets renumbered or If the mobile node's home network prefix(es) gets renumbered or
becomes invalid during the middle of a mobility session, the mobile becomes invalid during the middle of a mobility session, the mobile
access gateway MUST withdraw the prefix(es) by sending a Router access gateway MUST withdraw the prefix(es) by sending a Router
Advertisement message on the access link with zero prefix lifetime Advertisement message on the access link with zero prefix lifetime
for the prefix(es) that is being renumbered. Also, the local for the prefix(es) that is being renumbered. Also, the local
mobility anchor and the mobile access gateway MUST delete the created mobility anchor and the mobile access gateway MUST delete the created
routing state for the renumbered prefix(es). However, the specific routing state for the renumbered prefix(es). However, the specific
skipping to change at page 64, line 23 skipping to change at page 65, line 44
regular IP access to some other nodes. This requires the network to regular IP access to some other nodes. This requires the network to
have control on when to enable network-based mobility management have control on when to enable network-based mobility management
service to a mobile node and when to enable regular IPv6 access. service to a mobile node and when to enable regular IPv6 access.
This specification does not disallow such configuration. This specification does not disallow such configuration.
Upon detecting a mobile node on its access link and after policy Upon detecting a mobile node on its access link and after policy
considerations, the mobile access gateway MUST determine if network- considerations, the mobile access gateway MUST determine if network-
based mobility management service should be offered to that mobile based mobility management service should be offered to that mobile
node. If the mobile node is entitled for network-based mobility node. If the mobile node is entitled for network-based mobility
management service, then the mobile access gateway must ensure the management service, then the mobile access gateway must ensure the
mobile node believes it is on its home link, as explained in various mobile node does not detect any change with respect to its layer-3
sections of this specification. attachment, as explained in various sections of this specification.
If the mobile node is not entitled for the network-based mobility If the mobile node is not entitled for the network-based mobility
management service, as determined from the policy considerations, the management service, as determined from the policy considerations, the
mobile access gateway MAY choose to offer regular IPv6 access to the mobile access gateway MAY choose to offer regular IPv6 access to the
mobile node and in such a scenario the normal IPv6 considerations mobile node and in such a scenario the normal IPv6 considerations
apply. If IPv6 access is enabled, the mobile node SHOULD be able to apply. If IPv6 access is enabled, the mobile node SHOULD be able to
obtain IPv6 address(es) using the normal IPv6 address configuration obtain IPv6 address(es) using the normal IPv6 address configuration
procedures. The obtained address(es) must be from a local visitor procedures. The obtained address(es) must be from a local visitor
network prefix(es). This essentially ensures that the mobile access network prefix(es). This essentially ensures that the mobile access
gateway functions as a normal access router to a mobile node attached gateway functions as a normal access router to a mobile node attached
skipping to change at page 65, line 27 skipping to change at page 66, line 46
access gateway may not know the mobile node's home network prefix(es) access gateway may not know the mobile node's home network prefix(es)
and may not be able to emulate the mobile node's home link on the and may not be able to emulate the mobile node's home link on the
access link. In such a scenario, the mobile node may notice a delay access link. In such a scenario, the mobile node may notice a delay
before it receives a Router Advertisement message. This will also before it receives a Router Advertisement message. This will also
affect mobile nodes that would be capable of handling their own affect mobile nodes that would be capable of handling their own
mobility, or mobile nodes that do not need to maintain the same IP mobility, or mobile nodes that do not need to maintain the same IP
address through movements. address through movements.
If the received Router Advertisement message has the Managed Address If the received Router Advertisement message has the Managed Address
Configuration flag set, the mobile node, as it would normally do, Configuration flag set, the mobile node, as it would normally do,
will send a DHCPv6 Request [RFC-3315]. The DHCP relay service will send a DHCP Request [RFC-3315]. The DHCP relay service enabled
enabled on that access link will ensure the mobile node can obtain on that access link will ensure the mobile node can obtain one or
one or more addresses and from its home network prefix(es). more addresses from its home network prefix(es).
If the received Router Advertisement message does not have the If the received Router Advertisement message does not have the
Managed Address Configuration flag set and if the mobile node is Managed Address Configuration flag set and if the mobile node is
allowed to use autoconfigured address(es), the mobile node will be allowed to use autoconfigured address(es), the mobile node will be
able to obtain IPv6 address(es) and from each of its home network able to obtain IPv6 address(es) and from each of its home network
prefixes using any of the standard IPv6 address configuration prefixes using any of the standard IPv6 address configuration
mechanisms permitted for that mode. mechanisms permitted for that mode.
If the mobile node is IPv4 enabled and if the network permits, it If the mobile node is IPv4 enabled and if the network permits, it
will be able to obtain the IPv4 address configuration as specified in will be able to obtain the IPv4 address configuration as specified in
skipping to change at page 66, line 5 skipping to change at page 67, line 25
continue to use this address configuration as long as it is attached continue to use this address configuration as long as it is attached
to the network that is in the scope of that Proxy Mobile IPv6 domain. to the network that is in the scope of that Proxy Mobile IPv6 domain.
7.2. Roaming in the Proxy Mobile IPv6 Domain 7.2. Roaming in the Proxy Mobile IPv6 Domain
After obtaining the address configuration in the Proxy Mobile IPv6 After obtaining the address configuration in the Proxy Mobile IPv6
domain, as the mobile node moves and changes its point of attachment domain, as the mobile node moves and changes its point of attachment
from one mobile access gateway to the other, it can still continue to from one mobile access gateway to the other, it can still continue to
use the same address configuration. As long as the attached access use the same address configuration. As long as the attached access
link is in the scope of that Proxy Mobile IPv6 domain, the mobile link is in the scope of that Proxy Mobile IPv6 domain, the mobile
node will always detect the same default-router advertising the node will always detect the same router advertising itself as a
mobile node's home network prefix(es) on each connected link. If the default-router and advertising the mobile node's home network
mobile node has address configuration that it obtained using DHCPv6, prefix(es) on each connected link. If the mobile node has address
it will be able to retain the address configuration and extend the configuration that it obtained using DHCP, it will be able to retain
lease lifetime. the address configuration and extend the lease lifetime.
8. Message Formats 8. Message Formats
This section defines extensions to the Mobile IPv6 [RFC-3775] This section defines extensions to the Mobile IPv6 [RFC-3775]
protocol messages. protocol messages.
8.1. Proxy Binding Update Message 8.1. Proxy Binding Update Message
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
skipping to change at page 82, line 13 skipping to change at page 84, line 13
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] 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.
[RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, December 1998.
[RFC-3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC 3168, September
2001.
[RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 3315, July 2003. RFC 3315, July 2003.
[RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005. January 2005.
 End of changes. 43 change blocks. 
175 lines changed or deleted 251 lines changed or added

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