draft-ietf-mext-nemo-pd-01.txt   draft-ietf-mext-nemo-pd-02.txt 
Mobile IPv6 Extensions Group R. Droms Mobile IPv6 Extensions Group R. Droms
Internet-Draft P. Thubert Internet-Draft P. Thubert
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: May 7, 2009 F. Dupont Expires: September 7, 2009 F. Dupont
ISC ISC
W. Haddad W. Haddad
Qualcomm Qualcomm
November 3, 2008 March 6, 2009
DHCPv6 Prefix Delegation for NEMO DHCPv6 Prefix Delegation for NEMO
draft-ietf-mext-nemo-pd-01 draft-ietf-mext-nemo-pd-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
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 May 7, 2009. This Internet-Draft will expire on September 7, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
One aspect of network mobility support is the assignment of a prefix One aspect of network mobility support is the assignment of a prefix
or prefixes to a Mobile Router (MR) for use on the links in the or prefixes to a Mobile Router (MR) for use on the links in the
Mobile Network. DHCPv6 prefix delegation can be used for this Mobile Network. DHCPv6 prefix delegation can be used for this
configuration task. configuration task.
1. Introduction 1. Introduction
skipping to change at page 5, line 32 skipping to change at page 6, line 12
DHCPv6 client in the MR. The way in which this handoff takes place DHCPv6 client in the MR. The way in which this handoff takes place
is beyond the scope of this document. is beyond the scope of this document.
3.4. Exchanging DHCPv6 messages when MR is at home 3.4. Exchanging DHCPv6 messages when MR is at home
When the MR is on its home link, the HA uses the home link to When the MR is on its home link, the HA uses the home link to
exchange DHCPv6PD messages with the MR. It is the responsibility of exchange DHCPv6PD messages with the MR. It is the responsibility of
the implementation to determine when the MR is on its home link and the implementation to determine when the MR is on its home link and
to avoid use of any existing tunnel. to avoid use of any existing tunnel.
3.5. Minimizing DHCPv6PD messages 3.5. Selecting an HA that provides DHCPv6PD
DHCPv6PD in a Mobile Network can be combined with the Rapid Commit
option [RFC3315] to provide DHCPv6 prefix delegation with a two
message exchange between the mobile node and the DHCPv6PD DR.
3.6. DHCPv6PD and DHAAD
The MR acting as RR needs a direct link to the DR (or relay)
function. When the MR is away from Home, that link is the MR-HA
tunnel. If a MR needs to obtain a prefix by means of DHCPv6PD, it
has to locate a HA that is capable of serving either as a DHCPv6PD
relay agent or server. Since the use of DHCPv6PD is optional and
comes as an addition to existing protocols RFC 3775 and RFC 3963, it
can not be expected that all HAs are DHCPv6PD capable.
This specification extends Dynamic Home Agent Address Discovery and
the Home Agent Information Option in order to enable the detection by
a MR of all HAs that are DHCPv6PD capable. A new 'D' bit is
introduced to let Home Agents advertise that they are willing to
participate to DHCP. Note that there is no direct way for the MR
acting as RR to know whether a HA is actually a DR or simply acting
as a relay.
3.6.1. Modified Dynamic Home Agent Address Discovery Request
A new flag (D) (Support for DHCPv6PD) is introduced in the DHAAD
Request message, defined in RFC 3775 and RFC 3963. The Mobile Router
sets this flag to indicate that it wants to discover Home Agents
participating to DHCPv6 Prefix Delegation.
A the MR which sets the 'D' flag MUST also set the 'R' flag, to
declare that it is a Mobile Router and asks for a HA that supports
Mobile Routers, as defined in RFC 3963.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |R|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DHCPv6PD Support Flag (D)
A one-bit flag that when set indicates that the Mobile Router
wants to discover Home Agents participating to DHCPv6 Prefix
Delegation.
For a description of the other fields in the message, see RFC 3775
and RFC 3963.
3.6.2. Modified Dynamic Home Agent Address Discovery Reply
A new flag (D) (Support for DHCPv6PD) is introduced in the DHAAD
Reply message, defined in RFC 3775 and RFC 3963. If a Home Agent
receives a Dynamic Home Agent Discovery request message with the
DHCPv6PD Support Flag set, it MUST include a list of Home Agents
participating to DHCPv6PD to any replies.
The DHCPv6PD Support Flag MUST be set if there is at least one Home
Agent participating to DHCPv6PD. In that case, the reply will list
only those HAs that participate to DHCPv6PD, whether they act as
servers (DRs) or relays.
A HA that supports DHCPv6PD MUST support Mobile Routers as well, so
if the 'D' bit is set, then the 'R' bit should be set as well. So
there is no need in an implementation to support the case where some
HAs would support Mobile Routers while others would be participating
to DHCPv6 Prefix Delegation but none could do both.
If none of the Home Agents support DHCPv6PD, the Home Agent MAY reply
with a list of Home Agents that only support NEMO basic Mobile
Routers or Mobile IPv6 Mobile Nodes. In this case, the DHCPv6PD
Support Flag MUST be set to 0.
The modified message format is as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |R|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DHCPv6PD Support Flag (D)
A one-bit flag that when set indicates that the Home Agents
listed in this message participate to DHCPv6 Prefix Delegation.
For a description of the other fields in the message, see RFC 3775
and RFC 3963.
3.6.3. Modified Home Agent Information Option
A new flag (D) (Support for DHCPv6PD) is introduced in the Home Agent
Information Option defined in RFC 3775 and RFC 3963.
If a Home Agent participates to DHCPv6PD, it SHOULD set the flag. If Not all nodes that are willing to act as an HA are required to
the HA sets the 'D' flag, then it MUST also set the 'R' flag, provide DHCPv6PD. Therefore, when selecting an HA, a MR that
Indicating that it supports Mobile Routers, as defined in RFC 3963. requires DHCPv6PD service must identify an HA that will provide the
service. The MR can determine if an HA provides DHCPv6PD by
initiating a DHCPv6 message exchange in which the MR requests
delegated prefix(es). If the HA does not respond or responds but
does not delegate any prefix(es) in its response, the MR assumes that
the HA does not provide DHCPv6PD service. The MR continues to query
all candidate HAs until it finds an HA that provides DHCPv6PD.
0 1 2 3 Querying an HA to determine if it provides DHCPv6PD requires a small
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 modification to the operation of DHCPv6 as described in RFC 3315.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Under normal circumstances, a host will continue to send DHCPv6
| Type | Length |R|D| Reserved | Solicit messages until it receives a response (see Section 17 of RFC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3315). However, an HA may choose not to respond to the Solicit
| Home Agent Preference | Home Agent Lifetime | messages from the MR because the HA does not provide DHCPv6.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Therefore, when querying an HA to determine if the HA provides
DHCPv6PD service, the MR MUST discontinue sending Solicit messages to
the HA after sending 6 Solicit messages, and conclude that the HA
will not provide DHCPv6PD service.
DHCPv6PD Support Flag (D) The MR may choose to probe the HAs for DHCPv6PD service sequentially
or in parallel.
A one-bit flag that when set indicates that the Home Agents 3.6. Minimizing DHCPv6PD messages
participates to DHCPv6 Prefix Delegation.
For a description of the other fields in the message, see RFC 3775 DHCPv6PD in a Mobile Network can be combined with the Rapid Commit
and RFC 3963. option [RFC3315] to provide DHCPv6 prefix delegation with a two
message exchange between the mobile node and the DHCPv6PD DR.
3.7. Location of DHCPv6PD Delegating Router function 3.7. Location of DHCPv6PD Delegating Router function
Support of DHCPv6PD for a Mobile Network is optional. Support of DHCPv6PD for a Mobile Network is optional.
The use of a DHCPv6 relay agent in DHCPv6PD may require "a protocol The use of a DHCPv6 relay agent in DHCPv6PD may require "a protocol
or other out-of-band communication to add routing information for or other out-of-band communication to add routing information for
delegated prefixes into the provider edge router" (section 14 of RFC delegated prefixes into the provider edge router" (section 14 of RFC
3633). If the DHCPv6PD DR function is implemented in the HA for the 3633). If the DHCPv6PD DR function is implemented in the HA for the
MR, no relay agent function is required. MR, no relay agent function is required.
skipping to change at page 9, line 32 skipping to change at page 8, line 6
The DHCPv6 messages exchanged between the MR and the HA may also be The DHCPv6 messages exchanged between the MR and the HA may also be
used for other DHCPv6 functions in addition to DHCPv6PD. For used for other DHCPv6 functions in addition to DHCPv6PD. For
example, the HA may assign global addresses to the MR and may pass example, the HA may assign global addresses to the MR and may pass
other configuration information such as a list of available DNS other configuration information such as a list of available DNS
recursive name servers [RFC3646] to the MR using the same DHCPv6 recursive name servers [RFC3646] to the MR using the same DHCPv6
messages as used for DHCPV6PD. messages as used for DHCPV6PD.
The HA may act as a DHCPv6 relay agent for MHs while it acts as a DR The HA may act as a DHCPv6 relay agent for MHs while it acts as a DR
for MRs. for MRs.
4. Changes in this draft 4. Security Considerations
This document is based on draft-ietf-nemo-dhcpv6-pd-03 and includes
the use of the DHCPv6 relay agent in the MR, as described in
Section 3.3, from draft-dupont-mext-dhcrelay-00.
5. Security Considerations
This document describes the use of DHCPv6 for prefix delegation in This document describes the use of DHCPv6 for prefix delegation in
Mobile Networks. It does not introduce any additional security Mobile Networks. It does not introduce any additional security
considerations for DHCPv6 beyond those described in the "Security considerations for DHCPv6 beyond those described in the "Security
Considerations" section of the DHCPv6 base specification [RFC3315] Considerations" section of the DHCPv6 base specification [RFC3315]
and the "Security Considerations" of the DHCPv6 Prefix Delegation and the "Security Considerations" of the DHCPv6 Prefix Delegation
specification [RFC3633]. specification [RFC3633].
The use of DHCPv6, as described in this document, requires only The use of DHCPv6, as described in this document, requires only
message integrity protection, which can be provided by the mobile message integrity protection, which can be provided by the mobile
skipping to change at page 10, line 16 skipping to change at page 8, line 30
nodes does not provide message integrity and source authentication nodes does not provide message integrity and source authentication
for the DHCPv6PD messages, HAs and MRs SHOULD use DHCPv6 for the DHCPv6PD messages, HAs and MRs SHOULD use DHCPv6
authentication as described in section "Authentication of DHCP authentication as described in section "Authentication of DHCP
messages" of the DHCPv6 specification [RFC3315], to guard against messages" of the DHCPv6 specification [RFC3315], to guard against
attacks mounted through prefix delegation. attacks mounted through prefix delegation.
If the HA and DHCPv6 PD functions are not provided by the same If the HA and DHCPv6 PD functions are not provided by the same
physical node, the HA will act as a DHCPv6 relay agent between the MR physical node, the HA will act as a DHCPv6 relay agent between the MR
and the DHCPv6 server. In this scenario, the mobile network and the DHCPv6 server. In this scenario, the mobile network
infrastructure will only protect the DHCPv6 traffic between the RR infrastructure will only protect the DHCPv6 traffic between the RR
(MR) and the relay agent (HA). Section 21.1 of RFC 3315 describes (MR) and the relay agent (HA). The following text, based on Section
how appropriate security can be provided between a DHCPv6 relay agent 21.1 of RFC 3315, describes how appropriate security can be provided
and server. between a DHCPv6 relay agent and server.
6. IANA Considerations DHCPv6 relay agents and servers MAY use IPsec mechanisms for IPv6
[RFC2401] to exchange messages securely. DHCPv6 relay agents and
servers that support secure relay agent to server or relay agent
to relay agent communication use IPsec under the following
conditions:
Selectors DHCPv6 relay agents are manually configured with
the addresses of the DHCPv6 server to which DHCPv6
messages are to be forwarded. Each DHCPv6 server
that will be using IPsec for securing DHCPv6
messages must also be configured with a list of
the DHCPv6 relay agents to which messages will be
returned. The selectors for the DHCPv6 relay
agents and servers will be the pairs of addresses
defining DHCPv6 relay agents and servers that
exchange DHCP messages on the DHCPv6 UDP ports 546
and 547.
Mode DHCPv6 relay agents and servers use transport mode
and ESP. The information in DHCPv6 messages is
not generally considered confidential, so
encryption need not be used (i.e., NULL encryption
can be used).
Key management If the HA providing the DHCPv6 relay agent
function and the DHCPv6 servers are both
administered by the same organization, public key
schemes are not necessary. Because the relay
agents and servers must be manually configured,
manually configured key management may suffice,
but does not provide defense against replayed
messages. Accordingly, IKE with preshared secrets
SHOULD be supported.
Discussion: If NEMO may be deployed with the HA
and the DHCPv6 server in different
administrative domains, this text
should be extended to include the use
of IKE with public keys.
Security policy DHCPv6 messages between relay agents and servers
should only be accepted from DHCPv6 peers as
identified in the local configuration.
Authentication Shared keys, indexed to the source IP address of
the received DHCPv6 message, are adequate in this
application.
5. IANA Considerations
This document describes the use of DHCPv6 for prefix delegation in This document describes the use of DHCPv6 for prefix delegation in
Mobile Networks. It does not introduce any additional IANA Mobile Networks. It does not introduce any additional IANA
considerations. considerations.
7. Change Log 6. Change Log
This section MUST be removed before this document is published as an This section MUST be removed before this document is published as an
RFC. RFC.
7.1. Revision -01 6.1. Revision -00
Added detail in "Security Considerations" describing protection This document is based on draft-ietf-nemo-dhcpv6-pd-03 and includes
required for DHCPv6 and a mechanism for protecting traffic between the use of the DHCPv6 relay agent in the MR, as described in
the DHCPv6 relay agent and server. Section 3.3, from draft-dupont-mext-dhcrelay-00.
8. References 6.2. Revision -01
8.1. Normative References Added detail in Section 4, "Security Considerations", describing
protection required for DHCPv6 and a mechanism for protecting traffic
between the DHCPv6 relay agent and server.
Corrected minor typos.
6.3. Revision -02
Removed text describing extensions to DHAAD for discovery of HA that
will provide PD.
Added Section 3.5, "Selecting an HA that provides DHCPv6PD," which
describes how an MR can discover DHCPv6PD service through polling of
multiple HAs.
Added text to Section 4, "Security Considerations", giving detail
about the use of IPsec.
7. References
7.1. Normative References
[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.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
skipping to change at page 11, line 20 skipping to change at page 11, line 9
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005. RFC 3963, January 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
8.2. Informative References 7.2. Informative References
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007. Terminology", RFC 4885, July 2007.
[RFC4886] Ernst, T., "Network Mobility Support Goals and [RFC4886] Ernst, T., "Network Mobility Support Goals and
Requirements", RFC 4886, July 2007. Requirements", RFC 4886, July 2007.
[I-D.ietf-dhc-dhcpv6-agentopt-delegate] [I-D.ietf-dhc-dhcpv6-agentopt-delegate]
Droms, R., "DHCPv6 Relay Agent Assignment Notification Droms, R. and B. Volz, "DHCPv6 Relay Agent Assignment
(RAAN) Option", draft-ietf-dhc-dhcpv6-agentopt-delegate-02 Notification (RAAN) Option",
(work in progress), November 2006. draft-ietf-dhc-dhcpv6-agentopt-delegate-03 (work in
progress), February 2009.
Authors' Addresses Authors' Addresses
Ralph Droms Ralph Droms
Cisco Cisco
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: +1 978.936.1674 Phone: +1 978.936.1674
skipping to change at page 12, line 17 skipping to change at page 12, line 4
400, Avenue Roumanille 400, Avenue Roumanille
Biot - Sophia Antipolis 06410 Biot - Sophia Antipolis 06410
FRANCE FRANCE
Email: pthubert@cisco.com Email: pthubert@cisco.com
Francis Dupont Francis Dupont
ISC ISC
Email: Francis.Dupont@fdupont.fr Email: Francis.Dupont@fdupont.fr
Wassim Haddad Wassim Haddad
Qualcomm Qualcomm
Email: whaddad@qualcomm.com Email: whaddad@qualcomm.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 24 change blocks. 
149 lines changed or deleted 131 lines changed or added

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