< draft-ietf-dime-mip6-split-12.txt   draft-ietf-dime-mip6-split-13.txt >
Diameter Maintenance and J. Korhonen Diameter Maintenance and J. Korhonen
Extensions (DIME) TeliaSonera Extensions (DIME) TeliaSonera
Internet-Draft H. Tschofenig Internet-Draft H. Tschofenig
Intended status: Standards Track Nokia Siemens Networks Intended status: Standards Track Nokia Siemens Networks
Expires: March 27, 2009 J. Bournelle Expires: April 30, 2009 J. Bournelle
Orange Labs Orange Labs
G. Giaretta G. Giaretta
Qualcomm Qualcomm
M. Nakhjiri M. Nakhjiri
Motorola Motorola
September 23, 2008 October 27, 2008
Diameter Mobile IPv6: Support for Home Agent to Diameter Server Diameter Mobile IPv6: Support for Home Agent to Diameter Server
Interaction Interaction
draft-ietf-dime-mip6-split-12.txt draft-ietf-dime-mip6-split-13.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 27, 2009. This Internet-Draft will expire on April 30, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
Mobile IPv6 deployments may want to bootstrap their operations Mobile IPv6 deployments may want to bootstrap their operations
dynamically based on an interaction between the Home Agent and the dynamically based on an interaction between the Home Agent and the
Diameter server of the Mobile Service Provider (MSP). This document Diameter server of the Mobile Service Provider (MSP). This document
skipping to change at page 3, line 45 skipping to change at page 3, line 45
6.6. MIP6-Agent-Info AVP . . . . . . . . . . . . . . . . . . . 22 6.6. MIP6-Agent-Info AVP . . . . . . . . . . . . . . . . . . . 22
6.7. MIP-Careof-Address AVP . . . . . . . . . . . . . . . . . . 23 6.7. MIP-Careof-Address AVP . . . . . . . . . . . . . . . . . . 23
6.8. MIP-Authenticator AVP . . . . . . . . . . . . . . . . . . 23 6.8. MIP-Authenticator AVP . . . . . . . . . . . . . . . . . . 23
6.9. MIP-MAC-Mobility-Data AVP . . . . . . . . . . . . . . . . 23 6.9. MIP-MAC-Mobility-Data AVP . . . . . . . . . . . . . . . . 23
6.10. MIP-Session-Key AVP . . . . . . . . . . . . . . . . . . . 23 6.10. MIP-Session-Key AVP . . . . . . . . . . . . . . . . . . . 23
6.11. MIP-MSA-Lifetime AVP . . . . . . . . . . . . . . . . . . . 23 6.11. MIP-MSA-Lifetime AVP . . . . . . . . . . . . . . . . . . . 23
6.12. MIP-MN-HA-MSA AVP . . . . . . . . . . . . . . . . . . . . 24 6.12. MIP-MN-HA-MSA AVP . . . . . . . . . . . . . . . . . . . . 24
6.13. MIP-Algorithm-Type AVP . . . . . . . . . . . . . . . . . . 24 6.13. MIP-Algorithm-Type AVP . . . . . . . . . . . . . . . . . . 24
6.14. MIP-Replay-Mode AVP . . . . . . . . . . . . . . . . . . . 24 6.14. MIP-Replay-Mode AVP . . . . . . . . . . . . . . . . . . . 24
6.15. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . . 24 6.15. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . . 24
6.16. MIP-Timestamp AVP . . . . . . . . . . . . . . . . . . . . 26 6.16. MIP-Timestamp AVP . . . . . . . . . . . . . . . . . . . . 25
6.17. QoS-Capability AVP . . . . . . . . . . . . . . . . . . . . 26 6.17. QoS-Capability AVP . . . . . . . . . . . . . . . . . . . . 25
6.18. QoS-Resources AVP . . . . . . . . . . . . . . . . . . . . 26 6.18. QoS-Resources AVP . . . . . . . . . . . . . . . . . . . . 25
6.19. Chargeable-User-Identity AVP . . . . . . . . . . . . . . . 26 6.19. Chargeable-User-Identity AVP . . . . . . . . . . . . . . . 25
6.20. MIP6-Auth-Mode AVP . . . . . . . . . . . . . . . . . . . . 26 6.20. MIP6-Auth-Mode AVP . . . . . . . . . . . . . . . . . . . . 25
6.21. Coupled Accounting Model Accounting AVPs . . . . . . . . . 27 6.21. Coupled Accounting Model Accounting AVPs . . . . . . . . . 26
7. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 27 7. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 26
7.1. Success . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.1. Success . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.2. Permanent Failures . . . . . . . . . . . . . . . . . . . . 28 7.2. Permanent Failures . . . . . . . . . . . . . . . . . . . . 27
8. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 28 8. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 27
8.1. DER, DEA, MIR and MIA AVP/Command-Code Table . . . . . . . 29 8.1. DER, DEA, MIR and MIA AVP/Command-Code Table . . . . . . . 28
8.2. Coupled Accounting Model AVP Table . . . . . . . . . . . . 29 8.2. Coupled Accounting Model AVP Table . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 30 9.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 29
9.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 30 9.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 29
9.3. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 31 9.3. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 30
9.4. Application Identifier . . . . . . . . . . . . . . . . . . 31 9.4. Application Identifier . . . . . . . . . . . . . . . . . . 30
9.5. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 31 9.5. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 30
9.6. Mobile IPv6 Status Codes . . . . . . . . . . . . . . . . . 32 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 12.2. Informative References . . . . . . . . . . . . . . . . . . 33
12.2. Informative References . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Introduction 1. Introduction
Performing the Mobile IPv6 protocol [1], requires the Mobile Node Performing the Mobile IPv6 protocol [1], requires the Mobile Node
(MN) to own a Home Address (HoA) and to have an assigned Home Agent (MN) to own a Home Address (HoA) and to have an assigned Home Agent
(HA) to the MN. The MN needs to register with the HA in order to (HA) to the MN. The MN needs to register with the HA in order to
enable its reachability and mobility, when away from its home link. enable its reachability and mobility, when away from its home link.
The registration process itself may require an establishment of IPSec The registration process itself may require an establishment of IPsec
security associations (SA) and cryptographic material between the MN security associations (SA) and cryptographic material between the MN
and HA. Alternatively, the registration process may be secured using and HA. Alternatively, the registration process may be secured using
a mobility message authentication option, which enables IPv6 mobility a mobility message authentication option, which enables IPv6 mobility
in a MN without having to establish an IPSec SA with its HA. in a MN without having to establish an IPsec SA with its HA.
Providing the collection of home address, HA address and keying Providing the collection of home address, HA address and keying
material is generally referred to as the Mobile IPv6 bootstrapping material is generally referred to as the Mobile IPv6 bootstrapping
problem [15]. The purpose of this specification is to provide problem [15]. The purpose of this specification is to provide
Diameter support for the interaction between the HA and the Diameter support for the interaction between the HA and the
Authentication, Authorization, and Accounting (AAA) server. This Authentication, Authorization, and Accounting (AAA) server. This
specification satisfies the requirements defined in [16] for the specification satisfies the requirements defined in [16] for the
bootstrapping problem in the split scenario [2] and also specifies bootstrapping problem in the split scenario [2] and also specifies
Diameter support for the Authentication Protocol for Mobile IPv6 [3]. Diameter support for the Authentication Protocol for Mobile IPv6 [3].
The Diameter support defined in this specification also applies to The Diameter support defined in this specification also applies to
Dual Stack Mobile IPv6 [17]. Dual Stack Mobile IPv6 [17].
skipping to change at page 6, line 37 skipping to change at page 6, line 37
| (this document) | (this document)
v v
+---------+ +---------------+ +---------+ +---------------+
| Mobile | Front-End Protocol |Home Agent / | | Mobile | Front-End Protocol |Home Agent / |
| Node |<-------------------->|Diameter Client| | Node |<-------------------->|Diameter Client|
+---------+ IKEv2 or RFC 4285 +---------------+ +---------+ IKEv2 or RFC 4285 +---------------+
Figure 1: Architecture Overview Figure 1: Architecture Overview
Mobile IPv6 signaling between the MN and the HA can be protected Mobile IPv6 signaling between the MN and the HA can be protected
using two different mechanisms, namely using IPSec or Authentication using two different mechanisms, namely using IPsec or Authentication
Protocol for Mobile IPv6 [3]. For these two approaches several Protocol for Mobile IPv6 [3]. For these two approaches several
different authentication and key exchange solutions are available. different authentication and key exchange solutions are available.
When IPSec is used to protect Mobile IPv6 signaling messages, IKEv2 When IPsec is used to protect Mobile IPv6 signaling messages, IKEv2
is used [4]. IKEv2 supports EAP-based initiator authentication, is used [4]. IKEv2 supports EAP-based initiator authentication,
certificates and pre-shared secrets. Alternatively, Authentication certificates and pre-shared secrets. Alternatively, Authentication
Protocol for Mobile IPv6 uses a mechanism that is very similar to the Protocol for Mobile IPv6 uses a mechanism that is very similar to the
one used for protecting Mobile IPv4 signaling messages. one used for protecting Mobile IPv4 signaling messages.
The ability to use different credentials and methods to authenticate The ability to use different credentials and methods to authenticate
the MN has an impact on the AAA interactions between the HA (acting the MN has an impact on the AAA interactions between the HA (acting
as a Diameter client) and the Diameter Server. This specification is as a Diameter client) and the Diameter Server. This specification is
only limited to the following MN authentication methods: only limited to the following MN authentication methods:
skipping to change at page 10, line 35 skipping to change at page 10, line 35
Diameter server selects the EAP method and replies with the Diameter- Diameter server selects the EAP method and replies with the Diameter-
EAP-Answer (DEA) Message. Depending on the type of EAP method EAP-Answer (DEA) Message. Depending on the type of EAP method
chosen, a number of DER and DEA messages carry the method specific chosen, a number of DER and DEA messages carry the method specific
exchanges between the MN and the Diameter server/EAP server. exchanges between the MN and the Diameter server/EAP server.
At the end of the EAP authentication phase, the Diameter server At the end of the EAP authentication phase, the Diameter server
indicates the result of the authentication in the Result-Code AVP and indicates the result of the authentication in the Result-Code AVP and
provides the corresponding EAP packet (EAP Success or EAP Failure). provides the corresponding EAP packet (EAP Success or EAP Failure).
The last IKEv2 message sent by the HA contains the Home Address or The last IKEv2 message sent by the HA contains the Home Address or
the Home Prefix. In the latter case, a CREATE_CHILD_SA exchange is the Home Prefix. In the latter case, a CREATE_CHILD_SA exchange is
necessary to setup IPSec SAs for Mobile IPv6 signaling. necessary to setup IPsec SAs for Mobile IPv6 signaling.
In some deployment scenarios, the HA may also acts as a IKEv2 In some deployment scenarios, the HA may also acts as a IKEv2
Responder for IPSec VPN access. A problem in this case is that the Responder for IPsec VPN access. A problem in this case is that the
IKEv2 responder may not know if IKEv2 is used for Mobile IPv6 service IKEv2 responder may not know if IKEv2 is used for Mobile IPv6 service
or for IPSec VPN access service. A network operator needs to be or for IPsec VPN access service. A network operator needs to be
aware of this limitation. The MN may provide a hint of the intended aware of this limitation. The MN may provide a hint of the intended
service, for example, by using different identities in the IKE_AUTH service, for example, by using different identities in the IKE_AUTH
message for the IPSec VPN service and Mobile IPv6 service. However, message for the IPsec VPN service and Mobile IPv6 service. However,
the use of different identities during the IKEv2 negotiation is the use of different identities during the IKEv2 negotiation is
deployment specific. Another possibility is to make the distinction deployment specific. Another possibility is to make the distinction
on the MN subscription basis. In this case the Diameter server can on the MN subscription basis. In this case the Diameter server can
inform the HA during the IKEv2 negotiation whether the MN is inform the HA during the IKEv2 negotiation whether the MN is
provisioned with an IPSec VPN access service or Mobile IPv6 service. provisioned with an IPsec VPN access service or Mobile IPv6 service.
Eventually, when the HA receives a Binding Update (BU), the HA Eventually, when the HA receives a Binding Update (BU), the HA
authenticates and authorizes the MN. It is RECOMMENDED that the HA authenticates and authorizes the MN. It is RECOMMENDED that the HA
sends an accounting request message every time it receives a BU. sends an accounting request message every time it receives a BU.
4.2. Support for the Mobile IPv6 Authentication Protocol 4.2. Support for the Mobile IPv6 Authentication Protocol
Figure 4 shows the message sequence between the MN, the HA and the Figure 4 shows the message sequence between the MN, the HA and the
Diameter server during the registration when Mobile IPv6 Diameter server during the registration when Mobile IPv6
Authentication Protocol is used. A BU and a Binding Acknowledgement Authentication Protocol is used. A BU and a Binding Acknowledgement
skipping to change at page 24, line 46 skipping to change at page 24, line 46
6.14. MIP-Replay-Mode AVP 6.14. MIP-Replay-Mode AVP
The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and
contains the replay mode the HA for authenticating the mobile node. contains the replay mode the HA for authenticating the mobile node.
The replay modes, defined in RFC 4004 [12], are supported. The replay modes, defined in RFC 4004 [12], are supported.
This AVP is re-used from [12]. This AVP is re-used from [12].
6.15. MIP6-Feature-Vector AVP 6.15. MIP6-Feature-Vector AVP
This AVP is defined in [10]. This document defines a new capability The MIP6-Feature-Vector AVP (AVP Code TBD) is of type Unsigned64 and
bit for signaling the support of Mobile IPv6 route optimization. The defined in [10]. This document defines a new capability flag bit for
following capability is defined in this document: signaling the support of Mobile IPv6 split scenario bootstrapping.
MIP6_SPLIT (0x0000000100000000) MIP6_SPLIT (0x0000000100000000)
When this flag is set by the NAS then it means that the Mobile When this flag is set by the NAS then it means that the Mobile
IPv6 split scenario bootstrapping functionality is supported by IPv6 split scenario bootstrapping functionality is supported by
the NAS. When this flag is set by the Diameter server then the the NAS. When this flag is set by the Diameter server then the
Mobile IPv6 split scenario bootstrapping is supported by the Mobile IPv6 split scenario bootstrapping is supported by the
Diameter server. Diameter server.
RO_SUPPORTED (0x0000000200000000)
Route optimization is supported. When the HA sets this bit, it
indicates support for the route optimization. If this bit is
unset in the returned Mobility-Capability AVP, the AAAH does not
authorize route optimization for the MN.
In a case the HA or the AAAH cannot authorize the use of route
optimization then the HA SHOULD send a Binding Acknowledgement
with a Status Code set to ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION
(status code TBD). This Status Code indicates that the binding
registration succeeded but the HA will fail all possible
subsequent route optimization attempts because of subscription or
operator policy.
USER_TRAFFIC_ENCRYPTION (0x0000000400000000)
User plane traffic encryption is supported. When the HA sets this
bit, it indicates support for the user plane traffic encryption
between the MN and the HA. If this bit is unset in the returned
Mobility-Capability AVP, the AAAH does not authorize user plane
traffic encryption because of subscription or operator policy.
In the case the AAAH cannot authorize the use of user plane
traffic encryption then the HA SHOULD send a Binding
Acknowledgement with a Status Code set to
ACCEPTED_BUT_NO_TRAFFIC_ENCRYPTION (status code TBD). This Status
Code indicates that the binding registration succeeded but the HA
will silently discard all encrypted user plane packets sent by the
MN to the HA.
VPN_GW_MODE (0x0000000800000000)
The HA is supposed to act as a IPSec VPN gateway for the user.
When the HA sets this bit, it indicates support for acting as a
standalone IPSec VPN gateway. If this bit is unset in the
returned Mobility-Capability AVP, the AAAH does not authorize the
HA to act as a standalone IPSec VPN gateway for the MN because of
subscription or operator policy.
MCOA_SUPPORTED (0x0000001000000000)
Multiple Care-of Addresses (MCoA) [21] are supported. When the HA
sets this bit, it indicates support for the MCoA. If this bit is
unset in the returned Mobility-Capability AVP, the AAAH does not
authorize the use of MCoA for the MN.
In a case the HA or the AAAH cannot authorize the use of the MCoA
then the HA SHOULD send a Binding Acknowledgement with a Status
Code set to ACCEPTED_BUT_NO_MCOA (status code TBD). This Status
Code indicates that the binding registration succeeded but the HA
will fail all possible subsequent attempts to use MCoA because of
subscription or operator policy.
6.16. MIP-Timestamp AVP 6.16. MIP-Timestamp AVP
The MIP-Timestamp AVP (AVP Code TBD) is of type Time and may contain The MIP-Timestamp AVP (AVP Code TBD) is of type Time and may contain
the timestamp value from the Mobility message replay protection the timestamp value from the Mobility message replay protection
option, defined in [3]. The HA extracts this value from the received option, defined in [3]. The HA extracts this value from the received
BU message, if available. The HA includes this AVP in the MIR BU message, if available. The HA includes this AVP in the MIR
message when the MN-AAA Mobility Message Authentication Option is message when the MN-AAA Mobility Message Authentication Option is
available in the received BU and the Diameter server is expected to available in the received BU and the Diameter server is expected to
return the key material required for the calculation and validation return the key material required for the calculation and validation
of the Mobile IPv6 MN-HA Authentication Option (and the MIP6-Auth- of the Mobile IPv6 MN-HA Authentication Option (and the MIP6-Auth-
skipping to change at page 31, line 47 skipping to change at page 30, line 47
Diameter Mobile IPv6 Auth (MIP6A) | TBD Diameter Mobile IPv6 Auth (MIP6A) | TBD
9.5. Namespaces 9.5. Namespaces
This specification defines new values to the "Mobility Capability" This specification defines new values to the "Mobility Capability"
registry (see [10]) for use with the MIP6-Feature-Vector AVP: registry (see [10]) for use with the MIP6-Feature-Vector AVP:
Token | Value | Description Token | Value | Description
---------------------------------+----------------------+------------ ---------------------------------+----------------------+------------
MIP6_SPLIT | 0x0000000100000000 | RFC TBD MIP6_SPLIT | 0x0000000100000000 | RFC TBD
RO_SUPPORTED | 0x0000000200000000 | RFC TBD
USER_TRAFFIC_ENCRYPTION | 0x0000000400000000 | RFC TBD
VPN_GW_MODE | 0x0000000800000000 | RFC TBD
MCOA_SUPPORTED | 0x0000001000000000 | RFC TBD
IANA is requested to create a new registry "MIP6 Authentication Mode" IANA is requested to create a new registry "MIP6 Authentication Mode"
registry for use with the enumerated MIP6-Auth-Mode AVP. The registry for use with the enumerated MIP6-Auth-Mode AVP. The
registry will initially contain the following values: registry will initially contain the following values:
Token | Value | Description Token | Value | Description
---------------------------------------------+----------+------------ ---------------------------------------------+----------+------------
MIP6_AUTH_MN_AAA | 1 | RFC TBD MIP6_AUTH_MN_AAA | 1 | RFC TBD
Allocation of new values follow the example policies described in Allocation of new values follow the example policies described in
[22] new values for the MIP6-Auth-Mode AVP will be assigned based on [21] new values for the MIP6-Auth-Mode AVP will be assigned based on
the "Specification Required" policy. the "Specification Required" policy.
9.6. Mobile IPv6 Status Codes
This specification defines new Mobile IPv6 [1] Status Code values.
The Status Code must be allocated from the range 0-127:
Status Code | Value | Description
----------------------------------------+---------------+------------
ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION | is set to TBD | RFC TBD
ACCEPTED_BUT_NO_TRAFFIC_ENCRYPTION | is set to TBD | RFC TBD
ACCEPTED_BUT_NO_MCOA | is set to TBD | RFC TBD
10. Security Considerations 10. Security Considerations
The security considerations for the Diameter interaction required to The security considerations for the Diameter interaction required to
accomplish the split scenario are described in in [2]. Additionally, accomplish the split scenario are described in in [2]. Additionally,
the security considerations of the Diameter Base protocol [5], the security considerations of the Diameter Base protocol [5],
Diameter EAP application [7] are applicable to this document. Diameter EAP application [7] are applicable to this document.
The Diameter messages may be transported between the HA and the The Diameter messages may be transported between the HA and the
Diameter server via one or more AAA brokers or Diameter agents. In Diameter server via one or more AAA brokers or Diameter agents. In
this case the HA to the Diameter server AAA communication rely on the this case the HA to the Diameter server AAA communication rely on the
skipping to change at page 34, line 51 skipping to change at page 33, line 34
RFC 4283, November 2005. RFC 4283, November 2005.
[19] Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G., and J. [19] Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G., and J.
Loughney, "Diameter Applications Design Guidelines", Loughney, "Diameter Applications Design Guidelines",
draft-ietf-dime-app-design-guide-07 (work in progress), draft-ietf-dime-app-design-guide-07 (work in progress),
July 2008. July 2008.
[20] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service [20] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
Selection for Mobile IPv6", RFC 5149, February 2008. Selection for Mobile IPv6", RFC 5149, February 2008.
[21] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, [21] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
"Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-09 (work in progress),
August 2008.
[22] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
Authors' Addresses Authors' Addresses
Jouni Korhonen Jouni Korhonen
TeliaSonera TeliaSonera
P.O.Box 970 P.O.Box 970
Sonera FIN-00051 Sonera FIN-00051
Finland Finland
Email: jouni.korhonen@teliasonera.com Email: jouni.nospam@gmail.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
 End of changes. 21 change blocks. 
120 lines changed or deleted 45 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/