wdiff rfc7051.original rfc7051.txt

Behavior
Internet Engineering for Hindrance Task Force (IETF) J. Korhonen, Ed.
Avoidance (BEHAVE) Nokia Siemens Networks
Internet-Draft
Request for Comments: 7051 Broadcom
Category: Informational T. Savolainen, Ed.
Intended status: Informational
ISSN: 2070-1721 Nokia
Expires: September 8, 2012 March 7, 2012
October 2013

Analysis of solution proposals Solution Proposals for hosts Hosts to learn Learn NAT64 prefix
draft-ietf-behave-nat64-learn-analysis-03.txt Prefix

Abstract

Hosts and applications may benefit from the knowledge learning if an IPv6 address
is synthesized, which would mean a synthesized and if NAT64 is used to reach the
IPv4 network or Internet. and DNS64 are present in a network. This
document analyses a number of analyzes all proposed solutions (known at the time of
writing) for communicating whether the synthesis is taking place, used
what address format, format was used, and the what IPv6 prefix was used by the
NAT64 and DNS64. The These solutions enable both NAT64 avoidance and intentional
utilization by allowing
local IPv6 address synthesis. The document concludes by recommending selection
the standardization of heuristic discovery the approach based
solution. on heuristic discovery.

Status of this This Memo

This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a maximum candidate for any level of Internet
Standard; see Section 2 of RFC 5741.

Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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.
http://www.rfc-editor.org/info/rfc7051.

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
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 ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 .....................................................4
3. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 ..........................................................5
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 ......................................................5
5. Proposed solutions Solutions to learn Learn about synthesis Synthesis and
Network-Specific Prefix . . . . . . . . . . . . . . . . . . . 8 .........................................7
5.1. DNS Query for a Well-Known Name . . . . . . . . . . . . . 8 ............................7
5.1.1. Solution description . . . . . . . . . . . . . . . . . 8 Description ................................7
5.1.2. Analysis and discussion . . . . . . . . . . . . . . . 8 Discussion .............................7
5.1.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 9 .............................................8
5.2. EDNS0 option indicating Option Indicating AAAA Record synthesis Synthesis and
format . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Format ...8
5.2.1. Solution description . . . . . . . . . . . . . . . . . 9 Description ................................8
5.2.2. Analysis and discussion . . . . . . . . . . . . . . . 9 Discussion .............................8
5.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 10 ............................................10
5.3. EDNS0 flags indicating Flags Indicating AAAA Record synthesis Synthesis and format . 11 Format ...10
5.3.1. Solution description . . . . . . . . . . . . . . . . . 11 Description ...............................10
5.3.2. Analysis and discussion . . . . . . . . . . . . . . . 11 Discussion ............................10
5.3.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 12 ............................................11
5.4. DNS Resource Record for IPv4-Embedded IPv6 address . . . . 12 Address ........11
5.4.1. Solution description . . . . . . . . . . . . . . . . . 12 Description ...............................11
5.4.2. Analysis and discussion . . . . . . . . . . . . . . . 12 Discussion ............................12
5.4.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 13 ............................................12
5.5. Learning the IPv6 Prefix of a Network's NAT64 using Using DNS . 13 ...13
5.5.1. Solution description . . . . . . . . . . . . . . . . . 13 Description ...............................13
5.5.2. Analysis and discussion . . . . . . . . . . . . . . . 14 Discussion ............................13
5.5.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 15 ............................................14
5.6. Learning the IPv6 Prefix of a Network's NAT64 using
Using DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 ..............................................14
5.6.1. Solution description . . . . . . . . . . . . . . . . . 15 Description ...............................14
5.6.2. Analysis and discussion . . . . . . . . . . . . . . . 16 Discussion ............................15
5.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 16 ............................................15
5.7. Learning the IPv6 Prefix of a Network's NAT64 using
Using Router Advertisements . . . . . . . . . . . . . . . . . . 17 ..............................................16
5.7.1. Solution description . . . . . . . . . . . . . . . . . 17 Description ...............................16
5.7.2. Analysis and discussion . . . . . . . . . . . . . . . 17 Discussion ............................16
5.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 18 ............................................17
5.8. Using application layer protocols Application-Layer Protocols such as STUN . . . . . . 18 ............17
5.8.1. Solution description . . . . . . . . . . . . . . . . . 18 Description ...............................17
5.8.2. Analysis and discussion . . . . . . . . . . . . . . . 18 Discussion ............................18
5.8.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 20 ............................................19
5.9. Learning the IPv6 Prefix of a Network's NAT64 using
Access Technology Specific
Using Access-Technology-Specific Methods . . . . . . . . . . . . 20 ..................19
5.9.1. Solution description . . . . . . . . . . . . . . . . . 20 Description ...............................19
5.9.2. Analysis and discussion . . . . . . . . . . . . . . . 20 Discussion ............................20
5.9.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 21 ............................................20
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21 .....................................................20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 ........................................21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
10. ...................................................22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
11. ...............................................22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. ....................................................22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. .....................................22
10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 ...................................24

1. Introduction

Hosts and applications may benefit from the knowledge of whether learning if an IPv6 address
is synthesized, which would mean that 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
Network-Specific Prefix (NSP) [RFC6052] used by the NAT64 [RFC6146]
and the DNS64 [RFC6147] devices.

Firstly,

The first issue is finding out whether a particular address is
synthetic and therefore learning the presence of a NAT64. For
example, a Dual-
Stack (DS) dual-stack 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

The second issue is finding 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', ('Issue
#3'), whether a solution supports changing NSP 'Issue #4', ('Issue #4'), and
whether multiple NSPs are supported (either of the same or different
length) for load-balancing purposes 'Issue #5'. ('Issue #5').

This document analyses analyzes all known solution proposals proposed solutions 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
an 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].

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 in the 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: vice versa: A network entity that
a host or an application may want to either avoid or utilize.
IPv6 packets that hosts send sent to addresses in the NSP and/or WKP
are routed to NAT64.

NSP

Network-Specific Prefix: A prefix chosen by a network
administrator for NAT64/DNS64 to present IPv4 addresses in the
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 the IPv6 namespace.

3. Issues

This document analyses analyzes different solutions with a focus to on the
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 (hence, applications are unable to
use DNS to learn the 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 a 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 the 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 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 synthesis, but to avoid NAT64 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"). Internet")
in the IPv4/IPv6 translation framework document [RFC6144]. Scenario 3("The
3 ("The IPv6 Internet to an IPv4 network") is not considered
applicable herein as in that case case, a NAT64 is located at the front of
a remote IPv4 network network, and a host in IPv6 Internet can benefit very
little of from learning the NSP IPv6 prefix used by the remote NAT64.
The NAT64 prefix can be either a Network Specific Network-Specific Prefix (NSP) or the Well-known
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: NSP/WKP:

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

o Protocols that use IPv4 literals: in literals. In IPv6-only access access, native
IPv4 connections cannot be created. If a network has NAT64 NAT64, it is
possible to synthesize an IPv6 address by combining the IPv4
literal 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. translation [MCAST-TRANSLATOR] [V4V6MC-FRAMEWORK].

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
ipp://192.0.2.1). A host can synthesize an IPv6 address out of
the literal in the URI and use IPv6 to create a connection through
NAT64.

o Updating the host's [RFC3484] [RFC6724] preference table to prefer native
prefixes over translated prefixes: this 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 the Real
Time Streaming Protocol (RTSP) [RFC2326] and the 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, 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. Internet [REFERRAL-PS]. 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 example, due to
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.

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

5.1. DNS Query for a Well-Known Name

5.1.1. Solution description Description

Section 3 of [I-D.ietf-behave-nat64-discovery-heuristic] [RFC7050] 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 a
AAAA record of a Well-Known IPv4-
only IPv4-only Fully Qualified Domain Name
(FQDN). If a host receives a negative reply, it knows there are that no DNS64
and NAT64 are in the network.

If a host receives a AAAA reply, it knows the network must be
utilizing IPv6 address synthesis. After receiving a synthesized AAAA Resource
Record,
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 Discussion

The PROs of the proposal are listed below:

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

+ Solves issue Issue #4 via the lifetime of the DNS record lifetime. record.

+ Can partially solve issue 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 the point of view of
'legacy' hosts and
servers point of view. servers.

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

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

The CONs of the proposal are listed below:

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

- Does not provide a solution for issue Issue #3.

- This method is only able to find one NSP even if a network is
utilizing multiple NSPs (issue (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, Format

5.2.1. Solution Description

[SYNTH-FLAG-2011] defined a new
EDNS0 Extension Mechanisms for DNS (EDNS0)
option [RFC2671], which [RFC2671] that contained 3 flag bits (called SY-bits). The
EDNS0 option served as an implicit indication of the presence of a
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. resource record.

5.2.2. Analysis and discussion 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 Issue #4 via the lifetime of the DNS record lifetime. record.

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

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

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

+ 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 EDNS0 extension mechanism. mechanisms
[RFC6891].

- Requires host resolver changes and a mechanism/additions to the host
resolver API (or flags, hints etc) 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 a solution for issue Issue #3.

- EDNS0 flags and options are typically hop-by-hop only, severely
limiting the applicability of these approaches, unless the EDNS0-
capable DNS64 is the first DNS server the end host talks to, as it
is otherwise not possible to guarantee that the EDNS0 option
survives through all DNS proxies and servers in between.

5.2.3. Summary

The solution based on the EDNS0 option based solution works by extending the
existing EDNS0
Resource Record. 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 minimal, if not non-existent non-existent, as the EDNS0
options are synthesized in a DNS64 server in a same manner as the
synthesized AAAA Resource
Records. resource records. Moreover, EDNS0 does not induce
any load to DNS servers because no new RRType query is defined.

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, Format

5.3.1. Solution Description

[SYNTH-FLAG-2010] defined 3 new flag bits (called SY-bits) into in the
EDNS0 OPT [RFC2671] header, which header that served as an implicit indication of
the presence of a 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. resource record.

5.3.2. Analysis and discussion 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 Issue #4 via the lifetime of the DNS record lifetime. record.

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

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

+ 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 EDNS0 extension mechanism. mechanisms
[RFC6891].

- Consumes scarce flag bits from the EDNS0 OPT header.

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

- Does not provide a solution for issue 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 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 Description

[DNS-A64] proposed a new DNS
Resource Record resource record (A64) that would be a
record dedicated to storing a single IPv4-Embedded IPv4-embedded IPv6 address
[RFC6052]. Use of a dedicated
Resource Record resource record would allow a host to
distinguish between real IPv6 addresses and synthesized IPv6
addresses. The solution requires the host to send a query for an A64
record. Positive A positive answer with an A64 record informs the requesting
host that the resolved address is not a native address but an IPv4-Embedded IPv4-
embedded IPv6 address. This would ease the local policies to prefer
direct communications (i.e., avoid using IPv4-
Embedded 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 Discussion

The PROs of the proposal are listed below:

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

+ Solves issue Issue #4 via the lifetime of the DNS record lifetime. record.

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

+ Synthesized addresses can be used in authoritative DNS servers.

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

+ When both IPv4-Converted 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 Issues #2 or #3 in any way.

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

- Requires a standardization of a new DNS Resource Record resource record type
(A64), (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 on the DNS servers (3 Queries, queries -- A64, AAAA AAAA, and A, 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 place, solving the Issue #1, a standardization
of a new DNS record type might turn out a to be too overwhelming a task for
as a solution for a temporary transition phase. Defining a new
record type increases the load towards the DNS server as the host
issues parallel A64, AAAA AAAA, and A queries.

5.5. Learning the IPv6 Prefix of a Network's NAT64 using 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, Description

[LEARN-PREFIX] proposed two DNS-based methods for discovering the
presence of a DNS64 server and a NAT64 device, and then device. It also proposed a
mechanism for discovering the used NSP.

Firstly,

First, the document proposed that a host may learn the presence of a
DNS64 server and a NAT64 device, device by receiving a TXT Resource Record resource record
with a well-known string (that (which the 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 resource record into the
DNS response.

Secondly,

Second, the document proposed specifying a new U-NAPTR URI-Enabled NAPTR
(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 U-NAPTR
query contains the unicast IPv6 address and the prefix length of the
NAT64 device.

5.5.2. Analysis and discussion Discussion

The PROs of the proposal are listed below:

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

+ Solves issue Issue #4 via the lifetime of the DNS record lifetime. record.

+ Does not require host stack or resolver changes if the required
logic and heuristics is are 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 Well-Known Name by IANA for the TXT
Resource Record
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) 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 the PROs list.

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

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

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

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

- Does not provide a solution for issue Issue #3.

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

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
Sections 5.2, Section 5.3 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 ".ip6.arpa." tree, which is not any more no longer entirely internal to
the provider hosting the NAT64/DNS64 service.

The iterative approach of learning the NAT64 prefix in U-NAPTR-based an 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 Using DHCPv6

5.6.1. Solution description Description

Two individual IETF Internet-Draft contributions documents specified DHCPv6
based 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,

[LEARN-PREFIX] described a new DHCPv6 [RFC3315] option
(OPTION_AFT_PREFIX_DHCP) that would contain the IPv6 unicast prefix,
IPv6 ASM Any-Source Multicast (ASM) prefix, and IPv6 SSM Source-Specific
Multicast (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,

[DHCPV6-SHARED-ADDRESS] proposed a DHCPv6 option that could be used
to communicate to a requesting host the prefix used for building IPv4-Converted
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.

5.6.2. Analysis and discussion Discussion

The PROs of the proposal are listed below:

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

+ Does not involve the 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 the DHCPv6 configuration.

- Requires at least Stateless 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
network-side nodes that are not really part of the NAT64/DNS64
deployment (or or aware of issues caused by their existence). NAT64/DNS64.

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

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

5.6.3. Summary

The DHCPv6-based solution would be a good solution in a sense as it hooks into
the general IP configuration phase, allows easy updates when
configuration information changes changes, and does not involve DNS in
general. Use of DHCPv6 requires configuration changes on DHCPv6
clients and servers and and, in some cases 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 Third Generation Partnership Project
(3GPP) networks do not mandate hosts or network networks to implement or
deploy DHCPv6.

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

5.7.1. Solution description 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, [LEARN-PREFIX] 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
DHCPv6, discussed in Section 5.6.

5.7.2. Analysis and discussion Discussion

The PROs of the proposal are listed below:

+ Can be used to solve Issue Issues #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 management of all access routers to
emit correct information in the RA. This could, for example, be
accomplished somehow by piggybacking on top of routing protocols
(which would then require enhancements to routing protocols) protocols).

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

- Requires changes to the host operating system's IP stack stack.

- An NSP change requires changes to the access router configuration configuration.

- Requires standardization of a new option to the Router Advertisement
that
Advertisement, which is generally an unfavored approach approach.

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

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

5.7.3. Summary

The RA-based solution would be a good solution in a sense as it hooks into the
general IP configuration phase, allows easy updates when
configuration information changes 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 the network-side node side and end host IP stack
implementations.

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

5.8. Using application layer protocols Application-Layer Protocols such as STUN

5.8.1. Solution description

Application layer Description

Application-layer protocols, such as Session Traversal Utilities for
NAT (STUN) [RFC5389], which that 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) representations of STUN
server(s)
servers' IPv4 address(es), addresses, because the host has no way to directly use
IPv4 addresses to contact to STUN server(s). servers.

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

5.8.2. Analysis and discussion Discussion

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

The PROs of the proposal are listed below:

+ Can be used to solve Issue Issues #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 the point of view of
'legacy' hosts and
servers point of view. servers.

+ Hosts or applications interested in learning about synthesis and
the used NSP can do the "discovery" proactively at any time, for
example
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
attributes, and hence hence, a client can learn its external IPv4
address and a an NSP/WKP with the same exchange exchange.

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

+ True The true IPv4 destination address is used in NSP determination
instead of the 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 a different IPv6
address than from 'SENDING-TO'.

The CONs of the proposal are listed below:

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

- Requires standardization if done as an extension to STUN.

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

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

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

- Does not solve issue 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,

An approach based on STUN or similar, a similar protocol based approach is a second way to
solve the problem without explicit access network access-network support. The
heuristics for NSP discovery would still be in the client, client; however,
the result may be more reliable as an actual IPv4 destination address
is compared to the 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 the
IPv6 representation of the STUN server's IPv4 address, and then tests test
connectivity to the STUN server.

As an additional benefit 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 Using Access-
Technology-Specific Methods

5.9.1. Solution description 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 link-layer connection. Examples of
such include the 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 Discussion

The PROs of the proposal are listed below:

+ Can be used to solve Issue Issues #1, Issue #2, Issue #3 #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 management of all access routers/
gateway
gateways to emit correct information in "link/lower layer" "link/lower-layer"
signaling. In a case the If 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 systems, it may not be trivial to transfer
information obtained in "link/lower layers" to upper layers.

- An NSP change may require changes to the 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 based on access technology would be a good solution in a
sense as
it hooks into general network access establishment phase, allows easy
updates when configuration information changes 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 RA-equivalent solution in Section 5.7 5.7, the management
overhead is equivalent or even less than the RA-based solution.

6. Conclusion

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

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

Of the different issues issues, we give the most weight for issues to Issues #1 and #2.
We
are do not giving give much weight for the to Issue #3 'DNS should not be
required', #3, as cases where hosts need to
synthesize IPv6 addresses but do not have DNS available seem rare for to
us. Even if an application does not otherwise utilize DNS, it ought
to be able to trigger a simple DNS query to find out WKP/NSP. Issue
#4 is handled by the majority of
solutions 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 supports 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 synthesis; 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 ".ip6.arpa." tree,
which would not be entirely internal for the provider. Use of DHCPv6
would require involve additional trouble configuring DHCPv6 servers and
ensuring DHCPv6 clients are in place, and furthermore place; it would also involve ensuring
that the NAT64, NAT64 and DHCPv6 (and possible possibly even some DNS64) servers DNS64 servers) are
all in sync. RA-
based 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 RA-based mechanisms involve
entities that do not otherwise need to be aware of protocol
translation (only (they only need to know DNS server addresses). Finally,
regarding the use of STUN. A STUN, a host does not need to implement STUN where as
whereas DNS is is, in practice practice, required anyway. Also, the STUN
protocol would need to be changed on both the 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 those
described in DNS64 [RFC6147]. The document also talks about man-in-
the-middle and denial-of-service attacks caused by forging of
information required for IPv6 synthesis from corresponding IPv4
addresses. Forgery of information required for IPv6 address
synthesis may allow an attacker to insert itself as a middle man or
to perform a denial-of-service attack. The DHCPv6 and RA
based RA-based
approaches are vulnerable for the to forgery as the attacker may send forged
RAs or act as a rogue DHCPv6 server (unless DHCPv6 authentication
[RFC3315] or SEND Secure Neighbor Discovery (SEND) [RFC3971] are used).
If the attacker is already able to modify and forge DNS responses
(flags, addresses of know known IPv4-only servers, records, etc), etc.), ability
to influence local address synthesis 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 if, for example, the host cannot trust e.g.
DHCPv6 DHCPv6, it cannot
trust the DNS server learned via DHCPv6 either, unless the host has a
way to authenticate all DNS responses. responses (e.g., via DNSSEC [RFC4033]).

8. IANA Considerations

This document is informative and has no actions to IANA.

9. Contributors

The following people have individual contributed text to this document.

Mohamed Boucadair
France Telecom
Rennes, 35000
France

Email:

EMail: mohamed.boucadair@orange-ftgroup.com

10.

9. Acknowledgements

Authors

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

11.

Jouni Korhonen would like to specifically thank Nokia Siemens
Networks as he completed the majority of this document while employed
there.

10. References

11.1.

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

[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.

[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, October 2013.

10.2. Informative References

[DHCPV6-SHARED-ADDRESS]
Boucadair, M., Levis, P., Grimault, J., Savolainen, T.,
and G. Bajko, "Dynamic Host Configuration Protocol
(DHCPv6) Options for Shared IP Addresses Solutions", Work
in Progress, December 2009.

[DNS-A64] Boucadair, M. and E. Burgey, "A64: DNS Resource Record for
IPv4-Embedded IPv6 Address", Work in Progress,
September 2010.

[LEARN-PREFIX]
Wing, D., "Learning the IPv6 Prefix of a Network's IPv6/
IPv4 Translator", Work in Progress, October 2009.

[MCAST-TRANSLATOR]
Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An
IPv4 - IPv6 multicast translator", Work in Progress,
December 2010.

[NAS.24.301]
3GPP, "Non-Access-Stratum (NAS) protocol for Evolved
Packet System (EPS)", 3GPP TS 24.301 8.8.0, December 2010. 2010,
<http://www.3gpp.org/ftp/Specs/html-info/24301.htm>.

[REFERRAL-PS]
Carpenter, B., Jiang, S., and Z. Cao, "Problem Statement
for Referral", Work in Progress, February 2011.

[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.

[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
IPv4/IPv6 Translation", RFC 6144, April 2011.

[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.

[SYNTH-FLAG-2010]
Korhonen, J. and T. Savolainen, "EDNS0 Option for
Indicating AAAA Record Synthesis and Format", Work
in Progress, July 2010.

[SYNTH-FLAG-2011]
Korhonen, J. and T. Savolainen, "EDNS0 Option for
Indicating AAAA Record Synthesis and Format", Work
in Progress, February 2011.

[V4V6MC-FRAMEWORK]
Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6
Multicast Translation", Work in Progress, June 2011.

Authors' Addresses

Jouni Korhonen (editor)
Nokia Siemens Networks
Linnoitustie 6
FI-02600 Espoo
Broadcom
Porkkalankatu 24
FIN-00180 Helsinki
Finland

Email:

EMail: jouni.nospam@gmail.com

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

Email:

EMail: teemu.savolainen@nokia.com