idnits 2.17.1 draft-ietf-6man-multi-homed-host-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) -- 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 (October 15, 2015) is 3114 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) == Missing Reference: 'MUST' is mentioned on line 174, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance F. Baker 3 Internet-Draft Cisco Systems 4 Updates: 4861 (if approved) B. Carpenter 5 Intended status: Standards Track Univ. of Auckland 6 Expires: April 17, 2016 October 15, 2015 8 Routing packets from hosts in a multi-prefix network 9 draft-ietf-6man-multi-homed-host-01 11 Abstract 13 This document describes expected IPv6 host behavior in a network that 14 has more than one prefix, each allocated by an upstream network that 15 implements BCP 38 ingress filtering, when the host has multiple 16 routers to choose from. It also applies to other scenarios such as 17 the usage of stateful firewalls that effectively act as address-based 18 filters. 20 This host behavior may interact with source address selection in a 21 given implementation, but logically follows it. Given that the 22 network or host is, or appears to be, multihomed with multiple 23 provider-allocated addresses, that the host has elected to use a 24 source address in a given prefix, and that some but not all 25 neighboring routers are advertising that prefix in their Router 26 Advertisement Prefix Information Options, this document specifies to 27 which router a host should present its transmission. It updates RFC 28 4861. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 17, 2016. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction and Applicability . . . . . . . . . . . . . . . 2 65 1.1. Host Model . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 67 2. Sending context expected by the host . . . . . . . . . . . . 5 68 2.1. Expectations the host has of the network . . . . . . . . 5 69 2.2. Expectations of multihomed networks . . . . . . . . . . . 7 70 3. Reasonable expectations of the host . . . . . . . . . . . . . 7 71 3.1. Interpreting Router Advertisements . . . . . . . . . . . 7 72 3.2. Default Router Selection . . . . . . . . . . . . . . . . 8 73 3.3. Source Address Selection . . . . . . . . . . . . . . . . 8 74 3.4. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 9 75 3.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4. Residual issues . . . . . . . . . . . . . . . . . . . . . . . 9 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 8.2. Informative References . . . . . . . . . . . . . . . . . 11 83 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction and Applicability 88 This document describes the expected behavior of an IPv6 [RFC2460] 89 host in a network that has more than one prefix, each allocated by an 90 upstream network that implements BCP 38 [RFC2827] ingress filtering, 91 and in which the host is presented with a choice of routers. It 92 expects that the network will implement some form of egress routing, 93 so that packets sent to a host outside the local network from a given 94 ISP's prefix will go to that ISP. If the packet is sent to the wrong 95 egress, it is liable to be discarded by the BCP 38 filter. However, 96 the mechanics of egress routing once the packet leaves the host are 97 out of scope. The question here is how the host interacts with that 98 network. 100 BCP 38 filtering by ISPs is not the only scenario where such behavior 101 is valuable. Implementations that combine existing recommendations, 102 such as [RFC6092] [RFC7084] can also result in such filtering. 103 Another case is when the connections to the upstream networks include 104 stateful firewalls, such that return packets in a stream will be 105 discarded if they do not return via the firewall that created state 106 for the outgoing packets. A similar cause of such discards is 107 unicast reverse path forwarding (uRPF) [RFC3704]. 109 In this document, the term "filter" is used for simplicity to cover 110 all such cases. In any case, one cannot assume the host to be aware 111 whether an ingress filter, a stateful firewall, or any other type of 112 filter is in place. Therefore, the only consistent solution is to 113 implement the features defined in this document. 115 Note that, apart from ensuring that a message with a given source 116 address is given to a first-hop router that appears to know about the 117 prefix in question, this specification is consistent with [RFC4861]. 118 Nevertheless, implementers of Sections 5.2, 6.2.3, 6.3.4 and 8 of RFC 119 4861 will need to extend their implementations accordingly. This 120 specification is fully consistent with [RFC6724] and implementers 121 will need to add support for its Rule 5.5. Hosts that do not support 122 these features may fail to communicate in the presence of filters as 123 described above. 125 1.1. Host Model 127 It could be argued that the proposal of this document, which is to 128 send messages using a source address in a given prefix to the router 129 that advertised the prefix in its RA, is a form of [RFC1122]'s Strong 130 ES (e.g. Host) Model, discussed in section 3.3.4.2 of that document. 131 In short, [RFC1122] identifies two basic models, in which the "strong 132 host" model models the host as a set of hosts in one chassis, each of 133 which uses a single address on a single interface, and always both 134 sends and receives on that interface, and the "weak host" model 135 treats the host as one system with zero or more addresses on every 136 interface, and capable of using any interface for any communication. 137 As noted there, neither model is completely satisfactory. For 138 example, a host with an addressless interface and a default route 139 pointing to the interface will necessarily send packets using any 140 address using that interface, and therefore be a de facto weak host. 141 However, if the router upstream from the host implements BCP 38 142 Ingress Filtering [RFC2827], such as by implementing uRPF on each 143 interface, the router is configured to only permit communication by 144 strong hosts. 146 +-----------------+ 147 | | 148 | MIF Router +---/--- other interfaces 149 | | 150 +---+---------+---+ 151 | | Two interfaces sharing a prefix 152 --+-+-- --+-+-- 153 | | 154 +--+---------+--+ 155 | MIF Host | 156 +---------------+ 158 Figure 1: Hypothetical MIF interconnection 160 The proposal also differs slightly from [RFC1122]'s language of the 161 Strong Host Model. The statement is that the packet will go to the 162 router that advertised a given prefix, but doesn't state what 163 interface that might happen on. Hence, if the router is a MIF router 164 and is using the same prefix on two or more LANs shared by the host 165 (as in Figure 1), the host might use each of those LANs and meet the 166 requirement. The Strong Host Model is not stated in those terms, but 167 in terms of the interface used, and would find a MIF router quite 168 confusing: 170 (A) A host [MUST] silently discard an incoming datagram whose 171 destination address does not correspond to the physical interface 172 through which it is received. 174 (B) A host [MUST] restrict itself to sending (non-source- routed) 175 IP datagrams only through the physical interface that corresponds 176 to the IP source address of the datagrams. 178 However, comparing the presumptive route lookup mechanisms in each 179 model, this proposal is indeed most similar to the Strong Host Model, 180 as is any source/destination routing paradigm. 182 Strong: route(src IP addr, dest IP addr, TOS) -> gateway 184 Weak: route(dest IP addr, TOS) -> gateway, interface 186 In the hypothetical MIF model suggested in Figure 1, the address 187 fails to identify a single interface, but it does identify a single 188 gateway. 190 1.2. Requirements Language 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in [RFC2119]. 196 2. Sending context expected by the host 198 2.1. Expectations the host has of the network 200 A host receives prefixes in a Router Advertisement [RFC4861], which 201 goes on to identify whether they are usable by SLAAC [RFC4862] 202 [RFC4941] [RFC7217]. When no prefixes are usable for SLAAC, the 203 Router Advertisement would normally signal the availability of DHCPv6 204 [RFC3315] and the host would use it to configure its addresses. In 205 the latter case (or if both SLAAC and DHCPv6 are used on the same 206 link for some reason) it will be generally the case that the 207 configured addresses match one of the prefixes advertised in a Router 208 Advertisement that are supposed to be in that link. 210 The simplest multihomed network implementation in which a host makes 211 choices among routers might be a LAN with one or more hosts on it and 212 two or more routers, one for each upstream network, or a host that is 213 served by disjoint networks on separate interfaces. In such a 214 network, especially the latter, there is not necessarily a routing 215 protocol, and the two routers may not even know that the other is a 216 router as opposed to a host, or may be configured to ignore its 217 presence. One might expect that the routers may or may not receive 218 each other's RAs and form an address in the other router's prefix 219 (which is not per [RFC4862], but is implemented by some stub router 220 implementations). However, all hosts in such a network might be 221 expected to create an address in each prefix so advertised. 223 +---------+ +---------+ +---------+ +---------+ 224 | ISP | | ISP | | ISP | | ISP | 225 +----+----+ +----+----+ +----+----+ +----+----+ 226 | | | | 227 | | | | 228 +----+----+ +----+----+ +----+----+ +----+----+ 229 | Router | | Router | | Router | | Router | 230 +----+----+ +----+----+ +----+----+ +----+----+ 231 | | | | 232 +------+------+ | +--------+ | 233 | +--+ Host +--+ 234 +----+----+ +--------+ 235 | Host | 236 +---------+ 237 Common LAN Case Disjoint LAN Case 238 (Multihomed Network) (Multihomed Host) 240 Figure 2: Two simple networks 242 If there is no routing protocol among those routers, there is no 243 mechanism by which packets can be deterministically forwarded between 244 the routers (as described in BCP 84 [RFC3704]) in order to avoid 245 filters. Even if there was routing, it would result in an indirect 246 route, rather than a direct route originating with the host; this is 247 not "wrong", but can be inefficient. Therefore the host would do 248 well to select the appropriate router itself. 250 Since the host derives fundamental default routing information from 251 the Router Advertisement, this implies that, in any network with 252 hosts using multiple prefixes, each prefix SHOULD be advertised via a 253 Prefix Information Option (PIO) [RFC4861] by one of the attached 254 routers, even if addresses are being assigned using DHCPv6. A router 255 that advertises a prefix indicates that it is able to appropriately 256 route packets with source addresses within that prefix, regardless of 257 the setting of the L and A flags in the PIO. In some circumstances 258 both L and A might be zero. 260 Although this does not violate the existing standard [RFC4861], such 261 a PIO has not previously been common, and it is possible that 262 existing host implementations simply ignore such a PIO or that a 263 router implementation rejects such a PIO as a configuration error. 264 Newer implementations that support this mechanism will need to be 265 updated accordingly: a host SHOULD NOT ignore a PIO simply because 266 both L and A flags are cleared; a router SHOULD be able to send such 267 a PIO. 269 2.2. Expectations of multihomed networks 271 The direct implication of Section 2.1 is that, if the network uses a 272 routing protocol, the routing protocols used in multihomed networks 273 SHOULD implement source-prefix based egress routing. Network designs 274 exist that can usefully limit themselves to static routing (such a a 275 simple tree network), or may internally use no routers at all, such 276 as a single LAN with two CE routers, each of which leads to a 277 different upstream network. 279 3. Reasonable expectations of the host 281 3.1. Interpreting Router Advertisements 283 As described in [RFC4191] and [RFC4861], a Router Advertisement may 284 contain zero or more Prefix information Options (PIOs), zero or more 285 Route Information Options (RIOs), or a Default Router List. In their 286 original intent, these indicate general information to a host: "these 287 are your default routers", "you might create or be configured with an 288 address in this prefix", or "this router would be a good place to 289 send traffic directed to a given destination prefix". In a multi- 290 homed network implementing source/destination routing, the 291 interpretation of a default router list or an RIO has to be modified 292 with the words "if the source address is in one of the prefixes I 293 advertise in a PIO". Additionally, the PIO must be reinterpreted to 294 also imply that the advertising router would be a reasonable first 295 hop for any packet using a source address in any advertised prefix. 297 +---------+ | 298 ( ISP A ) - + Bob-A +--+ +-----+ 299 +---------+ / +---------+ +--+ | 300 | | / | | | 301 | Alice +---/---( The Internet ) | Bob | 302 | | \ | | | 303 +---------+ \ +---------+ +--+ | 304 ( ISP B ) - + Bob-B +--+ +-----+ 305 +---------+ | 307 Figure 3: PIOs, RIOs, and Default Routes 309 The implications bear consideration. Imagine, Figure 3, that hosts 310 Alice and Bob are in communication, Bob's network is multihomed, and 311 Bob's first hop routers are Bob-A (to upstream ISP A advertising 312 prefix A') and Bob-B (to upstream network B and advertising prefix 313 B'). If Bob is responding to a message from Alice, his choice of 314 source address is forced to be the address Alice used as a 315 destination (which we may presume to have been in prefix A'). Hence, 316 Bob created or was assigned an address in A', and can only reasonably 317 send traffic using it to Bob-A as a first hop router. If there were 318 several instances of Bob-A and one had advertised itself as a default 319 router or as having a route to Alice, that is the router Bob should 320 choose. If none of Bob-A have advertised that but Bob-B has, it is 321 irrelevant; Bob is using the address allocated in A' and courts a BCP 322 38 discard if he doesn't send the packet to Bob-A. 324 In the special case that Bob is initiating the conversation, an RIO 325 might, however, influence source address choice. Bob could 326 presumably use any address allocated to him, in this case his address 327 in A' or B'. If Bob-B has advertised an RIO for Alice's prefix and 328 Bob-A has not, Bob MAY take that fact into account in address 329 selection - choosing an address that would allow him to make use of 330 the RIO. 332 3.2. Default Router Selection 334 Default Router Selection is modified as follows: A host SHOULD select 335 default routers for each prefix it is assigned an address in. 336 Routers that have advertised the prefix in its Router Advertisement 337 message SHOULD be preferred over routers that do not advertise the 338 prefix. 340 As a result of doing so, when a host sends a packet using a source 341 address in one of those prefixes and has no history directing it 342 otherwise, it SHOULD send it to the indicated default router. In the 343 "simplest" network described in Section 2.1, that would get it to the 344 only router that is directly capable of getting it to the right ISP. 345 This will also apply in more complex networks, even when more than 346 one physical or virtual interface is involved. 348 In more complex cases, wherein routers advertise RAs for multiple 349 prefixes whether or not they have direct or isolated upstream 350 connectivity, the host is dependent on the routing system already. 351 If the host gives the packet to a router advertising its source 352 prefix, it should be able to depend on the router to do the right 353 thing. 355 3.3. Source Address Selection 357 There is an interaction with Default Address Selection [RFC6724]. 358 Rule 5.5 of that specification states that the source address used to 359 send to a given destination address should if possible be chosen from 360 a prefix known to be advertised by the first-hop router for that 361 destination. This selection rule would be applicable in a host 362 following the recommendation in the previous section. 364 3.4. Redirects 366 There is potential for adverse interaction with any off-link Redirect 367 (Redirect for a GUA destination that is not on-link) message sent by 368 a router in accordance with Section 8 of [RFC4861]. Hosts SHOULD 369 apply off-link redirects only for the specific pair of source and 370 destination addresses concerned, so the host's Destination Cache may 371 need to contain appropriate source-specific entries. 373 3.5. History 375 Some modern hosts maintain history, in terms of what has previously 376 worked or not worked for a given address or prefix and in some cases 377 the effective window and MSS values for TCP or other protocols. This 378 might include a next hop address for use when a packet is sent to the 379 indicated address. 381 When such a host makes a successful exchange with a remote 382 destination using a particular address pair, and the host has 383 previously received a PIO that matches the source address, then the 384 host SHOULD include the prefix in such history, whatever the setting 385 of the L and A flags in the PIO. On subsequent attempts to 386 communicate with that destination, if it has an address in that 387 prefix at that time, a host MAY use an address in the remembered 388 prefix for the session. 390 4. Residual issues 392 Consider a network where routers on a link run a routing protocol and 393 are configured with the same information. Thus, on each link all 394 routers advertise all prefixes on the link. The assumption that 395 packets will be forwarded to the appropriate egress by the local 396 routing system might cause at least one extra hop in the local 397 network (from the host to the wrong router, and from there to another 398 router on the same link). 400 In a slightly more complex situation such as the disjoint LAN case of 401 Figure 2, which happens to be one of the authors' home plus corporate 402 home-office configuration, the two upstream routers might be on 403 different LANs and therefore different subnets (e.g., the host is 404 itself multi-homed). In that case, there is no way for the "wrong" 405 router to detect the existence of the "right" router, or to route to 406 it. 408 In such a case it is particularly important that hosts take the 409 responsibility to memorize and select the best first-hop as described 410 in Section 3. 412 5. IANA Considerations 414 This memo asks the IANA for no new parameters. 416 6. Security Considerations 418 This document does not create any new security or privacy exposures. 419 It is intended to avoid connectivity issues in the presence of BCP 38 420 ingress filters or stateful firewalls combined with multihoming. 422 There might be a small privacy improvement, however: with the current 423 practice, a multihomed host that sends packets with the wrong address 424 to an upstream router or network discloses the prefix of one upstream 425 to the other upstream network. This practice reduces the probability 426 of that occurrence. 428 7. Acknowledgements 430 Comments were received from Jinmei Tatuya and Ole Troan, who have 431 suggested important text, plus Mikael Abrahamsson, Steven Barth, 432 Juliusz Chroboczek, Toerless Eckert, David Farmer, Pierre Pfister, 433 Mark Smith, Dusan Mudric, and James Woodyatt. 435 8. References 437 8.1. Normative References 439 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 440 Requirement Levels", BCP 14, RFC 2119, 441 DOI 10.17487/RFC2119, March 1997, 442 . 444 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 445 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 446 December 1998, . 448 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 449 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 450 November 2005, . 452 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 453 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 454 DOI 10.17487/RFC4861, September 2007, 455 . 457 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 458 "Default Address Selection for Internet Protocol Version 6 459 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 460 . 462 8.2. Informative References 464 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 465 Communication Layers", STD 3, RFC 1122, 466 DOI 10.17487/RFC1122, October 1989, 467 . 469 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 470 Defeating Denial of Service Attacks which employ IP Source 471 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 472 May 2000, . 474 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 475 C., and M. Carney, "Dynamic Host Configuration Protocol 476 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 477 2003, . 479 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 480 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 481 2004, . 483 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 484 Address Autoconfiguration", RFC 4862, 485 DOI 10.17487/RFC4862, September 2007, 486 . 488 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 489 Extensions for Stateless Address Autoconfiguration in 490 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 491 . 493 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 494 Capabilities in Customer Premises Equipment (CPE) for 495 Providing Residential IPv6 Internet Service", RFC 6092, 496 DOI 10.17487/RFC6092, January 2011, 497 . 499 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 500 Requirements for IPv6 Customer Edge Routers", RFC 7084, 501 DOI 10.17487/RFC7084, November 2013, 502 . 504 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 505 Interface Identifiers with IPv6 Stateless Address 506 Autoconfiguration (SLAAC)", RFC 7217, 507 DOI 10.17487/RFC7217, April 2014, 508 . 510 Appendix A. Change Log 512 Initial Version: 2015-08-05 514 Version 01: Update text on PIOs, added text on Redirects, and 515 clarified the concept of a "simple" network, 2015-08-13. 517 Version 02: Clarifications after WG discussions, 2015-08-19. 519 Version 03: More clarifications after more WG discussions, 520 especially adding stateful firewalls, uRPF, and more precise 521 discussion of RFC 4861, 2015-09-03. 523 Version 04: Responds to various comments including 525 * Questions regarding RFC 1122's strong and weak host models. 526 This model is, strictly speaking, neither, but is most similar 527 to the strong host model. 529 * Some wording errors. 531 * Requests for discussion of the handling of the RIO, PIO, and 532 Default Router List in an RA. 534 Authors' Addresses 536 Fred Baker 537 Cisco Systems 538 Santa Barbara, California 93117 539 USA 541 Email: fred@cisco.com 543 Brian Carpenter 544 Department of Computer Science 545 University of Auckland 546 PB 92019 547 Auckland 1142 548 New Zealand 550 Email: brian.e.carpenter@gmail.com