idnits 2.17.1 draft-barton-clone-dns-labels-fun-profit-02.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 14, 2011) is 4598 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) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2672 (Obsoleted by RFC 6672) == Outdated reference: A later version (-01) exists of draft-ietf-dnsext-aliasing-requirements-00 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsext D. Barton, Ed. 3 Internet-Draft GridFury, LLC 4 Intended status: Standards Track September 14, 2011 5 Expires: March 17, 2012 7 Cloning Domain Name System (DNS) Labels for Fun and Profit 8 draft-barton-clone-dns-labels-fun-profit-02.txt 10 Abstract 12 This document describes a method for making one or more Domain Name 13 System (DNS) labels behave in the DNS "as if" they were actually an 14 entirely different label. E.g., the delegee for the example.org zone 15 could define bar.example.org to be a CLONE of foo.example.org. This 16 method is designed to meet the needs of those managing 17 Internationalized Domain Name (IDN) zones that have been determined 18 to be semantically similar, and therefore should be treated "as if" 19 they were identical. This method can also be used more generally to 20 handle situations where either CNAME or DNAME Resource Records are 21 currently being used. 23 A key design goal for the CLONE method is that all of the semantic 24 benefits are available by updating only the authoritative servers for 25 the zone. Domain managers who want to support DNSSEC for the CLONEd 26 labels/zones may do so with dynamic signing of the CLONEs, or rely on 27 users being behind a CLONE-Aware resolving name server. 29 Foreword 31 [RFC Editor, please remove this Section at publication time. 32 Thanks.] 34 This is my first draft, please be gentle. :) I'm definitely open to 35 the possibility that there are better ways to accomplish the concepts 36 presented herein. I'm sure that there are a non-zero number of 37 errors in the formatting, references, etc. Also Sections 2 and 3 may 38 be under-specified, unclear, or unworkable. So please don't be 39 afraid to offer (constructive) criticism. 41 TODO: 43 Update/add/improve references? 45 Add/improve examples? 47 Revision History: 49 1. -00 Initial version 51 2. -01 Minor textual edits, add support for dynamic signing, clarify 52 CLONE labels that are not zone cuts 54 3. -02 Bump date to avoid expiry 56 Requirements Language 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in [RFC2119]. 62 Status of this Memo 64 This Internet-Draft is submitted in full conformance with the 65 provisions of BCP 78 and BCP 79. 67 Internet-Drafts are working documents of the Internet Engineering 68 Task Force (IETF). Note that other groups may also distribute 69 working documents as Internet-Drafts. The list of current Internet- 70 Drafts is at http://datatracker.ietf.org/drafts/current/. 72 Internet-Drafts are draft documents valid for a maximum of six months 73 and may be updated, replaced, or obsoleted by other documents at any 74 time. It is inappropriate to use Internet-Drafts as reference 75 material or to cite them other than as "work in progress." 77 This Internet-Draft will expire on March 17, 2012. 79 Copyright Notice 81 Copyright (c) 2011 IETF Trust and the persons identified as the 82 document authors. All rights reserved. 84 This document is subject to BCP 78 and the IETF Trust's Legal 85 Provisions Relating to IETF Documents 86 (http://trustee.ietf.org/license-info) in effect on the date of 87 publication of this document. Please review these documents 88 carefully, as they describe your rights and restrictions with respect 89 to this document. Code Components extracted from this document must 90 include Simplified BSD License text as described in Section 4.e of 91 the Trust Legal Provisions and are provided without warranty as 92 described in the Simplified BSD License. 94 Table of Contents 96 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 97 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 98 1.2. CLONE Overview . . . . . . . . . . . . . . . . . . . . . . 5 99 1.2.1. Common And Non-DNSSEC Cases . . . . . . . . . . . . . 5 100 1.2.2. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 5 101 2. The Authoritative Name Server . . . . . . . . . . . . . . . . 5 102 2.1. Parent Zone File . . . . . . . . . . . . . . . . . . . . . 6 103 2.1.1. CLONE . . . . . . . . . . . . . . . . . . . . . . . . 6 104 2.1.2. CLONES . . . . . . . . . . . . . . . . . . . . . . . . 6 105 2.2. Child Authoritative Server Configuration . . . . . . . . . 7 106 2.3. Query Response For Labels That Are CLONEs . . . . . . . . 7 107 2.3.1. DNSSEC For The Parent Of A Zone Cut . . . . . . . . . 7 108 2.3.2. DNSSEC For The Dynamic-Signing Child . . . . . . . . . 7 109 2.3.3. DNSSEC For Other Authoritative Servers . . . . . . . . 8 110 2.4. Query Response For CLONE And CLONES Resource Records . . . 8 111 3. The CLONE-Aware Resolving Name Server . . . . . . . . . . . . 8 112 3.1. CARNS DNSSEC Behavior For "Typical" Queries . . . . . . . 9 113 3.2. CARNS Behavior for DNSSEC Resource Record Queries . . . . 9 114 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 115 4.1. Non-CARNS . . . . . . . . . . . . . . . . . . . . . . . . 9 116 4.2. CARNS - First Query For CLONE . . . . . . . . . . . . . . 10 117 4.3. CARNS - Second Query For CLONE . . . . . . . . . . . . . . 10 118 4.4. CLONES Response . . . . . . . . . . . . . . . . . . . . . 10 119 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 120 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 121 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 122 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 123 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 124 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 125 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 127 1. Introduction 129 The DNS was initially designed and implemented during a period when 130 the American Standard Code for Information Interchange [ASCII] text 131 was the lingua franca, and certain assumptions about the 132 characteristic behavior of ASCII text, and how it is commonly 133 understood in written form, were baked into the protocol. For 134 example, while the following may not be stylistically appealing on 135 the printed page; not only would all of the following be handled the 136 same by the DNS, there would not be any confusion that all of the 137 following representations refer to the same hostname: 139 o example.org 141 o Example.Org 143 o eXaMpLe.oRg 145 o EXAMPLE.ORG 147 Because of the way that Internationalized Domain Names (IDNs) 148 [RFC5890] work it is not possible for the DNS to provide the same 149 level(s) or type(s) of equivalence for different Unicode Code Points 150 that upper and lower case ASCII letters enjoy. Furthermore, there 151 are unique issues with Unicode representations of DNS labels that 152 have no equivalents in ASCII text. More information about the 153 problems that this document attempts to provide a solution for can be 154 found in DNS Resolution of Aliased Names 155 [I-D.ietf-dnsext-aliasing-requirements]. 157 In addition to solving the DNS part of the problem of IDN 158 equivalence, being able to use a more complete solution to the 159 problem of "aliasing" DNS labels than CNAMEs [RFC1035] and DNAMEs 160 [RFC2672] currently provide also has appeal. 162 1.1. Terminology 164 There is some feeling in the IDN community that a DNS solution for 165 IDN equivalence must treat (and consider) all versions of a label as 166 truly equal. However this document describes a procedure that relies 167 on one version of a label being configured in the familiar way, and 168 the CLONE(s) configured in a way that refers to the traditionally 169 configured label. Therefore this document will adopt the term used 170 in the Joint Engineering Team (JET) Guidelines [RFC3743] and refer to 171 the label configured in the typical way as the "preferred" label. 172 While on the one hand it is easy to see how a solution that treats 173 all versions of the label as truly equal would be desirable, this 174 document intentionally sacrifices the goal of true equality in the 175 interest of providing a solution that can get the maximum possible 176 benefit available to the largest number of end users while requiring 177 only that the authoritative name servers are upgraded. It will 178 ultimately be up to the community to decide whether this is a 179 sacrifice worth making. 181 The terms "authoritative name server" and "resolving name server" are 182 used with their commonly understood meanings. A CLONE-Aware 183 Resolving Name Server will hereinafter be referred to as a CARNS. 185 1.2. CLONE Overview 187 1.2.1. Common And Non-DNSSEC Cases 189 There are two sides of the CLONE method, the authoritative and 190 resolving name servers. For clients that are not aware of the CLONE 191 RR the authoritative server will simply respond "as if" the query for 192 a CLONE label had actually been for the preferred name. When a CARNS 193 queries the authoritative server it will send an EDNS [RFC2671] 194 option that indicates that it is CLONE-Aware. The authoritative 195 server will then add the CLONE Resource Record (RR) to the ANSWER 196 section, which will include the preferred label. From then on when 197 queries come into the CARNS for the CLONE it can in turn query the 198 authoritative server for the preferred label, and respond to its 199 querier "as if" the query had been for the preferred label. 201 This method also makes it possible to have CLONEs for more than one 202 label at a given level in the DNS. 204 The CLONES RR is intended to aid application developers by making it 205 easier to know when a given label has one or more other labels that 206 are configured as part of the same "bundle." 208 1.2.2. DNSSEC 210 An authoritative server may utilize what is commonly known as 211 "dynamic signing" to handle DNSSEC [RFC4035] signatures for the CLONE 212 labels. Those zone managers who do not wish to (or cannot) utilize 213 the dynamic signing method can rely on the end user being behind a 214 CARNS, which when querying for a CLONE label can perform DNSSEC 215 validation on the preferred version. 217 2. The Authoritative Name Server 218 2.1. Parent Zone File 220 2.1.1. CLONE 222 At any level of the DNS tree above the root itself ('.') a label MAY 223 be specified as a CLONE. For example: 225 clone1 CLONE preferred 227 In this example "preferred" would be the preferred label, "clone1" 228 would be the CLONE. Multiple CLONES MAY be defined for the same 229 preferred label. The RDATA for the CLONE RR MUST be either a valid 230 DNS label, or a valid hostname that is also served by the same 231 authoritative name server. Compliant authoritative server 232 implementations MUST generate a user error when attempting to load a 233 zone that contains a CLONE RR with RDATA that is not served by that 234 authoritative name server. 236 Other than the DS RR for CLONEs whose preferred label is a zone cut, 237 the CLONE label MUST NOT have any other data associated with it. An 238 authoritative name server above the zone cut (the "parent") MAY allow 239 configuration of a DS record for a label that is a CLONE of the 240 preferred label that is itself the point of the zone cut. For 241 example: 243 preferred NS ns1.preferred 245 preferred DS 123456789ABCDEF 247 clone1 CLONE preferred 249 clone1 DS FEDCBA987654321 251 Compliant authoritative server implementations MUST generate a user 252 error when attempting to load a zone that contains both a CLONE and 253 any other RR (other than DS for a CLONE zone cut) for the same label. 255 2.1.2. CLONES 257 The CLONES RR is used to list the preferred label and all of its 258 CLONEs. If the zone does not contain a CLONES RR for the preferred 259 label a compliant authoritative server MUST synthesize one at the 260 time that the zone is loaded. If the CLONES RR is already present in 261 the zone (perhaps because the zone has been signed) the server MUST 262 verify that it is correct. Compliant implementations MUST generate a 263 user error when attempting to load a zone that contains an incorrect 264 CLONES RR. 266 2.2. Child Authoritative Server Configuration 268 If the preferred label is a delegation point, and the delegee wishes 269 to answer for the CLONE label(s), the authoritative name server for 270 the child zone with the preferred label MUST be configured for the 271 CLONE(s). An example that uses a BIND-style syntax follows, but this 272 document is not attempting to specify how implementors perform this 273 configuration. 275 zone "clone1.example.org" { clone preferred.example.org; [ dnskey 276 ; ] }; 278 Behavior of child authoritative servers which configure real zones 279 for labels that the parent created as CLONEs of a preferred label is 280 undefined. 282 2.3. Query Response For Labels That Are CLONEs 284 When a compliant authoritative name server implementation receives a 285 query for a label or zone that is a CLONE, the server MUST respond 286 "as if" it had received the query for the preferred label. In the 287 example above if the name server receives any query for 288 clone1.example.org other than the CLONE or CLONES RRs, or as 289 described below the DS or DNSKEY RRs, it MUST respond "as if" the 290 query had been for preferred.example.org. 292 If the authoritative name server receives the CLONE-Aware EDNS option 293 it MUST add the CLONE RR to the ANSWER section of the query response 294 with the preferred label as the RDATA. This is similar to the 295 behavior when the QNAME is a CNAME and the same server is 296 authoritative for the canonical label. If the DO bit is set in the 297 query the server MUST include the RRSIG(s) for the CLONE RR itself. 299 2.3.1. DNSSEC For The Parent Of A Zone Cut 301 When the authoritative server which is the parent at a zone cut 302 answers a query for a CLONE label when the querier sets the DO bit, 303 and the CLONE label has a DS RR, a compliant server MUST return all 304 records "as if" the QNAME had been the preferred label, except for 305 the DS record; and the server MUST return the DS record of the CLONE 306 with the appropriate RRSIGs. This behavior is independent of the 307 presence of the CLONE-Aware EDNS option. 309 2.3.2. DNSSEC For The Dynamic-Signing Child 311 For the authoritative server which is the child below a zone cut for 312 the preferred label, when all of the following are true: 314 o The server is configured to do dynamic DNSSEC signatures 316 o The query has the DO bit set 318 o The CLONE has a DNSKEY configured 320 the compliant implementation MUST return the answer for the CLONE 321 zone "as if" the query had been for the preferred label, except that 322 it MUST return the DNSKEY for the CLONE zone instead of the DNSKEY 323 for the preferred label, and it MUST generate dynamic RRSIGs for all 324 answers, signed with the CLONE's DNSKEY. This behavior is 325 independent of the presence of the CLONE-Aware EDNS option. 327 2.3.3. DNSSEC For Other Authoritative Servers 329 If the conditions in 2.3.1 or 2.3.2 are not met an authoritative 330 server which receives a query which does not include the CLONE-Aware 331 EDNS option MUST NOT return DNSSEC-related records along with the 332 response, regardless of whether the DO bit was set in the query. If 333 the server receives both the DO bit and the CLONE-Aware EDNS option 334 it MUST return the DNSSEC records for the answer "as if" the QNAME 335 were the preferred label. 337 The behavior described in this Section is relevant whether or not the 338 preferred label is a zone cut. 340 2.4. Query Response For CLONE And CLONES Resource Records 342 When a compliant authoritative name server receives a query for the 343 CLONE RR with a label that is a CLONE as the QNAME it MUST return an 344 ANSWER with the preferred label as the RDATA. When a compliant 345 server receives a CLONE query for a label that is not a CLONE it MUST 346 return RCODE 0 (No error). 348 When a compliant server receives a query for the CLONES RR with a 349 label that is a CLONE or a preferred label as the QNAME it MUST 350 return an ANSWER with the preferred label listed first in the RDATA, 351 followed by all of the labels that are configured as a CLONE of the 352 preferred label. If the label in the QNAME is neither a preferred 353 label nor a CLONE the server MUST return RCODE 0 (No error). 355 3. The CLONE-Aware Resolving Name Server 357 When sending queries a compliant CARNS MUST send the EDNS option for 358 CLONE-Aware. When a compliant CARNS receives a query response which 359 contains a CLONE RR as described in Section 2.3 it MUST "transform" 360 future queries for hostnames or labels which it knows contain CLONE 361 labels to the preferred version(s). However regardless of whether 362 the CARNS knows that a hostname it is queried for contains a CLONE 363 label or not, the response to its client MUST be for the same QNAME 364 it was queried for. 366 3.1. CARNS DNSSEC Behavior For "Typical" Queries 368 When a CARNS receives a response to a query that originally contained 369 one or more CLONE labels that is signed with DNSSEC it MAY indicate 370 that the response is authentic by setting the AD bit if all other 371 conditions for setting it are otherwise met (i.e., the DO bit was set 372 in the query originally received by the CARNS, etc.). Local policy 373 SHALL be the determining factor for whether to set the AD bit in the 374 query response for the hostname which contains one or more CLONE 375 labels if it were otherwise appropriate to do so. 377 3.2. CARNS Behavior for DNSSEC Resource Record Queries 379 When a CARNS receives a direct query for a DNSSEC-related RR for a 380 hostname that contains one or more CLONE labels (e.g., RRSIG, DNSKEY, 381 etc.), and those RRs are not configured as described in Sections 382 2.3.1 and 2.3.2, it MUST return RCODE 0 (No answer) and include the 383 CLONE RR with the preferred label as RDATA in the ADDITIONAL section 384 of the response 386 4. Examples 388 Assuming a zone example.org with the following records: 390 preferred A 192.0.2.1 392 clone1 CLONE preferred 394 clone2 CLONE preferred 396 4.1. Non-CARNS 398 +---+ +-----------+ +---+ 399 | S | clone1.example.org A | | clone1.example.org A | A | 400 | t |--------------------->| Non-CARNS |--------------------->| u | 401 | u | | | | t | 402 | b | 192.0.2.1 | | 192.0.2.1 | h | 403 | |<---------------------| |<---------------------| | 404 +---+ +-----------+ +---+ 406 4.2. CARNS - First Query For CLONE 408 +---+ +---+ +---+ 409 | | | | clone1.example.org A | | 410 | S | clone1.example.org A | C | CLONE-Aware ENDS Opt | A | 411 | t |--------------------->| A |---------------------------->| u | 412 | u | | R | | t | 413 | b | | N | 192.0.2.1 | h | 414 | | 192.0.2.1 | S | clone1 CLONE preferred | | 415 | |<---------------------| |<----------------------------| | 416 +---+ +---+ +---+ 418 4.3. CARNS - Second Query For CLONE 420 +---+ +---+ +---+ 421 | | | C | preferred.example.org A | | 422 | S | clone1.example.org A | A | CLONE-Aware ENDS Opt | A | 423 | t |--------------------->| R |---------------------------->| u | 424 | u | | N | | t | 425 | b | 192.0.2.1 | S | 192.0.2.1 | h | 426 | |<---------------------| |<----------------------------| | 427 +---+ +---+ +---+ 429 4.4. CLONES Response 431 +---+ +---+ 432 | C | | | 433 | A | clone1.example.org CLONES | A | 434 | R |------------------------------------------------------------>| u | 435 | N | | t | 436 | S | preferred.example.org clone1.example.org clone2.example.org | h | 437 | |<------------------------------------------------------------| | 438 +---+ +---+ 440 5. IANA Considerations 442 This document requests that the IANA assign the Resource Record (RR) 443 Type Codes [RFC1035], [I-D.ietf-dnsext-5395bis] 77 and 88 to the 444 CLONE and CLONES RRs, respectively; and the EDNS0 Option [RFC2671] 11 445 for CLONE-Aware. 447 6. Security Considerations 449 There are currently (at least) two widely used solutions to the 450 equivalence problem at the zone level. For both of these solutions 451 the preferred label and all of the variations need to be delegated, 452 usually to the same set of name servers. The obvious, albeit 453 potentially the most difficult method of keeping the zones "the same" 454 is to create multiple zone files that contain records that are 455 identical to the extent possible. This solution allows for the 456 possibility of having DNSKEY records for each zone, thereby allowing 457 each label's zone to be signed. 459 The other solution that takes advantage of identical delegation is to 460 use the exact same "generic" zone file for multiple zones. This 461 method provides for DNSSEC configuration in the typical way for the 462 preferred label, but does not allow different DNSKEY records for the 463 other labels in the same "bundle." The records in the preferred 464 version of the zone can be signed, but validation would fail for the 465 other labels since the DNSKEY record would not be for that zone. 466 This behavior is similar to the CLONE solution in the absence of both 467 dynamic signing at the authoritative level and a validating CARNS. 469 For parents (such as TLD registries) that allow the delegee/ 470 registrant to choose what method of "bundling" semantically similar 471 labels to use, the techniques described in this document do not 472 reduce security in any way. The delegee can either decide as a 473 matter of local policy that the DNSSEC capability of the CLONE 474 technique is sufficient, or they can choose to have the non-preferred 475 versions of the label delegated and maintain separate zone files. In 476 a context where the delegee is required to accept the CLONE option 477 DNSSEC validation for the non-preferred versions of the label can be 478 provided without relying on end users being behind a CARNS by 479 utilizing dynamic signing. 481 No negative security implications for the CLONE or CLONES RRs 482 themselves are known, other than the possibility that the CLONES RR 483 could be used as a Distributed Denial Of Service amplifier if it 484 contained a sufficiently large ANSWER section. It is envisioned that 485 in certain contexts being able to verify that the non-preferred 486 versions of a label have been listed as CLONEs rather than using some 487 other method of "aliasing" (such as delegation, CNAME, etc.) could be 488 beneficial. 490 7. Acknowledgements 492 I would like to thank all of the participants in the dnsext and dnsop 493 working groups who discussed and fleshed out the ideas this document 494 is responding to. Particularly Suzanne Woolf and Xiaodong LEE for 495 producing the Problem Statement 496 [I-D.ietf-dnsext-aliasing-requirements] that this document is trying 497 to provide a solution for; both for their diligent work on the topic, 498 and for making it much simpler for me to write my Introduction. I 499 would also like to thank Nicholas Weaver for pushing me hard to think 500 about how dynamic DNSSEC could fit into the CLONE idea. 502 8. References 504 8.1. Normative References 506 [I-D.ietf-dnsext-5395bis] 507 3rd, D., "Domain Name System (DNS) IANA Considerations", 508 draft-ietf-dnsext-5395bis-03 (work in progress), 509 January 2011. 511 [RFC1035] Mockapetris, P., "Domain names - implementation and 512 specification", STD 13, RFC 1035, November 1987. 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, March 1997. 517 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 518 RFC 2671, August 1999. 520 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 521 RFC 2672, August 1999. 523 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 524 Rose, "Protocol Modifications for the DNS Security 525 Extensions", RFC 4035, March 2005. 527 [RFC5890] Klensin, J., "Internationalized Domain Names for 528 Applications (IDNA): Definitions and Document Framework", 529 RFC 5890, August 2010. 531 8.2. Informative References 533 [ASCII] American National Standards Institute (formerly United 534 States of America Standards Institute), "USA Code for 535 Information Interchange", ANSI X3.4-1968, 1968. 537 [I-D.ietf-dnsext-aliasing-requirements] 538 Woolf, S. and X. Lee, "Problem Statement: DNS Resolution 539 of Aliased Names", 540 draft-ietf-dnsext-aliasing-requirements-00 (work in 541 progress), February 2011. 543 [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint 544 Engineering Team (JET) Guidelines for Internationalized 545 Domain Names (IDN) Registration and Administration for 546 Chinese, Japanese, and Korean", RFC 3743, April 2004. 548 Author's Address 550 Douglas Barton (editor) 551 GridFury, LLC 552 11901 Santa Monica Boulevard, Unit 612 553 Los Angeles, CA 90025 554 USA 556 Email: dougb@dougbarton.us