Internet Engineering Task Force O. Nakamura
Internet-Draft Keio Univ./WIDE Project
Intended status: Informational H. Hazeyama
Expires: January 11, 2014 NAIST / WIDE Project
Y. Ueno
Keio Univ./WIDE Project
A. Kato
Keio Univ. / WIDE Project
July 10, 2013
IPv4 Address Literal in URL
draft-osamu-v6ops-ipv4-literal-in-url-00
Abstract
In an IPv6-only environment with DNS64/NAT64 based translation
service, there is no way to get access a URL whose domain name part
includes an IPv4 address literal. This memo discusses a few methods
to rewrite the URL on an IPv6-only host so that the URL is accessible
from the IPv6-only host.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 11, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Nakamura, et al. Expires January 11, 2014 [Page 1]
Internet-Draft IPv4addr in URL July 2013
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
1. Introduction and Overview
When a host in an IPv6 only environment (an IPv6-only host) has to
access an IPv4-only destination, a translator-based approach is a
powerful tool. The translator-based approach is usually composed of
a DNS64 server [RFC6147] and a stateful NAT64 translator [RFC6146].
The DNS64 server responds with an AAAA record of an IPv4 embedded
IPv6 address with significant IPv6 prefix assigned to the NAT64
translator. The IPv6-only host sends an IPv6 packet, which is
translated by the NAT64 box to an IPv4 packet. The translation of
responded IPv4 packet back into an IPv6 packet is also performed in
the NAT64 translator.
The NAT64 with DNS64 approach works well for most destinations. It
does not work well when the DNS response packet included NXDOMAIN or
SERVFAIL to the AAAA query, partly described in [RFC4074].
Resolution of this case is out of scope of this memo.
It is legitimate to embed an IPv4 address literal in an URL such as
follows:
http://192.0.2.10/index.html
In the environment described above, the destination is not accessible
from an IPv6-only host. This problem has already been reported in
[RFC6586] and other experiences.
The reason why we cannot access the destination specified by above
notation is that no DNS lookup is performed in most cases, and no
DNS64 service is able to tell an IPv4 embedded IPv6 address to the
host. To perform DNS64/NAT64 translation against such an IPv4
Nakamura, et al. Expires January 11, 2014 [Page 2]
Internet-Draft IPv4addr in URL July 2013
address literal notation, some mechanism will be required.
This memo proposes a special-use TLD. We denote the special-use TLD
as ``.TLD'' which will be replaced with actual TLD based on
discussion in Section 3.5. The concept of ``.TLD'' is simple; all
IPv4 address literal notations are rewritten to ``<ipv4-address-
literal>.TLD'' on the IPv6-only host, letting DNS servers and
translators translate the IPv4 address literal to appropriate IP
address on each leaf network. For example, <ipv4-address-
literal>.TLD in DNS64/NAT64 environment would be translated to a
NAT64 prefix mapped address.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Scope of this memo
Before discussing solutions, we define the scope of this memo. We
focus only on smooth migration to an IPv6-only environment with the
DNS64/NAT64 solution. Therefore, we focus on only ``IPv4 address
literal'' problem mentioned in [RFC6586].
The ``IPv6 address literal'' is out of scope of this memo, because an
URL including IPv6 address literal can be accessible in IPv6-only
networks and in dual stack networks. The solutions to keep IPv4-only
hosts or IPv4-only applications in IPv6 only environment are out of
scope on this memo.
3. A special-use TLD for IPv4 Address Literal
When the part of IPv4 address literal is written to form a pseudo
FQDN, the DNS64 server can return an AAAA record with the specified
IPv4 address that is mapped to a NAT64 prefix.
Once an AAAA record is obtained, the IPv6-only host can send an IPv6
packet to the destination. The IPv6 packet will be translated via
NAT64 translator in the same way as a regular IPv4-only destination.
3.1. The procedure in detail
The procedure of the special-use TLD is as follows;
o An host internally attaches ``.TLD'' to an IPv4 address literal.
For example, <ipv4-address-literal> is rewritten to <ipv4-address-
literal>.TLD.
Nakamura, et al. Expires January 11, 2014 [Page 3]
Internet-Draft IPv4addr in URL July 2013
o The host gets access to <ipv4-address-literal>.TLD instead of
<ipv4-address-literal>.
o As <ipv4-address-literal>.TLD looks like a regular FQDN, the IPv6-
only host will query the FQDN to a DNS server.
o The DNS server recognizes that the FQDN ``<ipv4-address-
literal>.TLD'' is a special-use TLD. Then,
* If the network is an IPv6-only network, and if the IPv6-only
network has a DNS64 server and NAT64 translator(s), then, the
DNS64 server SHOULD convert <ipv4-address-literal> into a NAT64
prefix mapped address and returns the NAT64 prefix mapped
address as an AAAA record.
* If the network is an IPv4-only network, then, the DNS4 server
MAY remove ``.TLD'' and returns an A record corresponding to
<ipv4-address-literal>.
* If the network is a dual stack network, and if the dual stack
network does not have any DNS64/NAT64 function, then, DNS4
server MAY remove ``.TLD'' and returns <ipv4-address-literal>
as an A record.
* If the network is a dual stack network, and if the dual stack
network has any DNS64/NAT64 function, then, <ipv4-address-
literal> MAY be returned as an A record and NAT64 prefix mapped
address MAY be returned as an AAAA record.
o After the name resolution procedure is completed, the host will
access the <ipv4-address-literal> through an appropriate socket.
This solution would not require the modification of common shared
libraries on Operating Systems. The DNS implementations have to
support the special-use TLD and the procedure mentioned above. The
modification of NAT64 or DHCP are not required.
3.2. Use case 1: manual use
For example, consider living on an IPv6-only network with DNS64/
NAT64, and receiving a message like ``please download a file foo.doc
from a ftp server 192.0.2.10''. Usually, you don't have any method
to get NAT64 information. Under the proposed mechanism, you can just
type as follow;
% ftp 192.0.2.10.TLD
The packet would be transferred along with [RFC6384].
3.3. Use case 2: browser plug-in
An IPv4 address literal is often used in URL for the lazy DNS
operation, a temporary HTTP server or a hidden (private) server.
Taking into account user convenience, a browser plug-in can be
developed that it converts the <ipv4-address-literal> on the hostname
part of an URL to <ipv4-address-literal>.TLD. It may suggested to
Nakamura, et al. Expires January 11, 2014 [Page 4]
Internet-Draft IPv4addr in URL July 2013
turn this on when the host is on IPv6-only network, however, it may
not be easy to detect it.
3.4. Other Possible Solutions
Several possible solutions can be considered described below,
however, most of them would not work between considerable fraction of
IPv6 only networks and dual stack networks.
3.4.1. IPv4-Compatible IPv6 Address
The literally embedded IPv4 address is converted to an IPv4-
Compatible IPv6 address, and sent to the NAT64 converter as usual.
This solution requires application or common shared library
modification.
Also, the procedure for learning about the NAT64 prefix to be used
for a particular IPv4 destination is issued. Looking up to some
known IPv4-only anchor host is a possible method. However, current
ISC BIND DNS64 implementation can set different NAT64 prefixes to
different IPv4 address prefixes. Therefore, this solution would not
work well.
3.4.2. Advertising NAT64 prefix by DHCP or DNS
Wing proposed a solution that advertises a NAT64 prefix by DHCP or
DNS in [I-D.draft-wing-behave-learn-prefix-04]'' in 2009. But this
solution is a little complex and requires various modifications to
DNS and DHCP implementations. Wing's draft has already expired.
3.4.3. Using BIH or 464XLAT CLAT on a host
Bump in the Host (BIH) [RFC6535] and 464XLAT [RFC6877] are possible
solutions, both of which are aimed at retaining the usage of IPv4-
only applications in IPv6-only environment. BIH has a local
translator function between the socket API and the TCP/IP stack. On
the other hand, 464XLAT provides PLAT (Provider side XLAT) [RFC6146]
and CLAT (Customer side XLAT) [RFC6145]. Some mobile carriers have
started CLAT CPE on smart phones. Therefore, some CLAT plug-in on a
browser or CLAT CPE on a host may work.
The BIH case requires several extensions on Operating Systems, so we
have to wait many independent Operating System Open Source Projects
and/or commercial Operating System vendors support BIH in their
Operating Systems.
In case of the 464XLAT, 464XLAT assumes that a user always uses a
specific CLAT and PLAT pair. If a user want to change or move
Nakamura, et al. Expires January 11, 2014 [Page 5]
Internet-Draft IPv4addr in URL July 2013
various public wi-fi networks, then, a global reachable PLAT might be
placed and a CLAT on a host has to equip a function that switches the
CLAT function depending on the condition of the current network.
3.5. special-use TLD alternatives
A few candidates of the special-use TLD is discussed here.
3.5.1. Use of .host special TLD
A special string ``.host'' is attached to an IPv4 address literal
notation like ``192.0.2.10'' to form a pseudo FQDN such as
``192.0.2.10.host''. Also, IPv4 address and port number literal is
often used, for instance, ``192.0.2.10:8080'' becomes
``192.0.2.10.host:8080''.
3.5.2. Use of .ip4host.arpa special TLD
This idea is almost the same as ``.host'', but uses ``ip4host.arpa''
top level labels rather than ``.host''. While the pseudo FQDN is
expected to appear only in the DNS look up by an IPv6-only host, it
may leak to the global Internet. In order to avoid the query to the
Root DNS servers, use of the sub-domain of ".arpa" may be
recommended. The generated pseudo FQDN looks like
``192.0.2.10.ip4host.arpa''.
3.5.3. Use of .dns64 special TLD
The special-use TLD is mainly aimed to force IPv4 address literal
notation to be translated by DNS64/NAT64 in IPv6-only environments.
Therefore, ``.dns64'' reflects the request for DNS64/NAT64
translation against an IPv4 address.
3.5.4. Our recommendation
We, authors of this memo, discussed which special-use TLD is
suitable. Our recommendation is to use ``.host'' from the view of
usability. Of course, we will accept any feedbacks from the
community such as IETF v6ops and dnsops working groups and users
community.
4. Discussions
4.1. Usages of IPv6 address literal
The special-use TLD may be applied to IPv6 address cases in same
ways, however, such notation is not required in dual stack / IPv6-
Nakamura, et al. Expires January 11, 2014 [Page 6]
Internet-Draft IPv4addr in URL July 2013
only environment, generally.
4.2. Attached the special-use TLD to a regular FQDN
Conceptually, the special-use TLD would be attached to only IPv4
address literals, however, the special-use TLD may be attached to a
regular FQDN notation like ``foo.bar.com.TLD''. We propose that such
misuses should be discarded on the DNS or applications on the host
side.
4.3. An embedded IP address literal in the content part of URL
In some case, <ipv4-address-literal> may be embedded into the content
part of a URL, however, it may be difficult for users or browser
plug-ins to recognize unambiguously that a string like <ipv4-address-
literal> surely means some IPv4 address. From the point of view of
IPv6 migration, embedded IP address literal in the content part of an
URL MUST be avoided.
4.4. Prevention the leak of the special-use TLD
When the special-use TLD ``.TLD'' is actually employed in the
operation, ``.TLD'' will leak to the public DNS infrastructure
including root DNS servers as seen in ``.local''. Therefore, once
consensus is obtained, the relevant TLD SHOULD be delegated to a set
of DNS servers.
Two possible DNS operation methods can be considered. One is to
delegate the TLD to AS112 servers [as112-servers]. When one of the
AS112 servers received a query with the special-use TLD, it returns
with NXDOMAIN.
The other possible DNS operation is to deploy a set of special
purpose DNS servers which accept queries with ``.TLD'' and synthesize
an A record corresponding to the IPv4 address in the QNAME when it is
a legitimate IPv4 address. Otherwise, NXDOMAIN is returned.
5. Implementation Strategy
It is suggested to implement the .TLD rewriting as in the following
order:
1. Define .TLD
Once the community agrees to accept the rewriting scheme
described in this memo, it must fix the .TLD to be used.
2. .TLD delegation
Nakamura, et al. Expires January 11, 2014 [Page 7]
Internet-Draft IPv4addr in URL July 2013
DNS queries with .TLD can leak to the DNS of the global
Internet, it is highly suggested to delegate .TLD to a set of
authoritative DNS servers as discussed in Section 4.4.
3. DNS64 modification
DNS64 implementation is suggested to modify to respond
corresponding AAAA record to a query with .TLD. This process
can be done in parallel to the step 2 above.
4. Start using .TLD rewriting
After, at least the step 2 is completed, the TLD rewriting may
be used in manually described in Section 3.2 or automatically
by browser plugins described in Section 3.3.
While further discussions and observation is required, we may
discourage to use an URL in IPv4 literal embedded. Instead,
we may encourage to use .TLD notation as a legitimate URL even
in the server side.
6. Security Considerations
The recommendation contains security considerations related to DNS.
At the moment, we do not consider the affinity with DNSSEC.
7. IANA Considerations
According to the discussion with communities, this memo may call for
changes or additions of special-use TLD to the IANA registry.
8. Acknowledgments
The authors thank all members of WIDE Project for their active
discussion, implementation, and evaluation.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against
DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
Nakamura, et al. Expires January 11, 2014 [Page 8]
Internet-Draft IPv4addr in URL July 2013
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011.
[RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG)
for IPv6-to-IPv4 Translation", RFC 6384, October 2011.
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012.
[RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
Network", RFC 6586, April 2012.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation",
RFC 6877, April 2013.
9.2. Informative References
[I-D.draft-wing-behave-learn-prefix-04]
Wing, D., "Learning the IPv6 Prefix of a Network's IPv6/
IPv4 Translator", October 2009,
<draft-wing-behave-learn-prefix-04 (expired)>.
[as112-servers]
AS112 Project, "AS112 Project", October 2009,
<https://www.as112.net/>.
Nakamura, et al. Expires January 11, 2014 [Page 9]
Internet-Draft IPv4addr in URL July 2013
Appendix A. Sample extension for Google Chrome
var wr = chrome.webRequest;
var v4Suffix = ".TLD";
var ipAddrRegex = /^(\d|[01]?\d\d|2[0-4]\d|25[0-5])\.(\d|[01]?\d\d|2[0-
4]\d|25[0-5])\.(\d|[01]?\d\d|2[0-4]\d|25[0-5])\.(\d|[01]?\d\d|2[0-4]\d|2
5[0-5])$/;
function onBeforeRequest(details) {
var tmpuri = new URI(details.url);
var tmphost = tmpuri.host();
var finalUri = '';
tmphost.replace(ipAddrRegex,function(str, p1, p2, p3, p4, offset, s){
finalUri = tmpuri.host(p1+"."+p2+"."+p3+"."+p4+v4Suffix).toString();
});
if('' != finalUri) {
console.log(finalUri);
return {redirectUrl: finalUri};
}
};
wr.onBeforeRequest.addListener(onBeforeRequest, {urls: ["https://*/*",
"http://*/*", "ftp://*/*"]}, ["blocking"]);
Authors' Addresses
Osamu Nakamura
Keio Univ./WIDE Project
5322 Endo
Fujisawa, Kanagawa 252-0882
JP
Phone: +81 466 49 1100
Email: osamu@wide.ad.jp
Hiroaki Hazeyama
NAIST / WIDE Project
8916-5 Takayama
Ikoma, Nara 630-0192
JP
Phone: +81 743 72 5111
Email: hiroa-ha@is.naist.jp
Nakamura, et al. Expires January 11, 2014 [Page 10]
Internet-Draft IPv4addr in URL July 2013
Yukito Ueno
Keio Univ./WIDE Project
5322 Endo
Fujisawa, Kanagawa 252-0882
JP
Phone: +81 466 49 1100
Email: eden@sfc.wide.ad.jp
Akira Kato
Keio Univ. / WIDE Project
Graduate School of Media Design, 4-1-1 Hiyoshi
Kohoku, Yokohama 223-8526
JP
Phone: +81 45 564 2490
Email: kato@wide.ad.jp
Nakamura, et al. Expires January 11, 2014 [Page 11]