idnits 2.17.1 draft-ogud-appsawg-multiple-namespaces-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3724 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4034' is defined on line 212, but no explicit reference was found in the text -- No information found for draft-iesg-special-use-p2p-names - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 4627 (Obsoleted by RFC 7158, RFC 7159) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Gudmundsson 3 Internet-Draft Shinkuro Inc. 4 Intended status: Standards Track February 14, 2014 5 Expires: August 18, 2014 7 Providing support for multiple namespaces to Internet protocols. 8 draft-ogud-appsawg-multiple-namespaces-00 10 Abstract 12 Over the years there have been various proposals as to use namespaces 13 other than the DNS/IN namespace that is under ICANN administration. 14 Some of these were simple DNS competitors others use different lookup 15 technologies. In addition it is hard to supply different character 16 encodings to DNS as each application needs to provide the translation 17 between the encoding used and the format expected by DNS. 19 This draft proposes a new service layer to provide multiplexing of 20 different namespaces into appropriate function calls. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 18, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Not all Namespaces are equal . . . . . . . . . . . . . . . . 3 59 3. Illustrative Examples . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Non DNS namespace . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Different DNS class . . . . . . . . . . . . . . . . . . . 4 62 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 4 63 5. Security considerations . . . . . . . . . . . . . . . . . . . 5 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 65 7. Informative References . . . . . . . . . . . . . . . . . . . 5 66 Appendix A. Document history . . . . . . . . . . . . . . . . . . 5 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 Most of us assume that there exists only one namespace on the 72 Internet, the DNS in class IN [RFC1034]. But in practice there are 73 multiple, in addition there are IPv4 and IPv6 address spaces, the 74 Bonjor/MDNS local net namespace. Number of groups are proposing new 75 namespaces that may or may not use DNS as underlying resolution 76 protocol. 78 The "state of the art" in identifying what namespace is used is by 79 using a postfix on the domain name, for example "ogud.onion" is a 80 lookup in a distributed hash table [GNU]. As identified in this 81 draft ALT TLD [ALT], proposing that such new uses be placed in a 82 "squatters TLD" called .alt there are many drawbacks to using what 83 looks like a DNS name to express a different lookup mechanism. One 84 effect is the overhead of trying to locally stop queries to go to the 85 internet[RFC6303] and special use registry exists[RFC6761]. Recently 86 a draft [ReserveTLD] requested a number of allocations some of which 87 are for namespaces that are not normal global DNS namespaces. 89 A further side effect of trying to fit new namespaces into the DNS 90 namespace via TLD name or other trailing names is that developers 91 then try to extend the resolution functions on the host OS to support 92 multiple lookup mehcanisms. 94 This draft proposes a radical solution of placing a "Namespace 95 Identifier" at the front of the name and relies on new software to 96 perform multiplexing between the different namespace lookup 97 mechanisms available on an host. This technique allows the host 98 itself to reject unsupported lookups rather than leak them to DNS 99 resolvers, or to authoritative servers. This is similar to URI but 100 places an explicit namespace identifier on the "name". 102 At this point this is call for discussion rather than an proposed 103 solution, all examples in this document are for illustration only. 104 It is easy to get into adversarial discussions on this topic thus the 105 draft tries to be non-confrontational, if the draft fails at that the 106 editor apologizes. 108 1.1. Terminology 110 None at this time. 112 2. Not all Namespaces are equal 114 Right now the Internet has two universal namespace (DNS in class IN) 115 and IPv4 addresses. There are number of minor namespaces in use such 116 as .local for local networks, DNS class CHAOS for few applications. 118 DNS class field has not been widely used due to perceived 119 difficulties in setting up new set of root servers for each class and 120 propagate the information to the clients. 122 Using suffix TLD name on the other hand requires the hosts/ 123 applications/resolvers to know the suffix string and have the 124 capability to resolve using the resolution process specified for that 125 suffix. 127 It is not hard to imagine namespaces that work quite differently from 128 DNS such as by creating long lived connections to the "servers" or 129 exchange information via "modern" encodings like Json [RFC4627]. 131 For these reasons it seems a better solution for multiple namespace 132 existence to have OS's provide a Namespace Abstraction layer that 133 applications call and each name space registers with the Abstraction 134 layer the functions to use. 136 3. Illustrative Examples 138 The proposal for the "Meta-TLD" .gnu [GNU]specifies a distributed 139 hash table to avoid centralized control of the namespace. This 140 resolution is nothing like the DNS resolution so trying to extend 141 functions like gethostbyname() to support multiple different lookup 142 techniques is likely to have adverse effects on the reliability of 143 the base OS functions. 145 3.1. Non DNS namespace 147 For a new namespace MARGIR (Icelandic for many) names are expressed 148 like this: 150 https://MARGIR##ACDBU0OCABU0R1FEL7V75RQE1G2GSVQM 151 application will call function 152 ret = namepace_lookup( "MARGIR##ACDBU0OCABU0R1FEL7V75RQE1G2GSVQM", 153 TYPE_ADDR, & answer) ; 155 If the function returns error code "do not understand name space" the 156 application knows this is something it can not use, there is no leak 157 of information from the host. If the function returns success then 158 the application can use the answer structure and proceed. 160 Underneath the namespace_lookup() function there is are calls to 161 various functions for each namespace, these functions are provided 162 via libraries, and each namespace provides a binding to the standard 163 calls such as: 165 Margir = { 166 TYPE_ADDR = margir_lookup(A1, A2, & A3); 167 TYPE_TXT = margir_lookup(A1, 888, & A3); 168 .... 169 } 171 3.2. Different DNS class 173 For a DNS lookups in a different class it is much easier to reuse the 174 existing lookup functions but still a translation is useful. 176 https://CLASS666##bad.lucifer. 178 Translation table can be 180 CLASS666 = { 181 TYPE_ADDR = gethostname(A1, CLASS_666, TYPE_A, & A3); 182 TYPE_TXT = query_by_type(A1, CLASS_666, TYPE_TXT, & A3); 183 .... 184 } 186 4. IANA considerations 188 This document has no actions for IANA. 190 5. Security considerations 192 TBD. If the proposed work goes forward there are many difficult 193 security issues that need to be addressed, the exact security issues 194 depends on the actual proposal. 196 6. Acknowledgements 198 7. Informative References 200 [ALT] Kumari, W. and A. Sullivan, "The ALT Special Use Top Level 201 Domain", draft-wkumari-dnsop-alt-tld (work in progress), 202 February 2014. 204 [GNU] Grothoff, C., Wachs, M., Wolf, H., and J. Applebaum, 205 "Special-Use Domain Names of Peer-to-Peer Systems", draft- 206 iesg-special-use-p2p-names (work in progress), December 207 2013. 209 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 210 STD 13, RFC 1034, November 1987. 212 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 213 Rose, "Resource Records for the DNS Security Extensions", 214 RFC 4034, March 2005. 216 [RFC4627] Crockford, D., "The application/json Media Type for 217 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 219 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 220 6303, July 2011. 222 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 223 RFC 6761, February 2013. 225 [ReserveTLD] 226 Chapin, L. and M. McFadden, "Additional Reserved Top Level 227 Domains", draft-chapin-additional-reserved-tlds (work in 228 progress), January 2014. 230 Appendix A. Document history 232 [RFC Editor: Please remove this section before publication ] 234 00 Initial version 236 Author's Address 237 Olafur Gudmundsson 238 Shinkuro Inc. 239 4922 Fairmont Av, Suite 250 240 Bethesda, MD 20814 241 USA 243 Email: ogud@ogud.com