draft-ietf-netlmm-proxymip6-10.txt   draft-ietf-netlmm-proxymip6-11.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: August 12, 2008 V. Devarapalli Expires: August 28, 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
February 09, 2008 February 25, 2008
Proxy Mobile IPv6 Proxy Mobile IPv6
draft-ietf-netlmm-proxymip6-10.txt draft-ietf-netlmm-proxymip6-11.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 August 12, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
Network-based mobility management enables IP mobility for a host Network-based mobility management enables IP mobility for a host
without requiring its participation in any mobility related without requiring its participation in any mobility related
signaling. The Network is responsible for managing IP mobility on signaling. The Network is responsible for managing IP mobility on
skipping to change at page 2, line 19 skipping to change at page 2, line 19
referred to as Proxy Mobile IPv6. referred to as Proxy Mobile IPv6.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . 15 4.1. Peer Authorization Database (PAD) Entries . . . . . . . . 15
4.2. Security Policy Database Entries . . . . . . . . . . . . . 15 4.2. Security Policy Database (SPD) 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.3.1. Processing Binding Registrations . . . . . . . . . . . 18 5.3.1. Processing Binding Registrations . . . . . . . . . . . 18
5.3.2. Initial Binding Registration (New Mobility Session) . 20 5.3.2. Initial Binding Registration (New Mobility Session) . 20
5.3.3. Binding Lifetime Extension (No handoff) . . . . . . . 21 5.3.3. Binding Lifetime Extension (No handoff) . . . . . . . 21
5.3.4. Binding Lifetime Extension (After handoff) . . . . . . 22 5.3.4. Binding Lifetime Extension (After handoff) . . . . . . 22
5.3.5. Binding De-Registration . . . . . . . . . . . . . . . 22 5.3.5. Binding De-Registration . . . . . . . . . . . . . . . 22
5.3.6. Constructing the Proxy Binding Acknowledgement 5.3.6. Constructing the Proxy Binding Acknowledgement
skipping to change at page 3, line 6 skipping to change at page 3, line 6
6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 38 6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 38
6.3. Supported Access Link Types . . . . . . . . . . . . . . . 38 6.3. Supported Access Link Types . . . . . . . . . . . . . . . 38
6.4. Supported Address Configuration Modes . . . . . . . . . . 39 6.4. Supported Address Configuration Modes . . . . . . . . . . 39
6.5. Access Authentication & Mobile Node Identification . . . . 39 6.5. Access Authentication & Mobile Node Identification . . . . 39
6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 40 6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 40
6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 40 6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 40
6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 41 6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 41
6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 42 6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 42
6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 42 6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 42
6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 50 6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 50
6.9.3. Default-Router Lifetime . . . . . . . . . . . . . . . 50 6.9.3. Default-Router Lifetime . . . . . . . . . . . . . . . 51
6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 51 6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 51
6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 52 6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 52
6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 52 6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 53
6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 53 6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 53
6.10.3. Local Routing . . . . . . . . . . . . . . . . . . . . 53 6.10.3. Local Routing . . . . . . . . . . . . . . . . . . . . 54
6.10.4. Tunnel Management . . . . . . . . . . . . . . . . . . 54 6.10.4. Tunnel Management . . . . . . . . . . . . . . . . . . 54
6.10.5. Forwarding Rules . . . . . . . . . . . . . . . . . . . 54 6.10.5. Forwarding Rules . . . . . . . . . . . . . . . . . . . 54
6.11. Supporting DHCPv6 based Address Configuration on the 6.11. Supporting DHCPv6 based Address Configuration on the
Access Link . . . . . . . . . . . . . . . . . . . . . . . 55 Access Link . . . . . . . . . . . . . . . . . . . . . . . 56
6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 56 6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 57
6.13. Mobile Node Detachment Detection and Resource Cleanup . . 57 6.13. Mobile Node Detachment Detection and Resource Cleanup . . 57
6.14. Allowing network access to other IPv6 nodes . . . . . . . 57 6.14. Allowing network access to other IPv6 nodes . . . . . . . 58
7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 58 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 58
7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 58 7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 58
7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 59 7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 59
8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 59 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 60
8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 60 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 60
8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 61 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 62
8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 63 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 63
8.4. Handoff Indicator Option . . . . . . . . . . . . . . . . . 64 8.4. Handoff Indicator Option . . . . . . . . . . . . . . . . . 64
8.5. Access Technology Type Option . . . . . . . . . . . . . . 65 8.5. Access Technology Type Option . . . . . . . . . . . . . . 65
8.6. Mobile Node Interface Identifier Option . . . . . . . . . 67 8.6. Mobile Node Interface Identifier Option . . . . . . . . . 67
8.7. Link-local Address Option . . . . . . . . . . . . . . . . 68 8.7. Link-local Address Option . . . . . . . . . . . . . . . . 68
8.8. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 68 8.8. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 68
8.9. Status Values . . . . . . . . . . . . . . . . . . . . . . 69 8.9. Status Values . . . . . . . . . . . . . . . . . . . . . . 69
9. Protocol Configuration Variables . . . . . . . . . . . . . . . 71 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 71
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72
11. Security Considerations . . . . . . . . . . . . . . . . . . . 73 11. Security Considerations . . . . . . . . . . . . . . . . . . . 73
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 74 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 74
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74
13.1. Normative References . . . . . . . . . . . . . . . . . . . 74 13.1. Normative References . . . . . . . . . . . . . . . . . . . 74
13.2. Informative References . . . . . . . . . . . . . . . . . . 75 13.2. Informative References . . . . . . . . . . . . . . . . . . 75
Appendix A. Proxy Mobile IPv6 interactions with AAA Appendix A. Proxy Mobile IPv6 interactions with AAA
Infrastructure . . . . . . . . . . . . . . . . . . . 76 Infrastructure . . . . . . . . . . . . . . . . . . . 76
Appendix B. Supporting Shared-Prefix Model using DHCPv6 . . . . . 76 Appendix B. Supporting Shared-Prefix Model using DHCPv6 . . . . . 77
Appendix C. Routing State . . . . . . . . . . . . . . . . . . . . 77 Appendix C. Routing State . . . . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 78
Intellectual Property and Copyright Statements . . . . . . . . . . 80 Intellectual Property and Copyright Statements . . . . . . . . . . 80
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
skipping to change at page 6, line 50 skipping to change at page 6, line 50
Mobile Node's Home Address (MN-HoA) Mobile Node's Home Address (MN-HoA)
MN-HoA is an address from a mobile node's home network prefix in a MN-HoA is an address from a mobile node's home network prefix in a
Proxy Mobile IPv6 domain. The mobile node will be able to use Proxy Mobile IPv6 domain. The mobile node will be able to use
this address as long as it is attached to the access network that this address as long as it is attached to the access network that
is in the scope of that Proxy Mobile IPv6 domain. Unlike in is in the scope of that Proxy Mobile IPv6 domain. Unlike in
Mobile IPv6 where the home agent is aware of the home address of Mobile IPv6 where the home agent is aware of the home address of
the mobile node, in Proxy Mobile IPv6, the mobility entities are the mobile node, in Proxy Mobile IPv6, the mobility entities are
only aware of the mobile node's home network prefix and are not only aware of the mobile node's home network prefix and are not
always aware of the exact address(es) that the mobile node always aware of the exact address(es) that the mobile node
configured on its interface from that prefix. configured on its interface from that prefix. However, in some
configurations and based on the enabled address configuration
modes on the access link, the mobility entities in the network can
be certain about the exact address configured by the mobile node.
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, each of the connected interface will interfaces, simultaneously, each of the connected interface will
be assigned a unique home network prefix and under a different be assigned a unique home network prefix and under a different
mobility session. mobility session.
skipping to change at page 7, line 37 skipping to change at page 7, line 41
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 these 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 use entities in a Proxy Mobile IPv6 domain can always acquire and use
it for predictably identifying a mobile node. This is typically it for predictably identifying a mobile node. This is typically
an identifier such as NAI or other identifier such as a MAC an identifier such as Network Access Identifier (NAI) or other
address. identifier such as a Media Access Control (MAC) 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.
skipping to change at page 8, line 24 skipping to change at page 8, line 28
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.
Per-MN-Prefix & Shared-Prefix Models
The term, Per-MN-Prefix model, is used to refer to an addressing
model where there is an unique network prefix assigned for each
node. The term, Shared-Prefix model, is used to refer to an
addressing model where the prefix is shared by more than one node.
ALL_ZERO & NON_ZERO
Protocol message fields initialized with value 0 in each byte of
the field. Ex: An 8-byte interface identifier field with the
value set to 0 in each of the 8 bytes, or an IPv6 address with the
value 0 in all of the 16 bytes. Conversely, the term NON_ZERO is
used to refer to any value other than an ALL_ZERO value.
3. Proxy Mobile IPv6 Protocol Overview 3. Proxy Mobile IPv6 Protocol Overview
This specification describes a network-based mobility management This specification describes a network-based mobility management
protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6
[RFC-3775]. [RFC-3775].
Proxy Mobile IPv6 protocol is intended for providing network-based IP 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 IP mobility related participation of the mobile node in any IP mobility related
signaling. The mobility entities in the network will track the signaling. The mobility entities in the network will track the
skipping to change at page 11, line 45 skipping to change at page 11, line 45
Figure 2 shows the signaling call flow when the mobile node enters Figure 2 shows the signaling call flow when the mobile node enters
the Proxy Mobile IPv6 domain. the Proxy Mobile IPv6 domain.
For updating the local mobility anchor about the current location of For updating the local mobility anchor about the current location of
the mobile node, the mobile access gateway sends a Proxy Binding the mobile node, the mobile access gateway sends a Proxy Binding
Update message to the mobile node's local mobility anchor. Upon Update message to the mobile node's local mobility anchor. Upon
accepting this Proxy Binding Update message, the local mobility accepting this Proxy Binding Update message, the local mobility
anchor sends a Proxy Binding Acknowledgement message including the anchor sends a Proxy Binding Acknowledgement message including the
mobile node's home network prefix. It also creates the Binding Cache mobile node's home network prefix. It also creates the Binding Cache
entry and establishes a bi-directional tunnel to the mobile access entry and sets up its endpoint of the bi-directional tunnel to the
gateway. mobile access gateway.
The mobile access gateway on receiving the Proxy Binding The mobile access gateway on receiving the Proxy Binding
Acknowledgement message sets up a bi-directional tunnel to the local Acknowledgement message sets up its endpoint of the bi-directional
mobility anchor and sets up the data path for the mobile node's tunnel to the local mobility anchor and also sets up the data path
traffic. At this point the mobile access gateway will have all the for the mobile node's traffic. At this point the mobile access
required information for emulating the mobile node's home link. It gateway will have all the required information for emulating the
sends Router Advertisement messages to the mobile node on the access mobile node's home link. It sends Router Advertisement messages to
link advertising the mobile node's home network prefix as the hosted the mobile node on the access link advertising the mobile node's home
on-link-prefix. network prefix as the hosted on-link-prefix.
The mobile node on receiving these Router Advertisement messages on The mobile node on receiving these Router Advertisement messages on
the access link will attempt to configure its interface either using the access link will attempt to configure its interface either using
stateful or stateless address configuration modes, based on the modes stateful or stateless address configuration modes, based on the modes
that are permitted on that access link. At the end of a successful that are permitted on that access link. At the end of a successful
address configuration procedure, the mobile node will end up with an address configuration procedure, the mobile node will end up with an
address from its home network prefix. address from its home network prefix.
Once the address configuration is complete, the mobile node has a Once the address configuration is complete, the mobile node has a
valid address from its home network prefix at the current point of valid address from its home network prefix at the current point of
attachment. The serving mobile access gateway and the local mobility attachment. The serving mobile access gateway and the local mobility
anchor also have proper routing states for handling the traffic sent anchor also have proper routing states for handling the traffic sent
to and from the mobile node using an address from its home network to and from the mobile node using an address from its home network
prefix. prefix.
The local mobility anchor, being the topological anchor point for the The local mobility anchor, being the topological anchor point for the
mobile node's home network prefix, receives any packets that are sent mobile node's home network prefix, receives any packets that are sent
by any correspondent node to the mobile node. The local mobility to the mobile node by any node in the network. The local mobility
anchor forwards these received packets to the mobile access gateway anchor forwards these received packets to the mobile access gateway
through the bi-directional tunnel. The mobile access gateway on through the bi-directional tunnel. The mobile access gateway on
other end of the tunnel, after receiving the packet, removes the other end of the tunnel, after receiving the packet, removes the
outer header and forwards the packet on the access link to the mobile outer header and forwards the packet on the access link to the mobile
node. node.
The mobile access gateway typically acts as a default router on the The mobile access gateway typically acts as a default router on the
access link. Any packet that the mobile node sends to any access link. Any packet that the mobile node sends to any
correspondent node will be received by the mobile access gateway and correspondent node will be received by the mobile access gateway and
will be sent to its local mobility anchor through the bi-directional will be sent to its local mobility anchor through the bi-directional
skipping to change at page 13, line 48 skipping to change at page 13, line 48
attached mobile access gateway (n-MAG). This call flow reflects only attached mobile access gateway (n-MAG). This call flow reflects only
a specific message ordering, it is possible the registration message a specific message ordering, it is possible the registration message
from the n-MAG may arrive before the de-registration message from the from the n-MAG may arrive before the de-registration message from the
p-MAG arrives. p-MAG arrives.
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 previous link will detect the mobile mobile access gateway on the previous link will detect the mobile
node's detachment from the link and will signal the local mobility node's detachment from the link and will signal the local mobility
anchor and will remove the binding and routing state for that mobile anchor and will remove the binding and routing state for that mobile
node. However, the local mobility anchor upon accepting the request node. The local mobility anchor upon receiving this request will
will wait for certain amount of time before it deletes the binding, identify the corresponding mobility session for which the binding
for allowing a smooth handoff. update request was received and once it accepts the request will wait
for certain amount of time for allowing the mobile access gateway on
the new link to update the binding. However, if it does not receive
any binding update request within that given amount of time, it will
delete the binding cache entry.
The mobile access gateway on the new access link upon detecting the The mobile access gateway on the new access link upon detecting the
mobile node on its access link will signal the local mobility anchor mobile node on its access link will signal the local mobility anchor
for updating the binding state. Once that signaling is complete, the for updating the binding state. Once that signaling is complete, the
mobile node will continue to receive the Router Advertisements 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 it will use the same address configuration on the the same link and it will use the same address configuration on the
new access link. new access link.
4. Proxy Mobile IPv6 Protocol Security 4. Proxy Mobile IPv6 Protocol Security
skipping to change at page 15, line 6 skipping to change at page 15, line 10
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, the local mobility messages or sending binding updates. Therefore, the local mobility
anchor MUST restrict the creation and manipulation of proxy bindings anchor MUST restrict the creation and manipulation of proxy bindings
to specifically authorized mobile access gateways and prefixes. The to specifically authorized mobile access gateways and prefixes. The
local mobility anchor MUST be locally configurable to authorize such local mobility anchor MUST be locally configurable to authorize such
specific combinations. Additional mechanisms such as a policy store specific combinations. Additional mechanisms such as a policy store
or AAA may be employed, but these are outside the scope of this or AAA may be employed, but these are outside the scope of this
specification. specification.
4.1. Peer Authorization Database Entries 4.1. Peer Authorization Database (PAD) Entries
This section describes PAD entries [RFC-4301] on the mobile access This section describes PAD entries [RFC-4301] on the mobile access
gateway and the local mobility anchor. The PAD entries are only gateway and the local mobility anchor. The PAD entries are only
example 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:
skipping to change at page 15, line 32 skipping to change at page 15, line 36
- IF remote_identity = mag_identity_1 - IF remote_identity = mag_identity_1
Then authenticate (shared secret/certificate/EAP) Then authenticate (shared secret/certificate/EAP)
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 (SPD) Entries
This section describes the security policy entries [RFC-4301] on the This section describes the security policy entries [RFC-4301] on the
mobile access gateway and the local mobility anchor required to mobile access gateway and the local mobility anchor required to
protect the Proxy Mobile IPv6 signaling messages. The SPD entries protect the Proxy Mobile IPv6 signaling messages. The SPD entries
are only example configurations. A particular mobile access gateway are only example configurations. A particular mobile access gateway
or a local mobility anchor implementation could configure different or a local mobility anchor implementation could configure different
SPD 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
skipping to change at page 16, line 41 skipping to change at page 16, line 41
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].
For supporting this specification, the Binding Cache Entry data For supporting this specification, the Binding Cache Entry data
structure needs to be extended with the following additional fields. structure needs to be extended with the following additional fields.
o A flag indicating whether or not this Binding Cache entry is o A flag indicating whether or not this Binding Cache entry is
created due to a proxy registration. This flag is enabled for created due to a proxy registration. This flag is set to value 1
Binding Cache entries that are proxy registrations and is turned for Binding Cache entries that are proxy registrations and is set
off for all other entries. to value 0 for all other entries.
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, present in the received Mobile Node Interface Identifier option, present in the received
Proxy Binding Update request. If the option was not present in Proxy Binding Update request. If the option was not present in
the request, the value MUST be set to ALL_ZERO. the request, the value MUST be set to ALL_ZERO.
skipping to change at page 18, line 36 skipping to change at page 18, line 36
This section provides the rules for processing the signaling This section provides the rules for processing the signaling
messages. The processing rules specified in this section and other messages. The processing rules specified in this section and other
related sections are chained and are in a specific order. When related sections are chained and are in a specific order. When
applying these considerations for processing the signaling messages, applying these considerations for processing the signaling messages,
the specified order MUST be maintained. the specified order MUST be maintained.
5.3.1. Processing Binding Registrations 5.3.1. Processing Binding Registrations
1. The received Proxy Binding Update message (a Binding Update 1. The received Proxy Binding Update message (a Binding Update
message with the 'P' flag set) MUST be authenticated as message with the 'P' flag set to value of 1, format specified in
described in Section 4. When IPsec is used for message Section 8.1) MUST be authenticated as described in Section 4.
authentication, the SPI in the IPsec header [RFC-4306] of the When IPsec is used for message authentication, the SPI in the
received packet is needed for locating the security association, IPsec header [RFC-4306] of the received packet is needed for
for authenticating the Proxy Binding Update message. locating the security association, for authenticating the Proxy
Binding Update message.
2. The local mobility anchor MUST observe the rules described in 2. The local mobility anchor MUST observe the rules described in
Section 9.2 [RFC-3775] when processing Mobility Header in the Section 9.2 [RFC-3775] when processing Mobility Header in the
received Proxy Binding Update request. Additionally, the rules received Proxy Binding Update request.
specified in Section 10.3 [RFC-3775] MUST be applied when
processing this message.
3. The local mobility anchor MUST ignore the check, specified in 3. The local mobility anchor MUST ignore the check, specified in
Section 10.3.1 [RFC-3775], related to the presence of Home Section 10.3.1 [RFC-3775], related to the presence of Home
Address destination option in the Proxy Binding Update request. Address destination option in the Proxy Binding Update request.
4. The local mobility anchor MUST identify the mobile node from the 4. The local mobility anchor MUST identify the mobile node from the
identifier present in the Mobile Node Identifier option [RFC- identifier present in the Mobile Node Identifier option [RFC-
4283] 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
skipping to change at page 22, line 18 skipping to change at page 22, line 18
binding lifetime, received from a new mobile access gateway where binding lifetime, received from a new mobile access gateway where
the mobile node's session is handed off, the local mobility the mobile node's session is handed off, the local mobility
anchor MUST update the Binding Cache entry with the accepted anchor MUST update the Binding Cache entry with the accepted
registration values. However, if the link-local address value in registration values. However, if the link-local address value in
the Link-local address option is ALL_ZERO value, the link-local the Link-local address option is ALL_ZERO value, the link-local
address field in the Binding Cache entry MUST NOT be updated. address field in the Binding Cache entry MUST NOT be updated.
2. The local mobility anchor MUST remove the previously created 2. The local mobility anchor MUST remove the previously created
route for the mobile node's home network prefix. Additionally, route for the mobile node's home network prefix. Additionally,
if there are no other mobile node's sessions sharing the tunnel if there are no other mobile node's sessions sharing the tunnel
to the previous mobile access gateway, the tunnel MUST be to the previous mobile access gateway, the tunnel MUST also be
deleted. deleted applying considerations from section 5.6.1 (if the tunnel
is a dynamically created tunnel and not a fixed pre-established
tunnel).
3. The local mobility anchor MUST establish a bi-directional tunnel 3. The local mobility anchor MUST establish a bi-directional tunnel
to the mobile access gateway that sent the request. to the mobile access gateway that sent the request.
Considerations from Section 5.6 MUST be applied for creating the Considerations from Section 5.6 MUST be applied for creating the
routing state. routing state.
4. The local mobility anchor MUST send the Proxy Binding 4. The local mobility anchor MUST send the Proxy Binding
Acknowledgement message with the Status field set to 0 (Proxy Acknowledgement message with the Status field set to 0 (Proxy
Binding Update Accepted). The message MUST be constructed as Binding Update Accepted). The message MUST be constructed as
specified in Section 5.3.6. specified in Section 5.3.6.
skipping to change at page 23, line 27 skipping to change at page 23, line 27
session. session.
5.3.6. Constructing the Proxy Binding Acknowledgement Message 5.3.6. Constructing the Proxy Binding Acknowledgement Message
o The local mobility anchor when sending the Proxy Binding o The local mobility anchor when sending the Proxy Binding
Acknowledgement message to the mobile access gateway MUST Acknowledgement message to the mobile access gateway MUST
construct the message as specified below. construct the message as specified below.
IPv6 header (src=LMAA, dst=Proxy-CoA) IPv6 header (src=LMAA, dst=Proxy-CoA)
Mobility header Mobility header
- BA /* P flag must be set */ - BA /* P flag must be set to value of 1 */
Mobility Options Mobility Options
- Mobile Node Identifier Option (mandatory) - Mobile Node Identifier Option (mandatory)
- Home Network Prefix option (mandatory) - Home Network Prefix option (mandatory)
- Handoff Indicator option (mandatory) - Handoff Indicator option (mandatory)
- Access Technology Type option (mandatory) - Access Technology Type option (mandatory)
- Timestamp Option (optional) - Timestamp Option (optional)
- Mobile Node Interface Identifier option (optional) - Mobile Node Interface Identifier option (optional)
- Link-local Address option (optional) - Link-local Address option (optional)
Figure 6: Proxy Binding Acknowledgement message format Figure 6: Proxy Binding Acknowledgement message format
skipping to change at page 26, line 36 skipping to change at page 26, line 36
| HI | | HI |
+==================================+==================================+ +==================================+==================================+
| BCE Lookup Key: (Home Network Prefix) | | BCE Lookup Key: (Home Network Prefix) |
+=====================================================================+ +=====================================================================+
Figure 7: BCE lookup using home network prefix Figure 7: BCE lookup using home network prefix
1. 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 with the home network prefix value matching Binding Cache entry with the home network prefix value matching
the prefix value in the Home Network Prefix option of the the prefix value in the Home Network Prefix option of the
received Proxy Binding Update request. [BCE(HNP) == PBU(HNP)] received Proxy Binding Update request. [BCE(HNP) equals
PBU(HNP)]
2. If there does not exist a Binding Cache entry (matching the MN- 2. If there does not exist a Binding Cache entry (matching the MN-
HNP), the request MUST be considered as a request for creating a HNP), the request MUST be considered as a request for creating a
new mobility session. new mobility session.
3. If there exists a Binding Cache entry (matching MN-HNP), and if 3. If there exists a Binding Cache entry (matching MN-HNP), and if
the mobile node identifier in the entry does not match the mobile the mobile node identifier in the entry does not match the mobile
node identifier in the Mobile Node Identifier option of the node identifier in the Mobile Node Identifier option of the
received Proxy Binding Update request, the local mobility anchor received Proxy Binding Update request, the local mobility anchor
MUST reject the request with the Status field value set to MUST reject the request with the Status field value set to
NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node is not NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node is not
authorized for the requesting home network prefix). [BCE(MN- authorized for the requesting home network prefix). [BCE(MN-
Identifier) != PBU(MN-Identifier)] Identifier) not equals PBU(MN-Identifier)]
4. If there exists a Binding Cache entry (matching MN-Identifier and 4. If there exists a Binding Cache entry (matching MN-Identifier and
MN-HNP) and if any one or more of these below stated conditions MN-HNP) and if any one or more of these below stated conditions
match, the request MUST be considered as a request for updating match, the request MUST be considered as a request for updating
that Binding Cache entry. [BCE(MN-Identifier) == PBU(MN- that Binding Cache entry. [BCE(MN-Identifier) equals PBU(MN-
Identifier)] Identifier)]
* If there is a Mobile Node Interface Identifier option present * If there is a Mobile Node Interface Identifier option present
in the request, and if the interface identifier value in that in the request, and if the interface identifier value in that
option matches the interface identifier value in the Binding option matches the interface identifier value in the Binding
Cache entry and the access technology type field in the Access Cache entry and the access technology type field in the Access
Technology Type option present in the request matches the Technology Type option present in the request matches the
access technology type in the Binding Cache entry . [BCE(ATT, access technology type in the Binding Cache entry . [BCE(ATT,
MN-Interface-Identifier) == PBU(ATT, MN-Interface-Identifier)] MN-Interface-Identifier) equals PBU(ATT, MN-Interface-
Identifier)]
* If the Handoff Indicator field in the Handoff Indicator option * If the Handoff Indicator field in the Handoff Indicator option
present in the request is set to a value of 2 (Handoff between present in the request is set to a value of 2 (Handoff between
two different interfaces of the mobile node). two different interfaces of the mobile node). [PBU(HI) equals
2]
* If there is no Mobile Node Interface Identifier option present * If there is no Mobile Node Interface Identifier option present
in the request, the interface identifier value in the Binding in the request, the interface identifier value in the Binding
Cache entry is set to ALL_ZERO, the access technology type Cache entry is set to ALL_ZERO, the access technology type
field in the Access Technology Type option present in the field in the Access Technology Type option present in the
request matches the access technology type in the Binding request matches the access technology type in the Binding
Cache entry and if the Handoff Indicator field in the Handoff Cache entry and if the Handoff Indicator field in the Handoff
Indicator option present in the request is set to a value of 3 Indicator option present in the request is set to a value of 3
(Handoff between mobile access gateways for the same (Handoff between mobile access gateways for the same
interface). interface).
* If the Proxy-CoA address in the Binding Cache entry matches * If the Proxy-CoA address in the Binding Cache entry matches
the source address of the request (or the address in the the source address of the request (or the address in the
alternate Care-of Address option, if the option is present) alternate Care-of Address option, if the option is present)
and if the access technology type field in the Access and if the access technology type field in the Access
Technology Type option present in the request matches the Technology Type option present in the request matches the
access technology type in the Binding Cache entry. access technology type in the Binding Cache entry.
[BCE(Proxy-CoA, ATT) == PBU(Proxy-CoA, ATT)]. [BCE(Proxy-CoA, ATT) equals PBU(Proxy-CoA, ATT)].
5. For all other cases, the message MUST be considered as a request 5. For all other cases, the message MUST be considered as a request
for creating a new mobility session. for creating a new mobility session.
5.4.1.2. Mobile Node Interface Identifier Option present in the request 5.4.1.2. Mobile Node Interface Identifier Option present in the request
+=====================================================================+ +=====================================================================+
| Registration/De-Registration Message | | Registration/De-Registration Message |
+=====================================================================+ +=====================================================================+
| HNP (ALL_ZERO Value) | | HNP (ALL_ZERO Value) |
skipping to change at page 28, line 31 skipping to change at page 28, line 31
Figure 8: BCE Lookup using Interface Identifier Figure 8: BCE Lookup using Interface Identifier
1. 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, with the mobile node identifier matching the Binding Cache entry, with the mobile node identifier matching the
identifier in the received Mobile Node Identifier option, access identifier in the received Mobile Node Identifier option, access
technology type matching the value in the received Access technology type matching the value in the received Access
Technology Type option and the interface identifier value Technology Type option and the interface identifier value
matching the identifier in the received Mobile Node Interface matching the identifier in the received Mobile Node Interface
Identifier option. [BCE(MN-Identifier, ATT, MN-Interface- Identifier option. [BCE(MN-Identifier, ATT, MN-Interface-
Identifier) == PBU(MN-Identifier, ATT, MN-Interface-Identifier)] Identifier) equals PBU(MN-Identifier, ATT, MN-Interface-
Identifier)]
2. If there exists a Binding Cache entry (matching MN-Identifier, 2. If there exists a Binding Cache entry (matching MN-Identifier,
ATT and MN-Interface-Identifier), the request MUST be considered ATT and MN-Interface-Identifier), the request MUST be considered
as a request for updating that Binding Cache entry. as a request for updating that Binding Cache entry.
3. If there does not exist a Binding Cache entry (matching MN- 3. If there does not exist a Binding Cache entry (matching MN-
Identifier, ATT and MN-Interface-Identifier) and the Handoff Identifier, ATT and MN-Interface-Identifier) and the Handoff
Indicator field in the Handoff Indicator option present in the Indicator field in the Handoff Indicator option present in the
request is set to a value of 2 (Handoff between two different request is set to a value of 2 (Handoff between two different
interfaces of the mobile node). The local mobility anchor MUST interfaces of the mobile node). The local mobility anchor MUST
apply the following additional considerations. [PBU(HI) == 2] apply the following additional considerations. [PBU(HI) equals
2]
* The local mobility anchor MUST verify if there exists one and * The local mobility anchor MUST verify if there exists one and
only one Binding Cache entry with the mobile node identifier only one Binding Cache entry with the mobile node identifier
matching the identifier in the Mobile Node Identifier option matching the identifier in the Mobile Node Identifier option
present in the request and for any interface identifier value. present in the request and for any interface identifier value.
If there exists only one such entry (matching the MN- If there exists only one such entry (matching the MN-
Identifier), the request MUST be considered as a request for Identifier), the request MUST be considered as a request for
updating that Binding Cache entry. [BCE(MN-Identifier) == updating that Binding Cache entry. [BCE(MN-Identifier) equals
PBU(MN-Identifier)] PBU(MN-Identifier)]
4. If there does not exist a Binding Cache entry (matching MN- 4. If there does not exist a Binding Cache entry (matching MN-
Identifier, ATT and MN-Interface-Identifier) and if the Handoff Identifier, ATT and MN-Interface-Identifier) and if the Handoff
Indicator field in the Handoff Indicator option present in the Indicator field in the Handoff Indicator option present in the
request is set to a value of 4 (Handoff state unknown), the local request is set to a value of 4 (Handoff state unknown), the local
mobility anchor MUST apply the following additional mobility anchor MUST apply the following additional
considerations. considerations.
* The local mobility anchor MUST verify if there exists one and * The local mobility anchor MUST verify if there exists one and
skipping to change at page 29, line 27 skipping to change at page 29, line 29
matching the identifier in the Mobile Node Identifier option matching the identifier in the Mobile Node Identifier option
present in the request and for any interface identifier value. present in the request and for any interface identifier value.
If there exists only one such entry (matching the MN- If there exists only one such entry (matching the MN-
Identifier), the local mobility anchor SHOULD wait till the Identifier), the local mobility anchor SHOULD wait till the
existing Binding Cache entry is de-registered by the existing Binding Cache entry is de-registered by the
previously serving mobile access gateway, before the request previously serving mobile access gateway, before the request
can be considered as a request for updating that Binding Cache can be considered as a request for updating that Binding Cache
entry. However, if there is no de-registration message that entry. However, if there is no de-registration message that
is received within MaxDelayBeforeNewBCEAssign amount of time, is received within MaxDelayBeforeNewBCEAssign amount of time,
the local mobility anchor upon accepting the request MUST the local mobility anchor upon accepting the request MUST
consider the request as a request for updating that Binding consider the request as a request for creating a new mobility
Cache entry. The local mobility anchor MAY also choose to session. The local mobility anchor MAY also choose to create
create a new mobility session and without waiting for a de- a new mobility session and without waiting for a de-
registration message and this should be configurable on the registration message and this should be configurable on the
local mobility anchor. local mobility anchor.
5. For all other cases, the message MUST be considered as a request 5. For all other cases, the message MUST be considered as a request
for creating a new mobility session. for creating a new mobility session.
5.4.1.3. Mobile Node Interface Identifier Option not present in the 5.4.1.3. Mobile Node Interface Identifier Option not present in the
request request
+=====================================================================+ +=====================================================================+
skipping to change at page 30, line 34 skipping to change at page 30, line 34
1. The local mobility anchor MUST verify if there exists one and 1. The local mobility anchor MUST verify if there exists one and
only one Binding Cache entry with the mobile node identifier only one Binding Cache entry with the mobile node identifier
matching the identifier in the Mobile Node Identifier option matching the identifier in the Mobile Node Identifier option
present in the request. present in the request.
2. If there exists only one such entry (matching the MN-Identifier) 2. If there exists only one such entry (matching the MN-Identifier)
and the Handoff Indicator field in the Handoff Indicator option and the Handoff Indicator field in the Handoff Indicator option
present in the request is set to a value of 2 (Handoff between present in the request is set to a value of 2 (Handoff between
two different interfaces of the mobile node), the request MUST be two different interfaces of the mobile node), the request MUST be
considered as a request for updating that Binding Cache entry. considered as a request for updating that Binding Cache entry.
[PBU(HI) == 2] [PBU(HI) equals 2]
3. If there exists only one such entry (matching the MN-Identifier) 3. If there exists only one such entry (matching the MN-Identifier)
and the Handoff Indicator field in the Handoff Indicator option and the Handoff Indicator field in the Handoff Indicator option
present in the request is set to a value of 4 (Handoff state present in the request is set to a value of 4 (Handoff state
unknown), the local mobility anchor SHOULD wait till the existing unknown), the local mobility anchor SHOULD wait till the existing
Binding Cache entry is de-registered by the previously serving Binding Cache entry is de-registered by the previously serving
mobile access gateway, before the request can be considered as a mobile access gateway, before the request can be considered as a
request for updating that Binding Cache entry. However, if there request for updating that Binding Cache entry. However, if there
is no de-registration message that is received within is no de-registration message that is received within
MaxDelayBeforeNewBCEAssign amount of time, the local mobility MaxDelayBeforeNewBCEAssign amount of time, the local mobility
anchor upon accepting the request MUST consider the request as a anchor upon accepting the request MUST consider the request as a
request for updating that Binding Cache entry. The local request for creating a new mobility session. The local mobility
mobility anchor MAY also choose to create a new mobility session anchor MAY also choose to create a new mobility session and
and without waiting for a de-registration message and this should without waiting for a de-registration message and this should be
be configurable on the local mobility anchor. configurable on the local mobility anchor.
4. For all other cases, the message MUST be considered as a request 4. For all other cases, the message MUST be considered as a request
for creating a new mobility session. for creating a new mobility session.
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
skipping to change at page 39, line 30 skipping to change at page 39, line 30
to each mobile node. to each mobile node.
When stateless address autoconfiguration is supported on the access When stateless address autoconfiguration is supported on the access
link, the mobile node can generate one or more IPv6 addresses by link, the mobile node can generate one or more IPv6 addresses by
standard IPv6 mechanisms such as Stateless Autoconfiguration standard IPv6 mechanisms such as Stateless Autoconfiguration
specification [RFC-4862] or Privacy extension specification [RFC- specification [RFC-4862] or Privacy extension specification [RFC-
4941]. 4941].
When stateful address autoconfiguration is supported on the link, the When stateful address autoconfiguration is supported on the link, the
mobile node can obtain the address configuration from the DHCPv6 mobile node can obtain the address configuration from the DHCPv6
server by standard DHCPv6 mechanisms, as specified in DHCPv6 server located in the Proxy Mobile IPv6 domain, by standard DHCPv6
specification [RFC-3315]. mechanisms, as specified in DHCPv6 specification [RFC-3315]. The
obtained address will be from its respective home network prefix.
Section 6.11 specifies the details on how this configuration can be
achieved.
Additionally, other address configuration mechanisms specific to the Additionally, other address configuration mechanisms specific to the
access link between the mobile node and the mobile access gateway may access link between the mobile node and the mobile access gateway may
also be used for pushing the address configuration to the mobile also be used for pushing the address configuration to the mobile
node. This specification does not change the behavior of address node. This specification does not change the behavior of address
configuration mechanisms in any way. configuration mechanisms in any way.
6.5. Access Authentication & Mobile Node Identification 6.5. Access Authentication & Mobile Node Identification
When a mobile node attaches to an access link connected to the mobile When a mobile node attaches to an access link connected to the mobile
skipping to change at page 42, line 50 skipping to change at page 43, line 7
value is ALL_ZERO, then the local mobility anchor will do the value is ALL_ZERO, then the local mobility anchor will do the
prefix assignment. prefix assignment.
4. The Handoff Indicator option MUST be present in the Proxy 4. The Handoff Indicator option MUST be present in the Proxy
Binding Update message. The Handoff Indicator field in the Binding Update message. The Handoff Indicator field in the
Handoff Indicator option MUST be set to a value indicating the Handoff Indicator option MUST be set to a value indicating the
handoff hint. handoff hint.
* The Handoff Indicator field MUST be set to value 1 * The Handoff Indicator field MUST be set to value 1
(Attachment over a new interface), if the mobile access (Attachment over a new interface), if the mobile access
gateway predictably knows that the mobile node's current gateway determines (under the Handoff Indicator
attachment to the network over this interface is not as a considerations specified in this section) that the mobile
result of an handoff of an existing mobility session (over node's current attachment to the network over this interface
the same interface or through a different interface), but as is not as a result of an handoff of an existing mobility
a result of an attachment over a new interface. This session (over the same interface or through a different
essentially serves as a request to the local mobility anchor interface), but as a result of an attachment over a new
to create a new mobility session and not update any existing interface. This essentially serves as a request to the local
Binding Cache entry created for the same mobile node mobility anchor to create a new mobility session and not
connected to the Proxy Mobile IPv6 domain through a different update any existing Binding Cache entry created for the same
interface. mobile node connected to the Proxy Mobile IPv6 domain through
a different interface.
* The Handoff Indicator field MUST be set to value 2 (Handoff * The Handoff Indicator field MUST be set to value 2 (Handoff
between two different interfaces of the mobile node), if the between two different interfaces of the mobile node), if the
mobile access gateway definitively knows the mobile node's mobile access gateway definitively knows the mobile node's
current attachment is due to an handoff of an existing current attachment is due to an handoff of an existing
mobility session, between two different interfaces of the mobility session, between two different interfaces of the
mobile node. mobile node.
* The Handoff Indicator field MUST be set to value 3 (Handoff * The Handoff Indicator field MUST be set to value 3 (Handoff
between mobile access gateways for the same interface), if between mobile access gateways for the same interface), if
skipping to change at page 45, line 27 skipping to change at page 45, line 33
10. The Proxy Binding Update message MUST be constructed as 10. The Proxy Binding Update message MUST be constructed as
specified in Section 6.9.1.5. specified in Section 6.9.1.5.
11. If there is no existing Binding Update List entry for that 11. If there is no existing Binding Update List entry for that
mobile node, the mobile access gateway MUST create a Binding mobile node, the mobile access gateway MUST create a Binding
Update List entry for the mobile node upon sending the Proxy Update List entry for the mobile node upon sending the Proxy
Binding Update request. Binding Update request.
6.9.1.2. Receiving Binding Registration Reply 6.9.1.2. Receiving Binding Registration Reply
On receiving a Proxy Binding Acknowledgement message from the local On receiving a Proxy Binding Acknowledgement message (format
mobility anchor, the mobile access gateway MUST process the message specified in Section 8.2) from the local mobility anchor, the mobile
as specified below. access gateway MUST process the message as specified below.
1. The received Proxy Binding Acknowledgement message (a Binding 1. The received Proxy Binding Acknowledgement message (a Binding
Acknowledgement message with the 'P' flag set) MUST be Acknowledgement message with the 'P' flag set to value of 1)
authenticated as described in Section 4. When IPsec is used for MUST be authenticated as described in Section 4. When IPsec is
message authentication, the SPI in the IPsec header [RFC-4306] used for message authentication, the SPI in the IPsec header
of the received packet is needed for locating the security [RFC-4306] of the received packet is needed for locating the
association, for authenticating the Proxy Binding security association, for authenticating the Proxy Binding
Acknowledgement message . Acknowledgement message .
2. The mobile access gateway MUST observe the rules described in 2. 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. received Proxy Binding Acknowledgement message.
3. The mobile access gateway MUST apply the considerations 3. The mobile access gateway MUST apply the considerations
specified in Section 5.5 for processing the Sequence Number specified in Section 5.5 for processing the Sequence Number
field and the Timestamp option (if present), in the message. field and the Timestamp option (if present), in the message.
skipping to change at page 48, line 31 skipping to change at page 48, line 40
the currently assigned home network prefix. the currently assigned home network prefix.
3. The Handoff Indicator field in the Handoff Indicator option MUST 3. The Handoff Indicator field in the Handoff Indicator option MUST
be set to a value of 4 (Handoff state unknown). be set to a value of 4 (Handoff state unknown).
4. The value in the Link-local Address option (if the option was 4. The value in the Link-local Address option (if the option was
present in the initial registration message) MUST be set to the present in the initial registration message) MUST be set to the
link-local address of the mobile node's attached interface. link-local address of the mobile node's attached interface.
Either upon receipt of a Proxy Binding Acknowledgement message from Either upon receipt of a Proxy Binding Acknowledgement message from
the local mobility anchor or after INITIAL_BINDINGACK_TIMEOUT [RFC- the local mobility anchor or after INITIAL_BINDACK_TIMEOUT [RFC-3775]
3775] timeout waiting for the reply, the mobile access gateway MUST timeout waiting for the reply, the mobile access gateway MUST do the
do the following: following:
1. It MUST remove the Binding Update List entry for the mobile node 1. It MUST remove the Binding Update List entry for the mobile node
from its Binding Update List. from its Binding Update List.
2. It MUST withdraw the mobile node's home network prefix as the 2. It MUST withdraw the mobile node's home network prefix as the
hosted on-link prefix, by sending a Router Advertisement message hosted on-link prefix, by sending a Router Advertisement message
with the prefix lifetime value set to zero. with the prefix lifetime value set to zero.
3. It MUST remove the created routing state for tunneling the mobile 3. It MUST remove the created routing state for tunneling the mobile
node's traffic. node's traffic.
skipping to change at page 49, line 13 skipping to change at page 49, line 21
to-point link. to-point link.
6.9.1.5. Constructing the Proxy Binding Update Message 6.9.1.5. 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 MUST be set */ - BU /* P & A flags MUST be set to value 1 */
Mobility Options Mobility Options
- Mobile Node Identifier option (mandatory) - Mobile Node Identifier option (mandatory)
- Home Network Prefix option (mandatory) - Home Network Prefix option (mandatory)
- Handoff Indicator option (mandatory) - Handoff Indicator option (mandatory)
- Access Technology Type option (mandatory) - Access Technology Type option (mandatory)
- Timestamp option (optional) - Timestamp option (optional)
- Mobile Node Interface Identifier option (optional) - Mobile Node Interface Identifier option (optional)
- Link-local Address option (optional) - Link-local Address option (optional)
Figure 11: Proxy Binding Update message format Figure 11: Proxy Binding Update message format
o The Source Address field in the IPv6 header of the message MUST be o The Source Address field in the IPv6 header of the message MUST be
set to the address configured on the interface of the mobile set to the address configured on the interface of the mobile
access gateway. When there is no Alternate Care-of Address option access gateway. When there is no Alternate Care-of Address option
present in the request, this address will be considered as the present in the request, this address will be considered as the
Proxy-CoA address for this binding registration request. However, Proxy-CoA address for this binding registration request. However,
when there is Alternate Care-of Address option present in the when there is Alternate Care-of Address option present in the
request, this address will be not be the considered as the Proxy- request, this address will be not be considered as the Proxy-CoA
CoA address, but the address in the alternate Care-of Address address, but the address in the alternate Care-of Address option
option will be considered as the Proxy-CoA address. will be considered as the Proxy-CoA address.
o The Destination Address field in the IPv6 header of the message o The Destination Address field in the IPv6 header of the message
MUST be set to the local mobility anchor address. MUST be set to the local mobility anchor address.
o The Mobile Node Identifier option [RFC-4283] MUST be present. o The Mobile Node Identifier option [RFC-4283] MUST be present.
o The Home Network Prefix option MUST be present. o The Home Network Prefix option MUST be present.
o The Handoff Indicator option MUST be present. o The Handoff Indicator option MUST be present.
skipping to change at page 51, line 45 skipping to change at page 52, line 9
6.9.4. Retransmissions and Rate Limiting 6.9.4. 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 to the local limiting the binding registration requests that it sends to the local
mobility anchor. The Retransmission and the Rate Limiting rules are mobility anchor. The Retransmission and the Rate Limiting rules are
as specified in [RFC-3775]. However, the following considerations as specified in [RFC-3775]. However, the following considerations
MUST be applied. MUST be applied.
1. 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_BINDACK_TIMEOUT
[RFC-3775], for configuring the retransmission timer, as [RFC-3775], for configuring the retransmission timer, as
specified in Section 11.8 [RFC-3775]. However, the mobile access specified in Section 11.8 [RFC-3775]. However, the mobile access
gateway is not required to use a longer retransmission interval gateway is not required to use a longer retransmission interval
of InitialBindackTimeoutFirstReg as specified in [RFC-3775] for of InitialBindackTimeoutFirstReg as specified in [RFC-3775] for
the initial binding registration request. the initial binding registration request.
2. If the mobile access gateway fails to receive a valid matching 2. If the mobile access gateway fails to receive a valid matching
response for a registration or re-registration message within the response for a registration or re-registration message within the
retransmission interval, it SHOULD retransmit the message until a retransmission interval, it SHOULD retransmit the message until a
response is received. However, the mobile access gateway MUST response is received. However, the mobile access gateway MUST
skipping to change at page 55, line 44 skipping to change at page 56, line 13
Figure 13: Tunneled Packets from MAG to LMA Figure 13: 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 For supporting Stateful Address Configuration using DHCPv6, the o For supporting Stateful Address Configuration using DHCPv6, the
DHCPv6 relay agent [RFC-3315] service MUST be enabled on each of DHCPv6 relay agent [RFC-3315] service MUST be configured on each
the access links in the Proxy Mobile IPv6 domain. Further, as of the mobile access gateways in the Proxy Mobile IPv6 domain.
specified in Section 20 [RFC-3315], the relay agent should be Further, as specified in Section 20 [RFC-3315], the DHCPv6 relay
configured to use a list of destination addresses, which MAY agent should be configured to use a list of destination addresses,
include unicast addresses, the All_DHCP_Servers multicast address, which MAY include unicast addresses, the All_DHCP_Servers
or other addresses selected by the network administrator. 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.
o When a mobile node sends a DHCPv6 request message, the DHCP relay o When a mobile node sends a DHCPv6 request message, the DHCPv6
agent function on the access link will set the link-address field relay agent function on the access link will set the link-address
in the DHCP message to an address in the mobile node's home field in the DHCPv6 message to an address in the mobile node's
network prefix, so as to provide a prefix hint to the DHCP Server home network prefix. The address is generated as per [RFC-4862]
for the address pool selection. The DHCP server on receiving the by combining the mobile node's home network prefix (assigned by
the local mobility anchor for this mobility session) and its own
interface identifier on the access link shared with the mobile
node, so as to provide a prefix hint to the DHCPv6 Server for the
address pool selection. The DHCPv6 server on receiving the
request from the mobile node, will allocate an address from the request from the mobile node, will allocate an address from the
prefix pool present in the link-address field of the request. prefix pool pointed to by the link-address field of the request.
o Once the mobile node obtains an address and moves to a different o Once the mobile node obtains an address and moves to a different
link and sends a DHCP request, the DHCP relay agent on the new link and sends a DHCPv6 request, the DHCPv6 relay agent on the new
link will set the prefix hint in the DHCP messages to the mobile link will set the prefix hint in the DHCPv6 message to the mobile
node's home network prefix. The DHCP server will identify the node's home network prefix (assigned by the local mobility anchor
for this mobility session). The DHCPv6 server will identify the
client from the Client-DUID option and present in the request and client from the Client-DUID option and present in the request and
will allocate the same address as before. will allocate the same address as before.
o The DHCP based address configuration is not recommended for o The DHCPv6 based address configuration is not recommended for
deployments where the local mobility anchor and the mobile access deployments where the local mobility anchor and the mobile access
gateways are located in different administrative domains. For gateways are located in different administrative domains. For
this configuration to work, all the mobile access gateways in the this configuration to work, all the mobile access gateways in the
Proxy Mobile IPv6 domain should be able to ensure that the DHCP Proxy Mobile IPv6 domain should be able to ensure that the DHCPv6
requests from a given mobile node anchored on any of the access request messages from a given mobile node anchored on any of the
links in that domain, will always be handled by the same DHCP access links in that domain, will always be handled by the same
server. DHCPv6 server.
o The DHCP server should be configured to offer low address lease o The DHCPv6 server should be configured to offer low address lease
times. A lease time that is too large prevents the DHCP server times. A lease time that is too large prevents the DHCPv6 server
from reclaiming the address even after the local mobility anchor from reclaiming the address even after the local mobility anchor
deletes the mobile node's binding cache entry. deletes the mobile node's binding cache entry.
6.12. Home Network Prefix Renumbering 6.12. Home Network Prefix Renumbering
If the mobile node's home network prefix gets renumbered or becomes If the mobile node's home network prefix gets renumbered or becomes
invalid during the middle of a mobility session, the mobile access invalid during the middle of a mobility session, the mobile access
gateway MUST withdraw the prefix by sending a Router Advertisement on gateway MUST withdraw the prefix by sending a Router Advertisement on
the access link with zero prefix lifetime for the mobile node's home the access link with zero prefix lifetime for the mobile node's home
network prefix. Also, the local mobility anchor and the mobile network prefix. Also, the local mobility anchor and the mobile
skipping to change at page 61, line 46 skipping to change at page 62, line 26
. Mobility options . . Mobility options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Binding Acknowledgement message that is sent by a local mobility A Binding Acknowledgement message that is sent by a local mobility
anchor to a mobile access gateway is referred to as the "Proxy anchor to a mobile access gateway is referred to as the "Proxy
Binding Acknowledgement" message. A new flag (P) is included in the Binding Acknowledgement" message. A new flag (P) is included in the
Binding Acknowledgement message. The rest of the Binding Binding Acknowledgement message. The rest of the Binding
Acknowledgement message format remains the same as defined in [RFC- Acknowledgement message format remains the same as defined in [RFC-
3775] and with the additional (R) and (M) flags as specified in [RFC- 3775] and with the additional (R) flag as specified in [RFC-3963].
3963] and [RFC-4140] respectively.
Proxy Registration Flag (P) Proxy Registration Flag (P)
A new flag (P) is included in the Binding Acknowledgement message A new flag (P) is included in the Binding Acknowledgement message
to indicate that the local mobility anchor that processed the to indicate that the local mobility anchor that processed the
corresponding Proxy Binding Update message supports proxy corresponding Proxy Binding Update message supports proxy
registrations. The flag is set only if the corresponding Proxy registrations. The flag is set to value of 1 only if the
Binding Update had the Proxy Registration Flag (P) set to value of corresponding Proxy Binding Update had the Proxy Registration Flag
1. (P) set to value of 1.
Mobility Options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2 [RFC- and format of defined options are described in Section 6.2 [RFC-
3775]. The mobile access gateway MUST ignore and skip any options 3775]. The mobile access gateway MUST ignore and skip any options
which it does not understand. which it does not understand.
skipping to change at page 72, line 30 skipping to change at page 72, line 30
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 value of 0, indicating
the mobile access gateway MUST reverse tunnel all the traffic to that the mobile access gateway MUST reverse tunnel all the traffic
the mobile node's local mobility anchor. to 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 value of 1, the mobile
gateway MUST route the traffic locally. access 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.
10. IANA Considerations 10. IANA Considerations
This document defines six new Mobility Header options, the Home This document defines six new Mobility Header options, the Home
Network Prefix option, Handoff Indicator option, Access Technology Network Prefix option, Handoff Indicator option, Access Technology
Type option, Interface Identifier option, Link-local Address option Type option, Interface Identifier option, Link-local Address option
and Timestamp option. These options are described in Section 8. The and Timestamp option. These options are described in Section 8. The
Type value for these options needs to be assigned from the same Type value for these options needs to be assigned from the same
numbering space as allocated for the other mobility options, as numbering space as allocated for the other mobility options, as
defined in [RFC-3775]. defined in [RFC-3775].
The Handoff Indicator option defined in Section 8.4 of this document
introduces a new Handoff Indicator (HI) numbering space, where the
values from 0 to 5 have been reserved by this document. Approval of
new Handoff Indicator type values are to be made through IANA Expert
Review.
The Access Technology Type option defined in Section 8.5 of this The Access Technology Type option defined in Section 8.5 of this
document introduces a new Access Technology type numbering space, document introduces a new Access Technology type (ATT) numbering
where the values from 0 to 5 have been reserved by this document. space, where the values from 0 to 5 have been reserved by this
Approval of new Access Technology type numbers are to be made through document. Approval of new Access Technology type values are to be
IANA Expert Review. 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.9. The status values MUST be assigned from as described in Section 8.9. 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 74, line 18 skipping to change at page 74, line 23
definitively attached to the mobile access gateway that sent the definitively attached to the mobile access gateway that sent the
proxy binding registration request. This may be accomplished by proxy binding registration request. This may be accomplished by
contacting a trusted entity which is able to track the mobile node's contacting a trusted entity which is able to track the mobile node's
current point of attachment. However, the specific details of the current point of attachment. However, the specific details of the
actual mechanisms for achieving this is outside the scope of this actual mechanisms for achieving this is outside the scope of this
document. document.
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, Jari
their thorough review of this document. Arkko and Elwyn Davies for 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, Jean-Michel Combes, Jun Awano, John Zhao, Jong-
Jong-Hyouk Lee, Jonne Soininen, Jouni Korhonen, Kalin Getov, Kilian Hyouk Lee, Jonne Soininen, Jouni Korhonen, Kalin Getov, Kilian
Weniger, Marco Liebsch, Mohamed Khalil, Nishida Katsutoshi, Phil Weniger, Marco Liebsch, Mohamed Khalil, Nishida Katsutoshi, Phil
Roberts, Ryuji Wakikawa, Sangjin Jeong, Suresh Krishnan, Ved Kafle, Roberts, Ryuji Wakikawa, Sangjin Jeong, Suresh Krishnan, Uri
Vidya Narayanan, Youn-Hee Han and many others for their passionate Blumenthal, Ved Kafle, Vidya Narayanan, Youn-Hee Han and many others
discussions in the working group mailing list on the topic of for their passionate discussions in the working group mailing list on
localized mobility management solutions. These discussions the topic of localized mobility management solutions. These
stimulated much of the thinking and shaped the draft to the current discussions stimulated much of the thinking and shaped the draft to
form. We acknowledge that ! the current 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 75, line 43 skipping to change at page 75, line 50
2005. 2005.
[RFC-4140] Soliman, H., Castelluccia, C., El Malki, K., and L. [RFC-4140] Soliman, H., Castelluccia, C., El Malki, K., and L.
Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC
4140, August 2005. 4140, August 2005.
[RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2) [RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005. Protocol", RFC 4306, December 2005.
[RFC-4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 [RFC-4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 2030, October 1996. for IPv4, IPv6 and OSI", RFC 4330, October 1996.
[RFC-4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, [RFC-4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney,
"Chargeable User Identity", RFC 4372, January 2006. "Chargeable User Identity", RFC 4372, January 2006.
[RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, [RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta,
G., Liebsch, M., "Problem Statement for Network-based Localized G., Liebsch, M., "Problem Statement for Network-based Localized
Mobility Management", September 2006. Mobility Management", September 2006.
[RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, [RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta,
G., Liebsch, M., "Goals for Network-based Localized Mobility G., Liebsch, M., "Goals for Network-based Localized Mobility
 End of changes. 65 change blocks. 
139 lines changed or deleted 184 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/