idnits 2.17.1 draft-main-ipaddr-text-rep-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 610. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([SMTP-1], [SMTP-2], [MTP], [IPV6-AA-2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Unrecognized Status in 'Category: Standards-Track', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (2005-02-23) is 6995 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 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 2133 (ref. 'BSI-IPV6-1') (Obsoleted by RFC 2553) -- Obsolete informational reference (is this intentional?): RFC 810 (ref. 'HOST-TBL-2') (Obsoleted by RFC 952) -- Obsolete informational reference (is this intentional?): RFC 790 (ref. 'IPV4-NUMB') (Obsoleted by RFC 820) -- Obsolete informational reference (is this intentional?): RFC 1884 (ref. 'IPV6-AA-1') (Obsoleted by RFC 2373) -- Obsolete informational reference (is this intentional?): RFC 2373 (ref. 'IPV6-AA-2') (Obsoleted by RFC 3513) -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. 'IPV6-AA-3') (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 780 (ref. 'MTP') (Obsoleted by RFC 788, RFC 821, RFC 974, RFC 1869, RFC 1870) -- Obsolete informational reference (is this intentional?): RFC 821 (ref. 'SMTP-1') (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. 'SMTP-2') (Obsoleted by RFC 5321) Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Main 3 Internet-Draft: draft-main-ipaddr-text-rep-02 Black Ops Ltd 4 Category: Standards-Track 2005-02-23 5 Expires: 2005-08-23 7 Textual Representation of IPv4 and IPv6 Addresses 9 Status of this Memo 11 This document is an Internet-Draft. 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 Historically, the conventional textual representations of IPv4 and 37 IPv6 addresses have been poorly specified. This document gives 38 precise definitions of these conventions, together with advice for 39 implementors. 41 Change Log 43 Changes from -01 to -02: 45 o Updated reference to what is now RFC 3986. 47 Changes from -00 to -01: 49 Internet-Draft Textual Representation of IP Addresses 2005-02-23 51 o Discussion of the ABNF grammar for IPv4 addresses given in [MTP] 52 and [SMTP-1]. 54 o Explanation of the faulty ABNF grammar in [IPV6-AA-2]. 56 o Mention of another faulty grammar for IPv6 addresses in [SMTP-2]. 58 o Specific references for the enclosing of IP addresses in brackets. 60 o Changed intended category from Informational to Standards-Track. 62 o A couple of minor wording changes. 64 o Updated author's address. 66 1 Introduction 68 For as long as IP has existed, there has been a need to represent IP 69 addresses in textual contexts, but the nature of these requirements 70 has changed. IP addresses are textually represented much more widely 71 than appears to have been originally envisioned; in particular, such 72 representation has become a part of many network protocols. There is 73 an increasing need for interoperability in IP address textual 74 representations, for it is more commonly software than humans that 75 read and write addresses in this format. 77 Historically, the definitions of IP address textual representations 78 have been loose, underspecifying the syntax. They have also always 79 been a minor part of a standard whose main focus is some other 80 problem. This makes them difficult to locate and inconvenient to 81 cite. With IPv6 address textual representation incorporating the 82 IPv4 format by reference, the IPv6 format has not previously been 83 completely specified in a single RFC. 85 This document collects together the complete syntax for textual 86 representation of IPv4 and IPv6 addresses, clarifying the 87 underspecified parts. It is intended to be a complete and 88 unambiguous specification of these address formats, located together 89 in a single document for ease of reference. 91 Section 2 of this document discusses the history of the specification 92 and implementation of textual representation of IP addresses. 93 Section 3 gives the complete syntax. Section 4 gives some advice for 94 implementors. 96 1.1 Requirements Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 100 Internet-Draft Textual Representation of IP Addresses 2005-02-23 102 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 103 interpreted as described in [REQ-TERM]. 105 1.2 Augmented BNF Notation 107 Syntax specifications in this document use augmented BNF notation as 108 defined in [ABNF]. The `core rules' in appendix A of [ABNF] are used 109 as defined there. 111 2 History 113 2.1 IPv4 Dotted Octet Format 115 2.1.1 Early Practice 117 The original IPv4 "dotted octet" format was never fully defined in 118 any RFC, so it is necessary to look at usage, rather than merely find 119 an authoritative definition, to determine what the effective syntax 120 was. The first mention of dotted octets in the RFC series is in 121 [MTP], a predecessor of SMTP, which interestingly mentions two 122 address formats that evidently by then had some currency: 124 One form is a decimal integer prefixed by a pound sign, "#", 125 which indicates the number is the address of the host. Another 126 form is four small decimal integers separated by dots and 127 enclosed by brackets, e.g., "[123.255.37.321]", which indicates 128 a 32 bit ARPA Internet Address in four eight bit fields. 130 [MTP] also gives a partial ABNF specification for these address 131 formats. The grammar requires four dot-separated parts, each of 132 which consists of "three digits representing an integer value in the 133 range 0 through 255". Presumably the exclusion of one- and two-digit 134 parts is a mistake, since it clashes with the example quoted above. 135 [MTP]'s descendent [SMTP-1] gives the same partial ABNF but requires 136 each part to consist of "one, two, or three digits representing a 137 decimal integer value in the range 0 through 255". 139 A few months later, [IPV4-NUMB] (the "Assigned Numbers" RFC published 140 at the same time as [IPV4]) gave, for the first time, a table of 141 assigned IP addresses. (Previous "Assigned Numbers" RFCs, predating 142 classful addressing, had merely had a table of "network numbers". 143 Although the new table retained the title "assigned network numbers", 144 it was actually expressed in terms of address blocks.) This table 145 used dotted decimal format, zero-filling each encoded octet to three 146 digits. The notes accompanying the table said: 148 One notation for internet host addresses commonly used divides 149 the 32-bit address into four 8-bit fields and specifies the 151 Internet-Draft Textual Representation of IP Addresses 2005-02-23 153 value of each field as a decimal number with the fields 154 separated by periods. For example, the internet address of ISIF 155 is 010.020.000.052. This notation will be used in the listing 156 of assigned network numbers. 158 Shortly thereafter, [NCP-TCP] gave a handful of live IP addresses 159 without comment on the format, for example, "ARPANET/SATNET gateway 160 at BBN (10.3.0.40)". 162 The next description of dotted octet notation is in [HOST-TBL-2], 163 defining the host table file format, which describes the notation as 164 "four decimal numbers separated by a period. Each decimal number 165 represents 1 octet.". One of its example host table entries was 166 "GATEWAY : 10.0.0.77, 18.8.0.4 : MIT-GW :: MOS : IP/GW :". 168 It is at this point in the history that [SMTP-1] reiterated the 169 formal grammar given in [MTP], with the emendation to unambiguously 170 allow decimal numbers of fewer than three digits. 172 [HREQ-APP], a much later and more significant standard, describes IP 173 address text representation, in the course of recommending that 174 applications allow users to specify IP addresses directly as well as 175 via DNS host names. It merely describes the format as "dotted- 176 decimal ("#.#.#.#") form". It gives no example of an address in this 177 format. 179 So far we have seen dotted octet format in five different types of 180 situation: a network protocol (machine-parsed email address), a table 181 of address blocks, English text (discussion the NCP to TCP/IP 182 switch), a machine-readable database (the host table), and human 183 interfaces to network applications. All are consistent about 184 dividing the address into octets and representing each octet purely 185 in decimal, but there are two variants of the format due to a more 186 subtle issue. The explicit descriptions of the format given so far 187 have been silent about the permissibility of leading zeroes in octet 188 representations; only one example, a human-oriented table of 189 addresses, used leading zeroes. 191 This variation in the format, presumably initially intended to be of 192 no consequence, lives on today. The direct descendent of 193 [IPV4-NUMB]'s "assigned network numbers" table is the IANA-maintained 194 "ipv4-address-space" table, which at the date of this document still 195 shows octet values in zero-filled three-digit decimal. In all non- 196 table contexts in which IPv4 addresses appear, including anything 197 intended to be machine-readable, almost universally leading zeroes 198 are suppressed. (Curiously, a different IANA-maintained table, the 199 "multicast-addresses" table of IPv4 multicast addresses, uses a 200 mixture of zero-filled and zero-suppressed octet values.) 202 Internet-Draft Textual Representation of IP Addresses 2005-02-23 204 Meanwhile, a very popular implementation of IP networking went off in 205 its own direction. 4.2BSD introduced a function inet_aton(), whose 206 job was to interpret character strings as IP addresses. It 207 interpreted both of the syntaxes mentioned in [MTP] (see above): a 208 single number giving the entire 32-bit address, and dot-separated 209 octet values. It also interpreted two intermediate syntaxes: octet- 210 dot-octet-dot-16bits, intended for class B addresses, and octet- 211 dot-24bits, intended for class A addresses. It also allowed some 212 flexibility in how the individual numeric parts were specified: it 213 allowed octal and hexadecimal in addition to decimal, distinguishing 214 these radices by using the C language syntax involving a prefix "0" 215 or "0x", and allowed the numbers to be arbitrarily long. 217 The 4.2BSD inet_aton() has been widely copied and imitated, and so is 218 a de facto standard for the textual representation of IPv4 addresses. 219 Nevertheless, these alternative syntaxes have now fallen out of use 220 (if they ever had significant use). The only practical use that they 221 now see is for deliberate obfuscation of addresses: giving an IPv4 222 address as a single 32-bit decimal number is favoured among people 223 wishing to conceal the true location that is encoded in a URL. All 224 the forms except for decimal octets are seen as non-standard (despite 225 being quite widely interoperable) and undesirable. 227 2.1.2 Revision From IPv6 Work 229 When the textual format for IPv6 addresses was developed, part of the 230 syntax involved representing an embedded IPv4 address by embedding an 231 IPv4 address textual representation in the IPv6 textual format. 232 [IPV6-AA-1], describing the IPv6 format for the first time, referred 233 simply to "decimal values of the four low-order 8-bit pieces of the 234 address (standard IPv4 representation)", giving "::13.1.68.3" as an 235 example of the format in practice. 237 [IPV6-AA-2] added an ABNF grammar, giving the first formal 238 specification of IPv4 textual address syntax in the RFC series. This 239 grammar showed dot-separated segments of one to three decimal digits 240 each. Unfortunately, there were some errors in related bits of the 241 grammar, and even with errors corrected the IPv6 address grammar was 242 loose, syntactically permitting addresses of the wrong length. This, 243 together with the similar looseness of the IPv4 address grammar 244 (which would match "123.456.789.999"), left open the question of 245 whether the grammar's acceptance of leading zeroes in IPv4 addresses 246 was an intentional feature, an error, or deliberate looseness. 247 [IPV6-AA-3], rather than correct the errors, withdrew the grammar. 249 The IPv6 effort also had an opportunity to advance the other branch 250 of development of IPv4 address representation. [BSI-IPV6-1] doesn't 251 attempt to modify inet_aton(), but defines a new function 253 Internet-Draft Textual Representation of IP Addresses 2005-02-23 255 inet_pton(), which, in handling IPv4 addresses, accepts dotted 256 decimal octets where each octet is encoded as "a one to three digit 257 decimal number between 0 and 255". The variant forms traditionally 258 accepted by inet_aton() are explicitly excluded. This definition is 259 still not explicit about the handling of leading zeroes, but it seems 260 to be intended to allow them, and it is being implemented 261 accordingly. 263 2.1.3 Finale 265 So far we've seen two parallel versions of IPv4 address textual 266 syntax, which we may label the IETF version and the BSD version. The 267 difference has persisted for so long because the two are just 268 sufficiently interoperable: they both handle in the same way the 269 overwhelmingly dominant syntax, dotted decimal octets with leading 270 zeroes suppressed. In all the other address forms they support they 271 disagree: the IETF syntax makes nothing of most of the variants that 272 BSD allows, and the two interpret differently a large group of 273 representations involving leading zeroes, which is why zeroes have 274 been mentioned so much in the foregoing history. 276 As of this writing, IPv4 addresses written with leading zeroes are de 277 facto ambiguous. Although all IETF output that expresses an opinion 278 has consistently indicated that these should be interpreted as 279 decimal, implementations that interpret them as octal are far too 280 widespread to ignore. For this reason it is not safe to generate 281 such addresses; the only way to generate an interoperable textual 282 IPv4 address is to suppress leading zeroes. Overwhelmingly popular 283 practice is, indeed, to avoid leading zeroes. 285 The most recent version of the URI syntax [URI] attempts to reconcile 286 these variants in order to give a precise definition for acceptable 287 IP address syntax in a URL. (Its predecessors had incorporated the 288 traditionally ambiguous syntax by reference.) [URI] is the first RFC 289 to require a completely rigorous definition of IP address syntax. 290 The approach taken was to standardise the safe common subset of the 291 IETF and BSD syntaxes, which achieves standardisation on IETF-like 292 syntax while also retaining backward compatibility with existing BSD- 293 based implementations. 295 This document, in section 3.1, presents the IPv4 address grammar from 296 [URI]. 298 2.2 IPv6 Presentation Format 300 The development of the IPv6 address presentation format has been 301 simpler than the IPv4 history. The divergence between specification 302 and implementation has been less significant, and there has been 304 Internet-Draft Textual Representation of IP Addresses 2005-02-23 306 conscious effort to fully specify the format rather than leave it as 307 oral tradition. 309 The first appearance of IPv6 address textual format in the RFC series 310 is the specification of the format in [IPV6-AA-1]. This 311 specification's relevant features are: a basic format of eight colon- 312 separated 16-bit pieces; each piece represented in hexadecimal, with 313 leading zeroes "not necessary" (examples are given both with and 314 without leading zeroes); optional use of "::", once in an address, to 315 indicate a run of zero-valued 16-bit pieces; optional use of 316 "standard IPv4 representation" for the least-significant 32 bits of 317 the address. 319 Note that this doesn't say what the maximum length of a piece 320 representation is, or whether "::" can be used in an address where 321 all 16-bit pieces are given explicitly (the "::" would represent a 322 sequence of zero consecutive zero-valued pieces). 324 [IPV6-AA-2] didn't substantially modify the description of the 325 syntax, but augmented it with an ABNF grammar. The grammar specified 326 that a 16-bit piece could be represented in one to four case- 327 insensitive hexadecimal digits, ruling out the use of more than four 328 digits per piece. There were some errors in the grammar, making it 329 inappropriate as a reference, and some looseness that makes it 330 impossible to clear up any other syntactic uncertainty from it. 331 These errors resulted from a "rough cut" grammar getting into the RFC 332 largely unchanged, clearly without serious analysis. 334 [SMTP-2] gives an ABNF grammar for IPv6 address literals in email 335 addresses. Unfortunately this grammar, also, is faulty and loose, 336 but it concurs with the [IPV6-AA-2] grammar in requiring each piece 337 to consist of one to four hexadecimal digits. 339 [IPV6-AA-3] dropped the faulty grammar from [IPV6-AA-2], and amended 340 the format description to say that "::" represents "one or more" 341 16-bit pieces. This amended description leaves unclear only the 342 issue of whether a 16-bit piece is permitted to be written with more 343 than four hexadecimal digits; fortunately the intended answer (which 344 is that it is not permitted) is known from the [IPV6-AA-2] and 345 [SMTP-2] ABNF grammars. This document, in section 3.2, presents this 346 syntax. 348 Internet-Draft Textual Representation of IP Addresses 2005-02-23 350 3 Syntax and Semantics 352 3.1 IPv4 Dotted Octet Format 354 A 32-bit IPv4 address is divided into four octets. Each octet is 355 represented numerically in decimal, using the minimum possible number 356 of digits (leading zeroes are not used, except in the case of 0 357 itself). The four encoded octets are given most-significant first, 358 separated by period characters. 360 IPv4address = d8 "." d8 "." d8 "." d8 362 d8 = DIGIT ; 0-9 363 / %x31-39 DIGIT ; 10-99 364 / "1" 2DIGIT ; 100-199 365 / "2" %x30-34 DIGIT ; 200-249 366 / "25" %x30-35 ; 250-255 368 3.2 IPv6 Presentation Format 370 A 128-bit IPv6 address is divided into eight 16-bit pieces. Each 371 piece is represented numerically in case-insensitive hexadecimal, 372 using one to four hexadecimal digits (leading zeroes are permitted). 373 The eight encoded pieces are given most-significant first, separated 374 by colon characters. Optionally, the least-significant two pieces 375 may instead be represented in IPv4 address textual format (the 376 production given above). Optionally, once in the 377 address, a sequence of one or more consecutive zero-valued 16-bit 378 pieces may be elided, omitting all their digits and leaving exactly 379 two consecutive colons in their place to mark the elision. 381 IPv6address = 6(h16 ":") ls32 382 / "::" 5(h16 ":") ls32 383 / [ h16 ] "::" 4(h16 ":") ls32 384 / [ *1(h16 ":") h16 ] "::" 3(h16 ":") ls32 385 / [ *2(h16 ":") h16 ] "::" 2(h16 ":") ls32 386 / [ *3(h16 ":") h16 ] "::" h16 ":" ls32 387 / [ *4(h16 ":") h16 ] "::" ls32 388 / [ *5(h16 ":") h16 ] "::" h16 389 / [ *6(h16 ":") h16 ] "::" 391 ls32 = h16 ":" h16 / IPv4address 393 h16 = 1*4HEXDIG 395 Internet-Draft Textual Representation of IP Addresses 2005-02-23 397 4 Recommendations 399 4.1 Be Stringent in What You Accept 401 Interpreting textual network addresses is a case where being liberal 402 in what one receives is not a virtue. In addition to the well-known 403 problem of interoperability testing against a liberal implementation 404 leading to insufficiently conservative sending behaviour, variations 405 on the address syntaxes tend to result in strings whose intended 406 meaning is unclear. Since a misinterpreted network address is quite 407 useless, whereas partial misinterpretation of most other things is 408 forgivable, it is particularly important to reject any address whose 409 interpretation is in question. 411 For backward compatibility, some applications will wish to continue 412 supporting some of the variations discussed in section 2. New 413 applications, however, SHOULD accept only the syntax given in section 414 3. Regardless of any alternative syntax that is supported, the 415 standard syntax given in section 3 MUST be interpreted exactly as 416 described there. 418 4.2 Generation of Representations of IPv6 Addresses 420 The standard format for IPv6 addresses has several options, granting 421 some discretion in the choice of representation. The choices 422 available are: 424 o which case to use for hexadecimal digits above 9; 426 o whether to use leading zeroes in the representation of 16-bit 427 pieces whose upper four bits are all zero; 429 o whether to represent the least-significant 32 bits as two pieces 430 in hexadecimal or in IPv4 format; 432 o whether to elide a sequence of zero-valued pieces, and which such 433 sequence to elide. 435 For specific applications there may be needs that dictate some of 436 these choices. For example, if laying out IPv6 addresses vertically 437 in a table, comparison is eased by using a fixed format by including 438 all leading zeroes and not eliding zero-valued pieces. 440 For general-purpose use, common practice is to use lowercase, use 441 nearly the shortest possible representation, and to represent 442 IPv4-compatible and IPv4-mapped addresses using the embedded IPv4 443 address representation. Experience has shown this format to be 444 nearly optimal for human comprehension of an address presented in 446 Internet-Draft Textual Representation of IP Addresses 2005-02-23 448 isolation, and so is RECOMMENDED when there are no strong 449 considerations promoting a different format. To generate this 450 format: 452 o Use the embedded IPv4 address format for addresses in 453 ::ffff:0:0/96 (IPv4-mapped addresses), and in ::/96 454 (IPv4-compatible addresses) except for :: (the unspecified 455 address) and ::1 (the loopback address) which are not 456 IPv4-compatible addresses. 458 o Omit all optional leading zeroes in the representations of 16-bit 459 pieces. 461 o If there are any sequences of consecutive zero-valued pieces, 462 elide the longest such sequence. In case of a tie, it seems to be 463 most common to pick the leftmost candidate. 465 4.3 Delimitation 467 Textually-represented IPv4 and IPv6 addresses have a sufficiently 468 narrow format that delimitation is rarely a problem. In human- 469 readable text they look sufficiently like words that additional 470 delimitation is usually not required; adjacent punctuation mostly 471 wouldn't be a valid character in the address, and even with 472 punctuation that can appear in the addresses (period and colon) 473 trailing punctuation creates no ambiguity due to the restricted use 474 of punctuation in the addresses. 476 A significant area where there is a delimitation issue is when an IP 477 address is presented together with an alphanumeric subaddress such as 478 a TCP port number. Some applications separate an IP address and port 479 number using a period, which, particularly in the case of IPv4, makes 480 the port number visually appear to be part of the address. This is 481 particularly tricky to read if a bare IP address without port number 482 might appear in the same context. Some applications use a colon to 483 separate IP address and port number, which is good for IPv4 but in 484 IPv6 it creates the same kind of problem that the period did in IPv4, 485 and can actually give an ambiguous result if a bare IPv6 address is 486 permitted in the same context. Applications SHOULD, therefore, pick 487 some other character to separate IP addresses and port numbers; BIND, 488 for example, uses "#". "/" is not recommended, due to a clash with 489 address prefix syntax. 491 In contexts where an IP address needs to be distinguished from 492 similar-looking data that can appear in the same place, there is 493 precedent for enclosing an IP address in brackets ("[]") as a 494 distinguisher. Precedents are email addresses [SMTP-2] and URIs 495 [URI]. 497 Internet-Draft Textual Representation of IP Addresses 2005-02-23 499 5 Security Considerations 501 In a network protocol, representation of network addresses in a 502 textual format raises no inherent issues over representation in a 503 binary format. Care should be taken to ensure that textual addresses 504 are parsed safely, so that bad syntax will not cause unwanted 505 behaviour. Where a textually-represented address is expected, it 506 should be decoded by a subroutine that will decode only the expected 507 address format and will not do anything (besides report an error) if 508 given some other input such as a host name. 510 In applications, the capability for the user to specify a network 511 node by address as well as by name is both powerful and potentially 512 dangerous. If an application does not intend to let the user specify 513 absolutely any network resource, then it should either have only a 514 more restrictive means of identifying network nodes or apply 515 reasonableness checks on the address that the user enters. 517 6 Acknowledgements 519 This document is a spin-off from the development of [URI], which was 520 the first RFC to give such a precise definition of IP address textual 521 syntax as is given here. The ABNF rules in section 3 were developed 522 collaboratively by Roy T. Fielding (author of [URI]) and the author 523 of this document. 525 Brian Carpenter confessed to being the perpetrator of the faulty 526 grammar that got into [IPV6-AA-2], and supplied a copy of the 527 historically-interesting email message in which he originally 528 proposed it. He also made some useful comments. 530 7 Normative References 532 [ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 533 Specifications: ABNF", RFC 2234, November 1997. 535 [REQ-TERM] S. Bradner, "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, March 1997. 538 8 Informative References 540 [BSI-IPV6-1] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic 541 Socket Interface Extensions for IPv6", RFC 2133, April 542 1997. 544 [HOST-TBL-2] E.J. Feinler, K. Harrenstien, Z. Su, V. White, "DoD 545 Internet host table specification", RFC 810, 546 Mar-01-1982. 548 Internet-Draft Textual Representation of IP Addresses 2005-02-23 550 [HREQ-APP] R.T. Braden, "Requirements for Internet hosts - 551 application and support", STD 3, RFC 1123, Oct-01-1989. 553 [IPV4] J. Postel, "Internet Protocol", RFC 791, Sep-01-1981. 555 [IPV4-NUMB] J. Postel, "Assigned numbers", RFC 790, Sep-01-1981. 557 [IPV6-AA-1] R. Hinden, S. Deering, Eds., "IP Version 6 Addressing 558 Architecture", RFC 1884, December 1995. 560 [IPV6-AA-2] R. Hinden, S. Deering, "IP Version 6 Addressing 561 Architecture", RFC 2373, July 1998. 563 [IPV6-AA-3] R. Hinden, S. Deering, "Internet Protocol Version 6 564 (IPv6) Addressing Architecture", RFC 3513, April 2003. 566 [MTP] S. Sluizer, J. Postel, "Mail Transfer Protocol", RFC 567 780, May-01-1981. 569 [NCP-TCP] J. Postel, "NCP/TCP transition plan", RFC 801, 570 Nov-01-1981. 572 [SMTP-1] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 573 821, Aug-01-1982. 575 [SMTP-2] J. Klensin, Ed., "Simple Mail Transfer Protocol", RFC 576 2821, April 2001. 578 [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform 579 Resource Identifier (URI): Generic Syntax", RFC 3986, 580 January 2005. 582 9 Author's Address 584 Andrew Main 585 Black Ops Ltd 586 Flat 2 587 84 Isledon Road 588 London 589 N7 7JS 590 United Kingdom 592 Phone: +44 7887 945779 593 EMail: zefram@fysh.org 595 10 Copyright and Disclaimer 597 Copyright (C) The Internet Society 2005. This document is subject 599 Internet-Draft Textual Representation of IP Addresses 2005-02-23 601 to the rights, licenses and restrictions contained in BCP 78, and 602 except as set forth therein, the authors retain all their rights. 604 This document and the information contained herein are provided on an 605 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 606 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 607 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 608 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 609 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 610 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.