draft-ietf-hip-registration-00.txt   draft-ietf-hip-registration-01.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft DoCoMo Euro-Labs Internet-Draft DoCoMo Euro-Labs
Expires: March 24, 2006 T. Koponen Expires: June 19, 2006 T. Koponen
HIIT HIIT
L. Eggert L. Eggert
NEC NEC
September 20, 2005 December 16, 2005
Host Identity Protocol (HIP) Registration Extension Host Identity Protocol (HIP) Registration Extension
draft-ietf-hip-registration-00 draft-ietf-hip-registration-01
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 37 skipping to change at page 1, line 37
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 24, 2006. This Internet-Draft will expire on June 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document specifies a registration mechanism for the Host This document specifies a registration mechanism for the Host
Identity Protocol (HIP) that allows hosts to register with services, Identity Protocol (HIP) that allows hosts to register with services,
such as HIP rendezvous servers or middleboxes. such as HIP rendezvous servers or middleboxes.
skipping to change at page 3, line 14 skipping to change at page 3, line 14
3. HIP Registration Extension Overview 3. HIP Registration Extension Overview
This document does not specify the means by which a requester This document does not specify the means by which a requester
discovers the availability of a service, or how a requester locates a discovers the availability of a service, or how a requester locates a
registrar. After a requester has discovered a registrar, it either registrar. After a requester has discovered a registrar, it either
initiates HIP base exchange or uses an existing HIP association with initiates HIP base exchange or uses an existing HIP association with
the registrar. In both cases, registrars use additional parameters the registrar. In both cases, registrars use additional parameters
that the remainder of this document defines to announce their quality that the remainder of this document defines to announce their quality
and grant or refuse registration. Requesters use corresponding and grant or refuse registration. Requesters use corresponding
parameters to register with the service. The following sections parameters to register with the service. Both the registrar and the
describe the differences between this registration handshake and the requester MAY also include in the messages exchanged additional HIP
standard HIP base exchange [I-D.ietf-hip-base] . parameters specific to the registration type implicated. Other
documents will define parameters and how they shall be used. The
following sections describe the differences between this registration
handshake and the standard HIP base exchange [I-D.ietf-hip-base] .
3.1 Registrar Announcing its Ability 3.1. Registrar Announcing its Ability
A host that is capable and willing to act as a registrar SHOULD A host that is capable and willing to act as a registrar SHOULD
include a REG_INFO parameter in the R1 packets it sends during all include a REG_INFO parameter in the R1 packets it sends during all
base exchanges. If it is currently unable to provide services due to base exchanges. If it is currently unable to provide services due to
transient conditions, it SHOULD include an empty REG_INFO, i.e., one transient conditions, it SHOULD include an empty REG_INFO, i.e., one
with no services listed. If services can be provided later, it with no services listed. If services can be provided later, it
SHOULD send UPDATE packets indicating the current set of services SHOULD send UPDATE packets indicating the current set of services
available in a new REG_INFO parameter to all hosts it is associated available in a new REG_INFO parameter to all hosts it is associated
with. with.
3.2 Requester Requesting Registration 3.2. Requester Requesting Registration
To request registration with a service, a requester constructs and To request registration with a service, a requester constructs and
includes a corresponding REG_REQUEST parameter in an I2 or UPDATE includes a corresponding REG_REQUEST parameter in an I2 or UPDATE
packet it sends to the registrar. packet it sends to the registrar.
If the requester has no HIP association established with the If the requester has no HIP association established with the
registrar, it SHOULD already send the REG_REQUEST in the I2 packet. registrar, it SHOULD already send the REG_REQUEST in the I2 packet.
This minimizes the number of packets that need to be exchanged with This minimizes the number of packets that need to be exchanged with
the registrar. A registrar MAY end a HIP association that does not the registrar. A registrar MAY end a HIP association that does not
carry a REG_REQUEST by including a NOTIFY with the type REG_REQUIRED carry a REG_REQUEST by including a NOTIFY with the type REG_REQUIRED
in the R2. In this case, no HIP association is created between the in the R2. In this case, no HIP association is created between the
hosts. The REG_REQUIRED notification error type is TBD. hosts. The REG_REQUIRED notification error type is TBD.
3.3 Registrar Granting or Refusing Service(s) Registration 3.3. Registrar Granting or Refusing Service(s) Registration
Once registration has been requested, the registrar is able to Once registration has been requested, the registrar is able to
authenticate the requester based on the host identity included in I2. authenticate the requester based on the host identity included in I2.
It then verifies the host identity is authorized to register with the It then verifies the host identity is authorized to register with the
requested service(s), based on local policies. The details of this requested service(s), based on local policies. The details of this
authorization procedure depend on the type of requested service(s) authorization procedure depend on the type of requested service(s)
and on the local policies of the registrar, and are therefore not and on the local policies of the registrar, and are therefore not
further specified in this document. further specified in this document.
After authorization, the registrar includes in its response (i.e., an After authorization, the registrar includes in its response (i.e., an
skipping to change at page 4, line 19 skipping to change at page 4, line 21
type(s) for which it has authorized registration, and zero or more type(s) for which it has authorized registration, and zero or more
REG_FAILED parameter containing the service(s) type(s) for which it REG_FAILED parameter containing the service(s) type(s) for which it
has not authorized registration or registration has failed for other has not authorized registration or registration has failed for other
reasons. In particular, REG_FAILED with a failure type of zero reasons. In particular, REG_FAILED with a failure type of zero
indicates the service(s) type(s) that require further credentials for indicates the service(s) type(s) that require further credentials for
registration. registration.
If the registrar requires further authorization and the requester has If the registrar requires further authorization and the requester has
additional credentials available, the requester SHOULD try to again additional credentials available, the requester SHOULD try to again
register with the service after the HIP association has been register with the service after the HIP association has been
established. established. The precise means of establishing and verifying
credentials are beyond the scope of this document and are expected to
be defined in other documents.
Successful processing of a REG_RESPONSE parameter creates Successful processing of a REG_RESPONSE parameter creates
registration state at the requester. In a similar manner, successful registration state at the requester. In a similar manner, successful
processing of a REG_REQUEST parameter creates registration state at processing of a REG_REQUEST parameter creates registration state at
the registrar and possibly at the service. Both the requester and the registrar and possibly at the service. Both the requester and
registrar can cancel a registration before it expires, if the registrar can cancel a registration before it expires, if the
services afforded by a registration are no longer needed by the services afforded by a registration are no longer needed by the
requester, or cannot be provided any longer by the registrar (for requester, or cannot be provided any longer by the registrar (for
instance, because its configuration has changed). instance, because its configuration has changed).
skipping to change at page 5, line 10 skipping to change at page 5, line 18
| | UPDATE(REG_REQ:S) | | | | | UPDATE(REG_REQ:S) | | |
| | UPDATE(REG_RESP:S) | | | | | UPDATE(REG_RESP:S) | | |
| |<---------------------| | | | |<---------------------| | |
+-----+ +-----+-----+ +-----+ +-----+-----+
4. Parameter Formats and Processing 4. Parameter Formats and Processing
This section describes the format and processing of the new This section describes the format and processing of the new
parameters introduced by the HIP registration extension. parameters introduced by the HIP registration extension.
4.1 Encoding Registration Lifetimes with Exponents 4.1. Encoding Registration Lifetimes with Exponents
The HIP registration uses an exponential encoding of registration The HIP registration uses an exponential encoding of registration
lifetimes. This allows compact encoding of 255 different lifetime lifetimes. This allows compact encoding of 255 different lifetime
values ranging from 4 ms to 178 days into an 8-bit integer field. values ranging from 4 ms to 178 days into an 8-bit integer field.
The lifetime exponent field used throughout this document MUST be The lifetime exponent field used throughout this document MUST be
interpreted as representing the lifetime value 2^((lifetime - 64)/8) interpreted as representing the lifetime value 2^((lifetime - 64)/8)
seconds. seconds.
4.2 REG_INFO 4.2. REG_INFO
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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 | | Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reg Type #3 | | | ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+ Padding + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA (930) ] Type [ TBD by IANA (930) ]
Length Length in octets, excluding Type, Length, and Padding. Length Length in octets, excluding Type, Length, and Padding.
Min Lifetime Minimum registration lifetime. Min Lifetime Minimum registration lifetime.
Max Lifetime Maximum registration lifetime. Max Lifetime Maximum registration lifetime.
Reg Type The registration types offered by the registrar. Reg Type The registration types offered by the registrar.
Other documents will define specific values for registration types. Other documents will define specific values for registration types.
skipping to change at page 6, line 5 skipping to change at page 7, line 5
Reg Type Service Reg Type Service
-------- ------- -------- -------
0-200 Reserved by IANA 0-200 Reserved by IANA
201-255 Reserved by IANA for private use 201-255 Reserved by IANA for private use
Registrars include the parameter in R1 packets in order to announce Registrars include the parameter in R1 packets in order to announce
their registration capabilities. The registrar SHOULD include the their registration capabilities. The registrar SHOULD include the
parameter in UPDATE packets when its service offering has changed. parameter in UPDATE packets when its service offering has changed.
HIP_SIGNATURE_2 protects the parameter within the R1 packets. HIP_SIGNATURE_2 protects the parameter within the R1 packets.
4.3 REG_REQUEST 4.3. REG_REQUEST
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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reg Type #1 | Reg Type #2 | Padding | | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA (932) ] Type [ TBD by IANA (932) ]
Length Length in octets, excluding Type, Length, and Padding. Length Length in octets, excluding Type, Length, and Padding.
Lifetime Requested registration lifetime. Lifetime Requested registration lifetime.
Reg Type The preferred registration types in order of preference. Reg Type The preferred registration types in order of preference.
Other documents will define specific values for registration types. Other documents will define specific values for registration types.
Reg Type Service Reg Type Service
skipping to change at page 7, line 5 skipping to change at page 8, line 5
one or more REG_REQUEST parameters in received I2 or UPDATE packets. one or more REG_REQUEST parameters in received I2 or UPDATE packets.
When the registrar is requested a registration which lifetime is When the registrar is requested a registration which lifetime is
either smaller or greater than the minimum or maximum lifetime, either smaller or greater than the minimum or maximum lifetime,
respectively, then it SHOULD grant the registration for the minimum respectively, then it SHOULD grant the registration for the minimum
or maximum lifetime, respectively. or maximum lifetime, respectively.
HIP_SIGNATURE protects the parameter within the I2 and UPDATE HIP_SIGNATURE protects the parameter within the I2 and UPDATE
packets. packets.
4.4 REG_RESPONSE 4.4. REG_RESPONSE
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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reg Type #1 | Reg Type #2 | Padding | | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA (934) ] Type [ TBD by IANA (934) ]
Length Length in octets, excluding Type, Length, and Padding. Length Length in octets, excluding Type, Length, and Padding.
Lifetime Granted registration lifetime. Lifetime Granted registration lifetime.
Reg Type The granted registration types in order of preference. Reg Type The granted registration types in order of preference.
Other documents will define specific values for registration types. Other documents will define specific values for registration types.
Reg Type Service Reg Type Service
skipping to change at page 8, line 5 skipping to change at page 9, line 5
The requester MUST be prepared to receive any registration lifetime, The requester MUST be prepared to receive any registration lifetime,
included ones beyond the minimum and maximum lifetime indicated in included ones beyond the minimum and maximum lifetime indicated in
the REG_INFO parameter. It MUST NOT expect that the returned the REG_INFO parameter. It MUST NOT expect that the returned
lifetime will be the requested one, even in the case that the lifetime will be the requested one, even in the case that the
requested lifetime falls within the announced minimum and maximum. requested lifetime falls within the announced minimum and maximum.
HIP_SIGNATURE protects the parameter within the R2 and UPDATE HIP_SIGNATURE protects the parameter within the R2 and UPDATE
packets. packets.
4.5 REG_FAILED 4.5. REG_FAILED
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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure Type | Reg Type #1 | Reg Type #n | Padding | | Failure Type | Reg Type #1 | Reg Type #2 | Reg Type #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA (936) ] Type [ TBD by IANA (936) ]
Length Length in octets, excluding Type, Length, and Padding. Length Length in octets, excluding Type, Length, and Padding.
Failure Type Reason for failure. Failure Type Reason for failure.
Reg Type The registration types that failed with the specified Reg Type The registration types that failed with the specified
reason. reason.
Other documents will define specific values for registration types. Other documents will define specific values for registration types.
skipping to change at page 8, line 37 skipping to change at page 9, line 41
Failure Type Reason Failure Type Reason
------------ -------------------------------------------- ------------ --------------------------------------------
0 Registration requires additional credentials 0 Registration requires additional credentials
1 Registration type unavailable 1 Registration type unavailable
2-200 Reserved by IANA 2-200 Reserved by IANA
201-255 Reserved by IANA for private use 201-255 Reserved by IANA for private use
A failure type of zero means a registrar requires additional A failure type of zero means a registrar requires additional
credentials to authorize a requester to register with the credentials to authorize a requester to register with the
registration types listed in the parameter. Other failure types than registration types listed in the parameter. A failure type of one
zero have not been defined. means that the requested service type is unavailable at the
registrar. Other failure types than zero (0) and one (1) have not
been defined.
The registrar SHOULD include the REG_FAILED parameter in its R2 or The registrar SHOULD include the REG_FAILED parameter in its R2 or
UPDATE packet, if registration with the registration types listed has UPDATE packet, if registration with the registration types listed has
not completed successfully and a requester is asked to try again with not completed successfully and a requester is asked to try again with
additional credentials. additional credentials.
HIP_SIGNATURE protects the parameter within the R2 and UPDATE HIP_SIGNATURE protects the parameter within the R2 and UPDATE
packets. packets.
5. Establishing and Maintaining Registrations 5. Establishing and Maintaining Registrations
Establishing and/or maintaining a registration may require additional Establishing and/or maintaining a registration may require additional
information not available in the transmitted REG_REQUEST or information not available in the transmitted REG_REQUEST or
REG_RESPONSE parameters. Therefore, registration type definitions REG_RESPONSE parameters. Therefore, registration type definitions
MAY define dependencies for HIP parameters that are not defined in MAY define dependencies for HIP parameters that are not defined in
this document. Their semantics are subject to the specific this document. Their semantics are subject to the specific
registration type specifications. registration type specifications.
The minimum lifetime both registrars and requesters MUST support is The minimum lifetime both registrars and requesters MUST support is
10 seconds, while they SHOULD support a maximum lifetime of 120 10 seconds, while they SHOULD support a maximum lifetime of 120
seconds, at least. seconds, at least. These values define a baseline for the
specification of services based on the registration system. They
were chosen to be neither to short nor too long, and to accommodate
for existing timeouts of state established in middleboxes (e.g. NATs
and firewalls.)
A zero lifetime is reserved for canceling purposes. Requesting a A zero lifetime is reserved for canceling purposes. Requesting a
zero lifetime for a registration type equals to canceling the zero lifetime for a registration type equals to canceling the
registration of that type. A requester MAY cancel a registration registration of that type. A requester MAY cancel a registration
before it expires by sending a REG_REQ to the registrar with a zero before it expires by sending a REG_REQ to the registrar with a zero
lifetime. A registrar SHOULD respond and grant a registration with a lifetime. A registrar SHOULD respond and grant a registration with a
zero lifetime. A registrar (and an attached service) MAY cancel a zero lifetime. A registrar (and an attached service) MAY cancel a
registration before it expires, at its own discretion. However, if registration before it expires, at its own discretion. However, if
it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all
registered requesters. registered requesters.
skipping to change at page 11, line 5 skipping to change at page 12, line 17
Julien Laganier and Lars Eggert are partly funded by Ambient Julien Laganier and Lars Eggert are partly funded by Ambient
Networks, a research project supported by the European Commission Networks, a research project supported by the European Commission
under its Sixth Framework Program. The views and conclusions under its Sixth Framework Program. The views and conclusions
contained herein are those of the authors and should not be contained herein are those of the authors and should not be
interpreted as necessarily representing the official policies or interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the Ambient Networks endorsements, either expressed or implied, of the Ambient Networks
project or the European Commission. project or the European Commission.
9. References 9. References
9.1 Normative References 9.1. Normative References
[I-D.ietf-hip-base] [I-D.ietf-hip-base]
Moskowitz, R., "Host Identity Protocol", Moskowitz, R., "Host Identity Protocol",
draft-ietf-hip-base-03 (work in progress), June 2005. draft-ietf-hip-base-04 (work in progress), October 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
9.2 Informative References 9.2. Informative References
[I-D.ietf-hip-arch] [I-D.ietf-hip-arch]
Moskowitz, R., "Host Identity Protocol Architecture", Moskowitz, R. and P. Nikander, "Host Identity Protocol
draft-ietf-hip-arch-02 (work in progress), January 2005. Architecture", draft-ietf-hip-arch-03 (work in progress),
August 2005.
[I-D.ietf-hip-rvs] [I-D.ietf-hip-rvs]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rvs-03 (work in Rendezvous Extension", draft-ietf-hip-rvs-04 (work in
progress), July 2005. progress), October 2005.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002. Issues", RFC 3234, February 2002.
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
DoCoMo Communications Laboratories Europe GmbH DoCoMo Communications Laboratories Europe GmbH
Landsberger Strasse 312 Landsberger Strasse 312
Munich 80687 Munich 80687
 End of changes. 25 change blocks. 
31 lines changed or deleted 55 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/