draft-ietf-tram-turn-server-discovery-04.txt   draft-ietf-tram-turn-server-discovery-05.txt 
TRAM P. Patil TRAM P. Patil
Internet-Draft T. Reddy Internet-Draft T. Reddy
Intended status: Standards Track D. Wing Intended status: Standards Track D. Wing
Expires: January 21, 2016 Cisco Expires: April 10, 2016 Cisco
July 20, 2015 October 8, 2015
TURN Server Auto Discovery TURN Server Auto Discovery
draft-ietf-tram-turn-server-discovery-04 draft-ietf-tram-turn-server-discovery-05
Abstract Abstract
Current Traversal Using Relays around NAT (TURN) server discovery Current Traversal Using Relays around NAT (TURN) server discovery
mechanisms are relatively static and limited to explicit mechanisms are relatively static and limited to explicit
configuration. These are usually under the administrative control of configuration. These are usually under the administrative control of
the application or TURN service provider, and not the enterprise, the application or TURN service provider, and not the enterprise,
ISP, or the network in which the client is located. Enterprises and ISP, or the network in which the client is located. Enterprises and
ISPs wishing to provide their own TURN servers need auto discovery ISPs wishing to provide their own TURN servers need auto discovery
mechanisms that a TURN client could use with no or minimal mechanisms that a TURN client could use with no or minimal
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 January 21, 2016. This Internet-Draft will expire on April 10, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
4.1.2. From own Identity . . . . . . . . . . . . . . . . . . 5 4.1.2. From own Identity . . . . . . . . . . . . . . . . . . 5
4.2. Resolution . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Resolution . . . . . . . . . . . . . . . . . . . . . . . 5
5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 6 5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 6
5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Discovery using Anycast . . . . . . . . . . . . . . . . . . . 8 6. Discovery using Anycast . . . . . . . . . . . . . . . . . . . 8
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 8
7.1. Mobility and Changing IP addresses . . . . . . . . . . . 9 7.1. Mobility and Changing IP addresses . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9.1. Service Resolution . . . . . . . . . . . . . . . . . . . 9 9.1. Service Resolution . . . . . . . . . . . . . . . . . . . 10
9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 10 9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 10
9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 13 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 13
A.1. Change from draft-patil-tram-serv-disc-00 to -01 . . . . 13 A.1. Change from draft-patil-tram-serv-disc-00 to -01 . . . . 14
A.2. Change from draft-ietf-tram-turn-server-discovery-01 to A.2. Change from draft-ietf-tram-turn-server-discovery-01 to
02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
TURN [RFC5766] is a protocol that is often used to improve the TURN [RFC5766] is a protocol that is often used to improve the
connectivity of Peer-to-Peer (P2P) applications (as defined in connectivity of Peer-to-Peer (P2P) applications (as defined in
section 2.7 of [RFC5128]). TURN allows a connection to be section 2.7 of [RFC5128]). TURN allows a connection to be
established when one or both sides are incapable of a direct P2P established when one or both sides are incapable of a direct P2P
connection. It is an important building block for interactive, real- connection. It is an important building block for interactive, real-
time communication using audio, video, collaboration etc. time communication using audio, video, collaboration etc.
While TURN services are extensively used today, the means to auto While TURN services are extensively used today, the means to auto
discover TURN servers do not exist. TURN clients are usually discover TURN servers do not exist. TURN clients are usually
explicitly configured with a well known TURN server. To allow TURN explicitly configured with a well known TURN server. To allow TURN
applications to operate seamlessly across different types of networks applications to operate seamlessly across different types of networks
and encourage the use of TURN without the need for manual and encourage the use of TURN without the need for manual
configuration, it is important that there exists an auto discovery configuration, it is important that there exists an auto discovery
mechanism for TURN services. Web Real-Time Communication (WebRTC) mechanism for TURN services. Web Real-Time Communication (WebRTC)
[I-D.ietf-rtcweb-overview] usages and related extensions, which are [I-D.ietf-rtcweb-overview] usages and related extensions, which are
mostly based on web applications, need this immediately. mostly based on web applications, need this immediately.
This document describes three discovery mechanisms. The reason for This document describes three discovery mechanisms, so as to maximize
providing multiple mechanisms is to maximize the opportunity for opportunity for discovery, based on the network in which the TURN
discovery, based on the network in which the TURN client finds client finds itself. The three discovery mechanisms are:
itself. The three discovery mechanisms are:
o A resolution mechanism based on straightforward Naming Authority o A resolution mechanism based on straightforward Naming Authority
Pointer (S-NAPTR) resource records in the Domain Name System Pointer (S-NAPTR) resource records in the Domain Name System
(DNS). [RFC5928] describes details on retrieving a list of server (DNS). [RFC5928] describes details on retrieving a list of server
transport addresses from DNS that can be used to create a TURN transport addresses from DNS that can be used to create a TURN
allocation. allocation.
o DNS Service Discovery o DNS Service Discovery
o A mechanism based on anycast address for TURN. o A mechanism based on anycast address for TURN.
skipping to change at page 3, line 44 skipping to change at page 3, line 43
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Discovery Procedure 3. Discovery Procedure
A TURN client that implements the auto discovery algorithm uses the A TURN client that implements the auto discovery algorithm uses the
following mechanisms for discovery: following mechanisms for discovery:
1. Local Configuration : Local or manual TURN configuration (i.e., 1. Local Configuration : Local or manual TURN configuration i.e.,
TURN servers configured at the system level) should be tried TURN servers configured at the system level. For example, in
first, as it may be an explicit preferred choice of a user. An case of Web Real-Time Communication (WebRTC)
[I-D.ietf-rtcweb-overview] usages and related extensions, which
are based on web applications, a Java Script specified TURN
server MUST be considered as local configuration. An
implementation MAY give the user an opportunity (e.g., by means implementation MAY give the user an opportunity (e.g., by means
of configuration file options or menu items) to specify a TURN of configuration file options or menu items) to specify a TURN
server for every address family. server for each address family.
2. Service Resolution : The TURN client attempts to perform TURN 2. Service Resolution : The TURN client attempts to perform TURN
service resolution using the host's DNS domain. service resolution using the host's DNS domain.
3. DNS SD: DNS Service Discovery. 3. DNS SD: DNS Service Discovery.
4. Anycast : Send TURN allocate request to the assigned TURN anycast 4. Anycast : Send TURN allocate request to the assigned TURN anycast
request for each combination of interface and address family. request for each combination of interface and address family.
Not all TURN servers may be discovered using NAPTR records or DNS SD; Not all TURN servers may be discovered using NAPTR records or DNS SD;
Similarly, not all TURN servers may support anycast. For best Similarly, not all TURN servers may support anycast. For best
results, a client SHOULD implement all discovery mechanisms described results, a client SHOULD implement all discovery mechanisms described
above. above.
The document does not prescribe a strict order that a client must The document does not prescribe a strict order that a client must
follow for discovery. An implementation may choose to perform steps follow for discovery. An implementation may choose to perform all
2,3 and 4 in parallel for discovery OR choose to follow any desired the above steps in parallel for discovery OR choose to follow any
order and stop the discovery procedure if a mechanism succeeds. desired order and stop the discovery procedure if a mechanism
succeeds.
On hosts with more than one interface or address family (IPv4/v6), On hosts with more than one interface or address family (IPv4/v6),
the TURN server discovery procedure has to be performed for each the TURN server discovery procedure has to be performed for each
combination of interface and address family. A client MAY optionaly combination of interface and address family. A client MAY optionaly
choose to perform the discovery procedure only for a desired choose to perform the discovery procedure only for a desired
interface/address combination if the client does not wish to discover interface/address combination if the client does not wish to discover
a TURN server for all combinations of interface and address family. a TURN server for all combinations of interface and address family.
4. Discovery using Service Resolution 4. Discovery using Service Resolution
skipping to change at page 9, line 31 skipping to change at page 9, line 31
IANA should allocate an IPv4 and an IPv6 well-known TURN anycast IANA should allocate an IPv4 and an IPv6 well-known TURN anycast
address. 192.0.0.0/24 and 2001:0000::/48 are reserved for IETF address. 192.0.0.0/24 and 2001:0000::/48 are reserved for IETF
Protocol Assignments, as listed at Protocol Assignments, as listed at
<http://www.iana.org/assignments/iana-ipv4-special-registry/> and <http://www.iana.org/assignments/iana-ipv4-special-registry/> and
<http://www.iana.org/assignments/iana-ipv6-special-registry/> <http://www.iana.org/assignments/iana-ipv6-special-registry/>
9. Security Considerations 9. Security Considerations
In general, it is recommended that a TURN client authenticate with Clients can use TURN servers provided by the local network or by the
the TURN server to identify a rouge server. [RFC7350] can be access network without authenticating with the TURN server. It is
potentially used by a client to validate a previously unknown server. recommended that clients use (D)TLS with network provided TURN
servers to validate the TURN server and prevent man-in-middle
attacks. A TURN client may use the following techniques to validate
a TURN server:
o For certificate-based authentication, a pre-populated trust anchor
store [RFC6024] allows a TURN client to perform path validation
for the server certificate obtained during the (D)TLS handshake.
If the client used a domain name to discover the TURN server, that
domain name also provides a mechanism for validation of the TURN
server. The client MUST use the rules and guidelines given in
section 6 of [RFC6125] to validate the TURN server identity.
o For TURN servers that don't have a certificate trust chain (e.g.,
because they are on a home network or a corporate network), a
configured list of TURN servers can contain the Subject Public Key
Info (SPKI) fingerprint of the TURN servers. The public key is
used for the same reasons HTTP pinning [RFC7469] uses the public
key.
o Raw public key-based authentication, as defined in [RFC7250],
could also be used to authenticate a TURN server.
o For opportunistic privacy, analogous to SMTP opportunistic
encryption [RFC7435] one does not require privacy, but one desires
privacy when possible. With opportunistic privacy, a client might
learn of a TLS-enabled TURN server from an untrusted source and
may not be able to validate the TLS certificate. These choices
maximize availability and performance, but they leave the client
vulnerable to on-path attacks that remove privacy. Opportunistic
privacy can be used by any current client, but it only provides
guaranteed privacy when there are no on-path active attackers.
9.1. Service Resolution 9.1. Service Resolution
The primary attack against the methods described in this document is The primary attack against the methods described in this document is
one that would lead to impersonation of a TURN server. An attacker one that would lead to impersonation of a TURN server. An attacker
could attempt to compromise the S-NAPTR resolution. Security could attempt to compromise the S-NAPTR resolution. Security
considerations described in [RFC5928] are applicable here as well. considerations described in [RFC5928] are applicable here as well.
In addition to considerations related to S-NAPTR, it is important to In addition to considerations related to S-NAPTR, it is important to
recognize that the output of this is entirely dependent on its input. recognize that the output of this is entirely dependent on its input.
skipping to change at page 10, line 49 skipping to change at page 11, line 32
configuration can occur naturally via BGP messages advertising that configuration can occur naturally via BGP messages advertising that
no route exists to said address. no route exists to said address.
Sensitive clients that do not wish to leak information about their Sensitive clients that do not wish to leak information about their
presence can set an IP TTL on their TURN requests that limits how far presence can set an IP TTL on their TURN requests that limits how far
they can travel into the public Internet. they can travel into the public Internet.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Simon Perrault, Paul Kyzivat, Troy The authors would like to thank Simon Perrault, Paul Kyzivat, Troy
Shields, Eduardo Gueiros and Ted Hardie for their review and valuable Shields, Eduardo Gueiros, Ted Hardie, Bernard Aboba and Karl Stahl
comments. Thanks to Adam Roach for his detailed review and for their review and valuable comments. Thanks to Adam Roach for his
suggesting DNS Service Discovery as an additional discovery detailed review and suggesting DNS Service Discovery as an additional
mechanism. discovery mechanism.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 11, line 33 skipping to change at page 12, line 14
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997, RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://www.rfc-editor.org/info/rfc2136>. <http://www.rfc-editor.org/info/rfc2136>.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
<http://www.rfc-editor.org/info/rfc3007>. <http://www.rfc-editor.org/info/rfc3007>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
DOI 10.17487/RFC3596, October 2003,
<http://www.rfc-editor.org/info/rfc3596>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>. <http://www.rfc-editor.org/info/rfc4033>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
<http://www.rfc-editor.org/info/rfc5198>. <http://www.rfc-editor.org/info/rfc5198>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
skipping to change at page 12, line 23 skipping to change at page 12, line 47
<http://www.rfc-editor.org/info/rfc5986>. <http://www.rfc-editor.org/info/rfc5986>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>. <http://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>. <http://www.rfc-editor.org/info/rfc6763>.
[RFC7216] Thomson, M. and R. Bellis, "Location Information Server
(LIS) Discovery Using IP Addresses and Reverse DNS",
RFC 7216, DOI 10.17487/RFC7216, April 2014,
<http://www.rfc-editor.org/info/rfc7216>.
[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
Layer Security (DTLS) as Transport for Session Traversal
Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350,
August 2014, <http://www.rfc-editor.org/info/rfc7350>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-14 Browser-based Applications", draft-ietf-rtcweb-overview-14
(work in progress), June 2015. (work in progress), June 2015.
[I-D.kist-alto-3pdisc]
Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party
ALTO Server Discovery (3pdisc)", draft-kist-alto-3pdisc-05
(work in progress), January 2014.
[I-D.wing-tram-turn-mobility] [I-D.wing-tram-turn-mobility]
Wing, D., Patil, P., Reddy, T., and P. Martinsen, Wing, D., Patil, P., Reddy, T., and P. Martinsen,
"Mobility with TURN", draft-wing-tram-turn-mobility-03 "Mobility with TURN", draft-wing-tram-turn-mobility-03
(work in progress), May 2015. (work in progress), May 2015.
[RFC3188] Hakala, J., "Using National Bibliography Numbers as [RFC3188] Hakala, J., "Using National Bibliography Numbers as
Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188, Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188,
October 2001, <http://www.rfc-editor.org/info/rfc3188>. October 2001, <http://www.rfc-editor.org/info/rfc3188>.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Peer (P2P) Communication across Network Address Peer (P2P) Communication across Network Address
Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March
2008, <http://www.rfc-editor.org/info/rfc5128>. 2008, <http://www.rfc-editor.org/info/rfc5128>.
[RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
H. Song, "Application-Layer Traffic Optimization (ALTO) Requirements", RFC 6024, DOI 10.17487/RFC6024, October
Server Discovery", RFC 7286, DOI 10.17487/RFC7286, 2010, <http://www.rfc-editor.org/info/rfc6024>.
November 2014, <http://www.rfc-editor.org/info/rfc7286>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <http://www.rfc-editor.org/info/rfc7250>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
2015, <http://www.rfc-editor.org/info/rfc7469>.
Appendix A. Change History Appendix A. Change History
[Note to RFC Editor: Please remove this section prior to [Note to RFC Editor: Please remove this section prior to
publication.] publication.]
A.1. Change from draft-patil-tram-serv-disc-00 to -01 A.1. Change from draft-patil-tram-serv-disc-00 to -01
o Added IP address (Section 4.1.2) and Own identity (4.1.3) as new o Added IP address (Section 4.1.2) and Own identity (4.1.3) as new
means to obtain domain names means to obtain domain names
 End of changes. 17 change blocks. 
52 lines changed or deleted 86 lines changed or added

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