From eab1b7cb5a18cc53dfc547df04b705c744da622f Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 7 Mar 2003 00:15:18 +0000 Subject: [PATCH] new draft --- ....txt => draft-ietf-dnsext-gss-tsig-06.txt} | 284 ++++++++++-------- ...xt => draft-ietf-dnsext-rfc1886bis-02.txt} | 73 +++-- 2 files changed, 194 insertions(+), 163 deletions(-) rename doc/draft/{draft-ietf-dnsext-gss-tsig-05.txt => draft-ietf-dnsext-gss-tsig-06.txt} (90%) rename doc/draft/{draft-ietf-dnsext-rfc1886bis-01.txt => draft-ietf-dnsext-rfc1886bis-02.txt} (87%) diff --git a/doc/draft/draft-ietf-dnsext-gss-tsig-05.txt b/doc/draft/draft-ietf-dnsext-gss-tsig-06.txt similarity index 90% rename from doc/draft/draft-ietf-dnsext-gss-tsig-05.txt rename to doc/draft/draft-ietf-dnsext-gss-tsig-06.txt index ee3b0391fd..f8438c0683 100644 --- a/doc/draft/draft-ietf-dnsext-gss-tsig-05.txt +++ b/doc/draft/draft-ietf-dnsext-gss-tsig-06.txt @@ -1,8 +1,8 @@ INTERNET-DRAFT Stuart Kwan - Praerit Garg -January 30, 2002 James Gilroy -Expires July 30, 2002 Levon Esibov + Praerit Garg +February 28, 2003 James Gilroy +Expires August 28, 2003 Levon Esibov Jeff Westhead Microsoft Corp. Randy Hall @@ -41,7 +41,8 @@ Abstract The TSIG protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service -Application Program Interface (GSS-API) (RFC2743). +Application Program Interface (GSS-API) (RFC2743). This document updates +RFC 2845. @@ -53,41 +54,40 @@ Application Program Interface (GSS-API) (RFC2743). +Expires August 28, 2003 [Page 1] -Expires July 30, 2002 [Page 1] - -INTERNET-DRAFT GSS-TSIG January 30, 2002 +INTERNET-DRAFT GSS-TSIG February 28, 2003 Table of Contents 1: Introduction......................................................2 2: Algorithm Overview................................................3 2.1: GSS Details...................................................4 + 2.2: Modifications to the TSIG protocol (RFC 2845).................4 3: Client Protocol Details...........................................4 - 3.1: Negotiating Context...........................................4 + 3.1: Negotiating Context...........................................5 3.1.1: Call GSS_Init_sec_context.................................5 - 3.1.2: Send TKEY Query to Server.................................6 + 3.1.2: Send TKEY Query to Server.................................7 3.1.3: Receive TKEY Query-Response from Server...................7 - 3.2: Context Established...........................................9 + 3.2: Context Established..........................................10 3.2.1: Terminating a Context....................................10 4: Server Protocol Details..........................................10 4.1: Negotiating Context..........................................10 - 4.1.1: Receive TKEY Query from Client...........................10 + 4.1.1: Receive TKEY Query from Client...........................11 4.1.2: Call GSS_Accept_sec_context..............................11 - 4.1.3: Send TKEY Query-Response to Client.......................11 + 4.1.3: Send TKEY Query-Response to Client.......................12 4.2: Context Established..........................................13 4.2.1: Terminating a Context....................................13 -5: Sending and Verifying Signed Messages............................13 - 5.1: Sending a Signed Message - Call GSS_GetMIC...................13 - 5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............14 -6: Example usage of GSS-TSIG algorithm..............................15 -7: Security Considerations..........................................19 -8: IANA Considerations..............................................19 -9: Conformance......................................................19 +5: Sending and Verifying Signed Messages............................14 + 5.1: Sending a Signed Message - Call GSS_GetMIC...................14 + 5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............15 +6: Example usage of GSS-TSIG algorithm..............................16 +7: Security Considerations..........................................20 +8: IANA Considerations..............................................20 +9: Conformance......................................................20 10:Acknowledgements.................................................20 11:References.......................................................20 - 1. Introduction The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845] @@ -112,9 +112,9 @@ over time. For example, a client and server MAY use Kerberos [RFC1964] for one transaction, whereas that same server MAY use SPKM [RFC2025] with a different client. -Expires July 30, 2002 [Page 2] +Expires August 28, 2003 [Page 2] -INTERNET-DRAFT GSS-TSIG January 30, 2002 +INTERNET-DRAFT GSS-TSIG February 28, 2003 * The protocol developer is removed from the responsibility of creating and managing a security infrastructure. For example, the @@ -170,9 +170,9 @@ states of a context associated with a connection: | | +----------+ -Expires July 30, 2002 [Page 3] +Expires August 28, 2003 [Page 3] -INTERNET-DRAFT GSS-TSIG January 30, 2002 +INTERNET-DRAFT GSS-TSIG February 28, 2003 Every connection begins in the uninitialized state. @@ -198,6 +198,28 @@ records exchanged in DNS messages sent between the Client and Server, as described in [RFC2845]. +2.2 Modifications to the TSIG protocol (RFC 2845) + +Modification to RFC 2845 allows use of TSIG through signing server's +response in an explicitly specified place in multi message exchange +between two DNS entities even if client's request wasn't signed. + +Specifically Section 4.2 of RFC 2845 MUST be modified as follows. + +Replace: +"The server MUST not generate a signed response to an unsigned +request." + +With: +"The server MUST not generate a signed response to an unsigned request, +except in case of response to client's unsigned TKEY query if secret +key is established on server side after server processed client's +query. Signing responses to unsigned TKEY queries MUST be explicitly +specified in the description of an individual secret key establishment +algorithm." + + + 3. Client Protocol Details A unique context is required for each server to which the client sends @@ -206,6 +228,11 @@ client maintains a mapping of servers to handles, (target_name, key_name, context_handle) +Expires August 28, 2003 [Page 4] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + The value key_name also identifies a context handle. The key_name is the owner name of the TKEY and TSIG records sent between a client and a server to indicate to each other which context MUST be used to process @@ -227,11 +254,6 @@ initial token and sends it to the server. The server processes the token and if necessary, returns a subsequent token to the client. The client processes this token, and so on, until the negotiation is complete. The number of times the client and server exchange tokens - -Expires July 30, 2002 [Page 4] - -INTERNET-DRAFT GSS-TSIG January 30, 2002 - depends on the underlying security mechanism. A completed negotiation results in a context handle. @@ -263,6 +285,11 @@ indicated with the output values below. Consult Sections 2.2.1 more information). OCTET STRING input_token = NULL BOOLEAN replay_det_req_flag = TRUE + +Expires August 28, 2003 [Page 5] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + BOOLEAN mutual_req_flag = TRUE BOOLEAN deleg_req_flag = TRUE BOOLEAN sequence_req_flag = TRUE @@ -285,11 +312,6 @@ indicated with the output values below. Consult Sections 2.2.1 BOOLEAN deleg_state BOOLEAN sequence_state BOOLEAN anon_state - -Expires July 30, 2002 [Page 5] - -INTERNET-DRAFT GSS-TSIG January 30, 2002 - BOOLEAN trans_state BOOLEAN prot_ready_state BOOLEAN conf_avail @@ -322,6 +344,11 @@ Success values of major_status are GSS_S_CONTINUE_NEEDED and GSS_S_COMPLETE. The exact success code is important during later processing. +Expires August 28, 2003 [Page 6] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + The values of replay_det_state and mutual_state indicate if the security package provides replay detection and mutual authentication, respectively. If returned major_status is GSS_S_COMPLETE AND one or both @@ -343,11 +370,6 @@ to the server in a query request with QTYPE=TKEY. The token itself will be placed in a Key Data field of the RDATA field in the TKEY resource record in the additional records section of the query. The owner name of the TKEY resource record set queried for and the owner - -Expires July 30, 2002 [Page 6] - -INTERNET-DRAFT GSS-TSIG January 30, 2002 - name of the supplied TKEY resource record in the additional records section MUST be the same. This name uniquely identifies the security context to both the client and server, and thus the client SHOULD use @@ -380,12 +402,15 @@ Upon the reception of the TKEY query DNS server MUST respond according to the description in Section 4. This Section specifies the behavior of the client after it receives the matching response to its query. +Expires August 28, 2003 [Page 7] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + The next processing step depends on the value of major_status from the most recent call that client performed to GSS_Init_sec_context: either GSS_S_COMPLETE or GSS_S_CONTINUE. - 3.1.3.1 Value of major_status == GSS_S_COMPLETE If the last call to GSS_Init_sec_context yielded a major_status value @@ -395,18 +420,14 @@ client is awaiting confirmation from the server. Confirmation is in the form of a query response with RCODE=NOERROR and with the last client supplied TKEY record in the answer section -of the query. The response MUST be signed with a TSIG record. The -signature in the TSIG record MUST be verified using the procedure +of the query. The response MUST be signed with a TSIG record. Note +that server is allowed to sign a response to unsigned client's query +due to modification to the RFC 2845 specified in Section 2.2 above. +The signature in the TSIG record MUST be verified using the procedure detailed in section 5, Sending and Verifying Signed Messages. If the response is not signed, OR if the response is signed but signature is invalid, then an attacker has tampered with the message in transit or has attempted to send the client a false response. In this case the - -Expires July 30, 2002 [Page 7] - -INTERNET-DRAFT GSS-TSIG January 30, 2002 - - client MAY continue waiting for a response to its last TKEY query until the time period since the client sent last TKEY query expires. Such a time period is specified by the policy local to the client. This is a @@ -439,6 +460,11 @@ using the same parameters values as in previous call except values for CONTEXT HANDLE input_context_handle and OCTET STRING input_token as described below: +Expires August 28, 2003 [Page 8] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + INPUTS CONTEXT HANDLE input_context_handle = context_handle (this is the context_handle corresponding to the key_name which is the @@ -459,11 +485,6 @@ If OUTPUT major_status is set to one of the following values GSS_S_NO_CRED GSS_S_CREDENTIALS_EXPIRED GSS_S_BAD_BINDINGS - -Expires July 30, 2002 [Page 8] - -INTERNET-DRAFT GSS-TSIG January 30, 2002 - GSS_S_OLD_TOKEN GSS_S_DUPLICATE_TOKEN GSS_S_NO_CONTEXT @@ -496,6 +517,12 @@ MUST be limited to ten or less. If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet finished. The token output_token MUST be passed to the server in a TKEY record by repeating the negotiation sequence beginning with section + +Expires August 28, 2003 [Page 9] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + 3.1.2. The client MUST place a limit on the number of continuations in a context negotiation to prevent endless looping. Such limit SHOULD NOT exceed value of 10. @@ -518,10 +545,6 @@ used for the generation and verification of transaction signatures. The procedures for sending and receiving signed messages are described in section 5, Sending and Verifying Signed Messages. -Expires July 30, 2002 [Page 9] - -INTERNET-DRAFT GSS-TSIG January 30, 2002 - 3.2.1 Terminating a Context @@ -553,6 +576,10 @@ request. The server maintains a mapping of key names to handles: A server MUST recognize TKEY queries as security context negotiation messages. +Expires August 28, 2003 [Page 10] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + 4.1.1 Receive TKEY Query from Client @@ -576,10 +603,6 @@ context negotiation and performs operations described in Section 4.1.2 and 4.1.3. -Expires July 30, 2002 [Page 10] - -INTERNET-DRAFT GSS-TSIG January 30, 2002 - 4.1.2 Call GSS_Accept_sec_context @@ -610,6 +633,12 @@ for syntax definitions. INTERNAL NAME src_name OBJECT IDENTIFIER mech_type BOOLEAN deleg_state + +Expires August 28, 2003 [Page 11] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + BOOLEAN mutual_state BOOLEAN replay_det_state BOOLEAN sequence_state @@ -632,12 +661,6 @@ TKEY record. The server MUST respond to the client with a TKEY query response with RCODE = NOERROR, that contains a TKEY record in the answer section. - - -Expires July 30, 2002 [Page 11] - -INTERNET-DRAFT GSS-TSIG January 30, 2002 - If OUTPUT major_status is one of the following errors the error field in the TKEY record set to BADKEY. @@ -661,13 +684,24 @@ negotiation is finished. If output_token is non-NULL, then it MUST be returned to the client in a Key Data field of the RDATA in TKEY. The error field in the TKEY record is set to NOERROR. The message MUST be signed with a TSIG record as described in section 5, Sending and -Verifying Signed Messages. The context state is advanced to Context -Established. Section 4.2 discusses the usage of the security context. +Verifying Signed Messages. Note that server is allowed to sign a +response to unsigned client's query due to modification to the RFC +2845 specified in Section 2.2 above. The context state is advanced to +Context Established. Section 4.2 discusses the usage of the security +context. + + + +Expires August 28, 2003 [Page 12] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 If major_status is GSS_S_COMPLETE and output_token is NULL, then the TKEY record received from the client MUST be returned in the Answer section of the response. The message MUST be signed with a TSIG record -as described in section 5, Sending and Verifying Signed Messages. The +as described in section 5, Sending and Verifying Signed Messages. Note +that server is allowed to sign a response to unsigned client's query +due to modification to the RFC 2845 specified in section 2.2 above. The context state is advanced to Context Established. Section 4.2 discusses the usage of the security context. @@ -692,12 +726,6 @@ Error, Other Size and Data Fields, MUST be set according to [RFC2930]. -Expires July 30, 2002 [Page 12] - -INTERNET-DRAFT GSS-TSIG January 30, 2002 - - - 4.2 Context Established When context negotiation is complete, the handle context_handle @@ -722,6 +750,9 @@ including a TKEY RR in a response with the Mode field set to 5, i.e. An active context is deleted by calling GSS_Delete_sec_context providing the associated context_handle. +Expires August 28, 2003 [Page 13] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 5. Sending and Verifying Signed Messages @@ -746,14 +777,6 @@ parameters MUST be used. The outcome of the call is indicated with the output values specified below. Consult Sections 2.3.1 "GSS_GetMIC call" of the RFC 2743[RFC2743] for syntax definitions. - - - - -Expires July 30, 2002 [Page 13] - -INTERNET-DRAFT GSS-TSIG January 30, 2002 - INPUTS CONTEXT HANDLE context_handle = context_handle for key_name OCTET STRING message = outgoing message plus TSIG @@ -785,6 +808,10 @@ If major_status is GSS_S_BAD_QOP, the caller SHOULD repeat the GSS_GetMIC call with allowed QOP value. The number of such repetitions MUST be limited to prevent infinite loops. +Expires August 28, 2003 [Page 14] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + 5.2 Verifying a Signed Message - Call GSS_VerifyMIC @@ -808,10 +835,6 @@ For the GSS algorithm, a signature is verified by using GSS_VerifyMIC: INTEGER minor_status INTEGER qop_state -Expires July 30, 2002 [Page 14] - -INTERNET-DRAFT GSS-TSIG January 30, 2002 - If major_status is GSS_S_COMPLETE, the signature is authentic and the message was delivered intact. Per [RFC2845], the timer values of the TSIG record MUST also be valid before considering the message to be @@ -839,6 +862,15 @@ is processing a client request, the appropriate error response MUST be sent to the client according to [RFC2845]. + + + + +Expires August 28, 2003 [Page 15] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + 6. Example usage of GSS-TSIG algorithm This Section describes an example where a Client, client.example.com, @@ -864,12 +896,6 @@ to the algorithm described above. BOOLEAN replay_det_state = TRUE BOOLEAN mutual_state = TRUE - - -Expires July 30, 2002 [Page 15] - -INTERNET-DRAFT GSS-TSIG January 30, 2002 - Client verifies that replay_det_state and mutual_state values are TRUE. Since the major_status is GSS_S_CONTINUE_NEEDED, which is a success OUTPUT major_status value, client stores context_handle that @@ -895,6 +921,13 @@ INTERNET-DRAFT GSS-TSIG January 30, 2002 context_handle) mapping table. + + + +Expires August 28, 2003 [Page 16] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + III. Server receives a query with QTYPE = TKEY When server receives a query with QTYPE = TKEY, the server verifies that Mode and Algorithm fields in the TKEY record in the Additional @@ -923,11 +956,6 @@ INTERNET-DRAFT GSS-TSIG January 30, 2002 in its (key_name, context_handle) mapping table. - -Expires July 30, 2002 [Page 16] - -INTERNET-DRAFT GSS-TSIG January 30, 2002 - V. Server responds to the TKEY query Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's call to GSS_Accept_sec_context, the server responds to the TKEY query @@ -953,6 +981,12 @@ INTERNET-DRAFT GSS-TSIG January 30, 2002 The OUTPUTS parameters returned by GSS_Init_sec_context include INTEGER major_status = GSS_S_COMPLETE + +Expires August 28, 2003 [Page 17] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + CONTEXT HANDLE output_context_handle = context_handle OCTET STRING output_token = output_token BOOLEAN replay_det_state = TRUE @@ -977,15 +1011,6 @@ INTERNET-DRAFT GSS-TSIG January 30, 2002 Key Data = output_token - - - - - -Expires July 30, 2002 [Page 17] - -INTERNET-DRAFT GSS-TSIG January 30, 2002 - VIII. Server receives a TKEY query When the server receives a TKEY query, the server verifies that Mode and Algorithm fields in the TKEY record in the Additional records @@ -1012,6 +1037,14 @@ INTERNET-DRAFT GSS-TSIG January 30, 2002 CONTEXT_HANDLE output_context_handle = context_handle OCTET STRING output_token = NULL + + + +Expires August 28, 2003 [Page 18] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + Since major_status = GSS_S_COMPLETE, the security context on the server side is established, but the server still needs to respond to the client's TKEY query, as described below. The security context @@ -1040,10 +1073,6 @@ INTERNET-DRAFT GSS-TSIG January 30, 2002 Signature field in the TSIG record is set to per_msg_token. -Expires July 30, 2002 [Page 18] - -INTERNET-DRAFT GSS-TSIG January 30, 2002 - XI. Client processes token returned by server Client receives the TKEY query response from the server. Since the @@ -1068,6 +1097,11 @@ INTERNET-DRAFT GSS-TSIG January 30, 2002 other until the context expires. + +Expires August 28, 2003 [Page 19] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + 7. Security Considerations This document describes a protocol for DNS security using GSS-API. @@ -1097,11 +1131,6 @@ support such flexibility, DNS clients and servers SHOULD specify SPNEGO mech_type in their GSS API calls. At the same time, in order to guarantee interoperability between DNS clients and servers that support GSS-TSIG it is required that - -Expires July 30, 2002 [Page 19] - -INTERNET-DRAFT GSS-TSIG January 30, 2002 - - DNS servers specify SPNEGO mech_type - GSS APIs called by DNS client support Kerberos v5 - GSS APIs called by DNS server support SPNEGO [RFC2478] and @@ -1125,6 +1154,12 @@ Nordmark. Interface, Version 2 , Update 1", RFC 2743, RSA Laboratories, January 2000. + + +Expires August 28, 2003 [Page 20] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + [RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, ISC, NAI Labs, Motorola, Nominum, May, 2000, @@ -1156,18 +1191,11 @@ Nordmark. [RFC2478] Baize, E., Pinkas, D., "The Simple and Protected GSS-API Negotiation Mechanism", RFC 2478, Bull, December 1998. -Expires July 30, 2002 [Page 20] - -INTERNET-DRAFT GSS-TSIG January 30, 2002 - - [ISO11578]"Information technology", "Open Systems Interconnection", "Remote Procedure Call", ISO/IEC 11578:1996, http://www.iso.ch/cate/d2229.html. - - 12. Author's Addresses Stuart Kwan Praerit Garg @@ -1185,6 +1213,12 @@ USA USA jamesg@microsoft.com levone@microsoft.com + +Expires August 28, 2003 [Page 21] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + Randy Hall Jeff Westhead Lucent Technologies Microsoft Corporation 400 Lapp Road One Microsoft Way @@ -1194,4 +1228,4 @@ randyhall@lucent.com jwesth@microsoft.com -Expires July 30, 2002 [Page 21] +Expires August 28, 2003 [Page 22] diff --git a/doc/draft/draft-ietf-dnsext-rfc1886bis-01.txt b/doc/draft/draft-ietf-dnsext-rfc1886bis-02.txt similarity index 87% rename from doc/draft/draft-ietf-dnsext-rfc1886bis-01.txt rename to doc/draft/draft-ietf-dnsext-rfc1886bis-02.txt index cd09fdffb0..52c8333ce0 100644 --- a/doc/draft/draft-ietf-dnsext-rfc1886bis-01.txt +++ b/doc/draft/draft-ietf-dnsext-rfc1886bis-02.txt @@ -1,14 +1,14 @@ Internet Engineering Task Force S. Thomson, Cisco INTERNET-DRAFT C. Huitema, Microsoft -October 29, 2002 V. Ksinant, 6WIND -Expires April 29, 2003 M. Souissi, AFNIC +February 28, 2003 V. Ksinant, 6WIND +Expires August 28, 2003 M. Souissi, AFNIC DNS Extensions to support IP version 6 - + Status of this Memo @@ -21,6 +21,7 @@ Status of this Memo other groups may also distribute working documents as Internet- Drafts. + 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 @@ -29,7 +30,7 @@ Status of this Memo To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. - This Internet Draft expires April 29, 2003. + This Internet Draft expires August 28, 2003. @@ -53,10 +54,9 @@ Abstract - -draft-ietf-dnsext-rfc1886bis-01.txt [Page 1] +draft-ietf-dnsext-rfc1886bis-02.txt [Page 1] -INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002 +INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003 Table of Contents @@ -109,9 +109,9 @@ Table of Contents that has more than one IPv6 address must have more than one such record. -draft-ietf-dnsext-rfc1886bis-01.txt [Page 2] +draft-ietf-dnsext-rfc1886bis-02.txt [Page 2] -INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002 +INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003 2.1 AAAA record type @@ -165,20 +165,20 @@ INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002 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. -draft-ietf-dnsext-rfc1886bis-01.txt [Page 3] +draft-ietf-dnsext-rfc1886bis-02.txt [Page 3] -INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002 +INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003 3. MODIFICATIONS TO EXISTING QUERY TYPES All existing query types that perform type A additional section - processing, i.e. name server (NS) 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. - + 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 @@ -200,6 +200,8 @@ APPENDIX A: Changes from RFC 1886 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 2373 (IP Version 6 Addressing @@ -217,14 +219,9 @@ APPENDIX A: Changes from RFC 1886 - - - - - -draft-ietf-dnsext-rfc1886bis-01.txt [Page 4] +draft-ietf-dnsext-rfc1886bis-02.txt [Page 4] -INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002 +INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003 Acknowledgements @@ -236,6 +233,8 @@ Acknowledgements Many thanks to Alain Durand and Olafur Gudmundsson for their support. + + Normative References [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD @@ -251,12 +250,16 @@ Normative References "draft-ietf-ipngwg-addr-arch-v3-11.txt", Hinden, R., and S. Deering, October 25, 2002 + + +Informative References + [4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, FreeGate Corp., Sun Microsystems Inc., August 2000. This RFC is being updated. The current draft is - "draft-ietf-ngtrans-mech-v2-00.txt", Gilligan, R., and - E. Nordmark, July 17, 2002 + "draft-ietf-v6ops-mech-v2-00.txt", Gilligan, R., and + E. Nordmark, February 24, 2003 [5] Thomson, S., and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, Bellcore, INRIA, December 1995. @@ -272,15 +275,9 @@ Normative References RFC 2845, ISC, NAI Labs, Motorola, Nominum, May 2000. - - - - - - -draft-ietf-dnsext-rfc1886bis-01.txt [Page 5] +draft-ietf-dnsext-rfc1886bis-02.txt [Page 5] -INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002 +INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003 Authors' Addresses @@ -332,9 +329,9 @@ Authors' Addresses -draft-ietf-dnsext-rfc1886bis-01.txt [Page 6] +draft-ietf-dnsext-rfc1886bis-02.txt [Page 6] -INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002 +INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003 Full Copyright Statement @@ -390,4 +387,4 @@ Full Copyright Statement information to the IETF Executive Director. -draft-ietf-dnsext-rfc1886bis-01.txt [Page 7] +draft-ietf-dnsext-rfc1886bis-02.txt [Page 7]