idnits 2.17.1 draft-osamu-v6ops-ipv4-literal-in-url-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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2014) is 3467 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '01' on line 587 == Missing Reference: '0-4' is mentioned on line 588, but not defined == Missing Reference: '0-5' is mentioned on line 588, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations Working Group (v6ops) O. Nakamura 3 Internet-Draft Keio Univ./WIDE Project 4 Intended status: Experimental H. Hazeyama 5 Expires: April 30, 2015 NAIST / WIDE Project 6 Y. Ueno 7 Keio Univ./WIDE Project 8 A. Kato 9 Keio Univ. / WIDE Project 10 October 27, 2014 12 A Special Purpose TLD to resolve IPv4 Address Literal on DNS64/NAT64 13 environments 14 draft-osamu-v6ops-ipv4-literal-in-url-02 16 Abstract 18 In an IPv6-only environment with DNS64/NAT64 based translation 19 service, there is no way to get access a URL whose domain name part 20 includes an IPv4 address literal. This memo proposes a special 21 purpose TLD so that the IPv4 address literal is accessible from such 22 a DNS64/NAT64 environments. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 30, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 1. Introduction and Overview 70 When a host in an IPv6 only environment (an IPv6-only host) has to 71 access an IPv4-only destination, a translator-based approach is a 72 powerful tool. The translator-based approach is usually composed of 73 a DNS64 server [RFC6147] and a stateful NAT64 translator [RFC6146]. 74 The DNS64 server responds with a AAAA record of an IPv4 embedded IPv6 75 address with a certain IPv6 prefix assigned to the NAT64 translator, 76 for example, the well known NAT64 prefix (64:ff9b::) or a global IPv6 77 prefix. The IPv6-only host sends an IPv6 packet, which is translated 78 by the NAT64 box to an IPv4 packet. In this memo, an IPv4 embedded 79 IPv6 address with a NAT64 prefix is described as ``Pref64::/n 80 address''. The translation of responded IPv4 packet back into an 81 IPv6 packet is also performed in the NAT64 translator. 83 The NAT64 with DNS64 approach works well for most destinations. But 84 it does not work well when the DNS response packet resulted NXDOMAIN 85 or SERVFAIL to the AAAA query, partly described in [RFC4074]. 86 Resolutions of this case are out of scope of this memo. 88 It is legitimate to embed an IPv4 address literal in an URL such as 89 follows: 90 http://192.0.2.10/index.html 91 In the environment described above, the destination is not accessible 92 from an IPv6-only host. This problem has already been reported in 93 [RFC6586] and others. 95 The reason why the destination specified by above notation cannot be 96 accessible is that no DNS lookup is performed, and no DNS64 service 97 is able to tell a Pref64::/n address to the host. To perform DNS64/ 98 NAT64 translation against such an IPv4 address literal notation, some 99 mechanism will be required. 101 This memo proposes a special-purpose TLD and defines behaviors of 102 resolvers and of the authoritative servers to treat the special- 103 purpose TLD. This memo also considers implementation strategy of 104 .TLD and side effects of .TLD usages to the current communications on 105 the Internet. The special-purpose TLD is denoted as .TLD which will 106 be replaced with an actual TLD allocated by IANA. 108 The concept of .TLD is simple: All IPv4 address literal notations are 109 rewritten to ``.TLD'' on a host. As ``.TLD'' is seemed to be a regular FQDN, ``.TLD'' lets DNS64 servers resolve IPv4 address 112 literal as a regular FQDN and translate the A record of ``.TLD'' to a corresponding Pref64::/n address on each 114 leaf network. For example, 192.0.2.10.TLD in DNS64/NAT64 environment 115 would be translated to a Pref64::c000:020a. In an IPv4 environment, 116 192.0.2.10.TLD would be resolved just as an A record about 117 192.0.2.10. 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 2. Scope of this memo 125 This memo focuses only on smooth migration to an IPv6-only 126 environment with the DNS64/NAT64 solution. Therefore, this memo 127 focuses on only ``IPv4 address literal'' problem mentioned in 128 [RFC6586]. 130 The ``IPv6 address literal'' is out of scope of this memo, because an 131 URL including IPv6 address literal can be accessible in IPv6-only 132 networks and in dual stack networks. The solutions to keep IPv4-only 133 hosts or IPv4-only applications in IPv6 only environment are out of 134 scope on this memo. 136 3. A special-purpose TLD for IPv4 Address Literal 138 When the part of IPv4 address literal is written to form a pseudo 139 FQDN and the pseudo FQDN is resolved as an IPv4 address, a DNS64 140 server can return a AAAA record with the specified IPv4 address that 141 is mapped to an appropriate NAT64 prefix. 143 Once a AAAA record is obtained, the IPv6-only host can send IPv6 144 packets to the destination. IPv6 packets will be translated back via 145 NAT64 translator in exactly the same as a regular IPv4-only 146 destination. 148 3.1. .TLD Authoritative DNS server behavior 150 The authoritative DNS server of .TLD SHOULD be operated only for a 151 special purpose. 152 1. If a DNS query asks ``.TLD '', .TLD 153 authoritative server MUST return ``'' as 154 the A record of ``.TLD ''. 155 2. Otherwise, .TLD authoritative server MUST return NXDOMAIN. 157 3.2. DNS64 behaviors 159 When a DNS64 receives a query of .TLD, it 160 SHOULD issue a DNS query to one of the .TLD authoritative servers. 161 The response from .TLD authoritative server will be either an A 162 record of the issued or NXDOMAIN. If the 163 response contains an A record, the DNS64 MUST translate the IPv4 164 address in the A record to the AAAA record by Pref64::/n address 165 according to [RFC6147]. 167 Taking into account of scalability, the DNS64 WOULD cache the AAAA 168 record of .TLD in a certain interval. As one 169 of possible ways to get more scalability, the DNS64 CLOUD have the 170 function of .TLD authoritative server. 172 3.3. Client behaviors 174 3.3.1. Case 1: manual type-writing 176 When a client (human) wants to access an IPv4 only server by IPv4 177 address literal in a DNS64/NAT64 network, he / she manually attaches 178 .TLD to the IPv4 address of the IPv4 only server. When the network 179 has DNS64/NAT64 function, the AAAA record, that is Pref64::/n address 180 of the issued , will be return. 182 The client COULD attach .TLD to the IPv4 address of the IPv4 only 183 server in an IPv4 only network or a dual stack network. When the 184 network situation is IPv4 only or dual stack, the A record of the 185 issued .TLD will be returned. 187 If the client uses FQDN or IPv6 address literal, he / she MUST NOT 188 attach .TLD. 190 3.3.2. Case 2: device or application 192 A client (device or application), that has a name resolution 193 function, SHOULD attach .TLD when the input value of getaddrinfo is 194 an IPv4 address literal. For example, SHOULD 195 be rewritten to .TLD. If the input value of 196 getaddrinfo is not IPv4 address literal, the client MUST NOT attach 197 .TLD. 199 Of course, the client CAN take self-synthesizing of mapped address 200 mentioned in [RFC7050], or MAY combine .TLD method and [RFC7050] 201 self-synthesizing method. 203 Some access authentication may not allow any external accesses until 204 access authentication procedure is finished, and may use an IPv4 205 address literal on the redirected authentication web page. Taking 206 into account such corner case, client WOULD check the reachability to 207 the external network initially. 209 NOTE: migrating from IPv4 to IPv6, access authentication SHOULD avoid 210 to use IPv4 address literal and SHOULD use FQDN for dual stack client 211 or IPv6 only client. 213 3.4. DNS query flow 215 Figure 1 shows a DNS query flow on the .TLD. 217 1. An application on a client creates .TLD. 218 2. The application inputs the query of AAAA or ANY about .TLD. to its local resolver. 220 3. The local resolver forwards the query to a recursive resolver 221 that would be a DNS64 server in DNS64/NAT64 environment. 222 4. The recursive resolver sends a recursive query of .TLD. 224 5. .TLD authoritative server creates the A record of the issued 225 .TLD, and MAY check PTR record of the 226 issued . Then, .TLD authoritative server 227 returns the DNS response to the recursive resolver. 228 6. When the recursive resolver has DNS64 function, it creates the 229 AAAA record according to [RFC6147] and replies the AAAA record to 230 the local resolver on the client. If the recursive resolver does 231 not have DNS64 function, the recursive resolver returns the A 232 record responded from .TLD authoritative server. 233 7. The application on the client gets the appropriate IP address 234 (IPv4 address or Pref64::/n address), then creates an appropriate 235 socket. 237 +----------+ 238 | auth DNS | 239 | for PTR | 240 | Record | 241 +----------+ 242 || 243 (5) 244 || 245 +-------+ +--------+ +---------+ +----------+ 246 | app |--(2)-->| local |--(3)-->|Recursive|--(4)-->|auth .TLD | 247 |(1)(7) |<-(6)-- |resolver|<-(6)---|Resolver |<-(5)---|DNS server| 248 +-------+ | | | | +----------+ 249 +--------+ | (DNS64) | 250 +---------+ 252 DNS Query Flow on .TLD 254 Figure 1 256 This solution would not require the modification of common shared 257 libraries on any Operating Systems. The DNS implementations, SHOULD 258 support .TLD. As the query flow mentioned above, .TLD authoritative 259 server SHOULD be placed. The modification of NAT64 or DHCP are not 260 required in this method. 262 3.5. Use cases 264 3.5.1. Use case 1: manual type-writing 266 For example, consider living on an IPv6-only network with DNS64/ 267 NAT64, and receiving a message like ``please download a file foo.doc 268 from a ftp server 192.0.2.10''. Usually, you may estimate the NAT64 269 prefix and calculate Pref64::/n address through [RFC7050] or 270 [RFC7051]. Under the proposed mechanism on this memo, you can just 271 type as follow; 272 % ftp 192.0.2.10.TLD 274 The packet would be transferred along with [RFC6384]. 276 3.5.2. Use case 2: browser plug-in 278 An IPv4 address literal is often used in URL for the lazy DNS 279 operation, a temporary HTTP server or a hidden (private) server. 280 Taking into account user convenience, a browser plug-in can be 281 developed that it converts the on the hostname 282 part of an URL to .TLD. It may be suggested to 283 turn this function on when the host is on IPv6-only network, however, 284 it may not be easy to detect the situation of the network (IPv4 only, 285 dual stack or DNS64/NAT64 environment). A sample of Google Chrome 286 plug-in is attached in Appendix B 288 3.6. Recommendation 290 For usability in manual type-writing, the .TLD SHOULD be as short as 291 possible, and SHOULD express the special purpose in the name space. 292 ``.v4'' is recommended as a candidate of .TLD, because of the 293 simplicity and the expression of IPv4. 295 4. Considerations 297 4.1. Attached the special-purpose TLD to a regular FQDN 299 Conceptually, the special-purpose TLD would be attached to only IPv4 300 address literals, however, the special-purpose TLD may be attached to 301 a regular FQDN notation like ``foo.bar.com.TLD''. Such misuses 302 SHOULD be avoided. 304 4.2. An embedded IP address literal in the content part of URL 306 In some case, may be embedded into the content 307 part of a URL, however, it may be difficult for users or browser 308 plug-ins to recognize unambiguously that a string like surely means some IPv4 address. From the point of view of 310 IPv6 migration, embedded IP address literal in the content part of an 311 URL MUST be avoided. 313 4.3. Prevention the leak of the special-purpose TLD 315 When .TLD is actually employed in the operation, .TLD may leak to the 316 public DNS infrastructure including root DNS servers as seen in 317 ``.local''. Therefore, once consensus is obtained, the relevant TLD 318 SHOULD be delegated to a set of DNS servers. 320 Two possible DNS operation methods can be considered. One is to 321 delegate the TLD to AS112 servers [as112-servers]. When one of the 322 AS112 servers received a query with .TLD, it returns with NXDOMAIN. 324 The other possible DNS operation is to deploy a set of special 325 purpose DNS servers which accept queries with .TLD and synthesize an 326 A record corresponding to the IPv4 address in the QNAME when it is a 327 legitimate IPv4 address. Otherwise, NXDOMAIN MUST be returned. 329 4.4. Possibility to break connections with Apache VirtualHost concept 331 Changing the URL (swapping the DNS name or adding in a Pref64) 332 frequently breaks the connections since the application is aware of 333 the name it expects, and connecting correctly to the correct IP 334 address is not sufficient, the name must also be the same in many 335 cases. 337 For example, many websites use the Apache VirtualHost concept. When 338 a web site that changes contents along with accessed IP address 339 family like http://www.kame.net/ or http://dual.tlund.se/ , and if 340 some client accesses such web site by .TLD 341 instead of FQDN, the VirtualHost may not work as intended. 343 Therefore, such web site, that uses the Apache VirtualHost concept, 344 SHOULD NOT use in URL and SHOULD use 345 appropriate FQDN. 347 4.5. Inaffinity with HTTP/HTTPS Cookie 349 This solution may not work with HTTP/HTTPS cookie. We should also 350 consider the HTTP security considerations for the cases where someone 351 puts one of the names into a URL. For example, consider 352 http://192.0.2.10.TLD/ to an origin that sets a cookie on the domain 353 "*.10.TLD". 355 There are likely already plenty of ways to do the same thing out 356 there, so this may not be a major issue. 358 4.6. TLD alternatives 360 In Section 3.6, we propose .v4 as the TLD, and comparisons with other 361 candidates are discussed as follows. 363 4.6.1. .v4.arpa 365 ``v4.arpa'' may be a candidate of .TLD that does not require new TLD, 366 however, it may be confued with [RFC7050] ``ipv4only.arpa'', and the 367 length (8 characters) of ``.v4.arpa'' is bit longer than the length 368 (3 characters) of ``.v4'' for type-writing usages. 370 4.6.2. .host 372 ``.host'' has already been assigned as one of the new gTLDs, and not 373 considered a candidate here unless the authority of .host offers 256 374 (or 356 -- see discussion in Section 4.6.3) delegations to this 375 purpose. 377 4.6.3. TLD less delegation 379 When it is feasible to "delegate" 256 TLDs (from ".0" through ".255") 380 or 366 TLDs (".00", ".000", and others are added) for this particular 381 purpose, it is possible to implement the functionality described in 382 this memo without assigning a particular .TLD. It contributes 256 383 (or 356) extra TLDs in the Root zone. 385 It is known that DNS queries with such TLDs have been observed, and 386 this delegation may interfere with undocumented usage of such TLDs. 388 If such 256 (or 366) delegations is suitable, bogus such queries to 389 the root servers will be redirected to the DNS server described in 390 Section 5. 392 4.7. Usages of IPv6 address literal 394 The special-purpose TLD may be applied to IPv6 address cases in same 395 ways, however, such notation is not required in dual stack / IPv6- 396 only environment, generally. 398 4.8. RFC7050 ipv4only.arpa 400 [RFC7050] defines a method to estimate a NAT64 prefix by querying 401 Well-Known IPv4-only Name ``ipv4only.arpa''. [RFC7050] does not 402 cover several situations. .TLD method is aimed to solve such 403 situations as follows: 405 4.8.1. Multiple NAT64 prefixes for load balancing 407 One of situations is multihoming, illustrated in Figure 2. In this 408 situation, the NAT64 prefix estimated by [RFC7050] method may be 409 different from the one that the operator intends. 411 +-------------+ +-------+ +-------------------+ 412 | +====| NAT64 |=====+ IPv4 ISP A | 413 +------+ | IPv6 Only | +-------+ +-------------------+ 414 |client|====| Segment | 415 +------+ | | +-------+ +-------------------+ 416 | +====| NAT64 |=====+ IPv4 ISP B | 417 +-------------+ +-------+ +-------------------+ 418 | 419 +---+---+ 420 | DNS64 | 421 +-------+ 423 Situation A : multiple NAT64 prefixes for optimizing routes on 424 multihoming 426 Figure 2 428 4.8.2. Multiple NAT64 prefixes for external / internal IPv4 only 429 networks 431 Another situation is where multiple NAT64 prefixes are operated for 432 accessing the external IPv4 Internet and an internal private IPv4 433 only network from an internal IPv6 only network. Figure 3 draws this 434 situation. In this situation, the NAT64 prefix estimated by 435 [RFC7050] method could not be reached to the internal IPv4 only 436 network. 438 +-------+ 439 | DNS64 | 440 +---+---+ 441 | 442 +-------------+ +--------+ +----------+ 443 | | +-------+ | IPv6 | +-------+ | | 444 | internal +===| NAT64 |==+ Only +==| NAT64 |==+ IPv4 | 445 | network | +-------+ | Seg. | +-------+ | Internet | 446 +-------------+ +--------+ +----------+ 447 | 448 +---+----+ 449 | client | 450 +--------+ 452 Situation B : multiple NAT64 prefixes for internal / external 454 Figure 3 456 4.8.3. Difficulty of conversion from octet expression to hex expression 457 by human type-writing 459 As the initial motivation of this memo, IPv4 address literal is often 460 used for a personal / private server that is not registered in DNS 461 record because of lazy operation, temporal usage, or the intention to 462 hide from DNS query scans. ``ipv4only.arpa'' solution can be 463 available to synthesize the Pref64::/n address for the private 464 server, however, the owner of the private server has to convert the 465 octet expression of the IPv4 address on his/her private server to the 466 hex expression by manual. Usually, conversion from octet expression 467 to hex expression by manual is difficult or tiresome operation. 469 5. Implementation Strategy 471 It is suggested to implement the .TLD rewriting as in the following 472 order: 473 1. Define .TLD 474 Once the community agrees to accept the rewriting scheme 475 described in this memo, it must fix the .TLD to be used. The 476 .TLD WOULD require the update of [RFC6761]. 477 2. .TLD delegation 478 DNS queries with .TLD can leak to the DNS of the global 479 Internet, it is highly suggested to delegate .TLD to a set of 480 authoritative DNS servers as discussed in Section 4.3. 481 3. DNS64 modification 482 DNS64 implementation is suggested to modify to respond 483 corresponding AAAA record to a query with .TLD. This process 484 can be done in parallel to the step 2 above. 485 4. Start using .TLD rewriting 486 After, at least the step 2 is completed, the TLD rewriting may 487 be used in manually described in Section 3.5.1 or 488 automatically by browser plugins described in Section 3.5.2. 489 While further discussions and observation is required, the use 490 of an URL in IPv4 literal embedded might be discouraged. 491 Instead, the use of .TLD notation as a legitimate URL might be 492 encouraged even in the server side. 494 6. Security Considerations 496 The recommendation contains security considerations related to DNS. 497 The special purpose DNS servers of this memo only treats the IPv4 498 address literal with .TLD. Therefore, the special DNS MAY use self- 499 signed / authorized key for DNS responses. 501 When a client is to access an URL with IPv4 literal address embedded, 502 it triggers a DNS query, and the query may be sent over the Internet 503 to the nearest authoritative .TLD DNS server. It may break the 504 confidentiality against the DNS service. 506 TBD 508 7. IANA Considerations 510 This memo calls for ``.v4'' as the special-purpose TLD to the IANA 511 registry. 513 8. Acknowledgments 515 Authors thank to WIDE Project members for their active discussion, 516 implementations, and evaluations. Especially, we thank to Atsushi 517 ONOE for the revision of this solution, Hirochika ASAI for the 518 contribution of the prototype implementation of the special purpose 519 authoritative DNS, and Hirotaka NAKAJIMA for the contribution of the 520 Google chrome plug-in. We also thank to Yoshiaki KITAGUCHI, Yu-ya 521 KAWAKAMI and others who evaluated our proof of concept special 522 purpose DNS (.v4.wide.ad.jp) and the Google Chrome plugin-in at 523 JANOG34 DNS64/NAT64 experiment networks. Teeme Savolainen, Cameron 524 Byrne, Dan Wing, Erik Nygren gave us various considerations on the 525 actual operation of .TLD. 527 9. References 529 9.1. Normative References 531 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 532 Requirement Levels", BCP 14, RFC 2119, March 1997. 534 [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against 535 DNS Queries for IPv6 Addresses", RFC 4074, May 2005. 537 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 538 NAT64: Network Address and Protocol Translation from IPv6 539 Clients to IPv4 Servers", RFC 6146, April 2011. 541 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 542 Beijnum, "DNS64: DNS Extensions for Network Address 543 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 544 April 2011. 546 [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) 547 for IPv6-to-IPv4 Translation", RFC 6384, October 2011. 549 [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 550 Network", RFC 6586, April 2012. 552 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 553 RFC 6761, February 2013. 555 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 556 the IPv6 Prefix Used for IPv6 Address Synthesis", 557 RFC 7050, November 2013. 559 [RFC7051] Korhonen, J. and T. Savolainen, "Analysis of Solution 560 Proposals for Hosts to Learn NAT64 Prefix", RFC 7051, 561 November 2013. 563 9.2. Informative References 565 [as112-servers] 566 AS112 Project, "AS112 Project", October 2009, 567 . 569 Appendix A. A Test Server of the special TLD 571 We run a prototype implementation of the special-purpose DNS server 572 in the WIDE backbone (AS 2500). We use ``.v4.wide.ad.jp'' as .TLD. 574 Appendix B. Sample extension for Google Chrome 576 We developed a sample plug-in code for Google Chrome ``IPv4 Address 577 Literal Appender'' that automatically converts 578 in URL to .TLD. The .TLD can be customized in 579 the option. The ``IPv4 Address Literal Appender'' is freely 580 available in Google Chrome Web Store, and also in github 581 https://github.com/nunnun/nat64-v4-literal-extension. 583 var wr = chrome.webRequest; 585 var v4Suffix = ".TLD"; 586 var ipAddrRegex = /^(\d|[01]?\d\d|2[0-4]\d|25[0-5])\.(\d|[01]?\d\d| 587 2[0-4]\d|25[0-5])\.(\d|[01]?\d\d|2[0-4]\d|25[0-5])\.(\d|[01]?\d\d|2 588 [0-4]\d|25[0-5])$/; 590 function onBeforeRequest(details) { 591 var tmpuri = new URI(details.url); 592 var tmphost = tmpuri.host(); 593 var finalUri = ''; 594 tmphost.replace(ipAddrRegex,function(str,p1,p2,p3,p4,offset,s){ 595 finalUri=tmpuri.host(p1+"."+p2+"."+p3+"."+p4+v4Suffix).toString(); 596 }); 597 if('' != finalUri) { 598 console.log(finalUri); 599 return {redirectUrl: finalUri}; 600 } 601 }; 603 wr.onBeforeRequest.addListener(onBeforeRequest,{urls: ["https://*/*", 604 "http://*/*", "ftp://*/*"]}, ["blocking"]); 606 Authors' Addresses 608 Osamu Nakamura 609 Keio Univ./WIDE Project 610 5322 Endo 611 Fujisawa, Kanagawa 252-0882 612 JP 614 Phone: +81 466 49 1100 615 Email: osamu@wide.ad.jp 617 Hiroaki Hazeyama 618 NAIST / WIDE Project 619 8916-5 Takayama 620 Ikoma, Nara 630-0192 621 JP 623 Phone: +81 743 72 5111 624 Email: hiroa-ha@is.naist.jp 625 Yukito Ueno 626 Keio Univ./WIDE Project 627 5322 Endo 628 Fujisawa, Kanagawa 252-0882 629 JP 631 Phone: +81 466 49 1100 632 Email: eden@sfc.wide.ad.jp 634 Akira Kato 635 Keio Univ. / WIDE Project 636 Graduate School of Media Design, 4-1-1 Hiyoshi 637 Kohoku, Yokohama 223-8526 638 JP 640 Phone: +81 45 564 2490 641 Email: kato@wide.ad.jp