Internet DRAFT - draft-kaplan-dns-opaque-text-opt-code
draft-kaplan-dns-opaque-text-opt-code
DNSExt Working Group H. Kaplan
Internet Draft Acme Packet
Intended status: Informational R. Walter
Expires: January 7, 2009 NetNumber
R. Gopal
Nominum
T. Creighton
Comcast Cable Communications
July 7, 2008
EDNS Option Code for Private Opaque Text
draft-kaplan-dns-opaque-text-opt-code-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 January 7, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Kaplan Expires January 1, 2008 [Page 1]
EDNS Option Code for Private Text July 2008
Abstract
This document requests an IANA allocation for an EDNS Option code,
per [RFC2671], for an opaque text field for private use.
Table of Contents
1. Introduction................................................2
2. Terminology.................................................2
3. Applicability...............................................2
4. OPTION-DATA Format..........................................3
5. Security Considerations.....................................3
6. IANA Considerations.........................................3
7. References..................................................3
7.1. Normative References...................................3
7.2. Informative References.................................3
Authors' Addresses................................................4
Full Copyright Statement..........................................5
Intellectual Property Statement...................................5
Acknowledgment....................................................5
1. Introduction
In certain circumstances, DNS clients querying a private DNS server
need to provide the server with some additional private data to
facilitate the lookup process. The additional data is in the form
of a text string, which needs to be provided in the DNS query
request. The Extension Mechanism for DNS (EDNS) defined in
[RFC2671] provides a suitable means by which to encode such a string
into the DNS request, using the OPT RR and a new EDNS Option code
indicating this text field use. This document requests IANA for
assignment of such an Option code.
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 requests a new Option code value based on [EDNS0].
Kaplan Expires - January 2007 [Page 2]
EDNS Option Code for Private Text July 2008
4. OPTION-DATA Format
The format of the OPTION-DATA contents is an ascii-text string, with
no character termination (the OPTION-LENGTH field identifies the
length).
Although the text string should be opaque in general, for the
private use envisioned for it the contents of the text string are a
URI, typically a SIP 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.
The usage and source of the text content is outside the scope of
this document. It is of a hop-by-hop nature, not transitive.
5. Security Considerations
There are no specific security issues for this IANA request.
6. IANA Considerations
This document will presumably register an appropriate Option code
with IANA, if it moves forward.
7. References
7.1. Normative References
[RFC2671] 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.
7.2. Informative References
none.
Kaplan Expires - January 2007 [Page 3]
EDNS Option Code for Private Text July 2008
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
Tom Creighton
Comcast Cable Communications
1500 Market Street
Philadelphia, PA 19102
USA
Email: tom_creighton@cable.comcast.com
Kaplan Expires - January 2007 [Page 4]
EDNS Option Code for Private Text July 2008
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).
Kaplan Expires - January 2007 [Page 5]
