[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-korhonen-behave-nat64-learn-analysis) 00 01 02 03 RFC 7051

Behavior Engineering for Hindrance                      J. Korhonen, Ed.
Avoidance (BEHAVE)                                Nokia Siemens Networks
Internet-Draft                                        T. Savolainen, Ed.
Intended status: Informational                                     Nokia
Expires: September 8, 2012                                 March 7, 2012


     Analysis of solution proposals for hosts to learn NAT64 prefix
             draft-ietf-behave-nat64-learn-analysis-03.txt

Abstract

   Hosts and applications may benefit from the knowledge if an IPv6
   address is synthesized, which would mean a NAT64 is used to reach the
   IPv4 network or Internet.  This document analyses a number of
   proposed solutions for communicating whether the synthesis is taking
   place, used address format, and the IPv6 prefix used by the NAT64 and
   DNS64.  The solutions enable both NAT64 avoidance and intentional
   utilization by allowing local IPv6 address synthesis.  The document
   concludes by recommending selection of heuristic discovery based
   solution.

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 September 8, 2012.

Copyright Notice

   Copyright (c) 2012 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



Korhonen & Savolainen   Expires September 8, 2012               [Page 1]

Internet-Draft            Learning NAT64 prefix               March 2012


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Proposed solutions to learn about synthesis and
       Network-Specific Prefix  . . . . . . . . . . . . . . . . . . .  8
     5.1.  DNS Query for a Well-Known Name  . . . . . . . . . . . . .  8
       5.1.1.  Solution description . . . . . . . . . . . . . . . . .  8
       5.1.2.  Analysis and discussion  . . . . . . . . . . . . . . .  8
       5.1.3.  Summary  . . . . . . . . . . . . . . . . . . . . . . .  9
     5.2.  EDNS0 option indicating AAAA Record synthesis and
           format . . . . . . . . . . . . . . . . . . . . . . . . . .  9
       5.2.1.  Solution description . . . . . . . . . . . . . . . . .  9
       5.2.2.  Analysis and discussion  . . . . . . . . . . . . . . .  9
       5.2.3.  Summary  . . . . . . . . . . . . . . . . . . . . . . . 10
     5.3.  EDNS0 flags indicating AAAA Record synthesis and format  . 11
       5.3.1.  Solution description . . . . . . . . . . . . . . . . . 11
       5.3.2.  Analysis and discussion  . . . . . . . . . . . . . . . 11
       5.3.3.  Summary  . . . . . . . . . . . . . . . . . . . . . . . 12
     5.4.  DNS Resource Record for IPv4-Embedded IPv6 address . . . . 12
       5.4.1.  Solution description . . . . . . . . . . . . . . . . . 12
       5.4.2.  Analysis and discussion  . . . . . . . . . . . . . . . 12
       5.4.3.  Summary  . . . . . . . . . . . . . . . . . . . . . . . 13
     5.5.  Learning the IPv6 Prefix of a Network's NAT64 using DNS  . 13
       5.5.1.  Solution description . . . . . . . . . . . . . . . . . 13
       5.5.2.  Analysis and discussion  . . . . . . . . . . . . . . . 14
       5.5.3.  Summary  . . . . . . . . . . . . . . . . . . . . . . . 15
     5.6.  Learning the IPv6 Prefix of a Network's NAT64 using
           DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 15
       5.6.1.  Solution description . . . . . . . . . . . . . . . . . 15
       5.6.2.  Analysis and discussion  . . . . . . . . . . . . . . . 16
       5.6.3.  Summary  . . . . . . . . . . . . . . . . . . . . . . . 16
     5.7.  Learning the IPv6 Prefix of a Network's NAT64 using
           Router Advertisements  . . . . . . . . . . . . . . . . . . 17
       5.7.1.  Solution description . . . . . . . . . . . . . . . . . 17
       5.7.2.  Analysis and discussion  . . . . . . . . . . . . . . . 17
       5.7.3.  Summary  . . . . . . . . . . . . . . . . . . . . . . . 18
     5.8.  Using application layer protocols such as STUN . . . . . . 18
       5.8.1.  Solution description . . . . . . . . . . . . . . . . . 18



Korhonen & Savolainen   Expires September 8, 2012               [Page 2]

Internet-Draft            Learning NAT64 prefix               March 2012


       5.8.2.  Analysis and discussion  . . . . . . . . . . . . . . . 18
       5.8.3.  Summary  . . . . . . . . . . . . . . . . . . . . . . . 20
     5.9.  Learning the IPv6 Prefix of a Network's NAT64 using
           Access Technology Specific Methods . . . . . . . . . . . . 20
       5.9.1.  Solution description . . . . . . . . . . . . . . . . . 20
       5.9.2.  Analysis and discussion  . . . . . . . . . . . . . . . 20
       5.9.3.  Summary  . . . . . . . . . . . . . . . . . . . . . . . 21
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
     11.2. Informative References . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25



































Korhonen & Savolainen   Expires September 8, 2012               [Page 3]

Internet-Draft            Learning NAT64 prefix               March 2012


1.  Introduction

   Hosts and applications may benefit from the knowledge of whether an
   IPv6 address is synthesized, which would mean a NAT64 is used to
   reach the IPv4 network or Internet.  There are two issues that can be
   addressed with solutions that allow hosts and applications to learn
   the Network Specific Prefix (NSP) [RFC6052] used by the NAT64
   [RFC6146] and the DNS64 [RFC6147] devices.

   Firstly, finding out whether a particular address is synthetic and
   therefore learning the presence of a NAT64.  For example, a Dual-
   Stack (DS) host with IPv4 connectivity could use this information to
   bypass NAT64 and use native IPv4 transport for destinations that are
   reachable through IPv4.  We will refer this as 'Issue #1' throughout
   the document.

   Secondly, to find out how to construct from an IPv4 address an IPv6
   address that will be routable to/by the NAT64.  This is useful when
   IPv4 literals can be found in the payload of some protocol or
   applications do not use DNS to resolve names to addresses but know
   the IPv4 address of the destination by some other means.  We will
   refer this as 'Issue #2' throughout the document.

   Additionally, three other issues have to be considered by a solution
   addressing the first two issues: whether DNS is required 'Issue #3',
   whether a solution supports changing NSP 'Issue #4', and whether
   multiple NSPs are supported (either of the same or different length)
   for load-balancing purposes 'Issue #5'.

   This document analyses all known solution proposals known at the time
   of writing for communicating if the synthesis is taking place, used
   address format, and the IPv6 prefix used by the NAT64 and DNS64.
   Based on the analysis we conclude whether the issue of learning the
   Network-Specific Prefix is worth solving and what would be the
   recommended solution(s) in that case.


2.  Terminology

   Address Synthesis

      Address synthesis is a mechanism, in the context of this document,
      where an IPv4 address is represented as an IPv6 address understood
      by a NAT64 device.  The synthesized IPv6 address is formed by
      embedding an IPv4 address as-is into an IPv6 address prefixed with
      a NSP/WKP.  It is assumed that the 'unused' suffix bits of the
      synthesized address are set to zero as described in Section 2.2 of
      [RFC6052].



Korhonen & Savolainen   Expires September 8, 2012               [Page 4]

Internet-Draft            Learning NAT64 prefix               March 2012


   DNS64

      DNS extensions for network address translation from IPv6 clients
      to IPv4 servers: A network entity that synthesizes IPv6 addresses
      and AAAA records out of IPv4 addresses and A records, hence making
      IPv4 namespaces visible into IPv6 namespace.  DNS64 uses NSP
      and/or WKP in the synthesis process.

   NAT64

      Network Address and protocol Translation mechanism for translating
      IPv6 packets to IPv4 packets and vice-versa: A network entity that
      a host or an application may want to either avoid or utilize.
      IPv6 packets hosts send to addresses in the NSP and/or WKP are
      routed to NAT64.

   NSP

      Network-Specific Prefix: A prefix chosen by network administrator
      for NAT64/DNS64 to present IPv4 addresses in IPv6 namespace.

   WKP

      Well-Known Prefix: A prefix (64:ff9b::/96) chosen by IETF and
      configured by a network administrator for NAT64/DNS64 to present
      IPv4 addresses in IPv6 namespace.


3.  Issues

   This document analyses different solutions with a focus to following
   five issues:

   Issue #1

      The problem of distinguishing between a synthesized and a real
      IPv6 addresses, which allows a host to learn the presence of a
      NAT64 in the network.

   Issue #2

      The problem of learning the NSP used by the access network and
      needed for local IPv6 address synthesis.

   Issue #3

      The problem of learning the NSP or WKP used by the access network
      by a host not implementing DNS (hence applications are unable to



Korhonen & Savolainen   Expires September 8, 2012               [Page 5]

Internet-Draft            Learning NAT64 prefix               March 2012


      use DNS to learn prefix).

   Issue #4

      The problem of supporting changing NSP.  The NSP learned by the
      host may become stale for multiple reasons.  For example, the host
      might move to a new network that uses different NSP, thus making
      the previously learned NSP stale.  Also, the NSP used in the
      network may be changed due administrative reasons, thus again
      making previously learned NSP stale.

   Issue #5

      The problem of supporting multiple NSPs.  A network may be
      configured with multiple NSPs for address synthesis.  For example,
      for load-balancing purposes each NAT64 device in the same network
      could be assigned with their own NSP.  It should be noted that
      learning a single NSP is enough for an end host to successfully
      perform local IPv6 address synthesis but to avoid NAT64 the end
      host needs to learn all NSPs used by the access network.


4.  Background

   Certain applications, operating in protocol translation scenarios,
   can benefit from knowing the IPv6 prefix used by a local NAT64 of the
   attached access network.  This applies to the Framework document
   [RFC6144] Scenario 1 ("IPv6 network to IPv4 Internet"), Scenario 5
   ("An IPv6 network to an IPv4 network"), and Scenario 7 ("The IPv6
   Internet to the IPv4 Internet").  Scenario 3("The IPv6 Internet to an
   IPv4 network") is not considered applicable herein as in that case a
   NAT64 is located at the front of remote IPv4 network and host in IPv6
   Internet can benefit very little of learning NSP IPv6 prefix used by
   the remote NAT64.  The NAT64 prefix can be either a Network Specific
   Prefix (NSP) or the Well-known Prefix (WKP).  Below is (an
   incomplete) list of various use cases where it is beneficial for a
   host or an application to know the presence of a NAT64 and the NSP/
   WKP:

   o  Host-based DNSSEC validation: as is documented in DNS64 [RFC6147]
      section 5.5. point 3, synthetic AAAA records cannot be
      successfully validated in a host.  In order to utilize NAT64 a
      security-aware and validating host has to perform DNS64 function
      locally and hence it has to be able to learn WKP or proper NSP.

   o  Protocols that use IPv4 literals: in IPv6-only access native IPv4
      connections cannot be created.  If a network has NAT64 it is
      possible to synthesize IPv6 address by combining the IPv4 literal



Korhonen & Savolainen   Expires September 8, 2012               [Page 6]

Internet-Draft            Learning NAT64 prefix               March 2012


      and the IPv6 prefix used by NAT64.  The synthesized IPv6 address
      can then be used to create an IPv6 connection.

   o  Multicast translation, as described on Internet Drafts contributed
      to behave WG called "An IPv4 - IPv6 multicast translator" by Stig
      Venaas, Hitoshi Asaeda, Shinsuke Suzuki, and Tomohiro Fujisaki at
      December 2010 and "Framework for IPv4/IPv6 Multicast Translation"
      by Stig Venaas, Xing Li, and Congxiao Bao at June 2011.

   o  URI schemes with host IPv4 address literals rather than domain
      names (e.g., http://192.0.2.1, ftp://192.0.2.1, imap://192.0.2.1,
      ipp://192.0.2.1)): a host can synthesize IPv6 address out of the
      literal in URI and use IPv6 to create connection through NAT64.

   o  Updating host's [RFC3484] preference table to prefer native
      prefixes over translated prefixes: this is useful as applications
      are more likely able to traverse through NAT44 than NAT64.

   DNS64 cannot serve applications that are not using DNS or that obtain
   referral as an IPv4 literal address.  One example application is the
   Session Description Protocol (SDP) [RFC4566], as used by Real Time
   Streaming Protocol (RTSP) [RFC2326] and Session Initiation Protocol
   (SIP) [RFC3261].  Other example applications include web browsers, as
   IPv4 address literals are still encountered in web pages and URLs.
   Some of these applications could still work through NAT64, provided
   they were able to create locally valid IPv6 presentations of peers'
   IPv4 addresses.

   It is a known issue that passing IP address referrals, often fails in
   today's Internet, as described in "Problem Statement for Referral"
   draft submitted to the IETF by Brian Carpenter in February 2011.
   Synthesizing IPv6 addresses does not necessarily make the situation
   any better as the synthesized addresses utilizing NSP are not
   distinguishable from public IPv6 addresses for the referral receiver.
   However, the situation is not really any different from the current
   Internet as using public addresses does not really guarantee
   reachability (for example due firewalls).  A node 'A' behind NAT64
   may detect it is talking to a node 'B' through NAT64, in which case
   the node 'A' may want to avoid passing its IPv6 address as a referral
   to the node 'B'.  The node 'B' on the IPv4 side of the NAT64 should
   not see the IPv6 address of a node 'A' from the IPv6 side of NAT64,
   and hence the node 'B' should not be able to pass IPv6 address
   referral to a node 'C'.  Passing IPv4 presentation of the IPv6
   address of the host 'A' to the node 'C' is bound to similar problems
   as passing a public IPv4 address of a host behind NAT44 as a
   referral.  This analysis focuses on detecting NAT64 presence from the
   IPv6 side of NAT64.




Korhonen & Savolainen   Expires September 8, 2012               [Page 7]

Internet-Draft            Learning NAT64 prefix               March 2012


5.  Proposed solutions to learn about synthesis and Network-Specific
    Prefix

5.1.  DNS Query for a Well-Known Name

5.1.1.  Solution description

   Section 3 of [I-D.ietf-behave-nat64-discovery-heuristic] describes a
   host behavior for discovering the presence of a DNS64 server and a
   NAT64 device, and heuristics for discovering the used NSP.  A host
   requiring information for local IPv6 address synthesis or for NAT64
   avoidance sends a DNS query for an AAAA record of a Well-Known IPv4-
   only Fully Qualified Domain Name (FQDN).  If a host receives a
   negative reply, it knows there are no DNS64 and NAT64 in the network.

   If a host receives AAAA reply, it knows the network must be utilizing
   IPv6 address synthesis.  After receiving a synthesized AAAA Resource
   Record, the host may examine the received IPv6 address and use
   heuristics, such as "subtracting" the known IPv4 address out of
   synthesized IPv6 address, to find out the NSP.

   The Well-Known Name may be assigned by IANA or provided some third
   party, including application or operating system vendor.  The IPv4
   address corresponding to the Well-Known Name may be resolved via A
   query to Well-Known Name, assigned by IANA, or hard-coded.

5.1.2.  Analysis and discussion

   The PROs of the proposal are listed below:

   +  Can be used to solve Issue #1 and Issue #2.

   +  Solves issue #4 via DNS record lifetime.

   +  Can partially solve issue #5 if multiple synthetic AAAA records
      are included in the response.  Can find multiple address formats.

   +  Does not necessarily require any standards effort.

   +  Does not require host stack or resolver changes.  All required
      logic and heuristics can be implemented in applications that are
      interested in learning about address synthesis taking place.

   +  The solution is backward compatible from 'legacy' hosts and
      servers point of view.






Korhonen & Savolainen   Expires September 8, 2012               [Page 8]

Internet-Draft            Learning NAT64 prefix               March 2012


   +  Hosts or applications interested in learning about synthesis and
      the used NSP can do the "discovery" proactively at any time, for
      example every time the host attaches to a new network.

   +  Does not require explicit support from the network using NAT64

   The CONs of the proposal are listed below:

   -  Requires hosting of a DNS resource record for the Well-Known Name.

   -  Does not provide solution for issue #3.

   -  This method is only able to find one NSP even if a network is
      utilizing multiple NSPs (issue #5) (unless DNS64 includes multiple
      synthetic AAAA records in response).

5.1.3.  Summary

   This is the only approach that can be deployed without explicit
   support from the network or the host.  This approach could also
   complement explicit methods and be used as a fallback approach when
   explicit methods are not supported by an access network.

5.2.  EDNS0 option indicating AAAA Record synthesis and format

5.2.1.  Solution description

   The third revision of "EDNS0 Option for Indicating AAAA Record
   Synthesis and Format", a draft document submitted to the behave WG in
   February 2011 by Jouni Korhonen and Teemu Savolainen, defined a new
   EDNS0 option [RFC2671], which contained 3 flag bits (called SY-bits).
   The EDNS0 option served as an implicit indication of the presence of
   DNS64 server and the NAT64 device.  The EDNS0 option SY-bit values
   other than '000' and '111' explicitly told the NSP prefix length.
   Only the DNS64 server could insert the EDNS0 option and the required
   SY-bits combination into the synthesized AAAA Resource Record.

5.2.2.  Analysis and discussion

   The PROs of the proposal are listed below:

   +  Can be used to solve Issue #1 and is designed to explicitly solve
      Issue #2.

   +  Solves issue #4 via DNS record lifetime.






Korhonen & Savolainen   Expires September 8, 2012               [Page 9]

Internet-Draft            Learning NAT64 prefix               March 2012


   +  Can partially solve issue #5 if multiple synthetic AAAA records
      are included in the response and all use same format.

   +  The solution is backward compatible from 'legacy' hosts and
      servers point of view.

   +  Even if the solution is bundled with DNS queries and responses, a
      standardization of a new DNS record type is not required, rather
      just defining a new EDNS0 option.

   +  EDNS0 option implementation requires changes only to DNS64
      servers.

   +  Does not require additional provisioning or management as the
      EDNS0 option is added automatically by the DNS64 server to the
      responses.

   +  Does not involve additional queries towards the global DNS
      infrastructure as EDNS0 logic can be handled within the DNS64
      server.

   The CONs of the proposal are listed below:

   -  Requires end hosts to support [RFC2671] EDSN0 extension mechanism.

   -  Requires host resolver changes and a mechanism/additions to the
      host resolver API (or flags, hints etc) to deliver a note to the
      querying application that the address is synthesized and what is
      the NSP prefix length.

   -  Requires a modification to DNS64 servers to include the EDNS0
      option to the synthesized responses.

   -  Does not provide solution for issue #3.

5.2.3.  Summary

   The EDNS0 option based solution works by extending the existing EDNS0
   Resource Record.  Although the solution has host resolver and DNS64
   server impacts, the changes are limited to those entities (end host,
   applications) that are interested in learning the presence of NAT64
   and the used NAT64 prefix.  The provisioning and management overhead
   is minimal if not non-existent as the EDNS0 options are synthesized
   in a DNS64 server in a same manner as the synthesized AAAA Resource
   Records.  Moreover, EDNS0 does not induce any load to DNS servers
   because no new RRType query is defined.





Korhonen & Savolainen   Expires September 8, 2012              [Page 10]

Internet-Draft            Learning NAT64 prefix               March 2012


5.3.  EDNS0 flags indicating AAAA Record synthesis and format

5.3.1.  Solution description

   The first revision of "EDNS0 Flags Indicating AAAA Record Synthesis
   and Format", a draft document submitted to the behave WG in July 2010
   by Jouni Korhonen and Teemu Savolainen, defined 3 new flag bits
   (called SY-bits) into EDNS0 OPT [RFC2671] header, which served as an
   implicit indication of the presence of DNS64 server and a NAT64
   device.  SY-bit values other than '000' or '111' explicitly told the
   NSP prefix length.  Only the DNS64 server could insert the EDNS0
   option and the required SY-bits combination into the synthesized AAAA
   Resource Record.

5.3.2.  Analysis and discussion

   The PROs of the proposal are listed below:

   +  Can be used to solve Issue #1 and is designed to explicitly solve
      Issue #2.

   +  Solves issue #4 via DNS record lifetime.

   +  Can partially solve issue #5 if multiple synthetic AAAA records
      are included in the response and all use same format.

   +  The solution is backward compatible from 'legacy' hosts and
      servers point of view.

   +  EDNS0 option implementation requires changes only to DNS64
      servers.

   +  Does not require additional provisioning or management as the
      EDNS0 option is added automatically by the DNS64 server to the
      responses.

   +  Does not involve additional queries towards the global DNS
      infrastructure as EDNS0 logic can be handled within the DNS64
      server.

   The CONs of the proposal are listed below:

   -  Requires end hosts to support [RFC2671] EDSN0 extension mechanism.

   -  Consumes scarce flag bits from EDNS0 OPT header.






Korhonen & Savolainen   Expires September 8, 2012              [Page 11]

Internet-Draft            Learning NAT64 prefix               March 2012


   -  Requires a host resolver changes and a mechanism/additions to the
      host resolver API (or flags, hints etc) to deliver a note to the
      querying application that the address is synthesized and what is
      the NSP prefix length.

   -  Requires a modification to DNS64 servers to include the EDNS0
      option to the synthesized responses.

   -  Does not provide solution for issue #3.

5.3.3.  Summary

   This option is included here for the sake of completeness.  The
   consumption of three bits of the limited EDNS0 OPT space can be
   considered unfavorable and hence is unlikely to be accepted.

5.4.  DNS Resource Record for IPv4-Embedded IPv6 address

5.4.1.  Solution description

   An Internet Draft titled "A64: DNS Resource Record for IPv4-Embedded
   IPv6 Address" by Mohamed Boucadair and Eric Burgey that was
   contributed to behave WG at September 2010 proposed a new DNS
   Resource Record (A64) that would be a record dedicated to storing a
   single IPv4-Embedded IPv6 address [RFC6052].  Use of a dedicated
   Resource Record would allow a host to distinguish between real IPv6
   addresses and synthesized IPv6 addresses.  The solution requires host
   to send a query for an A64 record.  Positive answer with A64 record
   informs the requesting host that the resolved address is not a native
   address but an IPv4-Embedded IPv6 address.  This would ease the local
   policies to prefer direct communications (i.e., avoid using IPv4-
   Embedded IPv6 addresses when a native IPv6 address or a native IPv4
   address is available).  Applications may be notified via new or
   modified API.

5.4.2.  Analysis and discussion

   The PROs of the proposal are listed below:

   +  Can be used to solve Issue #1 and #5.

   +  Solves issue #4 via DNS record lifetime.

   +  The solution is backward compatible from 'legacy' hosts and
      servers point of view.






Korhonen & Savolainen   Expires September 8, 2012              [Page 12]

Internet-Draft            Learning NAT64 prefix               March 2012


   +  Synthesized addresses can be used in authoritative DNS servers.

   +  Maintains the reliability of the DNS model (i.e., a synthesised
      IPv6 address is presented as such and not as native IPv6 address).

   +  When both IPv4-Converted and native IPv6 addresses are configured
      for the same QNAME, native addresses are preferred.

   The CONs of the proposal are listed below:

   -  Does not address Issue #2 or #3 in any way.

   -  Requires a host resolver changes and a mechanism/additions to the
      host resolver API (or flags, hints etc) to deliver a note to the
      querying application that the address is synthesized.

   -  Requires a standardization of a new DNS Resource Record type
      (A64), and the implementation of it in both resolvers and servers.

   -  Requires a coordinated deployment between different flavors of DNS
      servers within the provider to work deterministically.

   -  Additional load the DNS servers (3 Queries, A64, AAAA and A, may
      be issued by a dual-stack host).

   -  Does not help to identify synthesized IPv6 addresses if the
      session does not involve any DNS queries.

5.4.3.  Summary

   While the proposed solution delivers explicit information about
   address synthesis taking place solving the Issue #1, a
   standardization of a new DNS record type might turn out a too
   overwhelming task for a solution for a temporary transition phase.
   Defining a new record type increases load towards DNS server as the
   host issues parallel A64, AAAA and A queries.

5.5.  Learning the IPv6 Prefix of a Network's NAT64 using DNS

5.5.1.  Solution description

   Revision four of "Learning the IPv6 Prefix of a Network's IPv6/IPv4
   Translator", a draft document submitted to the behave WG in October
   2009 by Dan Wing, proposed two DNS-based methods for discovering the
   presence of a DNS64 server and a NAT64 device, and then a mechanism
   for discovering the used NSP.

   Firstly, the document proposed that a host may learn the presence of



Korhonen & Savolainen   Expires September 8, 2012              [Page 13]

Internet-Draft            Learning NAT64 prefix               March 2012


   a DNS64 server and a NAT64 device, by receiving a TXT Resource Record
   with a well-known string (that document proposes to be reserved by
   IANA) followed by the NAT64 unicast IPv6 address and the prefix
   length.  The DNS64 server would add the TXT Resource Record into the
   DNS response.

   Secondly, the document proposed specifying a new U-NAPTR [RFC4848]
   application to discover the NAT64's IPv6 prefix and length.  The
   input domain name is exactly the same as would be used for a reverse
   DNS lookup, derived from the host's IPv6 in the ".ip6.arpa." tree.
   The host doing the U-NAPTR queries may need multiple queries until
   the host finds the provisioned domain name with the correct prefix
   length.  The response to a successful U-NATPR query contains the
   unicast IPv6 address and the prefix length of the NAT64 device.

5.5.2.  Analysis and discussion

   The PROs of the proposal are listed below:

   +  Can be used to solve Issue #1 and Issue #2.

   +  Solves issue #4 via DNS record lifetime.

   +  Does not require host stack or resolver changes if the required
      logic and heuristics is implemented in applications that are
      interested in learning about address synthesis taking place.

   The CONs of the proposal are listed below:

   -  Requires standardization of a well-known name by IANA for TXT
      Resource Record and/or a standardization of a new U-NAPTR
      application.

   -  Requires a host resolver changes and a mechanism/additions to the
      host resolver API (or flags, hints etc) to deliver a note to the
      querying application that the address is synthesized and what is
      the NSP prefix length.  However, it is possible that the U-NAPTR
      application logic is completely implemented by the application
      itself as noted in PROs list.

   -  U-NAPTR prefix learning method may entail multiple queries.

   -  U-NAPTR prefix learning method requires provisioning of NSPs in
      ".ip6.arpa." tree.







Korhonen & Savolainen   Expires September 8, 2012              [Page 14]

Internet-Draft            Learning NAT64 prefix               March 2012


   -  RFC5507 [RFC5507] specifically recommends against reusing TXT
      Resource Records to expand DNS.

   -  Requires configuration on the access network's DNS servers.

   -  Does not provide solution for issue #3.

   If TXT record would include multiple NSPs issue #5 could be solved as
   well, but only if nodes as a group would select different NSPs hence
   supporting load-balancing.  As this is not clear this item is not yet
   listed under PRO or CON.

5.5.3.  Summary

   The implementation of this solution requires some changes to the
   applications and resolvers in a similar fashion as in solutions in
   Section 5.2, Section 5.3 and Section 5.4.  Unlike the other DNS-based
   approaches, the U-NAPTR-based solution also requires provisioning
   information into the '.ip6.arpa.' tree which is not any more entirely
   internal to the provider hosting the NAT64/DNS64 service.

   The iterative approach of learning the NAT64 prefix in U-NAPTR-based
   solution may result in multiple DNS queries, which can be considered
   more complex and inefficient compared to other DNS-based solutions.

5.6.  Learning the IPv6 Prefix of a Network's NAT64 using DHCPv6

5.6.1.  Solution description

   Two individual IETF Internet-Draft contributions specified DHCPv6
   based approaches.

   "Learning the IPv6 Prefix of a Network's IPv6/IPv4 Translator", a
   draft document submitted to the behave WG in October 2009 by Dan
   Wing, described a new DHCPv6 [RFC3315] option
   (OPTION_AFT_PREFIX_DHCP) that would contain the IPv6 unicast prefix,
   IPv6 ASM prefix, and IPv6 SSM prefix (and their lengths) for the
   NAT64.

   "Dynamic Host Configuration Protocol (DHCPv6) Options for Shared IP
   Addresses Solutions", a draft document submitted to the behave WG in
   December 2009 by Mohamed Boucadair, Pierre Levis, Jean-Luc Grimault,
   Teemu Savolainen, and Gabor Bajko, proposed a DHCPv6 option that
   could be used to communicate to a requesting host the prefix used for
   building IPv4-Converted IPv6 addresses together with the format type
   and therefore also the used address synthesis algorithm.
   Provisioning the format type is required so as to be correctly
   handled by the NAT64-enabled devices deployed in a given domain.



Korhonen & Savolainen   Expires September 8, 2012              [Page 15]

Internet-Draft            Learning NAT64 prefix               March 2012


5.6.2.  Analysis and discussion

   The PROs of the proposal are listed below:

   +  Can be used to solve Issue #1, Issue #2, Issue #3 and Issue #4 via
      DHCPv6 information lifetime.

   +  Does not involve DNS system.  Therefore, applications that would
      not normally initiate any DNS queries can still learn the NAT64
      prefix.

   +  DHCPv6 is designed to provide various kinds of configuration
      information in a centrally managed fashion.

   The CONs of the proposal are listed below:

   -  Change of NSP requires change to DHCPv6 configuration.

   -  Requires at least Stateless DHCPv6 client on hosts.

   -  Requires support on DHCPv6 clients, which is not trivial in all
      operating systems.

   -  The DHCPv6-based solution involves changes and management on
      network side nodes that are not really part of the NAT64/DNS64
      deployment (or issues caused by their existence).

   -  A new DHCPv6 option is required and the corresponding changes to
      both DHCPv6 clients and servers.

   If DHCPv6 would include multiple NSPs issue #5 could be solved as
   well, but only if nodes as a group would select different NSPs hence
   supporting load-balancing.  As this is not clear this item is not yet
   listed under PRO or CON.

5.6.3.  Summary

   The DHCPv6-based solution would be a good solution in a sense it
   hooks into general IP configuration phase, allows easy updates when
   configuration information changes and does not involve DNS in
   general.  Use of DHCPv6 requires configuration changes on DHCPv6
   clients and servers and in some cases may also require implementation
   changes.  Furthermore, it is not obvious that all devices that need
   translation services would implement stateless DHCPv6.  For example,
   cellular 3GPP networks do not mandate hosts or network to implement
   or deploy DHCPv6.





Korhonen & Savolainen   Expires September 8, 2012              [Page 16]

Internet-Draft            Learning NAT64 prefix               March 2012


5.7.  Learning the IPv6 Prefix of a Network's NAT64 using Router
      Advertisements

5.7.1.  Solution description

   Revision three of "Learning the IPv6 Prefixes of an IPv6/IPv4
   Translator", a draft document submitted to the behave WG in July 2009
   by Dan Wing, Xuewei Wang, and Xiaohu Xu, described a new Router
   Advertisement (RA) [RFC4861] option (OPTION_AFT_PREFIX_RA) that would
   contain the IPv6 unicast prefix, IPv6 ASM prefix, and IPv6 SSM prefix
   (and their lengths) for the NAT64.  The RA option is essentially the
   same as for DHCPv6 discussed in Section 5.6.

5.7.2.  Analysis and discussion

   The PROs of the proposal are listed below:

   +  Can be used to solve Issue #1, Issue #2, and Issue #3.

   +  Can solve Issue #4 if lifetime information can be communicated.

   The CONs of the proposal are listed below:

   -  Requires configuration and managements of all access routers to
      emit correct information in RA.  This could, for example, be
      accomplished somehow by piggybacking on top of routing protocols
      (which would then require enhancements to routing protocols)

   -  In some operating systems it may not be trivial to transfer
      information obtained in RA to upper layers

   -  Requires changes to host operating system's IP stack

   -  NSP change requires changes to access router configuration

   -  Requires standardization of a new option to Router Advertisement
      that is generally unfavored approach

   -  The RA-based solution involves changes and management on network
      side nodes that are not really part of the NAT64/DNS64 deployment
      (or issues caused by their existence).

   If RA would include multiple NSPs issue #5 could be solved as well,
   but only if nodes as a group would select different NSPs hence
   supporting load-balancing.  As this is not clear this item is not yet
   listed under PRO or CON.





Korhonen & Savolainen   Expires September 8, 2012              [Page 17]

Internet-Draft            Learning NAT64 prefix               March 2012


5.7.3.  Summary

   The RA-based solution would be a good solution in a sense it hooks
   into general IP configuration phase, allows easy updates when
   configuration information changes and does not involve DNS in
   general.  However, generally introducing any changes to the Neighbor
   Discovery Protocol that are not absolutely necessary are unfavored
   due to the impact on both network node side and end host IP stack
   implementations.

   Compared to the DHCPv6 equivalent solution in Section 5.6 the
   management overhead is greater with RA-based solution.  In case of
   DHCPv6-based solution the management can be centralized to few DHCPv6
   servers compared to RA-based solution where each access router is
   supposed to be configured with the same information.

5.8.  Using application layer protocols such as STUN

5.8.1.  Solution description

   Application layer protocols, such as Session Traversal Utilities for
   NAT (STUN) [RFC5389], which define methods for endpoints to learn
   their external IP addresses could be used for NAT64 and NSP
   discovery.  This document focuses on STUN, but the protocol could be
   something else as well.

   A host must first use DNS to discover IPv6 representation(s) of STUN
   server(s) IPv4 address(es), because the host has no way to directly
   use IPv4 addresses to contact to STUN server(s).

   After learning the IPv6 address of a STUN server the STUN client
   sends a request to the STUN server containing new 'SENDING-TO'
   attribute that tells to the server the IPv6 address the client sent
   the request to.  In a reply the server includes another new attribute
   called 'RECEIVED-AS', which contains server's IP address the request
   arrived on.  After receiving the reply the client compares
   'SENDING-TO' and 'RECEIVED-AS' attributes to find out an NSP
   candidate.

5.8.2.  Analysis and discussion

   This solution is relatively similar as described in Section 5.1, but
   instead of using DNS uses STUN to get input for heuristic algorithms.

   The PROs of the proposal are listed below:






Korhonen & Savolainen   Expires September 8, 2012              [Page 18]

Internet-Draft            Learning NAT64 prefix               March 2012


   +  Can be used to solve Issue #1 and Issue #2.

   +  Does not require host changes or supportive protocols such as DNS
      or DHCPv6.  All required logic and heuristics can be implemented
      in applications that are interested in learning about address
      synthesis taking place.

   +  The solution is backward compatible from 'legacy' hosts and
      servers point of view.

   +  Hosts or applications interested in learning about synthesis and
      the used NSP can do the "discovery" proactively at any time, for
      example every time the host attaches to a new network.

   +  Does not require explicit support from the network using NAT64.

   +  Can possibly be bundled to existing STUN message exchanges as new
      attributes and hence client can learn its external IPv4 address
      and a NSP/WKP with the same exchange

   +  Can be used to confirm the heuristics by synthesizing IPv6 address
      of another STUN server or by synthesizing IPv6 address of first
      STUN server after host has heuristically determined NSP using
      method from Section 5.1.  I.e. the connectivity test could be done
      with STUN.

   +  True IPv4 destination address is used in NSP determination instead
      of IPv4 address received from DNS.  This may increase reliability.

   +  The same STUN improvement could also be used to reveal NAT66 on
      the data path, if the 'RECEIVED-AS' would contain different IPv6
      address than 'SENDING-TO'.

   The CONs of the proposal are listed below:

   -  Requires a server on the network to respond the queries.

   -  Requires standardization if done as extension to STUN.

   -  The solution involves changes and management on network side nodes
      that are not really part of the NAT64/DNS64 deployment (or issues
      caused by their existence).

   -  Does not solve issue #3 if STUN server's synthetic IPv6 address is
      provisioned via DNS.






Korhonen & Savolainen   Expires September 8, 2012              [Page 19]

Internet-Draft            Learning NAT64 prefix               March 2012


   -  Does not solve issue #4 as the STUN server would not be aware of
      learned NSP's validity time.

   -  Does not solve issue #5 as the STUN server would not be aware of
      multiple NSP prefixes.

   -  Heavyweight solution especially if an application does not
      otherwise support STUN.

5.8.3.  Summary

   The STUN, or similar, protocol based approach is a second way to
   solve the problem without explicit access network support.  The
   heuristics for NSP discovery would still be in the client, however,
   the result may be more reliable as actual IPv4 destination address is
   compared to IPv6 address used in sending.  The additional benefit of
   STUN is that the client learns its public IPv4 address with the same
   message exchange.  STUN could also be used as the connectivity test
   tool if the client would first heuristically determine NSP out of DNS
   as described in Section 5.1, synthesize IPv6 representation of STUN
   server's IPv4 address, and then tests connectivity to the STUN
   server.

   As an additional benefit the STUN improvement could be used for NAT66
   discovery.

5.9.  Learning the IPv6 Prefix of a Network's NAT64 using Access
      Technology Specific Methods

5.9.1.  Solution description

   Several link layers on different access systems have attachment time
   signaling protocols for negotiating various parameters that are used
   later on with the established link layer connection.  Examples of
   such include 3GPP Non-Access-Stratum (NAS) signaling protocol
   [NAS.24.301] among other link layers and tunneling solutions.  There,
   using NAS signaling it could be possible to list all NSPs with their
   respective prefix lengths in generic protocol configuration option
   containers during the network access establishment.  The lack of NSPs
   in protocol configuration option containers would be an implicit
   indication that there is no NAT64 present in the network.

5.9.2.  Analysis and discussion

   The PROs of the proposal are listed below:






Korhonen & Savolainen   Expires September 8, 2012              [Page 20]

Internet-Draft            Learning NAT64 prefix               March 2012


   +  Can be used to solve Issue #1, Issue #2, Issue #3 and Issue #5.

   +  Can solve Issue #4 if lifetime information is also communicated.

   The CONs of the proposal are listed below:

   -  Requires configuration and managements of all access routers/
      gateway to emit correct information in "link/lower layer"
      signaling.  In a case the NAT64 functionality is implemented into
      the access router/gateway itself that terminates the generic
      protocol configuration exchange, then the configuration management
      can be automated.

   -  In some operating systems it may not be trivial to transfer
      information obtained in "link/lower layers" to upper layers.

   -  NSP change may require changes to access router/gateway
      configuration.

   -  Requires standardization of a new configuration parameter
      exchange/container for each access system of interest.  The
      proposed solution is indeed specific to each access technology.

5.9.3.  Summary

   The Access Technology-based solution would be a good solution in a
   sense it hooks into general network access establishment phase,
   allows easy updates when configuration information changes and does
   not involve DNS in general.  However, generally introducing any
   changes to the link/lower layers is a long and slow process, and
   changes would need to be done for all access technologies/systems
   that are used with NAT64.

   Compared to the RA equivalent solution in Section 5.7 the management
   overhead is equivalent or even less than RA-based solution.


6.  Conclusion

   Our conclusion is to recommend publishing the Well-Known DNS Name
   heuristic discovery-based method as a standards track IETF document
   for applications and host implementors to implement as-is.

   As a general principle we prefer to have as minimal solution as
   possible, avoid impacts to entities not otherwise involved in the
   protocol translation scheme, minimize host impact, and that requires
   minimal to no operational effort on the network side.




Korhonen & Savolainen   Expires September 8, 2012              [Page 21]

Internet-Draft            Learning NAT64 prefix               March 2012


   Of the different issues we give most weight for issues #1 and #2.  We
   are not giving much weight for the Issue #3 'DNS should not be
   required', as cases where hosts need to synthesize IPv6 addresses but
   do not have DNS available seem rare for us.  Even if application does
   not otherwise utilize DNS, it ought to be able to trigger simple DNS
   query to find out WKP/NSP.  Issue #4 is handled by majority of
   solutions and Issue #5 is considered to be mostly insignificant as
   even if individual hosts would use only one NSP at a time, different
   hosts would be using different NSPs, hence supporting load-balancing
   targets.  Only one of the discussed solutions, see Section 5.6,
   support learning of possible new or indicating support for multiple
   algorithms for address synthesis other than the one described in
   [RFC6052].

   The DNS64 entity has to be configured with WKP/NSP in order for it to
   do synthesis and hence using DNS also for delivering the synthesis
   information sounds logical.  The fact that the synthesis information
   fate-shares the information received in the DNS response is a
   valuable attribute and reduces the possible distribution of stale
   prefix information.  However, having all DNS64 servers to support
   explicit WKP/NSP discovery (ENDS0, A64, and DNS SRV record
   approaches) is difficult to arrange.  The U-NAPTR-based approach
   would require provisioning information into the '.ip6.arpa' tree
   which would not be entirely internal for the provider.  Use of DHCPv6
   would require additional trouble configuring DHCPv6 servers and
   ensuring DHCPv6 clients are in place, and furthermore that the NAT64,
   DHCPv6 (and possible even some DNS64) servers are all in sync.  RA-
   based mechanisms are operationally expensive as configuration would
   have to be placed and maintained in the access routers.  Furthermore,
   both DHCPv6 and RA based mechanisms involve entities that do not
   otherwise need to be aware of protocol translation (only need to know
   DNS server addresses).  Finally, regarding the use of STUN.  A host
   does not need to implement STUN where as DNS is in practice required
   anyway.  Also, STUN protocol would need to be changed on both host
   and network side to support the discovery of NAT64 and WKP/NSP.


7.  Security Considerations

   The security considerations are essentially similar to what is
   described in DNS64 [RFC6147].  Forgery of information required for
   IPv6 address synthesis may allow an attacker to insert itself as
   middle man or to perform denial-of-service attack.  The DHCPv6 and RA
   based approaches are vulnerable for the forgery as the attacker may
   send forged RAs or act as a rogue DHCPv6 server (unless DHCPv6
   authentication or SEND are used).  If the attacker is already able to
   modify and forge DNS responses (flags, addresses of know IPv4-only
   servers, records, etc), ability to influence local address synthesis



Korhonen & Savolainen   Expires September 8, 2012              [Page 22]

Internet-Draft            Learning NAT64 prefix               March 2012


   is likely of low additional value.  Also, a DNS-based mechanism is
   only as secure as the method used to configure the DNS server's IP
   addresses on the host.  Therefore, if the host cannot trust e.g.
   DHCPv6 it cannot trust the DNS server learned via DHCPv6 either,
   unless the host has a way to authenticate all DNS responses.


8.  IANA Considerations

   This document is informative and has no actions to IANA.


9.  Contributors

   The following people have contributed text to this document.

      Mohamed Boucadair
      France Telecom
      Rennes, 35000
      France

      Email: mohamed.boucadair@orange-ftgroup.com


10.  Acknowledgements

   Authors would like to thank Dan Wing and Christian Huitema especially
   for the STUN idea and for their valuable comments and discussions.


11.  References

11.1.  Normative References

   [I-D.ietf-behave-nat64-discovery-heuristic]
              Savolainen, T., Korhonen, J., and D. Wing, "Discovery of a
              Network-Specific NAT64 Prefix using a Well-Known Name",
              draft-ietf-behave-nat64-discovery-heuristic-05 (work in
              progress), January 2012.

   [RFC2326]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
              Streaming Protocol (RTSP)", RFC 2326, April 1998.

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
              RFC 2671, August 1999.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.



Korhonen & Savolainen   Expires September 8, 2012              [Page 23]

Internet-Draft            Learning NAT64 prefix               March 2012


              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4848]  Daigle, L., "Domain-Based Application Service Location
              Using URIs and the Dynamic Delegation Discovery Service
              (DDDS)", RFC 4848, April 2007.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

   [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.

11.2.  Informative References

   [NAS.24.301]
              3GPP, "Non-Access-Stratum (NAS) protocol for Evolved
              Packet System (EPS)", 3GPP TS 24.301 8.8.0, December 2010.

   [RFC5507]  IAB, Faltstrom, P., Austein, R., and P. Koch, "Design
              Choices When Expanding the DNS", RFC 5507, April 2009.

   [RFC6144]  Baker, F., Li, X., Bao, C., and K. Yin, "Framework for



Korhonen & Savolainen   Expires September 8, 2012              [Page 24]

Internet-Draft            Learning NAT64 prefix               March 2012


              IPv4/IPv6 Translation", RFC 6144, April 2011.


Authors' Addresses

   Jouni Korhonen (editor)
   Nokia Siemens Networks
   Linnoitustie 6
   FI-02600 Espoo
   Finland

   Email: jouni.nospam@gmail.com


   Teemu Savolainen (editor)
   Nokia
   Hermiankatu 12 D
   FI-33720 Tampere
   Finland

   Email: teemu.savolainen@nokia.com






























Korhonen & Savolainen   Expires September 8, 2012              [Page 25]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/