draft-ietf-v6ops-rfc6555bis-06.txt   draft-ietf-v6ops-rfc6555bis-07.txt 
Network D. Schinazi Network D. Schinazi
Internet-Draft T. Pauly Internet-Draft T. Pauly
Obsoletes: 6555 (if approved) Apple Inc. Obsoletes: 6555 (if approved) Apple Inc.
Intended status: Standards Track October 20, 2017 Intended status: Standards Track October 25, 2017
Expires: April 23, 2018 Expires: April 28, 2018
Happy Eyeballs Version 2: Better Connectivity Using Concurrency Happy Eyeballs Version 2: Better Connectivity Using Concurrency
draft-ietf-v6ops-rfc6555bis-06 draft-ietf-v6ops-rfc6555bis-07
Abstract Abstract
Many communication protocols operated over the modern Internet use Many communication protocols operated over the modern Internet use
host names. These often resolve to multiple IP addresses, each of host names. These often resolve to multiple IP addresses, each of
which may have different performance and connectivity which may have different performance and connectivity
characteristics. Since specific addresses or address families (IPv4 characteristics. Since specific addresses or address families (IPv4
or IPv6) may be blocked, broken, or sub-optimal on a network, clients or IPv6) may be blocked, broken, or sub-optimal on a network, clients
that attempt multiple connections in parallel have a higher chance of that attempt multiple connections in parallel have a higher chance of
establishing a connection sooner. This document specifies establishing a connection sooner. This document specifies
requirements for algorithms that reduce this user-visible delay and requirements for algorithms that reduce this user-visible delay and
provides an example algorithm. provides an example algorithm, referred to as "Happy Eyeballs". This
document obsoletes the original algorithm description in [RFC6555].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2018. This Internet-Draft will expire on April 28, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Hostname Resolution Query Handling . . . . . . . . . . . . . 4 3. Hostname Resolution Query Handling . . . . . . . . . . . . . 4
3.1. Handling Multiple DNS Server Addresses . . . . . . . . . 5 3.1. Handling Multiple DNS Server Addresses . . . . . . . . . 5
4. Sorting Addresses . . . . . . . . . . . . . . . . . . . . . . 5 4. Sorting Addresses . . . . . . . . . . . . . . . . . . . . . . 5
5. Connection Attempts . . . . . . . . . . . . . . . . . . . . . 6 5. Connection Attempts . . . . . . . . . . . . . . . . . . . . . 6
6. DNS Answer Changes during Happy Eyeballs Connection Setup . . 7 6. DNS Answer Changes during Happy Eyeballs Connection Setup . . 7
7. Supporting IPv6-only Networks with NAT64 and DNS64 . . . . . 7 7. Supporting IPv6-only Networks with NAT64 and DNS64 . . . . . 8
7.1. IPv4 Address Literals . . . . . . . . . . . . . . . . . . 8 7.1. IPv4 Address Literals . . . . . . . . . . . . . . . . . . 8
7.2. Host Names with Broken AAAA Records . . . . . . . . . . . 9 7.2. Host Names with Broken AAAA Records . . . . . . . . . . . 9
7.3. Virtual Private Networks . . . . . . . . . . . . . . . . 10 7.3. Virtual Private Networks . . . . . . . . . . . . . . . . 10
8. Summary of Configurable Values . . . . . . . . . . . . . . . 11 8. Summary of Configurable Values . . . . . . . . . . . . . . . 11
9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Path Maximum Transmission Unit Discovery . . . . . . . . 12 9.1. Path Maximum Transmission Unit Discovery . . . . . . . . 12
9.2. Application Layer . . . . . . . . . . . . . . . . . . . . 12 9.2. Application Layer . . . . . . . . . . . . . . . . . . . . 12
9.3. Hiding Operational Issues . . . . . . . . . . . . . . . . 12 9.3. Hiding Operational Issues . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Normative References . . . . . . . . . . . . . . . . . . 13 13.1. Normative References . . . . . . . . . . . . . . . . . . 13
13.2. Informative References . . . . . . . . . . . . . . . . . 14 13.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Differences from RFC6555 . . . . . . . . . . . . . . 14 Appendix A. Differences from RFC6555 . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Many communication protocols operated over the modern Internet use Many communication protocols operated over the modern Internet use
host names. These often resolve to multiple IP addresses, each of host names. These often resolve to multiple IP addresses, each of
skipping to change at page 3, line 37 skipping to change at page 3, line 37
how to handle DNS queries when starting a connection on a dual-stack how to handle DNS queries when starting a connection on a dual-stack
client, how to create an ordered list of destination addresses to client, how to create an ordered list of destination addresses to
which to attempt connections, and how to race the connection which to attempt connections, and how to race the connection
attempts. attempts.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
"Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. [RFC2119] [RFC8174] when, and only when, they appear in all capitals,
as shown here.
2. Overview 2. Overview
This document defines a method of connection establishment, named This document defines a method of connection establishment, named
"Happy Eyeballs Connection Setup". This approach has several "Happy Eyeballs Connection Setup". This approach has several
distinct phases: distinct phases:
1. Initiation of asynchronous DNS queries [Section 3] 1. Initiation of asynchronous DNS queries [Section 3]
2. Sorting of resolved destination addresses [Section 4] 2. Sorting of resolved destination addresses [Section 4]
skipping to change at page 4, line 28 skipping to change at page 4, line 28
Implementations SHOULD NOT wait for both families of answers to Implementations SHOULD NOT wait for both families of answers to
return before attempting connection establishment. If one query return before attempting connection establishment. If one query
fails to return, or takes significantly longer to return, waiting for fails to return, or takes significantly longer to return, waiting for
the second address family can significantly delay the connection the second address family can significantly delay the connection
establishment of the first one. Therefore, the client SHOULD treat establishment of the first one. Therefore, the client SHOULD treat
DNS resolution as asynchronous. Note that if the platform does not DNS resolution as asynchronous. Note that if the platform does not
offer an asynchronous DNS API, this behavior can be simulated by offer an asynchronous DNS API, this behavior can be simulated by
making two separate synchronous queries on different threads, one per making two separate synchronous queries on different threads, one per
address family. address family.
The RECOMMENDED algorithm proceeds as follows: if a positive AAAA The algorithm proceeds as follows: if a positive AAAA response (a
response (a response with at least one valid AAAA record) is received response with at least one valid AAAA record) is received first, the
first, the first IPv6 connection attempt is immediately started. If first IPv6 connection attempt is immediately started. If a positive
a positive A response is received first due to reordering, the client A response is received first due to reordering, the client SHOULD
SHOULD wait for a short time for the AAAA response to ensure wait for a short time for the AAAA response to ensure preference is
preference is given to IPv6 (it is common for the AAAA response to given to IPv6 (it is common for the AAAA response to follow the A
follow the A response by a few milliseconds). This delay will be response by a few milliseconds). This delay will be referred to as
referred to as the "Resolution Delay". The RECOMMENDED value for the the "Resolution Delay". The recommended value for the Resolution
Resolution Delay is 50 milliseconds. If a positive AAAA response is Delay is 50 milliseconds. If a positive AAAA response is received
received within the Resolution Delay period, the client immediately within the Resolution Delay period, the client immediately starts the
starts the IPv6 connection attempt. If a negative AAAA response (no IPv6 connection attempt. If a negative AAAA response (no error, no
error, no data) is received within the Resolution Delay period or the data) is received within the Resolution Delay period or the AAAA
AAAA response has not been received by the end of the Resolution response has not been received by the end of the Resolution Delay
Delay period, the client SHOULD proceed to Sorting Addresses period, the client SHOULD proceed to Sorting Addresses [Section 4]
[Section 4] and staggered connection attempts [Section 5] using any and staggered connection attempts [Section 5] using any IPv4
IPv4 addresses returned so far. If the AAAA response arrives while addresses returned so far. If the AAAA response arrives while these
these connection attempts are in progress, but before any connection connection attempts are in progress, but before any connection has
has been established, then the newly received IPv6 addresses are been established, then the newly received IPv6 addresses are
incorporated into the list of available candidate addresses incorporated into the list of available candidate addresses
[Section 6] and the process of connection attempts will continue with [Section 6] and the process of connection attempts will continue with
the IPv6 addresses added, until one connection is established. the IPv6 addresses added, until one connection is established.
3.1. Handling Multiple DNS Server Addresses 3.1. Handling Multiple DNS Server Addresses
If multiple DNS server addresses are configured for the current If multiple DNS server addresses are configured for the current
network, the client may have the option of sending its DNS queries network, the client may have the option of sending its DNS queries
over IPv4 or IPv6. In keeping with the Happy Eyeballs approach, over IPv4 or IPv6. In keeping with the Happy Eyeballs approach,
queries SHOULD be sent over IPv6 first (note that this is not queries SHOULD be sent over IPv6 first (note that this is not
skipping to change at page 5, line 25 skipping to change at page 5, line 25
be sent to other DNS server addresses. be sent to other DNS server addresses.
As native IPv6 deployments become more prevalent, and IPv4 addresses As native IPv6 deployments become more prevalent, and IPv4 addresses
are exhausted, it is expected that IPv6 connectivity will have are exhausted, it is expected that IPv6 connectivity will have
preferential treatment within networks. If a DNS server is preferential treatment within networks. If a DNS server is
configured to be accessible over IPv6, IPv6 should be assumed to be configured to be accessible over IPv6, IPv6 should be assumed to be
the preferred address family. the preferred address family.
Client systems SHOULD NOT have an explicit limit to the number of DNS Client systems SHOULD NOT have an explicit limit to the number of DNS
servers that can be configured, either manually or by the network. servers that can be configured, either manually or by the network.
If such a limit is required by hardware limitations, it is If such a limit is required by hardware limitations, the client
RECOMMENDED to use at least one address from each address family from SHOULD use at least one address from each address family from the
the available list. available list.
4. Sorting Addresses 4. Sorting Addresses
Before attempting to connect to any of the resolved destination Before attempting to connect to any of the resolved destination
addresses, the client should define the order in which to start the addresses, the client should define the order in which to start the
attempts. Once the order has been defined, the client can use a attempts. Once the order has been defined, the client can use a
simple algorithm for racing each option after a short delay simple algorithm for racing each option after a short delay
[Section 5]. It is important that the ordered list involves all [Section 5]. It is important that the ordered list involves all
addresses from both families that have been received by this point, addresses from both families that have been received by this point,
as this allows the client to get the racing effect of Happy Eyeballs as this allows the client to get the racing effect of Happy Eyeballs
skipping to change at page 6, line 14 skipping to change at page 6, line 14
If the client is stateful and has history of expected round-trip If the client is stateful and has history of expected round-trip
times (RTT) for the routes to access each address, it SHOULD add a times (RTT) for the routes to access each address, it SHOULD add a
Destination Address Selection rule between rules 8 and 9 that prefers Destination Address Selection rule between rules 8 and 9 that prefers
addresses with lower RTTs. If the client keeps track of which addresses with lower RTTs. If the client keeps track of which
addresses it has used in the past, it SHOULD add another destination addresses it has used in the past, it SHOULD add another destination
address selection rule between the RTT rule and rule 9, which prefers address selection rule between the RTT rule and rule 9, which prefers
used addresses over unused ones. This helps servers that use the used addresses over unused ones. This helps servers that use the
client's IP address during authentication, as is the case for TCP client's IP address during authentication, as is the case for TCP
Fast Open [RFC7413] and some HTTP cookies. This historical data MUST Fast Open [RFC7413] and some HTTP cookies. This historical data MUST
NOT be used across networks, and SHOULD be flushed on network NOT be used across different network interfaces, and SHOULD be
changes. flushed whenever a device changes the network to which it is
attached.
Next, the client SHOULD modify the ordered list to interleave address Next, the client SHOULD modify the ordered list to interleave address
families. Whichever address family is first in the list should be families. Whichever address family is first in the list should be
followed by an address of the other address family; that is, if the followed by an address of the other address family; that is, if the
first address in the sorted list is IPv6, then the first IPv4 address first address in the sorted list is IPv6, then the first IPv4 address
should be moved up in the list to be second in the list. An should be moved up in the list to be second in the list. An
implementation MAY want to favor one address family more by allowing implementation MAY want to favor one address family more by allowing
multiple addresses of that family to be attempted before trying the multiple addresses of that family to be attempted before trying the
other family. The number of contiguous addresses of the first other family. The number of contiguous addresses of the first
address family will be referred to as the "First Address Family address family will be referred to as the "First Address Family
skipping to change at page 6, line 51 skipping to change at page 7, line 4
address is started first, followed by the others in the list, one at address is started first, followed by the others in the list, one at
a time. Starting a new connection attempt does not affect previous a time. Starting a new connection attempt does not affect previous
attempts, as multiple connection attempts may occur in parallel. attempts, as multiple connection attempts may occur in parallel.
Once one of the connection attempts succeeds (generally when the TCP Once one of the connection attempts succeeds (generally when the TCP
handshake completes), all other connections attempts that have not handshake completes), all other connections attempts that have not
yet succeeded SHOULD be cancelled. Any address that was not yet yet succeeded SHOULD be cancelled. Any address that was not yet
attempted as a connection SHOULD be ignored. At that time, the attempted as a connection SHOULD be ignored. At that time, the
asynchronous DNS query MAY be cancelled as new addresses will not be asynchronous DNS query MAY be cancelled as new addresses will not be
used for this connection. However, the DNS client resolver SHOULD used for this connection. However, the DNS client resolver SHOULD
still process DNS replies from the network for a short period of time still process DNS replies from the network for a short period of time
(RECOMMENDED at 1 second), as they will populate the DNS cache and (recommended to be 1 second), as they will populate the DNS cache and
can be used for subsequent connections. can be used for subsequent connections.
A simple implementation can have a fixed delay for how long to wait A simple implementation can have a fixed delay for how long to wait
before starting the next connection attempt. This delay is referred before starting the next connection attempt. This delay is referred
to as the "Connection Attempt Delay". One recommended value for a to as the "Connection Attempt Delay". One recommended value for a
default delay is 250 milliseconds. A more nuanced implementation's default delay is 250 milliseconds. A more nuanced implementation's
delay should correspond to the time when the previous attempt is delay should correspond to the time when the previous attempt is
sending its second TCP SYN, based on TCP's retransmission timer sending its second TCP SYN, based on TCP's retransmission timer
[RFC6298]. If the client has historical RTT data gathered from other [RFC6298]. If the client has historical RTT data gathered from other
connections to the same host or prefix, it can use this information connections to the same host or prefix, it can use this information
skipping to change at page 9, line 34 skipping to change at page 9, line 34
responses for AAAA records in order to synthesize, they will not responses for AAAA records in order to synthesize, they will not
synthesize records for these particular host names, and will instead synthesize records for these particular host names, and will instead
pass through the broken AAAA record. pass through the broken AAAA record.
In order to support these scenarios, the client device needs to query In order to support these scenarios, the client device needs to query
the DNS for the A record then perform local synthesis. Since these the DNS for the A record then perform local synthesis. Since these
types of host names are rare, and in order to minimize load on DNS types of host names are rare, and in order to minimize load on DNS
servers, this A query should only be performed when the client has servers, this A query should only be performed when the client has
given up on the AAAA records it initially received. This can be given up on the AAAA records it initially received. This can be
achieved by using a longer timeout, referred to as the "Last Resort achieved by using a longer timeout, referred to as the "Last Resort
Local Synthesis Delay" and RECOMMENDED at 2 seconds. The timer is Local Synthesis Delay" and recommended to be 2 seconds. The timer is
started when the last connection attempt is fired. If no connection started when the last connection attempt is fired. If no connection
attempt has succeeded when this timer fires, the device queries the attempt has succeeded when this timer fires, the device queries the
DNS for the IPv4 address and on reception of a valid A record, treats DNS for the IPv4 address and on reception of a valid A record, treats
it as if it were provided by the application (Section 7.1). it as if it were provided by the application (Section 7.1).
7.3. Virtual Private Networks 7.3. Virtual Private Networks
Some Virtual Private Networks (VPN) may be configured to handle DNS Some Virtual Private Networks (VPN) may be configured to handle DNS
queries from the device. The configuration could encompass all queries from the device. The configuration could encompass all
queries, or a subset such as "*.internal.example.com". These VPNs queries, or a subset such as "*.internal.example.com". These VPNs
skipping to change at page 11, line 11 skipping to change at page 11, line 11
resolve the A record using the company's resolver then locally resolve the A record using the company's resolver then locally
synthesize an IPv6 address, as if the resolved IPv4 address were synthesize an IPv6 address, as if the resolved IPv4 address were
provided by the application (Section 7.1). provided by the application (Section 7.1).
8. Summary of Configurable Values 8. Summary of Configurable Values
The values that may be configured as defaults on a client for use in The values that may be configured as defaults on a client for use in
Happy Eyeballs are as follows: Happy Eyeballs are as follows:
o Resolution Delay (Section 3): The time to wait for a AAAA response o Resolution Delay (Section 3): The time to wait for a AAAA response
after receiving an A response. RECOMMENDED at 50 milliseconds. after receiving an A response. Recommended to be 50 milliseconds.
o First Address Family Count (Section 4): The number of addresses o First Address Family Count (Section 4): The number of addresses
belonging to the first address family (such as IPv6) that should belonging to the first address family (such as IPv6) that should
be attempted before attempting another address family. be attempted before attempting another address family.
RECOMMENDED as 1, or 2 to more aggressively favor one address Recommended to be 1, or 2 to more aggressively favor one address
family. family.
o Connection Attempt Delay (Section 5): The time to wait between o Connection Attempt Delay (Section 5): The time to wait between
connection attempts in the absence of RTT data. RECOMMENDED at connection attempts in the absence of RTT data. Recommended to be
250 milliseconds. 250 milliseconds.
o Minimum Connection Attempt Delay (Section 5): The minimum time to o Minimum Connection Attempt Delay (Section 5): The minimum time to
wait between connection attempts. RECOMMENDED at 100 wait between connection attempts. Recommended to be 100
milliseconds. MUST NOT be less than 10 milliseconds. milliseconds. MUST NOT be less than 10 milliseconds.
o Maximum Connection Attempt Delay (Section 5): The maximum time to o Maximum Connection Attempt Delay (Section 5): The maximum time to
wait between connection attempts. RECOMMENDED at 2 seconds. wait between connection attempts. Recommended to be 2 seconds.
o Last Resort Local Synthesis Delay (Section 7.2): The time to wait o Last Resort Local Synthesis Delay (Section 7.2): The time to wait
after starting the last IPv6 attempt and before sending the A after starting the last IPv6 attempt and before sending the A
query. RECOMMENDED at 2 seconds. query. Recommended to be 2 seconds.
The delay values described in this section were determined The delay values described in this section were determined
empirically by measuring the timing of connections on a very wide set empirically by measuring the timing of connections on a very wide set
of production devices. They were picked to reduce wait times noticed of production devices. They were picked to reduce wait times noticed
by users while minimizing load on the network. As time passes, it is by users while minimizing load on the network. As time passes, it is
expected that the properties of networks will evolve. For that expected that the properties of networks will evolve. For that
reason, it is expected that these values will change over time. reason, it is expected that these values will change over time.
Implementors should feel welcome to use different values without Implementors should feel welcome to use different values without
changing this specification. Since IPv6 issues are expected to be changing this specification. Since IPv6 issues are expected to be
less common, the delays SHOULD be increased with time as client less common, the delays SHOULD be increased with time as client
skipping to change at page 12, line 31 skipping to change at page 12, line 31
It has been observed in practice that Happy Eyeballs can hide issues It has been observed in practice that Happy Eyeballs can hide issues
in networks. For example, if a misconfiguration causes IPv6 to in networks. For example, if a misconfiguration causes IPv6 to
consistently fail on a given network while IPv4 is still functional, consistently fail on a given network while IPv4 is still functional,
Happy Eyeballs may impair the operator's ability to notice the issue. Happy Eyeballs may impair the operator's ability to notice the issue.
It is recommended that network operators deploy external means of It is recommended that network operators deploy external means of
monitoring to ensure functionality of all address families. monitoring to ensure functionality of all address families.
10. Security Considerations 10. Security Considerations
This memo has no direct security considerations.
Note that applications should not rely upon a stable hostname-to- Note that applications should not rely upon a stable hostname-to-
address mapping to ensure any security properties, since DNS results address mapping to ensure any security properties, since DNS results
may change between queries. Happy Eyeballs may make it more likely may change between queries. Happy Eyeballs may make it more likely
that subsequent connections to a single hostname use different IP that subsequent connections to a single hostname use different IP
addresses. addresses.
11. IANA Considerations 11. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
skipping to change at page 14, line 24 skipping to change at page 14, line 10
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>. <https://www.rfc-editor.org/info/rfc6724>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC7050, November 2013, RFC 7050, DOI 10.17487/RFC7050, November 2013,
<https://www.rfc-editor.org/info/rfc7050>. <https://www.rfc-editor.org/info/rfc7050>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References 13.2. Informative References
[DNS-PUSH] [DNS-PUSH]
Pusateri, T. and S. Cheshire, "DNS Push Notifications", Pusateri, T. and S. Cheshire, "DNS Push Notifications",
Work in Progress, draft-ietf-dnssd-push, March 2017. Work in Progress, draft-ietf-dnssd-push, March 2017.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013, RFC 6877, DOI 10.17487/RFC6877, April 2013,
<https://www.rfc-editor.org/info/rfc6877>. <https://www.rfc-editor.org/info/rfc6877>.
skipping to change at page 15, line 4 skipping to change at page 14, line 43
Appendix A. Differences from RFC6555 Appendix A. Differences from RFC6555
"Happy Eyeballs: Success with Dual-Stack Hosts" [RFC6555] mostly "Happy Eyeballs: Success with Dual-Stack Hosts" [RFC6555] mostly
concentrates on how to stagger connections to a hostname that has an concentrates on how to stagger connections to a hostname that has an
AAAA and an A record. This document additionally discusses: AAAA and an A record. This document additionally discusses:
o how to perform DNS queries to obtain these addresses o how to perform DNS queries to obtain these addresses
o how to handle multiple addresses from each address family o how to handle multiple addresses from each address family
o how to handle DNS updates while connections are being raced o how to handle DNS updates while connections are being raced
o how to leverage historical information o how to leverage historical information
o how to support IPv6-only networks with NAT64 and DNS64 o how to support IPv6-only networks with NAT64 and DNS64
Note that a simple implementation of the algorithm described in this
document is still compliant with the previous specification
[RFC6555]. Implementations should take the new considerations into
account when applicable to optimize their behavior.
Authors' Addresses Authors' Addresses
David Schinazi David Schinazi
Apple Inc. Apple Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, California 95014 Cupertino, California 95014
US US
Email: dschinazi@apple.com Email: dschinazi@apple.com
 End of changes. 22 change blocks. 
41 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/