idnits 2.17.1 draft-main-ipaddr-text-rep-00.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.) == 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). -- 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 (May 2003) is 7653 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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) == Outdated reference: A later version (-07) exists of draft-fielding-uri-rfc2396bis-01 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 9 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-00 Black Ops Ltd 4 Category: Informational May 2003 5 Expires: November 2003 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 1 Introduction 39 For as long as IP has existed, there has been a need to represent IP 40 addresses in textual contexts, but the nature of these requirements 41 has changed. IP addresses are textually represented much more widely 42 than appears to have been originally envisioned; in particular, such 43 representation has become a part of many network protocols. There is 44 an increasing need for interoperability in IP address textual 45 representations, for it is more commonly software than humans that 46 read and write addresses in this format. 48 Historically, the definitions of IP address textual representations 49 have been loose, underspecifying the syntax. They have also always 50 been a minor part of a standard whose main focus is some other 51 problem. This makes them difficult to locate and inconvenient to 52 cite. With IPv6 address textual representation incorporating the 53 IPv4 format by reference, the IPv6 format has not previously been 54 completely specified in a single RFC. 56 This document collects together the complete syntax for textual 57 representation of IPv4 and IPv6 addresses, clarifying the 58 underspecified parts. It is intended to be a complete and 59 unambiguous specification of these address formats, located together 60 in a single document for ease of reference. 62 Section 2 of this document discusses the history of the specification 63 and implementation of textual representation of IP addresses. 64 Section 3 gives the complete syntax. Section 4 gives some advice for 65 implementors. 67 1.1 Requirements Terminology 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 70 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 71 interpreted as described in [REQ-TERM]. 73 1.2 Augmented BNF Notation 75 Syntax specifications in this document use augmented BNF notation as 76 defined in [ABNF]. The `core rules' in appendix A of [ABNF] are used 77 as defined there. 79 2 History 81 2.1 IPv4 Dotted Octet Format 83 2.1.1 Early Practice 85 The original IPv4 "dotted octet" format was never fully defined in 86 any RFC, so it is necessary to look at usage, rather than merely find 87 an authoritative definition, to determine what the effective syntax 88 was. The first mention of dotted octets in the RFC series is in 89 [MTP], a predecessor of SMTP, which interestingly mentions two 90 address formats that evidently by then had some currency: 92 One form is a decimal integer prefixed by a pound sign, "#", 93 which indicates the number is the address of the host. Another 94 form is four small decimal integers separated by dots and 95 enclosed by brackets, e.g., "[123.255.37.321]", which indicates 96 a 32 bit ARPA Internet Address in four eight bit fields. 98 A few months later, [IPV4-NUMB] (the "Assigned Numbers" RFC published 99 at the same time as [IPV4]) gave, for the first time, a table of 100 assigned IP addresses. (Previous "Assigned Numbers" RFCs, predating 101 classful addressing, had merely had a table of "network numbers". 102 Although the new table retained the title "assigned network numbers", 103 it was actually expressed in terms of address blocks.) This table 104 used dotted decimal format, zero-filling each encoded octet to three 105 digits. The notes accompanying the table said: 107 One notation for internet host addresses commonly used divides 108 the 32-bit address into four 8-bit fields and specifies the 109 value of each field as a decimal number with the fields 110 separated by periods. For example, the internet address of ISIF 111 is 010.020.000.052. This notation will be used in the listing 112 of assigned network numbers. 114 Shortly thereafter, [NCP-TCP] gave a handful of live IP addresses 115 without comment on the format, for example, "ARPANET/SATNET gateway 116 at BBN (10.3.0.40)". 118 The next description of dotted octet notation is in [HOST-TBL-2], 119 defining the host table file format, which describes the notation as 120 "four decimal numbers separated by a period. Each decimal number 121 represents 1 octet.". One of its example host table entries was 122 "GATEWAY : 10.0.0.77, 18.8.0.4 : MIT-GW :: MOS : IP/GW :". 124 [HREQ-APP], a much later and more significant standard, describes IP 125 address text representation in recommending that applications allow 126 users to specify IP addresses directly as well as via DNS host names. 127 It merely describes the format as "dotted-decimal ("#.#.#.#") form". 128 It gives no example of an address in this format. 130 So far we have seen dotted octet format in five different types of 131 situation: a network protocol (machine-parsed email address), a table 132 of address blocks, English text (discussion the NCP to TCP/IP 133 switch), a machine-readable database (the host table), and human 134 interfaces to network applications. All are consistent about 135 dividing the address into octets and representing each octet purely 136 in decimal, but there are two variants of the format due to a more 137 subtle issue. The explicit descriptions of the format given so far 138 have been silent about the permissibility of leading zeroes in octet 139 representations; only one example, a human-oriented table of 140 addresses, used leading zeroes. 142 This variation in the format, presumably initially intended to be of 143 no consequence, lives on today. The direct descendent of 144 [IPV4-NUMB]'s "assigned network numbers" table is the IANA-maintained 145 "ipv4-address-space" table, which at the date of this document still 146 shows octet values in zero-filled three-digit decimal. In all non- 147 table contexts in which IPv4 addresses appear, including anything 148 intended to be machine-readable, almost universally leading zeroes 149 are suppressed. (Curiously, a different IANA-maintained table, the 150 "multicast-addresses" table of IPv4 multicast addresses, uses a 151 mixture of zero-filled and zero-suppressed octet values.) 153 Meanwhile, a very popular implementation of IP networking went off in 154 its own direction. 4.2BSD introduced a function inet_aton(), whose 155 job was to interpret character strings as IP addresses. It 156 interpreted both of the syntaxes mentioned in [MTP] (see above): a 157 single number giving the entire 32-bit address, and dot-separated 158 octet values. It also interpreted two intermediate syntaxes: octet- 159 dot-octet-dot-16bits, intended for class B addresses, and octet- 160 dot-24bits, intended for class A addresses. It also allowed some 161 flexibility in how the individual numeric parts were specified: it 162 allowed octal and hexadecimal in addition to decimal, distinguishing 163 these radices by using the C language syntax involving a prefix "0" 164 or "0x", and allowed the numbers to be arbitrarily long. 166 The 4.2BSD inet_aton() has been widely copied and imitated, and so is 167 a de facto standard for the textual representation of IPv4 addresses. 168 Nevertheless, these alternative syntaxes have now fallen out of use 169 (if they ever had significant use). The only practical use that they 170 now see is for deliberate obfuscation of addresses: giving an IPv4 171 address as a single 32-bit decimal number is favoured among people 172 wishing to conceal the true location that is encoded in a URL. All 173 the forms except for decimal octets are seen as non-standard (despite 174 being quite widely interoperable) and undesirable. 176 2.1.2 Revision From IPv6 Work 178 When the textual format for IPv6 addresses was developed, part of the 179 syntax involved representing an embedded IPv4 address by embedding an 180 IPv4 address textual representation in the IPv6 textual format. 181 [IPV6-AA-1], describing the IPv6 format for the first time, referred 182 simply to "decimal values of the four low-order 8-bit pieces of the 183 address (standard IPv4 representation)", giving "::13.1.68.3" as an 184 example of the format in practice. 186 [IPV6-AA-2] added an ABNF grammar, giving the first formal 187 specification of IPv4 textual address syntax in the RFC series. This 188 grammar showed dot-separated segments of one to three decimal digits 189 each. Unfortunately, there were some errors in related bits of the 190 grammar, and even with errors corrected the IPv6 address grammar was 191 loose, syntactically permitting addresses of the wrong length. This, 192 together with the similar looseness of the IPv4 address grammar 193 (which would match "123.456.789.999"), left open the question of 194 whether the grammar's acceptance of leading zeroes in IPv4 addresses 195 was an intentional feature, an error, or deliberate looseness. 196 [IPV6-AA-3], rather than correct the errors, withdrew the grammar. 198 The IPv6 effort also had an opportunity to advance the other branch 199 of development of IPv4 address representation. [BSI-IPV6-1] doesn't 200 attempt to modify inet_aton(), but defines a new function 201 inet_pton(), which, in handling IPv4 addresses, accepts dotted 202 decimal octets where each octet is encoded as "a one to three digit 203 decimal number between 0 and 255". The variant forms traditionally 204 accepted by inet_aton() are explicitly excluded. This definition is 205 still not explicit about the handling of leading zeroes, but it seems 206 to be intended to allow them, and it is being implemented 207 accordingly. 209 2.1.3 Finale 211 So far we've seen two parallel versions of IPv4 address textual 212 syntax, which we may label the IETF version and the BSD version. The 213 difference has persisted for so long because the two are just 214 sufficiently interoperable: they both handle in the same way the 215 overwhelmingly dominant syntax, dotted decimal octets with leading 216 zeroes suppressed. In all the other address forms they support they 217 disagree: the IETF syntax makes nothing of most of the variants that 218 BSD allows, and the two interpret differently a large group of 219 representations involving leading zeroes, which is why zeroes have 220 been mentioned so much in the foregoing history. 222 As of this writing, IPv4 addresses written with leading zeroes are de 223 facto ambiguous. Although all IETF output that expresses an opinion 224 has consistently indicated that these should be interpreted as 225 decimal, implementations that interpret them as octal are far too 226 widespread to ignore. For this reason it is not safe to generate 227 such addresses; the only way to generate an interoperable textual 228 IPv4 address is to suppress leading zeroes. Overwhelmingly popular 229 practice is, indeed, to avoid leading zeroes. 231 The most recent version of the URI syntax [URI] attempts to reconcile 232 these variants in order to give a precise definition for acceptable 233 IP address syntax in a URL. (Its predecessors had incorporated the 234 traditionally ambiguous syntax by reference.) [URI] is the first RFC 235 to require a completely rigorous definition of IP address syntax. 236 The approach taken was to standardise the safe common subset of the 237 IETF and BSD syntaxes, which achieves standardisation on IETF-like 238 syntax while also retaining backward compatibility with existing BSD- 239 based implementations. 241 This document, in section 3.1, presents the IPv4 address grammar from 243 [URI]. 245 2.2 IPv6 Presentation Format 247 The development of the IPv6 address presentation format has been 248 simpler than the IPv4 history. The divergence between specification 249 and implementation has been less significant, and there has been 250 conscious effort to fully specify the format rather than leave it as 251 oral tradition. 253 The first appearance of IPv6 address textual format in the RFC series 254 is the specification of the format in [IPV6-AA-1]. This 255 specification's relevant features are: a basic format of eight colon- 256 separated 16-bit pieces; each piece represented in hexadecimal, with 257 leading zeroes "not necessary" (examples are given both with and 258 without leading zeroes); optional use of "::", once in an address, to 259 indicate a run of zero-valued 16-bit pieces; optional use of 260 "standard IPv4 representation" for the least-significant 32 bits of 261 the address. 263 Note that this doesn't say what the maximum length of a piece 264 representation is, or whether "::" can be used in an address where 265 all 16-bit pieces are given explicitly (the "::" would represent a 266 sequence of zero consecutive zero-valued pieces). 268 [IPV6-AA-2] didn't substantially modify the description of the 269 syntax, but augmented it with an ABNF grammar. The grammar specified 270 that a 16-bit piece could be represented in one to four case- 271 insensitive hexadecimal digits, ruling out the use of more than four 272 digits per piece. There were some errors in the grammar, making it 273 inappropriate as a reference, and some looseness that makes it 274 impossible to clear up any other syntactic uncertainty from it. 276 [IPV6-AA-3] dropped the ABNF grammar, and amended the format 277 description to say that "::" represents "one or more" 16-bit pieces. 278 This amended description leaves unclear only the issue of whether a 279 16-bit piece is permitted to be written with more than four 280 hexadecimal digits; fortunately the intended answer (which is that it 281 is not permitted) is known from the [IPV6-AA-2] ABNF grammar. This 282 document, in section 3.2, presents this syntax. 284 3 Syntax and Semantics 286 3.1 IPv4 Dotted Octet Format 288 A 32-bit IPv4 address is divided into four octets. Each octet is 289 represented numerically in decimal, using the minimum possible number 290 of digits (leading zeroes are not used, except in the case of 0 291 itself). The four encoded octets are given most-significant first, 292 separated by period characters. 294 IPv4address = d8 "." d8 "." d8 "." d8 296 d8 = DIGIT ; 0-9 297 / %x31-39 DIGIT ; 10-99 298 / "1" 2DIGIT ; 100-199 299 / "2" %x30-34 DIGIT ; 200-249 300 / "25" %x30-35 ; 250-255 302 3.2 IPv6 Presentation Format 304 A 128-bit IPv6 address is divided into eight 16-bit pieces. Each 305 piece is represented numerically in case-insensitive hexadecimal, 306 using one to four hexadecimal digits (leading zeroes are permitted). 307 The eight encoded pieces are given most-significant first, separated 308 by colon characters. Optionally, the least-significant two pieces 309 may instead be represented in IPv4 address textual format (the 310 production given above). Optionally, once in the 311 address, a sequence of one or more consecutive zero-valued 16-bit 312 pieces may be elided, omitting all their digits and leaving exactly 313 two consecutive colons in their place to mark the elision. 315 IPv6address = 6(h16 ":") ls32 316 / "::" 5(h16 ":") ls32 317 / [ h16 ] "::" 4(h16 ":") ls32 318 / [ *1(h16 ":") h16 ] "::" 3(h16 ":") ls32 319 / [ *2(h16 ":") h16 ] "::" 2(h16 ":") ls32 320 / [ *3(h16 ":") h16 ] "::" h16 ":" ls32 321 / [ *4(h16 ":") h16 ] "::" ls32 322 / [ *5(h16 ":") h16 ] "::" h16 323 / [ *6(h16 ":") h16 ] "::" 325 ls32 = h16 ":" h16 / IPv4address 327 h16 = 1*4HEXDIG 329 4 Recommendations 331 4.1 Be Stringent in What You Accept 333 Interpreting textual network addresses is a case where being liberal 334 in what one receives is not a virtue. In addition to the well-known 335 problem of interoperability testing against a liberal implementation 336 leading to insufficiently conservative sending behaviour, variations 337 on the address syntaxes tend to result in strings whose intended 338 meaning is unclear. Since a misinterpreted network address is quite 339 useless, whereas in most other contexts partial misinterpretation is 340 forgivable, it is particularly important to reject any address whose 341 interpretation is in question. 343 For backward compatibility, some applications will wish to continue 344 supporting some of the variations discussed in section 2. New 345 applications, however, SHOULD accept only the syntax given in section 346 3. Regardless of any alternative syntax that is supported, the 347 standard syntax given in section 3 MUST be interpreted exactly as 348 described there. 350 4.2 Generation of Representations of IPv6 Addresses 352 The standard format for IPv6 addresses has several options, granting 353 some discretion in the choice of representation. The choices 354 available are: 356 o which case to use for hexadecimal digits above 9; 358 o whether to use leading zeroes in the representation of 16-bit 359 pieces whose upper four bits are all zero; 361 o whether to represent the least-significant 32 bits as two pieces 362 in hexadecimal or in IPv4 format; 364 o whether to elide a sequence of zero-valued pieces, and which such 365 sequence to elide. 367 For specific applications there may be needs that dictate some of 368 these choices. For example, if laying out IPv6 addresses vertically 369 in a table, comparison is eased by using a fixed format by including 370 all leading zeroes and not eliding zero-valued pieces. 372 For general-purpose use, common practice is to use lowercase, use 373 nearly the shortest possible representation, and to represent 374 IPv4-compatible and IPv4-mapped addresses using the embedded IPv4 375 address representation. This format has shown to be nearly optimal 376 for human comprehension of an address presented in isolation, and so 377 is RECOMMENDED when there are no strong considerations promoting a 378 different format. To generate this format: 380 o Use the embedded IPv4 address format for addresses in 381 ::ffff:0:0/96 (IPv4-mapped addresses), and in ::/96 382 (IPv4-compatible addresses) except for :: (the unspecified 383 address) and ::1 (the loopback address) which are not 384 IPv4-compatible addresses. 386 o Omit all optional leading zeroes in the representations of 16-bit 387 pieces. 389 o If there are any sequences of consecutive zero-valued pieces, 390 elide the longest such sequence. In case of a tie, it seems to be 391 most common to pick the leftmost candidate. 393 4.3 Delimitation 395 Textually-represented IPv4 and IPv6 addresses have a sufficiently 396 narrow format that delimitation is rarely a problem. In human- 397 readable text they look sufficiently like words that additional 398 delimitation is usually not required; adjacent punctuation mostly 399 wouldn't be a valid character in the address, and even with 400 punctuation that can appear in the addresses (period and colon) 401 trailing punctuation creates no ambiguity due to the restricted use 402 of punctuation in the addresses. 404 A significant area where there is a delimitation issue is when an IP 405 address is presented together with an alphanumeric subaddress such as 406 a TCP port number. Some applications separate an IP address and port 407 number using a period, which, particularly in the case of IPv4, makes 408 the port number visually appear to be part of the address. This is 409 particularly tricky to read if a bare IP address without port number 410 might appear in the same context. Some applications use a colon to 411 separate IP address and port number, which is good for IPv4 but in 412 IPv6 it creates the same kind of problem that the period did in IPv4, 413 and can actually give an ambiguous result if a bare IPv6 address is 414 permitted in the same context. Applications SHOULD, therefore, pick 415 some other character to separate IP addresses and port numbers; BIND, 416 for example, uses "#". "/" is not recommended, due to a clash with 417 address prefix syntax. 419 In contexts where an IP address needs to be distinguished from 420 similar-looking data that can appear in the same place, there is 421 precedent (from email addresses and URLs) for enclosing an IP address 422 in brackets ("[]") as a distinguisher. 424 5 Security Considerations 426 In a network protocol, representation of network addresses in a 427 textual format raises no inherent issues over representation in a 428 binary format. Care should be taken to ensure that textual addresses 429 are parsed safely, so that bad syntax will not cause unwanted 430 behaviour. Where a textually-represented address is expected, it 431 should be decoded by a subroutine that will decode only the expected 432 address format and will not do anything (besides report an error) if 433 given some other input such as a host name. 435 In applications, the capability for the user to specify a network 436 node by address as well as by name is both powerful and potentially 437 dangerous. If an application does not intend to let the user specify 438 absolutely any network resource, then it should either have only a 439 more restrictive means of identifying network nodes or apply 440 reasonableness checks on the address that the user enters. 442 6 Acknowledgements 444 This document is a spin-off from the development of [URI], which was 445 the first RFC to give such a precise definition of IP address textual 446 syntax as is given here. The ABNF rules in section 3 were developed 447 collaboratively by Roy T. Fielding (author of [URI]) and the author 448 of this document. 450 7 Normative References 452 [ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 453 Specifications: ABNF", RFC 2234, November 1997. 455 [REQ-TERM] S. Bradner, "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, March 1997. 458 8 Informative References 460 [BSI-IPV6-1] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic 461 Socket Interface Extensions for IPv6", RFC 2133, April 462 1997. 464 [HOST-TBL-2] E.J. Feinler, K. Harrenstien, Z. Su, V. White, "DoD 465 Internet host table specification", RFC 810, 466 Mar-01-1982. 468 [HREQ-APP] R.T. Braden, "Requirements for Internet hosts - 469 application and support", STD 3, RFC 1123, Oct-01-1989. 471 [IPV4] J. Postel, "Internet Protocol", RFC 791, Sep-01-1981. 473 [IPV4-NUMB] J. Postel, "Assigned numbers", RFC 790, Sep-01-1981. 475 [IPV6-AA-1] R. Hinden, S. Deering, Eds., "IP Version 6 Addressing 476 Architecture", RFC 1884, December 1995. 478 [IPV6-AA-2] R. Hinden, S. Deering, "IP Version 6 Addressing 479 Architecture", RFC 2373, July 1998. 481 [IPV6-AA-3] R. Hinden, S. Deering, "Internet Protocol Version 6 482 (IPv6) Addressing Architecture", RFC 3513, April 2003. 484 [MTP] S. Sluizer, J. Postel, "Mail Transfer Protocol", RFC 485 780, May-01-1981. 487 [NCP-TCP] J. Postel, "NCP/TCP transition plan", RFC 801, 488 Nov-01-1981. 490 [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform 491 Resource Identifier (URI): Generic Syntax", draft- 492 fielding-uri-rfc2396bis-01, March 3, 2003. 494 9 Author's Address 496 Andrew Main 497 Black Ops Ltd 498 12 Montagu Mews South 499 London 500 W1H 7ER 501 United Kingdom 503 Phone: +44 7887 945779 504 EMail: zefram@fysh.org