One document matched: draft-kaplan-enum-source-uri-00.txt
ENUM Working Group H. Kaplan
Internet Draft Acme Packet
Intended status: Standards Track R. Walter
Expires: June 11, 2008 NetNumber
R. Gopal
Nominum
T. Creighton
Comcast Cable Communications
December 11, 2007
DNS Extension for ENUM Source-URI
draft-kaplan-enum-source-uri-00
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 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.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on June 11, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Kaplan Expires June 1, 2008 [Page 1]
DNS Extension for ENUM Source-URI December 2007
Abstract
This document defines a specific DNS extension, based on the EDNS0
OPT RR, for an ENUM query to include the source URI which caused the
ENUM request. This is useful, for example, to specify the
originating SIP or TEL URI from a SIP request which triggered the
ENUM query, so the ENUM server can provide a different response.
Table of Contents
1. Introduction................................................2
2. Terminology.................................................3
3. Applicability...............................................3
4. Overview of Operation.......................................3
5. ENUM Client Behavior........................................4
6. ENUM Server Behavior........................................4
7. DNS Extension Option Code...................................4
8. Opt-RR Format...............................................4
9. RDATA Format................................................5
10. Example Exchange............................................5
11. Security Considerations.....................................5
12. IANA Considerations.........................................6
13. References..................................................6
13.1. Normative References...................................6
13.2. Informative References.................................6
Authors' Addresses................................................6
Full Copyright Statement..........................................8
Intellectual Property Statement...................................8
Acknowledgment....................................................8
1. Introduction
SIP session routing based on private-ENUM resolution has been
gaining ground in some large operator networks. However, a need has
arisen to respond with different ENUM/DNS responses based on the
originating username or domain of the application request which
triggered the ENUM query, such as a SIP request. For example, it is
often cheaper to route calls from local source prefix numbers to
other local prefixes numbers in a given region directly, whereas
out-of-region sources going to the same destination numbers may be
cheaper to send through a transit provider or even the PSTN.
Another example is when only certain calling domains can source
specific calling numbers, and ENUM is used to determine the
legitimacy of the source.
Kaplan Expires - June 2007 [Page 2]
DNS Extension for ENUM Source-URI December 2007
Today such source-based routing with ENUM is performed through
various means, which are usually cumbersome and error-prone. A
common example is where the proxy performing the lookup changes the
ENUM root based on a source prefix, and thus the ENUM server has a
separate root per source prefix; or the server returns all possible
results with proprietary indicators for source filtering. These
mechanisms typically require the ENUM client and server to agree on
a common scheme, and require every proxy to know and use the same
proprietary scheme, which leads to interoperability problems.
This draft proposes a specific, yet flexible, mechanism for
performing such lookups. The DNS extension OPT RR mechanism defined
in [EDNS0] is used to provide the ENUM server the source URI of the
SIP request, with which it can make its own local decision of which
responses to provide.
Note that using the OPT RR for this purpose is not a perfect model.
Local response caching must be avoided, and typically the OPT RR is
used for generic DNS capabilities below the database layer, rather
than as part of the input to the database lookup. In particular, it
does not address how such source information is populated in the DNS
server records or tree, which may lead to different implementations,
and does not describe how to transfer such data between DNS servers.
Instead, this draft is focused on ENUM servers, rather than all DNS
servers.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. The
terminology in this document conforms to RFC 2828, "Internet
Security Glossary".
3. Applicability
This draft proposes a DNS extension based on [EDNS0].
4. Overview of Operation
The general concept is that a SIP/H.323/etc. UAC or Proxy, acting as
the ENUM client, inserts the URI from the SIP Request's P-Asserted-
Identity header, or the From header, or the calling party info, in
an OPT RR RDATA field in the ENUM query. The ENUM server then may
use the originating URI information (username, domain, etc.) in
choosing what responses to send in response to the query.
Kaplan Expires - June 2007 [Page 3]
DNS Extension for ENUM Source-URI December 2007
5. ENUM Client Behavior
The ENUM client inserts the originating URI in the RDATA portion of
an [EDNS0] OPT RR in the ENUM query, by copying the SIP-URI, SIPS-
URI or TEL-URI from the P-Asserted-Identity header, if present, and
if not present then that from the From header of the request. For
H.323 or other protocols, a TEL-URI is formed from the calling
number. Note that for SIP, this would include both the full
sip:username@domain and any URI parameters. It does NOT include any
display-name, less-than or greater-than symbols (LAQUOT/RAQUOT), or
header parameters. It is literally the SIP-URI or SIPS-URI as
defined by the ABNF in [RFC3261], or the telephone-URI as defined by
[RFC3966].
The ENUM client MUST NOT cache responses for such queries, and
instead MUST treat the TTL value as zero. Otherwise the local cache
would be used for subsequent queries, even if the originating info
changed, which would lead to false results. Clearly this could be
overridden based on local policy, if the client had control of its
DNS cache implementation to include the originating number.
However, it should be noted that typical ENUM queries hardly ever
benefit from caching, because the probability of the same numbers
being dialed in a short interval are very low.
6. ENUM Server Behavior
An ENUM Server which supports this extension MAY use the originating
URI encoded in the RDATA for its lookup process. The details of how
it does so are out of scope of this draft. The ENUM Server MUST
support the SIP-URI, SIPS-URI and telephone-URI formats, as defined
by [RFC3261] and [RFC3966] respectively. It MUST ignore any
parameters it does not understand - i.e., it is not a protocol
failure that the URI contains parameters the ENUM server does not
understand.
The ENUM server MUST set all responses for requests which contained
this extension with a TTL of zero.
7. DNS Extension Option Code
The EDNS0 Option Code will be assigned by IANA.
8. Opt-RR Format
All OPT-RRs used in Source-URI are formatted as follows:
Kaplan Expires - June 2007 [Page 4]
DNS Extension for ENUM Source-URI December 2007
Field Name Field Type Description
-------------------------------------------------------------------
NAME domain name empty (root domain)
TYPE u_int16_t OPT
CLASS u_int16_t 1220 (minimum)*
TTL u_int32_t 0
RDLEN u_int16_t describes RDATA
RDATA octet stream (see below)
* The CLASS field indicates, as per [EDNS0], the sender's UDP
payload size. Per [draft-ietf-enum-edns0], ENUM clients MUST
support 1220 bytes, but SHOULD support at least 4000.
9. RDATA Format
Field Name Field Type Description
--------------------------------------------------------------------
OPTION-CODE u_int16_t Source-URI
OPTION-LENGTH u_int16_t Length of following fields
VERSION u_int16_t Version of S-URI mechanism
URI char_string SIP/SIPS/TEL-URI data
The current Version is 0. Future drafts may specify other versions,
but they must be compatible with this one. (i.e., they can specify
more data, but not less)
The URI field is null-terminated, ASCII representation of the URI.
One example is a SIP/SIPS/TEL-URI, including the "sip:", "sips:", or
"tel:" schemes. Non-Ascii characters, or characters not allowed in
the ABNF for a SIP-URI/SIPS-URI/TEL-URI format per [RFC3261] or
[RFC3966] MUST be escaped per those formats.
10. Example Exchange
[Do we need an example?]
11. Security Considerations
There are no specific security issues for this mechanism, beyond
those already applicable to DNS and ENUM.
Kaplan Expires - June 2007 [Page 5]
DNS Extension for ENUM Source-URI December 2007
12. IANA Considerations
This document will presumably register appropriate Option code with
IANA, if it moves forward.
13. References
13.1. Normative References
[EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
3966, December 2004.
13.2. Informative References
[draft-ietf-enum-edns0] Conroy, L., Reid, J., "ENUM Requirement for
EDNS0 Support", draft-ietf-enum-edns0-00.txt, September 2006.
Authors' Addresses
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803
USA
Email: hkaplan@acmepacket.com
Robert H. Walter
NetNumber, Inc.
650 Suffolk Street, Suite 307
Lowell, MA 01854
USA
Email: rwalter@netnumber.com
Raja Gopal
Nominum, Inc.
2385 Bay Road
Redwood City, CA 94063
USA
Email: raja.gopal@nominum.com
Kaplan Expires - June 2007 [Page 6]
DNS Extension for ENUM Source-URI December 2007
Tom Creighton
Comcast Cable Communications
1500 Market Street
Philadelphia, PA 19102
USA
Email: tom_creighton@cable.comcast.com
Kaplan Expires - June 2007 [Page 7]
DNS Extension for ENUM Source-URI December 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Thanks to Richard Shockey, Prakash Mistry, and David Schwartz for
feedback and comments.
Kaplan Expires - June 2007 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 05:38:15 |