draft-ietf-netlmm-proxymip6-13.txt   draft-ietf-netlmm-proxymip6-14.txt 
NETLMM WG S. Gundavelli (Editor) NETLMM WG S. Gundavelli (Editor)
Internet-Draft K. Leung Internet-Draft K. Leung
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: November 13, 2008 V. Devarapalli Expires: November 14, 2008 V. Devarapalli
Wichorus Wichorus
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
B. Patil B. Patil
Nokia Siemens Networks Nokia Siemens Networks
May 12, 2008 May 13, 2008
Proxy Mobile IPv6 Proxy Mobile IPv6
draft-ietf-netlmm-proxymip6-13.txt draft-ietf-netlmm-proxymip6-14.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 13, 2008. This Internet-Draft will expire on November 14, 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 3, line 6 skipping to change at page 3, line 6
6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 41 6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 41
6.3. Supported Access Link Types . . . . . . . . . . . . . . . 42 6.3. Supported Access Link Types . . . . . . . . . . . . . . . 42
6.4. Supported Address Configuration Modes . . . . . . . . . . 42 6.4. Supported Address Configuration Modes . . . . . . . . . . 42
6.5. Access Authentication & Mobile Node Identification . . . . 43 6.5. Access Authentication & Mobile Node Identification . . . . 43
6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 43 6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 43
6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 44 6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 44
6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 44 6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 44
6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 45 6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 45
6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 45 6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 45
6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 54 6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 54
6.9.3. Default-Router . . . . . . . . . . . . . . . . . . . . 54 6.9.3. Default-Router . . . . . . . . . . . . . . . . . . . . 55
6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 55 6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 55
6.9.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . 56 6.9.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . 56
6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 57 6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 57
6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 57 6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 57
6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 57 6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 58
6.10.3. Local Routing . . . . . . . . . . . . . . . . . . . . 58 6.10.3. Local Routing . . . . . . . . . . . . . . . . . . . . 59
6.10.4. Tunnel Management . . . . . . . . . . . . . . . . . . 59 6.10.4. Tunnel Management . . . . . . . . . . . . . . . . . . 59
6.10.5. Forwarding Rules . . . . . . . . . . . . . . . . . . . 59 6.10.5. Forwarding Rules . . . . . . . . . . . . . . . . . . . 59
6.11. Supporting DHCPv6 based Address Configuration on the 6.11. Supporting DHCPv6 based Address Configuration on the
Access Link . . . . . . . . . . . . . . . . . . . . . . . 61 Access Link . . . . . . . . . . . . . . . . . . . . . . . 61
6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 62 6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 62
6.13. Mobile Node Detachment Detection and Resource Cleanup . . 62 6.13. Mobile Node Detachment Detection and Resource Cleanup . . 63
6.14. Allowing network access to other IPv6 nodes . . . . . . . 63 6.14. Allowing network access to other IPv6 nodes . . . . . . . 63
7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 64 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 64
7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 64 7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 64
7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 65 7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 65
8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 65 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 65
8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 66 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 66
8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 67 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 67
8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 69 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 69
8.4. Handoff Indicator Option . . . . . . . . . . . . . . . . . 70 8.4. Handoff Indicator Option . . . . . . . . . . . . . . . . . 70
8.5. Access Technology Type Option . . . . . . . . . . . . . . 71 8.5. Access Technology Type Option . . . . . . . . . . . . . . 71
skipping to change at page 3, line 44 skipping to change at page 3, line 44
9.1. Local Mobility Anchor - Configuration Variables . . . . . 77 9.1. Local Mobility Anchor - Configuration Variables . . . . . 77
9.2. Mobile Access Gateway - Configuration Variables . . . . . 78 9.2. Mobile Access Gateway - Configuration Variables . . . . . 78
9.3. Proxy Mobile IPv6 Domain - Configuration Variables . . . . 79 9.3. Proxy Mobile IPv6 Domain - Configuration Variables . . . . 79
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
11. Security Considerations . . . . . . . . . . . . . . . . . . . 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 80
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 81 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 81
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81
13.1. Normative References . . . . . . . . . . . . . . . . . . . 81 13.1. Normative References . . . . . . . . . . . . . . . . . . . 81
13.2. Informative References . . . . . . . . . . . . . . . . . . 82 13.2. Informative References . . . . . . . . . . . . . . . . . . 82
Appendix A. Proxy Mobile IPv6 interactions with AAA Appendix A. Proxy Mobile IPv6 interactions with AAA
Infrastructure . . . . . . . . . . . . . . . . . . . 83 Infrastructure . . . . . . . . . . . . . . . . . . . 84
Appendix B. Routing State . . . . . . . . . . . . . . . . . . . . 84 Appendix B. Routing State . . . . . . . . . . . . . . . . . . . . 84
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 85
Intellectual Property and Copyright Statements . . . . . . . . . . 87 Intellectual Property and Copyright Statements . . . . . . . . . . 87
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 18, line 27 skipping to change at page 18, line 27
to value 0 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 link-layer identifier of the mobile node's connected interface o The link-layer 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 Link-layer Identifier option, present in the received Mobile Node Link-layer 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, this variable length field MUST be set to two
(octets) and MUST be initialized to a value of ALL_ZERO.
o The link-local address of the mobile access gateway on the point- o The link-local address of the mobile access gateway on the point-
to-point link shared with the mobile node. This is generated by to-point link shared with the mobile node. This is generated by
the local mobility anchor after accepting the initial Proxy the local mobility anchor after accepting the initial Proxy
Binding Update request. Binding Update request.
o List of IPv6 home network prefixes assigned to the mobile node's o List of IPv6 home network prefixes assigned to the mobile node's
connected interface. The home network prefix(es) may have been connected interface. The home network prefix(es) may have been
statically configured in the mobile node's policy profile, or, statically configured in the mobile node's policy profile, or,
they may have been dynamically allocated by the local mobility they may have been dynamically allocated by the local mobility
skipping to change at page 28, line 29 skipping to change at page 28, line 29
5.4.1. Binding Cache entry lookup considerations 5.4.1. Binding Cache entry lookup considerations
There can be multiple Binding Cache entries for a given mobile node. There can be multiple Binding Cache entries for a given mobile node.
When doing a lookup for a mobile node's Binding Cache entry for When doing a lookup for a mobile node's Binding Cache entry for
processing a received Proxy Binding Update request message, the local processing a received Proxy Binding Update request message, the local
mobility anchor MUST apply the following multihoming considerations mobility anchor MUST apply the following multihoming considerations
(in the below specified order, starting with Section 5.4.1.1). These (in the below specified order, starting with Section 5.4.1.1). These
rules are chained with the processing rules specified in Section 5.3. rules are chained with the processing rules specified in Section 5.3.
5.4.1.1. Mobile Node Link-layer Identifier Option present in the 5.4.1.1. Home Network Prefix Option (NON_ZERO Value) present in the
request
+=====================================================================+
| Registration/De-Registration Message |
+=====================================================================+
| HNP Option(s) |
+=====================================================================+
| ATT |
+=====================================================================+
| MN-LL-Identifier Option Present (NON_ZERO Value) |
+=====================================================================+
| HI |
+==================================+==================================+
| BCE Lookup Keys: (MN-Identifier + ATT + MN-LL-Identifier) |
+=====================================================================+
Figure 7: BCE Lookup using Link-layer Identifier
1. The local mobility anchor MUST verify if there is an existing
Binding Cache entry, with the mobile node identifier matching the
identifier in the received Mobile Node Identifier option, access
technology type matching the value in the received Access
Technology Type option and the link-layer identifier value
matching the identifier in the received Mobile Node Link-layer
Identifier option. [BCE(MN-Identifier, ATT, MN-LL-Identifier)
equals PBU(MN-Identifier, ATT, MN-LL-Identifier)]
2. If there exists a Binding Cache entry (matching MN-Identifier,
ATT and MN-LL-Identifier), the request MUST be considered as a
request for updating that Binding Cache entry (mobility session).
3. If there does not exist a Binding Cache entry (matching MN-
Identifier, ATT and MN-LL-Identifier) and the Handoff Indicator
field in the Handoff Indicator option present in the request is
set to a value of 2 (Handoff between two different interfaces of
the mobile node). The local mobility anchor MUST apply the
following additional considerations. [PBU(HI) equals 2]
* The local mobility anchor MUST verify if there exists one and
only one Binding Cache entry with the mobile node identifier
matching the identifier in the Mobile Node Identifier option
present in the request and for any link-layer identifier
value. If there exists only one such entry (matching the MN-
Identifier), the request MUST be considered as a request for
updating that Binding Cache entry. [BCE(MN-Identifier) equals
PBU(MN-Identifier)]
4. If there does not exist a Binding Cache entry (matching MN-
Identifier, ATT and MN-LL-Identifier) and if the Handoff
Indicator field in the Handoff Indicator option present in the
request is set to a value of 4 (Handoff state unknown), the local
mobility anchor MUST apply the following additional
considerations.
* The local mobility anchor MUST verify if there exists one and
only one Binding Cache entry with the mobile node identifier
matching the identifier in the Mobile Node Identifier option
present in the request and for any link-layer identifier
value. If there exists only one such entry (matching the MN-
Identifier), the local mobility anchor SHOULD wait till the
existing Binding Cache entry is de-registered by the
previously serving mobile access gateway, before the request
can be considered as a request for updating that Binding Cache
entry. However, if there is no de-registration message that
is received within MaxDelayBeforeNewBCEAssign amount of time,
the local mobility anchor upon accepting the request MUST
consider the request as a request for creating a new mobility
session. The local mobility anchor MAY also choose to create
a new mobility session and without waiting for a de-
registration message and this should be configurable on the
local mobility anchor.
5. For all other cases, the message MUST be considered as a request
for creating a new mobility session.
5.4.1.2. Home Network Prefix Option (NON_ZERO Value) present in the
request request
+=====================================================================+ +=====================================================================+
| Registration/De-Registration Message | | Registration/De-Registration Message |
+=====================================================================+ +=====================================================================+
| At least one HNP Option with NON_ZERO Value | | At least one HNP Option with NON_ZERO Value |
+=====================================================================+ +=====================================================================+
| ATT | | ATT |
+=====================================================================+ +=====================================================================+
| MN-LL-Identifier Opt Not Present | | MN-LL-Identifier Opt Present | MN-LL-Identifier Opt Not Present |
+=====================================================================+ +=====================================================================+
| HI | | HI |
+==================================+==================================+ +==================================+==================================+
| BCE Lookup Key: Any of the Home Network Prefixes from the request | | BCE Lookup Key: Any of the Home Network Prefixes from the request |
+=====================================================================+ +=====================================================================+
Figure 8: BCE lookup using home network prefix Figure 7: BCE lookup using home network prefix
If there is at least one Home Network Prefix option present in the If there is at least one Home Network Prefix option present in the
request with NON_ZERO prefix value, the following considerations MUST request with NON_ZERO prefix value, the following considerations MUST
be applied. If there are more than instances of the Home Network be applied. If there are more than one instances of the Home Network
Prefix option, any one of the Home Network Prefix options present in Prefix option, any one of the Home Network Prefix options present in
the request (with NON_ZERO prefix value) can be used for locating the the request (with NON_ZERO prefix value) can be used for locating the
Binding Cache entry. Binding Cache entry.
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 one of its home network prefixes Binding Cache entry with one of its home network prefixes
matching the prefix value in one of the Home Network Prefix matching the prefix value in one of the Home Network Prefix
options of the received Proxy Binding Update request. [BCE(HNP) options of the received Proxy Binding Update request. [BCE(HNP)
equals PBU(HNP)] equals PBU(HNP)]
2. If there does not exist a Binding Cache entry (with one its home 2. If there does not exist a Binding Cache entry (with one of its
network prefixes in the Binding Cache entry matching the prefix home network prefixes in the Binding Cache entry matching the
value in one of the Home Network Prefix options of the received prefix value in one of the Home Network Prefix options of the
Proxy Binding Update request), the request MUST be considered as received Proxy Binding Update request), the request MUST be
a request for creating a new mobility session. [BCE(HNP) not considered as a request for creating a new mobility session.
equals PBU(HNP)] [BCE(HNP) not equals PBU(HNP)]
3. If there exists a Binding Cache entry (with one of its home 3. If there exists a Binding Cache entry (with one of its home
network prefixes in the Binding Cache entry matching the prefix network prefixes in the Binding Cache entry matching the prefix
value in one the Home Network Prefix options of the received value in one of the Home Network Prefix options of the received
Proxy Binding Update request) but if the mobile node identifier Proxy Binding Update request) but if the mobile node identifier
in the entry does not match the mobile node identifier in the in the entry does not match the mobile node identifier in the
Mobile Node Identifier option of the received Proxy Binding Mobile Node Identifier option of the received Proxy Binding
Update request, the local mobility anchor MUST reject the request Update request, the local mobility anchor MUST reject the request
with the Status field value set to 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 one or more of the requesting home network authorized for one or more of the requesting home network
prefixes). [BCE(MN-Identifier) not equals PBU(MN-Identifier)] prefixes). [BCE(MN-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
one of its home network prefixes in the Binding Cache entry one of its home network prefixes in the Binding Cache entry
matching the prefix value in one the Home Network Prefix options matching the prefix value in one of the Home Network Prefix
of the received Proxy Binding Update request), but if all the options of the received Proxy Binding Update request), but if all
prefixes in the request do not match all the prefixes in the the prefixes in the request do not match all the prefixes in the
Binding Cache entry, or if they do not match in count, then the Binding Cache entry, or if they do not match in count, then the
local mobility anchor MUST reject the request with the Status local mobility anchor MUST reject the request with the Status
field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile field value set to BCE_PBU_PREFIX_SET_DO_NOT_MATCH (all the home
node is not authorized for the requesting home network prefix). network prefixes listed in the BCE do not match all the prefixes
[BCE(HNP1, HNP2, .. HNPn) not equals PBU(HNP1, HNP2, ..HNPn)] OR in the received PBU). [BCE(HNP1, HNP2, .. HNPn) not equals
[BCE(Count(HNP))] not equals PBU(Count(HNP))] PBU(HNP1, HNP2, ..HNPn)] OR [BCE(Count(HNP))] not equals
PBU(Count(HNP))]
5. If there exists a Binding Cache entry (matching MN-Identifier and 5. If there exists a Binding Cache entry (matching MN-Identifier and
all the home network prefixes in the Binding Cache entry matching all the home network prefixes in the Binding Cache entry matching
all the home network prefixes in the received Proxy Binding all the home network prefixes in the received Proxy Binding
Update request) and if any one or more of these below stated Update request) and if any one or more of these below stated
conditions match, the request MUST be considered as a request for conditions match, the request MUST be considered as a request for
updating that Binding Cache entry. [BCE(MN-Identifier) equals updating that Binding Cache entry. [BCE(MN-Identifier) equals
PBU(MN-Identifier)] AND [BCE(HNP1, HNP2, .. HNPn) equals PBU(MN-Identifier)] AND [BCE(HNP1, HNP2, .. HNPn) equals
PBU(HNP1, HNP2, ..HNPn)] PBU(HNP1, HNP2, ..HNPn)]
* 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). [PBU(HI) equals two different interfaces of the mobile node). [PBU(HI) equals
2] 2]
* The access technology type field in the Access Technology Type * If there is no Mobile Node Link-layer Identifier option
option present in the request matches the access technology present in the request, the link-layer identifier value in the
type in the Binding Cache entry and if the Handoff Indicator Binding Cache entry is set to ALL_ZERO, the access technology
field in the Handoff Indicator option present in the request type field in the Access Technology Type option present in the
is set to a value of 3 (Handoff between mobile access gateways request matches the access technology type in the Binding
for the same interface). Cache entry and if the Handoff Indicator field in the Handoff
Indicator option present in the request is set to a value of 3
(Handoff between mobile access gateways for the same
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) equals PBU(Proxy-CoA, ATT)]. [BCE(Proxy-CoA, ATT) equals PBU(Proxy-CoA, ATT)].
6. For all other cases, the message MUST be considered as a request 6. 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 Link-layer Identifier Option present in the
request
+=====================================================================+
| Registration/De-Registration Message |
+=====================================================================+
| HNP option with ALL_ZERO Value |
+=====================================================================+
| ATT |
+=====================================================================+
| MN-LL-Identifier Option Present (NON_ZERO Value) |
+=====================================================================+
| HI |
+==================================+==================================+
| BCE Lookup Keys: (MN-Identifier + ATT + MN-LL-Identifier) |
+=====================================================================+
Figure 8: BCE Lookup using Link-layer Identifier
1. The local mobility anchor MUST verify if there is an existing
Binding Cache entry, with the mobile node identifier matching the
identifier in the received Mobile Node Identifier option, access
technology type matching the value in the received Access
Technology Type option and the link-layer identifier value
matching the identifier in the received Mobile Node Link-layer
Identifier option. [BCE(MN-Identifier, ATT, MN-LL-Identifier)
equals PBU(MN-Identifier, ATT, MN-LL-Identifier)]
2. If there exists a Binding Cache entry (matching MN-Identifier,
ATT and MN-LL-Identifier), the request MUST be considered as a
request for updating that Binding Cache entry.
3. If there does not exist a Binding Cache entry (matching MN-
Identifier, ATT and MN-LL-Identifier) and the Handoff Indicator
field in the Handoff Indicator option present in the request is
set to a value of 2 (Handoff between two different interfaces of
the mobile node). The local mobility anchor MUST apply the
following additional considerations. [PBU(HI) equals 2]
* The local mobility anchor MUST verify if there exists one and
only one Binding Cache entry with the mobile node identifier
matching the identifier in the Mobile Node Identifier option
present in the request and for any link-layer identifier
value. If there exists only one such entry (matching the MN-
Identifier), the request MUST be considered as a request for
updating that Binding Cache entry. [BCE(MN-Identifier) equals
PBU(MN-Identifier)]
4. If there does not exist a Binding Cache entry (matching MN-
Identifier, ATT and MN-LL-Identifier) and if the Handoff
Indicator field in the Handoff Indicator option present in the
request is set to a value of 4 (Handoff state unknown), the local
mobility anchor MUST apply the following additional
considerations.
* The local mobility anchor MUST verify if there exists one and
only one Binding Cache entry with the mobile node identifier
matching the identifier in the Mobile Node Identifier option
present in the request and for any link-layer identifier
value. If there exists only one such entry (matching the MN-
Identifier), the local mobility anchor SHOULD wait till the
existing Binding Cache entry is de-registered by the
previously serving mobile access gateway, before the request
can be considered as a request for updating that Binding Cache
entry. However, if there is no de-registration message that
is received within MaxDelayBeforeNewBCEAssign amount of time,
the local mobility anchor upon accepting the request MUST
consider the request as a request for creating a new mobility
session. The local mobility anchor MAY also choose to create
a new mobility session and without waiting for a de-
registration message and this should be configurable on the
local mobility anchor.
5. For all other cases, the message MUST be considered as a request
for creating a new mobility session.
5.4.1.3. Mobile Node Link-layer Identifier Option not present in the 5.4.1.3. Mobile Node Link-layer Identifier Option not present in the
request request
+=====================================================================+ +=====================================================================+
| Registration/De-Registration Message | | Registration/De-Registration Message |
+=====================================================================+ +=====================================================================+
| HNP option with ALL_ZERO Value | | HNP option with ALL_ZERO Value |
+=====================================================================+ +=====================================================================+
| ATT | | ATT |
+=====================================================================+ +=====================================================================+
skipping to change at page 40, line 43 skipping to change at page 40, line 46
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 link-layer identifier of the mobile node's connected o The link-layer identifier of the mobile node's connected
interface. This can be acquired from the received Router interface. This can be acquired from the received Router
Solicitation messages from the mobile node or during the mobile Solicitation messages from the mobile node or during the mobile
node's attachment to the access network. This is typically a node's attachment to the access network. This is typically a
link-layer identifier conveyed by the mobile node; however, the link-layer identifier conveyed by the mobile node; however, the
specific details on how that is conveyed is out of scope for this specific details on how that is conveyed is out of scope for this
specification. If this identifier is not available, this variable specification. If this identifier is not available, this variable
length field MUST be set to some default size and MUST be length field MUST be set to two (octets) and MUST be initialized
initialized to a value of ALL_ZERO. to a value of ALL_ZERO.
o List of IPv6 home network prefixes assigned to the mobile node's o List of IPv6 home network prefixes assigned to the mobile node's
connected interface. The home network prefix(es) may have been connected interface. The home network prefix(es) may have been
statically configured in the mobile node's policy profile, or, may statically configured in the mobile node's policy profile, or, may
have been dynamically allocated by the local mobility anchor. have been dynamically allocated by the local mobility anchor.
Each of these prefix entries will also includes the corresponding Each of these prefix entries will also includes the corresponding
prefix length. prefix length.
o The Link-local address of the mobile access gateway on the access o The Link-local address of the mobile access gateway on the access
link shared with the mobile node. link shared with the mobile node.
skipping to change at page 48, line 39 skipping to change at page 48, line 42
gateway. gateway.
9. The Link-local Address option MAY be present in the Proxy 9. The Link-local Address option MAY be present in the Proxy
Binding Update message. Considerations from Section 6.8 MUST be Binding Update message. Considerations from Section 6.8 MUST be
applied when using the link-local address option. applied when using the link-local address option.
* When querying the local mobility anchor for the link-local * When querying the local mobility anchor for the link-local
address that it should use on the point-to-point link shared address that it should use on the point-to-point link shared
with the mobile node, this option MUST be set to ALL_ZERO. with the mobile node, this option MUST be set to ALL_ZERO.
This essentially serves as a request to the local mobility This essentially serves as a request to the local mobility
anchor to return the link-local address of the mobile access anchor to provide the link-local address that it can use on
gateway stored in the binding cache entry associated with the access link shared with the mobile node.
this mobility session.
* When uploading the link-local address to the local mobility * When uploading the link-local address to the local mobility
anchor, the value in the option MUST be set to the link-local anchor, the value in the option MUST be set to the link-local
address that is configured on the point-to-point link shared address that is configured on the point-to-point link shared
with the mobile node. This is allowed only during an initial with the mobile node. This is allowed only during an initial
mobile node's attachment. mobile node's attachment.
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.
skipping to change at page 51, line 11 skipping to change at page 51, line 13
(i.e., if the binding is rejected), the mobile access gateway (i.e., if the binding is rejected), the mobile access gateway
MUST NOT advertise the mobile node's home network prefix(es) in MUST NOT advertise the mobile node's home network prefix(es) in
the Router Advertisement messages sent on that access link and the Router Advertisement messages sent on that access link and
MUST deny the mobility service to the mobile node by not MUST deny the mobility service to the mobile node by not
forwarding any packets received from the mobile node using an forwarding any packets received from the mobile node using an
address from the home network prefix(es). It MAY also tear down address from the home network prefix(es). It MAY also tear down
the point-to-point link shared with the mobile node. the point-to-point link shared with the mobile node.
12. If the received Proxy Binding Acknowledgement message has the 12. If the received Proxy Binding Acknowledgement message has the
Status field value set to 0 (Proxy Binding Update accepted), the Status field value set to 0 (Proxy Binding Update accepted), the
mobile access gateway MUST setup the routing state, as explained mobile access gateway MUST establish a bi-directional tunnel to
in section 6.10, and MUST also update the Binding Update List the local mobility anchor (if there is no existing bi-
entry for reflecting the accepted binding registration status. directional tunnel to that local mobility anchor).
It MUST also advertise the mobile node's home network prefix(es) Considerations from Section 5.6.1 MUST be applied for managing
as the hosted on-link prefixes, by including them in the Router the dynamically created bi-directional tunnel.
Advertisement messages that it sends on that access link.
13. If the received Proxy Binding Acknowledgement message has the 13. The mobile access gateway MUST set up the route for forwarding
the packets received from the mobile node using address(es) from
its home network prefix(es) through the bi-directional set up
for that mobile node. The created tunnel and the routing state
MUST result in the forwarding behavior on the mobile access
gateway as specified in Section 6.10.5.
14. The mobile access gateway MUST also update the Binding Update
List entry for reflecting the accepted binding registration
values. It MUST also advertise the mobile node's home network
prefix(es) as the hosted on-link prefixes, by including them in
the Router Advertisement messages that it sends on that access
link.
15. If the received Proxy Binding Acknowledgement message has the
address in the Link-local Address option set to a NON_ZERO address in the Link-local Address option set to a NON_ZERO
value, the mobile access gateway MUST configure that link-local value, the mobile access gateway MUST configure that link-local
address on that point-to-point link and MUST NOT configure any address on that point-to-point link and MUST NOT configure any
other link-local address on that point-to-point link. This will other link-local address on that point-to-point link. This will
avoid any link-local address collisions with the mobile node on avoid any link-local address collisions with the mobile node on
that access link. that access link.
6.9.1.3. Extending Binding Lifetime 6.9.1.3. Extending Binding Lifetime
1. For extending the lifetime of a currently registered mobile node 1. For extending the lifetime of a currently registered mobile node
skipping to change at page 54, line 35 skipping to change at page 54, line 44
binding registration process for whatever reason, the mobile binding registration process for whatever reason, 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(es) in the Router Advertisement messages that it sends on prefix(es) in the Router Advertisement messages that it sends on
the access link. However, it MAY choose to advertise a local the access link. However, it MAY choose to advertise a local
visited network prefix(es) to enable the mobile node for regular visited network prefix(es) to enable the mobile node for regular
IPv6 access. IPv6 access.
3. The mobile access gateway SHOULD add the MTU option, as specified 3. The mobile access gateway SHOULD add the MTU option, as specified
in [RFC-4861], to the Router Advertisement messages that it sends in [RFC-4861], to the Router Advertisement messages that it sends
on the access link. This will ensure the mobile node on the link on the access link. This will ensure the mobile node on the link
uses the advertised MTU value. The MTU value MUST reflect the uses the advertised MTU value. The MTU value SHOULD reflect the
tunnel MTU for the bi-directional tunnel between the mobile tunnel MTU for the bi-directional tunnel between the mobile
access gateway and the local mobility anchor. Considerations access gateway and the local mobility anchor. Considerations
from Section 6.9.5 SHOULD be applied for determining the tunnel from Section 6.9.5 SHOULD be applied for determining the tunnel
MTU value. MTU value.
6.9.3. Default-Router 6.9.3. Default-Router
In Proxy Mobile IPv6, the mobile access gateway is the IPv6 default- In Proxy Mobile IPv6, the mobile access gateway is the IPv6 default-
router for the mobile node on the access link, as it is the entity router for the mobile node on the access link, as it is the entity
that sends the Router Advertisements on the access link. However, as that sends the Router Advertisements on the access link. However, as
skipping to change at page 57, line 10 skipping to change at page 57, line 19
o If there is an administratively configured PMTU value for the path o If there is an administratively configured PMTU value for the path
between the local mobility anchor and the mobile access gateway, between the local mobility anchor and the mobile access gateway,
the dynamic discovery of PMTU is not required. the dynamic discovery of PMTU is not required.
o The IPv6 tunnel MTU for the established tunnel between the local o The IPv6 tunnel MTU for the established tunnel between the local
mobility anchor and the mobile access gateway can be computed mobility anchor and the mobile access gateway can be computed
based on this Path MTU value, as specified in Section 6.7 of [RFC- based on this Path MTU value, as specified in Section 6.7 of [RFC-
2473]. 2473].
o The mobile access gateway MAY use this determined tunnel Path MTU o The mobile access gateway SHOULD use this determined tunnel Path
value (for the tunnel established with the mobile node's local MTU value (for the tunnel established with the mobile node's local
mobility anchor) as the MTU value in the MTU option that it sends mobility anchor) as the MTU value in the MTU option that it sends
in the Router Advertisements on the access link shared with the in the Router Advertisements on the access link shared with the
mobile node. mobile node.
6.10. Routing Considerations 6.10. Routing Considerations
This section describes how the mobile access gateway handles the This section describes how the mobile access gateway handles the
traffic to/from the mobile node that is attached to one of its access traffic to/from the mobile node that is attached to one of its access
interfaces. interfaces.
skipping to change at page 61, line 45 skipping to change at page 62, line 5
corresponding prefixes are allocated. It just views these corresponding prefixes are allocated. It just views these
prefixes as hosted prefixes on a given link in that domain. Based prefixes as hosted prefixes on a given link in that domain. Based
on the prefix value present in the link-address option of the on the prefix value present in the link-address option of the
received DHCPv6 request, the DHCPv6 server assigns addresses from received DHCPv6 request, the DHCPv6 server assigns addresses from
all of the prefixes associated with that link, all of the prefixes associated with that link,
o When a mobile node sends a DHCPv6 request message, the DHCPv6 o When a mobile node sends a DHCPv6 request message, the DHCPv6
relay agent function on the mobile access gateway will set the relay agent function on the mobile access gateway will set the
link-address field in the DHCPv6 message to an address in the link-address field in the DHCPv6 message to an address in the
mobile node's home network prefix (any one of the mobile node's mobile node's home network prefix (any one of the mobile node's
home network prefix assigned to that mobile node's attached home network prefixes assigned to that mobile node's attached
interface). The address is generated as per [RFC-4862] by interface). The address is generated as per [RFC-4862] by
combining that mobile node's home network prefix and its own combining that mobile node's home network prefix and its own
interface identifier on the access link shared with the mobile interface identifier on the access link shared with the mobile
node, so as to provide a hint to the DHCPv6 Server for the link node, so as to provide a hint to the DHCPv6 Server for the link
identification. The DHCPv6 server on receiving the request from identification. The DHCPv6 server on receiving the request from
the mobile node, will allocate address(es) from the prefixes the mobile node, will allocate address(es) from the prefixes
associated with that link (identified using the link-address field associated with that link (identified using the link-address field
of the request). of the request).
o Once the mobile node obtains address(es) and moves to a different o Once the mobile node obtains address(es) and moves to a different
skipping to change at page 76, line 38 skipping to change at page 76, line 38
Invalid timestamp value (the clocks are out of sync) Invalid timestamp value (the clocks are out of sync)
TIMESTAMP_LOWER_THAN_PREV_ACCEPTED: IANA TIMESTAMP_LOWER_THAN_PREV_ACCEPTED: IANA
The timestamp value is lower than the previously accepted value The timestamp value is lower than the previously accepted value
MISSING_HOME_NETWORK_PREFIX_OPTION: IANA MISSING_HOME_NETWORK_PREFIX_OPTION: IANA
Missing home network prefix option Missing home network prefix option
BCE_PBU_PREFIX_SET_DO_NOT_MATCH: IANA
All the home network prefixes listed in the BCE do not match all
the prefixes in the received PBU
MISSING_MN_IDENTIFIER_OPTION: IANA MISSING_MN_IDENTIFIER_OPTION: IANA
Missing mobile node identifier option Missing mobile node identifier option
MISSING_HANDOFF_INDICATOR_OPTION: IANA MISSING_HANDOFF_INDICATOR_OPTION: IANA
Missing handoff indicator option Missing handoff indicator option
MISSING_ACCESS_TECH_TYPE_OPTION: IANA MISSING_ACCESS_TECH_TYPE_OPTION: IANA
Missing access technology type option Missing access technology type option
Additionally, the following Status values defined in [RFC-3775] can Additionally, the following Status values defined in [RFC-3775] can
also be used in Proxy Binding Acknowledgement message. also be used in Proxy Binding Acknowledgement message.
0 Proxy Binding Update accepted 0 Proxy Binding Update accepted
 End of changes. 28 change blocks. 
125 lines changed or deleted 148 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/