idnits 2.17.1 draft-ietf-6man-text-addr-representation-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4291, but the abstract doesn't seem to directly say this. It does mention RFC4291 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC4291, updated by this document, for RFC5378 checks: 2003-10-10) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2010) is 5166 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-04 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance Working Group S. Kawamura 3 Internet-Draft NEC BIGLOBE, Ltd. 4 Updates: 4291 (if approved) M. Kawashima 5 Intended status: Standards Track NEC AccessTechnica, Ltd. 6 Expires: August 29, 2010 February 25, 2010 8 A Recommendation for IPv6 Address Text Representation 9 draft-ietf-6man-text-addr-representation-07 11 Abstract 13 As IPv6 deployment increases there will be a dramatic increase in the 14 need to use IPv6 addresses in text. While the IPv6 address 15 architecture in RFC 4291 section 2.2 describes a flexible model for 16 text representation of an IPv6 address this flexibility has been 17 causing problems for operators, system engineers, and users. This 18 document defines a canonical textual representation format. It does 19 not define a format for internal storage, such as within an 20 application or database. It is expected that the canonical format is 21 followed by humans and systems when representing IPv6 addresses as 22 text, but all implementations must accept and be able to handle any 23 legitimate RFC 4291 format. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on August 29, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 2. Text Representation Flexibility of RFC4291 . . . . . . . . . . 4 67 2.1. Leading Zeros in a 16 Bit Field . . . . . . . . . . . . . 4 68 2.2. Zero Compression . . . . . . . . . . . . . . . . . . . . . 5 69 2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 5 70 3. Problems Encountered with the Flexible Model . . . . . . . . . 6 71 3.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.1.1. General Summary . . . . . . . . . . . . . . . . . . . 6 73 3.1.2. Searching Spreadsheets and Text Files . . . . . . . . 6 74 3.1.3. Searching with Whois . . . . . . . . . . . . . . . . . 6 75 3.1.4. Searching for an Address in a Network Diagram . . . . 7 76 3.2. Parsing and Modifying . . . . . . . . . . . . . . . . . . 7 77 3.2.1. General Summary . . . . . . . . . . . . . . . . . . . 7 78 3.2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . 7 79 3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 7 80 3.2.4. Auditing: Case 2 . . . . . . . . . . . . . . . . . . . 8 81 3.2.5. Verification . . . . . . . . . . . . . . . . . . . . . 8 82 3.2.6. Unexpected Modifying . . . . . . . . . . . . . . . . . 8 83 3.3. Operating . . . . . . . . . . . . . . . . . . . . . . . . 8 84 3.3.1. General Summary . . . . . . . . . . . . . . . . . . . 8 85 3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 8 86 3.3.3. Abuse . . . . . . . . . . . . . . . . . . . . . . . . 9 87 3.4. Other Minor Problems . . . . . . . . . . . . . . . . . . . 9 88 3.4.1. Changing Platforms . . . . . . . . . . . . . . . . . . 9 89 3.4.2. Preference in Documentation . . . . . . . . . . . . . 9 90 3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 9 91 4. A Recommendation for IPv6 Text Representation . . . . . . . . 9 92 4.1. Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10 93 4.2. "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10 94 4.2.1. Shorten As Much As Possible . . . . . . . . . . . . . 10 95 4.2.2. Handling One 16 Bit 0 Field . . . . . . . . . . . . . 10 96 4.2.3. Choice in Placement of "::" . . . . . . . . . . . . . 10 97 4.3. Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 10 98 5. Text Representation of Special Addresses . . . . . . . . . . . 10 99 6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11 100 7. Prefix Representation . . . . . . . . . . . . . . . . . . . . 12 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 102 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 103 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 105 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 106 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 107 Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 13 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 110 1. Introduction 112 A single IPv6 address can be text represented in many ways. Examples 113 are shown below. 115 2001:db8:0:0:1:0:0:1 117 2001:0db8:0:0:1:0:0:1 119 2001:db8::1:0:0:1 121 2001:db8::0:1:0:0:1 123 2001:0db8::1:0:0:1 125 2001:db8:0:0:1::1 127 2001:db8:0000:0:1::1 129 2001:DB8:0:0:1::1 131 All of the above examples represent the same IPv6 address. This 132 flexibility has caused many problems for operators, systems 133 engineers, and customers. The problems are noted in Section 3. 134 Also, a canonical representation format to avoid problems is 135 introduced in Section 4. 137 1.1. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 2. Text Representation Flexibility of RFC4291 145 Examples of flexibility in Section 2.2 of [RFC4291] are described 146 below. 148 2.1. Leading Zeros in a 16 Bit Field 150 'It is not necessary to write the leading zeros in an individual 151 field.' 153 Conversely it is also not necessary to omit leading zeros. This 154 means that, it is possible to select from such as the following 155 example. The final 16 bit field is different, but all these 156 addresses represent the same address. 158 2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001 160 2001:db8:aaaa:bbbb:cccc:dddd:eeee:001 162 2001:db8:aaaa:bbbb:cccc:dddd:eeee:01 164 2001:db8:aaaa:bbbb:cccc:dddd:eeee:1 166 2.2. Zero Compression 168 'A special syntax is available to compress the zeros. The use of 169 "::" indicates one or more groups of 16 bits of zeros.' 171 It is possible to select whether or not to omit just one 16 bits of 172 zeros. 174 2001:db8:aaaa:bbbb:cccc:dddd::1 176 2001:db8:aaaa:bbbb:cccc:dddd:0:1 178 In case where there is more than one zero fields, there is a choice 179 of how many fields can be shortened. 181 2001:db8:0:0:0::1 183 2001:db8:0:0::1 185 2001:db8:0::1 187 2001:db8::1 189 In addition, [RFC4291] in section 2.2 notes, 191 'The "::" can only appear once in an address.' 193 This gives a choice on where in a single address to compress the 194 zero. 196 2001:db8::aaaa:0:0:1 198 2001:db8:0:0:aaaa::1 200 2.3. Uppercase or Lowercase 202 [RFC4291] does not mention any preference of uppercase or lowercase. 204 2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa 206 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA 208 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa 210 3. Problems Encountered with the Flexible Model 212 3.1. Searching 214 3.1.1. General Summary 216 A search of an IPv6 address if conducted through a UNIX system is 217 usually case sensitive and extended options to allow for regular 218 expression use will come in handy. However, there are many 219 applications in the Internet today that do not provide this 220 capability. When searching for an IPv6 address in such systems, the 221 system engineer will have to try each and every possibility to search 222 for an address. This has critical impacts especially when trying to 223 deploy IPv6 over an enterprise network. 225 3.1.2. Searching Spreadsheets and Text Files 227 Spreadsheet applications and text editors on GUI systems, rarely have 228 the ability to search for a text using regular expression. Moreover, 229 there are many non-engineers (who are not aware of case sensitivity 230 and regular expression use) that use these application to manage IP 231 addresses. This has worked quite well with IPv4 since text 232 representation in IPv4 has very little flexibility. There is no 233 incentive to encourage these non-engineers to change their tool or 234 learn regular expression when they decide to go dual-stack. If the 235 entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was 236 conducted as 2001:db8:0:0:1::1, this will show a result of no match. 237 One example where this will cause problem is, when the search is 238 being conducted to assign a new address from a pool, and a check was 239 being done to see if it was not in use. This may cause problems to 240 the end-hosts or end-users. This type of address management is very 241 often seen in enterprise networks and also in ISPs. 243 3.1.3. Searching with Whois 245 The "whois" utility is used by a wide range of people today. When a 246 record is set to a database, one will likely check the output to see 247 if the entry is correct. If an entity was recorded as 2001:db8::/48, 248 but the whois output showed 2001:0db8:0000::/48, most non-engineers 249 would think that their input was wrong and will likely retry several 250 times or make a frustrated call to the database hostmaster. If there 251 was a need to register the same address on different systems, and 252 each system showed a different text representation, this would 253 confuse people even more. Although this document focuses on 254 addresses rather than prefixes, this is worth mentioning since the 255 problems encountered are mostly equal. 257 3.1.4. Searching for an Address in a Network Diagram 259 Network diagrams and blueprints often show what IP addresses are 260 assigned to a system devices. In times of trouble shooting there may 261 be a need to search through a diagram to find the point of failure 262 (for example, if a traceroute stopped at 2001:db8::1, one would 263 search the diagram for that address). This is a technique quite 264 often in use in enterprise networks and managed services. Again, the 265 different flavors of text representation will result in a time- 266 consuming search leading to longer MTTR in times of trouble. 268 3.2. Parsing and Modifying 270 3.2.1. General Summary 272 With all the possible methods of text representation each application 273 must include a module, object, link, etc. to a function that will 274 parse IPv6 addresses in a manner that no matter how it is 275 represented, they will mean the same address. Many system engineers 276 who integrate complex computer systems for corporate customers will 277 have difficulties finding that their favorite tool will not have this 278 function, or will encounter difficulties such as having to rewrite 279 their macros or scripts for their customers. 281 3.2.2. Logging 283 If an application were to output a log summary that represented the 284 address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444), 285 the output would be highly unreadable compared to the IPv4 output. 286 The address would have to be parsed and reformed to make it useful 287 for human reading. Sometimes logging for critical systems is done by 288 mirroring the same traffic to two different systems. Care must be 289 taken so that no matter what the log output is the logs should be 290 parsed so they will mean the same. 292 3.2.3. Auditing: Case 1 294 When a router or any other network appliance machine configuration is 295 audited, there are many methods to compare the configuration 296 information of a node. Sometimes auditing will be done by just 297 comparing the changes made each day. In this case if configuration 298 was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000: 300 0000:0000:0000:0001 just because the new engineer on the block felt 301 it was better, a simple diff will show that a different address was 302 configured. If this was done on a wide scale network people will be 303 focusing on 'why the extra zeros were put in' instead of doing any 304 real auditing. Lots of tools are just plain diffs that do not take 305 into account address representation rules. 307 3.2.4. Auditing: Case 2 309 Node configurations will be matched against an information system 310 that manages IP addresses. If output notation is different there 311 will need to be a script that is implemented to cover for this. The 312 result of an SNMP GET operation, converted to text and compared to a 313 textual address written by a human is highly unlikely to match on the 314 first try. 316 3.2.5. Verification 318 Some protocols require certain data fields to be verified. One 319 example of this is X.509 certificates. If an IPv6 address field in a 320 certificate was incorrectly verified by converting it to text and 321 making a simple textual comparison to some other address, the 322 certificate may be mistakenly shown as being invalid due to a 323 difference in text representation methods. 325 3.2.6. Unexpected Modifying 327 Sometimes, a system will take an address and modify it as a 328 convenience. For example, a system may take an input of 329 2001:0db8:0::1 and make the output 2001:db8::1. If the zeros were 330 input for a reason, the outcome may be somewhat unexpected. 332 3.3. Operating 334 3.3.1. General Summary 336 When an operator sets an IPv6 address of a system as 2001:db8:0:0:1: 337 0:0:1, the system may take the address and show the configuration 338 result as 2001:DB8::1:0:0:1. Someone familiar with IPv6 address 339 representation will know that the right address is set, but not 340 everyone may understand this. 342 3.3.2. Customer Calls 344 When a customer calls to inquire about a suspected outage, IPv6 345 address representation should be handled with care. Not all 346 customers are engineers nor have the same skill in IPv6 technology. 347 The network operations center will have to take extra steps to 348 humanly parse the address to avoid having to explain to the customers 349 that 2001:db8:0:1::1 is the same as 2001:db8::1:0:0:0:1. This is one 350 thing that will never happen in IPv4 because IPv4 address cannot be 351 abbreviated. 353 3.3.3. Abuse 355 Network abuse reports generally include the abusing IP address. This 356 'reporting' could take any shape or form of the flexible model. A 357 team that handles network abuse must be able to tell the difference 358 between a 2001:db8::1:0:1 and 2001:db8:1::0:1. Mistakes in the 359 placement of the "::" will result in a critical situation. A system 360 that handles these incidents should be able to handle any type of 361 input and parse it in a correct manner. Also, incidents are reported 362 over the phone. It is unnecessary to report if the letter is an 363 uppercase or lowercase. However, when a letter is spelled uppercase, 364 people tend to clarify that it is uppercase, which is unnecessary 365 information. 367 3.4. Other Minor Problems 369 3.4.1. Changing Platforms 371 When an engineer decides to change the platform of a running service, 372 the same code may not work as expected due to the difference in IPv6 373 address text representation. Usually, a change in a platform (e.g. 374 Unix to Windows, Cisco to Juniper) will result in a major change of 375 code anyway, but flexibility in address representation will increase 376 the work load. 378 3.4.2. Preference in Documentation 380 A document that is edited by more than one author may become harder 381 to read. 383 3.4.3. Legibility 385 Capital case D and 0 can be quite often misread. Capital B and 8 can 386 also be misread. 388 4. A Recommendation for IPv6 Text Representation 390 A recommendation for a canonical text representation format of IPv6 391 addresses is presented in this section. The recommendation in this 392 document is one that, complies fully with [RFC4291], is implemented 393 by various operating systems, and is human friendly. The 394 recommendation in this section SHOULD be followed by systems when 395 generating an address to represent as text, but all implementations 396 MUST accept and be able to handle any legitimate [RFC4291] format. 397 It is advised that humans also follow these recommendations when 398 spelling an address. 400 4.1. Handling Leading Zeros in a 16 Bit Field 402 Leading zeros MUST be suppressed. For example 2001:0db8::0001 is not 403 acceptable and must be represented as 2001:db8::1. A single 16 bit 404 0000 field MUST be represented as 0. 406 4.2. "::" Usage 408 4.2.1. Shorten As Much As Possible 410 The use of symbol "::" MUST be used to its maximum capability. For 411 example, 2001:db8::0:1 is not acceptable, because the symbol "::" 412 could have been used to produce a shorter representation 2001:db8::1. 414 4.2.2. Handling One 16 Bit 0 Field 416 The symbol "::" MUST NOT be used to shorten just one 16 bit 0 field. 417 For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 418 2001:db8::1:1:1:1:1 is not correct. 420 4.2.3. Choice in Placement of "::" 422 When there is an alternative choice in the placement of a "::", the 423 longest run of consecutive 16 bit 0 fields MUST be shortened (i.e. 424 the sequence with three consecutive zero fields is shortened in 2001: 425 0:0:1:0:0:0:1). When the length of the consecutive 16 bit 0 fields 426 are equal (i.e. 2001:db8:0:0:1:0:0:1), the first sequence of zero 427 bits MUST be shortened. For example 2001:db8::1:0:0:1 is correct 428 representation. 430 4.3. Lower Case 432 The characters "a", "b", "c", "d", "e", "f" in an IPv6 address MUST 433 be represented in lower case. 435 5. Text Representation of Special Addresses 437 Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and 438 IPv4-translatable addresses [I-D.ietf-behave-address-format] have 439 IPv4 addresses embedded in the low-order 32 bits of the address. 440 These addresses have special representation that may mix hexadecimal 441 and dot decimal notations. The decimal notation may be used only for 442 the last 32 bits of the address. For these addresses, mixed notation 443 is RECOMMENDED if the following condition is met: The address can be 444 distinguished as having IPv4 addresses embedded in the lower 32 bits 445 solely from the address field through the use of a well known prefix. 446 Such prefixes are defined in [RFC4291] and [RFC2765] at the time of 447 writing. If it is known by some external method that a given prefix 448 is used to embed IPv4, it MAY be represented as mixed notation. 449 Tools that provide options to specify prefixes that are (or are not) 450 to be represented as mixed notation may be useful. 452 There is a trade-off here where a recommendation to achieve exact 453 match in a search (no dot decimals whatsoever) and recommendation to 454 help the readability of an addresses (dot decimal whenever possible) 455 does not result in the same solution. The above recommendation is 456 aimed at fixing the representation as much as possible while leaving 457 the opportunity for future well known prefixes to be represented in a 458 human friendly manner as tools adjust to newly assigned prefixes. 460 The text representation method noted in Section 4 should be applied 461 for the leading hexadecimal part (i.e. ::ffff:192.0.2.1 instead of 462 0:0:0:0:0:ffff:192.0.2.1). 464 6. Notes on Combining IPv6 Addresses with Port Numbers 466 When IPv6 addresses and port numbers are represented in text combined 467 together, there are many different ways to do so. Examples are shown 468 below. 470 o [2001:db8::1]:80 472 o 2001:db8::1:80 474 o 2001:db8::1.80 476 o 2001:db8::1 port 80 478 o 2001:db8::1p80 480 o 2001:db8::1#80 482 The situation is not much different in IPv4, but the most ambiguous 483 case with IPv6 is the second bullet. This is due to the "::"usage in 484 IPv6 addresses. This style is NOT RECOMMENDED for its ambiguity. 485 The [] style as expressed in [RFC3986] SHOULD be employed, and is the 486 default unless otherwise specified. Other styles are acceptable when 487 there is exactly one style for the given context and cross-platform 488 portability does not become an issue. For URIs containing IPv6 489 address literals, [RFC3986] MUST be followed, as well as the rules in 490 this document. 492 7. Prefix Representation 494 Problems with prefixes are just the same as problems encountered with 495 addresses. The text representation method of IPv6 prefixes should be 496 no different from that of IPv6 addresses. 498 8. Security Considerations 500 This document notes some examples where IPv6 addresses are compared 501 in text format. The example on Section 3.2.5 is one that may cause a 502 security risk if used for access control. The common practice of 503 comparing X.509 data is done in binary format. 505 9. IANA Considerations 507 None. 509 10. Acknowledgements 511 The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami, 512 Toshimitsu Matsuura for their generous and helpful comments in kick 513 starting this document. We also would like to thank Brian Carpenter, 514 Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler, 515 Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki 516 Vatiainen ,Dan Wing, and Doug Barton for their input. Also a very 517 special thanks to Ron Bonica, Fred Baker, Brian Haberman, Robert 518 Hinden, Jari Arkko, and Kurt Lindqvist for their support in bringing 519 this document to the light of IETF working groups. 521 11. References 523 11.1. Normative References 525 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 526 Requirement Levels", BCP 14, RFC 2119, March 1997. 528 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 529 (SIIT)", RFC 2765, February 2000. 531 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 532 Resource Identifier (URI): Generic Syntax", STD 66, 533 RFC 3986, January 2005. 535 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 536 Architecture", RFC 4291, February 2006. 538 11.2. Informative References 540 [I-D.ietf-behave-address-format] 541 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 542 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 543 draft-ietf-behave-address-format-04 (work in progress), 544 January 2010. 546 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 547 Castro, "Application Aspects of IPv6 Transition", 548 RFC 4038, March 2005. 550 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 551 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 552 March 2008. 554 Appendix A. For Developers 556 We recommend that developers use display routines that conform to 557 these rules. For example, the usage of getnameinfo() with flags 558 argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output, 559 except for the special addresses notes in Section 5. The function 560 inet_ntop() of FreeBSD7.0 is a good C code reference, but should not 561 be called directly. See [RFC4038] for details. 563 Authors' Addresses 565 Seiichi Kawamura 566 NEC BIGLOBE, Ltd. 567 14-22, Shibaura 4-chome 568 Minatoku, Tokyo 108-8558 569 JAPAN 571 Phone: +81 3 3798 6085 572 Email: kawamucho@mesh.ad.jp 573 Masanobu Kawashima 574 NEC AccessTechnica, Ltd. 575 800, Shimomata 576 Kakegawa-shi, Shizuoka 436-8501 577 JAPAN 579 Phone: +81 537 23 9655 580 Email: kawashimam@necat.nec.co.jp