--------------------- PatchSet 4143 Date: 2007/04/02 12:47:45 Author: amosjeffries Branch: squid3-ipv6 Tag: (none) Log: RFC3226 affecting expected DNS changes. RFC3596 obsoletes RFC3152 Members: NOTES-IPv6:1.1.2.10->1.1.2.11 doc/rfc/rfc3152.txt:1.1.2.1->1.1.2.2(DEAD) doc/rfc/rfc3226.txt:1.1->1.1.2.1 doc/rfc/rfc3596.txt:1.1->1.1.2.1 Index: squid3/NOTES-IPv6 =================================================================== RCS file: /cvsroot/squid-sf//squid3/Attic/NOTES-IPv6,v retrieving revision 1.1.2.10 retrieving revision 1.1.2.11 diff -u -r1.1.2.10 -r1.1.2.11 --- squid3/NOTES-IPv6 1 Apr 2007 05:38:33 -0000 1.1.2.10 +++ squid3/NOTES-IPv6 2 Apr 2007 12:47:45 -0000 1.1.2.11 @@ -1,4 +1,4 @@ -$Id: NOTES-IPv6,v 1.1.2.10 2007/04/01 05:38:33 amosjeffries Exp $ +$Id: NOTES-IPv6,v 1.1.2.11 2007/04/02 12:47:45 amosjeffries Exp $ KNOWN BUGS: @@ -19,4 +19,10 @@ 3 Determin what plumbing can still be passed up immediately to simplify -4 find more, bugs etc ??? +4.1 Write an rfc3596 DNS Resolver library (IPv6 partner to lib/rfc1035.c ) + defines AAAA records and IPv6 rDNS + +4.2 Write an rfc2874/3266 DNS Resolver library (IPv6 DNS extensions ) + defines A6, DNAME, packet sizes + +5 find more, bugs etc ??? --- squid3/doc/rfc/rfc3152.txt Tue Apr 3 00:23:33 2007 +++ /dev/null Tue Apr 3 00:23:33 2007 @@ -1,227 +0,0 @@ - - - - - - -Network Working Group R. Bush -Request for Comments: 3152 RGnet -BCP: 49 August 2001 -Updates: 2874, 2772, 2766, 2553, 1886 -Category: Best Current Practice - - - Delegation of IP6.ARPA - -Status of this Memo - - This document specifies an Internet Best Current Practices for the - Internet Community, and requests discussion and suggestions for - improvements. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2001). All Rights Reserved. - -Abstract - - This document discusses the need for delegation of the IP6.ARPA DNS - zone, and specifies a plan for the technical operation thereof. - -1. Why IP6.ARPA? - - In the IPv6 address space, there is a need for 'reverse mapping' of - addresses to DNS names analogous to that provided by the IN-ADDR.ARPA - zone for IPv4. - - The IAB recommended that the ARPA top level domain (the name is now - considered an acronym for "Address and Routing Parameters Area") be - used for technical infrastructure sub-domains when possible. It is - already in use for IPv4 reverse mapping and has been established as - the location for E.164 numbering on the Internet [RFC2916 RFC3026]. - - IETF consensus was reached that the IP6.ARPA domain be used for - address to DNS name mapping for the IPv6 address space [RFC2874]. - -2. Obsoleted Usage - - This document deprecates references to IP6.INT in [RFC1886] section - 2.5, [RFC2553] section 6.2.3, [RFC2766] section 4.1, [RFC2772] - section 7.1.c, and [RFC2874] section 2.5. - - In this context, 'deprecate' means that the old usage is not - appropriate for new implementations, and IP6.INT will likely be - phased out in an orderly fashion. - - - -Bush Best Current Practice [Page 1] - -RFC 3152 Delegation of IP6.ARPA August 2001 - - -3. IANA Considerations - - This memo requests that the IANA delegate the IP6.ARPA domain - following instructions to be provided by the IAB. Names within this - zone are to be further delegated to the regional IP registries in - accordance with the delegation of IPv6 address space to those - registries. The names allocated should be hierarchic in accordance - with the address space assignment. - -4. Security Considerations - - While DNS spoofing of address to name mapping has been exploited in - IPv4, delegation of the IP6.ARPA zone creates no new threats to the - security of the internet. - -5. References - - [RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP - version 6", RFC 1886, December 1995. - - [RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, - "Basic Socket Interface Extensions for IPv6", RFC 2553, - March 1999. - - [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address - Translation - Protocol Translation (NAT-PT)", RFC 2766, - February 2000. - - [RFC2772] Rockell, R. and R. Fink, "6Bone Backbone Routing - Guidelines", RFC 2772, February 2000. - - [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support - IPv6 Address Aggregation and Renumbering", RFC 2874, July - 2001. - - [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, - September 2000. - - [RFC3026] Blane, R., "Liaison to IETF/ISOC on ENUM", RFC 3026, - January 2001. - - - - - - - - - - - -Bush Best Current Practice [Page 2] - -RFC 3152 Delegation of IP6.ARPA August 2001 - - -6. Author's Address - - Randy Bush - 5147 Crystal Springs - Bainbridge Island, WA US-98110 - - Phone: +1 206 780 0431 - EMail: randy@psg.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bush Best Current Practice [Page 3] - -RFC 3152 Delegation of IP6.ARPA August 2001 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2001). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Bush Best Current Practice [Page 4] - --- /dev/null Tue Apr 3 00:23:33 2007 +++ squid3/doc/rfc/rfc3226.txt Tue Apr 3 00:23:34 2007 @@ -0,0 +1,339 @@ + + + + + + +Network Working Group O. Gudmundsson +Request for Comments: 3226 December 2001 +Updates: 2874, 2535 +Category: Standards Track + + + DNSSEC and IPv6 A6 aware server/resolver message size requirements + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + This document mandates support for EDNS0 (Extension Mechanisms for + DNS) in DNS entities claiming to support either DNS Security + Extensions or A6 records. This requirement is necessary because + these new features increase the size of DNS messages. If EDNS0 is + not supported fall back to TCP will happen, having a detrimental + impact on query latency and DNS server load. This document updates + RFC 2535 and RFC 2874, by adding new requirements. + +1. Introduction + + Familiarity with the DNS [RFC1034, RFC1035], DNS Security Extensions + [RFC2535], EDNS0 [RFC2671] and A6 [RFC2874] is helpful. + + STD 13, RFC 1035 Section 2.3.4 requires that DNS messages over UDP + have a data payload of 512 octets or less. Most DNS software today + will not accept larger UDP datagrams. Any answer that requires more + than 512 octets, results in a partial and sometimes useless reply + with the Truncation Bit set; in most cases the requester will then + retry using TCP. Furthermore, server delivery of truncated responses + varies widely and resolver handling of these responses also varies, + leading to additional inefficiencies in handling truncation. + + Compared to UDP, TCP is an expensive protocol to use for a simple + transaction like DNS: a TCP connection requires 5 packets for setup + and tear down, excluding data packets, thus requiring at least 3 + round trips on top of the one for the original UDP query. The DNS + + + +Gudmundsson Standards Track [Page 1] + +RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 + + + server also needs to keep a state of the connection during this + transaction. Many DNS servers answer thousands of queries per + second, requiring them to use TCP will cause significant overhead and + delays. + +1.1. Requirements + + The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" + in this document are to be interpreted as described in RFC 2119. + +2. Motivating factors + +2.1. DNSSEC motivations + + DNSSEC [RFC2535] secures DNS by adding a Public Key signature on each + RR set. These signatures range in size from about 80 octets to 800 + octets, most are going to be in the range of 80 to 200 octets. The + addition of signatures on each or most RR sets in an answer + significantly increases the size of DNS answers from secure zones. + + For performance reasons and to reduce load on DNS servers, it is + important that security aware servers and resolvers get all the data + in Answer and Authority section in one query without truncation. + Sending Additional Data in the same query is helpful when the server + is authoritative for the data, and this reduces round trips. + + DNSSEC OK[OK] specifies how a client can, using EDNS0, indicate that + it is interested in receiving DNSSEC records. The OK bit does not + eliminate the need for large answers for DNSSEC capable clients. + +2.1.1. Message authentication or TSIG motivation + + TSIG [RFC2845] allows for the light weight authentication of DNS + messages, but increases the size of the messages by at least 70 + octets. DNSSEC specifies for computationally expensive message + authentication SIG(0) using a standard public key signature. As only + one TSIG or SIG(0) can be attached to each DNS answer the size + increase of message authentication is not significant, but may still + lead to a truncation. + +2.2. IPv6 Motivations + + IPv6 addresses [RFC2874] are 128 bits and can be represented in the + DNS by multiple A6 records, each consisting of a domain name and a + bit field. The domain name refers to an address prefix that may + require additional A6 RRs to be included in the answer. Answers + where the queried name has multiple A6 addresses may overflow a 512- + octet UDP packet size. + + + +Gudmundsson Standards Track [Page 2] + +RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 + + +2.3. Root server and TLD server motivations + + The current number of root servers is limited to 13 as that is the + maximum number of name servers and their address records that fit in + one 512-octet answer for a SOA record. If root servers start + advertising A6 or KEY records then the answer for the root NS records + will not fit in a single 512-octet DNS message, resulting in a large + number of TCP query connections to the root servers. Even if all + client resolver query their local name server for information, there + are millions of these servers. Each name server must periodically + update its information about the high level servers. + + For redundancy, latency and load balancing reasons, large numbers of + DNS servers are required for some zones. Since the root zone is used + by the entire net, it is important to have as many servers as + possible. Large TLDs (and many high-visibility SLDs) often have + enough servers that either A6 or KEY records would cause the NS + response to overflow the 512 byte limit. Note that these zones with + large numbers of servers are often exactly those zones that are + critical to network operation and that already sustain fairly high + loads. + +2.4. UDP vs TCP for DNS messages + + Given all these factors, it is essential that any implementation that + supports DNSSEC and or A6 be able to use larger DNS messages than 512 + octets. + + The original 512 restriction was put in place to reduce the + probability of fragmentation of DNS responses. A fragmented UDP + message that suffers a loss of one of the fragments renders the + answer useless and the query must be retried. A TCP connection + requires a larger number of round trips for establishment, data + transfer and tear down, but only the lost data segments are + retransmitted. + + In the early days a number of IP implementations did not handle + fragmentation well, but all modern operating systems have overcome + that issue thus sending fragmented messages is fine from that + standpoint. The open issue is the effect of losses on fragmented + messages. If connection has high loss ratio only TCP will allow + reliable transfer of DNS data, most links have low loss ratios thus + sending fragmented UDP packet in one round trip is better than + establishing a TCP connection to transfer a few thousand octets. + + + + + + + +Gudmundsson Standards Track [Page 3] + +RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 + + +2.5. EDNS0 and large UDP messages + + EDNS0 [RFC2671] allows clients to declare the maximum size of UDP + message they are willing to handle. Thus, if the expected answer is + between 512 octets and the maximum size that the client can accept, + the additional overhead of a TCP connection can be avoided. + +3. Protocol changes: + + This document updates RFC 2535 and RFC 2874, by adding new + requirements. + + All RFC 2535 compliant servers and resolvers MUST support EDNS0 and + advertise message size of at least 1220 octets, but SHOULD advertise + message size of 4000. This value might be too low to get full + answers for high level servers and successor of this document may + require a larger value. + + All RFC 2874 compliant servers and resolver MUST support EDNS0 and + advertise message size of at least 1024 octets, but SHOULD advertise + message size of 2048. The IPv6 datagrams should be 1024 octets, + unless the MTU of the path is known. (Note that this is smaller than + the minimum IPv6 MTU to allow for some extension headers and/or + encapsulation without exceeding the minimum MTU.) + + All RFC 2535 and RFC 2874 compliant entities MUST be able to handle + fragmented IPv4 and IPv6 UDP packets. + + All hosts supporting both RFC 2535 and RFC 2874 MUST use the larger + required value in EDNS0 advertisements. + +4. Acknowledgments + + Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas + Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward Lewis + Michael Patton and Kazu Yamamoto were instrumental in motivating and + shaping this document. + +5. Security Considerations: + + There are no additional security considerations other than those in + RFC 2671. + +6. IANA Considerations: + + None + + + + + +Gudmundsson Standards Track [Page 4] + +RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 + + +7. References + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [RFC2535] Eastlake, D. "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + + [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support + IPv6 Address Aggregation and Renumbering", RFC 2874, July + 2000. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + +8. Author Address + + Olafur Gudmundsson + 3826 Legation Street, NW + Washington, DC 20015 + USA + + EMail: ogud@ogud.com + + + + + + + + + + + + + + + + + + +Gudmundsson Standards Track [Page 5] + +RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Gudmundsson Standards Track [Page 6] + --- /dev/null Tue Apr 3 00:23:33 2007 +++ squid3/doc/rfc/rfc3596.txt Tue Apr 3 00:23:34 2007 @@ -0,0 +1,451 @@ + + + + + + +Network Working Group S. Thomson +Request for Comments: 3596 Cisco +Obsoletes: 3152, 1886 C. Huitema +Category: Standards Track Microsoft + V. Ksinant + 6WIND + M. Souissi + AFNIC + October 2003 + + + DNS Extensions to Support IP Version 6 + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document defines the changes that need to be made to the Domain + Name System (DNS) to support hosts running IP version 6 (IPv6). The + changes include a resource record type to store an IPv6 address, a + domain to support lookups based on an IPv6 address, and updated + definitions of existing query types that return Internet addresses as + part of additional section processing. The extensions are designed + to be compatible with existing applications and, in particular, DNS + implementations themselves. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. New resource record definition and domain. . . . . . . . . . . 2 + 2.1. AAAA record type . . . . . . . . . . . . . . . . . . . . 3 + 2.2. AAAA data format . . . . . . . . . . . . . . . . . . . . 3 + 2.3. AAAA query . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.4. Textual format of AAAA records . . . . . . . . . . . . . 3 + 2.5. IP6.ARPA domain. . . . . . . . . . . . . . . . . . . . . 3 + 3. Modifications to existing query types. . . . . . . . . . . . . 4 + 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 4 + 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 4 + + + +Thomson, et al. Standards Track [Page 1] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + + 6. Intellectual Property Statement. . . . . . . . . . . . . . . . 4 + Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 5 + Appendix A: Changes from RFC 1886. . . . . . . . . . . . . . . . . 6 + Normative References . . . . . . . . . . . . . . . . . . . . . . . 6 + Informative References . . . . . . . . . . . . . . . . . . . . . . 6 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8 + +1. Introduction + + Current support for the storage of Internet addresses in the Domain + Name System (DNS) [1,2] cannot easily be extended to support IPv6 + addresses [3] since applications assume that address queries return + 32-bit IPv4 addresses only. + + To support the storage of IPv6 addresses in the DNS, this document + defines the following extensions: + + o A resource record type is defined to map a domain name to an + IPv6 address. + + o A domain is defined to support lookups based on address. + + o Existing queries that perform additional section processing to + locate IPv4 addresses are redefined to perform additional + section processing on both IPv4 and IPv6 addresses. + + The changes are designed to be compatible with existing software. + The existing support for IPv4 addresses is retained. Transition + issues related to the co-existence of both IPv4 and IPv6 addresses in + the DNS are discussed in [4]. + + The IP protocol version used for querying resource records is + independent of the protocol version of the resource records; e.g., + IPv4 transport can be used to query IPv6 records and vice versa. + + This document combines RFC 1886 [5] and changes to RFC 1886 made by + RFC 3152 [6], obsoleting both. Changes mainly consist in replacing + the IP6.INT domain by IP6.ARPA as defined in RFC 3152. + +2. New resource record definition and domain + + A record type is defined to store a host's IPv6 address. A host that + has more than one IPv6 address must have more than one such record. + + + + + + + +Thomson, et al. Standards Track [Page 2] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +2.1 AAAA record type + + The AAAA resource record type is a record specific to the Internet + class that stores a single IPv6 address. + + The IANA assigned value of the type is 28 (decimal). + +2.2 AAAA data format + + A 128 bit IPv6 address is encoded in the data portion of an AAAA + resource record in network byte order (high-order byte first). + +2.3 AAAA query + + An AAAA query for a specified domain name in the Internet class + returns all associated AAAA resource records in the answer section of + a response. + + A type AAAA query does not trigger additional section processing. + +2.4 Textual format of AAAA records + + The textual representation of the data portion of the AAAA resource + record used in a master database file is the textual representation + of an IPv6 address as defined in [3]. + +2.5 IP6.ARPA Domain + + A special domain is defined to look up a record given an IPv6 + address. The intent of this domain is to provide a way of mapping an + IPv6 address to a host name, although it may be used for other + purposes as well. The domain is rooted at IP6.ARPA. + + An IPv6 address is represented as a name in the IP6.ARPA domain by a + sequence of nibbles separated by dots with the suffix ".IP6.ARPA". + The sequence of nibbles is encoded in reverse order, i.e., the + low-order nibble is encoded first, followed by the next low-order + nibble and so on. Each nibble is represented by a hexadecimal digit. + For example, the reverse lookup domain name corresponding to the + address + + 4321:0:1:2:3:4:567:89ab + + would be + + b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6. + ARPA. + + + + +Thomson, et al. Standards Track [Page 3] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +3. Modifications to existing query types + + All existing query types that perform type A additional section + processing, i.e., name server (NS), location of services (SRV) and + mail exchange (MX) query types, must be redefined to perform both + type A and type AAAA additional section processing. These + definitions mean that a name server must add any relevant IPv4 + addresses and any relevant IPv6 addresses available locally to the + additional section of a response when processing any one of the above + queries. + +4. Security Considerations + + Any information obtained from the DNS must be regarded as unsafe + unless techniques specified in [7] or [8] are used. The definitions + of the AAAA record type and of the IP6.ARPA domain do not change the + model for use of these techniques. + + So, this specification is not believed to cause any new security + problems, nor to solve any existing ones. + +5. IANA Considerations + + There are no IANA assignments to be performed. + +6. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + +Thomson, et al. Standards Track [Page 4] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +Acknowledgments + + Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien + Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael Guerin + (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND), Frederic + Roudaut (IRISA) and G6 group for their help during the RFC 1886 + Interop tests sessions. + + Many thanks to Alain Durand and Olafur Gudmundsson for their support. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 5] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +Appendix A: Changes from RFC 1886 + + The following changes were made from RFC 1886 "DNS Extensions to + support IP version 6": + + - Replaced the "IP6.INT" domain by "IP6.ARPA". + - Mentioned SRV query types in section 3 "MODIFICATIONS TO + EXISTING QUERY TYPES" + - Added security considerations. + - Updated references : + * From RFC 1884 to RFC 3513 (IP Version 6 Addressing + Architecture). + * From "work in progress" to RFC 2893 (Transition Mechanisms for + IPv6 Hosts and Routers). + * Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845. + - Updated document abstract + - Added table of contents + - Added full copyright statement + - Added IANA considerations section + - Added Intellectual Property Statement + +Normative References + + [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + +Informative References + + [4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 + Hosts and Routers", RFC 2893, August 2000. + + [5] Thomson, S. and C. Huitema, "DNS Extensions to support IP + version 6", RFC 1886, December 1995. + + [6] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August + 2001. + + [7] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999 + + + + + + +Thomson, et al. Standards Track [Page 6] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + + [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + +Authors' Addresses + + Susan Thomson + Cisco Systems + 499 Thornall Street, 8th floor + Edison, NJ 08837 + + Phone: +1 732-635-3086 + EMail: sethomso@cisco.com + + + Christian Huitema + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052-6399 + + EMail: huitema@microsoft.com + + + Vladimir Ksinant + 6WIND S.A. + Immeuble Central Gare - Bat.C + 1, place Charles de Gaulle + 78180, Montigny-Le-Bretonneux - France + + Phone: +33 1 39 30 92 36 + EMail: vladimir.ksinant@6wind.com + + + Mohsen Souissi + AFNIC + Immeuble International + 2, rue Stephenson, + 78181, Saint-Quentin en Yvelines Cedex - France + + Phone: +33 1 39 30 83 40 + EMail: Mohsen.Souissi@nic.fr + + + + + + + + + + +Thomson, et al. Standards Track [Page 7] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 8] +