draft-ietf-mmusic-latching-01.txt   draft-ietf-mmusic-latching-02.txt 
Network Working Group E. Ivov Network Working Group E. Ivov
Internet-Draft Jitsi Internet-Draft Jitsi
Intended status: Informational H. Kaplan Intended status: Informational H. Kaplan
Expires: November 08, 2013 Acme Packet Expires: December 12, 2013 Acme Packet
D. Wing D. Wing
Cisco Cisco
May 07, 2013 June 10, 2013
Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Latching: Hosted NAT Traversal (HNT) for Media in Real-Time
Communication Communication
draft-ietf-mmusic-latching-01 draft-ietf-mmusic-latching-02
Abstract Abstract
This document describes behavior of signalling intermediaries in This document describes behavior of signalling intermediaries in
Real-Time Communication (RTC) deployments, sometimes referred to as Real-Time Communication (RTC) deployments, sometimes referred to as
Session Border Controllers (SBCs), when performing Hosted NAT Session Border Controllers (SBCs), when performing Hosted NAT
Traversal (HNT). HNT is a set of mechanisms, such as media relaying Traversal (HNT). HNT is a set of mechanisms, such as media relaying
and latching, that such intermediaries use to enable other RTC and latching, that such intermediaries use to enable other RTC
devices behind NATs to communicate with each other. This document is devices behind NATs to communicate with each other. This document is
non-normative, and is only written to explain HNT in order to provide non-normative, and is only written to explain HNT in order to provide
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 08, 2013. This Internet-Draft will expire on December 12, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 4 3. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 5
4. Media Behavior, Latching . . . . . . . . . . . . . . . . . . 5 4. Media Behavior, Latching . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Informative References . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Network Address Translators (NATs) are widely used in the Internet by Network Address Translators (NATs) are widely used in the Internet by
consumers and organizations. Although specific NAT behaviors vary, consumers and organizations. Although specific NAT behaviors vary,
this document uses the term "NAT" for devices that map any IPv4 or this document uses the term "NAT" for devices that map any IPv4 or
IPv6 address and transport port number to another IPv4 or IPv6 IPv6 address and transport port number to another IPv4 or IPv6
address and transport port number. This includes consumer NATs, address and transport port number. This includes consumer NATs,
Firewall-NATs, IPv4-IPv6 NATs, Carrier-Grade NATs, etc. Firewall-NATs, IPv4-IPv6 NATs, Carrier-Grade NATs, etc.
skipping to change at page 2, line 48 skipping to change at page 3, line 8
Protocols like SIP [RFC3261], and others that try to use a more Protocols like SIP [RFC3261], and others that try to use a more
direct path for media than with signalling, are difficult to use direct path for media than with signalling, are difficult to use
across NATs. They use IP addresses and transport port numbers across NATs. They use IP addresses and transport port numbers
encoded in bodies such as SDP [RFC4566] as well as, in the case of encoded in bodies such as SDP [RFC4566] as well as, in the case of
SIP, various header fields. Such addresses and ports are unusable SIP, various header fields. Such addresses and ports are unusable
unless all peers in a session are located behind the same NAT. unless all peers in a session are located behind the same NAT.
Mechanisms such as Session Traversal Utilities for NAT (STUN) Mechanisms such as Session Traversal Utilities for NAT (STUN)
[RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and
Interactive Connectivity Establishment (ICE) [RFC5245] did not exist Interactive Connectivity Establishment (ICE) [RFC5245] did not exist
when protocols like SIP began being deployed. Session Border when protocols like SIP began being deployed. Some mechanisms, such
Controllers (SBCs) that were already being used by SIP domains for as the early versions of STUN [RFC3489], had started appearing but
other SIP and media-related purposes began to use proprietary they were unreliable and suffered a number of issues typical for
mechanisms to enable SIP devices behind NATs to communicate across UNilateral Self-Address Fixing (UNSAF) and described in [RFC3424].
the NATs. For these and other reasons, Session Border Controllers (SBCs) that
were already being used by SIP domains for other SIP and media-
related purposes began to use proprietary mechanisms to enable SIP
devices behind NATs to communicate across the NATs.
The term often used for this behavior is Hosted NAT Traversal (HNT), The term often used for this behavior is Hosted NAT Traversal (HNT),
although some manufacturers sometimes use other names such as "Far- although some manufacturers sometimes use other names such as "Far-
end NAT Traversal" or "NAT assist" instead. The systems which end NAT Traversal" or "NAT assist" instead. The systems which
perform HNT are frequently SBCs as described in [RFC5853], although perform HNT are frequently SBCs as described in [RFC5853], although
other systems such as media gateways and "media proxies" sometimes other systems such as media gateways and "media proxies" sometimes
perform the same role. For the purposes of this document, all such perform the same role. For the purposes of this document, all such
systems are referred to as SBCs, and the NAT traversal behavior is systems are referred to as SBCs, and the NAT traversal behavior is
called HNT. called HNT.
skipping to change at page 3, line 47 skipping to change at page 4, line 18
The SIP signaling-layer component of HNT is typically more The SIP signaling-layer component of HNT is typically more
implementation-specific and deployment-specific than the SDP and implementation-specific and deployment-specific than the SDP and
media components. For the purposes of this document it is hence media components. For the purposes of this document it is hence
assumed that signaling intermediaries handle traffic in way that assumed that signaling intermediaries handle traffic in way that
allows protocols such as SIP to function correctly across the NATs. allows protocols such as SIP to function correctly across the NATs.
The rest of this document is going to focus primarily on use of HNT The rest of this document is going to focus primarily on use of HNT
for SIP. However, the mechanisms described here are relatively for SIP. However, the mechanisms described here are relatively
generic and are often used with other protocols, such as XMPP generic and are often used with other protocols, such as XMPP
[RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435], H.248/ [RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435], H.248/
MEGACO [RFC3015], and H.323 [H.323]. MEGACO [RFC5125], and H.323 [H.323].
2. Background 2. Background
The general problems with NAT traversal for protocols such as SIP The general problems with NAT traversal for protocols such as SIP
are: are:
1. The addresses and port numbers encoded in SDP bodies (or their 1. The addresses and port numbers encoded in SDP bodies (or their
equivalents) by NATed User Agents (UAs) are not usable across the equivalents) by NATed User Agents (UAs) are not usable across the
Internet, because they represent the private network addressing Internet, because they represent the private network addressing
information of the UA rather than the addresses/ports that will information of the UA rather than the addresses/ports that will
skipping to change at page 5, line 6 skipping to change at page 5, line 25
3. Impact on Signaling 3. Impact on Signaling
Along with codec and other media-layer information, session Along with codec and other media-layer information, session
establishment signaling also conveys, potentially private and non- establishment signaling also conveys, potentially private and non-
globally routable addressing information. Signaling intermediaries globally routable addressing information. Signaling intermediaries
would hence modify such information so that peer UAs are given the would hence modify such information so that peer UAs are given the
(public) addressing information of a media relay controlled by the (public) addressing information of a media relay controlled by the
intermediary. intermediary.
Quite often, the IP address of the newly introduced media relay may Quite often, the IP address of the newly introduced media relay may
be the same as that of the signaling intermediary (e.g. the SIP SBC) be the same as that of the signaling intermediary (e.g. the SIP SBC)
or it may be a completely different one. In almost all cases or it may be a completely different one. In almost all cases
however, the new address would belong to the same IP address family however, the new address would belong to the same IP address family
as the one used for signaling, since it is known to work for that UA. as the one used for signaling, since it is known to work for that UA.
The port numbers introduced in the signaling by the intermediary are The port numbers introduced in the signaling by the intermediary are
typically allocated dynamically. Allocation strategies are entirely typically allocated dynamically. Allocation strategies are entirely
implementation dependent and they often vary from one product to the implementation dependent and they often vary from one product to the
next. next.
The offer/answer media negotiation model [RFC3264] is such that once The offer/answer media negotiation model [RFC3264] is such that once
skipping to change at page 6, line 34 skipping to change at page 6, line 50
traffic would belong to the public interface of the NAT in front traffic would belong to the public interface of the NAT in front
of the UA and anything that the relay sends there would find its of the UA and anything that the relay sends there would find its
way to it. way to it.
5. Similarly the source of the stream originating at the remote 5. Similarly the source of the stream originating at the remote
party would be latched upon and used for media going in that party would be latched upon and used for media going in that
direction. direction.
6. Latching is usually done only once per peer and not allowed to 6. Latching is usually done only once per peer and not allowed to
change or cause a re-latching until a new offer and answer get change or cause a re-latching until a new offer and answer get
exchanged (e.g. in a subsequent call or after a SIP peer has exchanged (e.g. in a subsequent call or after a SIP peer has gone
gone on and off hold). The reasons for such restrictions are on and off hold). The reasons for such restrictions are mostly
mostly related to security: once a session has started a user related to security: once a session has started a user agent is
agent is not expected to suddenly start streaming from a not expected to suddenly start streaming from a different port
different port without sending a new offer first. A change may without sending a new offer first. A change may indicate an
indicate an attempt to hijack the session. In some cases attempt to hijack the session. In some cases however, a port
however, a port change may be caused by a re-mapping in a NAT change may be caused by a re-mapping in a NAT device standing
device standing between the SBC and the UA. More advanced SBCs between the SBC and the UA. More advanced SBCs may therefore
may therefore allow some level of flexibility on the re-latching allow some level of flexibility on the re-latching restrictions
restrictions while carefully considering the potential security while carefully considering the potential security implications
implications of doing so. of doing so.
Figure 2 describes how latching occurs for SIP where HNT is provided Figure 2 describes how latching occurs for SIP where HNT is provided
by an SBC connected to two networks: 203.0.113/24 facing towards the by an SBC connected to two networks: 203.0.113/24 facing towards the
User Agent Client (UAC) network and 198.51.100/24 facing towards the User Agent Client (UAC) network and 198.51.100/24 facing towards the
User Agent Server (UAS) network. User Agent Server (UAS) network.
192.0.2.1 198.51.100.33 192.0.2.1 198.51.100.33
Alice NAT 203.0.113.0/24-SBC-198.51.100.0/24 Bob Alice NAT 203.0.113.0/24-SBC-198.51.100.0/24 Bob
------- --- --- ------- ------- --- --- -------
| | | | | | | |
1. |--SIP INVITE+offer c=192.0.2.1--->| | 1. |--SIP INVITE+offer c=192.0.2.1--->| |
| | | | | | | |
2. | | (SBC allocates 198.51.100.2:22007 | 2. | | (SBC allocates 198.51.100.2:22007 |
| | for inbound RTP from UAS) | | | for inbound RTP from UAS) |
| | | | | | | |
3. | | |---INVITE+offer---->| 3. | | |---INVITE+offer---->|
| | |c=198.51.100.2:22007| | | |c=198.51.100.2:22007|
| | | | | | | |
4. | | |<---180 Ringing-----| 4. | | |<---180 Ringing-----|
| | | | | | | |
| | | | | | | |
5. |<------180 Ringing----------------| | 5. |<------180 Ringing----------------| |
| | | | | | | |
6. | | |<---200+answer------| 6. | | |<---200+answer------|
| | | | | | | |
7. | | (SBC allocates 203.0.113.4:36010 | 7. | | (SBC allocates 203.0.113.4:36010 |
| | for inbound RTP from UAC) | | | for inbound RTP from UAC) |
| | | | | | | |
8. |<-200+answer,c=203.0.113.4:36010--| c=198.51.100.33 | 8. |<-200+answer,c=203.0.113.4:36010--| c=198.51.100.33 |
| | | | | | | |
9. |------------ACK------------------>| | 9. |------------ACK------------------>| |
10. | | |-------ACK--------->| 10. | | |-------ACK--------->|
| | | | | | | |
11. |=====RTP,dest=203.0.113.4:36010==>| | 11. |=====RTP,dest=203.0.113.4:36010==>| |
| | | | | | | |
12. | | (SBC latches to | 12. | | (SBC latches to |
| | source IP address and | | | source IP address and |
| | port seen at (10)) | | | port seen at (10)) |
| | | | | | | |
13. | | |<====== RTP ========| 13. | | |<====== RTP ========|
| | | | | | | |
14. |<=====RTP, to latched address=====| | 14. |<=====RTP, to latched address=====| |
| | | | | | | |
Figure 2: Latching by a SIP SBC across two interfaces Figure 2: Latching by a SIP SBC across two interfaces
While XMPP implementations often rely on ICE to handle NAT traversal, While XMPP implementations often rely on ICE to handle NAT traversal,
there are some that also support a non-ICE transport called XMPP there are some that also support a non-ICE transport called XMPP
Jingle Raw UDP Transport Method [XEP-0177]. Figure 3 describes how Jingle Raw UDP Transport Method [XEP-0177]. Figure 3 describes how
latching occurs for one such XMPP implementation where HNT is latching occurs for one such XMPP implementation where HNT is
provided by an XMPP server on the public internet. provided by an XMPP server on the public internet.
192.0.2.1 192.0.2.9/203.0.113.4 203.0.113.9 198.51.100.8 192.0.2.1 192.0.2.9/203.0.113.4 203.0.113.9 198.51.100.8
XMPP Client1 NAT XMPP Server XMPP Client2 XMPP Client1 NAT XMPP Server XMPP Client2
------- --- --- ------- ----- --- --- -----
| | | | | | | |
1. |----session-initiate cand=192.0.2.1--->| | 1. |----session-initiate cand=192.0.2.1--->| |
| | | | | | | |
2. |<------------ack-----------------------| | 2. |<------------ack-----------------------| |
| | | | | | | |
3. | | (Server allocates 203.0.113.9:2200 | 3. | | (Server allocates 203.0.113.9:2200 |
| | for inbound RTP from Client2) | | | for inbound RTP from Client2) |
| | | | | | | |
4. | | |--session-initiate->| 4. | | |--session-initiate->|
| | cand=203.0.113.9:2200| | | cand=203.0.113.9:2200|
| | | | | | | |
5. | | |<-------ack---------| 5. | | |<-------ack---------|
| | | | | | | |
| | | | | | | |
6. | | |<--session-accept---| 6. | | |<--session-accept---|
| | | cand=198.51.100.8 | | | | cand=198.51.100.8 |
| | | | | | | |
7. | | |--------ack-------> | 7. | | |--------ack-------> |
| | | | | | | |
8. | | (Server allocates 203.0.113.9:3300 | 8. | | (Server allocates 203.0.113.9:3300 |
| | for inbound RTP from Client1) | | | for inbound RTP from Client1) |
| | | | | | | |
9. |<-session-accept cand=203.0.113.9:3300-| | 9. |<-session-accept cand=203.0.113.9:3300-| |
| | | | | | | |
10. |-----------------ack------------------>| | 10. |-----------------ack------------------>| |
| | | | | | | |
| | | | | | | |
11. |======RTP, dest=203.0.113.9:3300======>| | 11. |======RTP, dest=203.0.113.9:3300======>| |
| | | | | | | |
12. | | (XMPP server latches to |
| | src IP 203.0.113.4 and | 12. | | (XMPP server latches to |
| | src port seen at (10)) | | | src IP 203.0.113.4 and |
| | | | | | src port seen at (10)) |
13. | | |<====== RTP ========| | | | |
| | | | 13. | | |<====== RTP ========|
14. |<======RTP, to latched address=========| | | | | |
| | | | 14. |<======RTP, to latched address=========| |
| | | |
Figure 3: Latching by a SIP SBC across two interfaces Figure 3: Latching by a SIP SBC across two interfaces
The above is a general description, and some details vary between The above is a general description, and some details vary between
implementations or configuration settings. For example, some implementations or configuration settings. For example, some
intermediaries perform additional logic before latching on received intermediaries perform additional logic before latching on received
packet source information to prevent malicious attacks or latching packet source information to prevent malicious attacks or latching
erroneously to previous media senders - often called "rogue-rtp" in erroneously to previous media senders - often called "rogue-rtp" in
the industry. the industry.
skipping to change at page 12, line 36 skipping to change at page 12, line 50
Note to the RFC-Editor: please remove this section prior to Note to the RFC-Editor: please remove this section prior to
publication as an RFC. publication as an RFC.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Flemming Andreasen, Miguel A. The authors would like to thank Flemming Andreasen, Miguel A.
Garcia, Ari Keraenen and Paul Kyzivat for their reviews and Garcia, Ari Keraenen and Paul Kyzivat for their reviews and
suggestions on improving this document. suggestions on improving this document.
8. References 8. Informative References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[H.323] International Telecommunication Union , "Packet Based [H.323] International Telecommunication Union , "Packet Based
Multimedia Communication Systems", Recommendation H.323, Multimedia Communication Systems", Recommendation H.323,
July 2003. July 2003.
[RFC3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen,
B., and J. Segers, "Megaco Protocol Version 1.0", RFC
3015, November 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264, June
2002. 2002.
[RFC3424] Daigle, L. IAB, "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control [RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control
Protocol (MGCP) Version 1.0", RFC 3435, January 2003. Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic",
RFC 5125, February 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245, April
2010. 2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
 End of changes. 17 change blocks. 
116 lines changed or deleted 119 lines changed or added

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