One document matched: draft-boucadair-behave-dns-a64-00.txt
Network Working Group M. Boucadair
Internet-Draft E. Burgey
Intended status: Standards Track France Telecom
Expires: April 22, 2010 October 19, 2009
A64: DNS Resource Record for IPv4-mapped IPv6 Address
draft-boucadair-behave-dns-a64-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. 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.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2010.
Copyright Notice
Copyright (c) 2009 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
Boucadair & Burgey Expires April 22, 2010 [Page 1]
Internet-Draft A64 DNS Record October 2009
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
In this context of IPv4-IPv6 interconnection, several solutions have
been proposed. Some of these solutions require the definition of a
new IPv4-mapped IPv6 address [I-D.ietf-behave-address-format] which
is used to represent an IPv4-only host in an IPv6 realms and the
definition of a new mechanism called DNS64 for synthesizing a AAAA
record, representing an IPv4-mapped IPv6 address in the DNS system,
from the A record representing the IPv4 address of the IPv4-only host
[I-D.ietf-behave-dns64]. This IPv4-mapped IPv6 address, when managed
by a translator, is to be considered as "fake" address in a DNS
system since it is not necessarily assigned to any host's interface
qualified by the associated name. This document defines a new DNS
record type and query type to identify IPv4-mapped IPv6 address
[I-D.ietf-behave-address-format] from native IPv6 ones. The new
record type and query type aim at helping the remote party to enforce
its policies and avoid NAT64 boxes when possible. Native addresses
are to be preferred.
Requirements Language
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 RFC 2119 [RFC2119].
Boucadair & Burgey Expires April 22, 2010 [Page 2]
Internet-Draft A64 DNS Record October 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Contribution of this Draft . . . . . . . . . . . . . . . . 4
1.3. Backward Compatibility Issue . . . . . . . . . . . . . . . 5
2. IPv4-mapped IPv6 Record: A64 . . . . . . . . . . . . . . . . . 5
2.1. A64 Record Type . . . . . . . . . . . . . . . . . . . . . . 5
2.2. A64 Data Format . . . . . . . . . . . . . . . . . . . . . . 6
2.3. A64 Query . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Textual format of A64 records . . . . . . . . . . . . . . . 6
2.5. IP64.INT Domain . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Modifications to Existing Query Types . . . . . . . . . . . 6
3. On the Need of a New Query type . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative Reference . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Boucadair & Burgey Expires April 22, 2010 [Page 3]
Internet-Draft A64 DNS Record October 2009
1. Introduction
1.1. Overall Context
Due to IPv4 address depletion, several solutions have been proposed
within IETF. Among those solutions, IPv6 is the only perennial
solution that should be implemented by service providers.
Nevertheless, this implementation won't be in one shot and the co-
existence between IPv4 and IPv6 should be managed for a while. In
addition to the co-existence issue, interconnection means to enable
successful communications between IPv4 and IPv6 realms must be
enforced.
In this context, BEHAVE WG is currently specifying translator
mechanisms which cover both stateful
[I-D.ietf-behave-v6v4-xlate-stateful] and stateless
[I-D.ietf-behave-v6v4-xlate] modes. The proposed solutions require
the definition of a new IPv4-mapped IPv6 address
[I-D.ietf-behave-address-format] which is used to represent an IPv4-
only host in an IPv6 realm. This type of addresses, when managed by
a translator, is to be considered as "fake" address since it is not
assigned to any host and can be confusing for the application. The
application querying for this address must be aware that the
application running on the host represented by the IPv4-mapped IPv6
address is connected through an IPv4 interface and may be not able to
use a reference (e.g., [I-D.carpenter-behave-referral-object]) to an
IPv6 address in the packet payload.
When an IPv4-mapped IPv6 address is used as destination address, the
traffic will be handled by a translator device and no direct
communication would be possible.
1.2. Contribution of this Draft
The aforementioned "fake" addresses should not be confused with
native IPv6 addresses in order to ease the enforcement of means to
avoid translators whenever possible. Notifying to the requesting
host that the resolved address is not a native address but an IPv4-
mapped IPv6 address (which is behind a NAT) would ease the local
policies to prefer direct communications (i.e., avoid using IPv4-
mapped IPv6 addresses when a native IPv6 address is available).
For the sake of maintaining the reliability of the information
maintained and sent by DNS and helping a given host to enforce
policies to prefer native communications, a new record type is
proposed (A64). This record type stores only IPv4-mapped IPv6
addresses. A new query type A64 is also defined to request A64
records or synthesised AAAA records as defined in
Boucadair & Burgey Expires April 22, 2010 [Page 4]
Internet-Draft A64 DNS Record October 2009
[I-D.ietf-behave-dns64].
1.3. Backward Compatibility Issue
The A64 record proposal suffers from DNS backward compatibility
issue. This issue is to be positioned in the following context:
o We are still in the early stages of IPv6 deployment;
o IPv4-mapped IPv6 addresses will be used in various architecture
configurations;
o DNS64 proposal as defined in [I-D.ietf-behave-dns64] may be used
for serving dual-stack hosts. DNS servers do not have any means
to restrict the use of the service based on the requesting
connectivity capabilities;
o [I-D.ietf-behave-dns64] does not define how to configure static
records using IPv4-mapped IPv6 addresses.
o Not all DNS servers are to be upgraded. Only a subset of DNS
servers may be updated to support the A64 records.
o A procedure for the discovery of these DNS A64-capable servers is
described in [I-D.boucadair-behave-dns64-discovery]. When
supported, only the appropriate DNS servers will be invoked.
o In some context, referral procedure should be aware about the type
of the remote party. This may help avoiding "some" ALGs in the
path.
2. IPv4-mapped IPv6 Record: A64
[I-D.ietf-behave-address-format] discusses issues related to how an
IPv4 host can be represented in the IPv6 realm. A new address format
is proposed. To store an IPv4-mapped IPv6 address
[I-D.ietf-behave-address-format], a new record type is defined.
2.1. A64 Record Type
The A64 resource record type is a record specific to the Internet
class that is destined to store a single IPv4-mapped IPv6 address.
A type value is to be assigned by IANA.
Boucadair & Burgey Expires April 22, 2010 [Page 5]
Internet-Draft A64 DNS Record October 2009
2.2. A64 Data Format
Same data format for as AAAA records [RFC3596].
2.3. A64 Query
An A64 query for a specified domain name in the Internet class
returns all associated A64 resource records in the answer section of
a response. As AAAA query type, a type A64 query does not perform
additional section processing.
2.4. Textual format of A64 records
Same as for AAAA records [RFC3596].
2.5. IP64.INT Domain
In order to not pollute IP6.INT domain with IPv4-inferred records, a
new domain SHOULD be defined.
The same requirements as those of IP6.INT are to be taken into
account for IP64.INT.
2.6. Modifications to Existing Query Types
All existing query types that perform type A and AAAA processing
SHOULD be updated to perform type A, AAAA and A64 processing.
Only AAAA records SHOULD be returned when AAAA only type is specified
in the query.
But during a transition phase, some hosts with IPv6-only connectivity
may not be updated to perform A64 queries. Specific IPv6 DNS
servers, called "A64-compliant DNS servers", may be used to serve
those hosts. A64-compliant DNS servers may return an A64 record as a
response to AAAA query if no AAAA record is available for the
specified resource (A64 are considered as AAAA records. This
behaviour advocates for enhancing the chance for a communication to
be established even through a translator). A64-compliant DNS servers
SHOULD not be used by dual-stack hosts which do not support A64 query
type. When A64 query type is received, only A64 record type MUST be
returned.
3. On the Need of a New Query type
In the context of IPv4-IPv6 co-existence, new query type(s) would be
required to achieve the following goals:
Boucadair & Burgey Expires April 22, 2010 [Page 6]
Internet-Draft A64 DNS Record October 2009
o Retrieve both A64 and AAAA records by issuing one single query;
o Retrieve both IPv4 and IPv6 records (i.e., A, A64 and AAAA)
records by issuing one single query;
A candidate solution is described in [I-D.li-dnsext-ipv4-ipv6].
4. IANA Considerations
A record TYPE is to be assigned by IANA.
5. Security Considerations
This document does not introduce any security threat to the DNS
system.
6. Acknowledgements
TBC
7. References
7.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
7.2. Informative Reference
[I-D.boucadair-behave-dns64-discovery]
Boucadair, M. and E. Burgey, "DNS64 Service Location and
Discovery, draft-boucadair-behave-dns64-discovery-00",
October 2009.
Boucadair & Burgey Expires April 22, 2010 [Page 7]
Internet-Draft A64 DNS Record October 2009
[I-D.carpenter-behave-referral-object]
Carpenter, B., Boucadair, M., Brim, S., Halpern, J.,
Jiang, S., and K. Moore, "A Generic Referral Object for
Internet Entities",
draft-carpenter-behave-referral-object-00 (work in
progress), May 2009.
[I-D.ietf-behave-address-format]
Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-00 (work in progress),
August 2009.
[I-D.ietf-behave-dns64]
Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
"DNS64: DNS extensions for Network Address Translation
from IPv6 Clients to IPv4 Servers",
draft-ietf-behave-dns64-00 (work in progress), July 2009.
[I-D.ietf-behave-v6v4-xlate]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-01 (work in
progress), September 2009.
[I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
Address and Protocol Translation from IPv6 Clients to IPv4
Servers", draft-ietf-behave-v6v4-xlate-stateful-02 (work
in progress), October 2009.
[I-D.li-dnsext-ipv4-ipv6]
Li, L., Li, Z., and X. Duan, "DNS Extensions to Support
IPv4 and IPv6", draft-li-dnsext-ipv4-ipv6-01 (work in
progress), July 2009.
Authors' Addresses
Mohamed Boucadair
France Telecom
3, Av Francois Chateau
Rennes, 35000
France
Email: mohamed.boucadair@orange-ftgroup.com
Boucadair & Burgey Expires April 22, 2010 [Page 8]
Internet-Draft A64 DNS Record October 2009
Eric Burgey
France Telecom
France
Email: eric.burgey@orange-ftgroup.com
Boucadair & Burgey Expires April 22, 2010 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 22:43:01 |