idnits 2.17.1 draft-main-ipaddr-text-rep-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 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 (2003-10-22) is 7491 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) == Outdated reference: A later version (-07) exists of draft-fielding-uri-rfc2396bis-01 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 11 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-01 Black Ops Ltd 4 Category: Standards-Track 2003-10-22 5 Expires: 2004-04-22 7 Textual Representation of IPv4 and IPv6 Addresses 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 Historically, the conventional textual representations of IPv4 and 33 IPv6 addresses have been poorly specified. This document gives 34 precise definitions of these conventions, together with advice for 35 implementors. 37 Change Log 39 Changes from -00 to -01: 41 o Discussion of the ABNF grammar for IPv4 addresses given in [MTP] 42 and [SMTP-1]. 44 o Explanation of the faulty ABNF grammar in [IPV6-AA-2]. 46 o Mention of another faulty grammar for IPv6 addresses in [SMTP-2]. 48 o Specific references for the enclosing of IP addresses in brackets. 50 Internet-Draft Textual Representation of IP Addresses 2003-10-22 52 o Changed intended category from Informational to Standards-Track. 54 o A couple of minor wording changes. 56 o Updated author's address. 58 1 Introduction 60 For as long as IP has existed, there has been a need to represent IP 61 addresses in textual contexts, but the nature of these requirements 62 has changed. IP addresses are textually represented much more widely 63 than appears to have been originally envisioned; in particular, such 64 representation has become a part of many network protocols. There is 65 an increasing need for interoperability in IP address textual 66 representations, for it is more commonly software than humans that 67 read and write addresses in this format. 69 Historically, the definitions of IP address textual representations 70 have been loose, underspecifying the syntax. They have also always 71 been a minor part of a standard whose main focus is some other 72 problem. This makes them difficult to locate and inconvenient to 73 cite. With IPv6 address textual representation incorporating the 74 IPv4 format by reference, the IPv6 format has not previously been 75 completely specified in a single RFC. 77 This document collects together the complete syntax for textual 78 representation of IPv4 and IPv6 addresses, clarifying the 79 underspecified parts. It is intended to be a complete and 80 unambiguous specification of these address formats, located together 81 in a single document for ease of reference. 83 Section 2 of this document discusses the history of the specification 84 and implementation of textual representation of IP addresses. 85 Section 3 gives the complete syntax. Section 4 gives some advice for 86 implementors. 88 1.1 Requirements Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 91 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 92 interpreted as described in [REQ-TERM]. 94 1.2 Augmented BNF Notation 96 Syntax specifications in this document use augmented BNF notation as 97 defined in [ABNF]. The `core rules' in appendix A of [ABNF] are used 98 as defined there. 100 Internet-Draft Textual Representation of IP Addresses 2003-10-22 102 2 History 104 2.1 IPv4 Dotted Octet Format 106 2.1.1 Early Practice 108 The original IPv4 "dotted octet" format was never fully defined in 109 any RFC, so it is necessary to look at usage, rather than merely find 110 an authoritative definition, to determine what the effective syntax 111 was. The first mention of dotted octets in the RFC series is in 112 [MTP], a predecessor of SMTP, which interestingly mentions two 113 address formats that evidently by then had some currency: 115 One form is a decimal integer prefixed by a pound sign, "#", 116 which indicates the number is the address of the host. Another 117 form is four small decimal integers separated by dots and 118 enclosed by brackets, e.g., "[123.255.37.321]", which indicates 119 a 32 bit ARPA Internet Address in four eight bit fields. 121 [MTP] also gives a partial ABNF specification for these address 122 formats. The grammar requires four dot-separated parts, each of 123 which consists of "three digits representing an integer value in the 124 range 0 through 255". Presumably the exclusion of one- and two-digit 125 parts is a mistake, since it clashes with the example quoted above. 126 [MTP]'s descendent [SMTP-1] gives the same partial ABNF but requires 127 each part to consist of "one, two, or three digits representing a 128 decimal integer value in the range 0 through 255". 130 A few months later, [IPV4-NUMB] (the "Assigned Numbers" RFC published 131 at the same time as [IPV4]) gave, for the first time, a table of 132 assigned IP addresses. (Previous "Assigned Numbers" RFCs, predating 133 classful addressing, had merely had a table of "network numbers". 134 Although the new table retained the title "assigned network numbers", 135 it was actually expressed in terms of address blocks.) This table 136 used dotted decimal format, zero-filling each encoded octet to three 137 digits. The notes accompanying the table said: 139 One notation for internet host addresses commonly used divides 140 the 32-bit address into four 8-bit fields and specifies the 141 value of each field as a decimal number with the fields 142 separated by periods. For example, the internet address of ISIF 143 is 010.020.000.052. This notation will be used in the listing 144 of assigned network numbers. 146 Shortly thereafter, [NCP-TCP] gave a handful of live IP addresses 147 without comment on the format, for example, "ARPANET/SATNET gateway 148 at BBN (10.3.0.40)". 150 Internet-Draft Textual Representation of IP Addresses 2003-10-22 152 The next description of dotted octet notation is in [HOST-TBL-2], 153 defining the host table file format, which describes the notation as 154 "four decimal numbers separated by a period. Each decimal number 155 represents 1 octet.". One of its example host table entries was 156 "GATEWAY : 10.0.0.77, 18.8.0.4 : MIT-GW :: MOS : IP/GW :". 158 It is at this point in the history that [SMTP-1] reiterated the 159 formal grammar given in [MTP], with the emendation to unambiguously 160 allow decimal numbers of fewer than three digits. 162 [HREQ-APP], a much later and more significant standard, describes IP 163 address text representation, in the course of recommending that 164 applications allow users to specify IP addresses directly as well as 165 via DNS host names. It merely describes the format as "dotted- 166 decimal ("#.#.#.#") form". It gives no example of an address in this 167 format. 169 So far we have seen dotted octet format in five different types of 170 situation: a network protocol (machine-parsed email address), a table 171 of address blocks, English text (discussion the NCP to TCP/IP 172 switch), a machine-readable database (the host table), and human 173 interfaces to network applications. All are consistent about 174 dividing the address into octets and representing each octet purely 175 in decimal, but there are two variants of the format due to a more 176 subtle issue. The explicit descriptions of the format given so far 177 have been silent about the permissibility of leading zeroes in octet 178 representations; only one example, a human-oriented table of 179 addresses, used leading zeroes. 181 This variation in the format, presumably initially intended to be of 182 no consequence, lives on today. The direct descendent of 183 [IPV4-NUMB]'s "assigned network numbers" table is the IANA-maintained 184 "ipv4-address-space" table, which at the date of this document still 185 shows octet values in zero-filled three-digit decimal. In all non- 186 table contexts in which IPv4 addresses appear, including anything 187 intended to be machine-readable, almost universally leading zeroes 188 are suppressed. (Curiously, a different IANA-maintained table, the 189 "multicast-addresses" table of IPv4 multicast addresses, uses a 190 mixture of zero-filled and zero-suppressed octet values.) 192 Meanwhile, a very popular implementation of IP networking went off in 193 its own direction. 4.2BSD introduced a function inet_aton(), whose 194 job was to interpret character strings as IP addresses. It 195 interpreted both of the syntaxes mentioned in [MTP] (see above): a 196 single number giving the entire 32-bit address, and dot-separated 197 octet values. It also interpreted two intermediate syntaxes: octet- 198 dot-octet-dot-16bits, intended for class B addresses, and octet- 199 dot-24bits, intended for class A addresses. It also allowed some 201 Internet-Draft Textual Representation of IP Addresses 2003-10-22 203 flexibility in how the individual numeric parts were specified: it 204 allowed octal and hexadecimal in addition to decimal, distinguishing 205 these radices by using the C language syntax involving a prefix "0" 206 or "0x", and allowed the numbers to be arbitrarily long. 208 The 4.2BSD inet_aton() has been widely copied and imitated, and so is 209 a de facto standard for the textual representation of IPv4 addresses. 210 Nevertheless, these alternative syntaxes have now fallen out of use 211 (if they ever had significant use). The only practical use that they 212 now see is for deliberate obfuscation of addresses: giving an IPv4 213 address as a single 32-bit decimal number is favoured among people 214 wishing to conceal the true location that is encoded in a URL. All 215 the forms except for decimal octets are seen as non-standard (despite 216 being quite widely interoperable) and undesirable. 218 2.1.2 Revision From IPv6 Work 220 When the textual format for IPv6 addresses was developed, part of the 221 syntax involved representing an embedded IPv4 address by embedding an 222 IPv4 address textual representation in the IPv6 textual format. 223 [IPV6-AA-1], describing the IPv6 format for the first time, referred 224 simply to "decimal values of the four low-order 8-bit pieces of the 225 address (standard IPv4 representation)", giving "::13.1.68.3" as an 226 example of the format in practice. 228 [IPV6-AA-2] added an ABNF grammar, giving the first formal 229 specification of IPv4 textual address syntax in the RFC series. This 230 grammar showed dot-separated segments of one to three decimal digits 231 each. Unfortunately, there were some errors in related bits of the 232 grammar, and even with errors corrected the IPv6 address grammar was 233 loose, syntactically permitting addresses of the wrong length. This, 234 together with the similar looseness of the IPv4 address grammar 235 (which would match "123.456.789.999"), left open the question of 236 whether the grammar's acceptance of leading zeroes in IPv4 addresses 237 was an intentional feature, an error, or deliberate looseness. 238 [IPV6-AA-3], rather than correct the errors, withdrew the grammar. 240 The IPv6 effort also had an opportunity to advance the other branch 241 of development of IPv4 address representation. [BSI-IPV6-1] doesn't 242 attempt to modify inet_aton(), but defines a new function 243 inet_pton(), which, in handling IPv4 addresses, accepts dotted 244 decimal octets where each octet is encoded as "a one to three digit 245 decimal number between 0 and 255". The variant forms traditionally 246 accepted by inet_aton() are explicitly excluded. This definition is 247 still not explicit about the handling of leading zeroes, but it seems 248 to be intended to allow them, and it is being implemented 249 accordingly. 251 Internet-Draft Textual Representation of IP Addresses 2003-10-22 253 2.1.3 Finale 255 So far we've seen two parallel versions of IPv4 address textual 256 syntax, which we may label the IETF version and the BSD version. The 257 difference has persisted for so long because the two are just 258 sufficiently interoperable: they both handle in the same way the 259 overwhelmingly dominant syntax, dotted decimal octets with leading 260 zeroes suppressed. In all the other address forms they support they 261 disagree: the IETF syntax makes nothing of most of the variants that 262 BSD allows, and the two interpret differently a large group of 263 representations involving leading zeroes, which is why zeroes have 264 been mentioned so much in the foregoing history. 266 As of this writing, IPv4 addresses written with leading zeroes are de 267 facto ambiguous. Although all IETF output that expresses an opinion 268 has consistently indicated that these should be interpreted as 269 decimal, implementations that interpret them as octal are far too 270 widespread to ignore. For this reason it is not safe to generate 271 such addresses; the only way to generate an interoperable textual 272 IPv4 address is to suppress leading zeroes. Overwhelmingly popular 273 practice is, indeed, to avoid leading zeroes. 275 The most recent version of the URI syntax [URI] attempts to reconcile 276 these variants in order to give a precise definition for acceptable 277 IP address syntax in a URL. (Its predecessors had incorporated the 278 traditionally ambiguous syntax by reference.) [URI] is the first RFC 279 to require a completely rigorous definition of IP address syntax. 280 The approach taken was to standardise the safe common subset of the 281 IETF and BSD syntaxes, which achieves standardisation on IETF-like 282 syntax while also retaining backward compatibility with existing BSD- 283 based implementations. 285 This document, in section 3.1, presents the IPv4 address grammar from 286 [URI]. 288 2.2 IPv6 Presentation Format 290 The development of the IPv6 address presentation format has been 291 simpler than the IPv4 history. The divergence between specification 292 and implementation has been less significant, and there has been 293 conscious effort to fully specify the format rather than leave it as 294 oral tradition. 296 The first appearance of IPv6 address textual format in the RFC series 297 is the specification of the format in [IPV6-AA-1]. This 298 specification's relevant features are: a basic format of eight colon- 299 separated 16-bit pieces; each piece represented in hexadecimal, with 300 leading zeroes "not necessary" (examples are given both with and 302 Internet-Draft Textual Representation of IP Addresses 2003-10-22 304 without leading zeroes); optional use of "::", once in an address, to 305 indicate a run of zero-valued 16-bit pieces; optional use of 306 "standard IPv4 representation" for the least-significant 32 bits of 307 the address. 309 Note that this doesn't say what the maximum length of a piece 310 representation is, or whether "::" can be used in an address where 311 all 16-bit pieces are given explicitly (the "::" would represent a 312 sequence of zero consecutive zero-valued pieces). 314 [IPV6-AA-2] didn't substantially modify the description of the 315 syntax, but augmented it with an ABNF grammar. The grammar specified 316 that a 16-bit piece could be represented in one to four case- 317 insensitive hexadecimal digits, ruling out the use of more than four 318 digits per piece. There were some errors in the grammar, making it 319 inappropriate as a reference, and some looseness that makes it 320 impossible to clear up any other syntactic uncertainty from it. 321 These errors resulted from a "rough cut" grammar getting into the RFC 322 largely unchanged, clearly without serious analysis. 324 [SMTP-2] gives an ABNF grammar for IPv6 address literals in email 325 addresses. Unfortunately this grammar, also, is faulty and loose, 326 but it concurs with the [IPV6-AA-2] grammar in requiring each piece 327 to consist of one to four hexadecimal digits. 329 [IPV6-AA-3] dropped the faulty grammar from [IPV6-AA-2], and amended 330 the format description to say that "::" represents "one or more" 331 16-bit pieces. This amended description leaves unclear only the 332 issue of whether a 16-bit piece is permitted to be written with more 333 than four hexadecimal digits; fortunately the intended answer (which 334 is that it is not permitted) is known from the [IPV6-AA-2] and 335 [SMTP-2] ABNF grammars. This document, in section 3.2, presents this 336 syntax. 338 Internet-Draft Textual Representation of IP Addresses 2003-10-22 340 3 Syntax and Semantics 342 3.1 IPv4 Dotted Octet Format 344 A 32-bit IPv4 address is divided into four octets. Each octet is 345 represented numerically in decimal, using the minimum possible number 346 of digits (leading zeroes are not used, except in the case of 0 347 itself). The four encoded octets are given most-significant first, 348 separated by period characters. 350 IPv4address = d8 "." d8 "." d8 "." d8 352 d8 = DIGIT ; 0-9 353 / %x31-39 DIGIT ; 10-99 354 / "1" 2DIGIT ; 100-199 355 / "2" %x30-34 DIGIT ; 200-249 356 / "25" %x30-35 ; 250-255 358 3.2 IPv6 Presentation Format 360 A 128-bit IPv6 address is divided into eight 16-bit pieces. Each 361 piece is represented numerically in case-insensitive hexadecimal, 362 using one to four hexadecimal digits (leading zeroes are permitted). 363 The eight encoded pieces are given most-significant first, separated 364 by colon characters. Optionally, the least-significant two pieces 365 may instead be represented in IPv4 address textual format (the 366 production given above). Optionally, once in the 367 address, a sequence of one or more consecutive zero-valued 16-bit 368 pieces may be elided, omitting all their digits and leaving exactly 369 two consecutive colons in their place to mark the elision. 371 IPv6address = 6(h16 ":") ls32 372 / "::" 5(h16 ":") ls32 373 / [ h16 ] "::" 4(h16 ":") ls32 374 / [ *1(h16 ":") h16 ] "::" 3(h16 ":") ls32 375 / [ *2(h16 ":") h16 ] "::" 2(h16 ":") ls32 376 / [ *3(h16 ":") h16 ] "::" h16 ":" ls32 377 / [ *4(h16 ":") h16 ] "::" ls32 378 / [ *5(h16 ":") h16 ] "::" h16 379 / [ *6(h16 ":") h16 ] "::" 381 ls32 = h16 ":" h16 / IPv4address 383 h16 = 1*4HEXDIG 385 Internet-Draft Textual Representation of IP Addresses 2003-10-22 387 4 Recommendations 389 4.1 Be Stringent in What You Accept 391 Interpreting textual network addresses is a case where being liberal 392 in what one receives is not a virtue. In addition to the well-known 393 problem of interoperability testing against a liberal implementation 394 leading to insufficiently conservative sending behaviour, variations 395 on the address syntaxes tend to result in strings whose intended 396 meaning is unclear. Since a misinterpreted network address is quite 397 useless, whereas partial misinterpretation of most other things is 398 forgivable, it is particularly important to reject any address whose 399 interpretation is in question. 401 For backward compatibility, some applications will wish to continue 402 supporting some of the variations discussed in section 2. New 403 applications, however, SHOULD accept only the syntax given in section 404 3. Regardless of any alternative syntax that is supported, the 405 standard syntax given in section 3 MUST be interpreted exactly as 406 described there. 408 4.2 Generation of Representations of IPv6 Addresses 410 The standard format for IPv6 addresses has several options, granting 411 some discretion in the choice of representation. The choices 412 available are: 414 o which case to use for hexadecimal digits above 9; 416 o whether to use leading zeroes in the representation of 16-bit 417 pieces whose upper four bits are all zero; 419 o whether to represent the least-significant 32 bits as two pieces 420 in hexadecimal or in IPv4 format; 422 o whether to elide a sequence of zero-valued pieces, and which such 423 sequence to elide. 425 For specific applications there may be needs that dictate some of 426 these choices. For example, if laying out IPv6 addresses vertically 427 in a table, comparison is eased by using a fixed format by including 428 all leading zeroes and not eliding zero-valued pieces. 430 For general-purpose use, common practice is to use lowercase, use 431 nearly the shortest possible representation, and to represent 432 IPv4-compatible and IPv4-mapped addresses using the embedded IPv4 433 address representation. Experience has shown this format to be 434 nearly optimal for human comprehension of an address presented in 436 Internet-Draft Textual Representation of IP Addresses 2003-10-22 438 isolation, and so is RECOMMENDED when there are no strong 439 considerations promoting a different format. To generate this 440 format: 442 o Use the embedded IPv4 address format for addresses in 443 ::ffff:0:0/96 (IPv4-mapped addresses), and in ::/96 444 (IPv4-compatible addresses) except for :: (the unspecified 445 address) and ::1 (the loopback address) which are not 446 IPv4-compatible addresses. 448 o Omit all optional leading zeroes in the representations of 16-bit 449 pieces. 451 o If there are any sequences of consecutive zero-valued pieces, 452 elide the longest such sequence. In case of a tie, it seems to be 453 most common to pick the leftmost candidate. 455 4.3 Delimitation 457 Textually-represented IPv4 and IPv6 addresses have a sufficiently 458 narrow format that delimitation is rarely a problem. In human- 459 readable text they look sufficiently like words that additional 460 delimitation is usually not required; adjacent punctuation mostly 461 wouldn't be a valid character in the address, and even with 462 punctuation that can appear in the addresses (period and colon) 463 trailing punctuation creates no ambiguity due to the restricted use 464 of punctuation in the addresses. 466 A significant area where there is a delimitation issue is when an IP 467 address is presented together with an alphanumeric subaddress such as 468 a TCP port number. Some applications separate an IP address and port 469 number using a period, which, particularly in the case of IPv4, makes 470 the port number visually appear to be part of the address. This is 471 particularly tricky to read if a bare IP address without port number 472 might appear in the same context. Some applications use a colon to 473 separate IP address and port number, which is good for IPv4 but in 474 IPv6 it creates the same kind of problem that the period did in IPv4, 475 and can actually give an ambiguous result if a bare IPv6 address is 476 permitted in the same context. Applications SHOULD, therefore, pick 477 some other character to separate IP addresses and port numbers; BIND, 478 for example, uses "#". "/" is not recommended, due to a clash with 479 address prefix syntax. 481 In contexts where an IP address needs to be distinguished from 482 similar-looking data that can appear in the same place, there is 483 precedent for enclosing an IP address in brackets ("[]") as a 484 distinguisher. Precedents are email addresses [SMTP-2] and URIs 485 [URI]. 487 Internet-Draft Textual Representation of IP Addresses 2003-10-22 489 5 Security Considerations 491 In a network protocol, representation of network addresses in a 492 textual format raises no inherent issues over representation in a 493 binary format. Care should be taken to ensure that textual addresses 494 are parsed safely, so that bad syntax will not cause unwanted 495 behaviour. Where a textually-represented address is expected, it 496 should be decoded by a subroutine that will decode only the expected 497 address format and will not do anything (besides report an error) if 498 given some other input such as a host name. 500 In applications, the capability for the user to specify a network 501 node by address as well as by name is both powerful and potentially 502 dangerous. If an application does not intend to let the user specify 503 absolutely any network resource, then it should either have only a 504 more restrictive means of identifying network nodes or apply 505 reasonableness checks on the address that the user enters. 507 6 Acknowledgements 509 This document is a spin-off from the development of [URI], which was 510 the first RFC to give such a precise definition of IP address textual 511 syntax as is given here. The ABNF rules in section 3 were developed 512 collaboratively by Roy T. Fielding (author of [URI]) and the author 513 of this document. 515 Brian Carpenter confessed to being the perpetrator of the faulty 516 grammar that got into [IPV6-AA-2], and supplied a copy of the 517 historically-interesting email message in which he originally 518 proposed it. He also made some useful comments. 520 7 Normative References 522 [ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 523 Specifications: ABNF", RFC 2234, November 1997. 525 [REQ-TERM] S. Bradner, "Key words for use in RFCs to Indicate 526 Requirement Levels", BCP 14, RFC 2119, March 1997. 528 8 Informative References 530 [BSI-IPV6-1] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic 531 Socket Interface Extensions for IPv6", RFC 2133, April 532 1997. 534 [HOST-TBL-2] E.J. Feinler, K. Harrenstien, Z. Su, V. White, "DoD 535 Internet host table specification", RFC 810, 536 Mar-01-1982. 538 Internet-Draft Textual Representation of IP Addresses 2003-10-22 540 [HREQ-APP] R.T. Braden, "Requirements for Internet hosts - 541 application and support", STD 3, RFC 1123, Oct-01-1989. 543 [IPV4] J. Postel, "Internet Protocol", RFC 791, Sep-01-1981. 545 [IPV4-NUMB] J. Postel, "Assigned numbers", RFC 790, Sep-01-1981. 547 [IPV6-AA-1] R. Hinden, S. Deering, Eds., "IP Version 6 Addressing 548 Architecture", RFC 1884, December 1995. 550 [IPV6-AA-2] R. Hinden, S. Deering, "IP Version 6 Addressing 551 Architecture", RFC 2373, July 1998. 553 [IPV6-AA-3] R. Hinden, S. Deering, "Internet Protocol Version 6 554 (IPv6) Addressing Architecture", RFC 3513, April 2003. 556 [MTP] S. Sluizer, J. Postel, "Mail Transfer Protocol", RFC 557 780, May-01-1981. 559 [NCP-TCP] J. Postel, "NCP/TCP transition plan", RFC 801, 560 Nov-01-1981. 562 [SMTP-1] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 563 821, Aug-01-1982. 565 [SMTP-2] J. Klensin, Ed., "Simple Mail Transfer Protocol", RFC 566 2821, April 2001. 568 [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform 569 Resource Identifier (URI): Generic Syntax", draft- 570 fielding-uri-rfc2396bis-01, March 3, 2003. 572 9 Author's Address 574 Andrew Main 575 Black Ops Ltd 576 Flat 2 577 84 Isledon Road 578 London 579 N7 7JS 580 United Kingdom 582 Phone: +44 7887 945779 583 EMail: zefram@fysh.org