draft-ietf-hip-rfc5204-bis-02.txt   draft-ietf-hip-rfc5204-bis-03.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft Juniper Networks Internet-Draft Luminate Wireless, Inc.
Obsoletes: 5204 (if approved) L. Eggert Obsoletes: 5204 (if approved) L. Eggert
Intended status: Standards Track NetApp Intended status: Standards Track NetApp
Expires: March 26, 2013 September 22, 2012 Expires: June 14, 2014 December 11, 2013
Host Identity Protocol (HIP) Rendezvous Extension Host Identity Protocol (HIP) Rendezvous Extension
draft-ietf-hip-rfc5204-bis-02 draft-ietf-hip-rfc5204-bis-03
Abstract Abstract
This document defines a rendezvous extension for the Host Identity This document defines a rendezvous extension for the Host Identity
Protocol (HIP). The rendezvous extension extends HIP and the HIP Protocol (HIP). The rendezvous extension extends HIP and the HIP
registration extension for initiating communication between HIP nodes registration extension for initiating communication between HIP nodes
via HIP rendezvous servers. Rendezvous servers improve reachability via HIP rendezvous servers. Rendezvous servers improve reachability
and operation when HIP nodes are multi-homed or mobile. and operation when HIP nodes are multi-homed or mobile. This
document obsoletes RFC5204.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on March 26, 2013. This Internet-Draft will expire on June 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4 3. Overview of Rendezvous Server Operation . . . . . . . . . . . 3
3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . . 5 3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . 5
3.2. Rendezvous Client Registration . . . . . . . . . . . . . . 6 3.2. Rendezvous Client Registration . . . . . . . . . . . . . 5
3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . . 6 3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . 5
4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 7 4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . 7
4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 7 4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . 7
4.2. Parameter Formats and Processing . . . . . . . . . . . . . 8 4.2. Parameter Formats and Processing . . . . . . . . . . . . 7
4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 8 4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . 7
4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . . 9 4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . 8
4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 10 4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 8
4.3. Modified Packets Processing . . . . . . . . . . . . . . . 10 4.3. Modified Packets Processing . . . . . . . . . . . . . . . 9
4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . . 10 4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . 9
4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . . 11 4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . 10
4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . . 11 4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . 10
4.3.4. Processing Incoming R1 Packets . . . . . . . . . . . . 11 4.3.4. Processing Incoming R1 Packets . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from RFC 5204 . . . . . . . . . . . . . . . . 14 Appendix A. Changes from RFC 5204 . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) Architecture The Host Identity Protocol (HIP) Architecture
[I-D.ietf-hip-rfc4423-bis] introduces the rendezvous mechanism to [I-D.ietf-hip-rfc4423-bis] introduces the rendezvous mechanism to
help a HIP node to contact a frequently moving HIP node. The help a HIP node to contact a frequently moving HIP node. The
rendezvous mechanism involves a third party, the rendezvous server rendezvous mechanism involves a third party, the rendezvous server
(RVS), which serves as an initial contact point ("rendezvous point") (RVS), which serves as an initial contact point ("rendezvous point")
for its clients. The clients of an RVS are HIP nodes that use the for its clients. The clients of an RVS are HIP nodes that use the
HIP Registration Extension [I-D.ietf-hip-rfc5203-bis] to register HIP Registration Extension [I-D.ietf-hip-rfc5203-bis] to register
skipping to change at page 4, line 16 skipping to change at page 3, line 43
A HIP registration for rendezvous service, established between a A HIP registration for rendezvous service, established between a
rendezvous server and a rendezvous client. rendezvous server and a rendezvous client.
3. Overview of Rendezvous Server Operation 3. Overview of Rendezvous Server Operation
Figure 1 shows a simple HIP base exchange without a rendezvous Figure 1 shows a simple HIP base exchange without a rendezvous
server, in which the initiator initiates the exchange directly with server, in which the initiator initiates the exchange directly with
the responder by sending an I1 packet to the responder's IP address, the responder by sending an I1 packet to the responder's IP address,
as per the HIP specification [I-D.ietf-hip-rfc5201-bis]. as per the HIP specification [I-D.ietf-hip-rfc5201-bis].
+-----+ +-----+ +-----+ +-----+
| |-------I1------>| | | |-------I1------>| |
| I |<------R1-------| R | | I |<------R1-------| R |
| |-------I2------>| | | |-------I2------>| |
| |<------R2-------| | | |<------R2-------| |
+-----+ +-----+ +-----+ +-----+
Figure 1: HIP base exchange without rendezvous server. Figure 1: HIP base exchange without rendezvous server.
The End-Host Mobility and Multihoming with the Host Identity The End-Host Mobility and Multihoming with the Host Identity Protocol
Protocol specification [I-D.ietf-hip-rfc5206-bis] allows a HIP node specification [I-D.ietf-hip-rfc5206-bis] allows a HIP node to notify
to notify its peers about changes in its set of IP addresses. This its peers about changes in its set of IP addresses. This
specification presumes initial reachability of the two nodes with specification presumes initial reachability of the two nodes with
respect to each other. respect to each other.
However, such a HIP node MAY also want to be reachable to other However, such a HIP node MAY also want to be reachable to other
future correspondent peers that are unaware of its location change. future correspondent peers that are unaware of its location change.
The HIP Architecture [I-D.ietf-hip-rfc4423-bis] introduces rendezvous The HIP Architecture [I-D.ietf-hip-rfc4423-bis] introduces rendezvous
servers with whom a HIP node MAY register its host identity tags servers with whom a HIP node MAY register its host identity tags
(HITs) and current IP addresses. An RVS relays HIP packets arriving (HITs) and current IP addresses. An RVS relays HIP packets arriving
for these HITs to the node's registered IP addresses. When a HIP for these HITs to the node's registered IP addresses. When a HIP
node has registered with an RVS, it SHOULD record the IP address of node has registered with an RVS, it SHOULD record the IP address of
its RVS in its DNS record, using the HIP DNS resource record type its RVS in its DNS record, using the HIP DNS resource record type
defined in the HIP DNS Extension [I-D.ietf-hip-rfc5205-bis]. defined in the HIP DNS Extension [I-D.ietf-hip-rfc5205-bis].
+-----+ +-----+
+--I1--->| RVS |---I1--+ +--I1--->| RVS |---I1--+
| +-----+ | | +-----+ |
| v | v
+-----+ +-----+ +-----+ +-----+
| |<------R1-------| | | |<------R1-------| |
| I |-------I2------>| R | | I |-------I2------>| R |
| |<------R2-------| | | |<------R2-------| |
+-----+ +-----+ +-----+ +-----+
Figure 2: HIP base exchange with a rendezvous server. Figure 2: HIP base exchange with a rendezvous server.
Figure 2 shows a HIP base exchange involving a rendezvous server. It Figure 2 shows a HIP base exchange involving a rendezvous server. It
is assumed that HIP node R previously registered its HITs and current is assumed that HIP node R previously registered its HITs and current
IP addresses with the RVS, using the HIP Registration Extension IP addresses with the RVS, using the HIP Registration Extension
[I-D.ietf-hip-rfc5203-bis]. When the initiator I tries to establish [I-D.ietf-hip-rfc5203-bis]. When the initiator I tries to establish
contact with the responder R, it must send the I1 of the base contact with the responder R, it must send the I1 of the base
exchange either to one of R's IP addresses (if known via DNS or other exchange either to one of R's IP addresses (if known via DNS or other
means) or to one of R's rendezvous servers. Here, I obtains the IP means) or to one of R's rendezvous servers. Here, I obtains the IP
skipping to change at page 6, line 12 skipping to change at page 5, line 37
VIA:RVS A VIA_RVS parameter containing the IP address RVS of a VIA:RVS A VIA_RVS parameter containing the IP address RVS of a
rendezvous server is present in the HIP header. rendezvous server is present in the HIP header.
3.2. Rendezvous Client Registration 3.2. Rendezvous Client Registration
Before a rendezvous server starts to relay HIP packets to a Before a rendezvous server starts to relay HIP packets to a
rendezvous client, the rendezvous client needs to register with it to rendezvous client, the rendezvous client needs to register with it to
receive rendezvous service by using the HIP Registration Extension receive rendezvous service by using the HIP Registration Extension
[I-D.ietf-hip-rfc5203-bis] as illustrated in the following schema: [I-D.ietf-hip-rfc5203-bis] as illustrated in the following schema:
+-----+ +-----+ +-----+ +-----+
| | I1 | | | | I1 | |
| |--------------------------->| | | |--------------------------->| |
| |<---------------------------| | | |<---------------------------| |
| I | R1(REG_INFO) | RVS | | I | R1(REG_INFO) | RVS |
| | I2(REG_REQ) | | | | I2(REG_REQ) | |
| |--------------------------->| | | |--------------------------->| |
| |<---------------------------| | | |<---------------------------| |
| | R2(REG_RES) | | | | R2(REG_RES) | |
+-----+ +-----+ +-----+ +-----+
Rendezvous client registering with a rendezvous server. Rendezvous client registering with a rendezvous server.
3.3. Relaying the Base Exchange 3.3. Relaying the Base Exchange
If a HIP node and one of its rendezvous servers have a rendezvous If a HIP node and one of its rendezvous servers have a rendezvous
registration, the rendezvous servers relay inbound I1 packets (that registration, the rendezvous servers relay inbound I1 packets (that
contain one of the client's HITs) by rewriting the IP header. They contain one of the client's HITs) by rewriting the IP header. They
replace the destination IP address of the I1 packet with one of the replace the destination IP address of the I1 packet with one of the
IP addresses of the owner of the HIT, i.e., the rendezvous client. IP addresses of the owner of the HIT, i.e., the rendezvous client.
They MUST also recompute the IP checksum accordingly. They MUST also recompute the IP checksum accordingly.
Because of egress filtering on the path from the RVS to the client Because of egress filtering on the path from the RVS to the client
[RFC2827][RFC3013], a HIP rendezvous server SHOULD replace the source [RFC2827][RFC3013], a HIP rendezvous server SHOULD replace the source
IP address, i.e., the IP address of I, with one of its own IP IP address, i.e., the IP address of I, with one of its own IP
skipping to change at page 6, line 38 skipping to change at page 6, line 15
registration, the rendezvous servers relay inbound I1 packets (that registration, the rendezvous servers relay inbound I1 packets (that
contain one of the client's HITs) by rewriting the IP header. They contain one of the client's HITs) by rewriting the IP header. They
replace the destination IP address of the I1 packet with one of the replace the destination IP address of the I1 packet with one of the
IP addresses of the owner of the HIT, i.e., the rendezvous client. IP addresses of the owner of the HIT, i.e., the rendezvous client.
They MUST also recompute the IP checksum accordingly. They MUST also recompute the IP checksum accordingly.
Because of egress filtering on the path from the RVS to the client Because of egress filtering on the path from the RVS to the client
[RFC2827][RFC3013], a HIP rendezvous server SHOULD replace the source [RFC2827][RFC3013], a HIP rendezvous server SHOULD replace the source
IP address, i.e., the IP address of I, with one of its own IP IP address, i.e., the IP address of I, with one of its own IP
addresses. The replacement IP address SHOULD be chosen according to addresses. The replacement IP address SHOULD be chosen according to
relevant IPv4 and IPv6 specifications [RFC1122][RFC3484]. Because relevant IPv4 and IPv6 specifications [RFC1122][RFC6724]. Because
this replacement conceals the initiator's IP address, the RVS MUST this replacement conceals the initiator's IP address, the RVS MUST
append a FROM parameter containing the original source IP address of append a FROM parameter containing the original source IP address of
the packet. This FROM parameter MUST be integrity protected by an the packet. This FROM parameter MUST be integrity protected by an
RVS_HMAC keyed with the corresponding rendezvous registration RVS_HMAC keyed with the corresponding rendezvous registration
integrity key [I-D.ietf-hip-rfc5203-bis]. integrity key [I-D.ietf-hip-rfc5203-bis].
I1(RVS, R, HIT-I, HIT-R I1(RVS, R, HIT-I, HIT-R
I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC) I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC)
+----------------------->| |--------------------+ +----------------------->| |--------------------+
| | RVS | | | | RVS | |
| | | | | | | |
| +---------+ | | +---------+ |
| V | V
+-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+ +-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+
| |<---------------------------------------------| | | |<---------------------------------------------| |
| | | | | | | |
| I | I2(I, R, HIT-I, HIT-R) | R | | I | I2(I, R, HIT-I, HIT-R) | R |
| |--------------------------------------------->| | | |--------------------------------------------->| |
| |<---------------------------------------------| | | |<---------------------------------------------| |
+-----+ R2(R, I, HIT-R, HIT-I) +-----+ +-----+ R2(R, I, HIT-R, HIT-I) +-----+
Rendezvous server rewriting IP addresses. Rendezvous server rewriting IP addresses.
This modification of HIP packets at a rendezvous server can be This modification of HIP packets at a rendezvous server can be
problematic because the HIP protocol uses integrity checks. Because problematic because the HIP protocol uses integrity checks. Because
the I1 does not include HMAC or SIGNATURE parameters, these two end- the I1 does not include HMAC or SIGNATURE parameters, these two end-
to-end integrity checks are unaffected by the operation of rendezvous to-end integrity checks are unaffected by the operation of rendezvous
servers. servers.
The RVS SHOULD verify the checksum field of an I1 packet before doing The RVS SHOULD verify the checksum field of an I1 packet before doing
skipping to change at page 12, line 40 skipping to change at page 11, line 33
that originally sent the I1. This procedure retains a level of that originally sent the I1. This procedure retains a level of
security that is equivalent to what exists in the Internet today. security that is equivalent to what exists in the Internet today.
However, for reasons of simplicity, this specification does not allow However, for reasons of simplicity, this specification does not allow
the establishment of a HIP association via a rendezvous server in an the establishment of a HIP association via a rendezvous server in an
opportunistic manner. opportunistic manner.
6. IANA Considerations 6. IANA Considerations
This section is to be interpreted according to the Guidelines for This section is to be interpreted according to the Guidelines for
Writing an IANA Considerations Section in RFCs [RFC2434]. Writing an IANA Considerations Section in RFCs [RFC5226].
This document updates the IANA Registry for HIP Parameters Types by This document updates the IANA Registry for HIP Parameters Types by
assigning new HIP Parameter Types values for the new HIP Parameters assigning new HIP Parameter Types values for the new HIP Parameters
defined in Section 4.2: defined in Section 4.2:
o RVS_HMAC (defined in Section 4.2.1) o RVS_HMAC (defined in Section 4.2.1)
o FROM (defined in Section 4.2.2) o FROM (defined in Section 4.2.2)
o VIA_RVS (defined in Section 4.2.3) o VIA_RVS (defined in Section 4.2.3)
skipping to change at page 13, line 24 skipping to change at page 12, line 17
The following people have provided thoughtful and helpful discussions The following people have provided thoughtful and helpful discussions
and/or suggestions that have improved this document: Marcus Brunner, and/or suggestions that have improved this document: Marcus Brunner,
Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Justino Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Justino
Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin
Stiemerling, and Juergen Quittek. Stiemerling, and Juergen Quittek.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and [I-D.ietf-hip-rfc5201-bis]
T. Henderson, "Host Identity Protocol Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
Version 2 (HIPv2)", "Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
draft-ietf-hip-rfc5201-bis-09 (work in hip-rfc5201-bis-14 (work in progress), October 2013.
progress), July 2012.
[I-D.ietf-hip-rfc5203-bis] Laganier, J., Koponen, T., and L. Eggert, [I-D.ietf-hip-rfc5203-bis]
"Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", Registration Extension", draft-ietf-hip-rfc5203-bis-02
draft-ietf-hip-rfc5203-bis-01 (work in (work in progress), September 2012.
progress), March 2011.
[I-D.ietf-hip-rfc5205-bis] Laganier, J., "Host Identity Protocol [I-D.ietf-hip-rfc5205-bis]
(HIP) Domain Name System (DNS) Laganier, J., "Host Identity Protocol (HIP) Domain Name
Extension", draft-ietf-hip-rfc5205-bis-01 System (DNS) Extension", draft-ietf-hip-rfc5205-bis-02
(work in progress), March 2011. (work in progress), September 2012.
[RFC1122] Braden, R., "Requirements for Internet [RFC1122] Braden, R., "Requirements for Internet Hosts -
Hosts - Communication Layers", STD 3, Communication Layers", STD 3, RFC 1122, October 1989.
RFC 1122, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
to Indicate Requirement Levels", BCP 14, Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
for Writing an IANA Considerations IANA Considerations Section in RFCs", BCP 26, RFC 5226,
Section in RFCs", BCP 26, RFC 2434, May 2008.
October 1998.
[RFC3484] Draves, R., "Default Address Selection [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
for Internet Protocol version 6 (IPv6)", "Default Address Selection for Internet Protocol Version 6
RFC 3484, February 2003. (IPv6)", RFC 6724, September 2012.
8.2. Informative References 8.2. Informative References
[I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol [I-D.ietf-hip-rfc4423-bis]
Architecture", Moskowitz, R. and M. Komu, "Host Identity Protocol
draft-ietf-hip-rfc4423-bis-04 (work in Architecture", draft-ietf-hip-rfc4423-bis-06 (work in
progress), July 2012. progress), November 2013.
[I-D.ietf-hip-rfc5206-bis] Henderson, T., Vogt, C., and J. Arkko, [I-D.ietf-hip-rfc5206-bis]
"Host Mobility with the Host Identity Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with
Protocol", draft-ietf-hip-rfc5206-bis-04 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-06
(work in progress), July 2012. (work in progress), July 2013.
[RFC2827] Ferguson, P. and D. Senie, "Network [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Ingress Filtering: Defeating Denial of Defeating Denial of Service Attacks which employ IP Source
Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
Address Spoofing", BCP 38, RFC 2827,
May 2000.
[RFC3013] Killalea, T., "Recommended Internet [RFC3013] Killalea, T., "Recommended Internet Service Provider
Service Provider Security Services and Security Services and Procedures", BCP 46, RFC 3013,
Procedures", BCP 46, RFC 3013, November 2000.
November 2000.
Appendix A. Changes from RFC 5204 Appendix A. Changes from RFC 5204
o Updated HIP references to revised HIP specifications. o Updated HIP references to revised HIP specifications.
o Added relaying of UPDATE packets to support double jump mobility o Added relaying of UPDATE packets to support double jump mobility
scenario. scenario.
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
Juniper Networks Luminate Wireless, Inc.
1094 North Mathilda Avenue Cupertino, CA
Sunnyvale, CA 94089
USA USA
Phone: +1 408 936 0385
EMail: julien.ietf@gmail.com EMail: julien.ietf@gmail.com
Lars Eggert Lars Eggert
NetApp NetApp
Sonnenallee 1 Sonnenallee 1
Kirchheim 85551 Kirchheim 85551
Germany Germany
Phone: +49 151 12055791 Phone: +49 151 12055791
EMail: lars@netapp.com EMail: lars@netapp.com
URI: http://eggert.org URI: http://eggert.org
 End of changes. 29 change blocks. 
123 lines changed or deleted 114 lines changed or added

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