draft-ietf-v6ops-ent-analysis-06.txt   draft-ietf-v6ops-ent-analysis-07.txt 
IPv6 Operations Working Group IPv6 Operations WG Jim Bound
Internet Draft Jim Bound Internet-Draft Yanick Pouffary
Document: draft-ietf-v6ops-ent-analysis-06.txt Yanick Pouffary Expires June 8, 2007 Hewlett-Packard
Obsoletes: ietf-v6ops-ent-analysis-05.txt Hewlett-Packard Steve Klynsma
Expires: December 2006 Steve Klynsma
MITRE MITRE
Tim Chown Tim Chown
University of Southampton University of Southampton
Dave Green Dave Green
Command Information Command Information
December 8, 2007
IPv6 Enterprise Network Analysis IPv6 Enterprise Network Analysis - IP Layer 3 Focus
<draft-ietf-v6ops-ent-analysis-06.txt> <draft-ietf-v6ops-ent-analysis-07.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is By submitting this Internet-Draft, each author represents that any
aware have been or will be disclosed, and any of which he or she applicable patent or other IPR claims of which he or she is aware
becomes aware will be disclosed, in accordance with Section 6 of have been or will be disclosed, and any of which he or she becomes
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
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 Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet- time. It is inappropriate to use Internet-Drafts as reference
Drafts as reference material or to cite them other than as "work material or to cite them other than as "work in progress."
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/1id-abstracts.html. 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.
Abstract This Internet-Draft will expire on June 1, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document analyzes the transition to IPv6 in enterprise This document analyzes the transition to IPv6 in enterprise
networks. These networks are characterized as a network that has networks focusing on IP Layer 3. These networks are characterized
multiple internal links, one or more router connections, to one or as a network that has multiple internal links, one or more router
more Providers, and is managed by a network operations entity. The connections, to one or more Providers, and is managed by a network
analysis will focus on a base set of transition notational networks operations entity. The analysis will focus on a base set of
and requirements expanded from a previous Enterprise Scenarios transition notational networks and requirements expanded from a
document. Discussion is provided on a focused set of transition previous Enterprise Scenarios document. Discussion is provided on a
analysis required for the enterprise to transition to IPv6, focused set of transition analysis required for the enterprise to
assuming a Dual-IP layer (IPv4 and IPv6) network and node transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6)
environment, within the enterprise. Then a set of transition network and node environment, within the enterprise. Then a set of
mechanisms are recommended for each notational network. transition mechanisms are recommended for each notational network.
Table of Contents: Table of Contents:
1. Introduction................................................4 1. Introduction................................................4
2. Terminology.................................................7 2. Terminology.................................................7
3. Enterprise Matrix Analysis for Transition...................8 3. Enterprise Matrix Analysis for Transition...................8
4. Wide-Scale Dual-Stack Deployment Analysis..................12 4. Wide-Scale Dual-Stack Deployment Analysis..................12
4.1 Staged Dual-Stack Deployment...............................12 4.1 Staged Dual-Stack Deployment...............................12
4.2 Routing Capability Analysis for Dual-IP Deployment.........13 4.2 Routing Capability Analysis for Dual-IP Deployment.........13
4.2.1 IPv6 Routing Capability..................................13 4.2.1 IPv6 Routing Capability..................................13
skipping to change at page 3, line 46 skipping to change at page 3, line 46
8. Applicable Transition Mechanisms...........................26 8. Applicable Transition Mechanisms...........................26
8.1 Recognizing Incompatible Network touchpoints...............26 8.1 Recognizing Incompatible Network touchpoints...............26
8.2 Recognizing Application incompatibilities..................27 8.2 Recognizing Application incompatibilities..................27
8.3 Using Multiple Mechanisms to Support IPv6 Transition.......28 8.3 Using Multiple Mechanisms to Support IPv6 Transition.......28
9. Security Considerations....................................29 9. Security Considerations....................................29
10. IANA Considerations........................................29 10. IANA Considerations........................................29
11. References.................................................29 11. References.................................................29
11.1 Normative References......................................29 11.1 Normative References......................................29
11.2 Non-Normative References..................................31 11.2 Non-Normative References..................................31
Change Log.....................................................32 Change Log.....................................................32
Document Acknowledgments.......................................34 Acknowledgments................................................34
Author's Addresses.............................................35 Author's Addresses.............................................35
Copyright (C) The Internet Society (2006)......................36 Intellectual Property and Copyright Statements.................36
IPR Disclosure Acknowledgement.................................36 Appendix A - Crisis Management Network Scenarios...............37
Disclaimer of validity.........................................36
Acknowledgment.................................................37
Appendix A - Crisis Management Network Scenarios...............38
1. Introduction 1. Introduction
This document analyzes the transition to IPv6 in enterprise This document analyzes the transition to IPv6 in enterprise
networks. These networks are characterized as a network that has networks focusing on IP Layer 3. These networks are characterized
multiple internal links, one or more router connections, to one or as a network that has multiple internal links, one or more router
more Providers, and is managed by a network operations entity. The connections, to one or more Providers, and is managed by a network
analysis will focus on a base set of transition notational networks operations entity. The analysis will focus on a base set of
and requirements expanded from a previous Enterprise Scenarios transition notational networks and requirements expanded from a
document. Discussion is provided on a focused set of transition previous Enterprise Scenarios document. Discussion is provided on a
analysis required for the enterprise to transition to IPv6, focused set of transition analysis required for the enterprise to
assuming a Dual-IP layer (IPv4 and IPv6) network and node transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6)
environment, within the enterprise. Then a set of transition network and node environment, within the enterprise. Then a set of
mechanisms are recommended for each notational network. transition mechanisms are recommended for each notational network.
The audience for this document is the enterprise network team The audience for this document is the enterprise network team
considering deployment of IPv6. The document will be useful for considering deployment of IPv6. The document will be useful for
enterprise teams that will have to determine the IPv6 transition enterprise teams that will have to determine the IPv6 transition
strategy for their enterprise. It is expected those teams include strategy for their enterprise. It is expected those teams include
members from management, network operations, and engineering. The members from management, network operations, and engineering. The
analysis and notational networks presented provide an example set analysis and notational networks presented provide an example set
of cases the enterprise can use to build an IPv6 transition of cases the enterprise can use to build an IPv6 transition
strategy. strategy.
skipping to change at page 4, line 48 skipping to change at page 4, line 48
is determined to be dominant across or within parts of the is determined to be dominant across or within parts of the
enterprise network. enterprise network.
The document then begins to discuss the general issues and The document then begins to discuss the general issues and
applicability from the previous analysis. The document concludes applicability from the previous analysis. The document concludes
providing a set of current transition mechanism recommendations for providing a set of current transition mechanism recommendations for
the notational network scenarios to support an enterprise planning the notational network scenarios to support an enterprise planning
to deploy IPv6. to deploy IPv6.
This document, as stated in the introduction, focuses only on the This document, as stated in the introduction, focuses only on the
deployment cases where a Dual-IP layer is supported across the deployment cases where a Dual-IP Layer 3 is supported across the
network and on the nodes in the enterprise. Additional deployment network and on the nodes in the enterprise. Additional deployment
transition analysis will be required from the effects of IPv6-only transition analysis will be required from the effects of IPv6-only
node or Provider deployments, and beyond the scope of this node or Provider deployments, and beyond the scope of this
document. In addition this document does not attempt to define or document. In addition this document does not attempt to define or
discuss any use with network address translation [NATPT] or the use discuss any use with network address translation [NATPT] or the use
of Provider Independent address space. of Provider Independent address space.
The following specific topics are currently out of scope for this The following specific topics are currently out of scope for this
document: document:
skipping to change at page 23, line 16 skipping to change at page 23, line 16
An enterprise network will have a number of tools available for An enterprise network will have a number of tools available for
IPv4 address and other configuration information delegation and IPv4 address and other configuration information delegation and
management, including manual configuration, NIS [NIS] or DHCP management, including manual configuration, NIS [NIS] or DHCP
[DHCPv4]. [DHCPv4].
In an IPv6 enterprise, Stateless Address Autoconfiguration [CONF] In an IPv6 enterprise, Stateless Address Autoconfiguration [CONF]
may be used to configure a host with a global IPv6 address, a may be used to configure a host with a global IPv6 address, a
default router, and an on-link prefix information. default router, and an on-link prefix information.
For secure autoconfiguration, the IPsec [IPSEC] or SEND method Where support for secure autoconfiguration is required, SEND [SEND]
[SEND] can be used. can be used. Readers should see the applicability statements to
IPsec [IPSEC] within the SEND document.
A stateless configured node wishing to gain other configuration A stateless configured node wishing to gain other configuration
information (e.g. DNS, NTP servers) will likely need a Stateful information (e.g. DNS, NTP servers) will likely need a Stateful
DHCPv6 [DHCPv6] service available. DHCPv6 [DHCPv6] service available.
For nodes configuring using DHCPv6, where DHCPv6 servers are For nodes configuring using DHCPv6, where DHCPv6 servers are
offlink, a DHCPv6 Relay Agent function will be required. Where offlink, a DHCPv6 Relay Agent function will be required. Where
DHCPv4 and DHCPv6 service are deployed together, dual-stack DHCPv4 and DHCPv6 service are deployed together, dual-stack
considerations need to be made, as discussed within current work on considerations need to be made, as discussed within current work on
DHCP dual stack issues [DHDS]. DHCP dual stack issues [DHDS].
skipping to change at page 24, line 23 skipping to change at page 24, line 24
The deployment of specific transition mechanisms may also introduce The deployment of specific transition mechanisms may also introduce
threats, e.g. carrying IPv6 data tunnelled in IPv4. The site threats, e.g. carrying IPv6 data tunnelled in IPv4. The site
security policy should embrace the transition mechanisms that are security policy should embrace the transition mechanisms that are
deployed. deployed.
An overview of IPv6 security issues can be found in [V6SEC]. This An overview of IPv6 security issues can be found in [V6SEC]. This
includes discussion of issues specific to the IPv6 protocol, to includes discussion of issues specific to the IPv6 protocol, to
transition mechanisms, and to IPv6 deployment itself. transition mechanisms, and to IPv6 deployment itself.
In addition an enterprise should review all current Host Based
security requirements for their networks and verify support for
IPv6.
7.5 Stage 3: Widespread Dual-Stack deployment on-site 7.5 Stage 3: Widespread Dual-Stack deployment on-site
With the basic building blocks of external connectivity, interior With the basic building blocks of external connectivity, interior
IPv6 routing, an IPv6 DNS service and address allocation management IPv6 routing, an IPv6 DNS service and address allocation management
in place, the IPv6 capability can be rolled out to the wider in place, the IPv6 capability can be rolled out to the wider
enterprise. This involves putting IPv6 on the wire in the desired enterprise. This involves putting IPv6 on the wire in the desired
links, and enabling applications and other services to begin using links, and enabling applications and other services to begin using
an IPv6 transport. an IPv6 transport.
In the Dual-IP deployment case, this means enabling IPv6 on In the Dual-IP deployment case, this means enabling IPv6 on
skipping to change at page 27, line 13 skipping to change at page 27, line 13
assigned IPv6 prefix address. assigned IPv6 prefix address.
Identifying the responsible device to perform the tunneling is Identifying the responsible device to perform the tunneling is
driven by the position of the incompatible touchpoint. If a local driven by the position of the incompatible touchpoint. If a local
network is incompatible then host tunneling is appropriate. If the network is incompatible then host tunneling is appropriate. If the
backbone (provider) network is incompatible then gateway-to-gateway backbone (provider) network is incompatible then gateway-to-gateway
tunneling might be a better choice. By working to ensure tunnel tunneling might be a better choice. By working to ensure tunnel
endpoints are always configured at dual-IP devices, end-to-end endpoints are always configured at dual-IP devices, end-to-end
communication or services (IPv4 or IPv6) can be preserved. communication or services (IPv4 or IPv6) can be preserved.
Readers should review the current work regarding tunnels within the
IETF Softwire working group and problem statement [SOFTW].
Having IPv6 applications on a Dual-IP host on a v4-only network Having IPv6 applications on a Dual-IP host on a v4-only network
requires some form of tunneling. Where configured tunnels are not requires some form of tunneling. Where configured tunnels are not
sufficient a more automatic solution may be appropriate. Available sufficient a more automatic solution may be appropriate. Available
solutions include ISATAP [ISTP] or Teredo [TRDO] to tunnel to a v6 solutions include ISATAP [ISTP] or Teredo [TRDO] to tunnel to a v6
end service. ISATAP [ISTP] can be used to provide end node IPv6 end service. ISATAP [ISTP] can be used to provide end node IPv6
connectivity from nodes on an isolated IPv4 network, through the connectivity from nodes on an isolated IPv4 network, through the
use of automatic tunneling of IPv6 in IPv4. Teredo [TRDO] can be use of automatic tunneling of IPv6 in IPv4. Teredo [TRDO] can be
used when the enterprise network is behind a NAT. used when the enterprise network is behind a NAT.
Enterprise architects should consider providing a Tunnel Broker Enterprise architects should consider providing a Tunnel Broker
[TBRK] [TSPB] as a cost effective service to local users or [TBRK] [TSPB] as a cost effective service to local users or
applications. Tunnel Brokers can be used to provide tunnel setup applications. Tunnel Brokers can be used to provide tunnel setup
for an enterprise using manual configured tunnels, 6TO4 [6TO4], or for an enterprise using manual configured tunnels and 6TO4 [6TO4].
DSTM [DSTM]. Tunnel Brokers can automate the use of tunnels across Tunnel Brokers can automate the use of tunnels across an enterprise
an enterprise deploying IPv6. deploying IPv6.
Later in the transition process, after the enterprise has Later in the transition process, after the enterprise has
transitioned to a predominately IPv6 infrastructure, the architect transitioned to a predominately IPv6 infrastructure, the architect
will need to determine a network transition strategy to tunnel IPv4 will need to determine a network transition strategy to tunnel IPv4
within IPv6 [V6TUN] across IPv6-dominant links, or the enterprise within IPv6 [V6TUN] across IPv6-dominant links, or the enterprise
Intranet. Or in the case of early deployment of IPv6-dominant Intranet. Or in the case of early deployment of IPv6-dominant
networks the architect will need to address this from the beginning networks the architect will need to address this from the beginning
of the required transition planning. The deployment methodology of the required transition planning.
for an architect to design IPv6-dominant networks is under study
currently, two work in progress reference points that can be used
for analysis are use of Tunnel Brokers [TBRK] or Dual-IP Layer
Transition Mechanism [DSTM].
8.2 Recognizing Application incompatibilities 8.2 Recognizing Application incompatibilities
Having recognized incompatible network touchpoints, it is also Having recognized incompatible network touchpoints, it is also
incumbent on the architect to identify application incumbent on the architect to identify application
incompatibilities. During the transition period, particularly for incompatibilities. During the transition period, particularly for
large enterprises, it is to be expected that applications hosted at large enterprises, it is to be expected that applications hosted at
one location may lead (or lag) the IPv6-compability of its peer (or one location may lead (or lag) the IPv6-compability of its peer (or
server) at some other location. server) at some other location.
skipping to change at page 31, line 32 skipping to change at page 31, line 32
[SEND] Arkko, J. et al. "Secure Neighbor Discovery [SEND] Arkko, J. et al. "Secure Neighbor Discovery
(SEND)". RFC 3971 March 2005. (SEND)". RFC 3971 March 2005.
[PRIVv6] Narten, T., Draves, R., "Privacy Extensions [PRIVv6] Narten, T., Draves, R., "Privacy Extensions
for Stateless Address Autoconfiguration in for Stateless Address Autoconfiguration in
IPv6. RFC 3041 January 2001. IPv6. RFC 3041 January 2001.
11.2 Non-Normative References 11.2 Non-Normative References
[DSTM] Bound, J., (Ed) et al. "Dual Stack Transition
Mechanim" Work in Progress.
[TSPB] Blanchet, M., Parent, F. "IPv6 Tunnel Broker [TSPB] Blanchet, M., Parent, F. "IPv6 Tunnel Broker
with the Tunnel Setup Protocol". with the Tunnel Setup Protocol".
Work in Progress. Work in Progress.
[V6SEC] Davies, E. et al "IPv6 Transition/Co-existence [V6SEC] Davies, E. et al "IPv6 Transition/Co-existence
Security Considerations". Work in Progress. Security Considerations". Work in Progress.
[NAP] Van de Velde, G. et al "IPv6 Network [NAP] Van de Velde, G. et al "IPv6 Network
Architecture Protection". Work in Progress. Architecture Protection". Work in Progress.
skipping to change at page 32, line 21 skipping to change at page 32, line 18
Work in Progress. Work in Progress.
[VLAN] Chown, T. "Use of VLANs for IPv4-IPv6 [VLAN] Chown, T. "Use of VLANs for IPv4-IPv6
Coexistence in Enterprise Networks". Coexistence in Enterprise Networks".
Work in Progress. Work in Progress.
[V6DEF] Roy, S., Durand, A., Paugh, J., "IPv6 Neighbor [V6DEF] Roy, S., Durand, A., Paugh, J., "IPv6 Neighbor
Discovery On-Link Assumption Considered Discovery On-Link Assumption Considered
Harmful". Work in Progress. Harmful". Work in Progress.
[SOFTW] Dawkins, S. (Ed) "Softwire Problem Statement"
Work in Progress
Change Log Change Log
ID 06-07
- Add IP Layer 3 Focus to the title
- Remove IPsec use SEND for Autoconfiguration
- Remove all mentions of DSTM
- Add Softwire Tunnel Reference
- Add Host Based Security check to security section
ID 05 - 06 ID 05 - 06
- Fix ID Nits for IESG - Fix ID Nits for IESG
ID 04 to 05 ID 04 to 05
- Edits: Intro, Sections 4 and 7, References - Edits: Intro, Sections 4 and 7, References
- Update definition IPv6-Dominant - Update definition IPv6-Dominant
- Add Campus Deployment Reference - Add Campus Deployment Reference
- Fix ID-Nits - Fix ID-Nits
July 2005 - February 2006 July 2005 - February 2006
skipping to change at page 34, line 6 skipping to change at page 34, line 14
- Updated section 3 matrix and description to simplify and focus - Updated section 3 matrix and description to simplify and focus
on dual IP layer. on dual IP layer.
- Edited base text of Sections 4-7 but all three require extensive - Edited base text of Sections 4-7 but all three require extensive
additional test for descriptions. additional test for descriptions.
- Edited section 8 and removed table and will reference table in - Edited section 8 and removed table and will reference table in
section 3. This section still needs to be written. section 3. This section still needs to be written.
Document Acknowledgments Acknowledgments
The Author's would like to acknowledge contributions from the The Author's would like to acknowledge contributions from the
following: IETF v6ops Working Group members, Fred Baker, Pekka following: IETF v6ops Working Group members, Fred Baker, Pekka
Savola, and Jordi Palet Savola, and Jordi Palet
Author's Addresses Author's Addresses
Jim Bound Jim Bound
HP HP
110 Spitbrook Road 110 Spitbrook Road
skipping to change at page 36, line 5 skipping to change at page 36, line 5
Email: green@commandinformation.com Email: green@commandinformation.com
Steve Klynsma Steve Klynsma
The MITRE Corporation The MITRE Corporation
7515 Colshire Drive 7515 Colshire Drive
McLean, VA 22102-5708 McLean, VA 22102-5708
USA USA
703-883-6469 703-883-6469
Email: sklynsma@mitre.org Email: sklynsma@mitre.org
Copyright (C) The Internet Society (2006) Intellectual Property and Copyright Statements
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 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.
IPR Disclosure Acknowledgement
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Disclaimer of validity
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; nor does it represent that might or might not be available; nor does it represent that it has
it has made any independent effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the procedures with respect to rights in RFC on the procedures with respect to rights in RFC documents can be
documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Appendix A - Crisis Management Network Scenarios Appendix A - Crisis Management Network Scenarios
Introduction: Introduction:
 End of changes. 27 change blocks. 
95 lines changed or deleted 101 lines changed or added

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