--- 1/draft-ietf-mboned-driad-amt-discovery-10.txt 2019-12-18 15:13:16.198971725 -0800 +++ 2/draft-ietf-mboned-driad-amt-discovery-11.txt 2019-12-18 15:13:16.278973774 -0800 @@ -1,46 +1,48 @@ Mboned J. Holland Internet-Draft Akamai Technologies, Inc. -Updates: 7450 (if approved) December 12, 2019 +Updates: 7450 (if approved) December 18, 2019 Intended status: Standards Track -Expires: June 14, 2020 +Expires: June 20, 2020 - DNS Reverse IP AMT Discovery - draft-ietf-mboned-driad-amt-discovery-10 + DNS Reverse IP AMT (Automatic Multicast Tunneling) Discovery + draft-ietf-mboned-driad-amt-discovery-11 Abstract This document updates RFC 7450 (Automatic Multicast Tunneling, or - AMT) by extending the relay discovery process to use a new DNS - resource record named AMTRELAY when discovering AMT relays for + AMT) by modifying the relay discovery process. A new DNS resource + record named AMTRELAY is defined for publishing AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicast sender's IP address is configured to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward - multicast traffic from that sender over an AMT tunnel. + multicast traffic from that sender over an AMT tunnel. Other + extensions and clarifications to the relay discovery process are also + defined. 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 https://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 June 14, 2020. + This Internet-Draft will expire on June 20, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -50,69 +52,70 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.1. Relays and Gateways . . . . . . . . . . . . . . . . . 4 1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4 - 2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 5 + 2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 6 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6 - 2.3. Optimal Relay Selection . . . . . . . . . . . . . . . . . 8 - 2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 8 + 2.3. Optimal Relay Selection . . . . . . . . . . . . . . . . . 9 + 2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 9 2.3.2. Preference Ordering . . . . . . . . . . . . . . . . . 10 - 2.3.3. Connecting to Multiple Relays . . . . . . . . . . . . 12 - 2.4. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 12 + 2.3.3. Connecting to Multiple Relays . . . . . . . . . . . . 13 + 2.4. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 13 2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13 2.4.2. Algorithm Guidelines . . . . . . . . . . . . . . . . 13 2.4.3. Connection Definition . . . . . . . . . . . . . . . . 14 2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 15 2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 15 - 2.5.2. Updates to Restarting Events . . . . . . . . . . . . 15 - 2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 16 + 2.5.2. Updates to Restarting Events . . . . . . . . . . . . 16 + 2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 17 2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 17 - 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 18 + 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 19 2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 19 - 2.5.7. Independent Discovery Per Traffic Source . . . . . . 19 + 2.5.7. Independent Discovery Per Traffic Source . . . . . . 20 2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 20 2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 20 - 3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 20 - 3.1. Example Receiving Networks . . . . . . . . . . . . . . . 20 + 3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 21 + 3.1. Example Receiving Networks . . . . . . . . . . . . . . . 21 3.1.1. Internet Service Provider . . . . . . . . . . . . . . 21 3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 22 - 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 23 - 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 23 - 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 24 - 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 25 - 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 25 - 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 25 - 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 26 - 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 26 - 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 26 - 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 27 - 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 27 - 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 27 - 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 28 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 - 6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 29 - 6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 29 - 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 30 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 30 - 8.2. Informative References . . . . . . . . . . . . . . . . . 32 - Appendix A. Unknown RRType construction . . . . . . . . . . . . 34 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35 + 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 24 + 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 24 + 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 25 + 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 26 + 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 26 + 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 26 + 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 27 + 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 27 + 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 27 + 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 28 + + 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 28 + 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 28 + 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 29 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 + 6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 30 + 6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 30 + 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 31 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 31 + 8.2. Informative References . . . . . . . . . . . . . . . . . 33 + Appendix A. Unknown RRType construction . . . . . . . . . . . . 35 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction This document defines DNS Reverse IP AMT Discovery (DRIAD), a mechanism for AMT gateways to discover AMT relays that are capable of forwarding multicast traffic from a known source IP address. AMT (Automatic Multicast Tunneling) is defined in [RFC7450], and provides a method to transport multicast traffic over a unicast tunnel, in order to traverse non-multicast-capable network segments. @@ -199,29 +202,34 @@ | | | | RR | A DNS Resource Record, as described in [RFC1034] | | | | | RRType | A DNS Resource Record Type, as described in | | | [RFC1034] | | | | | SSM | Source-specific multicast, as described in [RFC4607] | | | | | upstream | Closer to the source of traffic, as described in | | | [RFC7450]. | + | | | + | CMTS | Cable Modem Termination System | + | | | + | OLT | Optical Line Terminal | +------------+------------------------------------------------------+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Relay Discovery Operation + 2.1. Overview The AMTRELAY resource record (RR) defined in this document is used to publish the IP address or domain name of a set of AMT relays or discovery brokers that can receive, encapsulate, and forward multicast traffic from a particular sender. The sender is the owner of the RR, and configures the zone so that it contains a set of RRs that provide the addresses or domain names of AMT relays (or discovery brokers that advertise relays) that can @@ -279,47 +287,48 @@ +---------------+ | Sender | | | | 198.51.100.15 | | | +---------------+ |Data| | |Flow| Multicast | \| |/ Network | \ / | 5: Propagate RPF for Join(S,G) \ / +---------------+ \/ | AMT Relay | - | 203.0.113.15 | + | 2001:db8::f | +---------------+ | 4: Gateway connects to Relay, sends Join(S,G) over tunnel | Unicast Tunnel | ^ | 3: --> DNS Query: type=AMTRELAY, | / 15.100.51.198.in-addr.arpa. | | / <-- Response: - Join/Leave +-------------+ AMTRELAY=203.0.113.15 + Join/Leave +-------------+ AMTRELAY=2001:db8::f Signals | AMT gateway | | +-------------+ | | 2: Propagate RPF for Join(S,G) | Multicast | Network | - | 1: Join(S=198.51.100.15, G) + | 1: Join(S=198.51.100.15,G=232.252.0.2) +-------------+ | Receiver | | (end user) | +-------------+ Figure 2: DRIAD Messaging - In this simple example, the sender IP is 198.51.100.15, and the relay - IP is 203.0.113.15. + In this simple example, the sender IP is 198.51.100.15, it is sending + traffic to the group address 232.252.0.2, and the relay IP is + 2001:db8::f. The content provider has previously configured the DNS zone that contains the domain name "15.100.51.198.in-addr.arpa.", which is the reverse lookup domain name for his sender. The zone file contains an AMTRELAY RR with the Relay's IP address. (See Section 4.3 for details about the AMTRELAY RR format and semantics.) The sequence of events depicted in Figure 2 is as follows: 1. The end user starts the app, which issues a join to the (S,G): @@ -332,31 +341,42 @@ 3. The AMT gateway performs a reverse DNS lookup for the AMTRELAY RRType, by sending an AMTRELAY RRType query for the FQDN "15.100.51.198.in-addr.arpa.", using the reverse IP domain name for the sender's source IP address (the S from the (S,G)), as described in Section 3.5 of [RFC1035]. The DNS resolver for the AMT gateway uses ordinary DNS recursive resolution until it has the authoritative result that the content provider configured, which informs the AMT gateway that the relay - address is 203.0.113.15. + address is 2001:db8::f. 4. The AMT gateway performs AMT handshakes with the AMT relay as described in Section 4 of [RFC7450], then forwards a Membership report to the relay indicating subscription to the (S,G). 5. The relay propagates the join through its network toward the sender, then forwards the appropriate AMT-encapsulated traffic to the gateway, which decapsulates and forwards it as native multicast through its downstream network to the end user. + In the case of an IPv6 (S,G), the only difference in the AMT relay + discovery process is the use of the ip6.arpa reverse IP domain name, + as described in Section 2.5 of [RFC3596]), instead of the in- + addr.arpa domain name. + + For example, if the (S,G) is (2001:db8:c::f, ffe3::80fc:2), the + reverse domain name for the AMTRELAY query would be: + + f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.0.0.0.8.b.d.0.1.0.0.2.ip6. + arpa. + 2.3. Optimal Relay Selection 2.3.1. Overview The reverse source IP DNS query of an AMTRELAY RR is a good way for a gateway to discover a relay that is known to the sender. However, it is NOT necessarily a good way to discover the best relay for that gateway to use, because the RR will only provide information about relays known to the source. @@ -492,38 +511,43 @@ 1. DNS-SD 2. Anycast addresses from Section 7 of [RFC7450] 3. DRIAD This default behavior MAY be overridden by administrative configuration where other behavior is more appropriate for the gateway within its network. Among relay addresses that have an equivalent preference as described - above, a Happy Eyeballs algorithm for AMT MUST use the Destination - Address Selection defined in Section 6 of [RFC6724], as required by - [RFC8305]. + above, a Happy Eyeballs algorithm for AMT SHOULD use use the + Destination Address Selection defined in Section 6 of [RFC6724]. Among relay addresses that still have an equivalent preference after - the above orderings, a gateway MUST make a non-deterministic choice - for relay preference ordering, in order to support load balancing by - DNS configurations that provide many relay options. + the above orderings, a gateway SHOULD make a non-deterministic choice + (such as a pseudorandom selection) for relay preference ordering, in + order to support load balancing by DNS configurations that provide + many relay options. The gateway MAY introduce a bias in the non-deterministic choice according to information obtained out of band or from a historical record about network topology, timing information, or the response to a probing mechanism, that indicates some expected benefits from selecting some relays in preference to others. Details about the structure and collection of this information are out of scope for this document, but a gateway in possession of such information MAY use it to prefer topologically closer relays. + Within the above constraints, gateways MAY make use of other + considerations from Section 4 of [RFC8305], such as the address + family interleaving strategies, to produce a final ordering of + candidate relay addresses. + Note also that certain relay addresses might be excluded from consideration by the hold-down timers described in Section 2.5.4.1 or Section 2.5.5. These relays constitute "unusable destinations" under Rule 1 of the Destination Address Selection, and are also not part of the superseding considerations described above. The discovery and connection process for the relay addresses in the above described ordering MAY operate in parallel, subject to delays prescribed by the Happy Eyeballs requirements described in Section 5 of [RFC8305] for successively launched concurrent connection @@ -554,21 +579,21 @@ relays concurrently. The parallel discovery logic of a Happy Eyeballs algorithm serves to reduce join latency for the initial join of an SSM channel. This section and the preference ordering of relays defined in Section 2.3.2 taken together provide guidance on use of a Happy Eyeballs algorithm for the case of establishing AMT connections. Note that according to the definition in Section 2.4.3 of this document, establishing the connection occurs before sending a - membership report. As described in Section 5 of [RFC8085], only one + membership report. As described in Section 5 of [RFC8305], only one of the successful connections will be used, and the others are all canceled or ignored. In the context of an AMT connection, this means the gateway will send the membership reports that subscribe to traffic only for the chosen connection, after the Happy Eyeballs algorithm resolves. 2.4.2. Algorithm Guidelines During the "Initiation of asynchronous DNS queries" phase described in Section 3 of [RFC8305]), a gateway attempts to resolve the domain @@ -578,43 +603,45 @@ Each of the SRV and AMTRELAY responses might contain one or more IP addresses, (as with type 1 or type 2 AMTRELAY responses, or when the SRV Additional Data section of the SRV response contains the address records for the target, as urged by [RFC2782]), or they might contain only domain names (as with type 3 responses from Section 4.2.3, or an SRV response without an additional data section). When present, IP addresses in the initial response provide resolved destination address candidates for the "Sorting of resolved - destination addresses" phase described in Section 4 of [RFC8085]), + destination addresses" phase described in Section 4 of [RFC8305]), whereas domain names without IP addresses in the initial response result in another set of queries for AAAA and A records, whose responses provide the candidate resolved destination addresses. Since the SRV or AMTRELAY responses don't have a bound on the count of queries that might be generated aside from the bounds imposed by the DNS resolver, it's important for the gateway to provide a rate limit on the DNS queries. The DNS query functionality is expected to follow ordinary standards and best practices for DNS clients. A gateway MAY use an existing DNS client implementation that does so, and MAY rely on that client's rate limiting logic to avoid issuing excessive queries. Otherwise, a gateway MUST provide a rate limit - for the DNS queries, and its default settings MUST NOT permit more + for the DNS queries, and its default settings SHOULD NOT permit more than 10 queries for any 100-millisecond period (though this MAY be overridable by administrative configuration). As the resolved IP addresses arrive, the Happy Eyeballs algorithm sorts them according to the requirements and recommendations given in Section 2.3.2, and attempts connections with the corresponding relays - under the algorithm restrictions and guidelines given in [RFC8085] + under the algorithm restrictions and guidelines given in [RFC8305] for the "Establishment of one connection, which cancels all other - attempts" phase. + attempts" phase. As described in Section 3 of [RFC8305], DNS + resolution is treated as asynchronous, and connection initiation does + not wait for lagging DNS responses. 2.4.3. Connection Definition Section 5 of [RFC8305] non-normatively describes success at a connection attempt as "generally when the TCP handshake completes". There is no normative definition of a connection in the AMT specification [RFC7450], and there is no TCP connection involved in an AMT tunnel. @@ -699,22 +726,22 @@ 6. When the gateway wishes to report an (S,G) subscription with a source address that does not currently have other group subscriptions. 7. When there is a network change detected, for example when a gateway is operating inside an end user device or application, and the device joins a different network, or when the domain portion of a DNS-SD domain name changes in response to a DHCP message or administrative configuration. - 8. When congestion or substantial loss is detected in the stream of - AMT packets from a relay. + 8. When substantial loss, persistent congestion, or network overload + is detected in the stream of AMT packets from a relay. 9. When the gateway has reported one or more (S,G) subscriptions, but no traffic is received from the source for some timeout. (See Section 2.5.4.1). This list is not exhaustive, nor are any of the listed events strictly required to always force a restart of the discovery process. Note that during event #1, a gateway may use DNS-SD, but does not have sufficient information to use DRIAD, since no source is known. @@ -883,23 +910,24 @@ Often an AMT gateway will only have access to the source and group IP addresses of the desired traffic, and will not know any other name for the source of the traffic. Because of this, typically the best way of looking up AMTRELAY RRs will be by using the source IP address as an index into one of the reverse mapping trees (in-addr.arpa for IPv4, as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as described in Section 2.5 of [RFC3596]). Therefore, it is RECOMMENDED that AMTRELAY RRs be added to reverse IP zones as appropriate. AMTRELAY records MAY also appear in other - zones, but the primary intended use case requires a reverse IP - mapping for the source from an (S,G) in order to be useful to most - AMT gateways. + zones, since this may be necessary to perform delegation from the + reverse zones (see for example Section 5.2 of [RFC2317]), but the use + case enabled by this document requires a reverse IP mapping for the + source from an (S,G) in order to be useful to most AMT gateways. When performing the AMTRELAY RR lookup, any CNAMEs or DNAMEs found MUST be followed. This is necessary to support zone delegation. Some examples outlining this need are described in [RFC2317]. See Section 4 and Section 4.3 for a detailed explanation of the contents for a DNS Zone file. 2.7. Waiting for DNS resolution @@ -1076,21 +1105,21 @@ Internet (non-multicast) Figure 6: Small Office Example 3.2.2. Provider-controlled Relays When an ISP offers a service to transmit outbound multicast traffic through a forwarding network, it might also offer AMT relays in order to reach receivers without multicast connectivity to the forwarding - network, as in Figure 7. In this case it's RECOMMENDED that the ISP + network, as in Figure 7. In this case it's recommended that the ISP also provide at least one domain name for the AMT relays for use with the AMTRELAY RR. When the sender wishes to use the relays provided by the ISP for forwarding multicast traffic, an AMTRELAY RR should be configured to use the domain name provided by the ISP, to allow for address reassignment of the relays without forcing the sender to reconfigure the corresponding AMTRELAY RRs. +--------+ @@ -1237,21 +1266,21 @@ IN AMTRELAY precedence D-bit type relay 4.3.2. Examples In a DNS authoritative nameserver that understands the AMTRELAY type, the zone might contain a set of entries like this: $ORIGIN 100.51.198.in-addr.arpa. 10 IN AMTRELAY 10 0 1 203.0.113.15 - 10 IN AMTRELAY 10 0 2 2001:DB8::15 + 10 IN AMTRELAY 10 0 2 2001:db8::15 10 IN AMTRELAY 128 1 3 amtrelays.example.com. This configuration advertises an IPv4 discovery address, an IPv6 discovery address, and a domain name for AMT relays which can receive traffic from the source 198.51.100.10. The IPv4 and IPv6 addresses are configured with a D-bit of 0 (meaning discovery is mandatory, as described in Section 4.2.2), and a precedence 10 (meaning they're preferred ahead of the last entry, which has precedence 128). For zone files in name servers that don't support the AMTRELAY RRType @@ -1336,41 +1365,45 @@ If an AMT gateway accepts a maliciously crafted AMTRELAY record, the result could be a Denial of Service, or receivers processing multicast traffic from a source under the attacker's control. 6.3. Congestion Multicast traffic, particularly interdomain multicast traffic, carries some congestion risks, as described in Section 4 of [RFC8085]. - Application implementors and network operators that use DRIAD-capable - AMT gateways are advised to take precautions including monitoring of - application traffic behavior, traffic authentication at ingest, rate- - limiting of multicast traffic, and the use of circuit-breaker - techniques such as those described in Section 3.1.10 of [RFC8085] and - similar protections at the network level, in order to ensure network - health in the event of misconfiguration, poorly written applications - that don't follow UDP congestion control principles, or deliberate - attack. + Application implementors and network operators that use AMT gateways + are advised to take precautions including monitoring of application + traffic behavior, traffic authentication at ingest, rate-limiting of + multicast traffic, and the use of circuit-breaker techniques such as + those described in Section 3.1.10 of [RFC8085] and similar + protections at the network level, in order to ensure network health + in the event of misconfiguration, poorly written applications that + don't follow UDP congestion control principles, or deliberate attack. + + Section 4.1.4.2 of [RFC7450] and Section 6.1 of [RFC7450] provide + some further considerations and advice about mitigating congestion + risk. 7. Acknowledgements This specification was inspired by the previous work of Doug Nortz, Robert Sayko, David Segelstein, and Percy Tarapore, presented in the MBONED working group at IETF 93. Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill Atwood, Tim Chown, Warren Kumari, Dan Romanescu, Bernard Aboba, - Carlos Pignataro, and Niclas Comstedt for their very helpful reviews - and comments. + Carlos Pignataro, Niclas Comstedt, Mirja Kuehlewind, Henning Rogge, + Eric Vyncke, Barry Lieba, Roman Danyliw, Alissa Cooper, Suresh + Krishnan, and Adam Roach for their very helpful reviews and comments. 8. References 8.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and