INTERNET-DRAFT Jim Bound
NGTRANS Tools Working Group Digital Equipment Corp
November 1997
No Network Address Translation (NNAT) for IPv6
<draft-ietf-ngtrans-nnat-00.txt>
Status of this Memo
This document is a submission by the Next Generation Transition
Working Group of the Internet Engineering Task Force (IETF).
Comments should be submitted to the ngtrans@sunroof.eng.sun.com
mailing list.
This document is an Internet-Draft. 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."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Abstract
The initial deployment of IPv6 will require a tightly coupled use of
IPv4 addresses to support the interoperation of IPv6 and IPv4. Nodes
will be able to be deployed with IPv6 addresses, but will still need
to communicate with IPv4 nodes that do not have a dual IP layer
supporting both IPv4 and IPv6. This specification defines a
mechanism called No Network Address Translation (NNAT), which will
assign an IPv6 node a temporary IPv4 address, which can be used to
communicate with a node that supports only IPv4.
Bound Expires May 1998 [Page 1]
INTERNET-DRAFT draft-ietf-ngtrans-nnat-00.txt November 1997
Table of Contents:
1. Introduction....................................................3
2. Terminology.....................................................3
2.1 IPv6 NNAT Terminology.......................................3
2.2 Specification Language......................................4
3. NNAT Design Model...............................................5
4. IPv4 Query of an IPv6 Node......................................5
4.1 Reaching the Site Primary DNS Server........................5
4.2 Relaying the A Record Query to the NNAT Server..............5
5. NNAT Server Processing of a DNS A Query.........................6
5.1 DNS and DHCPv6 Processing...................................6
5.2 Cleaning up the NNAT IPv4 Assigned Address..................7
5.3 Conceptual Model of an Implementation.......................7
6. DHCPv6 Reconfigure IPv4 Address Extension.......................7
7. Security Considerations.........................................8
8. Year 2000 Considerations........................................8
Appendix A - Open Issues...........................................8
Appendix B - Draft Changes and Rationale History...................8
Acknowledgements...................................................8
References.........................................................9
Authors' Address..................................................10
Bound Expires May 1998 [Page 2]
INTERNET-DRAFT draft-ietf-ngtrans-nnat-00.txt November 1997
1. Introduction
The initial deployment of IPv6 will require a tightly coupled use of
IPv4 addresses to support the interoperation of IPv6 and IPv4. Nodes
will be able to be deployed with IPv6 addresses, but will still need
to communicate with IPv4 nodes that do not have a dual IP layer
supporting both IPv4 and IPv6. This specification defines a
mechanism called No Network Address Translation (NNAT), which will
assign an IPv6 node a temporary IPv4 address, which can be used to
communicate with a node that supports only IPv4.
NNAT uses the DNS [2,9] mechanisms to resolve a query for an IPv6
node name by an IPv4 node that wishes to communicate with the IPv4
stack of an IPv6 node that supports both IPv6 and IPv4. The IPv6
node that is the object of such a query will be assigned a temporary
IPv4 address, thru DHCPv6 [4], and the IPv4 node performing the query
will receive the address assigned to the IPv6 node in the query
response. Communications between the two nodes can then begin
directly without any intermediate nodes performing Network Address
Translation [15] or Application Level Gateway [7] functions.
The reason for this specification is that users deploying IPv6 will
not want (and most likely will not be able) to assign IPv4 addresses
to IPv6 nodes as they are deployed into their site, because IPv4
addresses are a rare commodity. But, IPv4 addresses will be needed
to permit IPv6 nodes to communicate with IPv6 nodes, which can
support both IPv4 and IPv6 communications.
The specification will begin by defining the terminology (section 2),
then discuss the NNAT design model (section 3), then define the
mechanism used for an IPv4 node to query an IPv6 node (section 4),
then discuss the NNAT Server processing to support this mechanism
(section 5), and complete the mechanism by defining the DHCPv6
Extension needed to assign a temporary IPv4 address to an IPv6 node
(section 6). The specification then discusses Security (section 7)
and Year 2000 considerations (section 8). Appendix A will discuss
Open Issues that need to be discussed in the ngtrans Tools Working
Group and Appendix B will keep a historical account of changes to the
draft and rationale for those changes as they occur.
2. Terminology
2.1 IPv6 NNAT Terminology
IPv6 Protocol Terms: See [3]
IPv6 Transition Terms: See [16]
DHCPv6 Terms: See [4,5]
NNAT Server: A Server that supports DNS [2] and DHCPv6 [4,5]
and communications between DNS and DHCPv6, which
is implementation defined. See section 4 and 5.
Bound Expires May 1998 [Page 3]
INTERNET-DRAFT draft-ietf-ngtrans-nnat-00.txt November 1997
2.2 Specification Language
In this document, several words are used to signify the requirements
of the specification, in accordance with RFC 2119 [10]. These words
are often capitalized.
MUST This word, or the adjective "required", means that
the definition is an absolute requirement of the
specification.
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
SHOULD This word, or the adjective "recommended", means
that there may exist valid reasons in particular
circumstances to ignore this item, but the full
implications must be understood and carefully
weighed before choosing a different course.
Unexpected results may result otherwise.
MAY This word, or the adjective "optional", means that
this item is one of an allowed set of alternatives.
An implementation which does not include this option
MUST be prepared to interoperate with another
implementation which does include the option.
silently discard
The implementation discards the packet without
further processing, and without indicating an error
to the sender. The implementation SHOULD provide
the capability of logging the error, including the
contents of the discarded packet, and SHOULD record
the event in a statistics counter.
Bound Expires May 1998 [Page 4]
INTERNET-DRAFT draft-ietf-ngtrans-nnat-00.txt November 1997
3. NNAT Design Model
The design model assumes that NNAT MUST only be used to obtain a
temporary IPv4 address for an IPv6 node from the receipt of a DNS
query for a DNS A Type Relative Record [1,2]. If an IPv6 node needs
to obtain an IPv4 address to initiate communications, it SHOULD
locate that address using DHCPv4 [17], using its IPv4 stack.
For an IPv6 node to participate in the NNAT mechanism it MUST have a
dual IP layer, supporting both an IPv4 and IPv6 stack. This
specification makes the assumption that for IPv6 initial deployment
Host nodes will not ship an IPv6-only stack implementation. For
embedded system type nodes that support only an IPv6 stack NNAT
cannot be a solution.
It is beyond the scope of this specification to define the mechanisms
used to describe the variant routing configurations to verify that
IPv4 connectivity exists between the IPv6 node and the ingress or
egress points of the IPv6 nodes site, to communicate with the IPv4
node establishing communications. It is assumed that IPv4-in-IPv6
and IPv6-in-IPv4 configured and automatic tunnels can be used as
defined in other transition mechanism documents [13, 14, 16].
4. IPv4 Query of an IPv6 Node
NNAT supports IPv4 DNS querys from the Internet or within a site to
establish communications with an IPv6 node. An IPv4 node will not
necessarily know that it is trying to establish communications with
an IPv6 node. The IPv4 node will communicate with the IPv6 node by
first obtaining an IPv4 address for the IPv6 node as it does for any
other node (e.g. gethostbyname API).
4.1 Reaching the Site Primary DNS Server
The IPv4 DNS query will reach the Primary DNS Name Server for the
IPv6 node. It is implementation defined how the DNS query passes
thru a domains Firewall [7] to reach the IPv6 nodes Primary DNS
Server. This is a per user policy that is beyond the scope of this
specification.
4.2 Relaying the A Record Query to the NNAT Server
When the Primary DNS Server for the IPv6 node processes the IPv4
nodes query, it will do a lookup for that IPv6 node and find a
Route Through (RT) DNS Type Record [9]. The RT record will inform
the Primary DNS Server to forward the query to an intermediate DNS
Server, which will respond to the IPv4 node that made the original
query, after a temporary IPv4 address has been assigned to the
IPv6 node.
The intermediate DNS Server is also the NNAT Server.
Bound Expires May 1998 [Page 5]
INTERNET-DRAFT draft-ietf-ngtrans-nnat-00.txt November 1997
For Example:
IPv4 node "v4node.abc.com" querys for "v6node.xyz.com"
Query reaches Primary DNS Server for "v6node.xyz.com".
Primary DNS Server finds:
v6node.xyz.com IN RT 5 nnat6.xyz.com
Primary DNS Server forwards the query to "nnat6.xyz.com"
5. NNAT Server Processing of a DNS A Query
5.1 DNS and DHCPv6 Processing
At this point the NNAT Server has received the DNS query from the
Primary DNS Server. An NNAT Server MUST support both a DNS Server
and DHCPv6 Server implementation to perform the necessary NNAT
operations. The NNAT DNS Server will communicate to the DHCPv6
Server that an IPv6 node is being queried for an IPv4 address.
The DHCPv6 Server will look within its pool of IPv4 addresses for
NNAT IPv4 temporary addresses for assignment. If an address is
available the DHCPv6 Server will send a DHCPv6 Reconfigure Message
to the IPv6 node to temporarily assign the node an IPv4 address.
The DHCPv6 extension to this is defined in section 6.
Then the DHCPv6 Server MUST send a dynamic update to DNS [6] to
add an A type record to the Primary DNS Server, where the query
came from to the NNAT Server. The Time-To-Live (TTL) field in the
update MUST not be set to be greater than the lifetime (section 6)
for the IPv4 address assigned to the IPv6 node. The TTL value
will permit the A record to be cached for at least as long as the
lifetime.
Then the DHCPv6 Server MUST communicate to the NNAT DNS Server the
IPv4 address assigned to the IPv6 node.
Then the NNAT DNS Server responds to the query of the IPv4 node
with the IPv4 address of the IPv6 node.
When the query is received by the NNAT DNS Server and an IPv4
address cannot be assigned, the NNAT DNS Server MUST respond to
the IPv4 node that the IPv6 node A Record could not be found.
For Example:
NNAT DNS Server informs DHCPv6 it needs an IPv4 address
for v6node.xyz.com.
DHCPv6 Server assigns 15.131.12.6 to v6node.xyz.com thru
Bound Expires May 1998 [Page 6]
INTERNET-DRAFT draft-ietf-ngtrans-nnat-00.txt November 1997
the Reconfigure IPv4 Address Extension with a lifetime
of 5 hours.
DHCPv6 updates the Primary DNS Server:
v6node.xyz.com 18000 IN A 15.131.12.6 ; Explicit TTL cache for 5 hours
DHCPv6 Server informs NNAT DNS Server of the IPv4 Address.
NNAT DNS Server responds to "v4node.abc.com" query.
5.2 Cleaning up the NNAT IPv4 Assigned Address
Once the IPv4 address expires the DHCPv6 Server will permit the
IPv4 address to be reused. But before the address can be reused
the DHCPv6 Server MUST delete the IPv4 address from the Primary
DNS Server, thru the Dyanamic Updates to DNS mechanism.
5.3 Conceptual Model of an Implementation
A conceptual model (not part of this specification) for the NNAT
DNS Server and DHCPv6 Server to communicate could be a number of
mechanisms that support interprocess communications between two
processes (e.g. Threads, Local Domain Sockets, Shared Memory).
The IPv4 pool of addresses maintained by the DHCPv6 server is
implementation defined how that is obtained and configured as is
specified for IPv6 addresses in DHCPv6. Once the IPv4 address is
assigned it can be kept as part of the IPv6 nodes binding entry on
the DHCPv6 Server as other configuration data as specified in
DHCPv6.
6. DHCPv6 Reconfigure IPv4 Address Extension
The DHCPv6 Reconfigure IPv4 Address Extension provides an IPv6 DHCPv6
Client with a temporary IPv4 address.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
| (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
| (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD
Length: 8
IPv4 Address: 32bit IPv4 Address
Lifetime: Absolute Time in Seconds
Bound Expires May 1998 [Page 7]
INTERNET-DRAFT draft-ietf-ngtrans-nnat-00.txt November 1997
7. Security Considerations
The NNAT mechanism can use all the defined security specifications
for each functional part of the operation. For DNS the DNS Security
Extensions/Update can be used [11, 12], for DHCPv6 the DHCPv6
Authentication Message can be used [5], and for communications
between the IPv6 node, once it has an IPv4 address, and the remote
IPv4 node, IPSEC [8] can be used as NNAT does not break secure end-
to-end communications at any point in the mechanism.
8. Year 2000 Considerations
There are no Year 2000 issues in this specification.
Appendix A - Open Issues
- The draft does not speak of PTR records for the IPv6 node
A record once its created. But its only useful during the
lifetime of the assigned IPv4 address.
- RFC 1183 RT Record is Experimental and there is some concern
its obsolete. Though some implementations still support some
code for the RT record. Also the Route Through semantics
specified may need to strongly state the query is passed thru
to the NNAT server. This needs to be discussed.
- The Primary Server must look for the IPv6 node A record first
before finding the RT record. This needs to be verified
as an implementation issue.
- WHen the NNAT Server responds to the query it may not be
authorative. This needs to be verified and checked.
Appendix B - Draft Changes and Rationale History
None at this time.
Acknowledgements
The author would like to thank Erik Nordmark for spending time
working with him on this idea and suggesting the use of the DHCPv6
Reconfigure Message, Gerd Hoelzing for suggesting the use of the DNS
RT Record, and Robert Watson who suggested that the NNAT DHCPv6 and
DNS Server be co-located.
Bound Expires May 1998 [Page 8]
INTERNET-DRAFT draft-ietf-ngtrans-nnat-00.txt November 1997
References
[1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[2] Mockapetris, P., "Domain Names - Implementation and Specifica-
tion", STD 13, RFC 1035, USC/Information Sciences Institute,
November 1987.
[3] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Architecture", RFC 1883, December 1995.
[4] J. Bound and C. Perkins. Dynamic Host Configuration Protocol
for IPv6. draft-ietf-dhc-dhcpv6-11.txt November 1997 (work
in progress).
[5] C. Perkins. Extensions for the Dynamic Host Configuration
Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-08.txt November
1997. (work in progress).
[6] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates
to the Domain Name System (DNS). RFC 2136, April 1997.
[7] William R. Cheswick and Steven Bellovin. Firewalls and Internet
Security. Addison-Wesley, Reading, MA 1994 (ISBN:
0-201-63357-4).
[8] IPSEC *TBD* - This needs to include the Arch, Auth, and ESP specs.
[9] C. Everhart, L. Mamakos, R. Ullmann, P. Mockapetris. New
DNS RR Definitions, RFC 1183, October 1990.
[10] S. Bradner. Key words for use in RFCs to indicate Requirment
Levels. RFC 2119, March 1997.
[11] D. Eastlake and C. Kaufman. Domain Name System Security
Extensions. RFC 2065, January 1997.
[12] D. Eastlake. Secure Domain Name System Dynamic Update.
RFC 2137, April 1997.
[13] R. Callon and D. Haskins. Routing Aspects Of IPv6 Transition
RFC 2185, September 1997.
[14] A. Conta and S. Deering. Generic Packet Tunneling in IPv6.
draft-ietf-ipngwg-ipv6-tunnel-07.txt. December 1996.
(work in progress)
[15] E. Nordmark. IPv4/IPv6 Stateless Header Translator
draft-ietf-ngtrans-header-trans-00.txt. July 1997.
(work in progress)
[16] R. Gilligan and E. Nordmark. Transition Mechanisms for IPv6
Hosts and Routers. RFC 1933, April 1996.
[17] R. Droms. Dynamic Host Configuration Protocol.
RFC 2131, March 1997.
Bound Expires May 1998 [Page 9]
INTERNET-DRAFT draft-ietf-ngtrans-nnat-00.txt November 1997
Authors' Address
Jim Bound
Digital Equipment Corporation
110 Spitbrook Road, ZKO3-3/U14
Nashua, NH 03062
Phone: (603) 881-0400
Email: bound@zk3.dec.com
Bound Expires May 1998 [Page 10]