idnits 2.17.1 draft-faltstrom-e164-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 363 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([2], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 79: '...ies the order in which records MUST be...' RFC 2119 keyword, line 83: '...s the order in which records SHOULD be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 118 has weird spacing: '...d pr fl servi...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '3' is defined on line 269, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2168 (ref. '5') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 2052 (ref. '6') (Obsoleted by RFC 2782) ** Obsolete normative reference: RFC 2065 (ref. '7') (Obsoleted by RFC 2535) Summary: 16 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Patrik Faltstrom 2 Internet Draft Tele2/Swipnet 3 draft-faltstrom-e164-00.txt Bjorn Larsson 4 June 1998 Ericsson 5 Expires: December 1998 7 Where to terminate a phone call 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mate- 19 rial or to cite them other than as ``work in progress''. 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 Distribution of this document is unlimited. 30 1. Abstract 32 This document discusses the use of DNS [1] for identifying available 33 services that can be used to contact a phone number. It also, for some 34 of these services, discusses how to route the message(s) to a specific 35 destination using the same techniques. Specifically it presents a way of 36 implementing portable phone numbers, where the services used can be the 37 H.323 protocol [2], POTS [4] phone call or something else like SMTP. 39 2. Introduction 41 The NAPTR [5] and SRV [6] records in DNS can be used for looking up what 42 services are available for a specific domainname, and for each one of 43 these combinations of destinations and protocols, an ordered list of 44 destinations to use. This technology can be used for redirecting a 45 phonecall from one phone number to a second one, map a POTS phone number 46 to an endnode to use for H.323 services etc. The latter can be used when 47 gatewaying a POTS phonecall from the POTS systems to a service using the 48 H.323 protocol on top of the IP protocol stack. 50 2.1 Terminology 52 "Must" or "Shall" - Software that does not behave in the manner that 53 this document says it must is not conformant to this 54 document. 55 "Should" - Software that does not follow the behavior that this 56 document says it should may still be conformant, but is 57 probably broken in some fundamental way. 58 "May" - Implementations may or may not provide the described 59 behavior, while still remaining conformant to this 60 document. 62 3. Identifying available services 64 For a record in DNS, the NAPTR record is used for identifying 65 available ways of contacting a specific endnode. Specifically it 66 can be used for knowing what services exists for contacting 67 a specific domainname, including phone numbers by the use of the 68 e164.int domain. 70 The identification is using the NAPTR recorce record defined 71 for use in the URN resolution process [5], but it can be generalized 72 in a way that suits the needs specified in this document. 74 3.1 The NAPTR record 76 The key fields in the NAPTR RR are order, preference, service, flags, 77 regexp, and replacement. For a detailed description, see [5]: 79 * The order field specifies the order in which records MUST be 80 processed when multiple NAPTR records are returned in response to a 81 single query. 83 * The preference field specifies the order in which records SHOULD be 84 processed when multiple NAPTR records have the same value of 85 "order". 87 * The service field specifies the resolution protocol and resolution 88 service(s) that will be available if the rewrite specified by the 89 regexp or replacement fields is applied. 91 * The flags field contains modifiers that affect what happens in the 92 next DNS lookup, typically for optimizing the process. 94 * The regexp field is one of two fields used for the rewrite rules, 95 and is the core concept of the NAPTR record. 97 * The replacement field is the other field that may be used for the 98 rewrite rule. 100 Note that the client applies all the substitutions and performs all 101 lookups, they are not performed in the DNS servers. Note also that it 102 is the belief that regexps should rarely be used. The replacement 103 field seems adequate for the vast majority of situations. 105 3.1.2 Specific use of some fields in the NAPTR record 107 The flags must be "s" for the next step in the resolution process 108 described in this document. "s" flag means that the next lookup should 109 be for SRV records. Other flags are the "a" and the "p" flags. 111 The service supported for a call must be N2R, i.e. the POTS terminal, 112 computer terminating the H.323 call etc is to be seen as the resource 113 in an NAPTR view. 115 3.1.3 Example of use 117 tele2.se. 118 ;; ord pr fl service re replacement 119 IN NAPTR 100 10 "s" "h323call+N2R" "" tele2.se. 120 IN NAPTR 102 10 "s" "potscall+N2R" "" tele2.se. 121 IN NAPTR 104 10 "s" "smtp+N2R" "" tele2.se. 123 This describes that the domain tele2.se is preferrable contacted via the 124 H.323 protocol with the registered protocol name h323call. Secondly 125 POTS, and thirdly SMTP (for voicemail over SMTP). 127 In all three cases above, the next step in the resolution process is to 128 look up an SRV record to know what node to contact for each protocol. 130 Note that the terminating address for POTS is the same domainname as the 131 H.323 protocol even though the hostname can not be used as an endnode 132 address in those protocols. The mapping back to a phone number is done 133 in the SRV record later. 135 Also note that it is possible to use this method for describing 136 other access methods aswell, i.e. the preferred method for contacting a 137 domain might be via Email, secondly via POTS. 139 3.1.4 When the virtual address is a phone number 141 When the target address is a phone number, it is first translated into a 142 RR name in the e164.int domain. It is done by reversing the order of the 143 digits in the phone number and placing dots inbetween, to make 144 delegation of series of numbers possible in the DNS. 146 Example: 147 0.0.0.4.6.2.6.5.8.6.4.e164.int. 148 IN NAPTR 100 10 "s" "h323call+N2R" "" tele2.se. 149 IN NAPTR 102 10 "s" "potscall+N2R" "" tele2.se. 150 IN NAPTR 102 10 "s" "smtp+N2R" "" tele2.se. 152 The rest of the resolution of the routing is done as described above in 153 point 3.1.3. 155 3.2 The potscall protocol name 157 The potscall protocol name is just a placeholder so one knows that 158 the protocol to use is POTS. Because the protocol is not run on 159 top of IP, the address to use when addressing the endnode has to be 160 a phone number. See 4.x how that is done in detail. 162 4 What node to contact 164 The SRV record is used for identifying what host to contact for a 165 given service. Clients ask for a specific service/protocol for a 166 specific domain (the word domain is used here in the strict RFC 1034 167 sense), and get back the names of any available servers. 169 This is applied for each record one is interested in among the ones 170 returned when looking up the NAPTR record. 172 The format of the SRV record is described in detail in [6], but briefly 173 the format is as follows: 175 Service.Proto.Name TTL Class SRV Priority Weight Port Target 177 Service 178 The symbolic name of the desired service, as defined in Assigned 179 Numbers or locally. 181 Proto 182 TCP and UDP are at present the most useful values 183 for this field, though any name defined by Assigned Numbers or 184 locally may be used (as for Service). 186 Name 187 The domain this RR refers to. 189 TTL 190 Standard DNS meaning. 192 Class 193 Standard DNS meaning. 195 Priority 196 As for MX, the priority of this target host. 198 Weight 199 Load balancing mechanism. 201 Port 202 The port on this target host of this service. 204 Target 205 As for MX, the domain name of the target host. 207 4.1 Example 209 h323call.tcp.tele2.se. IN SRV 1 1 1720 h323gw.tele2.se. 210 h323call.udp.tele2.se. IN SRV 1 1 1720 h323gw.tele2.se. 211 potscall.tcp.tele2.se. IN SRV 1 1 0 0.0.0.4.6.2.6.5.8.6.4.e164.int. 212 smtp.tcp.tele2.se. IN SRV 1 1 25 mailgw1.swip.net. 214 This shows that if the H.323 protocol is used, the host with name 215 h323gw.tele2.se should be contacted on port 1720. If POTS is to be used, 216 the host 0.0.0.4.6.2.6.5.8.6.4.e164.int. is to be contacted. This in 217 turn means that the address to use as a B-address is +46-8-56264000. For 218 SMTP, the host mailgw1.swip.net is to be contacted. 220 4.2 Specific rules for POTS and SRV records 222 The portnumber have no meaning, and neither has the protocol name. 223 The protocol name must be TCP, and the port number must be 0. 225 The value of the port number must be ignored by the client. 227 5. Security considerations 229 As this system is built on top of DNS, one can not be sure that the 230 information one get back from DNS is more secure than any DNS 231 query. To solve that, the use of DNSSEC [7] for securing and verifying 232 zones is to be recommended. 234 The caching in DNS can also make the propagation time for a change 235 take the same amount of time as the time to live for the NAPTR and 236 SRV records in the zone that is changed. The TTL should because of 237 that be kept to a minimum. The use of this in an environment where 238 IP-addresses are for hire (i.e. DHCP) must therefore be done only 239 very carefully. 241 6. Authors information 243 Patrik Faltstrom 244 Tele2/Swipnet 245 Borgarfjordsgatan 16 246 P.O.BOX 62 247 162 94 KISTA 248 Sweden 250 Email: paf@swip.net 252 Bjorn Larsson 253 Ericsson 255 Email: etxbmhh@hf.ericsson.se 257 7. References 259 [1] RFC 1035: Mockapetris, P., "Domain names - implementation and 260 specification", STD 13, RFC 1035, November 1987. 262 RFC 1034: Mockapetris, P., "Domain names - concepts and 263 facilities", STD 13, RFC 1034, November 1987. 265 [2] ITU-T Recommendation H.323 (1996), "Visual Telephone Systems and 266 Equipment for Local Area Networks which provide a Non-Guaranteed 267 Quality of Service". 269 [3] ISDN, ITU-T recommendation I.241.1 271 [4] POTS, ITU-T recommendation E.105 273 [5] RFC 2168: Daniel, R., Mealling, M., "Resolution of Uniform 274 Resource Identifiers using the Domain Name System", June 1997. 276 [6] RFC 2052: Gulbrandsen, A., Vixie, P., "A DNS RR for specifying 277 the location of services (DNS SRV)", October 1996. 279 [7] RFC 2065: Eastlake, D., Kaufman, C., "Domain Name System 280 Security Extensions", January 1997 282 Appendix A -- Examples 284 A.1 Example number 1 286 Caller (A) uses a phone, connected to the PSTN network, on number 287 +46-8-7525252. 289 Callee (B) have a two phones, one cellular phone on number +46-70-411111, 290 and one ordinary phone connected to the PSTN network on number 291 +46-8-7111111. 293 Callee want to get reached on the unified message number +46-76-11223344. 295 On the buissness card, the callee have printed the number +46-76-11223344. 296 He buys a telephone number routing service from the company Number Inc. 298 Caller reads the buissness card, lifts the handle, and punches the number 299 +46-76-11223344. 301 The phone switch looks up the NAPTR record in DNS for 302 4.4.3.3.2.2.1.1.6.7.6.4.e164.int. The DNS server for Number Inc. has the 303 following information in its DNS: 305 4.4.3.3.2.2.1.1.6.7.6.4.e164.int. IN SOA .... 306 IN NS .... 307 IN NAPTR 100 10 "s" "potscall+N2R" "" a.number.com. 309 This shows to the switch that the only way B can be contacted is via the 310 PSTN network. As A is also connected to the PSTN network, no gateway have 311 to be used. 313 In the next step, the switch is figuring out what number on the PSTN 314 network to use. This information is fetched by looking up the SRV record 315 for the record potscall.tcp.a.number.com. This information is held in 316 the DNS which Number Inc. runs as follows: 318 potscall.tcp.a.number.com. IN NS SOA .... 319 IN NS ... 320 IN SRV 2 1 0 1.1.1.1.1.4.0.7.6.4.e164.int. 321 IN SRV 1 1 0 1.1.1.1.1.1.7.8.6.4.e164.int. 323 We here see that the B want to be reached if possible on the number 324 +46-70-411111, and secondly on the number +46-8-7111111. The switch is 325 routing the phonecall to the desired number over the PSTN network. 327 A.2 Example number 2 329 Caller (A) uses a computer, connected to the Internet. The computer do 330 have support for the H.323 protocol. 332 He want to contact the company ACME Inc, which have the domainname acme.com 333 (which is known to A). 335 The computer looks up the NAPTR record for acme.com, which holds the 336 following information: 338 acme.com. IN SOA .... 339 IN NS .... 340 IN NAPTR 100 10 "s" "potscall+N2R" "" acme.com. 341 IN NAPTR 100 10 "s" "h323call+N2R" "" acme.com. 343 What we see here is that acme.com can be contacted both via PSTN and via 344 H.323. A can make the choice of either using some gateway to PSTN that he 345 has access to, or to run the call using H.323 all the way to the access 346 point that Acme Inc assigns. 348 In this example, the user tries to use the H.323 protocol, which means 349 that A selects to use the NAPTR record "h323call+N2R". 351 In the next step, the SRV record "h323.tcp.acme.com" which is as follows: 353 h323.tcp.acme.com. IN SOA .... 354 IN NS .... 355 IN SRV 1 1 1720 h323.acme.com. 356 IN SRV 2 1 1720 h323.telco.net. 358 As we can see, you should first try to use the H.323 access point at 359 Acme, and secondly at the H.323 access point at the Telco which Acme seem 360 to have a contract with.