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