draft-ietf-sipping-nat-scenarios-13.txt   draft-ietf-sipping-nat-scenarios-14.txt 
SIPPING Working Group C. Boulton SIPPING Working Group C. Boulton
Internet-Draft NS-Technologies Internet-Draft NS-Technologies
Intended status: BCP J. Rosenberg Intended status: BCP J. Rosenberg
Expires: December 13, 2010 Skype Expires: July 23, 2011 Skype
G. Camarillo G. Camarillo
Ericsson Ericsson
F. Audet F. Audet
Skype Skype
June 11, 2010 January 19, 2011
Best Current Practices for NAT Traversal for Client-Server SIP Best Current Practices for NAT Traversal for Client-Server SIP
draft-ietf-sipping-nat-scenarios-13 draft-ietf-sipping-nat-scenarios-14
Abstract Abstract
Traversal of the Session Initiation Protocol (SIP) and the sessions Traversal of the Session Initiation Protocol (SIP) and the sessions
it establishes through Network Address Translators (NATs) is a it establishes through Network Address Translators (NATs) is a
complex problem. Currently there are many deployment scenarios and complex problem. Currently there are many deployment scenarios and
traversal mechanisms for media traffic. This document aims to traversal mechanisms for media traffic. This document provides
provide concrete recommendations and a unified method for NAT concrete recommendations and a unified method for NAT traversal as
traversal as well as documenting corresponding flows. well as documenting corresponding flows.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 13, 2010. This Internet-Draft will expire on July 23, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 3, line 26 skipping to change at page 3, line 26
The IETF has been active on many specifications for the traversal of The IETF has been active on many specifications for the traversal of
NATs, including STUN[RFC5389], ICE[RFC5245], symmetric NATs, including STUN[RFC5389], ICE[RFC5245], symmetric
response[RFC3581], symmetric RTP[RFC4961], TURN[RFC5766], SIP response[RFC3581], symmetric RTP[RFC4961], TURN[RFC5766], SIP
Outbound[RFC5626], SDP attribute for RTCP[RFC3605], Multiplexing RTP Outbound[RFC5626], SDP attribute for RTCP[RFC3605], Multiplexing RTP
Data and Control Packets on a Single Port[RFC5761] and others. These Data and Control Packets on a Single Port[RFC5761] and others. These
each represent a part of the solution, but none of them gives the each represent a part of the solution, but none of them gives the
overall context for how the NATs traversal problem is decomposed and overall context for how the NATs traversal problem is decomposed and
solved through this collection of specifications. This document solved through this collection of specifications. This document
serves to meet that need. serves to meet that need.
This document provides a definitive set of 'Best Common Practices' to The draft is split into two distinct sections as follows:
demonstrate the traversal of SIP and its associated media through NAT
devices. The document does not propose any new functionality but o Section 4 provides a definitive set of 'Best Common Practices' to
does draw on existing solutions for both core SIP signaling and media demonstrate the traversal of SIP and its associated media through
traversal (as defined in Section 4). NAT devices.
o Section 5 provides non-normative examples representing
interactions of SIP using various NAT type deployments.
The document does not propose any new functionality but does draw on
existing solutions for both core SIP signaling and media traversal
(as defined in Section 4).
The best practices described in this document are for traditional The best practices described in this document are for traditional
"client-server"-style SIP. This term refers to the traditional use "client-server"-style SIP. This term refers to the traditional use
of the SIP protocol where User Agents talk to a series of of the SIP protocol where User Agents talk to a series of
intermediaries on a path to connect to a remote User Agent. It seems intermediaries on a path to connect to a remote User Agent. It seems
likely that other groups using SIP, for example "Peer-to-Peer- likely that other groups using SIP, for example "Peer-to-Peer-
SIP(P2PSIP), will recommend these same practices between a P2PSIP SIP(P2PSIP), will recommend these same practices between a P2PSIP
client and a P2PSIP peer, but will recommend different practices for client and a P2PSIP peer, but will recommend different practices for
use between peers in a peer-to-peer network. use between peers in a peer-to-peer network.
The draft is split into distinct sections as follows:
1. A clear definition of the problem statement.
2. Description of proposed solutions for both SIP protocol signaling
and media signaling.
3. A set of basic and advanced flow scenarios.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
It should be noted that the use of the term 'Endpoint Independent It should be noted that the use of the term 'Endpoint Independent
NAT' in this document refers to a NAT that is both 'Endpoint NAT' in this document refers to a NAT that is both 'Endpoint
Independent Filtering NAT' and 'Endpoint Independent Mapping NAT' per Independent Filtering NAT' and 'Endpoint Independent Mapping NAT' per
RFC 4787 [RFC4787] definition. RFC 4787 [RFC4787] definition.
skipping to change at page 5, line 18 skipping to change at page 5, line 18
that both require attention - The core SIP signaling and associated that both require attention - The core SIP signaling and associated
media traversal. This document assumes NATs that do not contain SIP- media traversal. This document assumes NATs that do not contain SIP-
aware Application Layer Gateways(ALG), which makes much of the issues aware Application Layer Gateways(ALG), which makes much of the issues
discussed in the document not applicable. ALGs have limitations (as discussed in the document not applicable. ALGs have limitations (as
per RFC 4787 [RFC4787]/section 7, RFC 3424 [RFC3424], and [RFC5245]/ per RFC 4787 [RFC4787]/section 7, RFC 3424 [RFC3424], and [RFC5245]/
section 18.6) and experience shows they can have an adverse impact on section 18.6) and experience shows they can have an adverse impact on
the functionality of SIP. This includes problems such as requiring the functionality of SIP. This includes problems such as requiring
the media and signaling to traverse the same device and not working the media and signaling to traverse the same device and not working
with encrypted signaling and/or payload. with encrypted signaling and/or payload.
It should also be noted that Session Border Controllers (SBC) doing The use of non-TURN based media intermediaries is not considered in
'hosted NAT traversal' also make many of the discussions in this this document. More information can be obtained from [RFC5853] and
document moot. More information can be obtained from [RFC5853] and
[I-D.ietf-mmusic-media-path-middleboxes]. [I-D.ietf-mmusic-media-path-middleboxes].
The core SIP signaling has a number of issues when traversing through The core SIP signaling has a number of issues when traversing through
NATs. NATs.
Normal SIP response routing over UDP causes the response to be SIP response routing over UDP as defined in RFC 3261 [RFC3261]
delivered to the source IP address specified in the topmost Via without extensions causes the response to be delivered to the source
header, or the "received" parameter of the topmost Via header. The IP address specified in the topmost Via header, or the "received"
port is extracted from the SIP 'Via' header to complete the IP parameter of the topmost Via header. The port is extracted from the
address/port combination for returning the SIP response. While the SIP 'Via' header to complete the IP address/port combination for
destination for the response is correct, the port contained in the returning the SIP response. While the destination for the response
SIP 'Via' header represents the listening port of the originating is correct, the port contained in the SIP 'Via' header represents the
client and not the port representing the open pin hole on the NAT. listening port of the originating client and not the port
This results in responses being sent back to the NAT but to a port representing the open pin hole on the NAT. This results in responses
that is likely not open for SIP traffic. The SIP response will then being sent back to the NAT but to a port that is likely not open for
be dropped at the NAT. This is illustrated in Figure 1 which depicts SIP traffic. The SIP response will then be dropped at the NAT. This
a SIP response being returned to port 5060. is illustrated in Figure 1 which depicts a SIP response being
returned to port 5060.
Private NAT Public Private NAT Public
Network | Network Network | Network
| |
| |
-------- SIP Request |open port 10923 -------- -------- SIP Request |open port 10923 --------
| |-------------------->--->-----------------------| | | |-------------------->--->-----------------------| |
| | | | | | | | | |
| Client | |port 5060 SIP Response | Proxy | | Client | |port 5060 SIP Response | Proxy |
| | x<------------------------| | | | x<------------------------| |
skipping to change at page 7, line 19 skipping to change at page 7, line 19
connection and opening a pin-hole in the NAT. The generation of a connection and opening a pin-hole in the NAT. The generation of a
new request from the proxy results in a request destined for the new request from the proxy results in a request destined for the
registered entity (Contact IP address) which is not reachable from registered entity (Contact IP address) which is not reachable from
the public network. This results in the new SIP request attempting the public network. This results in the new SIP request attempting
to create a connection to a private network address. This problem to create a connection to a private network address. This problem
would be solved if the original connection was re-used. While this would be solved if the original connection was re-used. While this
problem has been discussed in the context of connection orientated problem has been discussed in the context of connection orientated
protocols such as TCP, the problem exists for SIP signaling using any protocols such as TCP, the problem exists for SIP signaling using any
transport protocol. The impact of connection reuse of connection transport protocol. The impact of connection reuse of connection
orientated transports (TCP, TLS, etc) is discussed in more detail in orientated transports (TCP, TLS, etc) is discussed in more detail in
the connection reuse specification[I-D.ietf-sip-connect-reuse]. The the connection reuse specification[RFC5923]. The approach proposed
approach proposed for this problem in Section 4 of this document is for this problem in Section 4 of this document is relevant for all
relevant for all SIP signaling in conjunction with connection reuse, SIP signaling in conjunction with connection reuse, regardless of the
regardless of the transport protocol. transport protocol.
NAT policy can dictate that connections should be closed after a NAT policy can dictate that connections should be closed after a
period of inactivity. This period of inactivity may vary from a period of inactivity. This period of inactivity may vary from a
number seconds to hours. SIP signaling can not be relied upon to number seconds to hours. SIP signaling can not be relied upon to
keep alive connections for the following two reasons. Firstly, SIP keep alive connections for the following two reasons. Firstly, SIP
entities can sometimes have no signaling traffic for long periods of entities can sometimes have no signaling traffic for long periods of
time which has the potential to exceed the inactivity timer, and this time which has the potential to exceed the inactivity timer, and this
can lead to problems where endpoints are not available to receive can lead to problems where endpoints are not available to receive
incoming requests as the connection has been closed. Secondly, if a incoming requests as the connection has been closed. Secondly, if a
low inactivity timer is specified, SIP signaling is not appropriate low inactivity timer is specified, SIP signaling is not appropriate
skipping to change at page 10, line 18 skipping to change at page 10, line 18
can be divided into two discrete problem areas: getting the SIP can be divided into two discrete problem areas: getting the SIP
signaling across NATs, and enabling media as specified by SDP in a signaling across NATs, and enabling media as specified by SDP in a
SIP offer/answer exchange to flow between endpoints. SIP offer/answer exchange to flow between endpoints.
4.1. SIP Signaling 4.1. SIP Signaling
SIP signaling has two areas that result in transactional failure when SIP signaling has two areas that result in transactional failure when
traversing through NATs, as described in Section 3 of this document. traversing through NATs, as described in Section 3 of this document.
The remaining sub-sections describe appropriate solutions that result The remaining sub-sections describe appropriate solutions that result
in SIP signaling traversal through NATs, regardless of transport in SIP signaling traversal through NATs, regardless of transport
protocol. It is RECOMMENDED that SIP compliant entities follow the protocol. It is advised that SIP compliant entities follow the
guidelines presented in this section to enable traversal of SIP guidelines presented in this section to enable traversal of SIP
signaling through NATs. signaling through NATs.
4.1.1. Symmetric Response 4.1.1. Symmetric Response
As described in Section 3 of this document, when using an unreliable As described in Section 3 of this document, when using an unreliable
transport protocol such as UDP, SIP responses are sent to the IP transport protocol such as UDP, SIP responses are sent to the IP
address and port combination contained in the SIP 'Via' header field address and port combination contained in the SIP 'Via' header field
(or default port for the appropriate transport protocol if not (or default port for the appropriate transport protocol if not
present). Figure 4 illustrates the response traversal through the present). Figure 4 illustrates the response traversal through the
skipping to change at page 11, line 35 skipping to change at page 11, line 35
receiving an incoming request to a SIP Address-Of-Record (AOR), a receiving an incoming request to a SIP Address-Of-Record (AOR), a
proxy/registrar routes to the associated flow created by the proxy/registrar routes to the associated flow created by the
registration and thus a route through NATs. It also provides a registration and thus a route through NATs. It also provides a
keepalive mechanism for clients to keep NATs bindings alive. This is keepalive mechanism for clients to keep NATs bindings alive. This is
achieved by multiplexing a ping/pong mechanism over the SIP signaling achieved by multiplexing a ping/pong mechanism over the SIP signaling
connection (STUN for UDP and CRLF/operating system keepalive for connection (STUN for UDP and CRLF/operating system keepalive for
reliable transports like TCP). Usage of [RFC5626] is RECOMMENDED. reliable transports like TCP). Usage of [RFC5626] is RECOMMENDED.
This mechanism is not transport specific and should be used for any This mechanism is not transport specific and should be used for any
transport protocol. transport protocol.
Even if the SIP Outbound draft is not used, clients generating SIP Even if the SIP Outbound mechanism is not used, clients generating
requests SHOULD use the same IP address and port (i.e., socket) for SIP requests SHOULD use the same IP address and port (i.e., socket)
both transmission and receipt of SIP messages. Doing so allows for for both transmission and receipt of SIP messages. Doing so allows
the vast majority of industry provided solutions to properly for the vast majority of industry provided solutions to properly
function(e.g., SBC hosted NAT traversal). Deployments should also function(e.g., SBC hosted NAT traversal). Deployments should also
consider the mechanism described in the Connection consider the mechanism described in the Connection Reuse[RFC5923]
Reuse[I-D.ietf-sip-connect-reuse] specification for routing bi- specification for routing bi-directional messages securely between
directional messages securely between trusted SIP Proxy servers. trusted SIP Proxy servers.
4.2. Media Traversal 4.2. Media Traversal
The issues of media traversal through NATs is not straight forward The issues of media traversal through NATs is not straight forward
and requires the combination of a number of traversal methodologies. and requires the combination of a number of traversal methodologies.
The technologies outlined in the remainder of this section provide The technologies outlined in the remainder of this section provide
the required solution set. the required solution set.
4.2.1. Symmetric RTP/RTCP 4.2.1. Symmetric RTP/RTCP
skipping to change at page 16, line 43 skipping to change at page 16, line 43
Contact: <sip:bob@192.168.1.2 >;reg-id=1;expires=3600 Contact: <sip:bob@192.168.1.2 >;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0 Content-Length: 0
The response will be sent to the address appearing in the 'received' The response will be sent to the address appearing in the 'received'
parameter of the SIP 'Via' header (address 172.16.3.4). The response parameter of the SIP 'Via' header (address 172.16.3.4). The response
will not be sent to the port deduced from the SIP 'Via' header, as will not be sent to the port deduced from the SIP 'Via' header, as
per standard SIP operation but will be sent to the value that has per standard SIP operation but will be sent to the value that has
been stamped in the 'rport' parameter of the SIP 'Via' header (port been stamped in the 'rport' parameter of the SIP 'Via' header (port
8050). For the response to successfully traverse the NAT, all of the 8050). For the response to successfully traverse the NAT, all of the
conventions defined in RFC 3581 [RFC3581] MUST be obeyed. Make note conventions defined in RFC 3581 [RFC3581] are to be obeyed. Make
of both the 'reg-id' and 'sip.instance' contact header parameters. note of both the 'reg-id' and 'sip.instance' contact header
They are used to establish an Outbound connection tuple as defined in parameters. They are used to establish an Outbound connection tuple
[RFC5626]. The connection tuple creation is clearly shown in as defined in [RFC5626]. The connection tuple creation is clearly
Figure 5. This ensures that any inbound request that causes a shown in Figure 5. This ensures that any inbound request that causes
registration lookup will result in the re-use of the connection path a registration lookup will result in the re-use of the connection
established by the registration. This exonerates the need to path established by the registration. This removes the need to
manipulate contact header URIs to represent a globally routable manipulate contact header URIs to represent a globally routable
address as perceived on the public side of a NAT. address as perceived on the public side of a NAT.
5.1.1.2. Connection Oriented Transport 5.1.1.2. Connection Oriented Transport
Registrar/ Registrar/
Bob NAT Edge Proxy Bob NAT Edge Proxy
| | | | | |
|(1) REGISTER | | |(1) REGISTER | |
|----------------->| | |----------------->| |
skipping to change at page 26, line 25 skipping to change at page 26, line 25
Contact: <sip:alice@172.16.1.4> Contact: <sip:alice@172.16.1.4>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: .. Content-Length: ..
[SDP not shown] [SDP not shown]
It is a standard SIP INVITE request with no additional functionality. It is a standard SIP INVITE request with no additional functionality.
The major difference being that this request will not be forwarded to The major difference being that this request will not be forwarded to
the address specified in the Request-URI, as standard SIP rules would the address specified in the Request-URI, as standard SIP rules would
enforce but will be sent on the flow associated with the registration enforce but will be sent on the flow associated with the registration
binding (look-up procedures in RFC 3263 [RFC3263] are overridden). binding (look-up procedures in RFC 3263 [RFC3263] are overridden by
This then allows the original connection/mapping from the initial RFC 5626 [RFC5626]). This then allows the original connection/
registration process to be re-used. mapping from the initial registration process to be re-used.
5.1.4.2. Edge Proxy/Authoritative Proxy Not Co-located 5.1.4.2. Edge Proxy/Authoritative Proxy Not Co-located
The core SIP signaling associated with this call flow is not impacted The core SIP signaling associated with this call flow is not impacted
directly by the transport protocol and so only one example scenario directly by the transport protocol and so only one example scenario
is necessary. The example uses UDP and follows on from the is necessary. The example uses UDP and follows on from the
registration installed in the example from Section 5.1.2. registration installed in the example from Section 5.1.2.
Bob NAT Edge Proxy Auth. Proxy Alice Bob NAT Edge Proxy Auth. Proxy Alice
| | | | | | | | | |
skipping to change at page 64, line 9 skipping to change at page 64, line 9
supportive throughout. supportive throughout.
Detailed comments were provided by Vijay Gurbani, kaiduan xie, Remi Detailed comments were provided by Vijay Gurbani, kaiduan xie, Remi
Denis-Courmont, Hadriel Kaplan, Phillip Matthews, Spencer Dawkins and Denis-Courmont, Hadriel Kaplan, Phillip Matthews, Spencer Dawkins and
Hans Persson. Hans Persson.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-sip-connect-reuse]
Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in
the Session Initiation Protocol (SIP)",
draft-ietf-sip-connect-reuse-14 (work in progress),
August 2009.
[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.
[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.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, Protocol (SIP): Locating SIP Servers", RFC 3263,
skipping to change at page 65, line 28 skipping to change at page 65, line 22
Initiated Connections in the Session Initiation Protocol Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009. (SIP)", RFC 5626, October 2009.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in
the Session Initiation Protocol (SIP)", RFC 5923,
June 2010.
11.2. Informative References 11.2. Informative References
[I-D.cheshire-nat-pmp] [I-D.cheshire-nat-pmp]
Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
draft-cheshire-nat-pmp-03 (work in progress), April 2008. draft-cheshire-nat-pmp-03 (work in progress), April 2008.
[I-D.ietf-mmusic-media-path-middleboxes] [I-D.ietf-mmusic-media-path-middleboxes]
Stucker, B. and H. Tschofenig, "Analysis of Middlebox Stucker, B. and H. Tschofenig, "Analysis of Middlebox
Interactions for Signaling Protocol Communication along Interactions for Signaling Protocol Communication along
the Media Path", the Media Path",
draft-ietf-mmusic-media-path-middleboxes-02 (work in draft-ietf-mmusic-media-path-middleboxes-03 (work in
progress), March 2009. progress), July 2010.
[I-D.ietf-sipping-v6-transition] [I-D.ietf-sipping-v6-transition]
Camarillo, G., "IPv6 Transition in the Session Initiation Camarillo, G., "IPv6 Transition in the Session Initiation
Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work
in progress), August 2007. in progress), August 2007.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
 End of changes. 20 change blocks. 
68 lines changed or deleted 64 lines changed or added

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