From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5952.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc5952.txt (limited to 'doc/rfc/rfc5952.txt') diff --git a/doc/rfc/rfc5952.txt b/doc/rfc/rfc5952.txt new file mode 100644 index 0000000..56a0e0c --- /dev/null +++ b/doc/rfc/rfc5952.txt @@ -0,0 +1,787 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Kawamura +Request for Comments: 5952 NEC BIGLOBE, Ltd. +Updates: 4291 M. Kawashima +Category: Standards Track NEC AccessTechnica, Ltd. +ISSN: 2070-1721 August 2010 + + + A Recommendation for IPv6 Address Text Representation + +Abstract + + As IPv6 deployment increases, there will be a dramatic increase in + the need to use IPv6 addresses in text. While the IPv6 address + architecture in Section 2.2 of RFC 4291 describes a flexible model + for text representation of an IPv6 address, this flexibility has been + causing problems for operators, system engineers, and users. This + document defines a canonical textual representation format. It does + not define a format for internal storage, such as within an + application or database. It is expected that the canonical format + will be followed by humans and systems when representing IPv6 + addresses as text, but all implementations must accept and be able to + handle any legitimate RFC 4291 format. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5952. + + + + + + + + + + + + + + + +Kawamura & Kawashima Standards Track [Page 1] + +RFC 5952 IPv6 Text Representation August 2010 + + +Copyright Notice + + Copyright (c) 2010 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 + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kawamura & Kawashima Standards Track [Page 2] + +RFC 5952 IPv6 Text Representation August 2010 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 2. Text Representation Flexibility of RFC 4291 . . . . . . . . . 4 + 2.1. Leading Zeros in a 16-Bit Field . . . . . . . . . . . . . 4 + 2.2. Zero Compression . . . . . . . . . . . . . . . . . . . . . 5 + 2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 6 + 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 . . . . . . . . . . . . . . . . . . . . . . 9 + 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. Lowercase . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5. Text Representation of Special Addresses . . . . . . . . . . . 11 + 6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11 + 7. Prefix Representation . . . . . . . . . . . . . . . . . . . . 12 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 14 + + + + + + +Kawamura & Kawashima Standards Track [Page 3] + +RFC 5952 IPv6 Text Representation August 2010 + + +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 of the above examples represent the same IPv6 address. This + flexibility has caused many problems for operators, systems + engineers, and customers. The problems are noted in Section 3. A + canonical representation format to avoid problems is 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 RFC 4291 + + 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.' + + Conversely, it is also not necessary to omit leading zeros. This + means that it is possible to select from representations such as + those in the following example. The final 16-bit field is different, + but all of these addresses represent the same address. + + + + +Kawamura & Kawashima Standards Track [Page 4] + +RFC 5952 IPv6 Text Representation August 2010 + + + 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-bit 0 + field. + + 2001:db8:aaaa:bbbb:cccc:dddd::1 + + 2001:db8:aaaa:bbbb:cccc:dddd:0:1 + + In cases where there is more than one field of only zeros, there is a + choice of how many fields can be shortened. + + 2001:db8:0:0:0::1 + + 2001:db8:0:0::1 + + 2001:db8:0::1 + + 2001:db8::1 + + In addition, Section 2.2 of [RFC4291] notes, + + 'The "::" can only appear once in an address.' + + This gives a choice on where in a single address to compress the + zero. + + 2001:db8::aaaa:0:0:1 + + 2001:db8:0:0:aaaa::1 + + + + + + + + + + +Kawamura & Kawashima Standards Track [Page 5] + +RFC 5952 IPv6 Text Representation August 2010 + + +2.3. Uppercase or Lowercase + + [RFC4291] does not mention any preference of uppercase or lowercase. + + 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 that 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 text using regular expression. Moreover, + there are many non-engineers (who are not aware of case sensitivity + and regular expression use) that use these applications 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 a problem is, when the search is + being conducted to assign a new address from a pool, and a check is + being done to see if it is not in use. This may cause problems for + the end-hosts or end-users. This type of address management is very + often seen in enterprise networks and 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, + + + +Kawamura & Kawashima Standards Track [Page 6] + +RFC 5952 IPv6 Text Representation August 2010 + + + 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 + was a need to register the same prefix 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, it is worth mentioning the prefix problems because the + problems encountered with addresses and prefixes are mostly equal. + +3.1.4. Searching for an Address in a Network Diagram + + Network diagrams and blueprints often show what IP addresses are + assigned to a 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 mean times to restoration (MTTR) + in times of trouble. + +3.2. Parsing and Modifying + +3.2.1. General Summary + + With all the possible methods of text representation, each + application must include a module, object, link, etc. to a function + that will parse IPv6 addresses in a manner such that no matter how it + is represented, they will mean the same address. Many system + engineers who integrate complex computer systems for 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 macros or scripts for their 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. Sometimes logging for critical systems is done by + mirroring the same traffic to two different systems. Care must be + taken so that no matter what the log output is, the logs should be + parsed so they are equivalent. + + + + + + + +Kawamura & Kawashima Standards Track [Page 7] + +RFC 5952 IPv6 Text Representation August 2010 + + +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 show 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 diffs 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. The + result of an SNMP GET operation, converted to text and compared to a + textual address written by a human is highly unlikely to match on the + 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 field in a + certificate was incorrectly verified by converting it to text and + making a simple textual comparison to some other address, the + certificate may be mistakenly 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. 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. Someone familiar with IPv6 address + representation will know that the right address is set, but not + everyone may understand this. + + + +Kawamura & Kawashima Standards Track [Page 8] + +RFC 5952 IPv6 Text Representation August 2010 + + +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 do they have a similar skill level in + IPv6 technology. The network operations center 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 addresses cannot be abbreviated. + +3.3.3. Abuse + + Network abuse reports generally include 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 + uppercase or lowercase. However, when a letter is spelled uppercase, + people tend to specify 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 anyway, but flexibility in address representation will increase + the work load. + +3.4.2. Preference in Documentation + + A document that is edited by more than one author may become harder + to read. + +3.4.3. Legibility + + Capital case D and 0 can be quite often misread. Capital B and 8 can + also be misread. + + + + + + +Kawamura & Kawashima Standards Track [Page 9] + +RFC 5952 IPv6 Text Representation August 2010 + + +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 section SHOULD be followed by systems when generating an + address to be represented as text, but all implementations MUST + accept and be able to handle any legitimate [RFC4291] format. It is + advised that humans also follow these recommendations when spelling + an address. + +4.1. Handling Leading Zeros in a 16-Bit Field + + Leading zeros MUST be suppressed. For example, 2001:0db8::0001 is + not acceptable and must be represented as 2001:db8::1. A single 16- + bit 0000 field MUST be represented as 0. + +4.2. "::" Usage + +4.2.1. Shorten as Much as Possible + + The use of the symbol "::" MUST be used to its maximum capability. + For example, 2001:db8:0:0:0:0:2:1 must be shortened to 2001:db8::2:1. + Likewise, 2001:db8::0:1 is not acceptable, because the symbol "::" + could have been used to produce a shorter representation 2001:db8::1. + +4.2.2. Handling One 16-Bit 0 Field + + The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. + For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but + 2001:db8::1:1:1:1:1 is not correct. + +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 MUST be shortened (i.e., + the sequence with three consecutive zero fields 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 first sequence of zero + bits MUST be shortened. For example, 2001:db8::1:0:0:1 is correct + representation. + +4.3. Lowercase + + The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address + MUST be represented in lowercase. + + + + +Kawamura & Kawashima Standards Track [Page 10] + +RFC 5952 IPv6 Text Representation August 2010 + + +5. Text Representation of Special Addresses + + Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and + IPv4-translatable addresses [ADDR-FORMAT] have IPv4 addresses + embedded in the low-order 32 bits of the address. These addresses + have a special representation that may mix hexadecimal and dot + decimal notations. The decimal notation may be used only for the + last 32 bits of the address. For these addresses, mixed notation is + RECOMMENDED if the following condition is met: the address can be + distinguished as having IPv4 addresses embedded in the lower 32 bits + solely from the address field through the use of a well-known prefix. + Such prefixes are defined in [RFC4291] and [RFC2765] at the time of + this writing. If it is known by some external method that a given + prefix is used to embed IPv4, it MAY be represented as mixed + notation. Tools that provide options to specify prefixes that are + (or are not) to be represented as mixed notation may be useful. + + There is a trade-off here where a recommendation to achieve an exact + match in a search (no dot decimals whatsoever) and a recommendation + to help the readability of an address (dot decimal whenever possible) + does not result in the same solution. The above recommendation is + aimed at fixing the representation as much as possible while leaving + the opportunity for future well-known prefixes to be represented in a + human-friendly manner as tools adjust to newly assigned prefixes. + + 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 + + There are many different ways to combine IPv6 addresses and port + numbers that are represented in text. 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 + + + +Kawamura & Kawashima Standards Track [Page 11] + +RFC 5952 IPv6 Text Representation August 2010 + + + IPv6 addresses. This style is NOT RECOMMENDED because of its + ambiguity. The [] style as expressed in [RFC3986] SHOULD be + employed, and is the default unless otherwise specified. Other + styles are acceptable when there is exactly one style for the given + context and cross-platform portability does not become an issue. For + URIs containing IPv6 address literals, [RFC3986] MUST be followed, as + well as the rules defined in this document. + +7. Prefix Representation + + Problems with prefixes are the same as problems encountered with + addresses. The text representation method of IPv6 prefixes should be + no different from that of IPv6 addresses. + +8. Security Considerations + + This document notes some examples where IPv6 addresses are compared + in text format. The example on Section 3.2.5 is one that may cause a + security risk if used for access control. The common practice of + comparing X.509 data is done in binary format. + +9. Acknowledgements + + The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami, + and 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, Dan Wing, and Doug Barton 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 light in IETF working groups. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [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. + + + + + +Kawamura & Kawashima Standards Track [Page 12] + +RFC 5952 IPv6 Text Representation August 2010 + + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + +10.2. Informative References + + [ADDR-FORMAT] Bao, C., "IPv6 Addressing of IPv4/IPv6 Translators", + Work in Progress, July 2010. + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kawamura & Kawashima Standards Track [Page 13] + +RFC 5952 IPv6 Text Representation August 2010 + + +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. + +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 Standards Track [Page 14] + -- cgit v1.2.3