idnits 2.17.1 draft-faltstrom-uri-13.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 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.) -- The document date (March 6, 2015) is 3337 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'X' is mentioned on line 466, but not defined == Unused Reference: 'RFC3833' is defined on line 432, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6195 (Obsoleted by RFC 6895) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Faltstrom 3 Internet-Draft Netnod 4 Intended status: Informational O. Kolkman 5 Expires: September 7, 2015 ISOC 6 March 6, 2015 8 The Uniform Resource Identifier (URI) DNS Resource Record 9 draft-faltstrom-uri-13 11 Abstract 13 This document describes the already registered DNS resource record 14 type called the Uniform Resource Identifier (URI) RR, for publishing 15 mappings from hostnames to URIs. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 7, 2015. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 53 3. DNS considerations . . . . . . . . . . . . . . . . . . . . . 3 54 4. The format of the URI RR . . . . . . . . . . . . . . . . . . 4 55 4.1. Ownername, class and type . . . . . . . . . . . . . . . . 4 56 4.2. Priority . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.3. Weight . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.4. Target . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.5. URI RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 60 5. Usages . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.1. Example: FTP server in the example.com domain . . . . . . 6 62 5.2. Relation to S-NAPTR . . . . . . . . . . . . . . . . . . . 6 63 5.3. Relation to U-NAPTR . . . . . . . . . . . . . . . . . . . 7 64 5.4. Relation to SRV . . . . . . . . . . . . . . . . . . . . . 7 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 6.1. Registration of the URI Resource Record Type . . . . . . 7 67 6.2. Registration of services . . . . . . . . . . . . . . . . 7 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 9.2. Non-normative references . . . . . . . . . . . . . . . . 9 73 Appendix A. The original RRTYPE Allocation Request . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 This document explains the use of the Domain Name System (DNS) for 79 the storage of URIs, and how to resolve hostnames to such URIs that 80 can be used by various applications using the URI Resource Record 81 Type. For resolution the application need to know both the hostname 82 and the protocol that the URI is to be used for. The protocol is 83 registered by IANA. 85 Historically, uses of the DNS to map a domain name to a URL have 86 relied on the NAPTR RRTYPEs and then on the DDDS [RFC3401] 87 application framework with the DNS as a database as specified in RFC 88 3404 [RFC3404]. This has a number of implications such as the fact 89 the RRSet returned will contain all URIs "connected" with the owner, 90 and not only the ones related to a specific service. 92 The URI resource record specified in this document enables the 93 querying party to do the equivalence of selecting which ones of the 94 NAPTR records one is interested in, and have only those returned. 95 This because data in the service field of the NAPTR record is 96 included in the owner part of the URI resource record type. It is 97 also the case that as the URI resource record type include the target 98 URI directly as part of the RDATA, it is very easy to extract the 99 correct target URI, instead of applying rewrite rules as in NAPTR. 101 Querying for URI resource records is not replacing querying for NAPTR 102 resource records (or use of S-NAPTR [RFC3958]). Instead, the URI 103 resource record type provides a complementary mechanism to use when 104 one already knows what service field is interesting. With it, one 105 can directly query for the specific subset of the otherwise possibly 106 large RRSet given back when querying for NAPTR resource records. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in BCP 14, RFC 2119 111 [RFC2119]. 113 2. Applicability Statement 115 In general, it is expected that URI records will be used by clients 116 for applications where the relevant protocol to be used is known, 117 but, for example, an extra abstraction is needed in order to separate 118 a domain name from a point of service (as addressed by the URI). One 119 example of such a situation is when an organisation has many domain 120 names, but only one official web page. 122 Applications MUST know the specific service to prepend the hostname 123 with. Using repetitive queries for URI records MUST NOT be a 124 replacement for querying for NAPTR records according to the NAPTR 125 (DDDS) or S-NAPTR algorithms. NAPTR records serve the purpose to 126 discover the various services and URIs for looking up access points 127 for a given service. Those are two very different kinds of needs. 129 3. DNS considerations 131 Using prefix labels, such as underscored service tags, for a specific 132 owner name may cause a counter-intuitive effect when the owner name 133 is a wildcard name. For example, _s2._s1.*.example.net. is not a 134 wildcard name and cannot be used to return a synthesized answer for a 135 query name of _s2._s1.a.example.net. See Section 4.5 of RFC4592 136 [RFC4592] for more details. Besides, underscored service tags used 137 for the URI RR (based on the Service Name and Transport Protocol Port 138 Number Registry) may have slightly different semantics than service 139 tags used for underscored prefix labels that are used in combination 140 with other (yet unspecified) RR types. This may cause subtle 141 management problems when delegation structure that has developed 142 within the context of URI RRs is also to be used for other RR types. 143 Since the service labels might be overloaded, applications should 144 carefully check that the application level protocol is indeed the 145 protocol they expect. 147 Subtle management issues may also arise when the delegations from 148 service to sub service label involves several parties and different 149 stake holders. 151 4. The format of the URI RR 153 This is the presentation format of the URI RR: 155 Ownername TTL Class URI Priority Weight Target 157 The URI RR does not cause any kind of Additional Section processing. 159 4.1. Ownername, class and type 161 The URI ownername is subject to special conventions. 163 Just like the SRV RR [RFC2782] the URI RR has service information 164 encoded in its ownername. In order to encode the service for a 165 specific owner name one uses service parameters. Valid service 166 parameters used are those registered by IANA in the Service Name and 167 Transport Protocol Port Number Registry [RFC6335], or as Enumservice 168 Registrations [RFC6117]. The Enumservice Registration parameters are 169 reversed (subtype(s) before type), prepended with an underscore (_) 170 and prepended to the owner name in separate labels. The underscore 171 is prepended to the service parameters to avoid collisions with DNS 172 labels that occur in nature, and the order is reversed to make it 173 possible to do delegations, if needed, to different zones (and 174 therefore providers of DNS). 176 For example, suppose we are looking for the URI for a service with 177 ENUM Service Parameter "A:B:C" for host example.com. Then we would 178 query for (QNAME,QTYPE)=("_C._B._A.example.com","URI") 180 As another example, suppose we are looking for the URI for a service 181 with Service Name "A" and Transport Protocol "B" for host 182 example.com. Then we would query for 183 (QNAME,QTYPE)=("_A._B.example.com","URI") 185 The type number for the URI record is 256. 187 The URI resource record is class independent. 189 The URI RR has no special TTL requirements. 191 4.2. Priority 193 The priority of the target URI in this RR. Its range is 0-65535. A 194 client MUST attempt to contact the URI with the lowest-numbered 195 priority it can reach; URIs with the same priority SHOULD be tried in 196 the order defined by the weight field. 198 4.3. Weight 200 A server selection mechanism. The weight field specifies a relative 201 weight for entries with the same priority. Larger weights SHOULD be 202 given a proportionately higher probability of being selected. The 203 range of this number is 0-65535. 205 4.4. Target 207 The URI of the target, enclosed in double-quote characters ('"'). 208 Resolution of the URI is according to the definitions for the Scheme 209 of the URI. 211 Since the URI will not be encoded as a (see 212 RFC1035 section 3.3 [RFC1035]) there is no 255 character size 213 limitation. 215 The Target MUST NOT be empty (""). 217 4.5. URI RDATA Wire Format 219 The RDATA for a URI RR consists of a 2 octet Priority field, a two 220 octet Weight field, and a variable length target field. 222 Priority and Weight are unsigned integers in network byte order. 224 The remaining data in the RDATA contains the Target field. The 225 Target field contains the URI as a sequence of octets (without the 226 enclosing double- quote characters used in the presentation format). 228 The Target field can also contain an IRI, but with the additional 229 requirements that it are in UTF-8 [RFC3629], and the requirement that 230 it be possible to convert to a URI according to section 3.1 of RFC 231 3987 [RFC3987] and back again to an IRI according to section 3.2. 232 Other character sets than UTF-8 are not allowed. The domain name 233 part of the IRI can be either an U-LABEL or A-LABEL as defined in RFC 234 5890 [RFC5890]. 236 The length of the target field MUST be greater than zero. 238 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 239 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Priority | Weight | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 / / 244 / Target / 245 / / 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 5. Usages 250 5.1. Example: FTP server in the example.com domain 252 An organisation has the domain names example.com and example.net, and 253 their FTP archive is at ftp://ftp1.example.com/public. Given the 254 Service Name "ftp" and Transport Protocol "tcp" (from the IANA 255 registry of Service Name and Transport Protocol Port Numbers), the 256 following URI Resource Records could be made available in the 257 respective zones (example.com and example.net): 259 $ORIGIN example.com. 260 _ftp._tcp IN URI 10 1 "ftp://ftp1.example.com/public" 262 $ORIGIN example.net. 263 _ftp._tcp IN URI 10 1 "ftp://ftp1.example.com/public" 265 5.2. Relation to S-NAPTR 267 The URI resource record type is not a replacement for the S-NAPTR. 268 It is instead an extension and the second step of the S-NAPTR 269 resolution can resolve a URI resource record instead of using SRV 270 records and yet another algorithm for how to use SRV records for the 271 specific protocol. 273 $ORIGIN example.com. 274 ;; order pref flags 275 IN NAPTR 100 10 "D" "EM:ProtA" ( ; service 276 "" ; regexp 277 _http._tcp.example.com. ; replacement 278 _http._tcp IN URI 10 1 "http://www.example.com/path" 280 5.3. Relation to U-NAPTR 282 The URI Resource Record Type, together with S-NAPTR, can be viewed as 283 a replacement for U-NAPTR [RFC4848]. The URI Resource Record Type is 284 though only interesting when one know a base domain name, a protocol 285 and service so that one can compose the record to look up. NAPTR 286 records of any kind are used to look up what services exists for a 287 certain domain, which is one step before the URI resource record is 288 used. 290 5.4. Relation to SRV 292 The URI Resource Record Type can be viewed as a replacement for the 293 SRV record. This because it like the SRV record can only be looked 294 up if one know the base domain, the protocol and the service. It has 295 a similar functionality, and uses the same registry for Service 296 Names, but instead of returning a hostname and port number, the URI 297 record return a full URI. As such, it can be viewed as a more 298 powerful resource record than SRV. 300 6. IANA Considerations 302 6.1. Registration of the URI Resource Record Type 304 After an expert review in February 2011 (see Appendix A) IANA has 305 allocated RRTYPE 256 for the URI Resource Record Type in the registry 306 named Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 (at 307 the time RFC 6195 [RFC6195]), located at 308 http://www.iana.org/assignments/dns-parameters. 310 IANA is requested to update the reference with that registration to 311 this RFC. 313 6.2. Registration of services 315 No new registry is needed for the registration of services as the 316 Service Name, Transport Protocol Port Numbers, Enumservices and the 317 DNS SRV Service Type registries are used also for the URI resource 318 record type. 320 7. Security Considerations 322 Using the URI resource record together with security mechanisms that 323 relies on verification of authentication of hostnames, like TLS, 324 makes it important to choose the correct domain name when doing the 325 comparison, and that the change in what hostname to use is secured by 326 DNSSEC so that it can be trusted in a similar way as a redirect in 327 HTTP using TLS. 329 If for example the URI resource record is not signed with the help of 330 DNSSEC, and then validated successfully, trusting the non-signed URI 331 will effectlyely lead to a downgrade attack. 333 The basic mechanism for successful use of URI works as follows: 335 1. Announce the fact example.com is hosted at example.org (with 336 some URL) in DNS 338 2. Secure the URI resource record with DNSSEC. Best of course by 339 doing validation in the application doing the lookup, but it 340 could also be in the local recursive resolver or in the trusted 341 recursive resolver also doing validation. All according to the 342 local trust policy. 344 3. Verify the TLS (for example) certificate for the connection to 345 example.org matches, i.e. use the hostname in the URI and not 346 the hostname used originally when looking up the URI resource 347 record. 349 4. If needed, do application layer authentication etc over the then 350 encrypted connection. 352 What also can happen is that the URI in the resource record type has 353 errors in it. Applications using the URI resource record type for 354 resolution should behave similarly as if the user typed (or copy and 355 pasted) the URI. At least it must be clear to the user that the 356 error is not due to any error from his side. 358 One SHOULD NOT include userinfo (see User Information, Section 3.2.1, 359 in RFC 3986 [RFC3986]) in a URI that is used in a URI resource record 360 as DNS data must be viewed as publicly available information. 362 8. Acknowledgements 364 Ideas on how to split the two different kind of queries "What 365 services exists for this domain name" and "What is the URI for this 366 service" came from Scott Bradner and Lawrence Conroy. Other people 367 that have contributed to this document include Richard Barnes, Leslie 368 Daigle, Victor Dukhovni, Olafur Gudmundsson, Philip Hallam-Baker, Ted 369 Hardie, Sam Hartman, Evan Hunt, John klensin, Peter Koch, Eliot Lear, 370 Andy Newton, Mark Nottingham, Penn Pfautz, Jinmei Tatuya, Willem 371 Toorop, Nico Williams. 373 Cisco is acknowledged as mr Faltstrom's employer at the time this 374 document was developed. 376 The NLnet Labs is acknowledged as mr Kolkman's employer at the time 377 this document was developed. 379 9. References 381 9.1. Normative References 383 [RFC1035] Mockapetris, P., "Domain names - implementation and 384 specification", STD 13, RFC 1035, November 1987. 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, March 1997. 389 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 390 10646", STD 63, RFC 3629, November 2003. 392 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 393 Identifiers (IRIs)", RFC 3987, January 2005. 395 [RFC5890] Klensin, J., "Internationalized Domain Names for 396 Applications (IDNA): Definitions and Document Framework", 397 RFC 5890, August 2010. 399 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 400 Registration of Enumservices: Guide, Template, and IANA 401 Considerations", RFC 6117, March 2011. 403 [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA 404 Considerations", RFC 6195, March 2011. 406 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 407 Cheshire, "Internet Assigned Numbers Authority (IANA) 408 Procedures for the Management of the Service Name and 409 Transport Protocol Port Number Registry", BCP 165, RFC 410 6335, August 2011. 412 9.2. Non-normative references 414 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 415 specifying the location of services (DNS SRV)", RFC 2782, 416 February 2000. 418 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 419 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 421 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 422 Part Three: The Domain Name System (DNS) Database", RFC 423 3403, October 2002. 425 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 426 Part Four: The Uniform Resource Identifiers (URI)", RFC 427 3404, October 2002. 429 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 430 (RR) Types", RFC 3597, September 2003. 432 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 433 Name System (DNS)", RFC 3833, August 2004. 435 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 436 Service Location Using SRV RRs and the Dynamic Delegation 437 Discovery Service (DDDS)", RFC 3958, January 2005. 439 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 440 Resource Identifier (URI): Generic Syntax", STD 66, RFC 441 3986, January 2005. 443 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 444 System", RFC 4592, July 2006. 446 [RFC4848] Daigle, L., "Domain-Based Application Service Location 447 Using URIs and the Dynamic Delegation Discovery Service 448 (DDDS)", RFC 4848, April 2007. 450 [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design 451 Choices When Expanding the DNS", RFC 5507, April 2009. 453 Appendix A. The original RRTYPE Allocation Request 455 On February 22, 2011 IANA assigned RRTYPE 256 for the URI resource 456 record based on a request that followed the procedure documented in 457 RFC 6195 [RFC6195]. The DNS RRTYPE PARAMETER ALLOCATION form as 458 submitted to IANA at thet time is replicated below for reference. 460 A. Submission Date: 462 May 23, 2009 464 B. Submission Type: 466 [X] New RRTYPE 467 [ ] Modification to existing RRTYPE 469 C. Contact Information for submitter: 471 Name: Patrik Faltstrom 472 Email Address: paf@cisco.com 473 International telephone number: +46-8-6859131 474 Other contact handles: 475 (Note: This information will be publicly posted.) 477 D. Motivation for the new RRTYPE application? 479 There is no easy way to get from a domain name to a URI (or 480 IRI). Some mechanisms exists via use of the NAPTR [RFC3403] 481 resource record. That implies quite complicated rules that are 482 simplified via the S-NAPTR [RFC3958] specification. But, the 483 ability to directly look up a URI still exists. This 484 specification uses a prefix based naming mechanism originated in 485 the definition of the SRV [RFC2782] resource record, and the 486 RDATA is a URI, encoded as one text field. 488 See also above (Section 1). 490 E. Description of the proposed RR type. 492 The format of the URI resource record is as follows: 494 Ownername TTL Class URI Priority Weight Target 496 The URI RR has service information encoded in its ownername. In 497 order to encode the service for a specific owner name one uses 498 service parameters. Valid service parameters used are either 499 Enumservice Registrations registered by IANA, or prefixes used 500 for the SRV resource record. 502 The wire format of the RDATA is as follows: 504 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 505 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Priority | Weight | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 / / 510 / Target / 511 / / 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 F. What existing RRTYPE or RRTYPEs come closest to filling that 515 need and why are they unsatisfactory? 517 The RRTYPE that come closest is the NAPTR resource record. It 518 is for example used in the DDDS and S-NAPTR algorithms. The 519 main problem with the NAPTR is that selection of what record (or 520 records) one is interested in is based on data stored in the 521 RDATA portion of the NAPTR resource record. This, as explained 522 in RFC 5507 [RFC5507], is not optimal for DNS lookups. Further, 523 most applications using NAPTR resource records uses regular 524 expression based rewrite rules for creation of the URI, and that 525 has shown be complicated to implement. 527 The second closest RRTYPE is the SRV record that given a 528 prefixed based naming just like is suggested for the URI 529 resource record, one get back a port number and domain name. 530 This can also be used for creation of a URI, but, only URIs 531 without path components. 533 G. What mnemonic is requested for the new RRTYPE (optional)? 535 URI 537 H. Does the requested RRTYPE make use of any existing IANA Registry 538 or require the creation of a new IANA sub-registry in DNS 539 Parameters? 541 Yes, partially. 543 One of the mechanisms to select a service is to use the 544 Enumservice Registry managed by IANA. Another is to use 545 services and protocols used for SRV records. 547 I. Does the proposal require/expect any changes in DNS servers/ 548 resolvers that prevent the new type from being processed as an 549 unknown RRTYPE (see RFC 3597 [RFC3597])? 551 No 553 J. Comments: 555 None 557 Authors' Addresses 559 Patrik Faltstrom 560 Netnod 562 Email: paf@netnod.se 564 Olaf Kolkman 565 Internet Society 567 Email: kolkman@isoc.org