From: Automatic Updater Date: Wed, 3 Mar 2010 22:08:29 +0000 (+0000) Subject: sync X-Git-Tag: v9.6-ESV~5 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=12d91a5519fb5037fd5d416acb61cb2d7a1c23fd;p=thirdparty%2Fbind9.git sync --- diff --git a/doc/draft/draft-ietf-6man-text-addr-representation-01.txt b/doc/draft/draft-ietf-6man-text-addr-representation-01.txt deleted file mode 100644 index f15b069b5ba..00000000000 --- a/doc/draft/draft-ietf-6man-text-addr-representation-01.txt +++ /dev/null @@ -1,785 +0,0 @@ - - - -IPv6 Maintenance Working Group S. Kawamura -Internet-Draft NEC BIGLOBE, Ltd. -Intended status: Informational M. Kawashima -Expires: April 21, 2010 NEC AccessTechnica, Ltd. - October 18, 2009 - - - A Recommendation for IPv6 Address Text Representation - draft-ietf-6man-text-addr-representation-01 - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - 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 - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on April 21, 2010. - -Copyright Notice - - Copyright (c) 2009 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 in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract - - As IPv6 network grows, there will be more engineers and also non- - engineers who will have the need to use an IPv6 address in text. - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 1] - -Internet-Draft IPv6 Text Representation October 2009 - - - While the IPv6 address architecture RFC 4291 section 2.2 depicts a - flexible model for text representation of an IPv6 address, this - flexibility has been causing problems for operators, system - engineers, and users. This document will describe the problems that - a flexible text representation has been causing. This document also - recommends a canonical representation format that best avoids - confusion. It is expected that the canonical format is followed by - humans and systems when representing IPv6 addresses as text, but all - implementations must accept and be able to handle any legitimate - RFC4291 format. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 - 2. Text Representation Flexibility of RFC4291 . . . . . . . . . . 4 - 2.1. Leading Zeros in a 16 Bit Field . . . . . . . . . . . . . 4 - 2.2. Zero Compression . . . . . . . . . . . . . . . . . . . . . 5 - 2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 5 - 3. Problems Encountered with the Flexible Model . . . . . . . . . 6 - 3.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1.1. General Summary . . . . . . . . . . . . . . . . . . . 6 - 3.1.2. Searching Spreadsheets and Text Files . . . . . . . . 6 - 3.1.3. Searching with Whois . . . . . . . . . . . . . . . . . 6 - 3.1.4. Searching for an Address in a Network Diagram . . . . 7 - 3.2. Parsing and Modifying . . . . . . . . . . . . . . . . . . 7 - 3.2.1. General Summary . . . . . . . . . . . . . . . . . . . 7 - 3.2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 8 - 3.2.4. Auditing: Case 2 . . . . . . . . . . . . . . . . . . . 8 - 3.2.5. Verification . . . . . . . . . . . . . . . . . . . . . 8 - 3.2.6. Unexpected Modifying . . . . . . . . . . . . . . . . . 8 - 3.3. Operating . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.3.1. General Summary . . . . . . . . . . . . . . . . . . . 8 - 3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 9 - 3.3.3. Abuse . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.4. Other Minor Problems . . . . . . . . . . . . . . . . . . . 9 - 3.4.1. Changing Platforms . . . . . . . . . . . . . . . . . . 9 - 3.4.2. Preference in Documentation . . . . . . . . . . . . . 9 - 3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 10 - 4. A Recommendation for IPv6 Text Representation . . . . . . . . 10 - 4.1. Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10 - 4.2. "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.2.1. Shorten As Much As Possible . . . . . . . . . . . . . 10 - 4.2.2. Handling One 16 Bit 0 Field . . . . . . . . . . . . . 10 - 4.2.3. Choice in Placement of "::" . . . . . . . . . . . . . 10 - 4.3. Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 11 - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 2] - -Internet-Draft IPv6 Text Representation October 2009 - - - 5. Text Representation of Special Addresses . . . . . . . . . . . 11 - 6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11 - 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 13 - Appendix B. Prefix Issues . . . . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 3] - -Internet-Draft IPv6 Text Representation October 2009 - - -1. Introduction - - A single IPv6 address can be text represented in many ways. Examples - are shown below. - - 2001:db8:0:0:1:0:0:1 - - 2001:0db8:0:0:1:0:0:1 - - 2001:db8::1:0:0:1 - - 2001:db8::0:1:0:0:1 - - 2001:0db8::1:0:0:1 - - 2001:db8:0:0:1::1 - - 2001:db8:0000:0:1::1 - - 2001:DB8:0:0:1::1 - - All the above point to the same IPv6 address. This flexibility has - caused many problems for operators, systems engineers, and customers. - The problems will be noted in Section 3. Also, a canonical - representation format to avoid problems will be introduced in - Section 4. - -1.1. Requirements Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - -2. Text Representation Flexibility of RFC4291 - - Examples of flexibility in Section 2.2 of [RFC4291] are described - below. - -2.1. Leading Zeros in a 16 Bit Field - - 'It is not necessary to write the leading zeros in an individual - field.' - - In other words, it is also not necessary to omit leading zeros. This - means that, it is possible to select from such as the following - example. The final 16 bit field is different, but all these - addresses mean the same. - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 4] - -Internet-Draft IPv6 Text Representation October 2009 - - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001 - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:001 - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:01 - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:1 - -2.2. Zero Compression - - 'A special syntax is available to compress the zeros. The use of - "::" indicates one or more groups of 16 bits of zeros.' - - It is possible to select whether or not to omit just one 16 bits of - zeros. - - 2001:db8:aaaa:bbbb:cccc:dddd::1 - - 2001:db8:aaaa:bbbb:cccc:dddd:0:1 - - In case where there are more than one zero fields, there is a choice - of how many fields can be shortened. Examples follow. - - 2001:db8:0:0:0::1 - - 2001:db8:0:0::1 - - 2001:db8:0::1 - - 2001:db8::1 - - In addition, [RFC4291] in section 2.2 notes, - - 'The "::" can only appear once in an address.' - - This gives a choice on where, in a single address to compress the - zero. Examples are shown below. - - 2001:db8::aaaa:0:0:1 - - 2001:db8:0:0:aaaa::1 - -2.3. Uppercase or Lowercase - - [RFC4291] does not mention about preference of uppercase or - lowercase. Various flavors are shown below. - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 5] - -Internet-Draft IPv6 Text Representation October 2009 - - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa - - -3. Problems Encountered with the Flexible Model - -3.1. Searching - -3.1.1. General Summary - - A search of an IPv6 address if conducted through a UNIX system is - usually case sensitive and extended options to allow for regular - expression use will come in handy. However, there are many - applications in the Internet today that do not provide this - capability. When searching for an IPv6 address in such systems, the - system engineer will have to try each and every possibility to search - for an address. This has critical impacts especially when trying to - deploy IPv6 over an enterprise network. - -3.1.2. Searching Spreadsheets and Text Files - - Spreadsheet applications and text editors on GUI systems, rarely have - the ability to search for a text using regular expression. Moreover, - there are many non-engineers (who are not aware of case sensitivity - and regular expression use) that use these application to manage IP - addresses. This has worked quite well with IPv4 since text - representation in IPv4 has very little flexibility. There is no - incentive to encourage these non-engineers to change their tool or - learn regular expression when they decide to go dual-stack. If the - entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was - conducted as 2001:db8:0:0:1::1, this will show a result of no match. - One example where this will cause problem is, when the search is - being conducted to assign a new address from a pool, and a check was - being done to see if it was not in use. This may cause problems to - the end-hosts or end-users. This type of address management is very - often seen in enterprise networks and also in ISPs. - -3.1.3. Searching with Whois - - The "whois" utility is used by a wide range of people today. When a - record is set to a database, one will likely check the output to see - if the entry is correct. If an entity was recorded as 2001:db8::/48, - but the whois output showed 2001:0db8:0000::/48, most non-engineers - would think that their input was wrong, and will likely retry several - times or make a frustrated call to the database hostmaster. If there - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 6] - -Internet-Draft IPv6 Text Representation October 2009 - - - was a need to register the same address on different systems, and - each system showed a different text representation, this would - confuse people even more. Although this document focuses on - addresses rather than prefixes, this is worth mentioning since - problems encountered are mostly equal. - -3.1.4. Searching for an Address in a Network Diagram - - Network diagrams and blue-prints contain IP addresses as allocated to - system devices. In times of trouble shooting, there may be a need to - search through a diagram to find the point of failure (for example, - if a traceroute stopped at 2001:db8::1, one would search the diagram - for that address). This is a technique quite often in use in - enterprise networks and managed services. Again, the different - flavors of text representation will result in a time-consuming - search, leading to longer MTTR in times of trouble. - -3.2. Parsing and Modifying - -3.2.1. General Summary - - With all the possible text representation ways, each application must - include a module, object, link, etc. to a function that will parse - IPv6 addresses in a manner that no matter how it is represented, they - will mean the same address. This is not too much a problem if the - output is to be just 'read' or 'managed' by a network engineer. - However, many system engineers who integrate complex computer systems - to corporate customers will have difficulties finding that their - favorite tool will not have this function, or will encounter - difficulties such as having to rewrite their macro's or scripts for - their customers. It must be noted that each additional line of a - program will result in increased development fees that will be - charged to the customers. - -3.2.2. Logging - - If an application were to output a log summary that represented the - address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444), - the output would be highly unreadable compared to the IPv4 output. - The address would have to be parsed and reformed to make it useful - for human reading. This will result in additional code on the - applications which will result in extra fees charged to the - customers. Sometimes, logging for critical systems is done by - mirroring the same traffic to two different systems. Care must be - taken that no matter what the log output is, the logs should be - parsed so they will mean the same. - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 7] - -Internet-Draft IPv6 Text Representation October 2009 - - -3.2.3. Auditing: Case 1 - - When a router or any other network appliance machine configuration is - audited, there are many methods to compare the configuration - information of a node. Sometimes, auditing will be done by just - comparing the changes made each day. In this case, if configuration - was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000: - 0000:0000:0000:0001 just because the new engineer on the block felt - it was better, a simple diff will tell you that a different address - was configured. If this was done on a wide scale network, people - will be focusing on 'why the extra zeros were put in' instead of - doing any real auditing. Lots of tools are just plain 'diff's that - do not take into account address representation rules. - -3.2.4. Auditing: Case 2 - - Node configurations will be matched against an information system - that manages IP addresses. If output notation is different, there - will need to be a script that is implemented to cover for this. An - SNMP GET of an interface address and text representation in a humanly - written text file is highly unlikely to match on first try. - -3.2.5. Verification - - Some protocols require certain data fields to be verified. One - example of this is X.509 certificates. If an IPv6 address was - embedded in one of the fields in a certificate, and the verification - was done by just a simple textual comparison, the certificate may be - maistakenly shown as being invalid due to a difference in text - representation methods. - -3.2.6. Unexpected Modifying - - Sometimes, a system will take an address and modify it as a - convenience. For example, a system may take an input of - 2001:0db8:0::1 and make the output 2001:db8::1 (which is seen in some - RIR databases). If the zeros were input for a reason, the outcome - may be somewhat unexpected. - -3.3. Operating - -3.3.1. General Summary - - When an operator sets an IPv6 address of a system as 2001:db8:0:0:1: - 0:0:1, the system may take the address and show the configuration - result as 2001:DB8::1:0:0:1. A distinguished engineer will know that - the right address is set, but an operator, or a customer that is - communicating with the operator to solve a problem, is usually not as - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 8] - -Internet-Draft IPv6 Text Representation October 2009 - - - distinguished as we would like. Again, the extra load in checking - that the IP address is the same as was intended, will result in fees - that will be charged to the customers. - -3.3.2. Customer Calls - - When a customer calls to inquire about a suspected outage, IPv6 - address representation should be handled with care. Not all - customers are engineers nor have the same skill in IPv6 technology. - The NOC will have to take extra steps to humanly parse the address to - avoid having to explain to the customers that 2001:db8:0:1::1 is the - same as 2001:db8::1:0:0:0:1. This is one thing that will never - happen in IPv4 because IPv4 address cannot be abbreviated. - -3.3.3. Abuse - - Network abuse is reported along with the abusing IP address. This - 'reporting' could take any shape or form of the flexible model. A - team that handles network abuse must be able to tell the difference - between a 2001:db8::1:0:1 and 2001:db8:1::0:1. Mistakes in the - placement of the "::" will result in a critical situation. A system - that handles these incidents should be able to handle any type of - input and parse it in a correct manner. Also, incidents are reported - over the phone. It is unnecessary to report if the letter is an - uppercase or lowercase. However, when a letter is spelled uppercase, - people tend to clarify that it is uppercase, which is unnecessary - information. - -3.4. Other Minor Problems - -3.4.1. Changing Platforms - - When an engineer decides to change the platform of a running service, - the same code may not work as expected due to the difference in IPv6 - address text representation. Usually, a change in a platform (e.g. - Unix to Windows, Cisco to Juniper) will result in a major change of - code, but flexibility in address representation will increase the - work load which will again, result in fees that will be charged to - the customers, and also longer down time of systems. - -3.4.2. Preference in Documentation - - A document that is edited by more than one author, may become harder - to read. - - - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 9] - -Internet-Draft IPv6 Text Representation October 2009 - - -3.4.3. Legibility - - Capital case D and 0 can be quite often misread. Capital B and 8 can - also be misread. - - -4. A Recommendation for IPv6 Text Representation - - A recommendation for a canonical text representation format of IPv6 - addresses is presented in this section. The recommendation in this - document is one that, complies fully with [RFC4291], is implemented - by various operating systems, and is human friendly. The - recommendation in this document SHOULD be followed by humans and - systems when generating an address to represent as text, but all - implementations MUST accept any legitimate [RFC4291] format. - -4.1. Handling Leading Zeros in a 16 Bit Field - - Leading zeros should be chopped for human legibility and easier - searching. Also, a single 16 bit 0000 field should be represented as - just 0. Place holder zeros are often cause of misreading. - -4.2. "::" Usage - -4.2.1. Shorten As Much As Possible - - The use of "::" should be used to its maximum capability (i.e. 2001: - db8::0:1 is not considered as clean representation). - -4.2.2. Handling One 16 Bit 0 Field - - "::" should not be used to shorten just one 16 bit 0 field for it - would tend to mislead that there are more than one 16 bit field that - is shortened. - -4.2.3. Choice in Placement of "::" - - When there is an alternative choice in the placement of a "::", the - longest run of consecutive 16 bit 0 fields should be shortened (i.e. - latter is shortened in 2001:0:0:1:0:0:0:1). When the length of the - consecutive 16 bit 0 fields are equal (i.e. 2001:db8:0:0:1:0:0:1), - the former is shortened. This is consistent with many current - implementations. One idea to avoid any confusion, is for the - operator to not use 16 bit field 0 in the first 64 bits. By nature - IPv6 addresses are usually assigned or allocated to end-users as - longer than 32 bits (typically 48 bits or longer). - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 10] - -Internet-Draft IPv6 Text Representation October 2009 - - -4.3. Lower Case - - Recent implementations tend to represent IPv6 address as lower case. - It is better to use lower case to avoid problems such as described in - section 3.3.3 and 3.4.3. - - -5. Text Representation of Special Addresses - - Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and - IPv4-translated addresses [RFC2765] have IPv4 addresses embedded in - the low-order 32 bits of the address. These addresses have special - representation that may mix hexadecimal and decimal notations. In - cases where there is a choice of whether to express the address as - fully hexadecimal or hexadecimal and decimal mixed, and if the - address type can be distinguished as having IPv4 addresses embedded - in the lower 32 bits solely from the 128bits of the address field - itself, mixed notation is the better choice. However, there may be - situations where hexadecimal representation is chosen to meet certain - needs. Addressing those needs is out of the scope of this document. - The text representation method noted in Section 4 should be applied - for the leading hexadecimal part (i.e. ::ffff:192.0.2.1 instead of - 0:0:0:0:0:ffff:192.0.2.1). - - -6. Notes on Combining IPv6 Addresses with Port Numbers - - When IPv6 addresses and port numbers are represented in text combined - together, there seems to be many different ways to do so. Examples - are shown below. - - o [2001:db8::1]:80 - - o 2001:db8::1:80 - - o 2001:db8::1.80 - - o 2001:db8::1 port 80 - - o 2001:db8::1p80 - - o 2001:db8::1#80 - - The situation is not much different in IPv4, but the most ambiguous - case with IPv6 is the second bullet. This is due to the "::"usage in - IPv6 addresses. This style is not recommended for its ambiguity. - The [] style as expressed in [RFC3986] is recommended. Other styles - are acceptable when cross-platform portability does not become an - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 11] - -Internet-Draft IPv6 Text Representation October 2009 - - - issue. - - -7. Conclusion - - The recommended format of text representing an IPv6 address is - summarized as follows. - - (1) omit leading zeros in a 16 bit field - - (2) when using "::", shorten consecutive zero fields to their - maximum extent (leave no zero fields behind). - - (3) "::" used where shortens address the most - - (4) "::" used in the former part in case of a tie breaker - - (5) do not shorten one 16 bit 0 field, but always shorten when - there are two or more consecutive 16 bit 0 fields - - (6) use lower case - - Hints for developers are written in the Appendix section. - - -8. Security Considerations - - None. - - -9. IANA Considerations - - None. - - -10. Acknowledgements - - The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami, - Toshimitsu Matsuura for their generous and helpful comments in kick - starting this document. We also would like to thank Brian Carpenter, - Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler, - Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki - Vatiainen for their input. Also a very special thanks to Ron Bonica, - Fred Baker, Brian Haberman, Robert Hinden, Jari Arkko, and Kurt - Lindqvist for their support in bringing this document to the light of - IETF working groups. - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 12] - -Internet-Draft IPv6 Text Representation October 2009 - - -11. References - -11.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 4291, February 2006. - -11.2. Informative References - - [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm - (SIIT)", RFC 2765, February 2000. - - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", STD 66, - RFC 3986, January 2005. - - [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. - Castro, "Application Aspects of IPv6 Transition", - RFC 4038, March 2005. - - [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site - Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, - March 2008. - - -Appendix A. For Developers - - We recommend that developers use display routines that conform to - these rules. For example, the usage of getnameinfo() with flags - argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output, - except for the special addresses notes in Section 5. The function - inet_ntop() of FreeBSD7.0 is a good C code reference, but should not - be called directly. See [RFC4038] for details. - - -Appendix B. Prefix Issues - - Problems with prefixes are just the same as problems encountered with - addresses. Text representation method of IPv6 prefixes should be no - different from that of IPv6 addresses. - - - - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 13] - -Internet-Draft IPv6 Text Representation October 2009 - - -Authors' Addresses - - Seiichi Kawamura - NEC BIGLOBE, Ltd. - 14-22, Shibaura 4-chome - Minatoku, Tokyo 108-8558 - JAPAN - - Phone: +81 3 3798 6085 - Email: kawamucho@mesh.ad.jp - - - Masanobu Kawashima - NEC AccessTechnica, Ltd. - 800, Shimomata - Kakegawa-shi, Shizuoka 436-8501 - JAPAN - - Phone: +81 537 23 9655 - Email: kawashimam@necat.nec.co.jp - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 14] - - diff --git a/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt b/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt deleted file mode 100644 index ee35cb91af8..00000000000 --- a/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -INTERNET-DRAFT A. Gustafsson - Araneus Information Systems Oy - September 23, 2009 - -Intended status: Draft Standard -Obsoletes: RFC3597 - - Handling of Unknown DNS Resource Record (RR) Types - draft-ietf-dnsext-rfc3597-bis-00.txt - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that 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 - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - -Copyright Notice - - Copyright (c) 2009 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 in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract - - Extending the Domain Name System (DNS) with new Resource Record (RR) - types should not requires changes to name server software. This - document specifies how new RR types are transparently handled by DNS - software. - - - - -Expires March 2010 Standards Track [Page 1] - -draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 - - -1. Introduction - - The DNS [RFC1034] is designed to be extensible to support new - services through the introduction of new resource record (RR) types. - Nevertheless, DNS implementations have historically required software - changes to support new RR types, not only at the authoritative DNS - server providing the new information and the client making use of it, - but also at all slave servers for the zone containing it, and in some - cases also at caching name servers and forwarders used by the client. - Because the deployment of new DNS software is slow and expensive, - this has been a significant impediment to supporting new services in - the DNS. - - [RFC3597] defined DNS implementation behavior and procedures for - defining new RR types aimed at simplifying the deployment of new RR - types by allowing them to be treated transparently by existing - implementations. Thanks to the widespread adoption of that - specification, much of the DNS is now capable of handling new record - types without software changes. - - This document is a self-contained revised specification supplanting - and obsoleting [RFC3597]. - -2. Definitions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - An "RR of unknown type" is an RR whose RDATA format is not known to - the DNS implementation at hand, and whose type is not an assigned - QTYPE or Meta-TYPE as specified in [RFC5395] (section 3.1) nor within - the range reserved in that section for assignment only to QTYPEs and - Meta-TYPEs. Such an RR cannot be converted to a type-specific text - format, compressed, or otherwise handled in a type-specific way. - - In the case of a type whose RDATA format is class specific, an RR is - considered to be of unknown type when the RDATA format for that - combination of type and class is not known. - -3. Transparency - - To enable new RR types to be deployed without server changes, name - servers and resolvers MUST handle RRs of unknown type transparently. - That is, they must treat the RDATA section of such RRs as - unstructured binary data, storing and transmitting it without change - [RFC1123]. - - - - -Expires March 2010 Standards Track [Page 2] - -draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 - - - To ensure the correct operation of equality comparison (section 6) - and of the DNSSEC canonical form (section 7) when an RR type is known - to some but not all of the servers involved, servers MUST also - exactly preserve the RDATA of RRs of known type, except for changes - due to compression or decompression where allowed by section 4 of - this document. In particular, the character case of domain names - that are not subject to compression MUST be preserved. - -4. Domain Name Compression - - RRs containing compression pointers in the RDATA part cannot be - treated transparently, as the compression pointers are only - meaningful within the context of a DNS message. Transparently - copying the RDATA into a new DNS message would cause the compression - pointers to point at the corresponding location in the new message, - which now contains unrelated data. This would cause the compressed - name to be corrupted. - - To avoid such corruption, servers MUST NOT compress domain names - embedded in the RDATA of types that are class-specific or not well- - known. This requirement was stated in [RFC1123] without defining the - term "well-known"; it is hereby specified that only the RR types - defined in [RFC1035] are to be considered "well-known". - - Receiving servers MUST decompress domain names in RRs of well-known - type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX, - NXT, NAPTR, and SRV to ensure interoperability with implementations - predating [RFC3597]. - - Specifications for new RR types that contain domain names within - their RDATA MUST NOT allow the use of name compression for those - names, and SHOULD explicitly state that the embedded domain names - MUST NOT be compressed. - - As noted in [RFC1123], the owner name of an RR is always eligible for - compression. - -5. Text Representation - - In the "type" field of a master file line, an unknown RR type is - represented by the word "TYPE" immediately followed by the decimal RR - type number, with no intervening whitespace. In the "class" field, - an unknown class is similarly represented as the word "CLASS" - immediately followed by the decimal class number. - - This convention allows types and classes to be distinguished from - each other and from TTL values, allowing the "[] [] - " and "[] [] " forms of - - - -Expires March 2010 Standards Track [Page 3] - -draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 - - - [RFC1035] to both be unambiguously parsed. - - The RDATA section of an RR of unknown type is represented as a - sequence of white space separated words as follows: - - The special token \# (a backslash immediately followed by a hash - sign), which identifies the RDATA as having the generic encoding - defined herein rather than a traditional type-specific encoding. - - An unsigned decimal integer specifying the RDATA length in octets. - - Zero or more words of hexadecimal data encoding the actual RDATA - field, each containing an even number of hexadecimal digits. - - If the RDATA is of zero length, the text representation contains only - the \# token and the single zero representing the length. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Expires March 2010 Standards Track [Page 4] - -draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 - - - An implementation MAY also choose to represent some RRs of known type - using the above generic representations for the type, class and/or - RDATA, which carries the benefit of making the resulting master file - portable to servers where these types are unknown. Using the generic - representation for the RDATA of an RR of known type can also be - useful in the case of an RR type where the text format varies - depending on a version, protocol, or similar field (or several) - embedded in the RDATA when such a field has a value for which no text - format is known, e.g., a LOC RR [RFC1876] with a VERSION other than - 0. - - Even though an RR of known type represented in the \# format is - effectively treated as an unknown type for the purpose of parsing the - RDATA text representation, all further processing by the server MUST - treat it as a known type and take into account any applicable type- - specific rules regarding compression, canonicalization, etc. - - The following are examples of RRs represented in this manner, - illustrating various combinations of generic and type-specific - encodings for the different fields of the master file format: - - a.example. CLASS32 TYPE731 \# 6 abcd ( - ef 01 23 45 ) - b.example. HS TYPE62347 \# 0 - e.example. IN A \# 4 C0000201 - e.example. CLASS1 TYPE1 192.0.2.1 - -6. Equality Comparison - - Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs - to be compared for equality. Two RRs of the same unknown type are - considered equal when their RDATA is bitwise equal. To ensure that - the outcome of the comparison is identical whether the RR is known to - the server or not, specifications for new RR types MUST NOT specify - type-specific comparison rules. - - This implies that embedded domain names, being included in the - overall bitwise comparison, are compared in a case-sensitive manner. - - As a result, when a new RR type contains one or more embedded domain - names, it is possible to have multiple RRs owned by the same name - that differ only in the character case of the embedded domain - name(s). This is similar to the existing possibility of multiple TXT - records differing only in character case, and not expected to cause - any problems in practice. - - - - - - -Expires March 2010 Standards Track [Page 5] - -draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 - - -7. DNSSEC Considerations - - The rules for the DNSSEC canonical form and ordering were updated to - support transparent treatment of unknown types in [RFC3597]. Those - updates have subsequently been integrated into the base DNSSEC - specification, such that the DNSSEC canonical form and ordering are - now specified in [RFC4034] or its successors rather than in this - document. - -8. Additional Section Processing - - Unknown RR types cause no additional section processing. Future RR - type specifications MAY specify type-specific additional section - processing rules, but any such processing MUST be optional as it can - only be performed by servers for which the RR type in case is known. - -9. IANA Considerations - - This document does not require any IANA actions. - -10. Security Considerations - - This specification is not believed to cause any new security - problems, nor to solve any existing ones. - -11. Normative References - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and - Facilities", STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specifications", STD 13, RFC 1035, November 1987. - - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -- - Application and Support", STD 3, RFC 1123, October 1989. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA - Considerations", BCP 42, RFC 5395, November 2008. - -12. Informative References - - [RFC1876] Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A - Means for Expressing Location Information in the Domain - Name System", RFC 1876, January 1996. - - - - -Expires March 2010 Standards Track [Page 6] - -draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 - - - [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - -14. Author's Address - - Andreas Gustafsson - Araneus Information Systems Oy - PL 110 - 02321 Espoo - Finland - - Phone: +358 40 547 2099 - EMail: gson@araneus.fi - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Expires March 2010 Standards Track [Page 7] -