draft-ietf-netlmm-proxymip6-07.txt   draft-ietf-netlmm-proxymip6-08.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: May 7, 2008 V. Devarapalli Expires: June 27, 2008 V. Devarapalli
Azaire Networks Azaire Networks
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
B. Patil B. Patil
Nokia Siemens Networks Nokia Siemens Networks
November 04, 2007 December 25, 2007
Proxy Mobile IPv6 Proxy Mobile IPv6
draft-ietf-netlmm-proxymip6-07.txt draft-ietf-netlmm-proxymip6-08.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 May 7, 2008. This Internet-Draft will expire on June 27, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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 mobility on signaling. The Network is responsible for managing IP mobility on
behalf of the host. The design principle in the case of a network- behalf of the host. The mobility entities in the network are
based mobility management protocol relies on the network being in responsible for tracking the movements of the host and initiating the
control of the mobility management. The mobility entities in the required mobility signaling on its behalf. This specification
network are responsible for tracking the movements of the host and describes a network-based mobility management protocol and is
initiating the required mobility signaling on its behalf. This referred to as Proxy Mobile IPv6.
specification describes a network-based mobility management protocol
and is referred to as Proxy Mobile IPv6.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 5 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4
2.1. Conventions used in this document . . . . . . . . . . . . 5 2.1. Conventions used in this document . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Proxy Mobile IPv6 Protocol Overview . . . . . . . . . . . . . 8 3. Proxy Mobile IPv6 Protocol Overview . . . . . . . . . . . . . 8
4. Proxy Mobile IPv6 Protocol Security . . . . . . . . . . . . . 14 4. Proxy Mobile IPv6 Protocol Security . . . . . . . . . . . . . 14
4.1. Peer Authorization Database Entries . . . . . . . . . . . 14 4.1. Peer Authorization Database Entries . . . . . . . . . . . 15
4.2. Security Policy Database Entries . . . . . . . . . . . . . 15 4.2. Security Policy Database Entries . . . . . . . . . . . . . 15
5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 16 5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 16
5.1. Extensions to Binding Cache Entry Data Structure . . . . . 16 5.1. Extensions to Binding Cache Entry Data Structure . . . . . 16
5.2. Supported Home Network Prefix Models . . . . . . . . . . . 18 5.2. Supported Home Network Prefix Models . . . . . . . . . . . 18
5.3. Signaling Considerations . . . . . . . . . . . . . . . . . 18 5.3. Signaling Considerations . . . . . . . . . . . . . . . . . 18
5.4. Multihoming Support . . . . . . . . . . . . . . . . . . . 24 5.4. Multihoming Support . . . . . . . . . . . . . . . . . . . 24
5.5. Timestamp Option for Message Ordering . . . . . . . . . . 27 5.5. Timestamp Option for Message Ordering . . . . . . . . . . 28
5.6. Routing Considerations . . . . . . . . . . . . . . . . . . 30 5.6. Routing Considerations . . . . . . . . . . . . . . . . . . 30
5.6.1. Bi-Directional Tunnel Management . . . . . . . . . . . 30 5.6.1. Bi-Directional Tunnel Management . . . . . . . . . . . 30
5.6.2. Forwarding Considerations . . . . . . . . . . . . . . 31 5.6.2. Forwarding Considerations . . . . . . . . . . . . . . 31
5.7. Local Mobility Anchor Address Discovery . . . . . . . . . 31 5.7. Local Mobility Anchor Address Discovery . . . . . . . . . 32
5.8. Mobile Prefix Discovery Considerations . . . . . . . . . . 32 5.8. Mobile Prefix Discovery Considerations . . . . . . . . . . 32
5.9. Route Optimizations Considerations . . . . . . . . . . . . 32 5.9. Route Optimizations Considerations . . . . . . . . . . . . 33
6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 33 6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 33
6.1. Extensions to Binding Update List Entry Data Structure . . 33 6.1. Extensions to Binding Update List Entry Data Structure . . 34
6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 34 6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 35
6.3. Supported Access Link Types . . . . . . . . . . . . . . . 35 6.3. Supported Access Link Types . . . . . . . . . . . . . . . 35
6.4. Supported Address Configuration Models . . . . . . . . . . 35 6.4. Supported Address Configuration Models . . . . . . . . . . 36
6.5. Access Authentication & Mobile Node Identification . . . . 36 6.5. Access Authentication & Mobile Node Identification . . . . 36
6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 36 6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 36
6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 37 6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 37
6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 37 6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 38
6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 39 6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 39
6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 39 6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 39
6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 44 6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 45
6.9.3. Retransmissions and Rate Limiting . . . . . . . . . . 44 6.9.3. Retransmissions and Rate Limiting . . . . . . . . . . 45
6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 45 6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 46
6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 45 6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 46
6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 45 6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 46
6.10.3. Routing State . . . . . . . . . . . . . . . . . . . . 46 6.10.3. Routing State . . . . . . . . . . . . . . . . . . . . 47
6.10.4. Local Routing . . . . . . . . . . . . . . . . . . . . 47 6.10.4. Local Routing . . . . . . . . . . . . . . . . . . . . 48
6.10.5. Tunnel Management . . . . . . . . . . . . . . . . . . 48 6.10.5. Tunnel Management . . . . . . . . . . . . . . . . . . 49
6.10.6. Forwarding Rules . . . . . . . . . . . . . . . . . . . 48 6.10.6. Forwarding Rules . . . . . . . . . . . . . . . . . . . 49
6.11. Supporting DHCPv6 based Address Configuration on the 6.11. Supporting DHCPv6 based Address Configuration on the
Access Link . . . . . . . . . . . . . . . . . . . . . . . 49 Access Link . . . . . . . . . . . . . . . . . . . . . . . 50
6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 50 6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 51
6.13. Mobile Node Detachment Detection and Resource Cleanup . . 50 6.13. Mobile Node Detachment Detection and Resource Cleanup . . 51
6.14. Allowing network access to other IPv6 nodes . . . . . . . 51 6.14. Allowing network access to other IPv6 nodes . . . . . . . 52
7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 52 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 53
7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 52 7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 53
7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 53 7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 54
7.3. IPv6 Host Protocol Parameters . . . . . . . . . . . . . . 53 7.3. IPv6 Host Protocol Parameters . . . . . . . . . . . . . . 54
8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 54 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 55
8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 55 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 56
8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 56 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 57
8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 57 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 58
8.4. Access Technology Type Option . . . . . . . . . . . . . . 59 8.4. Access Technology Type Option . . . . . . . . . . . . . . 60
8.5. Mobile Node Interface Identifier Option . . . . . . . . . 60 8.5. Mobile Node Interface Identifier Option . . . . . . . . . 61
8.6. Link-local Address Option . . . . . . . . . . . . . . . . 61 8.6. Link-local Address Option . . . . . . . . . . . . . . . . 62
8.7. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 62 8.7. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 63
8.8. Status Values . . . . . . . . . . . . . . . . . . . . . . 63 8.8. Status Values . . . . . . . . . . . . . . . . . . . . . . 64
9. Protocol Configuration Variables . . . . . . . . . . . . . . . 65 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 66
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67
11. Security Considerations . . . . . . . . . . . . . . . . . . . 66 11. Security Considerations . . . . . . . . . . . . . . . . . . . 68
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69
13.1. Normative References . . . . . . . . . . . . . . . . . . . 68 13.1. Normative References . . . . . . . . . . . . . . . . . . . 69
13.2. Informative References . . . . . . . . . . . . . . . . . . 68 13.2. Informative References . . . . . . . . . . . . . . . . . . 70
Appendix A. Proxy Mobile IPv6 interactions with AAA Appendix A. Proxy Mobile IPv6 interactions with AAA
Infrastructure . . . . . . . . . . . . . . . . . . . 69 Infrastructure . . . . . . . . . . . . . . . . . . . 71
Appendix B. Supporting Shared-Prefix Model using DHCPv6 . . . . . 70 Appendix B. Supporting Shared-Prefix Model using DHCPv6 . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 72
Intellectual Property and Copyright Statements . . . . . . . . . . 72 Intellectual Property and Copyright Statements . . . . . . . . . . 74
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] is host centric as it requires Mobility as specified in [RFC-3775] requires the IP host to send IP
the IP host to manage its own mobility by signaling the Home Agent, mobility management signaling messages to the Home Agent, which is
which is located in the network. located in the network.
Network-based mobility is another approach to solving the IP mobility Network-based mobility is another approach to solving the IP mobility
challenge. It is possible to support mobility for IPv6 nodes without challenge. It is possible to support mobility for IPv6 nodes without
host involvement by extending Mobile IPv6 [RFC-3775] signaling host involvement by extending Mobile IPv6 [RFC-3775] signaling
messages and reusing the home agent. This approach to supporting messages and reusing the home agent. This approach to supporting
mobility does not require the mobile node to be involved in the mobility does not require the mobile node to be involved in the
exchange of signaling messages between itself and the Home Agent. A exchange of signaling messages between itself and the Home Agent. A
proxy mobility agent in the network performs the signaling with the proxy mobility agent in the network performs the signaling with the
home agent and does the mobility management on behalf of the mobile home agent and does the mobility management on behalf of the mobile
node attached to the network. Because of the use and extension of node attached to the network. Because of the use and extension of
skipping to change at page 4, line 43 skipping to change at page 4, line 43
functionality in the network. The advantages of developing a network functionality in the network. The advantages of developing a network
based mobility protocol based on Mobile IPv6 are: based mobility protocol based on Mobile IPv6 are:
o Reuse of home agent functionality and the messages/format used in o Reuse of home agent functionality and the messages/format used in
mobility signaling. Mobile IPv6 is a mature protocol with several mobility signaling. Mobile IPv6 is a mature protocol with several
implementations that have undergone interoperability testing. implementations that have undergone interoperability testing.
o A common home agent would serve as the mobility agent for all o A common home agent would serve as the mobility agent for all
types of IPv6 nodes. types of IPv6 nodes.
o Addresses a deployment need.
o May be better suited on certain types of resource-constrained
links or because of service provider specific policies.
The problem statement and the need for a network based mobility The problem statement and the need for a network based mobility
protocol solution has been documented in [RFC-4830]. Proxy Mobile protocol solution has been documented in [RFC-4830]. Proxy Mobile
IPv6 is a solution that addresses these issues and requirements. IPv6 is a solution that addresses these issues and requirements.
This document builds on Mobile IPv6 [RFC-3775] in specifying a
network-based mobility management protocol.
2. Conventions & Terminology 2. Conventions & Terminology
2.1. Conventions used in this document 2.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC-2119]. document are to be interpreted as described in RFC 2119 [RFC-2119].
2.2. Terminology 2.2. Terminology
skipping to change at page 5, line 39 skipping to change at page 5, line 37
domain includes local mobility anchors and mobile access gateways domain includes local mobility anchors and mobile access gateways
between which security associations can be setup and authorization between which security associations can be setup and authorization
for sending Proxy Binding Updates on behalf of the mobile nodes for sending Proxy Binding Updates on behalf of the mobile nodes
can be ensured. can be ensured.
Local Mobility Anchor (LMA) Local Mobility Anchor (LMA)
Local Mobility Anchor is the home agent for the mobile node in the Local Mobility Anchor is the home agent for the mobile node in the
Proxy Mobile IPv6 domain. It is the topological anchor point for Proxy Mobile IPv6 domain. It is the topological anchor point for
the mobile node's home network prefix and is the entity that the mobile node's home network prefix and is the entity that
manages the mobile node's binding state. It is important to manages the mobile node's binding state. The local mobility
understand that the local mobility anchor has the functional anchor has the functional capabilities of a home agent as defined
capabilities of a home agent as defined in Mobile IPv6 base in Mobile IPv6 base specification [RFC-3775] with the additional
specification [RFC-3775] with the additional capabilities required capabilities required for supporting Proxy Mobile IPv6 protocol as
for supporting Proxy Mobile IPv6 protocol as defined in this defined in this specification.
specification.
Mobile Access Gateway (MAG) Mobile Access Gateway (MAG)
Mobile Access Gateway is a function that manages the mobility Mobile Access Gateway is a function that manages the mobility
related signaling for a mobile node that is attached to its access related signaling for a mobile node that is attached to its access
link. It is responsible for tracking the mobile node's movements link. It is responsible for tracking the mobile node's movements
on the access link and for signaling the mobile node's local on the access link and for signaling the mobile node's local
mobility anchor. mobility anchor.
Mobile Node (MN) Mobile Node (MN)
Throughout this document, the term mobile node is used to refer to Throughout this document, the term mobile node is used to refer to
an IP host whose mobility is managed by the network. The mobile an IP host whose mobility is managed by the network. The mobile
skipping to change at page 6, line 15 skipping to change at page 6, line 10
related signaling for a mobile node that is attached to its access related signaling for a mobile node that is attached to its access
link. It is responsible for tracking the mobile node's movements link. It is responsible for tracking the mobile node's movements
on the access link and for signaling the mobile node's local on the access link and for signaling the mobile node's local
mobility anchor. mobility anchor.
Mobile Node (MN) Mobile Node (MN)
Throughout this document, the term mobile node is used to refer to Throughout this document, the term mobile node is used to refer to
an IP host whose mobility is managed by the network. The mobile an IP host whose mobility is managed by the network. The mobile
node may be operating in IPv6 mode, IPv4 mode or in IPv4/IPv6 dual node may be operating in IPv6 mode, IPv4 mode or in IPv4/IPv6 dual
mode. The mobile node is not required to participate in any mode. The mobile node is not required to participate in any IP
mobility related signaling for achieving mobility for an IP mobility related signaling for achieving mobility for an IP
address that is obtained in that Proxy Mobile IPv6 domain. This address that is obtained in that Proxy Mobile IPv6 domain. This
document further uses explicit text when referring to a mobile document further uses explicit text when referring to a mobile
node that is involved in mobility related signaling as per the node that is involved in mobility related signaling as per the
Mobile IPv6 specification [RFC-3775]. Mobile IPv6 specification [RFC-3775].
LMA Address (LMAA) LMA Address (LMAA)
The address that is configured on the interface of the local The address that is configured on the interface of the local
mobility anchor and is the transport endpoint of the bi- mobility anchor and is the transport endpoint of the bi-
skipping to change at page 7, line 4 skipping to change at page 6, line 43
the local mobility anchor and the mobile access gateway. The the local mobility anchor and the mobile access gateway. The
local mobility anchor views this address as the Care-of Address of local mobility anchor views this address as the Care-of Address of
the mobile node and registers it in the Binding Cache entry for the mobile node and registers it in the Binding Cache entry for
that mobile node. When the transport network between the mobile that mobile node. When the transport network between the mobile
access gateway and the local mobility anchor is an IPv4 network access gateway and the local mobility anchor is an IPv4 network
and if the care-of address that is registered at the local 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 Address (MN-HoA) Mobile Node's Home Address (MN-HoA)
MN-HoA is the home address of a mobile node in a Proxy Mobile IPv6 MN-HoA is the home address of a mobile node in a Proxy Mobile IPv6
domain. It is an address from its home network prefix obtained by domain. It is an address from its home network prefix obtained by
a mobile node in a Proxy Mobile IPv6 domain. The mobile node can a mobile node in a Proxy Mobile IPv6 domain. The mobile node can
continue to use this address as long as it is attached to the continue to use this address as long as it is attached to the
network that is in the scope of that Proxy Mobile IPv6 domain. network that is in the scope of that Proxy Mobile IPv6 domain.
Mobile Node's Home Network Prefix (MN-HNP) Mobile Node's Home Network Prefix (MN-HNP)
This is the on-link IPv6 prefix that is always present in the This is the on-link IPv6 prefix that is always present in the
Router Advertisements that the mobile node receives when it is Router Advertisements that the mobile node receives when it is
attached to any of the access links in that Proxy Mobile IPv6 attached to any of the access links in that Proxy Mobile IPv6
domain. This home network prefix is topologically anchored at the domain. This home network prefix is topologically anchored at the
mobile node's local mobility anchor. The mobile node configures mobile node's local mobility anchor. The mobile node configures
its interface with an address from this prefix. If the mobile its interface with an address from this prefix. If the mobile
node connects to the Proxy Mobile IPv6 domain through multiple node connects to the Proxy Mobile IPv6 domain through multiple
interfaces, simultaneously, there will be multiple and unique home interfaces, simultaneously, each of the connected interface will
network prefixes assigned for that mobile node. be assigned a unique home network prefix and under a different
mobility session.
Mobile Node's Home Link Mobile Node's Home Link
This is the link on which the mobile node obtained its initial This is the link on which the mobile node obtained its Layer-3
Layer-3 address configuration for one of its interfaces after it address configuration for the attached interface after it moved
moved into that Proxy Mobile IPv6 domain. This is the link that into that Proxy Mobile IPv6 domain. This is the link that
conceptually follows the mobile node. The network will ensure the conceptually follows the mobile node. The network will ensure the
mobile node always sees this link with respect to the layer-3 mobile node always sees this link with respect to the layer-3
network configuration, on any access link that it attaches to in network configuration, on any access link that it attaches to in
that Proxy Mobile IPv6 domain. that Proxy Mobile IPv6 domain.
Multihomed Mobile Node Multihomed Mobile Node
A mobile node that connects to the Proxy Mobile IPv6 domain A mobile node that connects to the Proxy Mobile IPv6 domain
through more than one interface and uses the interfaces through more than one interface and uses these interfaces
simultaneously is referred to as a multihomed mobile node. simultaneously is referred to as a multihomed mobile node.
Mobile Node Identifier (MN-Identifier) Mobile Node Identifier (MN-Identifier)
The identity of a mobile node in the Proxy Mobile IPv6 domain. The identity of a mobile node in the Proxy Mobile IPv6 domain.
This is the stable identifier of a mobile node that the mobility This is the stable identifier of a mobile node that the mobility
entities in a Proxy Mobile IPv6 domain can always acquire and entities in a Proxy Mobile IPv6 domain can always acquire and use
using which a mobile node can predictably be identified. This is it for predictably identifying a mobile node. This is typically
typically an identifier such as NAI or other identifier such as a an identifier such as NAI or other identifier such as a MAC
MAC address. address.
Mobile Node Interface Identifier (MN-Interface-Identifier) Mobile Node Interface Identifier (MN-Interface-Identifier)
The interface identifier that identifies a given interface of a The interface identifier that identifies a given interface of a
mobile node. For those interfaces that have a layer-2 identifier, mobile node. For those interfaces that have a layer-2 identifier,
the interface identifier can be based on that layer-2 identifier. the interface identifier can be based on that layer-2 identifier.
The interface identifier in some cases is generated by the mobile The interface identifier in some cases is generated by the mobile
node and conveyed to the access router or the mobile access node and conveyed to the access router or the mobile access
gateway. In some cases, there might not be any interface gateway. In some cases, there might not be any interface
identifier associated with the mobile node's interface. identifier associated with the mobile node's interface.
Policy Profile
Policy Profile is an abstract term for referring to a set of
configuration parameters that are configured for a given mobile
node. The mobility entities in the Proxy Mobile IPv6 domain
require access to these parameters for providing the mobility
management to a given mobile node. The specific details on how
the network entities obtain this policy profile is outside the
scope of this document.
Proxy Binding Update (PBU) Proxy Binding Update (PBU)
A binding registration request message sent by a mobile access A binding registration request message sent by a mobile access
gateway to a mobile node's local mobility anchor for establishing gateway to a mobile node's local mobility anchor for establishing
a binding between the mobile node's MN-HNP and the Proxy-CoA. a binding between the mobile node's MN-HNP and the Proxy-CoA.
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.
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
[RFC-3775]. [RFC-3775].
Proxy Mobile IPv6 protocol is intended for providing network-based Proxy Mobile IPv6 protocol is intended for providing network-based IP
mobility management support to a mobile node, without requiring the mobility management support to a mobile node, without requiring the
participation of the mobile node in any mobility related signaling. participation of the mobile node in any IP mobility related
The mobility entities in the network will track the mobile node's signaling. The mobility entities in the network will track the
movements and will initiate the mobility signaling and setup the mobile node's movements and will initiate the mobility signaling and
required routing state. setup the required routing state.
The core functional entities in the NETLMM infrastructure are the The core functional entities in the NETLMM infrastructure are the
Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The
local mobility anchor is responsible for maintaining the mobile local mobility anchor is responsible for maintaining the mobile
node's reachability state and is the topological anchor point for the node's reachability state and is the topological anchor point for the
mobile node's home network prefix. The mobile access gateway is the mobile node's home network prefix. The mobile access gateway is the
entity that performs the mobility management on behalf of a mobile entity that performs the mobility management on behalf of a mobile
node and it resides on the access link where the mobile node is node and it resides on the access link where the mobile node is
anchored. The mobile access gateway is responsible for detecting the anchored. The mobile access gateway is responsible for detecting the
mobile node's movements on its access link and for sending binding mobile node's movements on its access link and for sending binding
skipping to change at page 10, line 16 skipping to change at page 10, line 16
The mobile node may be operating in an IPv4-only mode, IPv6-only mode The mobile node may be operating in an IPv4-only mode, IPv6-only mode
or in dual IPv4/IPv6 mode. Based on what is enabled in the network or in dual IPv4/IPv6 mode. Based on what is enabled in the network
for that mobile node, the mobile node will be able to obtain an IPv4, for that mobile node, the mobile node will be able to obtain an IPv4,
IPv6 or dual IPv4/IPv6 addresses and move anywhere in that Proxy IPv6 or dual IPv4/IPv6 addresses and move anywhere in that Proxy
Mobile IPv6 domain. However, the specific details related to the Mobile IPv6 domain. However, the specific details related to the
IPv4 addressing or IPv4 transport support are specified in the IPv4 addressing or IPv4 transport support are specified in the
companion document [ID-IPV4-PMIP6]. companion document [ID-IPV4-PMIP6].
If the mobile node connects to the Proxy Mobile IPv6 domain, through If the mobile node connects to the Proxy Mobile IPv6 domain, through
multiple interfaces and over multiple access networks, the network multiple interfaces and over multiple access networks, the network
will allocate an unique home network prefix for each of the connected will allocate a unique home network prefix for each of the connected
interfaces and the mobile node will be able to configure an interfaces and the mobile node will be able to configure an
address(es) on those interfaces from the respective home network address(es) on those interfaces from the respective home network
prefixes. If the mobile node performs a handover from one interface prefixes. If the mobile node performs a handover from one interface
to another in the same Proxy Mobile IPv6 domain, then the local to another in the same Proxy Mobile IPv6 domain, then the local
mobility anchor will assign the same prefix to the new interface. mobility anchor will assign the same prefix to the new interface, if
it receives the handover hints from the mobile access gateway in the
signaling messages.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| MN | | MAG | | LMA | | MN | | MAG | | LMA |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | |
MN Attached | | MN Attached | |
| | | | | |
| MN Attached Event | | MN Attached Event |
| (Acquire MN-Id and Profile) | | (Acquire MN-Id and Profile) |
| | | | | |
skipping to change at page 13, line 42 skipping to change at page 13, line 42
| | | | | | | |
Figure 3: Mobile Node Handoff - Signaling Call Flow Figure 3: Mobile Node Handoff - Signaling Call Flow
Figure 3 shows the signaling call flow for the mobile node's handoff Figure 3 shows the signaling call flow for the mobile node's handoff
from previously attached mobile access gateway (p-MAG) to the newly from previously attached mobile access gateway (p-MAG) to the newly
attached mobile access gateway (n-MAG). attached mobile access gateway (n-MAG).
After obtaining the initial address configuration in the Proxy Mobile After obtaining the initial address configuration in the Proxy Mobile
IPv6 domain, if the mobile node changes its point of attachment, the IPv6 domain, if the mobile node changes its point of attachment, the
mobile access gateway on the new access link will signal the local mobile access gateway on the previous link will detect the mobile
mobility anchor for updating the binding and routing state. The node's detachment from the link and will signal the local mobility
anchor and will remove the binding and routing state for that mobile
node. However, the local mobility anchor upon accepting the request
will wait for certain amount of time before it deletes the binding,
for allowing a smooth handoff.
The mobile access gateway on the new access link upon detecting the
mobile node on its access link will signal the local mobility anchor
for updating the binding state. Once that signaling is complete, the
mobile node will continue to receive the Router Advertisements mobile node will continue to receive the Router Advertisements
containing its home network prefix, making it believe it is still on containing its home network prefix, making it believe it is still on
the same link and can use the same address configuration on the new the same link and it will use the same address configuration on the
access link. new 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. A association(s) offering integrity and data origin authentication.
security association with the mobile node for which the signaling
message is issued is not required for protection of these messages.
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
messages [RFC-4301]. IPsec is the default security mechanism for messages [RFC-4301]. IPsec is the default security mechanism for
securing the signaling messages. However in certain deployments of securing the signaling messages. However in certain deployments of
this protocol, other security mechanisms MAY be applied and the this protocol, other security mechanisms MAY be applied and the
signaling messages must be protected using the semantics provided by signaling messages must be protected using the semantics provided by
that respective mechanism. that respective mechanism. The specification of the other security
mechanisms are beyond the scope of this document
IPsec ESP [RFC-4303] in transport mode with mandatory integrity IPsec ESP [RFC-4303] in transport mode with mandatory integrity
protection SHOULD be used for protecting the signaling messages. protection SHOULD be used for protecting the signaling messages.
Confidentiality protection of these messages is not required. Confidentiality protection of these messages is not required.
IKEv2 [RFC-4306] SHOULD be used to setup security associations IKEv2 [RFC-4306] SHOULD be used to setup security associations
between the mobile access gateway and the local mobility anchor to between the mobile access gateway and the local mobility anchor to
protect the Proxy Binding Update and Proxy Binding Acknowledgement protect the Proxy Binding Update and Proxy Binding Acknowledgement
messages. The mobile access gateway and the local mobility anchor messages. The mobile access gateway and the local mobility anchor
can use any of the authentication mechanisms, as specified in IKEv2, can use any of the authentication mechanisms, as specified in IKEv2,
for mutual authentication. for mutual authentication.
The Mobile IPv6 specification [RFC-3775] requires the home agent to The Mobile IPv6 specification [RFC-3775] requires the home agent to
prevent a mobile node from creating security associations or creating prevent a mobile node from creating security associations or creating
binding cache entries for another mobile node's home address. In the binding cache entries for another mobile node's home address. In the
protocol described in this document, the mobile node is not involved protocol described in this document, the mobile node is not involved
in creating security associations for protecting the signaling in creating security associations for protecting the signaling
messages or sending binding updates. Therefore, this is not a messages or sending binding updates. Therefore, the local mobility
concern. However, the local mobility anchor MUST allow only anchor MUST allow only authorized mobile access gateways to create
authorized mobile access gateways to create binding cache entries on binding cache entries on behalf of the mobile nodes. The actual
behalf of the mobile nodes. The actual mechanism by which the local mechanism by which the local mobility anchor verifies if a specific
mobility anchor verifies if a specific mobile access gateway is mobile access gateway is authorized to send Proxy Binding Updates on
authorized to send Proxy Binding Updates on behalf of a mobile node behalf of a mobile node is outside the scope of this document. One
is outside the scope of this document. One possible way this could possible way this could be achieved is by sending a query to the
be achieved is by sending a query to the policy store, such as AAA. policy store, such as AAA.
4.1. Peer Authorization Database Entries 4.1. Peer Authorization Database Entries
This section describes PAD entries on the mobile access gateway and This section describes PAD entries [RFC-4301] on the mobile access
the local mobility anchor. The PAD entries are only example gateway and the local mobility anchor. The PAD entries are only
configurations. Note that the PAD is a logical concept and a example configurations. Note that the PAD is a logical concept and a
particular mobile access gateway or a local mobility anchor particular mobile access gateway or a local mobility anchor
implementation can implement the PAD in any implementation specific implementation can implement the PAD in any implementation specific
manner. The PAD state may also be distributed across various manner. The PAD state may also be distributed across various
databases in a specific implementation. databases in a specific implementation.
mobile access gateway PAD: mobile access gateway PAD:
- IF remote_identity = lma_identity_1 - IF remote_identity = lma_identity_1
Then authenticate (shared secret/certificate/EAP) Then authenticate (shared secret/certificate/EAP)
and authorize CHILD_SA for remote address lma_addres_1 and authorize CHILD_SA for remote address lma_addres_1
skipping to change at page 15, line 26 skipping to change at page 15, line 34
and authorize CHILD_SAs for remote address mag_address_1 and authorize CHILD_SAs for remote address mag_address_1
Figure 4: PAD Entries Figure 4: PAD Entries
The list of authentication mechanisms in the above examples is not The list of authentication mechanisms in the above examples is not
exhaustive. There could be other credentials used for authentication exhaustive. There could be other credentials used for authentication
stored in the PAD. stored in the PAD.
4.2. Security Policy Database Entries 4.2. Security Policy Database Entries
This section describes the security policy entries on the mobile This section describes the security policy entries [RFC-4301] on the
access gateway and the local mobility anchor required to protect the mobile access gateway and the local mobility anchor required to
Proxy Mobile IPv6 signaling messages. The SPD entries are only protect the Proxy Mobile IPv6 signaling messages. The SPD entries
example configurations. A particular mobile access gateway or a are only example configurations. A particular mobile access gateway
local mobility anchor implementation could configure different SPD or a local mobility anchor implementation could configure different
entries as long as they provide the required security. SPD entries as long as they provide the required security.
In the examples shown below, the identity of the mobile access In the examples shown below, the identity of the mobile access
gateway is assumed to be mag_1, the address of the mobile access gateway is assumed to be mag_1, the address of the mobile access
gateway is assumed to be mag_address_1, and the address of the local gateway is assumed to be mag_address_1, and the address of the local
mobility anchor is assumed to be lma_address_1. mobility anchor is assumed to be lma_address_1.
mobile access gateway SPD-S: mobile access gateway SPD-S:
- IF local_address = mag_address_1 & - IF local_address = mag_address_1 &
remote_address = lma_address_1 & remote_address = lma_address_1 &
proto = MH & local_mh_type = BU & remote_mh_type = BA proto = MH & local_mh_type = BU & remote_mh_type = BA
skipping to change at page 16, line 22 skipping to change at page 16, line 22
local mobility anchor SPD-S: local mobility anchor SPD-S:
- IF local_address = lma_address_1 & - IF local_address = lma_address_1 &
remote_address = mag_address_1 & remote_address = mag_address_1 &
proto = MH & local_mh_type = BA & remote_mh_type = BU proto = MH & local_mh_type = BA & remote_mh_type = BU
Then use SA ESP transport mode Then use SA ESP transport mode
Figure 5: SPD Entries Figure 5: SPD Entries
5. Local Mobility Anchor Operation 5. Local Mobility Anchor Operation
For supporting the Proxy Mobile IPv6 protocol specified in this The local mobility anchor MUST support the home agent function as
document, the home agent function, specified in [RFC-3775] requires defined in [RFC-3775] and additionally the extensions defined in this
certain functional modifications and enhancements. The home agent specification. A home agent with these modifications and enhanced
with these modifications and enhanced capabilities for supporting capabilities for supporting Proxy Mobile IPv6 protocol is referred to
Proxy Mobile IPv6 protocol is referred to as the local mobility as the local mobility anchor.
anchor.
This section describes the operational details of the local mobility This section describes the operational details of the local mobility
anchor. anchor.
5.1. Extensions to Binding Cache Entry Data Structure 5.1. Extensions to Binding Cache Entry Data Structure
Every local mobility anchor MUST maintain a Binding Cache entry for Every local mobility anchor MUST maintain a Binding Cache entry for
each currently registered mobile node. Binding Cache entry is a each currently registered mobile node. Binding Cache entry is a
conceptual data structure, described in Section 9.1 [RFC-3775]. conceptual data structure, described in Section 9.1 [RFC-3775].
skipping to change at page 17, line 7 skipping to change at page 17, line 7
Binding Cache entries that are proxy registrations and is turned Binding Cache entries that are proxy registrations and is turned
off for all other entries that are created due to the off for all other entries that are created due to the
registrations directly sent by the mobile node. registrations directly sent by the mobile node.
o The identifier of the registered mobile node, MN-Identifier. This o The identifier of the registered mobile node, MN-Identifier. This
identifier is obtained from the Mobile Node Identifier Option identifier is obtained from the Mobile Node Identifier Option
[RFC-4283] present in the received Proxy Binding Update request. [RFC-4283] present in the received Proxy Binding Update request.
o The interface identifier of the mobile node's connected interface o The interface identifier of the mobile node's connected interface
on the access link. This identifier can be acquired from the on the access link. This identifier can be acquired from the
Mobile Node Interface Identifier option (with P Flag set to 0), Mobile Node Interface Identifier option, present in the received
present in the received Proxy Binding Update request. If the Proxy Binding Update request. If the option was not present in
option was not present in the request, this value MUST be set to the request, this value MUST be set to ALL_ZERO.
ALL_ZERO.
o The Link-local address of the mobile node on the interface o The Link-local address of the mobile node on the interface
attached to the access link. This is obtained from the Link-local attached to the access link. This is obtained from the Link-local
Address option, present in the Proxy Binding Update request. Address option, present in the Proxy Binding Update request.
o The IPv6 home network prefix of the registered mobile node. The o The IPv6 home network prefix of the registered mobile node. The
home network prefix of the mobile node may have been statically home network prefix of the mobile node may have been statically
configured in the mobile node's policy profile, or, it may have configured in the mobile node's policy profile, or, it may have
been dynamically allocated by the local mobility anchor. The IPv6 been dynamically allocated by the local mobility anchor. The IPv6
home network prefix also includes the corresponding prefix length. home network prefix also includes the corresponding prefix length.
skipping to change at page 18, line 8 skipping to change at page 18, line 8
o MN-Identifier, Proxy-CoA o MN-Identifier, Proxy-CoA
o MN-Identifier, MN-Interface-Identifier o MN-Identifier, MN-Interface-Identifier
o MN-Identifier, Access Technology Type (When MN-Interface- o MN-Identifier, Access Technology Type (When MN-Interface-
Identifier is not present) Identifier is not present)
5.2. Supported Home Network Prefix Models 5.2. Supported Home Network Prefix Models
This specification supports Per-MN-Prefix model and does not support This specification supports Per-MN-Prefix model and does not support
Shared-Prefix model. As per the Per-MN-Prefix model, there will be Shared-Prefix model. As per the Per-MN-Prefix model, there will be a
an unique home network prefix assigned to each mobile node and no unique home network prefix assigned to each mobile node and no other
other node shares an address from that prefix. node shares an address from that prefix. The assigned prefix is
unique to a mobile node and also unique to a given interface of the
mobile node. If the mobile node attaches to the Proxy Mobile IPv6
domain through multiple interfaces and simultaneously, each of those
connected interfaces will be assigned a different prefix.
The mobile node's home network prefix is always hosted on the access The mobile node's home network prefix is always hosted on the access
link where the mobile node is anchored. Conceptually, the entire link where the mobile node is anchored. Conceptually, the entire
home network prefix follows the mobile node as it moves within the home network prefix follows the mobile node as it moves within the
Proxy Mobile IPv6 domain. The local mobility anchor is not required Proxy Mobile IPv6 domain. The local mobility anchor is not required
to perform any proxy ND operations [RFC-4861] for defending the to perform any proxy ND operations [RFC-4861] for defending the
mobile node's home address on the home link. However, from the mobile node's home address on the home link. However, from the
routing perspective, the home network prefix is topologically routing perspective, the home network prefix is topologically
anchored on the local mobility anchor. anchored on the local mobility anchor.
5.3. Signaling Considerations 5.3. Signaling Considerations
This section provides the rules for processing the signaling
messages. The processing rules specified in this section and other
related sections are chained and are in a specific order. When
applying these considerations for processing the signaling messages,
the specified order MUST be maintained.
Processing Binding Registrations Processing Binding Registrations
Upon receiving a Proxy Binding Update request (a Binding Update Upon receiving a Proxy Binding Update request (a Binding Update
Request with the 'P' flag set) from a mobile access gateway on behalf Request with the 'P' flag set) from a mobile access gateway on behalf
of a mobile node, the local mobility anchor MUST process the request of a mobile node, the local mobility anchor MUST process the request
as defined in Section 10.3 [RFC-3775], with one exception that this as defined in Section 10.3 [RFC-3775]; additionally the following
request is a Proxy Binding Update request and hence the following considerations must be applied.
additional considerations must be applied.
o The local mobility anchor MUST observe the rules described in 1. The local mobility anchor MUST observe the rules described in
Section 9.2 [RFC-3775] when processing Mobility Headers in the Section 9.2 [RFC-3775] when processing Mobility Headers in the
received Proxy Binding Update request. received Proxy Binding Update request.
o The local mobility anchor MUST identify the mobile node from the 2. The local mobility anchor MUST identify the mobile node from the
identifier present in the Mobile Node Identifier option [RFC-4283] identifier present in the Mobile Node Identifier option [RFC-
of the Proxy Binding Update request. If the Mobile Node 4283] of the Proxy Binding Update request. If the Mobile Node
Identifier option is not present in the Proxy Binding Update Identifier option is not present in the Proxy Binding Update
request, the local mobility anchor MUST reject the request and request, the local mobility anchor MUST reject the request and
send a Proxy Binding Acknowledgement message with Status field set send a Proxy Binding Acknowledgement message with Status field
to MISSING_MN_IDENTIFIER_OPTION (Missing mobile node identifier). set to MISSING_MN_IDENTIFIER_OPTION (Missing mobile node
identifier) and the identifier in the Mobile Node Identifier
Option MUST be set to a zero length identifier.
o If the local mobility anchor cannot identify the mobile node, from 3. If the local mobility anchor cannot authorize the mobile node
the Mobile Node Identifier option [RFC-4283] present in the based on the Mobile Node Identifier option [RFC-4283] present in
request, it MUST reject the Proxy Binding Update request and send the request, it MUST reject the Proxy Binding Update request and
a Proxy Binding Acknowledgement message with Status field set to send a Proxy Binding Acknowledgement message with Status field
133 (Not home agent for this mobile node). set to 133 (Not home agent for this mobile node).
o If the local mobility anchor determines that the mobile node is 4. If the local mobility anchor determines that the mobile node is
not authorized for the network-based mobility management service, not authorized for the network-based mobility management
it MUST reject the request and send a Proxy Binding service, it MUST reject the request and send a Proxy Binding
Acknowledgement message with Status field set to Acknowledgement message with Status field set to
PROXY_REG_NOT_ENABLED (Proxy Registration not enabled). PROXY_REG_NOT_ENABLED (Proxy Registration not enabled).
o The local mobility anchor MUST ignore the check, specified in 5. The local mobility anchor MUST ignore the check, specified in
Section 10.3.1 [RFC-3775], related to the presence of Home Address Section 10.3.1 [RFC-3775], related to the presence of Home
destination option in the Proxy Binding Update request. Address destination option in the Proxy Binding Update request.
o The local mobility anchor MUST authenticate the Proxy Binding 6. The local mobility anchor MUST authenticate the Proxy Binding
Update request as described in Section 4.0. When IPsec is used Update request as described in Section 4.0. When IPsec is used
for message authentication, the SPI in the IPsec header [RFC-4306] for message authentication, the SPI in the IPsec header [RFC-
of the received packet for locating the security association 4306] of the received packet is needed for locating the security
needed for authenticating the Proxy Binding Update request. association, for authenticating the Proxy Binding Update
request.
o The local mobility anchor MUST apply the required policy checks, 7. The local mobility anchor MUST apply the required policy checks,
as explained in Section 4.0, to verify the sender is a trusted as explained in Section 4.0, to verify the sender is a trusted
mobile access gateway, authorized to send Proxy Binding Update mobile access gateway, authorized to send Proxy Binding Update
requests on behalf of this mobile node. requests on behalf of this mobile node.
o If the local mobility anchor determines that the requesting node 8. If the local mobility anchor determines that the requesting node
is not authorized to send Proxy Binding Update requests, it MUST is not authorized to send Proxy Binding Update requests, it MUST
reject the request and send a Proxy Binding Acknowledgement reject the request and send a Proxy Binding Acknowledgement
message with Status field set to MAG_NOT_AUTHORIZED_FOR_PROXY_REG message with Status field set to
(Not authorized to send proxy registrations). MAG_NOT_AUTHORIZED_FOR_PROXY_REG (Not authorized to send proxy
registrations).
o If the Home Network Prefix option is not present in the Proxy 9. If the Home Network Prefix option is not present in the Proxy
Binding Update request, the local mobility anchor MUST reject the Binding Update request, the local mobility anchor MUST reject
request and send a Proxy Binding Acknowledgement message with the request and send a Proxy Binding Acknowledgement message
Status field set to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing with Status field set to MISSING_HOME_NETWORK_PREFIX_OPTION
mobile node's home network prefix option). (Missing mobile node's home network prefix option).
o If the Access Technology Type option is not present in the Proxy 10. If the Access Technology Type option is not present in the Proxy
Binding Update request, the local mobility anchor MUST reject the Binding Update request, the local mobility anchor MUST reject
request and send a Proxy Binding Acknowledgement message with the request and send a Proxy Binding Acknowledgement message
Status field set to MISSING_ACCESS_TECH_TYPE_OPTION (Missing with Status field set to MISSING_ACCESS_TECH_TYPE_OPTION
mobile node's access technology type). (Missing mobile node's access technology type).
o The local mobility anchor MUST apply the considerations specified 11. The local mobility anchor MUST apply the considerations
in Section 5.5, for processing the Sequence Number field and the specified in Section 5.5, for processing the Sequence Number
Timestamp option, in the Proxy Binding Update request. field and the Timestamp option, in the Proxy Binding Update
request.
o The local mobility anchor MUST use the identifier from the Mobile 12. The local mobility anchor MUST use the identifier from the
Node Identifier Option [RFC-4283] present in the Proxy Binding Mobile Node Identifier Option [RFC-4283] present in the Proxy
Update request and MUST apply multihoming considerations specified Binding Update request and MUST apply multihoming considerations
in Section 5.4 for performing the Binding Cache entry existence specified in Section 5.4 for performing the Binding Cache entry
test or for identifying the mobility session. If the entry does existence test or for identifying the mobility session. If the
not exist, the local mobility anchor MUST consider this request as entry does not exist, the local mobility anchor MUST consider
an initial binding registration request. If the entry exists, the this request as an initial binding registration request. If the
local mobility anchor MUST consider this request as an binding re- entry exists, the local mobility anchor MUST consider this
registration request. However, from the perspective of the mobile request as a binding re-registration request. However, from the
access gateway that sent the request, this binding re-registration perspective of the mobile access gateway that sent the request,
request may be an initial Binding Update request after the mobile this binding re-registration request may be an initial Binding
node's attachment to that mobile access gateway. Update request after the mobile node's attachment to that mobile
access gateway.
Initial Binding Registration: Initial Binding Registration:
o If the Home Network Prefix option present in the Proxy Binding 1. If the Home Network Prefix option present in the Proxy Binding
Update request has the value 0::/0, the local mobility anchor MUST Update request has the value 0::/0, the local mobility anchor
allocate a prefix for the mobile node and send a Proxy Binding SHOULD allocate a prefix for the mobile node and send a Proxy
Acknowledgement message including the Home Network Prefix option Binding Acknowledgement message including the Home Network Prefix
containing the allocated prefix value. The specific details on option containing the allocated prefix value. The local mobility
how the local mobility anchor allocates the home network prefix is anchor MUST ensure the allocated prefix is not in use by any
outside the scope of this document. The local mobility anchor other node.
MUST ensure the allocated prefix is not in use by any other mobile
node.
o If the local mobility anchor is unable to allocate a home network 2. If the local mobility anchor is unable to allocate a home network
prefix for the mobile node, it MUST reject the request and send a prefix for the mobile node, it MUST reject the request and send a
Proxy Binding Acknowledgement message with Status field set to 130 Proxy Binding Acknowledgement message with Status field set to
(Insufficient resources). 130 (Insufficient resources).
o If the Home Network Prefix option present in the request has a 3. If the Home Network Prefix option present in the request has a
specific prefix hint, the local mobility anchor before accepting specific prefix hint, the local mobility anchor before accepting
that request, MUST ensure the prefix is owned by the local that request, MUST ensure the prefix is owned by the local
mobility anchor and further the mobile node is authorized to use mobility anchor and further the mobile node is authorized to use
that prefix. If the mobile node is not authorized to use that that prefix. If the mobile node is not authorized to use that
prefix, the local mobility anchor MUST reject the request and send prefix, the local mobility anchor MUST reject the request and
a Proxy Binding Acknowledgement message with Status field set to send a Proxy Binding Acknowledgement message with Status field
NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (Mobile node not authorized set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (Mobile node not
to use that prefix). authorized to use that prefix).
o Upon accepting the request, the local mobility anchor MUST create 4. Upon accepting the request, the local mobility anchor MUST create
a Binding Cache entry for the mobile node. It must set the fields a Binding Cache entry for the mobile node. It must set the
in the Binding Cache entry to the accepted values for that fields in the Binding Cache entry to the accepted values for that
binding. If there is a Link-local Address option present in the binding. If there is a Link-local Address option present in the
request, the address must be copied to the link-local address request, the address must be copied to the link-local address
field in the Binding Cache entry. field in the Binding Cache entry.
o Upon accepting the Proxy Binding Update request, the local 5. Upon accepting the Proxy Binding Update request, the local
mobility anchor MUST establish a bi-directional tunnel to the mobility anchor MUST establish a bi-directional tunnel to the
mobile access gateway, as described in [RFC-2473]. Considerations mobile access gateway, as described in [RFC-2473].
from Section 5.6 must be applied. Considerations from Section 5.6 must be applied.
Binding Re-Registration: Binding Re-Registration:
o If the requesting prefix in the Home Network Prefix option is a 1. If the requesting prefix in the Home Network Prefix option is a
non 0::/0 value and is different from what is present in the non 0::/0 value and is different from what is present in the
currently active Binding Cache entry for that mobile node, the currently active Binding Cache entry for that mobile node, the
local mobility anchor MUST reject the request and send a Proxy local mobility anchor MUST reject the request and send a Proxy
Binding Acknowledgement message with Status field set to 129 Binding Acknowledgement message with Status field set to 129
(Administratively Prohibited). (Administratively Prohibited).
o If there is a Link-local Address option present in the request 2. If there is a Link-local Address option present in the request
with a value other than ALL_ZERO (not set), and upon accepting the with a value other than ALL_ZERO (not set), and upon accepting
binding re-registration request, the local mobility anchor MUST the binding re-registration request, the local mobility anchor
update the link-local address field in the Binding Cache entry to MUST update the link-local address field in the Binding Cache
the address value received in the request. entry to the address value received in the request.
o Upon accepting a Proxy Binding Update request for extending the 3. Upon accepting a Proxy Binding Update request for extending the
lifetime of a currently active binding for a mobile node, the lifetime of a currently active binding for a mobile node, the
local mobility anchor MUST update the existing Binding Cache entry local mobility anchor MUST update the existing Binding Cache
for this mobile node. Unless there exists an established bi- entry for this mobile node. Unless there exists an established
directional tunnel to the mobile access gateway with the same bi-directional tunnel to the mobile access gateway with the same
transport and encapsulation mode, the local mobility anchor MUST transport and encapsulation mode, the local mobility anchor MUST
create a tunnel to the mobile access gateway, as described in create a tunnel to the mobile access gateway, as described in
[RFC-2473] and also delete the existing tunnel route to the [RFC-2473] and also delete the existing tunnel route to the
previous mobile access gateway. It MUST also send a Proxy Binding previous mobile access gateway. It MUST also send a Proxy
Acknowledgement message to the mobile access gateway with the Binding Acknowledgement message to the mobile access gateway with
Status field set to 0 (Proxy Binding Update Accepted). the Status field set to 0 (Proxy Binding Update Accepted).
Binding De-Registration: Binding De-Registration:
o If the prefix in the Home Network Prefix option is a non 0::/0 1. If the received Proxy Binding Update request with the lifetime
value and is different from what is present in the currently value of zero and the prefix in the Home Network Prefix option is
active Binding Cache entry for that mobile node, the local a non 0::/0 value and is different from what is present in the
mobility anchor MUST reject the request and send a Proxy Binding currently active Binding Cache entry for that mobile node, the
Acknowledgement message with Status field set to 129 local mobility anchor MUST reject the request and send a Proxy
Binding Acknowledgement message with Status field set to 129
(Administratively Prohibited). (Administratively Prohibited).
o If the received Proxy Binding Update request with the lifetime 2. If the received Proxy Binding Update request with the lifetime
value of zero, has a Source Address in the IPv6 header different value of zero, has a Source Address in the IPv6 header different
from what is present in the Proxy-CoA address field in the Binding from what is present in the Proxy-CoA address field in the
Cache entry existing for that mobile node, the local mobility Binding Cache entry existing for that mobile node, the local
anchor MUST ignore the request. mobility anchor SHOULD ignore the request.
o Upon accepting the Proxy Binding Update request for a mobile node, 3. Upon accepting the Proxy Binding Update request for a mobile
with the lifetime value of zero, the local mobility anchor MUST node, with the lifetime value of zero, the local mobility anchor
wait for MinDelayBeforeBCEDelete amount of time, before it deletes MUST wait for MinDelayBeforeBCEDelete amount of time, before it
the mobile node's Binding Cache entry. Within this wait period, deletes the mobile node's Binding Cache entry. Within this wait
if the local mobility anchor receives a Proxy Binding Update period, if the local mobility anchor receives a Proxy Binding
request message for the same mobile node with the lifetime value Update request message for the same mobile node with the lifetime
of greater than zero, and if that request is accepted, then the value of greater than zero, and if that request is accepted, then
Binding Cache entry MUST NOT be deleted, but must be updated with the Binding Cache entry MUST NOT be deleted, but must be updated
the newly accepted registration values. The local mobility anchor with the newly accepted registration values. The local mobility
MUST send the Proxy Binding Acknowledgement message, immediately anchor MUST send the Proxy Binding Acknowledgement message,
upon accepting the request. However, within this wait period, if immediately upon accepting the request. However, within this
the local mobility anchor does not receive any valid binding wait period, if the local mobility anchor does not receive any
registration request for that mobile node, then at the end of this valid binding registration request for that mobile node, then at
wait period, it MUST delete the mobile node's Binding Cache entry the end of this wait period, it MUST delete the mobile node's
and remove the routing state created for that mobile node. In Binding Cache entry and remove the routing state created for that
addition, during this MinDelayBeforeBCEDelete wait period, the mobile node. In addition, during this MinDelayBeforeBCEDelete
local mobility anchor MUST continue to route the mobile node's wait period, the local mobility anchor MUST continue to route the
data traffic. mobile node's data traffic.
Constructing the Proxy Binding Acknowledgement Message: 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 is set*/ -BA /*P flag is set*/
Mobility Options Mobility Options
- Home Network Prefix Option - Home Network Prefix Option
- Link-local Address Option (optional) - Link-local Address Option (optional)
- Timestamp Option (optional) - Timestamp Option (optional)
- Mobile Node Identifier Option - Mobile Node Identifier Option (Mandatory)
- Access Technology Type option (Mandatory) - Access Technology Type option (Mandatory)
- Mobile Node Interface Identifier option - Mobile Node Interface Identifier option
(Optional) (Optional)
Figure 6: Proxy Binding Acknowledgement message format Figure 6: Proxy Binding Acknowledgement message format
o The Source Address field in the IPv6 header of the message SHOULD o The Source Address field in the IPv6 header of the message MUST be
be set to the destination address of the received Proxy Binding set to the destination address of the received Proxy Binding
Update request. Update request.
o The Destination Address field in the IPv6 header of the message o The Destination Address field in the IPv6 header of the message
SHOULD be set to the source address of the received Proxy Binding MUST be set to the source address of the received Proxy Binding
Update request. Update request.
o The Home Network Prefix option MUST be present in the Proxy o The Home Network Prefix option MUST be present in the Proxy
Binding Acknowledgement message. If the option was not present in Binding Acknowledgement message. If the option was not present in
the request and if the Status field value is set to the request and if the Status field value is set to
MISSING_HOME_NETWORK_PREFIX_OPTION, the value MUST be set to MISSING_HOME_NETWORK_PREFIX_OPTION, the value MUST be set to
ALL_ZERO. ALL_ZERO.
o The Access Technology Type option MUST be present. The access o The Access Technology Type option MUST be present. The access
technology type value in the option MUST be copied from the Access technology type value in the option MUST be copied from the Access
skipping to change at page 23, line 48 skipping to change at page 24, line 12
address MUST be copied from the Link-local Address option in the address MUST be copied from the Link-local Address option in the
received Proxy Binding Update request. For all other cases, it received Proxy Binding Update request. For all other cases, it
MUST be copied from the mobile node's Binding Cache entry. MUST be copied from the mobile node's Binding Cache entry.
o Considerations from Section 5.5 must be applied for constructing o Considerations from Section 5.5 must be applied for constructing
the Timestamp option. the Timestamp option.
o The identifier in the Mobile Node Identifier option [RFC-4283] o The identifier in the Mobile Node Identifier option [RFC-4283]
MUST be copied from the received Proxy Binding Update request. If MUST be copied from the received Proxy Binding Update request. If
the Status field value is set to MISSING_MN_IDENTIFIER_OPTION, the the Status field value is set to MISSING_MN_IDENTIFIER_OPTION, the
Mobile Node Identifier Option MUST NOT be present in the Proxy identifier in the Mobile Node Identifier Option MUST be set to a
Binding Acknowledgement message. zero length identifier.
o The message MUST be protected by using IPsec, using the security o If IPsec is used for protecting the signaling messages, the
association existing between the local mobility anchor and the message MUST be protected, using the security association existing
mobile access gateway. between the local mobility anchor and the mobile access gateway.
o The Type 2 Routing header MUST NOT be present in the IPv6 header o The Type 2 Routing header MUST NOT be present in the IPv6 header
of the packet. of the packet.
5.4. Multihoming Support 5.4. Multihoming Support
When a mobile node connects to a Proxy Mobile IPv6 domain through When a mobile node connects to a Proxy Mobile IPv6 domain through
multiple interfaces simultaneously, the local mobility anchor MUST multiple interfaces simultaneously, the local mobility anchor MUST
allocate a unique home network prefix for each of the connected allocate a unique home network prefix for each of the connected
interfaces. interfaces.
The local mobility anchor MUST manage each of the allocated home The local mobility anchor MUST manage each of the allocated home
network prefixes as part of a separate mobility session, each with a network prefixes as part of a separate mobility session, each under a
separate Binding Cache entry. separate Binding Cache entry and with its own lifetime.
The local mobility anchor MUST allow for an handover between two The local mobility anchor MUST allow for a handover between two
different interfaces of the mobile node. In such a case, the home different interfaces of the mobile node. In such a case, the home
network prefix that is associated with a specific interface network prefix that is associated with a specific interface
identifier of a mobile node will be updated with the new interface identifier of a mobile node will be updated with the new interface
identifier. identifier. The decision on when to create a new mobility session
and when to update an existing mobility session MUST be based on the
Handover hint present in the signaling messages and under the
considerations specified in this section.
The local mobility anchor MUST apply the following multihoming The local mobility anchor MUST apply the following multihoming
considerations when processing a received Proxy Binding Update considerations when processing a received Proxy Binding Update
request message. request message.
Processing De-Registration Message: Processing De-Registration Message:
o If the received Proxy Binding Update message has lifetime value of 1. If the received Proxy Binding Update message has lifetime value
zero, the local mobility anchor MUST verify if there is an of zero, the local mobility anchor MUST verify if there is an
existing Binding Cache entry for the mobile node, identified by existing Binding Cache entry for the mobile node, identified by
the MN-Identifier and with the Proxy-CoA address matching the the MN-Identifier and with the Proxy-CoA address matching the
source address in the IPv6 header of the received packet. If source address in the IPv6 header of the received packet. If
there exists a Binding Cache entry, the local mobility anchor MUST there exists a Binding Cache entry, the local mobility anchor
consider the message as a request for de-registering that specific MUST consider the message as a request for de-registering that
mobility session. If there does not exist a Binding Cache entry, specific mobility session. If there does not exist a Binding
the message MUST be ignored. Cache entry, the message MUST be ignored.
Home Network Prefix Option (Non-Zero Prefix) present in the request:
1. The local mobility anchor MUST verify if there is an existing
Binding Cache entry for the mobile node, identified by the MN-
Identifier and with the home network prefix value matching the
prefix value in the Home Network Prefix Option of the request.
If there is a Mobile Node Interface Identifier Option present in
the request, it MUST be ignored for this search. If there exists
a Binding Cache entry matching the specified criteria, the local
mobility anchor MUST consider the message as a request for
updating that specific mobility session. The local mobility
anchor upon accepting the request MUST update the existing
Binding Cache entry and assign the home network prefix present in
the Binding Cache entry. If there does not exist a Binding Cache
entry matching this specified criteria, the below considerations
MUST be applied.
Mobile Node Interface Identifier Option not present in the request: Mobile Node Interface Identifier Option not present in the request:
o The local mobility anchor MUST verify if there is an existing 1. The local mobility anchor MUST verify if there is an existing
Binding Cache entry for the mobile node, identified by the MN- Binding Cache entry for the mobile node, identified by the MN-
Identifier and with the interface identifier value set to ALL_ZERO Identifier and with the interface identifier value set to
. ALL_ZERO.
o If there does not exist a Binding Cache entry, the local mobility 2. If there does not exist a Binding Cache entry, the local mobility
anchor upon accepting the request MUST assign a new home network anchor upon accepting the request MUST assign a new home network
prefix and create a new Binding Cache entry. prefix and create a new Binding Cache entry.
o If there exists a Binding Cache entry and if the Handoff Indicator 3. If there exists a Binding Cache entry and if the Handoff
flag in the Access Technology Type option present in the received Indicator field in the Access Technology Type option present in
Proxy Binding Update message is set to value 1 (Attachment over a the received Proxy Binding Update message is set to value 1
new interface), the local mobility anchor upon accepting the (Attachment over a new interface), the local mobility anchor upon
request MUST assign a new home network prefix and create a new accepting the request MUST assign a new home network prefix and
Binding Cache entry. create a new Binding Cache entry.
o If there exists a Binding Cache entry and if the Handoff Indicator 4. If there exists a Binding Cache entry and if the Handoff
flag in the Access Technology Type option present in the received Indicator field in the Access Technology Type option present in
Proxy Binding Update message is set to either value 2 (Handoff the received Proxy Binding Update message is set to either value
between interfaces) or 3 (Handoff between mobile access gateways 2 (Handoff between interfaces) or 3 (Handoff between mobile
for the same mobile node's interface), the local mobility anchor access gateways for the same mobile node's interface), the local
upon accepting the request MUST update the existing Binding Cache mobility anchor upon accepting the request MUST update the
entry and assign the home network prefix present in the Binding existing Binding Cache entry and assign the home network prefix
Cache entry. present in the Binding Cache entry.
o If there exists a Binding Cache entry and if the Handoff Indicator 5. If there exists a Binding Cache entry and if the Handoff
flag in the Access Technology Type option present in the received Indicator field in the Access Technology Type option present in
Proxy Binding Update message is set to value 4 (Handoff state the received Proxy Binding Update message is set to value 4
unknown), the local mobility anchor SHOULD wait till the existing (Handoff state unknown), the local mobility anchor SHOULD wait
Binding Cache entry is de-registered by the previously serving till the existing Binding Cache entry is de-registered by the
mobile access gateway, before it assigns the same home network previously serving mobile access gateway, before it assigns the
prefix or updates the existing Binding Cache entry. However, if same home network prefix or updates the existing Binding Cache
there is no de-registration message that is received within a entry. However, if there is no de-registration message that is
given amount of time, the local mobility anchor upon accepting the received within MinDelayBeforeNewBCEAssign amount of time, the
request MUST assign a new home network prefix and create a new local mobility anchor upon accepting the request MUST assign a
Binding Cache entry. The local mobility anchor MAY also choose to new home network prefix and create a new Binding Cache entry.
assign a new home network prefix and without waiting for a de- The local mobility anchor MAY also choose to assign a new home
registration message. network prefix and without waiting for a de-registration message.
It can use the access technology type value present in the
request and as inputs for this decision.
o Either upon creating a new Binding Cache entry or from matching an 6. Either upon creating a new Binding Cache entry or from matching
existing Binding Cache entry, after applying the above an existing Binding Cache entry, after applying the above
considerations, the interface identifier field in the Binding considerations, the access technology field in the Binding Cache
Cache entry MUST be set to the value present in the received entry MUST be copied from the Access Technology type option
Mobile Node Interface Identifier Option and the access technology present in the received Proxy Binding Update message. The
type MUST be copied from the Access Technology type option present interface identifier field in the Binding Cache entry MUST be set
in the received Proxy Binding Update message. If the Mobile Node to ALL_ZERO.
Interface Identifier Option is not present, the interface
identifier field in the Binding Cache entry MUST be set to
ALL_ZERO.
Mobile Node Interface Identifier Option present in the request: Mobile Node Interface Identifier Option present in the request:
o The local mobility anchor MUST verify if there is an existing 1. The local mobility anchor MUST verify if there is an existing
Binding Cache entry for the mobile node, identified by the MN- Binding Cache entry for the mobile node, identified by the MN-
Identifier and with the interface identifier value matching the Identifier and with the interface identifier value matching the
identifier value present in the received Mobile Node Interface identifier value present in the received Mobile Node Interface
Identifier Option. Identifier Option.
o If there exists a Binding Cache entry, the local mobility anchor 2. If there exists a Binding Cache entry, the local mobility anchor
upon accepting the request MUST update the existing Binding Cache upon accepting the request MUST update the existing Binding Cache
entry and assign the home network prefix present in the Binding entry and assign the home network prefix present in the Binding
Cache entry. Cache entry.
o If there does not exist a Binding Cache entry and if the Handoff 3. If there does not exist a Binding Cache entry and if the Handoff
Indicator flag in the Access Technology Type option present in the Indicator field in the Access Technology Type option present in
received Proxy Binding Update message is set to value 1 the received Proxy Binding Update message is set to value 1
(Attachment over a new interface), the local mobility anchor upon (Attachment over a new interface), the local mobility anchor upon
accepting the request MUST assign a new home network prefix and accepting the request MUST assign a new home network prefix and
create a new Binding Cache entry. create a new Binding Cache entry.
o If there does not exist a Binding Cache entry and if the Handoff 4. If there does not exist a Binding Cache entry and if the Handoff
Indicator flag in the Access Technology Type option present in the Indicator field in the Access Technology Type option present in
received Proxy Binding Update message is set to value 2 (Handoff the received Proxy Binding Update message is set to value 2
between interfaces), the local mobility anchor MUST verify if (Handoff between interfaces), the local mobility anchor MUST
there exists one and only one Binding Cache entry for the mobile verify if there exists one and only one Binding Cache entry for
node, identified by the MN-Identifier and with any interface the mobile node, identified by the MN-Identifier and with any
identifier value. If there exists such an entry, the local interface identifier value. If there exists such an entry, the
mobility anchor upon accepting the request MUST update the local mobility anchor upon accepting the request MUST update the
existing Binding Cache entry and assign the home network prefix existing Binding Cache entry and assign the home network prefix
present in the Binding Cache entry. present in the Binding Cache entry.
o If there does not exist a Binding Cache entry and if the Handoff 5. If there does not exist a Binding Cache entry and if the Handoff
Indicator flag in the Access Technology Type option present in the Indicator field in the Access Technology Type option present in
received Proxy Binding Update message is set to value 2 (Handoff the received Proxy Binding Update message is set to value 2
between interfaces), the local mobility anchor MUST verify if (Handoff between interfaces), the local mobility anchor MUST
there exists a Binding Cache entry for the mobile node, identified verify if there exists a Binding Cache entry for the mobile node,
by the MN-Identifier and with the home network prefix value identified by the MN-Identifier and with the home network prefix
matching the prefix value in the received Home Network Prefix value matching the prefix value in the received Home Network
option. If there exists a Binding Cache entry, the local mobility Prefix option. If there exists a Binding Cache entry, the local
anchor upon accepting the request MUST assign the same prefix, mobility anchor upon accepting the request MUST assign the same
else it MUST assign a new home network prefix and create a new prefix, else it MUST assign a new home network prefix and create
Binding Cache entry. a new Binding Cache entry.
o If there does not exist a Binding Cache entry and if the Handoff 6. If there exists a Binding Cache entry and if the Handoff
Indicator flag in the Access Technology Type option present in the Indicator field in the Access Technology Type option present in
received Proxy Binding Update message is set to value 4 (Handoff the received Proxy Binding Update message is set to value 4
state unknown), the local mobility anchor SHOULD wait till the (Handoff state unknown), the local mobility anchor SHOULD wait
existing Binding Cache entry is de-registered by the previously till the existing Binding Cache entry is de-registered by the
serving mobile access gateway. However, if there is no de- previously serving mobile access gateway. However, if there is
registration message that is received within a given time, the no de-registration message that is received within a given time,
local mobility anchor upon accepting the request MUST assign a new the local mobility anchor upon accepting the request MUST assign
home network prefix and create a new Binding Cache entry. The a new home network prefix and create a new Binding Cache entry.
local mobility anchor MAY also choose to assign a new home network The local mobility anchor MAY also choose to assign a new home
prefix and without waiting for a de-registration message. network prefix and without waiting for a de-registration message.
o Either upon creating a new Binding Cache entry or from matching an 7. Either upon creating a new Binding Cache entry or from matching
existing Binding Cache entry, after applying the above an existing Binding Cache entry, after applying the above
considerations, the interface identifier field in the Binding considerations, the interface identifier field in the Binding
Cache entry MUST be set to the value present in the received Cache entry MUST be set to the value present in the received
Mobile Node Interface Identifier Option and the access technology Mobile Node Interface Identifier Option and the access technology
type MUST be copied from the Access Technology type option present type MUST be copied from the Access Technology type option
in the received Proxy Binding Update message. If the Mobile Node present in the received Proxy Binding Update message.
Interface Identifier Option is not present, the interface
identifier field in the Binding Cache entry MUST be set to
ALL_ZERO.
5.5. Timestamp Option for Message Ordering 5.5. Timestamp Option for Message Ordering
Mobile IPv6 [RFC-3775] uses the Sequence Number field in binding Mobile IPv6 [RFC-3775] uses the Sequence Number field in binding
registration messages as a way for the home agent to process the registration messages as a way for the home agent to process the
binding updates in the order they were sent by a mobile node. The binding updates in the order they were sent by a mobile node. The
home agent and the mobile node are required to manage this counter home agent and the mobile node are required to manage this counter
over the lifetime of a binding. However, in Proxy Mobile IPv6, as over the lifetime of a binding. However, in Proxy Mobile IPv6, as
the mobile node moves from one mobile access gateway to another and the mobile node moves from one mobile access gateway to another and
in the absence of mechanisms such as context transfer between the in the absence of mechanisms such as context transfer between the
skipping to change at page 28, line 25 skipping to change at page 29, line 7
sequence number MUST be maintained on a per mobile node basis and sequence number MUST be maintained on a per mobile node basis and
MUST be synchronized between the serving mobile access gateways. MUST be synchronized between the serving mobile access gateways.
This may be achieved by using context transfer schemes or by This may be achieved by using context transfer schemes or by
maintaining the sequence number in a policy store. However, the maintaining the sequence number in a policy store. However, the
specific details on how the mobile node's sequence number is specific details on how the mobile node's sequence number is
synchronized between different mobile access gateways is outside the synchronized between different mobile access gateways is outside the
scope of this document. scope of this document.
Using Timestamps based approach: Using Timestamps based approach:
o A local mobility anchor implementation MUST support Timestamp 1. A local mobility anchor implementation MUST support Timestamp
option. If the Timestamp option is present in the received Proxy option. If the Timestamp option is present in the received Proxy
Binding Update request message, then the local mobility anchor Binding Update request message, then the local mobility anchor
MUST include a valid Timestamp option in the Proxy Binding MUST include a valid Timestamp option in the Proxy Binding
Acknowledgement message that it sends to the mobile access Acknowledgement message that it sends to the mobile access
gateway. gateway.
o All the mobility entities in a Proxy Mobile IPv6 domain that are 2. All the mobility entities in a Proxy Mobile IPv6 domain that are
exchanging binding registration messages using the Timestamp exchanging binding registration messages using the Timestamp
option must have adequately synchronized time-of-day clocks. This option must have adequately synchronized time-of-day clocks.
is the essential requirement for this solution to work. If this This is the essential requirement for this solution to work. If
requirement is not met, the solution will not predictably work in this requirement is not met, the solution will not predictably
all cases. work in all cases.
o The mobility entities in a Proxy Mobile IPv6 domain SHOULD 3. The mobility entities in a Proxy Mobile IPv6 domain SHOULD
synchronize their clocks to a common time source. For synchronize their clocks to a common time source. For
synchronizing the clocks, the nodes may use Network Time Protocol synchronizing the clocks, the nodes may use Network Time Protocol
[RFC-4330]. Deployments may also adopt other approaches suitable [RFC-4330]. Deployments may also adopt other approaches suitable
for that specific deployment. Alternatively, if there is mobile for that specific deployment. Alternatively, if there is mobile
node generated timestamp that is increasing at every attachment to node generated timestamp that is increasing at every attachment
the access link and if that timestamp is available to the mobile to the access link and if that timestamp is available to the
access gateway (Ex: The timestamp option in the SEND messages that mobile access gateway (Ex: The timestamp option in the SEND
the mobile node sends), the mobile access gateway can use this messages that the mobile node sends), the mobile access gateway
timestamp or sequence number in the Proxy Binding Update messages can use this timestamp or sequence number in the Proxy Binding
and does not have to depend on any external clock source. Update messages and does not have to depend on any external clock
However, the specific details on how this is achieved is outside source. However, the specific details on how this is achieved is
the scope of this document. outside the scope of this document.
o When generating the timestamp value for building the Timestamp 4. When generating the timestamp value for building the Timestamp
option, the mobility entities MUST ensure that the generated option, the mobility entities MUST ensure that the generated
timestamp is the elapsed time past the same reference epoch, as timestamp is the elapsed time past the same reference epoch, as
specified in the format for the Timestamp option [Section 8.7]. specified in the format for the Timestamp option [Section 8.7].
o If the Timestamp option is present in the received Proxy Binding 5. If the Timestamp option is present in the received Proxy Binding
Update message, the local mobility anchor MUST ignore the sequence Update message, the local mobility anchor MUST ignore the
number field in the message. However, it MUST copy the sequence sequence number field in the message. However, it MUST copy the
number from the received Proxy Binding Update message to the Proxy sequence number from the received Proxy Binding Update message to
Binding Acknowledgement message. the Proxy Binding Acknowledgement message.
o Upon receipt of a Proxy Binding Update message with the Timestamp 6. Upon receipt of a Proxy Binding Update message with the Timestamp
option, the local mobility anchor MUST check the timestamp field option, the local mobility anchor MUST check the timestamp field
for validity. In order for it to be considered valid, the for validity. In order for it to be considered valid, the
timestamp value contained in the Timestamp option MUST be close timestamp value contained in the Timestamp option MUST be close
enough to the local mobility anchor's time-of-day clock and the enough to the local mobility anchor's time-of-day clock and the
timestamp MUST be greater than all previously accepted timestamps timestamp MUST be greater than all previously accepted timestamps
in the Proxy Binding Update messages sent for that mobile node. in the Proxy Binding Update messages sent for that mobile node.
o If the timestamp value in the received Proxy Binding Update is 7. If the timestamp value in the received Proxy Binding Update is
valid (validity as specified in the above considerations), the valid (validity as specified in the above considerations), the
local mobility anchor MUST return the same timestamp value in the local mobility anchor MUST return the same timestamp value in the
Timestamp option included in the Proxy Binding Acknowledgement Timestamp option included in the Proxy Binding Acknowledgement
message that it sends to the mobile access gateway. message that it sends to the mobile access gateway.
o If the timestamp value in the received Proxy Binding Update is 8. If the timestamp value in the received Proxy Binding Update is
lower than the previously accepted timestamp in the Proxy Binding lower than the previously accepted timestamp in the Proxy Binding
Update messages sent for that mobility binding, the local mobility Update messages sent for that mobility binding, the local
anchor MUST reject the Proxy Binding Update request and send a mobility anchor MUST reject the Proxy Binding Update request and
Proxy Binding Acknowledgement message with Status field set to send a Proxy Binding Acknowledgement message with Status field
TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp lower than set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp lower than
previously accepted timestamp). The message MUST also include the previously accepted timestamp). The message MUST also include
Timestamp option with the value set to the current time-of-day on the Timestamp option with the value set to the current time-of-
the local mobility anchor. day on the local mobility anchor.
o If the timestamp value in the received Proxy Binding Update is not 9. If the timestamp value in the received Proxy Binding Update is
valid (validity as specified in the above considerations), the not valid (validity as specified in the above considerations),
local mobility anchor MUST reject the Proxy Binding Update and the local mobility anchor MUST reject the Proxy Binding Update
send a Proxy Binding Acknowledgement message with Status field set and send a Proxy Binding Acknowledgement message with Status
to TIMESTAMP_MISMATCH (Timestamp mismatch). The message MUST also field set to TIMESTAMP_MISMATCH (Timestamp mismatch). The
include the Timestamp option with the value set to the current message MUST also include the Timestamp option with the value set
time-of-day on the local mobility anchor. to the current time-of-day on the local mobility anchor.
Using Sequence Number based approach: Using Sequence Number based approach:
o If the Timestamp option is not present in the received Proxy 1. If the Timestamp option is not present in the received Proxy
Binding Update request, the local mobility anchor MUST fallback to Binding Update request, the local mobility anchor MUST fallback
the Sequence Number based scheme. It MUST process the sequence to the Sequence Number based scheme. It MUST process the
number field as specified in [RFC-3775]. Also, it MUST NOT sequence number field as specified in [RFC-3775]. Also, it MUST
include the Timestamp option in the Proxy Binding Acknowledgement NOT include the Timestamp option in the Proxy Binding
messages that it sends to the mobile access gateway. Acknowledgement messages that it sends to the mobile access
gateway.
o An implementation MUST support Sequence Number based scheme, as 2. An implementation MUST support Sequence Number based scheme, as
per [RFC-3775]. per [RFC-3775].
5.6. Routing Considerations 5.6. Routing Considerations
5.6.1. Bi-Directional Tunnel Management 5.6.1. Bi-Directional Tunnel Management
o A bi-directional tunnel is established between the local mobility o A bi-directional tunnel MUST be established between the local
anchor and the mobile access gateway with IP-in-IP encapsulation, mobility anchor and the mobile access gateway with IP-in-IP
as described in [RFC-2473]. The tunnel end points are the Proxy- encapsulation, as described in [RFC-2473]. The tunnel end points
CoA and LMAA. When using IPv4 transport with a specific are the Proxy-CoA and LMAA. When using IPv4 transport with a
encapsulation mode, the end points of the tunnel are the IPv4-LMAA specific encapsulation mode, the end points of the tunnel are the
and IPv4-Proxy-CoA, as specified in [ID-IPV4-PMIP6]. IPv4-LMAA and IPv4-Proxy-CoA, as specified in [ID-IPV4-PMIP6].
o The bi-directional tunnel is used for routing the mobile node's o The bi-directional tunnel MUST be used for routing the mobile
data traffic between the mobile access gateway and the local node's data traffic between the mobile access gateway and the
mobility anchor. The tunnel hides the topology and enables a local mobility anchor. The tunnel hides the topology and enables
mobile node to use an address from its home network prefix from a mobile node to use an address from its home network prefix from
any access link attached to the mobile access gateway. any access link attached to the mobile access gateway.
o The bi-directional tunnel is established after accepting the Proxy o The bi-directional tunnel is established after accepting the Proxy
Binding Update request message. The created tunnel may be shared Binding Update request message. The created tunnel may be shared
with other mobile nodes attached to the same mobile access gateway with other mobile nodes attached to the same mobile access gateway
and with the local mobility anchor having a Binding Cache entry and with the local mobility anchor having a Binding Cache entry
for those mobile nodes. Implementations MAY choose to use static for those mobile nodes. Implementations MAY choose to use static
tunnels instead of dynamically creating and tearing them down on a tunnels instead of dynamically creating and tearing them down on a
need basis. need basis.
o Implementations typically use a software timer for managing the o Implementations MAY use a software timer for managing the tunnel
tunnel lifetime and a counter for keeping a count of all the lifetime and a counter for keeping a count of all the mobile nodes
mobile nodes that are sharing the tunnel. The timer value will be that are sharing the tunnel. The timer value MUST be set to the
set to the accepted binding lifetime and will be updated after accepted binding lifetime and will be updated after each periodic
each periodic re-registration for extending the lifetime. If the re-registration for extending the lifetime. If the tunnel is
tunnel is shared for multiple mobile nodes, the tunnel lifetime shared for multiple mobile nodes, the tunnel lifetime MUST be set
will be set to the highest binding lifetime that is granted to any to the highest binding lifetime that is granted to any one of
one of those mobile nodes sharing that tunnel. those mobile nodes sharing that tunnel.
5.6.2. Forwarding Considerations 5.6.2. Forwarding Considerations
Intercepting Packets Sent to the Mobile Node's Home Network: Intercepting Packets Sent to the Mobile Node's Home Network:
o When the local mobility anchor is serving a mobile node, it MUST o When the local mobility anchor is serving a mobile node, it MUST
be able to receive packets that are sent to the mobile node's home be able to receive packets that are sent to the mobile node's home
network. In order for it to receive those packets, it MUST network. In order for it to receive those packets, it MUST
advertise a connected route in to the Routing Infrastructure for advertise a connected route in to the Routing Infrastructure for
the mobile node's home network prefix or for an aggregated prefix the mobile node's home network prefix or for an aggregated prefix
skipping to change at page 32, line 48 skipping to change at page 33, line 24
5.9. Route Optimizations Considerations 5.9. Route Optimizations Considerations
The Route Optimization in Mobile IPv6, as defined in [RFC-3775], The Route Optimization in Mobile IPv6, as defined in [RFC-3775],
enables a mobile node to communicate with a correspondent node enables a mobile node to communicate with a correspondent node
directly using its care-of address and further the Return Routability directly using its care-of address and further the Return Routability
procedure enables the correspondent node to have reasonable trust procedure enables the correspondent node to have reasonable trust
that the mobile node is reachable at both its home address and that the mobile node is reachable at both its home address and
care-of address. care-of address.
In Proxy Mobile IPv6, the mobile node is not involved in any mobility In Proxy Mobile IPv6, the mobile node is not involved in any IP
related signaling. The mobile node uses only its home address for mobility related signaling. The mobile node uses only its home
all its communication and the Care-of address (Proxy-CoA) is not address for all its communication and the Care-of address (Proxy-CoA)
visible to the mobile node. Hence, the Return Routability procedure is not visible to the mobile node. Hence, the Return Routability
as defined in Mobile IPv6 cannot be used in Proxy Mobile IPv6. procedure as defined in Mobile IPv6 cannot be used in Proxy Mobile
IPv6.
6. Mobile Access Gateway Operation 6. Mobile Access Gateway Operation
The Proxy Mobile IPv6 protocol described in this document introduces The Proxy Mobile IPv6 protocol described in this document introduces
a new functional entity, the Mobile Access Gateway (MAG). The mobile a new functional entity, the Mobile Access Gateway (MAG). The mobile
access gateway is the entity that is responsible for detecting the access gateway is the entity that is responsible for detecting the
mobile node's movements on its access link and sending the binding mobile node's movements on its access link and sending the binding
registration requests to the local mobility anchor. In essence, the registration requests to the local mobility anchor. In essence, the
mobile access gateway performs mobility management on behalf of a mobile access gateway performs mobility management on behalf of a
mobile node. mobile node.
skipping to change at page 34, line 9 skipping to change at page 34, line 32
entry data structure needs be extended with the following additional entry data structure needs be extended with the following additional
fields. fields.
o The Identifier of the attached mobile node, MN-Identifier. This o The Identifier of the attached mobile node, MN-Identifier. This
identifier is acquired during the mobile node's attachment to the identifier is acquired during the mobile node's attachment to the
access link through mechanisms outside the scope of this document. access link through mechanisms outside the scope of this document.
o The interface identifier of the mobile node's connected interface. o The interface identifier of the mobile node's connected interface.
This address can be acquired from the received Router Solicitation This address can be acquired from the received Router Solicitation
messages from the mobile node or during the mobile node's messages from the mobile node or during the mobile node's
attachment to the access network. This is typically a L2 attachment to the access network. This is typically a Layer-2
identifier conveyed by the mobile node identifier conveyed by the mobile node; however, the specific
details on how that is conveyed is out of scope for this
specification.
o The IPv6 home network prefix of the attached mobile node. The o The IPv6 home network prefix of the attached mobile node. The
home network prefix of the mobile node is acquired from the mobile home network prefix of the mobile node is acquired from the mobile
node's local mobility anchor through the received Proxy Binding node's local mobility anchor through the received Proxy Binding
Acknowledgement messages. The IPv6 home network prefix also Acknowledgement messages. The IPv6 home network prefix also
includes the corresponding prefix length. includes the corresponding prefix length.
o The Link-local address of the mobile node on the interface o The Link-local address of the mobile node on the interface
attached to the access link. attached to the access link.
skipping to change at page 35, line 7 skipping to change at page 35, line 32
a handoff or the serving mobile access gateway MAY be able to a handoff or the serving mobile access gateway MAY be able to
dynamically generate this profile. The exact details on how this dynamically generate this profile. The exact details on how this
achieved is outside the scope of this document. However, this achieved is outside the scope of this document. However, this
specification requires that a mobile access gateway serving a mobile specification requires that a mobile access gateway serving a mobile
node MUST have access to its policy profile. node MUST have access to its policy profile.
The following are the mandatory fields of the policy profile: The following are the mandatory fields of the policy profile:
o The mobile node's identifier (MN-Identifier) o The mobile node's identifier (MN-Identifier)
o The IPv6 address of the local mobility anchor (LMAA)
The following are the optional fields of the policy profile: The following are the optional fields of the policy profile:
o The mobile node's IPv6 home network prefix (MN-HNP) o The mobile node's IPv6 home network prefix (MN-HNP)
o The IPv6 address of the local mobility anchor (LMAA)
o Supported address configuration procedures (Stateful, Stateless or o Supported address configuration procedures (Stateful, Stateless or
both) on the access links in the Proxy Mobile IPv6 domain both) on the access links in the Proxy Mobile IPv6 domain
6.3. Supported Access Link Types 6.3. Supported Access Link Types
This specification supports only point-to-point access link types and This specification supports only point-to-point access link types and
thus it assumes that the mobile node and the mobile access gateway thus it assumes that the mobile node and the mobile access gateway
are the only two nodes on the access link. The link is assumed to are the only two nodes on the access link. The link is assumed to
have multicast capability. This protocol may also be used on other have multicast capability. This protocol may also be used on other
link types, as long as the link is configured in such a way that it link types, as long as the link is configured in such a way that it
skipping to change at page 38, line 13 skipping to change at page 38, line 35
neighbors on that access link. neighbors on that access link.
For solving this problem, this specification allows the mobile access For solving this problem, this specification allows the mobile access
gateway to upload the mobile node's link-local address to the local gateway to upload the mobile node's link-local address to the local
mobility anchor using the Link-local Address option, exchanged in the mobility anchor using the Link-local Address option, exchanged in the
binding registration messages. The mobile access gateway can learn binding registration messages. The mobile access gateway can learn
the mobile node's link-local address, by snooping the DAD messages the mobile node's link-local address, by snooping the DAD messages
sent by the mobile node for establishing the link-local address sent by the mobile node for establishing the link-local address
uniqueness on the access link. Subsequently, at each handoff, the uniqueness on the access link. Subsequently, at each handoff, the
mobile access gateway can obtain this address from the local mobility mobile access gateway can obtain this address from the local mobility
anchor to ensure link-local address uniqueness and may change its own anchor to ensure link-local address uniqueness and change its own
link-local address, if it detects a collision. link-local address, if it detects a collision.
Alternatively, one of the workarounds for this issue is to set the Alternatively, one of the workarounds for this issue is to set the
DNAv6 configuration parameter, DNASameLinkDADFlag to TRUE and that DNAv6 configuration parameter, DNASameLinkDADFlag to TRUE and that
will force the mobile node to redo DAD operation on the global and will force the mobile node to redo DAD operation on the global and
link-local addresses every time the interface detects a handover, link-local addresses every time the interface detects a handover,
even when DNAv6 does not detect a link change. even when DNAv6 does not detect a link change.
However, this issue will not impact point-to-point links based on a However, this issue will not impact point-to-point links based on a
PPP session. Each time the mobile node moves and attaches to a new PPP session. Each time the mobile node moves and attaches to a new
skipping to change at page 38, line 50 skipping to change at page 39, line 24
local address whenever it moves to a new link. local address whenever it moves to a new link.
If the PPP session state is moved to the new mobile access gateway as If the PPP session state is moved to the new mobile access gateway as
part of context transfer procedures that are in place, there will not part of context transfer procedures that are in place, there will not
be any change to the interface identifiers of the two nodes on that be any change to the interface identifiers of the two nodes on that
point-to-point change. The whole link is moved to the new mobile point-to-point change. The whole link is moved to the new mobile
access gateway and there will not be any need for establishing link- access gateway and there will not be any need for establishing link-
local address uniqueness on that link. local address uniqueness on that 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. Since there is an unique home network prefix global address. Since there is a unique home network prefix assigned
assigned for each mobile node, the uniqueness for the mobile node's for each mobile node, the uniqueness for the mobile node's global
global address is assured on the access link. address is assured on the access link.
6.9. Signaling Considerations 6.9. Signaling Considerations
6.9.1. Binding Registrations 6.9.1. Binding Registrations
Mobile Node Attachment and Initial Binding Registration: Mobile Node Attachment and Initial Binding Registration:
o After detecting a new mobile node on its access link, the mobile 1. After detecting a new mobile node on its access link, the mobile
access gateway must identify the mobile node and acquire its MN- access gateway must identify the mobile node and acquire its MN-
Identifier. If it determines that the network-based mobility Identifier. If it determines that the network-based mobility
management service needs to be offered to the mobile node, it MUST management service needs to be offered to the mobile node, it
send a Proxy Binding Update message to the local mobility anchor. MUST send a Proxy Binding Update message to the local mobility
anchor. If there is no existing Binding Update List entry for
that mobile node, the mobile access gateway MUST create a
Binding Update List entry upon sending the Proxy Binding Update
request.
o The Proxy Binding Update message MUST have the Mobile Node 2. The Proxy Binding Update message MUST include the Mobile Node
Identifier option [RFC-4283], identifying the mobile node, the Identifier option [RFC-4283], identifying the mobile node, the
Home Network Prefix option, either the Timestamp option or a valid Home Network Prefix option, either the Timestamp option or a
sequence number and optionally the Link-local Address option. valid sequence number and optionally the Link-local Address
When Timestamp option is added to the message, the mobile access option. When Timestamp option is added to the message, the
gateway MAY set the Sequence Number field to a value of a mobile access gateway MAY set the Sequence Number field to a
monotonically increasing counter and the local mobility anchor value of a monotonically increasing counter and the local
will ignore this field, but will return the same value in the mobility anchor will ignore this field, but will return the same
Proxy Binding Acknowledgement message. This will be useful for value in the Proxy Binding Acknowledgement message. This will
matching the reply to the request message. be useful for matching the reply to the request message.
o The Home Address option MUST NOT be present in the Destination 3. The Home Address option MUST NOT be present in the Destination
Option extension header of the Proxy Binding Update message. Option extension header of the Proxy Binding Update message.
o The Access Technology Type option MUST be present in the Proxy 4. The Access Technology Type option MUST be present in the Proxy
Binding Update message. The access technology Type field in the Binding Update message. The access technology Type field in the
option MUST be set to the access technology using which the mobile option MUST be set to the access technology using which the
node is currently attached to the mobile access gateway. mobile node is currently attached to the mobile access gateway.
The Handoff Indicator field in the Access Technology Type option
MUST be set to the appropriate value. The specific details on
how the mobile access gateway is able to determine if the mobile
node's current attachment is due to a handoff of an existing
mobility session or if it is as a result of an attachment over a
different interface is outside the scope of this document.
o The Handoff Indicator flag in the Access Technology Type option 5. The Handoff Indicator field in the Access Technology Type option
MUST be set to value 1 (Attachment over a new interface), if the MUST be set to value 1 (Attachment over a new interface), if the
mobile access gateway predictably knows that the mobile node's mobile access gateway predictably knows that the mobile node's
attachment to the network using the current interface is due to attachment to the network using the current interface is due to
neither a handover between two interfaces of the mobile node nor a neither a handover between two interfaces of the mobile node nor
handover of the mobility session for the same interface of the a handover of the mobility session for the same interface of the
mobile node between two mobile access gateways. This essentially mobile node between two mobile access gateways. This
serves as a request to the local mobility anchor to allocate a new essentially serves as a request to the local mobility anchor to
home network prefix for this mobility session and not update any allocate a new home network prefix for this mobility session and
existing Binding Cache entry created for the same mobile node not update any existing Binding Cache entry created for the same
connected to the Proxy Mobile IPv6 domain through a different mobile node connected to the Proxy Mobile IPv6 domain through a
interface. different interface.
o The Handoff Indicator flag in the Access Technology Type option 6. The Handoff Indicator field in the Access Technology Type option
MUST be set to value 2 (Handoff between interfaces), if the mobile MUST be set to value 2 (Handoff between interfaces), if the
access gateway definitively knows the mobile node's current mobile access gateway definitively knows the mobile node's
attachment is due to a handoff of the mobility session between two current attachment is due to a handoff of the mobility session
interfaces of the mobile node. between two interfaces of the mobile node.
o The Handoff Indicator flag in the Access Technology Type option 7. The Handoff Indicator field in the Access Technology Type option
MUST be set to value 3 (Handoff between mobile access gateways for MUST be set to value 3 (Handoff between mobile access gateways
the same interface), if the mobile access gateway definitively for the same interface), if the mobile access gateway
knows the mobile node's current attachment is due to a handoff of definitively knows the mobile node's current attachment is due
the mobility session between two interfaces of the mobile node. to a handoff of the mobility session between different mobile
access gateways and for the same interface of the mobile node.
o The Handoff Indicator flag in the Access Technology Type option 8. The Handoff Indicator field in the Access Technology Type option
MUST be set to value 4 (Handoff State Unknown), if the mobile MUST be set to value 4 (Handoff State Unknown), if the mobile
access gateway cannot predictably know if the mobile node's access gateway cannot predictably know if the mobile node's
session is due to a handoff. session is due to a handoff.
o The Mobile Node Interface Identifier option carrying the 9. The Mobile Node Interface Identifier option carrying the
identifier of the currently attached interface MUST be present in identifier of the currently attached interface MUST be present
the Proxy Binding Update message, if the mobile access gateway in the Proxy Binding Update message, if the mobile access
knows the interface identifier of the mobile node's currently gateway knows the interface identifier of the mobile node's
attached interface. The "P" Flag in the option MUST be set to 0, currently attached interface. The "P" Flag in the option MUST
indicating that the carried identifier is the currently attached be set to 0, indicating that the carried identifier is the
interface identifier. If the interface identifier is now known, currently attached interface identifier. If the interface
this identifier MUST NOT be present. identifier is not known, this identifier MUST NOT be present.
o If the mobile access gateway learns the mobile node's home network 10. If the mobile access gateway learns the mobile node's home
prefix either from its policy store or from other means, the network prefix either from its policy store or from other means,
mobile access gateway MAY choose to specify the same in the Home the mobile access gateway MAY choose to specify the same in the
Network Prefix option for requesting the local mobility anchor to Home Network Prefix option for requesting the local mobility
allocate that prefix. If the specified value is 0::/0, then the anchor to allocate that prefix. If the specified value is
local mobility anchor will consider this as a request for prefix 0::/0, then the local mobility anchor will consider this as a
allocation. request for prefix allocation.
Receiving Binding Registration Reply: Receiving Binding Registration Reply:
o The mobile access gateway MUST observe the rules described in 1. The mobile access gateway MUST observe the rules described in
Section 9.2 [RFC-3775] when processing Mobility Headers in the Section 9.2 [RFC-3775] when processing Mobility Headers in the
received Proxy Binding Acknowledgement message (a Binding received Proxy Binding Acknowledgement message (a Binding
Acknowledgement message with the 'P' flag set). Acknowledgement message with the 'P' flag set).
o The message MUST be authenticated as described in Section 4.0. 2. The message MUST be authenticated as described in Section 4.0.
When IPsec is used for message authentication, the SPI in the When IPsec is used for message authentication, the SPI in the
IPsec header [RFC-4306] of the received packet MUST be used for IPsec header [RFC-4306] of the received packet is needed for
locating the security association needed for authenticating the locating the security association, for authenticating the Proxy
message. Binding Acknowledgement reply.
o The mobile access gateway MUST apply the considerations specified 3. The mobile access gateway MUST apply the considerations
in Section 5.5 for processing the Sequence Number field and the specified in Section 5.5 for processing the Sequence Number
Timestamp option, in the message. field and the Timestamp option, in the message.
o The mobile access gateway MUST ignore any checks, specified in 4. The mobile access gateway MUST ignore any checks, specified in
[RFC-3775] related to the presence of Type 2 Routing header in the [RFC-3775] related to the presence of Type 2 Routing header in
Proxy Binding Acknowledgement message. the Proxy Binding Acknowledgement message.
o If the Timestamp option is present in the received Proxy Binding 5. If the Timestamp option is present in the received Proxy Binding
Acknowledgement message and with the Status field value set to any Acknowledgement message and with the Status field value set to
value other than TIMESTAMP_MISMATCH (Invalid Timestamp), the any value other than TIMESTAMP_MISMATCH (Invalid Timestamp), the
mobile access gateway MAY use the timestamp value for matching the mobile access gateway MAY use the timestamp value for matching
response to the request message that it sent recently. For all the response to the request message that it sent recently. For
other cases, it MAY use the sequence number in combination with all other cases, it MAY use the sequence number in combination
the identifier present in the Mobile Node Identifier option for with the identifier present in the Mobile Node Identifier option
matching the response to the request. for matching the response to the request.
o If the received Proxy Binding Acknowledgement message has the 6. If the received Proxy Binding Acknowledgement message has the
Status field value set to PROXY_REG_NOT_ENABLED (Proxy Status field value set to PROXY_REG_NOT_ENABLED (Proxy
registration not enabled for the mobile node), the mobile access registration not enabled for the mobile node), the mobile access
gateway SHOULD NOT send binding registration requests again for gateway SHOULD NOT send binding registration requests again for
that mobile node. It must also deny the mobility service to that that mobile node. It must also deny the mobility service to
mobile node. that mobile node.
o If the received Proxy Binding Acknowledgement message has the 7. If the received Proxy Binding Acknowledgement message has the
Status field value set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED Status field value set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED
(Timestamp lower than previously accepted timestamp), the mobile (Timestamp lower than previously accepted timestamp), the mobile
access gateway SHOULD try to register again to reassert the mobile access gateway SHOULD try to register again to reassert the
node's presence to the mobility anchor. The mobile access gateway mobile node's presence to the mobility anchor. The mobile
is not specifically required to synchronize its clock upon access gateway is not specifically required to synchronize its
receiving this error code. clock upon receiving this error code.
o If the received Proxy Binding Acknowledgement message has the 8. If the received Proxy Binding Acknowledgement message has the
Status field value set to TIMESTAMP_MISMATCH (Invalid Timestamp), Status field value set to TIMESTAMP_MISMATCH (Invalid
the mobile access gateway SHOULD try to register again only after Timestamp), the mobile access gateway SHOULD try to register
it has synchronized its clock to a common time source that is used again only after it has synchronized its clock to a common time
by all the mobility entities in that domain for their clock source that is used by all the mobility entities in that domain
synchronization. The mobile access gateway SHOULD NOT synchronize for their clock synchronization. The mobile access gateway
its clock to the local mobility anchor's system clock, based on SHOULD NOT synchronize its clock to the local mobility anchor's
the timestamp present in the received message. system clock, based on the timestamp present in the received
message.
o If the received Proxy Binding Acknowledgement message has the 9. If the received Proxy Binding Acknowledgement message has the
Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX
(Not authorized for that prefix), the mobile access gateway SHOULD (Not authorized for that prefix), the mobile access gateway
try to request for that prefix in the binding registration SHOULD try to request for that prefix in the binding
request, only after it learned the validity of that prefix. registration request, only after it learned the validity of that
prefix.
o If the received Proxy Binding Acknowledgement message has the 10. If the received Proxy Binding Acknowledgement message has the
Status field value set to any value greater than or equal to 128 Status field value set to any value greater than or equal to 128
(i.e., if the binding is rejected), the mobile access gateway MUST (i.e., if the binding is rejected), the mobile access gateway
NOT advertise the mobile node's home network prefix in the Router MUST NOT advertise the mobile node's home network prefix in the
Advertisements sent on that access link and there by denying Router Advertisements sent on that access link and there by
mobility service to the mobile node. denying mobility service to the mobile node.
o If the received Proxy Binding Acknowledgement message has the 11. If the received Proxy Binding Acknowledgement message has the
Status field value set to 0 (Proxy Binding Update accepted) and if Status field value set to 0 (Proxy Binding Update accepted), the
there is no existing Binding Update List entry for that mobile mobile access gateway MUST setup the routing state, as explained
node, the mobile access gateway MUST create a Binding Update List in section 6.10, and MUST also update the Binding Update List
entry and must setup the routing state, as explained in section entry for reflecting the accepted binding registration status.
6.10. But, if there is an existing Binding Update List entry for
that mobile node, the entry MUST be updated reflecting the
accepted binding registration.
o If the received Proxy Binding Acknowledgement message has the 12. If the received Proxy Binding Acknowledgement message has the
address in the Link-local Address option set to a value that address in the Link-local Address option set to a value that
matches its own link-local address on that access interface where matches its own link-local address on that access interface
the mobile node is anchored, the mobile access gateway MUST change where the mobile node is anchored, the mobile access gateway
its link-local address on that interface. MUST change its link-local address on that interface.
Extending Binding Lifetime: Extending Binding Lifetime:
o For extending the lifetime of a currently registered mobile node 1. For extending the lifetime of a currently registered mobile node
(i.e., if there exists a Binding Update List entry for that mobile (i.e., if there exists a Binding Update List entry for that
node), the mobile access gateway MUST send a Proxy Binding Update mobile node), the mobile access gateway MUST send a Proxy Binding
message to the local mobility anchor. The prefix value in the Update message to the local mobility anchor. The prefix value in
Home Network Prefix option present in the request SHOULD be set to the Home Network Prefix option present in the request SHOULD be
the currently registered home network prefix and the value in the set to the currently registered home network prefix and the value
Link-local Address option MAY be set to ALL_ZERO or to the link- in the Link-local Address option MAY be set to ALL_ZERO or to the
local address of the mobile node. link-local address of the mobile node.
Mobile Node Detachment and Binding De-Registration: Mobile Node Detachment and Binding De-Registration:
o At any point, if the mobile access gateway detects that the mobile 1. At any point, if the mobile access gateway detects that the
node has moved away from its access link, it SHOULD send a Proxy mobile node has moved away from its access link, it SHOULD send a
Binding Update message to the local mobility anchor with the Proxy Binding Update message to the local mobility anchor with
lifetime value set to zero. the lifetime value set to zero.
o Either upon receipt of a Proxy Binding Acknowledgement message 2. Either upon receipt of a Proxy Binding Acknowledgement message
from the local mobility anchor or after a certain timeout waiting from the local mobility anchor or after a MinPBUReplyTime timeout
for the reply, the mobile access gateway MUST remove the Binding waiting for the reply, the mobile access gateway MUST remove the
Cache entry for that mobile node from its Binding Update List and Binding Cache entry for that mobile node from its Binding Update
withdraw the mobile node's home network prefix as the hosted on- List and withdraw the mobile node's home network prefix as the
link prefix on that access link. hosted on-link prefix on that access link.
Constructing the Proxy Binding Update Message: Constructing the Proxy Binding Update Message:
o The mobile access gateway when sending the Proxy Binding Update o The mobile access gateway when sending the Proxy Binding Update
request to the local mobility anchor MUST construct the message as request to the local mobility anchor MUST construct the message as
specified below. specified below.
IPv6 header (src=Proxy-CoA, dst=LMAA) IPv6 header (src=Proxy-CoA, dst=LMAA)
Mobility header Mobility header
-BU /*P & A flags are set*/ -BU /*P & A flags are set*/
skipping to change at page 43, line 23 skipping to change at page 44, line 19
- Home Network Prefix option - Home Network Prefix option
- Link-local Address option (Optional) - Link-local Address option (Optional)
- Timestamp Option (optional) - Timestamp Option (optional)
- Mobile Node Identifier option - Mobile Node Identifier option
- Access Technology Type option (Mandatory) - Access Technology Type option (Mandatory)
- Mobile Node Interface Identifier option - Mobile Node Interface Identifier option
(Optional) (Optional)
Figure 8: Proxy Binding Update message format Figure 8: Proxy Binding Update message format
o The Source Address field in the IPv6 header of the message SHOULD o The Source Address field in the IPv6 header of the message MUST be
be set to the address of the mobile access gateway. set to the address of the mobile access gateway.
o The Destination Address field in the IPv6 header of the message o The Destination Address field in the IPv6 header of the message
SHOULD be set to the local mobility anchor address. MUST be set to the local mobility anchor address.
o The Home Network Prefix option MUST be present. The prefix value o The Home Network Prefix option MUST be present. The prefix value
MAY be set 0::/0 or to a specific prefix value. MAY be set 0::/0 or to a specific prefix value.
o The Link-local Address option MAY be present. The value MAY be o The Link-local Address option MAY be present. The value MAY be
set to ALL_ZERO or the mobile node's link-local address. set to ALL_ZERO or the mobile node's link-local address.
o The Access Technology Type option MUST be present. The value MUST o The Access Technology Type option MUST be present. The value MUST
be set to the type of the access technology using which the mobile be set to the type of the access technology using which the mobile
node is currently attached to the mobile access gateway. node is currently attached to the mobile access gateway.
o The Mobile Node Interface Identifier option MAY be present. o The Mobile Node Interface Identifier option MAY be present.
o Considerations from Section 5.5 must be applied for constructing o Considerations from Section 5.5 must be applied for constructing
the Timestamp option. the Timestamp option.
o The Mobile Node Identifier option [RFC-4283] MUST be present, the o The Mobile Node Identifier option [RFC-4283] MUST be present, the
identifier field in the option MUST be set to mobile node's identifier field in the option MUST be set to mobile node's
identifier, MN-Identifier. identifier, MN-Identifier.
o The message MUST be protected by using IPsec, using the security o If IPsec is used for protecting the signaling messages, the
association existing between the local mobility anchor and the message MUST be protected, using the security association existing
mobile access gateway. between the local mobility anchor and the mobile access gateway.
6.9.2. Router Solicitation Messages 6.9.2. Router Solicitation Messages
The mobile node may send a Router Solicitation message on the access The mobile node may send a Router Solicitation message on the access
link whenever the link-layer detects a media change. The Source link whenever the link-layer detects a media change. The Source
Address in the IPv6 header of the Router Solicitation message may Address in the IPv6 header of the Router Solicitation message may
either be the link-local address of the mobile node or an unspecified either be the link-local address of the mobile node or an unspecified
address (::). address (::).
o The mobile access gateway on receiving the Router Solicitation 1. The mobile access gateway on receiving the Router Solicitation
message SHOULD send a Router Advertisement containing the mobile message SHOULD send a Router Advertisement containing the mobile
node's home network prefix as the on-link prefix. However, before node's home network prefix as the on-link prefix. However,
sending the Router Advertisement message containing the mobile before sending the Router Advertisement message containing the
node's home network prefix, it SHOULD complete the binding mobile node's home network prefix, it SHOULD complete the binding
registration process with the mobile node's local mobility anchor. registration process with the mobile node's local mobility
anchor.
o If the local mobility anchor rejects the binding registration 2. If the local mobility anchor rejects the binding registration
request, or, if the mobile access gateway failed to complete the request, or, if the mobile access gateway failed to complete the
binding registration process for whatever reasons, the mobile binding registration process for whatever reasons, the mobile
access gateway MUST NOT advertise the mobile node's home network access gateway MUST NOT advertise the mobile node's home network
prefix in the Router Advertisement messages that it sends on the prefix in the Router Advertisement messages that it sends on the
access link. However, it MAY choose to advertise a local visited access link. However, it MAY choose to advertise a local visited
network prefix to enable the mobile node for regular IPv6 access. network prefix to enable the mobile node for regular IPv6 access.
6.9.3. Retransmissions and Rate Limiting 6.9.3. Retransmissions and Rate Limiting
The mobile access gateway is responsible for retransmissions and rate The mobile access gateway is responsible for retransmissions and rate
limiting the binding registration requests that it sends for updating limiting the binding registration requests that it sends for updating
a mobile node's binding. Implementations MUST follow the below a mobile node's binding. Implementations MUST follow the below
guidelines. guidelines.
o When the mobile access gateway sends a Proxy Binding Update 1. When the mobile access gateway sends a Proxy Binding Update
request, it should use the constant, INITIAL_BINDINGACK_TIMEOUT request, it should use the constant, INITIAL_BINDINGACK_TIMEOUT
[RFC-3775], for configuring the retransmission timer. [RFC-3775], for configuring the retransmission timer.
o If the mobile access gateway fails to receive a valid matching 2. If the mobile access gateway fails to receive a valid matching
response within the retransmission interval, it SHOULD retransmit response within the retransmission interval, it SHOULD retransmit
the message until a response is received. However, the mobile the message until a response is received. However, the mobile
access gateway MUST ensure the mobile node is still attached to access gateway MUST ensure the mobile node is still attached to
the connected link before retransmitting the message. the connected link before retransmitting the message.
o As specified in Section 11.8 [RFC-3775], the mobile access gateway 3. As specified in Section 11.8 [RFC-3775], the mobile access
MUST use an exponential back-off process in which the timeout gateway MUST use an exponential back-off process in which the
period is doubled upon each retransmission, until either the node timeout period is doubled upon each retransmission, until either
receives a response or the timeout period reaches the value the node receives a response or the timeout period reaches the
MAX_BINDACK_TIMEOUT [RFC-3775]. The mobile access gateway MAY value MAX_BINDACK_TIMEOUT [RFC-3775]. The mobile access gateway
continue to send these messages at this slower rate indefinitely. MAY continue to send these messages at this slower rate
indefinitely.
o If Timestamp based scheme is in use, the retransmitted Proxy 4. If Timestamp based scheme is in use, the retransmitted Proxy
Binding Update messages MUST use the latest timestamp. If Binding Update messages MUST use the latest timestamp. If
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 that Update messages MUST use a Sequence Number value greater than
used for the previous transmission of this Proxy Binding Update that used for the previous transmission of this Proxy Binding
message, just as specified in [RFC-3775]. Update message, just as specified in [RFC-3775].
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
interface. interface.
Proxy-CoA LMAA Proxy-CoA LMAA
| | | |
+--+ +---+ +---+ +--+ +--+ +---+ +---+ +--+
skipping to change at page 45, line 43 skipping to change at page 46, line 45
extensions for negotiating IPv4 transport and the corresponding extensions for negotiating IPv4 transport and the corresponding
encapsulation mode for supporting this protocol operation. encapsulation mode for supporting this protocol operation.
6.10.2. Tunneling & Encapsulation Modes 6.10.2. Tunneling & Encapsulation Modes
The IPv6 address that a mobile node uses from its home network prefix The IPv6 address that a mobile node uses from its home network prefix
is topologically anchored at the local mobility anchor. For a mobile is topologically anchored at the local mobility anchor. For a mobile
node to use this address from an access network attached to a mobile node to use this address from an access network attached to a mobile
access gateway, proper tunneling techniques have to be in place. access gateway, proper tunneling techniques have to be in place.
Tunneling hides the network topology and allows the mobile node's Tunneling hides the network topology and allows the mobile node's
IPv6 datagrams to be encapsulated as a payload of another IPv6 packet IPv6 datagram to be encapsulated as a payload of another IPv6 packet
and to be routed between the local mobility anchor and the mobile and to be routed between the local mobility anchor and the mobile
access gateway. The Mobile IPv6 base specification [RFC-3775] access gateway. The Mobile IPv6 base specification [RFC-3775]
defines the use of IPv6-over-IPv6 tunneling, between the home agent defines the use of IPv6-over-IPv6 tunneling, between the home agent
and the mobile node and this specification extends the use of the and the mobile node and this specification extends the use of the
same tunneling mechanism between the local mobility anchor and the same tunneling mechanism between the local mobility anchor and the
mobile access gateway. mobile access gateway.
On most operating systems, tunnels are implemented as a virtual On most operating systems, tunnels are implemented as a virtual
point-to-point interface. The source and the destination address of point-to-point interface. The source and the destination address of
the two end points of this virtual interface along with the the two end points of this virtual interface along with the
skipping to change at page 49, line 32 skipping to change at page 50, line 32
Figure 12: Tunneled Packets from MAG to LMA Figure 12: Tunneled Packets from MAG to LMA
6.11. Supporting DHCPv6 based Address Configuration on the Access Link 6.11. Supporting DHCPv6 based Address Configuration on the Access Link
This section explains how Stateful Address Configuration using DHCPv6 This section explains how Stateful Address Configuration using DHCPv6
can be enabled on the access link attached to a mobile access gateway can be enabled on the access link attached to a mobile access gateway
and how a mobile node attached to that link can obtain an address and how a mobile node attached to that link can obtain an address
from its home network prefix using DHCPv6. from its home network prefix using DHCPv6.
o The DHCPv6 relay agent [RFC-3315] service needs to be enabled on o For supporting Stateful Address Configuration using DHCPv6, the
each of the access links in the Proxy Mobile IPv6 domain. DHCPv6 relay agent [RFC-3315] service MUST be enabled on each of
Further, as specified in Section 20 [RFC-3315], the relay agent the access links in the Proxy Mobile IPv6 domain. Further, as
should be configured to use a list of destination addresses, which specified in Section 20 [RFC-3315], the relay agent should be
MAY include unicast addresses, the All_DHCP_Servers multicast configured to use a list of destination addresses, which MAY
address, or other addresses selected by the network administrator. include unicast addresses, the All_DHCP_Servers multicast address,
or other addresses selected by the network administrator.
o The DHCPv6 server in the Proxy Mobile IPv6 domain can be o The DHCPv6 server in the Proxy Mobile IPv6 domain can be
configured with a list of prefix pools (P1, P2, ..., Pn). Each configured with a list of prefix pools (P1, P2, ..., Pn). Each
one of these prefix pools corresponds to a home network prefix one of these prefix pools corresponds to a home network prefix
that a local mobility anchor allocates to a mobile node in that that a local mobility anchor allocates to a mobile node in that
domain. However, the DHCPv6 server will not know the relation domain. However, the DHCPv6 server will not know the relation
between a given address pool and a mobile node to which the between a given address pool and a mobile node to which the
corresponding prefix is allocated. It just views these pools as corresponding prefix is allocated. It just views these pools as
prefixes hosted on different links in that domain. prefixes hosted on different links in that domain.
skipping to change at page 56, line 14 skipping to change at page 57, line 14
As per this specification, the following mobility options are As per this specification, the following mobility options are
valid in a Proxy Binding Update message: valid in a Proxy Binding Update message:
Home Network Prefix option Home Network Prefix option
Link-local Address option Link-local Address option
Mobile Node Identifier Option Mobile Node Identifier Option
Access Technology Type option
Mobile Node Interface Identifier option
Timestamp option Timestamp option
For descriptions of other fields present in this message, refer to For descriptions of other fields present in this message, refer to
section 6.1.7 [RFC-3775]. section 6.1.7 [RFC-3775].
8.2. Proxy Binding Acknowledgement Message 8.2. Proxy Binding Acknowledgement 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 57, line 29 skipping to change at page 58, line 29
As per this specification, the following mobility options are As per this specification, the following mobility options are
valid in a Proxy Binding Acknowledgement message: valid in a Proxy Binding Acknowledgement message:
Home Network Prefix option Home Network Prefix option
Link-local Address option Link-local Address option
Mobile Node Identifier option Mobile Node Identifier option
Access Technology Type option
Mobile Node Interface Identifier option
Timestamp option Timestamp option
Status Status
8-bit unsigned integer indicating the disposition of the Proxy 8-bit unsigned integer indicating the disposition of the Proxy
Binding Update. Values of the Status field less than 128 indicate Binding Update. Values of the Status field less than 128 indicate
that the Proxy Binding Update was accepted by the local mobility that the Proxy Binding Update was accepted by the local mobility
anchor. Values greater than or equal to 128 indicate that the anchor. Values greater than or equal to 128 indicate that the
binding registration was rejected by the local mobility anchor. binding registration was rejected by the local mobility anchor.
Section 8.8 defines the Status values that can used in Proxy Section 8.8 defines the Status values that can used in Proxy
skipping to change at page 59, line 42 skipping to change at page 60, line 42
Access Technology Type (Acc Tech) Access Technology Type (Acc Tech)
A 8-bit field that specifies the access technology through A 8-bit field that specifies the access technology through
which the mobile node is connected to the access link on the which the mobile node is connected to the access link on the
mobile access gateway. mobile access gateway.
The values 0-255 will be allocated and managed by IANA. The The values 0-255 will be allocated and managed by IANA. The
following values are currently reserved for the below specified following values are currently reserved for the below specified
access technology types. access technology types.
0: Reserved 0x00: Reserved
1: 802.3 0x01: Virtual
2: 802.11a/b/g 0x02: PPP
3: 802.16e 0x02: 802.3 (Ethernet)
4: PPP 0x03: 802.11a
5: LTE 0x04: 802.11b
0x05: 802.11g
0x06: 802.16e
0x07: CDMA2000 1xEV-DO Release 0
0x08: CDMA2000 1xEV-DO Revision A
0x09: CDMA2000 1xEV-DO Revision B
0x0a: 3GPP LTE
Handoff Indicator (HI) Handoff Indicator (HI)
A 2-bit field that specifies the type of handoff. The values
A 3-bit field that specifies the type of handoff. The values
(0-3) will be allocated and managed by IANA. The following (0-3) will be allocated and managed by IANA. The following
values are currently reserved. values are currently reserved.
0: Reserved 0: Reserved
1: Attachment over a new interface 1: Attachment over a new interface
2: Handoff between interfaces 2: Handoff between interfaces
3: Handoff between mobile access gateways for the same interface 3: Handoff between mobile access gateways for the same interface
4: Handoff state unknown 4: Handoff state unknown
Reserved (R) Reserved (R)
This 6-bit field is unused for now. The value MUST be This 5-bit field is unused for now. The value MUST be
initialized to 0 by the sender and MUST be ignored by the initialized to 0 by the sender and MUST be ignored by the
receiver. receiver.
8.5. Mobile Node Interface Identifier Option 8.5. Mobile Node Interface Identifier Option
A new option, Mobile Node Interface Identifier Option is defined for A new option, Mobile Node Interface Identifier Option is defined for
using it in the Proxy Binding Update and Proxy Binding using it in the Proxy Binding Update and Proxy Binding
Acknowledgement messages exchanged between a local mobility anchor Acknowledgement messages exchanged between a local mobility anchor
and a mobile access gateway. This option is used for exchanging the and a mobile access gateway. This option is used for exchanging the
mobile node's interface identifier. mobile node's interface identifier.
The format of the Interface Identifier option when the interface The format of the Interface Identifier option when the interface
identifier is 8 bytes is shown below. When the size is different, identifier is 8 bytes is shown below. When the size is different,
the option MUST be aligned appropriately, as per mobility option the option MUST be aligned appropriately, as per mobility option
alignment requirements specified in [RFC-3775]. alignment requirements specified in [RFC-3775].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |P| Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Interface Identifier + + Interface Identifier +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
<IANA> <IANA>
Length Length
8-bit unsigned integer indicating the length of the option 8-bit unsigned integer indicating the length of the option
in octets, excluding the type and length fields. This field in octets, excluding the type and length fields. This field
MUST be set to 10. MUST be set to 10.
P Flag
A 1-bit field that specifies whether the carried interface
identifier is the currently attached interface identifier of
the mobile node, or if it is the identifier of the interface
from where the session is being handed off to a different
interface of the mobile node.
0: Interface Identifier of the currently attached interface
1: Interface Identifier of the other interface, when the
handoff is performed between two interfaces of the mobile
node.
Reserved Reserved
This field is unused for now. The value MUST be initialized to This field is unused for now. The value MUST be initialized to
0 by the sender and MUST be ignored by the receiver. 0 by the sender and MUST be ignored by the receiver.
Interface Identifier Interface Identifier
A variable length field containing the mobile node's interface A variable length field containing the mobile node's interface
identifier. identifier.
skipping to change at page 63, line 7 skipping to change at page 64, line 7
8.7. Timestamp Option 8.7. Timestamp Option
A new option, Timestamp Option is defined for use in the Proxy A new option, Timestamp Option is defined for use in the Proxy
Binding Update and Proxy Binding Acknowledgement messages. Binding Update and Proxy Binding Acknowledgement messages.
The Timestamp option has an alignment requirement of 8n+2. Its The Timestamp option has an alignment requirement of 8n+2. Its
format is as follows: format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Timestamp + + Timestamp +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
<IANA> <IANA>
skipping to change at page 65, line 10 skipping to change at page 66, line 10
128 Reason unspecified 128 Reason unspecified
129 Administratively prohibited 129 Administratively prohibited
130 Insufficient resources 130 Insufficient resources
133 Not local mobility anchor for this mobile node 133 Not local mobility anchor for this mobile node
9. Protocol Configuration Variables 9. Protocol Configuration Variables
The local mobility anchor MUST allow the following variables to be
configured by the system management.
MinDelayBeforeBCEDelete
This variable specifies the amount of time in milliseconds the
local mobility anchor MUST wait before it deletes a Binding Cache
entry of a mobile node, upon receiving a Proxy Binding Update
message from a mobile access gateway with a lifetime value of 0.
During this wait time, if the local mobility anchor receives a
Proxy Binding Update for the same mobility binding, with lifetime
value greater than 0, then it must update the binding cache entry
with the accepted binding values. By the end of this wait-time,
if the local mobility anchor did not receive any valid Proxy
Binding Update message for that mobility binding, it MUST delete
the Binding Cache entry. This delay essentially ensures a mobile
node's Binding Cache entry is not deleted too quickly and allows
some time for the new mobile access gateway to complete the
signaling for the mobile node.
The default value for this variable is 10000 milliseconds.
MinDelayBeforeNewBCEAssign
This variable specifies the amount of time in milliseconds the
local mobility anchor MUST wait for the de-registration message
for an existing mobility session before it decides to create a new
mobility session.
The default value for this variable is 500 milliseconds.
The mobile access gateway MUST allow the following variables to be The mobile access gateway MUST allow the following variables to be
configured by the system management. configured by the system management.
EnableMAGLocalrouting EnableMAGLocalrouting
This flag indicates whether or not the mobile access gateway is This flag indicates whether or not the mobile access gateway is
allowed to enable local routing of the traffic exchanged between a allowed to enable local routing of the traffic exchanged between a
visiting mobile node and a correspondent node that is locally visiting mobile node and a correspondent node that is locally
connected to one of the interfaces of the mobile access gateway. connected to one of the interfaces of the mobile access gateway.
The correspondent node can be another visiting mobile node as The correspondent node can be another visiting mobile node as
well, or a local fixed node. well, or a local fixed node.
The default value for this flag is set to "FALSE", indicating that The default value for this flag is set to "FALSE", indicating that
the mobile access gateway MUST reverse tunnel all the traffic to the mobile access gateway MUST reverse tunnel all the traffic to
the mobile node's local mobility anchor. the mobile node's local mobility anchor.
skipping to change at page 65, line 32 skipping to change at page 67, line 21
The default value for this flag is set to "FALSE", indicating that The default value for this flag is set to "FALSE", indicating that
the mobile access gateway MUST reverse tunnel all the traffic to the mobile access gateway MUST reverse tunnel all the traffic to
the mobile node's local mobility anchor. the mobile node's local mobility anchor.
When the value of this flag is set to "TRUE", the mobile access When the value of this flag is set to "TRUE", the mobile access
gateway MUST route the traffic locally. gateway MUST route the traffic locally.
This aspect of local routing MAY be defined as policy on a per This aspect of local routing MAY be defined as policy on a per
mobile basis and when present will take precedence over this flag. mobile basis and when present will take precedence over this flag.
The local mobility anchor MUST allow the following variables to be MinPBUReplyTime
configured by the system management.
MinDelayBeforeBCEDelete
This variable specifies the amount of time in milliseconds the This variable specifies the amount of time in milliseconds the
local mobility anchor MUST wait before it deletes a Binding Cache mobile access gateway SHOULD wait for the reply message for the
entry of a mobile node, upon receiving a Proxy Binding Update Proxy Binding Update request that it sent to the local mobility
message from a mobile access gateway with a lifetime value of 0. anchor.
During this wait time, if the local mobility anchor receives a
Proxy Binding Update for the same mobility binding, with lifetime
value greater than 0, then it must update the binding cache entry
with the accepted binding values. By the end of this wait-time,
if the local mobility anchor did not receive any valid Proxy
Binding Update message for that mobility binding, it MUST delete
the Binding Cache entry. This delay essentially ensures a mobile
node's Binding Cache entry is not deleted too quickly and allows
some time for the new mobile access gateway to complete the
signaling for the mobile node.
The default value for this variable is 10000 milliseconds. The default value for this variable is 2000 milliseconds.
10. IANA Considerations 10. IANA Considerations
This document defines a three new Mobility Header Options, the Home This document defines five new Mobility Header Options, the Home
Network Prefix option, Access Technology Type option, Interface Network Prefix option, Access Technology Type option, Interface
Identifier option, Link-local Address option and Timestamp option. Identifier option, Link-local Address option and Timestamp option.
These options are described in Sections 8.3, 8.4, 8.5, 8.6 and 8.7 These options are described in Sections 8.3, 8.4, 8.5, 8.6 and 8.7
respectively. The Type value for these options needs to be assigned respectively. The Type value for these options needs to be assigned
from the same numbering space as allocated for the other mobility from the same numbering space as allocated for the other mobility
options, as defined in [RFC-3775]. options, as defined in [RFC-3775].
The Mobility Header Option, Access Technology Type option defined in The Mobility Header Option, Access Technology Type option defined in
Section 8.4 of this document introduces a new Access Technology type Section 8.4 of this document introduces a new Access Technology type
numbering space, where the values from 0 to 5 have been reserved by numbering space, where the values from 0 to 5 have been reserved by
this document. Approval of new Access Technology type numbers is this document. Approval of new Access Technology type numbers are to
subject to IANA Approval. be made through IANA Expert Review.
This document also defines new Binding Acknowledgement status values This document also defines new Binding Acknowledgement status values
as described in Section 8.8. The status values MUST be assigned from as described in Section 8.8. The status values MUST be assigned from
the same number space used for Binding Acknowledgement status values, the same number space used for Binding Acknowledgement status values,
as defined in [RFC-3775]. The allocated values for each of these as defined in [RFC-3775]. The allocated values for each of these
status values MUST be greater than 128. status values MUST be greater than 128.
11. Security Considerations 11. Security Considerations
The potential security threats against any network-based mobility The potential security threats against any network-based mobility
skipping to change at page 67, line 41 skipping to change at page 69, line 15
12. Acknowledgements 12. Acknowledgements
The authors would like to specially thank Julien Laganier, Christian The authors would like to specially thank Julien Laganier, Christian
Vogt, Pete McCann, Brian Haley, Ahmad Muhanna, JinHyeock Choi for Vogt, Pete McCann, Brian Haley, Ahmad Muhanna, JinHyeock Choi for
their thorough review of this document. their thorough review of this document.
The authors would also like to thank Alex Petrescu, Alice Qinxia, The authors would also like to thank Alex Petrescu, Alice Qinxia,
Alper Yegin, Ashutosh Dutta, Behcet Sarikaya, Fred Templin, Genadi Alper Yegin, Ashutosh Dutta, Behcet Sarikaya, Fred Templin, Genadi
Velev, George Tsirtsis, Gerardo Giaretta, Henrik Levkowetz, Hesham Velev, George Tsirtsis, Gerardo Giaretta, Henrik Levkowetz, Hesham
Soliman, James Kempf, Jari Arkko, Jean-Michel Combes, John Zhao, Soliman, James Kempf, Jari Arkko, Jean-Michel Combes, John Zhao,
Jong-Hyouk Lee, Jonne Soininen, Jouni Korhonen, Kilian Weniger, Marco Jong-Hyouk Lee, Jonne Soininen, Jouni Korhonen, Kalin Getov, Kilian
Liebsch, Mohamed Khalil, Nishida Katsutoshi, Phil Roberts, Ryuji Weniger, Marco Liebsch, Mohamed Khalil, Nishida Katsutoshi, Phil
Wakikawa, Sangjin Jeong, Suresh Krishnan, Ved Kafle, Vidya Narayanan, Roberts, Ryuji Wakikawa, Sangjin Jeong, Suresh Krishnan, Ved Kafle,
Youn-Hee Han and many others for their passionate discussions in the Vidya Narayanan, Youn-Hee Han and many others for their passionate
working group mailing list on the topic of localized mobility discussions in the working group mailing list on the topic of
management solutions. These discussions stimulated much of the localized mobility management solutions. These discussions
thinking and shaped the draft to the current form. We acknowledge stimulated much of the thinking and shaped the draft to the current
that ! form. We acknowledge that !
The authors would also like to thank Ole Troan, Akiko Hattori, Parviz The authors would also like to thank Ole Troan, Akiko Hattori, Parviz
Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer and Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer and
Tim Stammers for their input on this document. Tim Stammers for their input on this document.
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
skipping to change at page 69, line 42 skipping to change at page 71, line 13
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC-4941] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions [RFC-4941] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions
for Stateless Address Autoconfiguration in IPv6", RFC 4941, September for Stateless Address Autoconfiguration in IPv6", RFC 4941, September
2007. 2007.
[RFC-5072] Varada, S., Haskin, D. and Allen, E., "IP version 6 over [RFC-5072] Varada, S., Haskin, D. and Allen, E., "IP version 6 over
PPP", RFC 5072, September 2007. PPP", RFC 5072, September 2007.
[ID-IPV4-PMIP6] Wakikawa, R. and Gundavelli, S., "IPv4 Support for [ID-IPV4-PMIP6] Wakikawa, R. and Gundavelli, S., "IPv4 Support for
Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-01.txt, May Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02.txt,
2007. November 2007.
[ID-DNAV6] Kempf, J., et al "Detecting Network Attachment in IPv6 [ID-DNAV6] Kempf, J., et al "Detecting Network Attachment in IPv6
Networks (DNAv6)", draft-ietf-dna-protocol-06.txt, October 2006. Networks (DNAv6)", draft-ietf-dna-protocol-06.txt, October 2006.
Appendix A. Proxy Mobile IPv6 interactions with AAA Infrastructure Appendix A. Proxy Mobile IPv6 interactions with AAA Infrastructure
Every mobile node that roams in a proxy Mobile IPv6 domain, would Every mobile node that roams in a proxy Mobile IPv6 domain, would
typically be identified by an identifier, MN-Identifier, and that typically be identified by an identifier, MN-Identifier, and that
identifier will have an associated policy profile that identifies the identifier will have an associated policy profile that identifies the
mobile node's home network prefix, permitted address configuration mobile node's home network prefix, permitted address configuration
modes, roaming policy and other parameters that are essential for modes, roaming policy and other parameters that are essential for
providing network-based mobility service. This information is providing network-based mobility service. This information is
typically configured in AAA. It is possible the home network prefix typically configured in AAA. It is possible the home network prefix
is dynamically allocated for the mobile node when it boots up for the is dynamically allocated for the mobile node when it boots up for the
first time in the network, or it could be a statically configured first time in the network, or it could be a statically configured
value on per mobile node basis. However, for all practical purposes, value on per mobile node basis. However, for all practical purposes,
skipping to change at page 71, line 7 skipping to change at page 72, line 22
_ANY_DESTINATION_, route via tunnel0, next-hop LMAA, where tunnel0 is _ANY_DESTINATION_, route via tunnel0, next-hop LMAA, where tunnel0 is
the MAG to LMA tunnel. the MAG to LMA tunnel.
Routing state at the local mobility anchor: Routing state at the local mobility anchor:
For all IPv6 traffic to destination MN-HoA::/128, route via tunnel0, For all IPv6 traffic to destination MN-HoA::/128, route via tunnel0,
next-hop Proxy-CoA, where tunnel0 is the LMA to MAG tunnel. next-hop Proxy-CoA, where tunnel0 is the LMA to MAG tunnel.
Authors' Addresses Authors' Addresses
Sri Gundavelli (Editor) Sri Gundavelli
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: sgundave@cisco.com Email: sgundave@cisco.com
Kent Leung Kent Leung
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
 End of changes. 194 change blocks. 
637 lines changed or deleted 713 lines changed or added

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