idnits 2.17.1 draft-vandevelde-idr-remote-next-hop-04.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 : ---------------------------------------------------------------------------- ** There are 24 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 179 has weird spacing: '...tribute and i...' == 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 date (July 15, 2013) is 3938 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: 'RFC2003' is mentioned on line 164, but not defined == Missing Reference: 'VXLAN' is mentioned on line 225, but not defined == Missing Reference: 'NVGRE' is mentioned on line 265, but not defined == Missing Reference: 'IPVPN-overlay' is mentioned on line 194, but not defined == Missing Reference: 'EVPN-overlay' is mentioned on line 194, but not defined == Unused Reference: 'I-D.mahalingam-dutt-dcops-vxlan' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'I-D.sridharan-virtualization-nvgre' is defined on line 436, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) == Outdated reference: A later version (-08) exists of draft-ietf-sidr-bgpsec-overview-02 == Outdated reference: A later version (-09) exists of draft-mahalingam-dutt-dcops-vxlan-02 == Outdated reference: A later version (-08) exists of draft-sridharan-virtualization-nvgre-02 Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR G. Van de Velde 3 Internet-Draft K. Patel 4 Intended status: Standards Track D. Rao 5 Expires: January 16, 2014 Cisco Systems 6 R. Raszuk 7 NTT MCL Inc. 8 R. Bush 9 Internet Initiative Japan 10 July 15, 2013 12 BGP Remote-Next-Hop 13 draft-vandevelde-idr-remote-next-hop-04 15 Abstract 17 The BGP Remote-Next-Hop is a new optional transitive attribute 18 intended to facilitate automatic tunneling across an AS on a per 19 address family basis. The attribute carries one or more tunnel end- 20 points for a NLRI. Additionally, tunnel encapsulation information is 21 communicated to successfully setup these tunnels. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 16, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Tunnel Encapsulation attribute versus BGP Remote-Next-Hop 60 attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. BGP Remote-Next-Hop attribute TLV Format . . . . . . . . . . 3 62 4.1. Encapsulation sub-TLVs for virtual network overlays . . . 4 63 4.1.1. Encapsulation sub-TLV for VXLAN . . . . . . . . . . . 5 64 4.1.2. Encapsulation sub-TLV for NVGRE . . . . . . . . . . . 6 65 5. Use Case scenarios . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Multi-homing for IPv6 . . . . . . . . . . . . . . . . . . 7 67 5.2. Dynamic Network Overlay Infrastructure . . . . . . . . . 7 68 5.3. The Tunnel end-point is NOT the originating BGP speaker . 7 69 5.4. Networks that do not support BGP Remote-Next-Hop 70 attribute . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.5. Networks that do NOT support BGP Remote-Next-Hop 72 attribute . . . . . . . . . . . . . . . . . . . . . . . . 8 73 6. BGP Remote-Next-Hop Community . . . . . . . . . . . . . . . . 8 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 8.1. Protecting the validity of the BGP Remote-Next-Hop 77 attribute . . . . . . . . . . . . . . . . . . . . . . . . 8 78 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 79 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 82 11.2. Informative References . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 [RFC5512] defines an attribute attached to an NLRI to signal tunnel 88 end-point encapsulation information between two BGP speakers. It 89 assumes that the exchanged tunnel endpoint is the NLRI. 91 This document defines a new BGP transitive attribute known as a 92 Remote-Next-Hop BGP attribute for Intra-AS and Inter-AS usage which 93 removes that assumption. 95 The tunnel endpoint information and the tunnel encapsulation 96 information is carried within a Remote-Next-Hop BGP attribute. This 97 attribute is tagged on an any BGP NLRI. This way the Address Family 98 (AF) of the NLRI exchanged is decoupled from the tunnel SAFI address- 99 family defined in [RFC5512]. 101 2. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 105 be interpreted as described in [RFC2119] only when they appear in all 106 upper case. They may also appear in lower or mixed case as English 107 words, without any normative meaning. 109 3. Tunnel Encapsulation attribute versus BGP Remote-Next-Hop attribute 111 The Tunnel Encapsulation attribute [RFC5512] is based on the 112 principle that the tunnel end-point is the BGP speaker originating 113 the update and is inserted as the NLRI in the exchange, with the 114 consequence that it is impossible to set the endpoint to an arbitrary 115 IP address. 117 There are use cases where it is desired that the tunnel end-point 118 address should be a different address, or set of addresses, than the 119 originating BGP speaker. It is also useful to be able to signal 120 different encapsulation parameters for different prefixes with the 121 same remote tunnel end-point. The BGP Remote-Next-Hop attribute 122 provides the ability to have one or more different tunnel end-point 123 addresses from either the IPv4 and/or the IPv6 address-families, and 124 be able to signal next-hop encapsulation parameters along with any 125 prefix. 127 The sub-TLVs from the Tunnel Encapsulation Attribute [RFC5512] are 128 reused for the BGP Next-Hop-Attribute. 130 Due to the intrinsic nature of both attributes, the tunnel 131 encapsulation end-point assumes that the tunnel end-point is both the 132 NLRI exchanged and the originating router, while the BGP Remote-Next- 133 Hop attribute is inserted for an exchanged NLRI by adding a set of 134 tunnel end-points, these two attributes are mutually exclusive. 136 4. BGP Remote-Next-Hop attribute TLV Format 138 This attribute is an optional transitive attribute [RFC1771]. 140 The BGP Remote-Next-Hop attribute is is composed of a set of Type- 141 Length-Value (TLV) encodings. The type code of the attribute is 142 (IANA to assign). Each TLV contains information corresponding to a 143 particular tunnel technology and tunnel end-point address. The TLV 144 is structured as follows: 146 0 1 2 3 147 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Tunnel Type (2 Octets) | Length | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Addr len | Tunnel Address (IPv4 or IPv6) | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | AS Number | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Tunnel Parameters | 156 ~ ~ 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Tunnel Type (2 octets): identifies the type of tunneling technology 160 being signaled. This document specifies the following types: 162 - L2TPv3 over IP [RFC3931]: Tunnel Type = 1 163 - GRE [RFC2784]: Tunnel Type = 2 164 - IP in IP [RFC2003] [RFC4213]: Tunnel Type = 7 166 This document also defines the following types: 167 - VXLAN: Tunnel Type = 8 168 - NVGRE: Tunnel Type = 9 170 Unknown types MUST be ignored and skipped upon receipt. 172 Length (2 octets): the total number of octets of the value field. 174 Tunnel Address Length - Addr len (1 octet): Length of Tunnel 175 Address. Set to 4 bytes for an IPv4 address and 16 bytes for an 176 IPv6 address. 178 AS Number - The AS number originating the BGP Remote-Next-Hop 179 attribute and is either a 2-byte AS or 4-Byte AS number 181 Tunnel Parameter - (variable): comprised of multiple sub-TLVs. Each sub-TLV 182 consists of three fields: a 1-octet type, 1-octet length, and zero 183 or more octets of value. The sub-TLV definitions and the sub-TLV 184 data are described in depth in [RFC5512]. 186 4.1. Encapsulation sub-TLVs for virtual network overlays 188 A VN-ID may need to be signaled along with the encapsulation types 189 for DC overlay encapsulations such as [VXLAN] and [NVGRE]. The VN-ID 190 when present in the encapsulation sub-TLV for an overlay 191 encapsulation, MUST be processed by a receiving device if it is 192 capable of understanding it. The details regarding how such a 193 signaled VN-ID is processed and used is defined in specifications 194 such as [IPVPN-overlay] and [EVPN-overlay]. 196 4.1.1. Encapsulation sub-TLV for VXLAN 198 This document defines a new encapsulation sub-TLV format, defined in 199 [RFC5512], for VXLAN tunnels. When the tunnel type is VXLAN, the 200 following is the structure of the value field in the encapsulation 201 sub-TLV: 203 0 1 2 3 204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | MAC Address (4 Octets) | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | MAC Address (2 Octets) | Reserved | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 V: When set to 1, it indicates that a valid VN-ID is present in the 214 encapsulation sub-TLV. 215 M: When set to 1, it indicates that a valid MAC Address is present in the 216 encapsulation sub-TLV. 217 R: The remaining bits in the 8-bit flags field are reserved for further 218 use. They MUST be set to 0 on transmit and MUST be ignored on receipt. 220 VN-ID: Contains a 24-bit VN-ID value, if the 'V' flag bit is set. 221 If the 'V' flag is not set, it SHOULD be set to zero and MUST be ignored 222 on receipt. 224 The VN-ID value is filled in the VNI field in the VXLAN packet header as 225 defined in [VXLAN]. 227 MAC Address: Contains an Ethernet MAC address if the 'M' flag bit is set. 228 If the 'M' flag is not set, it SHOULD set to all zeroes and MUST be 229 ignored on receipt. 231 The MAC address is local to the device advertising the route, and should 232 be included as the destination MAC address in the inner Ethernet header 233 immediately following the outer VXLAN header, in the packets destined to 234 the advertiser. 236 4.1.2. Encapsulation sub-TLV for NVGRE 238 This document defines a new encapsulation sub-TLV format, defined in 239 [RFC5512], for NVGRE tunnels. When the tunnel type is NVGRE, the 240 following is the structure of the value field in the encapsulation 241 sub-TLV: 243 0 1 2 3 244 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | MAC Address (4 Octets) | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | MAC Address (2 Octets) | Reserved | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 V: When set to 1, it indicates that a valid VN-ID is present in the 254 encapsulation sub-TLV. 255 M: When set to 1, it indicates that a valid MAC Address is present in the 256 encapsulation sub-TLV. 257 R: The remaining bits in the 8-bit flags field are reserved for further 258 use. They MUST be set to 0 on transmit and MUST be ignored on receipt. 260 VN-ID: Contains a 24-bit VN-ID value, if the 'V' flag bit is set. 261 If the 'V' flag is not set, it SHOULD be set to zero and MUST be ignored 262 on receipt. 264 The VN-ID value is filled in the VSID field in the NVGRE packet header as 265 defined in [NVGRE]. 267 MAC Address: Contains an Ethernet MAC address if the 'M' flag bit is set. 268 If the 'M' flag is not set, it SHOULD set to all zeroes and MUST be 269 ignored on receipt. 271 The MAC address is local to the device advertising the route, and should 272 be included as the destination MAC address in the inner Ethernet header 273 immediately following the outer NVGRE header, in the packets destined to 274 the advertiser. 276 5. Use Case scenarios 278 This section provides a short overview of some use-cases for the BGP 279 Remote-Next-Hop attribute. Use of the BGP Remote-Next-Hop is not 280 limited to the examples in this section. 282 5.1. Multi-homing for IPv6 284 When an end-user IPv6 network is multi-homed to the Internet, it may 285 be assigned more than a single prefix originated by various upstream 286 ASs. Each AS prefers to only announce a supernet of all its assigned 287 IPv6 prefixes, unlike IPv4 where the AS announced the end-users 288 assigned prefix. The goal of this BGP policy behaviour is to keep 289 the number of entries in the IPv6 global BGP table to a minimum, it 290 also it also results in well known resiliency improvements. 292 For example, if an end-user IPv6 is peering with 2 different Service 293 providers AS1 and AS2. In this case the IPv6 end-user will have at 294 least one prefix assigned from each of these service providers. The 295 devices at the IPv6 end-user will each receive an address from these 296 prefixes. The devices will in most cases, when building IPv6 297 sessions (TCP, etc...), do so with only a single IPv6 address. The 298 decision which IPv6 address the device will use is documented in 299 [RFC3484]. 301 If one if the links between the end-user and one of the neighboring 302 AS's breaks, a consequence will be that a set of sessions need to be 303 reset, or that a section of the end-user network becomes unreachable. 305 With usage of the BGP-remote-Next-Hop attribute the service provider 306 can tunnel that packet towards an alternate BGP Remote-Next-Hop at 307 the end-users alternate provider and restore the network connectivity 308 even though the local link towards the end-user is broken. 310 5.2. Dynamic Network Overlay Infrastructure 312 The BGP Remote-Next-Hop extension allows signaling tunnel 313 encapsulations needed to build and dynamically create an overlay 314 tunneled network with traffic isolation and virtual private networks. 316 5.3. The Tunnel end-point is NOT the originating BGP speaker 318 Note that, in each network environment, the originating router is the 319 preferred tunnel end-point server. It may be that the network 320 administrator has deployed an independent set of tunnel end-point 321 servers across their network, which may or may not speak BGP. The 322 BGP Remote-Next-Hop attribute provides the ability to signal this via 323 BGP. 325 5.4. Networks that do not support BGP Remote-Next-Hop attribute 327 If a device does not support this attribute, and receives this 328 attribute, then normal NLRI BGP forwarding is used as the attribute 329 is optional and transitive. 331 5.5. Networks that do NOT support BGP Remote-Next-Hop attribute 333 If a BGP speaker does understand this attribute, and receives this 334 attribute, then the BGP speaker MAY, by configuration, skip use or 335 not use the information within this attribute. 337 6. BGP Remote-Next-Hop Community 339 place-holder for an BGP extension to signal valid prefixes allowed to 340 be considered as tunnel end-points. To be completed. 342 7. IANA Considerations 344 This memo asks the IANA for a new BGP attribute assignment for the 345 BGP Remote-Next-Hop attribute. 347 This memo also asks the IANA to reserve the following new Tunnel 348 Types for signaling VXLAN and NVGRE encapsulations. 350 VXLAN: Tunnel Type = 8 352 NVGRE: Tunnel Type = 9 354 8. Security Considerations 356 This technology could be used as technology as man in the middle 357 attack, however with existing RPKI validation for BGP that risk is 358 reduced. 360 The distribution of Tunnel end-point address information can result 361 in potential DoS attacks if the information is sent by malicious 362 organisations. Therefore is it strongly recommended to install 363 traffic filters, IDSs and IPSs at the perimeter of the tunneled 364 network infrastructure. 366 8.1. Protecting the validity of the BGP Remote-Next-Hop attribute 367 It is possible to inject a rogue BGP Remote-Next-Hop attribute to an 368 NLRI resulting in Monkey-In-The-Middle attack (MITM). To avoid this 369 type of MITM attack, it is strongly recommended to use a technology a 370 mechanism to verify that for NLRI it is the expected BGP Remote-Next- 371 Hop. We anticipate that this can be done with an expansion of RPKI- 372 Based origin validation, see [I-D.ietf-sidr-pfx-validate]. 374 This does not avoid the fact that rogue AS numbers may be inserted or 375 injected into the AS-Path. To achieve protection against that threat 376 BGP Path Validation should be used, see 377 [I-D.ietf-sidr-bgpsec-overview]. 379 9. Privacy Considerations 381 This proposal may introduce privacy issues, however with BGP security 382 mechanisms in place they should be prevented. 384 10. Change Log 386 Initial Version: 16 May 2012 388 Hacked for -01: 17 July 2012 390 11. References 392 11.1. Normative References 394 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 395 (BGP-4)", RFC 1771, March 1995. 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, March 1997. 400 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 401 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 402 March 2000. 404 [RFC3484] Draves, R., "Default Address Selection for Internet 405 Protocol version 6 (IPv6)", RFC 3484, February 2003. 407 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 408 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 410 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 411 for IPv6 Hosts and Routers", RFC 4213, October 2005. 413 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 414 Subsequent Address Family Identifier (SAFI) and the BGP 415 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 417 11.2. Informative References 419 [I-D.ietf-sidr-bgpsec-overview] 420 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 421 draft-ietf-sidr-bgpsec-overview-02 (work in progress), May 422 2012. 424 [I-D.ietf-sidr-pfx-validate] 425 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 426 Austein, "BGP Prefix Origin Validation", draft-ietf-sidr- 427 pfx-validate-10 (work in progress), October 2012. 429 [I-D.mahalingam-dutt-dcops-vxlan] 430 Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 431 L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A 432 Framework for Overlaying Virtualized Layer 2 Networks over 433 Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-02 434 (work in progress), August 2012. 436 [I-D.sridharan-virtualization-nvgre] 437 Sridharan, M., Greenberg, A., Venkataramaiah, N., Wang, 438 Y., Duda, K., Ganga, I., Lin, G., Pearson, M., Thaler, P., 439 and C. Tumuluri, "NVGRE: Network Virtualization using 440 Generic Routing Encapsulation", draft-sridharan- 441 virtualization-nvgre-02 (work in progress), February 2013. 443 Authors' Addresses 445 Gunter Van de Velde 446 Cisco Systems 447 De Kleetlaan 6a 448 Diegem 1831 449 Belgium 451 Phone: +32 2704 5473 452 Email: gvandeve@cisco.com 453 Keyur Patel 454 Cisco Systems 455 170 W. Tasman Drive 456 San Jose, CA 95124 95134 457 USA 459 Email: keyupate@cisco.com 461 Dhananjaya Rao 462 Cisco Systems 463 170 W. Tasman Drive 464 San Jose, CA 95124 95134 465 USA 467 Email: dhrao@cisco.com 469 Robert Raszuk 470 NTT MCL Inc. 471 101 S Ellsworth Avenue Suite 350 472 San Mateo, CA 94401 473 US 475 Email: robert@raszuk.net 477 Randy Bush 478 Internet Initiative Japan 479 5147 Crystal Springs 480 Bainbridge Island, Washington 98110 481 US 483 Email: randy@psg.com