< draft-ietf-mip4-reg-tunnel-03.txt   draft-ietf-mip4-reg-tunnel-04.txt >
MIP4 Working Group E. Fogelstroem MIP4 Working Group E. Fogelstroem
Internet-Draft A. Jonsson Internet-Draft A. Jonsson
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: February 23, 2007 C. Perkins Expires: April 26, 2007 C. Perkins
Nokia Research Center Nokia Research Center
August 22, 2006 October 23, 2006
Mobile IPv4 Regional Registration Mobile IPv4 Regional Registration
draft-ietf-mip4-reg-tunnel-03 draft-ietf-mip4-reg-tunnel-04
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 36 skipping to change at page 1, line 36
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 February 23, 2007. This Internet-Draft will expire on April 26, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Using Mobile IP, a mobile node registers with its home agent each Using Mobile IP, a mobile node registers with its home agent each
time it changes care-of address. This document describes a new kind time it changes care-of address. This document describes a new kind
of "regional registrations", i.e. registrations local to the visited of "regional registrations", i.e. registrations local to the visited
skipping to change at page 2, line 43 skipping to change at page 2, line 43
7.3. GFA Considerations for Dynamic GFA Assignment . . . . . . 19 7.3. GFA Considerations for Dynamic GFA Assignment . . . . . . 19
7.4. Home Agent Considerations for Dynamic GFA Assignment . . . 19 7.4. Home Agent Considerations for Dynamic GFA Assignment . . . 19
7.5. Regional Registration . . . . . . . . . . . . . . . . . . 20 7.5. Regional Registration . . . . . . . . . . . . . . . . . . 20
8. Router Discovery Extensions . . . . . . . . . . . . . . . . . 20 8. Router Discovery Extensions . . . . . . . . . . . . . . . . . 20
8.1. Regional Registration Flag . . . . . . . . . . . . . . . . 20 8.1. Regional Registration Flag . . . . . . . . . . . . . . . . 20
8.2. Foreign Agent NAI Extension . . . . . . . . . . . . . . . 21 8.2. Foreign Agent NAI Extension . . . . . . . . . . . . . . . 21
9. Regional Extensions to Mobile IPv4 Registration Messages . . . 21 9. Regional Extensions to Mobile IPv4 Registration Messages . . . 21
9.1. GFA IP Address Extension . . . . . . . . . . . . . . . . . 21 9.1. GFA IP Address Extension . . . . . . . . . . . . . . . . . 21
9.2. Hierarchical Foreign Agent Extension . . . . . . . . . . . 22 9.2. Hierarchical Foreign Agent Extension . . . . . . . . . . . 22
9.3. Replay Protection Style . . . . . . . . . . . . . . . . . 23 9.3. Replay Protection Style . . . . . . . . . . . . . . . . . 23
9.4. Regional Registration Lifetime Extension . . . . . . . . . 24 9.4. Regional Registration Lifetime Extension . . . . . . . . . 25
9.5. New Code Values for Registration Reply . . . . . . . . . . 25 9.5. New Code Values for Registration Reply . . . . . . . . . . 26
10. Regional Registration Message Formats . . . . . . . . . . . . 26 10. Regional Registration Message Formats . . . . . . . . . . . . 26
10.1. Regional Registration Request . . . . . . . . . . . . . . 26 10.1. Regional Registration Request . . . . . . . . . . . . . . 27
10.2. Regional Registration Reply . . . . . . . . . . . . . . . 28 10.2. Regional Registration Reply . . . . . . . . . . . . . . . 28
10.3. New Regional Registration Reply Code Values . . . . . . . 29 10.3. New Regional Registration Reply Code Values . . . . . . . 29
11. Authentication Extensions . . . . . . . . . . . . . . . . . . 30 11. Authentication Extensions . . . . . . . . . . . . . . . . . . 30
12. Security Considerations . . . . . . . . . . . . . . . . . . . 30 12. Security Considerations . . . . . . . . . . . . . . . . . . . 31
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . . 32 15.1. Normative References . . . . . . . . . . . . . . . . . . . 32
15.2. Informative References . . . . . . . . . . . . . . . . . . 32 15.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Authentication, Authorization and Accounting Appendix A. Authentication, Authorization and Accounting
(AAA) Interactions . . . . . . . . . . . . . . . . . 33 (AAA) Interactions . . . . . . . . . . . . . . . . . 33
Appendix B. Anchoring at a GFA . . . . . . . . . . . . . . . . . 33 Appendix B. Anchoring at a GFA . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. Introduction 1. Introduction
This document is an optional extension to the Mobile IPv4 protocol, This document is an optional extension to the Mobile IPv4 protocol,
and proposes a means for mobile nodes to register locally within a and proposes a means for mobile nodes to register locally within a
skipping to change at page 5, line 38 skipping to change at page 5, line 38
There are two models of how the MN uses Regional Registrations. The There are two models of how the MN uses Regional Registrations. The
FA can advertise a GFA to the MN. Alternatively, the FA can indicate FA can advertise a GFA to the MN. Alternatively, the FA can indicate
that dynamic assignment of GFA is to be used. With dynamic GFA that dynamic assignment of GFA is to be used. With dynamic GFA
assignment, the MN does not choose the GFA, rather the FA (or GFA) assignment, the MN does not choose the GFA, rather the FA (or GFA)
does so after receiving a Registration Request from the MN. However, does so after receiving a Registration Request from the MN. However,
in this mode the HA must understand (and support) Regional in this mode the HA must understand (and support) Regional
Registrations in order for them to be used. This last form is not Registrations in order for them to be used. This last form is not
transparent because the MN doesn't know in advance what GFA will be transparent because the MN doesn't know in advance what GFA will be
used, and cannot include it in a signed message to the HA. used, and cannot include it in a signed message to the HA.
When a MN moves to a new domain (determined by comparing its NAI When a MN moves to a new domain (determined by comparing its Network
[RFC4282] with the FA-NAI included in received Agent Advertisements), Access Identifier (NAI) [RFC4282] with the FA-NAI included in
it can opt to use Regional Registrations. A site indicates support received Agent Advertisements), it can opt to use Regional
for Regional Registrations by setting the I-bit of the Mobile IP Registrations. A site indicates support for Regional Registrations
Agent Advertisement extension. In addition, such advertisements by setting the I-bit of the Mobile IP Agent Advertisement extension.
include a list of one or more care-of addresses. If there is only In addition, such advertisements include a list of one or more
one care-of address, this is the address of the FA itself. In care-of addresses. If there is only one care-of address, this is the
addition, the advertisement may include the address of the GFA. A address of the FA itself. In addition, the advertisement may include
GFA care-of address of all-ones indicates that dynamic assignment of the address of the GFA. A GFA care-of address of all-ones indicates
GFA is supported. that dynamic assignment of GFA is supported.
A MN requests initial Regional Registration by sending a normal A MN requests initial Regional Registration by sending a normal
Registration Request to the FA, but setting the care-of address to Registration Request to the FA, but setting the care-of address to
that of the GFA (i.e., if it has selected it wishes to use this GFA) that of the GFA (i.e., if it has selected it wishes to use this GFA)
or all-zeros (which signals a dynamic GFA assignment request). The or all-zeros (which signals a dynamic GFA assignment request). The
FA adds a Hierarchical FA (HFA) extension and relays the request to FA adds a Hierarchical FA (HFA) extension and relays the request to
the appropriate GFA. The HFA extension contains a single field: the the appropriate GFA. The HFA extension contains a single field: the
IP address of the FA. IP address of the FA.
Note: the algorithm for MNs with co-located care-of addresses is Note: the algorithm for MNs with co-located care-of addresses is
skipping to change at page 13, line 52 skipping to change at page 13, line 52
[RFC3344]. For each pending or current home registration, the FA [RFC3344]. For each pending or current home registration, the FA
maintains a visitor list entry as described in [RFC3344]. If reverse maintains a visitor list entry as described in [RFC3344]. If reverse
tunneling is being used, the visitor list MUST, in addition to the tunneling is being used, the visitor list MUST, in addition to the
fields required in [RFC3344], contain the address of the GFA. fields required in [RFC3344], contain the address of the GFA.
Otherwise, if the care-of address in the Registration Request is the Otherwise, if the care-of address in the Registration Request is the
address of a GFA (or all-zeros), the FA adds a Hierarchical Foreign address of a GFA (or all-zeros), the FA adds a Hierarchical Foreign
Agent (HFA) extension, including its own address, to the Registration Agent (HFA) extension, including its own address, to the Registration
Request, and relays it to the GFA. The HFA extension MUST be Request, and relays it to the GFA. The HFA extension MUST be
appended at the end of all previous extensions that were included in appended at the end of all previous extensions that were included in
the Registration Request when the FA received it, and it SHOULD be the Registration Request when the FA received it, and it MUST be
protected by a Foreign-Foreign (FA-FA) Authentication extension (see protected by a Foreign-Foreign (FA-FA) Authentication extension (see
Section 11). Section 11).
5.3. GFA Considerations 5.3. GFA Considerations
For each pending or current home registration, the GFA maintains a For each pending or current home registration, the GFA maintains a
visitor list entry as described in [RFC3344]. This visitor list visitor list entry as described in [RFC3344]. This visitor list
entry is also updated for the regional registrations performed by the entry is also updated for the regional registrations performed by the
MN. In addition to the fields required in [RFC3344], the list entry MN. In addition to the fields required in [RFC3344], the list entry
MUST contain: MUST contain:
skipping to change at page 15, line 32 skipping to change at page 15, line 32
the FA). the FA).
When receiving a Registration Reply from the HA, the GFA MAY add a When receiving a Registration Reply from the HA, the GFA MAY add a
Regional Registration Lifetime extension to the message before Regional Registration Lifetime extension to the message before
relaying it to the FA. The extension defines the lifetime that the relaying it to the FA. The extension defines the lifetime that the
GFA allows the MN before it has to renew its regional registration. GFA allows the MN before it has to renew its regional registration.
The GFA MUST set the lifetime of the regional registration to be no The GFA MUST set the lifetime of the regional registration to be no
greater than the remaining lifetime of the MN's registration with its greater than the remaining lifetime of the MN's registration with its
HA. If used, the Regional Registration Lifetime extension MUST be HA. If used, the Regional Registration Lifetime extension MUST be
added after any other extensions, and MUST be protected. The added after any other extensions, and MUST be protected. The
Regional Registration Lifetime extension SHOULD be protected by an Regional Registration Lifetime extension MUST be protected by an
MN-FA Authentication extension. MN-FA Authentication extension.
5.4. Home Agent Considerations 5.4. Home Agent Considerations
The Registration Request is processed by the HA as described in The Registration Request is processed by the HA as described in
[RFC3344]. [RFC3344].
6. Regional Registration 6. Regional Registration
This section describes regional registrations. Once the HA has This section describes regional registrations. Once the HA has
skipping to change at page 16, line 14 skipping to change at page 16, line 14
visited domain. It will then receive an Agent Advertisement from the visited domain. It will then receive an Agent Advertisement from the
new FA. Suppose further that the Agent Advertisement indicates that new FA. Suppose further that the Agent Advertisement indicates that
the visited domain supports regional registrations, and that either the visited domain supports regional registrations, and that either
the advertised GFA address is the same as the one the MN has the advertised GFA address is the same as the one the MN has
registered as its care-of address during its last home registration, registered as its care-of address during its last home registration,
or that the realm part of the newly advertised FA-NAI matches the FA- or that the realm part of the newly advertised FA-NAI matches the FA-
NAI advertised by the MN's previous FA. Then, the MN can perform a NAI advertised by the MN's previous FA. Then, the MN can perform a
regional registration with this FA and GFA. The MN issues a Regional regional registration with this FA and GFA. The MN issues a Regional
Registration Request to the GFA via the new FA. The request is Registration Request to the GFA via the new FA. The request is
authenticated using the existing mobility security association authenticated using the existing mobility security association
between the GFA and the MN (either using the security association between the GFA and the MN and the message is authenticated by the
established during home registration, or using pre-configured keys) MN-GFA Authentication extension (see Section 11). The care-of
and the message is authenticated by the MN-GFA Authentication address should be set to the address of the local FA.
extension (see Section 11). The care-of address should be set to the
address of the local FA.
If the Regional Registration Request contains a care-of address field If the Regional Registration Request contains a care-of address field
of all-zeros, the FA adds a Hierarchical Foreign Agent (HFA) of all-zeros, the FA adds a Hierarchical Foreign Agent (HFA)
extension to the message and relays it to the GFA. Based on the extension to the message and relays it to the GFA. Based on the
information in the HFA extension, the GFA updates the MN's current information in the HFA extension, the GFA updates the MN's current
point of attachment in its visitor list. The GFA then issues a point of attachment in its visitor list. The GFA then issues a
Regional Registration Reply to the MN via the FA. Regional Registration Reply to the MN via the FA.
If the advertised GFA is not the same as the one the MN has If the advertised GFA is not the same as the one the MN has
registered as its care-of address, and if the MN is still within the registered as its care-of address, and if the MN is still within the
skipping to change at page 17, line 20 skipping to change at page 17, line 20
The replay protection for home registrations and regional The replay protection for home registrations and regional
registrations is performed as described in [RFC3344]. Since the MN registrations is performed as described in [RFC3344]. Since the MN
performs regional registrations at the GFA in parallel with home performs regional registrations at the GFA in parallel with home
registrations at the HA, the MN MUST be able to keep one replay registrations at the HA, the MN MUST be able to keep one replay
protection mechanism and sequence for the GFA, and a separate protection mechanism and sequence for the GFA, and a separate
mechanism and sequence for the HA. mechanism and sequence for the HA.
For regional registrations, replay protection may also be provided at For regional registrations, replay protection may also be provided at
the FA by the challenge-response mechanism, as described in the FA by the challenge-response mechanism, as described in
[RFC3012]. In this case, the MN inserts the 64 bit response value [RFC3012].
(timestamp or nonce, according to Mobile IPv4 [RFC3344]) in the
Identification field in the Regional Registration Request. Thus, the
GFA SHOULD expect such an Identification field.
6.2. Foreign Agent Considerations 6.2. Foreign Agent Considerations
When the FA receives a Regional Registration Request from a MN, When the FA receives a Regional Registration Request from a MN,
addressed to a GFA, it generally processes the message according to addressed to a GFA, it generally processes the message according to
the rules of processing a Registration Request addressed to a HA (see the rules of processing a Registration Request addressed to a HA (see
Section 5.2). The only difference is that the GFA IP address field Section 5.2). The only difference is that the GFA IP address field
replaces the HA address field. If that address belongs to a known replaces the HA address field. If that address belongs to a known
GFA, the FA forwards the request to the indicated GFA. Otherwise, GFA, the FA forwards the request to the indicated GFA. Otherwise,
the FA MUST generate a Regional Registration Reply with error code the FA MUST generate a Regional Registration Reply with error code
skipping to change at page 19, line 46 skipping to change at page 19, line 46
If the GFA does not support dynamic GFA assignment, it will deny the If the GFA does not support dynamic GFA assignment, it will deny the
request by sending a Registration Reply with the Code field set to request by sending a Registration Reply with the Code field set to
ZERO_COA_NOT_SUPP (see Section 9.5). ZERO_COA_NOT_SUPP (see Section 9.5).
7.4. Home Agent Considerations for Dynamic GFA Assignment 7.4. Home Agent Considerations for Dynamic GFA Assignment
If a HA receives a Registration Request with a GFA IP Address If a HA receives a Registration Request with a GFA IP Address
extension, and the HA does not allow the use of this extension, the extension, and the HA does not allow the use of this extension, the
HA MUST return a Registration Reply with the Code value set to HA MUST return a Registration Reply with the Code value set to
ZERO_COA_NOT_SUPP (see Section 9.5). DYN_GFA_NOT_SUPP (see Section 9.5).
If a HA receives a Registration Request message with the care-of If a HA receives a Registration Request message with the care-of
address set to all-zeros, but no GFA IP Address extension, it MUST address set to all-zeros, but no GFA IP Address extension, it MUST
deny the request by sending a Registration Reply message with the deny the request by sending a Registration Reply message with the
Code field set to ZERO_CAREOF_ADDRESS (see Section 9.5). Code field set to ZERO_CAREOF_ADDRESS (see Section 9.5).
If a HA that does not support dynamic GFA assignment receives a If a HA that does not support dynamic GFA assignment receives a
Registration Request with a GFA IP Address extension, the request Registration Request with a GFA IP Address extension, the request
will be denied by the HA, as described in [RFC3344]. will be denied by the HA, as described in [RFC3344].
skipping to change at page 22, line 31 skipping to change at page 22, line 31
GFA IP Address GFA IP Address
The GFA IP Address field contains the Gateway Foreign Agent's The GFA IP Address field contains the Gateway Foreign Agent's
(GFA) publicly routable address. (GFA) publicly routable address.
9.2. Hierarchical Foreign Agent Extension 9.2. Hierarchical Foreign Agent Extension
The Hierarchical Foreign Agent (HFA) extension may be present in a The Hierarchical Foreign Agent (HFA) extension may be present in a
Registration Request or Regional Registration Request. When a FA Registration Request or Regional Registration Request. When a FA
adds this extension to a Registration Request, the receiving mobility adds this extension to a Registration Request, the receiving mobility
agent sets up a pending registration record for the MN, using the IP agent (GFA) sets up a pending registration record for the MN, using
address in the HFA extension as the care-of address for the MN. the IP address in the HFA extension as the care-of address for the
Furthermore, in this case, the extension MUST be appended at the end MN. Furthermore, in this case, the extension MUST be appended at the
of all previous extensions that had been included in the registration end of all previous extensions that had been included in the
message as received by the FA. The HFA extension SHOULD be protected registration message as received by the FA. The HFA extension MUST
by an FA-FA Authentication extension. When the receiving FA receives be protected by an FA-FA Authentication extension. When the
the registration message, it MUST remove the HFA extension added by receiving mobility agent (GFA) receives the registration message, it
the sending FA. MUST remove the HFA extension added by the sending FA.
If a MN with a co-located care-of address adds the HFA extension to a
Registration Request the receiving mobility agent (GFA) sets up a
pending registration record for the MN, using the IP address in the
HFA extension as the care-of address for the MN. The extension MUST
be protected by an authentication extension. If the MN has
established a mobility security association with the GFA, the HFA
extension MUST be placed before the MN-FA Authentication extension,
and it SHOULD be placed after the Mobile-Home (MN-HA) Authentication
extension. Otherwise, if the MN has no established mobility security
association with the GFA, the HFA extension MUST be placed before the
MN-HA authentication extension. If the HFA extension is placed after
all other extensions, the receiving mobility agent (GFA) MUST remove
the HFA extension added by the MN. Otherwise, when the HA receives
the registration message, it ignores the HFA extension.
The Hierarchical Foreign Agent (HFA) Extension is defined as follows: The Hierarchical Foreign Agent (HFA) Extension is defined as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | reserved | | Type | Length | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA IP Address | | FA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 25, line 37 skipping to change at page 26, line 6
If the Code field indicates that the registration was accepted, If the Code field indicates that the registration was accepted,
the Regional Registration Lifetime field is set to the number of the Regional Registration Lifetime field is set to the number of
seconds remaining before the regional registration is considered seconds remaining before the regional registration is considered
expired. A value of zero indicates that the MN has been expired. A value of zero indicates that the MN has been
deregistered with the GFA. A value of 0xffff indicates infinity. deregistered with the GFA. A value of 0xffff indicates infinity.
If the Code field indicates that the home registration was denied, If the Code field indicates that the home registration was denied,
the contents of the Regional Registration Lifetime field are the contents of the Regional Registration Lifetime field are
unspecified and MUST be ignored on reception. unspecified and MUST be ignored on reception.
If the GFA adds a Regional Registration Lifetime extension to a If the GFA adds a Regional Registration Lifetime extension to a
Registration Reply, it SHOULD be placed before the MN-FA Registration Reply, it MUST be placed before the MN-FA Authentication
Authentication extension. The MN-FA Authentication extension should extension. The MN-FA Authentication extension should be based on
be based on security associations between the MN and GFA established security associations between the MN and GFA established during home
during home registration. registration.
9.5. New Code Values for Registration Reply 9.5. New Code Values for Registration Reply
The values to use within the Code field of the Registration Reply are The values to use within the Code field of the Registration Reply are
defined in [RFC3344]. In addition, the following values are defined: defined in [RFC3344]. In addition, the following values are defined:
Registration denied by the GFA: Registration denied by the GFA:
+---------------------+-------+---------------------+ +---------------------+-------+---------------------+
| Error Name | Value | Section of Document | | Error Name | Value | Section of Document |
skipping to change at page 26, line 20 skipping to change at page 26, line 31
| REPLAY_PROT_UNAVAIL | TBD | Section 5.3 | | REPLAY_PROT_UNAVAIL | TBD | Section 5.3 |
| ZERO_COA_NOT_SUPP | TBD | Section 7.3 | | ZERO_COA_NOT_SUPP | TBD | Section 7.3 |
+---------------------+-------+---------------------+ +---------------------+-------+---------------------+
Registration denied by the HA (for dynamic GFA assignment): Registration denied by the HA (for dynamic GFA assignment):
+---------------------+-----------+---------------------+ +---------------------+-----------+---------------------+
| Error Name | Value | Section of Document | | Error Name | Value | Section of Document |
+---------------------+-----------+---------------------+ +---------------------+-----------+---------------------+
| ZERO_CAREOF_ADDRESS | TBD | Section 7.4 | | ZERO_CAREOF_ADDRESS | TBD | Section 7.4 |
| ZERO_COA_NOT_SUPP | see above | Section 7.4 | | DYN_GFA_NOT_SUPP | see above | Section 7.4 |
+---------------------+-----------+---------------------+ +---------------------+-----------+---------------------+
10. Regional Registration Message Formats 10. Regional Registration Message Formats
This section specifies two new registration message types: Regional This section specifies two new registration message types: Regional
Registration Request and Regional Registration Reply. These messages Registration Request and Regional Registration Reply. These messages
are used by the MN instead of the existing Mobile IPv4 Registration are used by the MN instead of the existing Mobile IPv4 Registration
Request and Registration Reply, as described in Section 6. Request and Registration Reply, as described in Section 6.
Regional registration messages are protected by required Regional registration messages are protected by required
 End of changes. 18 change blocks. 
45 lines changed or deleted 55 lines changed or added

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