draft-ietf-hip-rfc5204-bis-00.txt   draft-ietf-hip-rfc5204-bis-01.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft QUALCOMM Inc. Internet-Draft Juniper Networks
Obsoletes: 5204 (if approved) L. Eggert Obsoletes: 5204 (if approved) L. Eggert
Intended status: Standards Track Nokia Intended status: Standards Track Nokia
Expires: February 21, 2011 August 20, 2010 Expires: September 15, 2011 March 14, 2011
Host Identity Protocol (HIP) Rendezvous Extension Host Identity Protocol (HIP) Rendezvous Extension
draft-ietf-hip-rfc5204-bis-00 draft-ietf-hip-rfc5204-bis-01
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.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 February 21, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
4.3. Modified Packets Processing . . . . . . . . . . . . . . . 10 4.3. Modified Packets Processing . . . . . . . . . . . . . . . 10
4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . . 10 4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . . 10
4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . . 11 4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . . 11
4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . . 11 4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . . 11
4.3.4. Processing Incoming R1 Packets . . . . . . . . . . . . 11 4.3.4. Processing Incoming R1 Packets . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Changes from RFC 5204 . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) Architecture [RFC4423] introduces The Host Identity Protocol (HIP) Architecture [RFC4423] introduces
the rendezvous mechanism to help a HIP node to contact a frequently the rendezvous mechanism to help a HIP node to contact a frequently
moving HIP node. The rendezvous mechanism involves a third party, moving HIP node. The rendezvous mechanism involves a third party,
the rendezvous server (RVS), which serves as an initial contact point the rendezvous server (RVS), which serves as an initial contact point
("rendezvous point") for its clients. The clients of an RVS are HIP ("rendezvous point") for its clients. The clients of an RVS are HIP
nodes that use the HIP Registration Extension [RFC5203] to register nodes that use the HIP Registration Extension
their HIT->IP address mappings with the RVS. After this [I-D.ietf-hip-rfc5203-bis] to register their HIT->IP address mappings
registration, other HIP nodes can initiate a base exchange using the with the RVS. After this registration, other HIP nodes can initiate
IP address of the RVS instead of the current IP address of the node a base exchange using the IP address of the RVS instead of the
they attempt to contact. Essentially, the clients of an RVS become current IP address of the node they attempt to contact. Essentially,
reachable at the RVS's IP address. Peers can initiate a HIP base the clients of an RVS become reachable at the RVS's IP address.
exchange with the IP address of the RVS, which will relay this Peers can initiate a HIP base exchange with the IP address of the
initial communication such that the base exchange may successfully RVS, which will relay this initial communication such that the base
complete. exchange may successfully complete.
2. Terminology 2. Terminology
This section defines terms used throughout the remainder of this This section defines terms used throughout the remainder of this
specification. specification.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
In addition to the terminology defined in the HIP specification In addition to the terminology defined in the HIP specification
[RFC5201] and the HIP Registration Extension [RFC5203], this document [I-D.ietf-hip-rfc5201-bis] and the HIP Registration Extension
defines and uses the following terms: [I-D.ietf-hip-rfc5203-bis], this document defines and uses the
following terms:
Rendezvous Service Rendezvous Service
A HIP service provided by a rendezvous server to its rendezvous A HIP service provided by a rendezvous server to its rendezvous
clients. The rendezvous server offers to relay some of the clients. The rendezvous server offers to relay some of the
arriving base exchange packets between the initiator and arriving base exchange packets between the initiator and
responder. responder.
Rendezvous Server (RVS) Rendezvous Server (RVS)
A HIP registrar providing rendezvous service. A HIP registrar providing rendezvous service.
skipping to change at page 4, line 10 skipping to change at page 4, line 10
Rendezvous Registration Rendezvous Registration
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 [RFC5201]. 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 specification [RFC5206] allows a HIP node to notify its Protocol specification [I-D.ietf-hip-rfc5206-bis] allows a HIP node
peers about changes in its set of IP addresses. This specification to notify its peers about changes in its set of IP addresses. This
presumes initial reachability of the two nodes with respect to each specification presumes initial reachability of the two nodes with
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 [RFC4423] introduces rendezvous servers with The HIP Architecture [RFC4423] introduces rendezvous servers with
whom a HIP node MAY register its host identity tags (HITs) and whom a HIP node MAY register its host identity tags (HITs) and
current IP addresses. An RVS relays HIP packets arriving for these current IP addresses. An RVS relays HIP packets arriving for these
HITs to the node's registered IP addresses. When a HIP node has HITs to the node's registered IP addresses. When a HIP node has
registered with an RVS, it SHOULD record the IP address of its RVS in registered with an RVS, it SHOULD record the IP address of its RVS in
its DNS record, using the HIP DNS resource record type defined in the its DNS record, using the HIP DNS resource record type defined in the
HIP DNS Extension [RFC5205]. 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
[RFC5203]. When the initiator I tries to establish contact with the [I-D.ietf-hip-rfc5203-bis]. When the initiator I tries to establish
responder R, it must send the I1 of the base exchange either to one contact with the responder R, it must send the I1 of the base
of R's IP addresses (if known via DNS or other means) or to one of exchange either to one of R's IP addresses (if known via DNS or other
R's rendezvous servers. Here, I obtains the IP address of R's means) or to one of R's rendezvous servers. Here, I obtains the IP
rendezvous server from R's DNS record and then sends the I1 packet of address of R's rendezvous server from R's DNS record and then sends
the HIP base exchange to RVS. RVS, noticing that the HIT contained the I1 packet of the HIP base exchange to RVS. RVS, noticing that
in the arriving I1 packet is not one of its own, MUST check its the HIT contained in the arriving I1 packet is not one of its own,
current registrations to determine if it needs to relay the packets. MUST check its current registrations to determine if it needs to
Here, it determines that the HIT belongs to R and then relays the I1 relay the packets. Here, it determines that the HIT belongs to R and
packet to the registered IP address. R then completes the base then relays the I1 packet to the registered IP address. R then
exchange without further assistance from RVS by sending an R1 completes the base exchange without further assistance from RVS by
directly to the I's IP address, as obtained from the I1 packet. In sending an R1 directly to the I's IP address, as obtained from the I1
this specification, the client of the RVS is always the responder. packet. In this specification, the client of the RVS is always the
However, there might be reasons to allow a client to initiate a base responder. However, there might be reasons to allow a client to
exchange through its own RVS, like NAT and firewall traversal. This initiate a base exchange through its own RVS, like NAT and firewall
specification does not address such scenarios, which should be traversal. This specification does not address such scenarios, which
specified in other documents. should be specified in other documents.
3.1. Diagram Notation 3.1. Diagram Notation
Notation Significance Notation Significance
-------- ------------ -------- ------------
I, R I and R are the respective source and destination IP I, R I and R are the respective source and destination IP
addresses in the IP header. addresses in the IP header.
HIT-I, HIT-R HIT-I and HIT-R are the initiator's and the HIT-I, HIT-R HIT-I and HIT-R are the initiator's and the
skipping to change at page 5, line 51 skipping to change at page 5, line 51
header. header.
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
[RFC5203] 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) | |
skipping to change at page 6, line 36 skipping to change at page 6, line 36
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][RFC3484]. 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 [RFC5203]. 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) +-----+
| |<---------------------------------------------| | | |<---------------------------------------------| |
skipping to change at page 7, line 39 skipping to change at page 7, line 39
any modifications. After modification, it MUST recompute the any modifications. After modification, it MUST recompute the
checksum field using the updated HIP header, which possibly included checksum field using the updated HIP header, which possibly included
new FROM and RVS_HMAC parameters, and a pseudo-header containing the new FROM and RVS_HMAC parameters, and a pseudo-header containing the
updated source and destination IP addresses. This enables the updated source and destination IP addresses. This enables the
responder to validate the checksum of the I1 packet "as is", without responder to validate the checksum of the I1 packet "as is", without
having to parse any FROM parameters. having to parse any FROM parameters.
4. Rendezvous Server Extensions 4. Rendezvous Server Extensions
This section describes extensions to the HIP Registration Extension This section describes extensions to the HIP Registration Extension
[RFC5203], allowing a HIP node to register with a rendezvous server [I-D.ietf-hip-rfc5203-bis], allowing a HIP node to register with a
for rendezvous service and notify the RVS aware of changes to its rendezvous server for rendezvous service and notify the RVS aware of
current location. It also describes an extension to the HIP changes to its current location. It also describes an extension to
specification [RFC5201] itself, allowing establishment of HIP the HIP specification [I-D.ietf-hip-rfc5201-bis] itself, allowing
associations via one or more HIP rendezvous server(s). establishment of HIP associations via one or more HIP rendezvous
server(s).
4.1. RENDEZVOUS Registration Type 4.1. RENDEZVOUS Registration Type
This specification defines an additional registration for the HIP This specification defines an additional registration for the HIP
Registration Extension [RFC5203] that allows registering with a Registration Extension [I-D.ietf-hip-rfc5203-bis] that allows
rendezvous server for rendezvous service. registering with a rendezvous server for rendezvous service.
Number Registration Type Number Registration Type
------ ----------------- ------ -----------------
1 RENDEZVOUS 1 RENDEZVOUS
4.2. Parameter Formats and Processing 4.2. Parameter Formats and Processing
4.2.1. RVS_HMAC Parameter 4.2.1. RVS_HMAC Parameter
The RVS_HMAC is a non-critical parameter whose only difference with The RVS_HMAC is a non-critical parameter whose only difference with
the HMAC parameter defined in the HIP specification [RFC5201] is its the HMAC parameter defined in the HIP specification
"type" code. This change causes it to be located after the FROM [I-D.ietf-hip-rfc5201-bis] is its "type" code. This change causes it
parameter (as opposed to the HMAC): to be located after the FROM parameter (as opposed to the HMAC):
Type 65500 Type 65500
Length Variable. Length in octets, excluding Type, Length, and Length Variable. Length in octets, excluding Type, Length, and
Padding. Padding.
HMAC HMAC computed over the HIP packet, excluding the HMAC HMAC computed over the HIP packet, excluding the
RVS_HMAC parameter and any following parameters. The RVS_HMAC parameter and any following parameters. The
HMAC is keyed with the appropriate HIP integrity key HMAC is keyed with the appropriate HIP integrity key
(HIP-lg or HIP-gl) established when rendezvous (HIP-lg or HIP-gl) established when rendezvous
registration happened. The HIP "checksum" field MUST be set registration happened. The HIP "checksum" field MUST be set
to zero, and the HIP header length in the HIP common header to zero, and the HIP header length in the HIP common header
skipping to change at page 11, line 41 skipping to change at page 11, line 41
been relayed. been relayed.
4.3.3. Processing Outgoing R1 Packets 4.3.3. Processing Outgoing R1 Packets
When a responder replies to an I1 relayed via an RVS, it MUST append When a responder replies to an I1 relayed via an RVS, it MUST append
to the regular R1 header a VIA_RVS parameter containing the IP to the regular R1 header a VIA_RVS parameter containing the IP
addresses of the traversed RVSs. addresses of the traversed RVSs.
4.3.4. Processing Incoming R1 Packets 4.3.4. Processing Incoming R1 Packets
The HIP specification [RFC5201] mandates that a system receiving an The HIP specification [I-D.ietf-hip-rfc5201-bis] mandates that a
R1 MUST first check to see if it has sent an I1 to the originator of system receiving an R1 MUST first check to see if it has sent an I1
the R1 (i.e., the system is in state I1-SENT). When the R1 is to the originator of the R1 (i.e., the system is in state I1-SENT).
replying to a relayed I1, this check SHOULD be based on HITs only. When the R1 is replying to a relayed I1, this check SHOULD be based
In case the IP addresses are also checked, then the source IP address on HITs only. In case the IP addresses are also checked, then the
MUST be checked against the IP address included in the VIA_RVS source IP address MUST be checked against the IP address included in
parameter. the VIA_RVS parameter.
5. Security Considerations 5. Security Considerations
This section discusses the known threats introduced by these HIP This section discusses the known threats introduced by these HIP
extensions and the implications on the overall security of HIP. In extensions and the implications on the overall security of HIP. In
particular, it argues that the extensions described in this document particular, it argues that the extensions described in this document
do not introduce additional threats to the Host Identity Protocol. do not introduce additional threats to the Host Identity Protocol.
It is difficult to encompass the whole scope of threats introduced by It is difficult to encompass the whole scope of threats introduced by
rendezvous servers because their presence has implications both at rendezvous servers because their presence has implications both at
skipping to change at page 13, line 5 skipping to change at page 13, line 5
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)
This document defines an additional registration for the HIP This document defines an additional registration for the HIP
Registration Extension [RFC5203] that allows registering with a Registration Extension [I-D.ietf-hip-rfc5203-bis] that allows
rendezvous server for rendezvous service. registering with a rendezvous server for rendezvous service.
Number Registration Type Number Registration Type
------ ----------------- ------ -----------------
1 RENDEZVOUS 1 RENDEZVOUS
7. Acknowledgments 7. Acknowledgments
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
[RFC1122] Braden, R., "Requirements for Internet Hosts - [I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and
Communication Layers", STD 3, RFC 1122, October 1989. T. Henderson, "Host Identity Protocol
Version 2 (HIPv2)",
draft-ietf-hip-rfc5201-bis-05 (work in
progress), March 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [I-D.ietf-hip-rfc5203-bis] Laganier, J., Koponen, T., and L. Eggert,
Requirement Levels", BCP 14, RFC 2119, March 1997. "Host Identity Protocol (HIP)
Registration Extension",
draft-ietf-hip-rfc5203-bis-00 (work in
progress), August 2010.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [I-D.ietf-hip-rfc5205-bis] Laganier, J., "Host Identity Protocol
IANA Considerations Section in RFCs", BCP 26, RFC 2434, (HIP) Domain Name System (DNS)
October 1998. Extension", draft-ietf-hip-rfc5205-bis-00
(work in progress), August 2010.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC1122] Braden, R., "Requirements for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Hosts - Communication Layers", STD 3,
RFC 1122, October 1989.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. [RFC2119] Bradner, S., "Key words for use in RFCs
Henderson, "Host Identity Protocol", RFC 5201, April 2008. to Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997.
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity [RFC2434] Narten, T. and H. Alvestrand, "Guidelines
Protocol (HIP) Registration Extension", RFC 5203, for Writing an IANA Considerations
April 2008. Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol [RFC3484] Draves, R., "Default Address Selection
(HIP) Domain Name System (DNS) Extensions", RFC 5205, for Internet Protocol version 6 (IPv6)",
April 2008. RFC 3484, February 2003.
8.2. Informative References 8.2. Informative References
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [I-D.ietf-hip-rfc5206-bis] Nikander, P., Henderson, T., Vogt, C.,
Defeating Denial of Service Attacks which employ IP Source and J. Arkko, "Host Mobility with the
Address Spoofing", BCP 38, RFC 2827, May 2000. Host Identity Protocol",
draft-ietf-hip-rfc5206-bis-01 (work in
progress), October 2010.
[RFC3013] Killalea, T., "Recommended Internet Service Provider [RFC2827] Ferguson, P. and D. Senie, "Network
Security Services and Procedures", BCP 46, RFC 3013, Ingress Filtering: Defeating Denial of
November 2000. Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827,
May 2000.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC3013] Killalea, T., "Recommended Internet
(HIP) Architecture", RFC 4423, May 2006. Service Provider Security Services and
Procedures", BCP 46, RFC 3013,
November 2000.
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming [RFC4423] Moskowitz, R. and P. Nikander, "Host
with the Host Identity Protocol", RFC 5206, April 2008. Identity Protocol (HIP) Architecture",
RFC 4423, May 2006.
Appendix A. Changes from RFC 5204
o Updated HIP references to revised HIP specifications.
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
QUALCOMM Incorporated Juniper Networks
5775 Morehouse Drive 1094 North Mathilda Avenue
San Diego, CA 92121 Sunnyvale, CA 94089
USA USA
Phone: +1 858 858 3538 Phone: +1 408 936 0385
EMail: julienl@qualcomm.com EMail: julien.ietf@gmail.com
Lars Eggert Lars Eggert
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
Nokia Group 00045 Nokia Group 00045
Finland Finland
Phone: +358 50 48 24461 Phone: +358 50 48 24461
EMail: lars.eggert@nokia.com EMail: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/ URI: http://research.nokia.com/people/lars_eggert/
 End of changes. 32 change blocks. 
94 lines changed or deleted 117 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/