draft-ietf-netlmm-proxymip6-04.txt   draft-ietf-netlmm-proxymip6-05.txt 
NETLMM WG S. Gundavelli NETLMM WG S. Gundavelli
Internet-Draft K. Leung Internet-Draft K. Leung
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: March 14, 2008 V. Devarapalli Expires: March 17, 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
September 11, 2007 September 14, 2007
Proxy Mobile IPv6 Proxy Mobile IPv6
draft-ietf-netlmm-proxymip6-04.txt draft-ietf-netlmm-proxymip6-05.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 March 14, 2008. This Internet-Draft will expire on March 17, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
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]. This protocol enables mobility support to a host without [RFC-3775]. This protocol enables mobility support to a host without
skipping to change at page 2, line 29 skipping to change at page 2, line 29
4. Proxy Mobile IPv6 Protocol Security . . . . . . . . . . . . . 13 4. Proxy Mobile IPv6 Protocol Security . . . . . . . . . . . . . 13
4.1. Peer Authorization Database Entries . . . . . . . . . . . 13 4.1. Peer Authorization Database Entries . . . . . . . . . . . 13
4.2. Security Policy Database Entries . . . . . . . . . . . . . 14 4.2. Security Policy Database Entries . . . . . . . . . . . . . 14
5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 15 5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 15
5.1. Extensions to Binding Cache Entry Data Structure . . . . . 15 5.1. Extensions to Binding Cache Entry Data Structure . . . . . 15
5.2. Supported Home Network Prefix Models . . . . . . . . . . . 16 5.2. Supported Home Network Prefix Models . . . . . . . . . . . 16
5.3. Signaling Considerations . . . . . . . . . . . . . . . . . 16 5.3. Signaling Considerations . . . . . . . . . . . . . . . . . 16
5.4. Timestamp Option for Message Ordering . . . . . . . . . . 21 5.4. Timestamp Option for Message Ordering . . . . . . . . . . 21
5.5. Routing Considerations . . . . . . . . . . . . . . . . . . 23 5.5. Routing Considerations . . . . . . . . . . . . . . . . . . 23
5.5.1. Bi-Directional Tunnel Management . . . . . . . . . . . 23 5.5.1. Bi-Directional Tunnel Management . . . . . . . . . . . 23
5.5.2. Forwarding Considerations . . . . . . . . . . . . . . 23 5.5.2. Forwarding Considerations . . . . . . . . . . . . . . 24
5.6. Local Mobility Anchor Address Discovery . . . . . . . . . 24 5.6. Local Mobility Anchor Address Discovery . . . . . . . . . 25
5.7. Mobile Prefix Discovery Considerations . . . . . . . . . . 25 5.7. Mobile Prefix Discovery Considerations . . . . . . . . . . 25
5.8. Route Optimizations Considerations . . . . . . . . . . . . 25 5.8. Route Optimizations Considerations . . . . . . . . . . . . 25
6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 25 6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 26
6.1. Extensions to Binding Update List Entry Data Structure . . 26 6.1. Extensions to Binding Update List Entry Data Structure . . 26
6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 27 6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 27
6.3. Supported Access Link Types . . . . . . . . . . . . . . . 28 6.3. Supported Access Link Types . . . . . . . . . . . . . . . 28
6.4. Supported Address Configuration Models . . . . . . . . . . 28 6.4. Supported Address Configuration Models . . . . . . . . . . 28
6.5. Access Authentication & Mobile Node Identification . . . . 28 6.5. Access Authentication & Mobile Node Identification . . . . 29
6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 29 6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 29
6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 29 6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 30
6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 30 6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 30
6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 31 6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 31
6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 31 6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 32
6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 34 6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 35
6.9.3. Retransmissions and Rate Limiting . . . . . . . . . . 35 6.9.3. Retransmissions and Rate Limiting . . . . . . . . . . 36
6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 35 6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 36
6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 36 6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 37
6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 36 6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 37
6.10.3. Routing State . . . . . . . . . . . . . . . . . . . . 37 6.10.3. Routing State . . . . . . . . . . . . . . . . . . . . 38
6.10.4. Local Routing . . . . . . . . . . . . . . . . . . . . 38 6.10.4. Local Routing . . . . . . . . . . . . . . . . . . . . 39
6.10.5. Tunnel Management . . . . . . . . . . . . . . . . . . 38 6.10.5. Tunnel Management . . . . . . . . . . . . . . . . . . 39
6.10.6. Forwarding Rules . . . . . . . . . . . . . . . . . . . 38 6.10.6. Forwarding Rules . . . . . . . . . . . . . . . . . . . 39
6.11. Interaction with DHCP Relay Agent . . . . . . . . . . . . 40 6.11. Interaction with DHCP Relay Agent . . . . . . . . . . . . 40
6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 40 6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 41
6.13. Mobile Node Detachment Detection and Resource Cleanup . . 40 6.13. Mobile Node Detachment Detection and Resource Cleanup . . 41
6.14. Allowing network access to other IPv6 nodes . . . . . . . 41 6.14. Allowing network access to other IPv6 nodes . . . . . . . 42
7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 42 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 42
7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 42 7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 43
7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 43 7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 44
7.3. IPv6 Host Protocol Parameters . . . . . . . . . . . . . . 43 7.3. IPv6 Host Protocol Parameters . . . . . . . . . . . . . . 44
8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 44 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 45
8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 45 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 46
8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 46 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 47
8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 46 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 48
8.4. Link-local Address Option . . . . . . . . . . . . . . . . 47 8.4. Link-local Address Option . . . . . . . . . . . . . . . . 50
8.5. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 48 8.5. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 51
8.6. Status Values . . . . . . . . . . . . . . . . . . . . . . 49 8.6. Status Values . . . . . . . . . . . . . . . . . . . . . . 51
9. Protocol Configuration Variables . . . . . . . . . . . . . . . 50 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 53
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
11. Security Considerations . . . . . . . . . . . . . . . . . . . 51 11. Security Considerations . . . . . . . . . . . . . . . . . . . 54
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
13.1. Normative References . . . . . . . . . . . . . . . . . . . 53 13.1. Normative References . . . . . . . . . . . . . . . . . . . 55
13.2. Informative References . . . . . . . . . . . . . . . . . . 54 13.2. Informative References . . . . . . . . . . . . . . . . . . 56
Appendix A. Proxy Mobile IPv6 interactions with AAA Appendix A. Proxy Mobile IPv6 interactions with AAA
Infrastructure . . . . . . . . . . . . . . . . . . . 55 Infrastructure . . . . . . . . . . . . . . . . . . . 57
Appendix B. Supporting Shared-Prefix Model using DHCPv6 . . . . . 55 Appendix B. Supporting Shared-Prefix Model using DHCPv6 . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58
Intellectual Property and Copyright Statements . . . . . . . . . . 57 Intellectual Property and Copyright Statements . . . . . . . . . . 60
1. Introduction 1. Introduction
Mobile IPv6 [RFC-3775] is the enabler for IPv6 mobility. It requires Mobile IPv6 [RFC-3775] is the enabler for IPv6 mobility. It requires
Mobile IPv6 client functionality in the IPv6 stack of a mobile node. Mobile IPv6 client functionality in the IPv6 stack of a mobile node.
Signaling between the mobile node and home agent enables the creation Signaling between the mobile node and home agent enables the creation
and maintenance of a binding between the mobile node's home address and maintenance of a binding between the mobile node's home address
and care-of-address. Mobile IPv6 has been designed to be an integral and care-of-address. Mobile IPv6 has been designed to be an integral
part of the IPv6 stack in a host. However there exist IPv6 stacks part of the IPv6 stack in a host. However there exist IPv6 stacks
today that do not have Mobile IPv6 functionality and there would today that do not have Mobile IPv6 functionality and there would
skipping to change at page 11, line 37 skipping to change at page 11, line 37
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 corresponding node to the mobile node. Local mobility anchor by any corresponding node to the mobile node. Local mobility anchor
forwards these received packets to the mobile access gateway through forwards these received packets to the mobile access gateway through
the bi-directional tunnel. The mobile access gateway on other end of the bi-directional tunnel. The mobile access gateway on other end of
the tunnel, after receiving the packet, removes the outer header and the tunnel, after receiving the packet, removes the outer header and
forwards the packet on the access link to the mobile node. forwards the packet on the access link to the mobile 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. However, in some configurations where the functionality access link. Any packet that the mobile node sends to any
of the mobile access gateway is split across different nodes, the
node sending the Router Advertisements will be the default-router for
the mobile node. Any packet that the mobile node sends to any
corresponding node will be received by the mobile access gateway and corresponding 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
tunnel. The local mobility anchor on the other end of the tunnel, tunnel. The local mobility anchor on the other end of the tunnel,
after receiving the packet removes the outer header and routes the after receiving the packet removes the outer header and routes the
packet to the destination. packet to the destination.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| MN | |p-MAG| | LMA | |n-MAG| | MN | |p-MAG| | LMA | |n-MAG|
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | |
skipping to change at page 21, line 28 skipping to change at page 21, line 28
it needs to use in the signaling messages. Hence, the sequence it needs to use in the signaling messages. Hence, the sequence
number scheme as specified in [RFC-3775], will be insufficient for number scheme as specified in [RFC-3775], will be insufficient for
Proxy Mobile IPv6. Proxy Mobile IPv6.
If the local mobility anchor cannot determine the sending order of If the local mobility anchor cannot determine the sending order of
the received binding registration messages, it may potentially the received binding registration messages, it may potentially
process an older message sent by a mobile access gateway, where the process an older message sent by a mobile access gateway, where the
mobile node was previously anchored, resulting in an incorrect mobile node was previously anchored, resulting in an incorrect
Binding Cache entry. Binding Cache entry.
For solving this problem, this specification RECOMMENDS the use of For solving this problem, this specification adopts two alternative
Timestamp option [Section 8.4]. The basic principle behind the use solutions, one is based on timestamps and the other based on sequence
of timestamps in binding registration messages is that the node numbers, as defined in [RFC-3775].
generating the message inserts the current time-of-day, and the node
receiving the message checks that this timestamp is greater than all
previously accepted timestamps.
Alternatively, the specification also allows the use of Sequence The basic principle behind the use of timestamps in binding
Number based scheme, as per [RFC-3775]. The sequence number MUST be registration messages is that the node generating the message inserts
maintained on a per mobile node basis and MUST be synchronized the current time-of-day, and the node receiving the message checks
between the serving mobile access gateways. However, the specific that this timestamp is greater than all previously accepted
details on how a mobile node's sequence number is synchronized timestamps. The timestamp based solution may be used, when the
between different mobile access gateways is outside the scope of this serving mobile access gateways in a Proxy Mobile IPv6 domain do not
document. have the ability to obtain the last sequence number that was sent in
a binding registration message for updating a given mobile node's
binding.
As an alternative to the Timestamp based approach, the specification
also allows the use of Sequence Number based scheme, as per [RFC-
3775]. However, for this scheme to work, the serving mobile access
gateways in a Proxy Mobile IPv6 domain MUST have the ability to
obtain the last sequence number that was sent in a binding
registration message for updating a given mobile node's binding. The
sequence number MUST be maintained on a per mobile node basis and
MUST be synchronized between the serving mobile access gateways.
However, the specific details on how a mobile node's sequence number
is synchronized between different mobile access gateways is outside
the scope of this document.
Using Timestamps based approach: Using Timestamps based approach:
o An implementation MUST support Timestamp option. If the Timestamp o An implementation MUST support Timestamp option. If the Timestamp
option is present in the received Proxy Binding Update request option is present in the received Proxy Binding Update request
message, then the local mobility anchor MUST include a valid message, then the local mobility anchor MUST include a valid
Timestamp option in the Proxy Binding Acknowledgement message that Timestamp option in the Proxy Binding Acknowledgement message that
it sends to the mobile access gateway. it sends to the mobile access gateway.
o All the mobility entities in a Proxy Mobile IPv6 domain, o All the mobility entities in a Proxy Mobile IPv6 domain,
exchanging binding registration messages using Timestamp option exchanging binding registration messages using Timestamp option
must have adequately synchronized time-of-day clocks. These nodes must have adequately synchronized time-of-day clocks. This is the
SHOULD synchronize their clocks to a common time source, using essential requirement for this solution to work. If this
Network Time Protocol [RFC-4330] or in any other ways suitable for requirement is not met, the solution will not predictably work in
that specific deployment. all cases.
o The mobility entities in a Proxy Mobile IPv6 domain SHOULD
synchronize their clocks to a common time source. For
synchronizing the clocks, the nodes may use Network Time Protocol
[RFC-4330]. Deployments may also adopt other approaches suitable
for that specific deployment.
o When generating the timestamp value for building the Timestamp o When generating the timestamp value for building the Timestamp
option, the mobility entities MUST ensure that the generated option, the mobility entities MUST ensure that the generated
timestamp is the elapsed time past the same reference epoch, as timestamp is the elapsed time past the same reference epoch, as
specified in the format for the Timestamp option [Section 8.5]. specified in the format for the Timestamp option [Section 8.5].
o Upon receipt of a Proxy Binding Update message with the Timestamp o Upon receipt of a Proxy Binding Update message with the Timestamp
option, the local mobility anchor MUST check the timestamp field option, the local mobility anchor MUST check the timestamp field
for validity. In order for it to be considered valid, the for validity. In order for it to be considered valid, the
timestamp value contained in the Timestamp option MUST be close timestamp value contained in the Timestamp option MUST be close
skipping to change at page 23, line 5 skipping to change at page 23, line 18
Using Sequence Number based approach: Using Sequence Number based approach:
o If the Timestamp option is not present in the received Proxy o If the Timestamp option is not present in the received Proxy
Binding Update request, the local mobility anchor MUST fallback to Binding Update request, the local mobility anchor MUST fallback to
the Sequence Number based scheme. It MUST process the sequence the Sequence Number based scheme. It MUST process the sequence
number field as specified in [RFC-3775]. Also, it MUST NOT number field as specified in [RFC-3775]. Also, it MUST NOT
include the Timestamp option in the Proxy Binding Acknowledgement include the Timestamp option in the Proxy Binding Acknowledgement
messages that it sends to the mobile access gateway. messages that it sends to the mobile access gateway.
o An implementation MUST support Sequence Number based scheme, as
per [RFC-3775].
5.5. Routing Considerations 5.5. Routing Considerations
5.5.1. Bi-Directional Tunnel Management 5.5.1. Bi-Directional Tunnel Management
o A bi-directional tunnel is established between the local mobility o A bi-directional tunnel is established between the local mobility
anchor and the mobile access gateway with IP-in-IP encapsulation, anchor and the mobile access gateway with IP-in-IP encapsulation,
as described in [RFC-2473]. The tunnel end points are the Proxy- as described in [RFC-2473]. The tunnel end points are the Proxy-
CoA and LMAA. When using IPv4 transport with a specific CoA and LMAA. When using IPv4 transport with a specific
encapsulation mode, the end points of the tunnel are the IPv4-LMAA encapsulation mode, the end points of the tunnel are the IPv4-LMAA
and IPv4-Proxy-CoA, as specified in [ID-IPV4-PMIP6]. and IPv4-Proxy-CoA, as specified in [ID-IPV4-PMIP6].
skipping to change at page 23, line 27 skipping to change at page 23, line 43
data traffic between the mobile access gateway and the local data traffic between the mobile access gateway and the local
mobility anchor. The tunnel hides the topology and enables a mobility anchor. The tunnel hides the topology and enables a
mobile node to use an address from its home network prefix from mobile node to use an address from its home network prefix from
any access link attached to the mobile access gateway. any access link attached to the mobile access gateway.
o The bi-directional tunnel is established after accepting the Proxy o The bi-directional tunnel is established after accepting the Proxy
Binding Update request message. The created tunnel may be shared Binding Update request message. The created tunnel may be shared
with other mobile nodes attached to the same mobile access gateway with other mobile nodes attached to the same mobile access gateway
and with the local mobility anchor having a Binding Cache entry and with the local mobility anchor having a Binding Cache entry
for those mobile nodes. Implementations MAY choose to use static for those mobile nodes. Implementations MAY choose to use static
tunnels as supposed to dynamically creating and tearing them down tunnels instead of dynamically creating and tearing them down on a
on a need basis. need basis.
o The tunnel between the local mobility anchor and the mobile access o The tunnel between the local mobility anchor and the mobile access
gateway is typically a shared tunnel and can be used for routing gateway is typically a shared tunnel and can be used for routing
traffic streams for different mobile nodes attached to the same traffic streams for different mobile nodes attached to the same
mobile access gateway. mobile access gateway.
o Implementations typically use a software timer for managing the o Implementations typically use a software timer for managing the
tunnel lifetime and a counter for keeping a count of all the tunnel lifetime and a counter for keeping a count of all the
mobile nodes that are sharing the tunnel. The timer value will be mobile nodes that are sharing the tunnel. The timer value will be
set to the accepted binding life-time and will be updated after set to the accepted binding life-time and will be updated after
skipping to change at page 28, line 12 skipping to change at page 28, line 27
The following are the optional fields of the policy profile: The following are the optional fields of the policy profile:
o The mobile node's IPv6 home network prefix (MN-HNP) o The mobile node's IPv6 home network prefix (MN-HNP)
6.3. Supported Access Link Types 6.3. Supported Access Link Types
This specification supports only point-to-point access link types and This specification supports only point-to-point access link types and
thus it assumes that the mobile node and the mobile access gateway thus it assumes that the mobile node and the mobile access gateway
are the only two nodes on the access link. The link is assumed to are the only two nodes on the access link. The link is assumed to
have multicast capability. have multicast capability. This protocol may also be used on other
link types, as long as the link is configured in such a way that it
guarantees a point-to-point delivery between the mobile node and the
mobile access gateway for all the protocol traffic.
6.4. Supported Address Configuration Models 6.4. Supported Address Configuration Models
A mobile node in the Proxy Mobile IPv6 domain can configure one or A mobile node in the Proxy Mobile IPv6 domain can configure one or
more IPv6 addresses on its interface using Stateless or Stateful more IPv6 addresses on its interface using Stateless or Stateful
address autoconfiguration procedures. The Router Advertisement address autoconfiguration procedures. The Router Advertisement
messages sent on the access link, specify the address configuration messages sent on the access link, specify the address configuration
methods permitted on that access link for that mobile node. However, methods permitted on that access link for that mobile node. However,
the advertised flags with respect the address configuration will be the advertised flags with respect to the address configuration will
consistent for a mobile node, on any of the access links in that be consistent for a mobile node, on any of the access links in that
Proxy Mobile IPv6 domain. Typically, these configuration settings Proxy Mobile IPv6 domain. Typically, these configuration settings
will be based on the domain wide policy or based on a policy specific will be based on the domain wide policy or based on a policy specific
to each mobile node. to each mobile node.
When stateless address autoconfiguration is supported on the link, When stateless address autoconfiguration is supported on the link,
the mobile node can generate one or more IPv6 addresses by combining the mobile node can generate one or more IPv6 addresses by combining
the network prefix advertised on the access link with an interface the network prefix advertised on the access link with an interface
identifier, using the techniques described in Stateless identifier, using the techniques described in Stateless
Autoconfiguration specification [RFC-2462] or as per Privacy Autoconfiguration specification [RFC-2462] or as per Privacy
extension specification [RFC-3041]. extension specification [RFC-3041].
skipping to change at page 31, line 42 skipping to change at page 32, line 17
Initial Binding Registration: Initial Binding Registration:
o After detecting a new mobile node on its access link, the mobile o After detecting a new mobile node on its access link, the mobile
access gateway must identify the mobile node and acquire its MN- access gateway must identify the mobile node and acquire its MN-
Identifier. If it determines that the network-based mobility Identifier. If it determines that the network-based mobility
management service needs to offered to the mobile node, it MUST management service needs to offered to the mobile node, it MUST
send a Proxy Binding Update message to the local mobility anchor. send a Proxy Binding Update message to the local mobility anchor.
o The Proxy Binding Update message MUST have the NAI option [RFC- o The Proxy Binding Update message MUST have the NAI option [RFC-
4283], identifying the mobile node, the Home Network Prefix 4283], identifying the mobile node, the Home Network Prefix
option, Timestamp option or a valid sequence number and optionally option, either the Timestamp option or a valid sequence number and
the Link-local Address option. optionally the Link-local Address option. When Timestamp option
is added to the message, the mobile access gateway MAY set the
Sequence Number field to a value of a monotonically increasing
counter and the local mobility anchor will ignore this field, but
will return the same value in the Proxy Binding Acknowledgement
message. This will be useful for matching the reply to the
request message.
o The Home Address option MUST not be present in the Destination
Option extension header of the Proxy Binding Update message.
o If the mobile access gateway learns the mobile node's home network o If the mobile access gateway learns the mobile node's home network
prefix either from its policy store or from other means, the prefix either from its policy store or from other means, the
mobile access gateway MAY choose to specify the same in the Home mobile access gateway MAY choose to specify the same in the Home
Network Prefix option for requesting the local mobility anchor to Network Prefix option for requesting the local mobility anchor to
allocate that prefix. If the specified value is 0::/0, then the allocate that prefix. If the specified value is 0::/0, then the
local mobility anchor will consider this as a request for prefix local mobility anchor will consider this as a request for prefix
allocation. allocation.
Receiving Binding Registration Reply: Receiving Binding Registration Reply:
skipping to change at page 32, line 24 skipping to change at page 33, line 9
authenticating the message. authenticating the message.
o The mobile access gateway MUST apply the considerations specified o The mobile access gateway MUST apply the considerations specified
in Section 5.4, for processing the Sequence Number field and the in Section 5.4, for processing the Sequence Number field and the
Timestamp option, in the message. Timestamp option, in the message.
o The mobile access gateway MUST ignore any checks, specified in o The mobile access gateway MUST ignore any checks, specified in
[RFC-3775] related to the presence of Type 2 Routing header in the [RFC-3775] related to the presence of Type 2 Routing header in the
Proxy Binding Acknowledgement message. Proxy Binding Acknowledgement message.
o If the Timestamp option is present in the received Proxy Binding
Acknowledgement message and with the Status field value set to any
value other than TIMESTAMP_MISMATCH (Invalid Timestamp), the
mobile access gateway MAY use the timestamp value for matching the
response to the request message that it sent recently. For all
other cases, it MAY use the sequence number in combination with
the identifier present in the NAI option for matching the response
to the request.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to PROXY_REG_NOT_ENABLED (Proxy Status field value set to PROXY_REG_NOT_ENABLED (Proxy
registration not enabled for the mobile node), the mobile access registration not enabled for the mobile node), the mobile access
gateway SHOULD not send binding registration requests again for gateway SHOULD not send binding registration requests again for
that mobile node. It must also deny the mobility service to that that mobile node. It must also deny the mobility service to that
mobile node. mobile node.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to TIMESTAMP_MISMATCH (Invalid Timestamp), Status field value set to TIMESTAMP_MISMATCH (Invalid Timestamp),
the mobile access gateway SHOULD try to register again only after the mobile access gateway SHOULD try to register again only after
it synchronized its clock with the local mobility anchor's system it synchronized its clock to a common time source that is used by
clock or to a common time source that is used by all mobility all the mobility entities in that domain for their clock
entities in that domain for their clock synchronization. synchronization. The mobile access gateway SHOULD NOT synchronize
its clock to the local mobility anchor's system clock, based on
the timestamp present in the received message.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX
(Not authorized for that prefix), the mobile access gateway SHOULD (Not authorized for that prefix), the mobile access gateway SHOULD
try to request for that prefix in the binding registration try to request for that prefix in the binding registration
request, only after it learned the validity of that prefix. request, only after it learned the validity of that prefix.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to any value greater than 128 (i.e., the Status field value set to any value greater than 128 (i.e., the
binding is rejected), the mobile access gateway MUST NOT advertise binding is rejected), the mobile access gateway MUST NOT advertise
skipping to change at page 37, line 5 skipping to change at page 37, line 44
outer header and the addresses as specified for that point to point outer header and the addresses as specified for that point to point
tunnel interface. For creating a point to point tunnel to any local tunnel interface. For creating a point to point tunnel to any local
mobility anchor, the mobile access gateway may implement a tunnel mobility anchor, the mobile access gateway may implement a tunnel
interface with the source address field set to its Proxy-CoA address interface with the source address field set to its Proxy-CoA address
and the destination address field set to the LMA address. and the destination address field set to the LMA address.
The following are the supported packet encapsulation modes that can The following are the supported packet encapsulation modes that can
be used by the mobile access gateway and the local mobility anchor be used by the mobile access gateway and the local mobility anchor
for routing mobile node's IPv6 datagrams. for routing mobile node's IPv6 datagrams.
o IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet. This o IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet [RFC-
mechanism is defined in the Generic Packet Tunneling for IPv6 2473].
specification [RFC-2473].
o IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet. The o IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet. The
details related to this encapsulation mode and the specifics on details on how this mode is negotiated is specified in [ID-IPV4-
how this mode is negotiated is specified in the companion PMIP6].
document, IPv4 support for Proxy Mobile IPv6 [ID-IPV4-PMIP6].
o IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP o IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP
packet. The details related to this mode are covered in the packet. This mode is specified in [ID-IPV4-PMIP6].
companion document, IPv4 support for Proxy Mobile IPv6 [ID-IPV4-
PMIP6].
6.10.3. Routing State 6.10.3. Routing State
The following section explains the routing state for a mobile node on The following section explains the routing state for a mobile node on
the mobile access gateway. This routing state reflects only one the mobile access gateway. This routing state reflects only one
specific way of implementation and one MAY choose to implement it in specific way of implementation and one MAY choose to implement it in
other ways. The policy based route defined below acts as a traffic other ways. The policy based route defined below acts as a traffic
selection rule for routing a mobile node's traffic through a specific selection rule for routing a mobile node's traffic through a specific
tunnel created between the mobile access gateway and that mobile tunnel created between the mobile access gateway and that mobile
node's local mobility anchor and with the specific encapsulation node's local mobility anchor and with the specific encapsulation
skipping to change at page 41, line 12 skipping to change at page 42, line 4
gateway can depend on for detecting the node loss. In general, the gateway can depend on for detecting the node loss. In general, the
mobile access gateway can depend on one or more of the following mobile access gateway can depend on one or more of the following
methods for the detection presence of the mobile node on the methods for the detection presence of the mobile node on the
connected link: connected link:
o Link-layer event specific to the access technology o Link-layer event specific to the access technology
o PPP Session termination event on point-to-point link types o PPP Session termination event on point-to-point link types
o IPv6 Neighbor Unreachability Detection event from IPv6 stack o IPv6 Neighbor Unreachability Detection event from IPv6 stack
o Notification event from the local mobility anchor o Notification event from the local mobility anchor
o Absence of data traffic from the mobile node on the link for a o Absence of data traffic from the mobile node on the link for a
certain duration of time certain duration of time
6.14. Allowing network access to other IPv6 nodes 6.14. Allowing network access to other IPv6 nodes
In some proxy mobile IPv6 deployments, network operators may want to In some Proxy Mobile IPv6 deployments, network operators may want to
provision the mobile access gateway to offer network-based mobility provision the mobile access gateway to offer network-based mobility
management service only to some visiting mobile nodes and enable just management service only to some visiting mobile nodes and enable just
regular IPv6/IPv4 access to some other nodes attached to that mobile regular IP access to some other nodes. This requires the network to
access gateway. This requires the network to have the control on have control on when to enable network-based mobility management
when to enable network-based mobility management service to a mobile service to a mobile node and when to enable regular IPv6 access.
node and when to enable regular IPv6 access. This specification does This specification does not disallow such configuration.
not disallow such configuration.
Upon obtaining the mobile node's profile after a successful access Upon detecting a mobile node on its access link and after policy
authentication and after a policy consideration, the mobile access considerations, the mobile access gateway MUST determine if network-
gateway MUST determine if the network based mobility service should based mobility management service should be offered to that mobile
be offered to that mobile node. If the mobile node is entitled for node. This decision may also be influenced by the mobile node's
such service, then the mobile access gateway must ensure the mobile host-based mobility capabilities and preferences. This may be
node believes it is on its home link, as explained in various negotiated using link-layer message exchange or through other means
sections of this specification. outside the scope of this specification. If the mobile node is
entitled for network-based mobility management service, then the
mobile access gateway must ensure the mobile node believes it is on
its home link, as explained in various sections of this
specification.
If the mobile node is not entitled for the network-based mobility If the mobile node is not entitled for the network-based mobility
management service, as enforced by the policy, the mobile access management service, as determined from the policy considerations, the
gateway MAY choose to offer regular IPv6 access to the mobile node mobile access gateway MAY choose to offer regular IPv6 access to the
and hence the normal IPv6 considerations apply. If IPv6 access is mobile node and in such scenario the normal IPv6 considerations
enabled, the mobile node SHOULD be able to obtain any IPv6 address apply. If IPv6 access is enabled, the mobile node SHOULD be able to
using normal IPv6 address configuration mechanisms. The obtained obtain an IPv6 address using normal IPv6 address configuration
address must be from a local visitor network prefix. This procedures. The obtained address must be from a local visitor
essentially ensures, the mobile access gateway functions as any other network prefix. This essentially ensures, the mobile access gateway
access router and does not impact the protocol operation of a mobile functions as a normal access router to a mobile node attached to its
node attempting to use host-based mobility management service when it access link and with out impacting its host-based mobility protocol
attaches to an access link connected to a mobile access gateway in a operation.
Proxy Mobile IPv6 domain.
7. Mobile Node Operation 7. Mobile Node Operation
This non-normative section explains the mobile node's operation in a This non-normative section explains the mobile node's operation in a
Proxy Mobile IPv6 domain. Proxy Mobile IPv6 domain.
7.1. Moving into a Proxy Mobile IPv6 Domain 7.1. Moving into a Proxy Mobile IPv6 Domain
Once a mobile node enters a Proxy Mobile IPv6 domain and attaches to Once a mobile node enters a Proxy Mobile IPv6 domain and attaches to
an access network, the mobile access gateway on the access link an access network, the mobile access gateway on the access link
skipping to change at page 44, line 4 skipping to change at page 44, line 48
sent Router Advertisement messages and are eligible to be default sent Router Advertisement messages and are eligible to be default
routers on that link. The Router Lifetime field in the received routers on that link. The Router Lifetime field in the received
Router Advertisement defines the life of this entry. Router Advertisement defines the life of this entry.
In case of Proxy Mobile IPv6, when a mobile node moves from one link In case of Proxy Mobile IPv6, when a mobile node moves from one link
to another, the source address of the received Router Advertisement to another, the source address of the received Router Advertisement
messages advertising the mobile node's home network prefix will be messages advertising the mobile node's home network prefix will be
from a different link-local address and thus making the mobile node from a different link-local address and thus making the mobile node
believe that there is a new default-router on the link. It is believe that there is a new default-router on the link. It is
important that the mobile node uses the newly learnt default-router important that the mobile node uses the newly learnt default-router
as supposed to the previously known default-router. The mobile node and not the previously known default-router. The mobile node must
must update its default-router list with the new default router entry update its default-router list with the new default router entry and
and must age out the previously learnt default router entry from its must age out the previously learnt default router entry from its
cache, just as specified in Section 6.3.5 [RFC-2461]. This action is cache, just as specified in Section 6.3.5 [RFC-2461]. This action is
critical for minimizing packet losses during a hand off switch. critical for minimizing packet losses during a hand off switch.
On detecting a reachability problem, the mobile node will certainly On detecting a reachability problem, the mobile node will certainly
detect the default-router loss by performing the Neighbor detect the default-router loss by performing the Neighbor
Unreachability Detection procedure, but it is important that the Unreachability Detection procedure, but it is important that the
mobile node times out the previous default router entry at the mobile node times out the previous default router entry at the
earliest. If a given IPv6 host implementation has the provision to earliest. If a given IPv6 host implementation has the provision to
adjust these flush timers, still conforming to the base IPv6 ND adjust these flush timers, still conforming to the base IPv6 ND
specification, it is desirable to keep the flush-timers to suit the specification, it is desirable to keep the flush-timers to suit the
skipping to change at page 44, line 30 skipping to change at page 45, line 26
access gateway may withdraw the previous default-router entry, by access gateway may withdraw the previous default-router entry, by
sending a Router Advertisement using the link-local address that of sending a Router Advertisement using the link-local address that of
the previous mobile access gateway and with the Router Lifetime field the previous mobile access gateway and with the Router Lifetime field
set to value 0, then this will force the flush of the Previous set to value 0, then this will force the flush of the Previous
Default-Router entry from the mobile node's cache. This certainly Default-Router entry from the mobile node's cache. This certainly
requires context-transfer mechanisms in place for notifying the link- requires context-transfer mechanisms in place for notifying the link-
local address of the default-router on the previous link to the local address of the default-router on the previous link to the
mobile access gateway on the new link. mobile access gateway on the new link.
There are other solutions possible for this problem, including the There are other solutions possible for this problem, including the
assignment of a unique link-local address for all the mobile access assignment of a fixed link-local address for all the mobile access
gateways in a Proxy Mobile IPv6 domain and where SEND [RFC-3971] is gateways in a Proxy Mobile IPv6 domain and where SEND [RFC-3971] is
not deployed. In such scenario, the mobile node is not required to not deployed. In such scenario, the mobile node is not required to
update the default-router entry. However, this is an implementation update the default-router entry. However, this is an implementation
choice and has no bearing on the protocol interoperability. choice and has no bearing on the protocol interoperability.
Implementations are free to adopt the best approach that suits their Implementations are free to adopt the best approach that suits their
target deployments. target deployments.
8. Message Formats 8. Message Formats
This section defines extensions to the Mobile IPv6 [RFC-3775] This section defines extensions to the Mobile IPv6 [RFC-3775]
skipping to change at page 45, line 15 skipping to change at page 46, line 15
8.1. Proxy Binding Update Message 8.1. Proxy Binding Update Message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | | Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P| Reserved | Lifetime | |A|H|L|K|M|R|P| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. .
. Mobility options .
. .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Proxy Binding Update Message Figure 13: Proxy Binding Update Message
A Binding Update message that is sent by a mobile access gateway to a A Binding Update message that is sent by a mobile access gateway to a
local mobility anchor is referred to as the "Proxy Binding Update" local mobility anchor is referred to as the "Proxy Binding Update"
message. A new flag (P) is included in the Binding Update message. message. A new flag (P) is included in the Binding Update message.
The rest of the Binding Update message format remains the same as The rest of the Binding Update message format remains the same as
defined in [RFC-3775]. defined in [RFC-3775].
Proxy Registration Flag (P) Proxy Registration Flag (P)
A new flag (P) is included in the Binding Update message to indicate A new flag (P) is included in the Binding Update message to
to the local mobility anchor that the Binding Update message is a indicate to the local mobility anchor that the Binding Update
proxy registration. The flag MUST be set to the value of 1 for proxy message is a proxy registration. The flag MUST be set to the
registrations and MUST be set to 0 for direct registrations sent by a value of 1 for proxy registrations and MUST be set to 0 for direct
mobile node. registrations sent by a mobile node.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2 [RFC-
3775]. The local mobility anchor MUST ignore and skip any options
which it does not understand.
As per this specification, the following mobility options are
valid in a Proxy Binding Update message:
Home Network Prefix option
Link-local Address option
NAI Option
Timestamp option
For descriptions of other fields present in this message, refer to For descriptions of other fields present in this message, refer to
section 6.1.7 [RFC-3775]. section 6.1.7 [RFC-3775].
8.2. Proxy Binding Acknowledgement Message 8.2. Proxy Binding Acknowledgement Message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|Reserved | | Status |K|R|P|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime | | Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. .
. Mobility options .
. .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Proxy Binding Acknowledgement Message Figure 14: Proxy Binding Acknowledgement Message
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]. 3775].
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 to indicate that the local mobility anchor that processed the
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 only if the corresponding Proxy
Binding Update had the Proxy Registration Flag (P) set to value of 1. Binding Update had the Proxy Registration Flag (P) set to value of
1.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2 [RFC-
3775]. The mobile access gateway MUST ignore and skip any options
which it does not understand.
As per this specification, the following mobility options are
valid in a Proxy Binding Acknowledgement message:
Home Network Prefix option
Link-local Address option
NAI Option
Timestamp option
Status
8-bit unsigned integer indicating the disposition of the Proxy
Binding Update. Values of the Status field less than 128 indicate
that the Proxy Binding Update was accepted by the local mobility
anchor. Values greater than or equal to 128 indicate that the
binding registration was rejected by the local mobility anchor.
Section 8.6 defines the Status values that can used in Proxy
Binding Acknowledgement message.
For descriptions of other fields present in this message, refer to For descriptions of other fields present in this message, refer to
the section 6.1.8 [RFC-3775]. the section 6.1.8 [RFC-3775].
8.3. Home Network Prefix Option 8.3. Home Network Prefix Option
A new option, Home Network Prefix Option is defined for using it in A new option, Home Network Prefix Option is defined for using it in
the Proxy Binding Update and Proxy Binding Acknowledgement messages the Proxy Binding Update and Proxy Binding Acknowledgement messages
exchanged between a local mobility anchor and a mobile access exchanged between a local mobility anchor and a mobile access
gateway. This option is used for exchanging the mobile node's home gateway. This option is used for exchanging the mobile node's home
skipping to change at page 50, line 27 skipping to change at page 52, line 34
TIMESTAMP_MISMATCH: TIMESTAMP_MISMATCH:
Invalid Timestamp value in the received Proxy Binding Update Invalid Timestamp value in the received Proxy Binding Update
message. message.
MISSING_MN_IDENTIFIER_OPTION: MISSING_MN_IDENTIFIER_OPTION:
Missing mobile node identifier in the Proxy Binding Update Missing mobile node identifier in the Proxy Binding Update
message. message.
Additionally, the following Status values defined in [RFC-3775] can
also be used in Proxy Binding Acknowledgement message.
0 Proxy Binding Update accepted
128 Reason unspecified
129 Administratively prohibited
130 Insufficient resources
133 Not local mobility anchor for this mobile node
9. Protocol Configuration Variables 9. Protocol Configuration Variables
The mobile access gateway MUST allow the following variables to be The mobile access gateway MUST allow the following variables to be
configured by the system management. configured by the system management.
EnableMAGLocalrouting EnableMAGLocalrouting
This flag indicates whether or not the mobile access gateway is This flag indicates whether or not the mobile access gateway is
allowed to enable local routing of the traffic exchanged between a allowed to enable local routing of the traffic exchanged between a
visiting mobile node and a corresponding node that is locally visiting mobile node and a corresponding node that is locally
 End of changes. 39 change blocks. 
121 lines changed or deleted 227 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/