idnits 2.17.1 draft-lear-httpbis-svcinfo-rr-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 == Line 320 has weird spacing: '...0 in ns ns1....' == Line 348 has weird spacing: '...0 in ns ns1....' == Line 374 has weird spacing: '...0 in ns ns1....' -- The document date (February 21, 2013) is 4082 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: 'X' is mentioned on line 405, but not defined -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft Cisco Systems GmbH 4 Intended status: Standards Track February 21, 2013 5 Expires: August 25, 2013 7 A DNS Resource Record for Service Descriptions 8 draft-lear-httpbis-svcinfo-rr-01 10 Abstract 12 Certain application protocols are highly transactional and require 13 substantial care when dealing with latency. Queries for versioning 14 information are, in these circumstances, costly. In addition, there 15 is a desire to allow for a means to specify a lightweight means to 16 alternative transport protocols, such as making use of SCTP instead 17 of TCP. This memo specifies a new DNS RR with an eye toward the 18 least necessary roundtrips to determine various protocols, port 19 numbers, and options for a given service instance. 21 Note 23 [[NOTE: For httpbis, the first goal is to focus down on requirements. 24 Consider all this draft through the lens of "http" where one sees the 25 words "application protocol" or "service".]] 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 25, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Design Requirements . . . . . . . . . . . . . . . . . . . 3 63 1.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 4 64 1.2.1. The DNS SRV Record . . . . . . . . . . . . . . . . . 4 65 1.2.2. NAPTR . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.2.3. The URI resource record . . . . . . . . . . . . . . . 4 67 1.2.4. Happy Eyeballs . . . . . . . . . . . . . . . . . . . 4 68 1.3. Overall approach . . . . . . . . . . . . . . . . . . . . 5 69 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. The SVCINFO Record Format and Use . . . . . . . . . . . . . . 5 71 2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.2. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3. Backward Compabitibility and Other Interactions . . . . . . . 7 74 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 6.1. Registration of Profiles . . . . . . . . . . . . . . . . 11 78 6.2. Initial SVCINFO Profile Registrations . . . . . . . . . . 11 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 8.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Appendix A. SRV example . . . . . . . . . . . . . . . . . . . . 12 84 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 13 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 For an application protocol to survive over time, it must include 90 version information, and usually must have some sort of capability 91 statement or exchange. How this is done depends on a number of 92 characteristics of the protocol, such as whether it is half-duplex 93 and what performance characteristics it has. When using many 94 transactional connections, end-to-end latency will occur before new 95 capabilities can be used. 97 In addition, traditionally application protocol specifications have 98 indicated the transport protocol to be used. It is useful to be able 99 to declare in advance what protocol(s) a service instance runs atop. 100 For instance, it might be possible to a service instance on both TCP 101 [RFC0792] and SCTP [RFC4960]. 103 1.1. Design Requirements 105 We have the following five design requirements for any solution: 107 1. Application protocol version information must be discoverable 108 within the DNS. 110 2. Transport protocol version information for a service must be 111 discoverable within the DNS. 113 3. Performance of the application must not be unduly impacted. Some 114 additional latency may be tolerated. 116 4. It should be possible for multiple instances of an application to 117 be advertised on different ports by the same host. This is 118 particularly common with HTTP [RFC2616]. 120 5. While it may be possible to modify URI schema definitions, all 121 such modifications MUST be 100% backward compatible. 123 One additional potential requirement would be host-level redirection. 124 The benefit of host-level redirection in the DNS is that it would 125 allow for a virtual server to securely offer TLS for multiple domains 126 without the need for multiple IP addresses, as different ports are 127 offered for different virtual hosts instead of different IP 128 addresses. 130 1.2. Related Work 132 There are a number of existing capabilities within the network that 133 can address some or all of the requirements above. 135 1.2.1. The DNS SRV Record 137 It has been possible to make use of a new service name and query the 138 DNS for a SRV resource record [RFC2782], again perhaps running a 139 race. SRV provides a mechanism to locate one or more server and port 140 for a given service. There are two concerns with SRV. First, one 141 must indicate the transport protocol as part of the QNAME. This 142 means that discovery of multiple transport protocols requires 143 multiple queries. 145 In addition, common enterprise deployments create a _TCP zone for 146 purposes such as load balancing of SRV responses separate from a 147 parent domain. Keeping in mind that the goal is to reduce the number 148 of queries to determine version and protocol parameters, multiple DNS 149 queries perform no better than an in-path application protocol 150 exchange. Additional information also cannot always be provided or 151 be trusted, because the authoritative name server for the service 152 name may not also be authoritative for the target domain. A detailed 153 example of the SRV record's performance is given in Appendix A. 155 1.2.2. NAPTR 157 Another record that could be considered is NAPTR [RFC3402]. NAPTR is 158 a very powerful means for DNS clients to apply search-and-replace 159 rules to a given URI. Building upon the SRV record, NAPTR provides a 160 means to specify use of alternate services and transport protocols. 161 Because NAPTR may return either an A record or SRV record, one or 162 more follow-on query may be needed. In addition, this leaves us 163 without protocol version information. 165 1.2.3. The URI resource record 167 The URI resource record provides for a mapping from hostname to URI. 168 This record can be used to map a domain to multiple URIs, in fact. 169 What it lacks, however, is version information about the application 170 protocol. 172 1.2.4. Happy Eyeballs 174 One final approach is to run a race by initiating the protocol 175 exchange using two alternatives, and pursuing the alternative that 176 indicates success first, the assumption being that the service 177 exists. An example of this model is Happy Eyeballs [RFC6555], where 178 different versions of IP are tested. This work specifies that when 179 an AAAA record is specified, a race may be performed. DNS cannot in 180 general be used to determine reachability. Hence, a race may yet be 181 appropriate in some circumstances, when a service is advertised. 183 1.3. Overall approach 185 To allow hosts to advertise a service using multiple versions of 186 application protocols or multiple transport protocols, a method is 187 needed to efficiently advertise that there exists an equivalence. To 188 accomplish this, we define a new RRtype that states each way to 189 connect to the service by using as an initial index the port and 190 service that the application intends to connect to, and then 191 providing an additional index known as an "InstanceId" that then 192 establishes an equivalence between the instant record and any other 193 record returned in the query with the same InstanceId. Examples of 194 this approach are found in Section 4. This additional index is 195 useful in circumstances where multiple applications making use of the 196 same service (such as HTTP) are running on a single host. The 197 InstanceId can be used to indicate to the client which application is 198 instantiated through multiple protocols (such as a database 199 application making use of both HTTP 1.1 and HTTP 2.0). In addition, 200 the record references profiles that provide transport protocol, 201 version, and other application protocol-specific information. 203 1.4. Terminology 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in RFC 2119 [RFC2119]. 209 2. The SVCINFO Record Format and Use 211 The SVCINFO RR is queried with DNS type code TBD. The format of the 212 SVCINFO resource record is as follows: 214 domain TTL Class SVCINFO InstanceId Priority Port Profile 216 The fields are defined as follows: 218 Domain, TTL, Class: These are specified in [RFC1035]. 220 SVCINFO: This is the resource record type. 222 InstanceId: This textual key identifies an instance of a service. 223 If the same InstanceId appears in multiple SVCINFO records, then 224 the services on those ports atop those protocols are said by the 225 service owner to be equivalent. 227 Priority: This eight-bit number has similar meaning to "Priority" 228 as defined in [RFC2782]. Its use and interaction with other 229 fields is described below. 231 Port: This is a port number associated with the service running on 232 a host. The value must be a legal value for the assocated 233 transport protocol. 235 Profile: This field indicates the name of a profile to be used to 236 determine transport protocol and protocol version. Each profile 237 is registered with IANA. If a host does not recognize the profile 238 it MUST ignore the record. Two initial entries are defined later 239 in this memo. 241 2.1. Usage 243 When a host offers an equivalent service in two different ways it 244 will advertise those ways in the DNS with the SVCINFO record, using 245 the same InstanceId. When a host wants to make use of a service, it 246 then queries the DNS with QNAME=domain, QCLASS=IN, and QTYPE=SVCINFO. 247 It processes the information as follows: 249 [[DISCUSS: Is class IN really correct?]] 251 1. First, the host constructs the information required to match 252 against. This will consist of transport protocol, and 253 application version that it would use in the absense of a 254 matching RR. This information should uniquely identify a 255 profile. For instance, given a URL of "http:// 256 www.example.com:49992", by default the host would connect via TCP 257 port 49992 to host www.example.com and proceed to use HTTP 1.1. 258 This is associated with a profile named TCP-HTTP-1.1. 260 2. If the reply is NOERROR and ANCOUNT=0 is returned, the host 261 attempts to connect using the information in the previous step 262 (e.g., using profile TCP-HTTP-1.1 which to port 49992). 264 3. If the reply is NOERROR and ANCOUNT > 0, the host searches for 265 the port and profile it determined in the first step. If there 266 is no match, it connects as it would have in the previous step. 267 Upon a match, it notes the InstanceId of that record, and any 268 matching InstanceId of other SVCINFO records returned in the 269 answer. 271 4. The host then attempts to connect to the profile and port with 272 the lowest number priority. Two records with same InstanceId 273 that have the same priority may be tried in any order, or raced. 275 2.2. Notes 277 Zones MUST NOT publish multiple SVCINFO records for the same domain 278 that use the same profile AND port. Resolvers SHOULD ignore such 279 SVCINFO records. 281 A client resolver MUST parse all RRs in the reply in order to 282 properly determine priority. Accordingly, clients MUST handle 283 truncated responses using the rules described in [RFC2181]. 285 In all cases when an SVCINFO record is returned, all A and AAAA 286 record for the domain SHOULD be returned in the additional 287 information section. This eliminates excess queries without adding 288 additional risk of cache poisoning. 290 When the application loses communication with the other side, it 291 SHOULD re-apply the rules above in attempting to re-establish 292 connectivity. When doing so, applications making use of the SVCINFO 293 record MUST observe DNS caching semantics. 295 3. Backward Compabitibility and Other Interactions 297 There are several side effects of using SVCINFO. The first, is that 298 by its nature, SVCINFO requires backward compatibility. A service 299 must always run on a port that is advertised, be that as an IANA- 300 assigned port, through specification within a URI, or some other 301 means. At the same time, when SVCINFO *is* used by the client, an 302 observer may not see the client connect to a server on a port 303 specified by a given URI. 305 4. Examples 307 Case 1: Different versions of HTTP, same transport protocol 309 Consider the case of host www.example.com, which is running an 310 HTTP1.1 server on port 80 and an HTTP2.0 server on port 49080, both 311 using TCP, both serving the same content. A records for this service 312 might appear as follows: 314 www.example.com 86400 in svcinfo homepage 10 80 TCP-HTTP-1.1 315 www.example.com 86400 in svcinfo homepage 5 49080 TCP-HTTP-2.0 317 Additional Information: 318 www.example.com 86400 in a 192.0.2.1 319 www.example.com 86400 in aaaa 2001:db8::1 320 example.com 604800 in ns ns1.example.com 322 When a web client attempted to connect to http://www.example.com, it 323 would construct the expected profile based on transport protocol TCP 324 and assuming HTTP 1.1. It would also know that it is expected to 325 connect to port 80. When it queries for the svcinfo record of 326 www.example.com, it receives the above response. It then sees that 327 the InstanceId on port 80 for TCP-HTTP-1.1 is "homepage". It also 328 sees that the InstanceId for port 49080 is also "homepage". It now 329 knows that these two services are equivalent, and sees that it should 330 attempt to connect to tcp/49080 if it understands the TCP-HTTP-2.0. 331 If the client doesn't understand that profile, it, it uses TCP- 332 HTTP-1.1, connecting again to 80/tcp and using HTTP 1.1. 334 Case two: Same service running on multiple transport protocols 336 In the next case, we change the case slightly from above by allowing 337 for the idea that http2.0 will make use of SCTP in addition to TCP. 338 We allow for the existence of another profile, SCTP-HTTP-2.0. 339 Therefore the records might appear as follows: 341 www.example.com 86400 in svcinfo homepage 10 80 TCP-HTTP-1.1 342 www.example.com 86400 in svcinfo homepage 5 49080 TCP-HTTP-2.0 343 www.example.com 86400 in svcinfo homepage 1 80 SCTP-HTTP-2.0 345 Additional Information: 346 www.example.com 86400 in a 192.0.2.1 347 www.example.com 86400 in aaaa 2001:db8::1 348 example.com 604800 in ns ns1.example.com 350 Now when the web client attempts to connect to http:// 351 www.example.com, after seeing that all three responses for 352 www.example.com have an InstanceId of "homepage" (including that of 353 port 80, where the client has constructed a default profile of TCP- 354 HTTP-1.1), if recognizes STCP-HTTP-2.0, it should first try to 355 connect to port 80 using sctp, otherwise it behaves as it did the 356 previous example. 358 Case 3: Multiple services 360 In this case the client is attempting to connect to http:// 361 www.example.com:8080, where www.example.com runs multiple http 362 servers. The DNS configuration appears as follows: 364 www.example.com 86400 in svcinfo homepage 10 80 TCP-HTTP-1.1 365 www.example.com 86400 in svcinfo homepage 5 49080 TCP-HTTP-2.0 366 www.example.com 86400 in svcinfo homepage 1 80 SCTP-HTTP-2.0 367 www.example.com 86400 in svcinfo database 10 8080 TCP-HTTP-1.1 368 www.example.com 86400 in svcinfo database 5 8081 TCP-HTTP-2.0 369 www.example.com 86400 in svcinfo database 1 8080 SCTP-HTTP-2.0 371 Additional Information: 372 www.example.com 86400 in a 192.0.2.1 373 www.example.com 86400 in aaaa 2001:db8::1 374 example.com 604800 in ns ns1.example.com 376 When the client queries for www.example.com and receives the above 377 information, it notes that port 8080 has an InstanceId of "database", 378 and it knows that it already understands TCP-HTTP-1.1. It matches 379 that InstanceId with the records that contain the other profiles. It 380 ignores all other records that contain InstanceIds other than 381 "database". The client then attempts to connect first using SCTP- 382 HTTP-2.0, if it understands that profile. If it doesn't understand 383 either SCTP-HTTP-2.0 or TCP-HTTP-2.0, it will connect on port 8080 384 and proceed with HTTP 1.1. 386 5. Security Considerations 388 Absent the use of DNSSEC [RFC4035], it is important that alternatives 389 offered by this service have the same security properties, lest a 390 downgrade attack be introduced. 392 When published to the world, this record would divulge that the 393 likely presence of services running on a particular set of ports. It 394 may not be all that difficult to divine what is running, either based 395 on a simple probe, or the version number in the response. 397 6. IANA Considerations 399 The IANA is requested to allocate a DNS RRTYPE with the following 400 information: 402 A. Submission Date: 404 B. Submission Type: 405 [X] New RRTYPE 406 [ ] Modification to existing RRTYPE 408 C. Contact Information for submitter (will be publicly posted): 409 Name: TBD 410 Email Address: TBD 411 International telephone number: TBD 412 Other contact handles: TBD 414 D. Motivation for the new RRTYPE application. 415 Please keep this part at a high level to inform the Expert and 416 reviewers about uses of the RRTYPE. Most reviewers will be DNS 417 experts that may have limited knowledge of your application 418 space. 420 Please see Section 1 of this document. 422 E. Description of the proposed RR type. 423 This description can be provided in-line in the template, as an 424 attachment, or with a publicly available URL. 426 Please see Section 1 of this document. 428 F. What existing RRTYPE or RRTYPEs come closest to filling that 429 need and why are they unsatisfactory? 431 Please see Section 1 of this document. 433 G. What mnemonic is requested for the new RRTYPE (optional)? 434 Note: this can be left blank and the mnemonic decided after the 435 template is accepted. 437 SVCINFO 439 H. Does the requested RRTYPE make use of any existing IANA registry 440 or require the creation of a new IANA sub-registry in DNS 441 Parameters? If so, please indicate which registry is to be used 442 or created. If a new sub-registry is needed, specify the 443 allocation policy for it and its initial contents. Also include 444 what the modification procedures will be. 446 This RRType refers to the IANA Assigned Internet Protocol 447 Numbers registry, but requires no allocations from it. 449 I. Does the proposal require/expect any changes in DNS 450 servers/resolvers that prevent the new type from being processed 451 as an unknown RRTYPE (see [RFC3597])? 453 No. 455 J. Comments: 457 None. 459 6.1. Registration of Profiles 461 The IANA is requested to maintain a registry of profiles for the 462 SVCINFO record. New entries SHALL require review by a designated 463 expert. The following template is to be used: 465 Profile Name: 467 Description: A short description of the profile 468 Transport Protocol Information: 469 Application information: A pointer to an RFC containing a 470 protocol specification 472 6.2. Initial SVCINFO Profile Registrations 474 The IANA is requested to register the following profiles in the 475 SVCINFO Profiles registry: 477 Profile Name: TCP-HTTP-1.1 Description: HTTP 1.1 over TCP, including 478 documented extensions Transport Protocol Information: TCP Application 479 information: RFC-2616 Profile Name: TCP-HTTP-2.0-a1 Description: 480 Early draft of HTTP-2.0 Transport Protocol Information: TCP 481 Application information: draft-ietf-httpbis-http2-01.txt 483 7. Acknowledgments 485 This work largely builds upon the experience gathered with SRV 486 records, as originally defined by Paul Vixie. SRV records are still 487 appropriate in many, if not most, circumstances. Thanks also go to 488 Joe Hildebrand, Dan Wing, and Mark Nottingham for their reviews. 490 8. References 492 8.1. Normative References 494 [RFC1035] Mockapetris, P., "Domain names - implementation and 495 specification", STD 13, RFC 1035, November 1987. 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, March 1997. 500 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 501 Specification", RFC 2181, July 1997. 503 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 504 specifying the location of services (DNS SRV)", RFC 2782, 505 February 2000. 507 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 508 (RR) Types", RFC 3597, September 2003. 510 8.2. Informative References 512 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 513 RFC 792, September 1981. 515 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 516 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 517 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 519 [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 520 Part Two: The Algorithm", RFC 3402, October 2002. 522 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 523 Rose, "Protocol Modifications for the DNS Security 524 Extensions", RFC 4035, March 2005. 526 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 527 4960, September 2007. 529 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 530 Dual-Stack Hosts", RFC 6555, April 2012. 532 Appendix A. SRV example 534 Consider the fictional case where http version 2 requires querying 535 the DNS for _http2._tcp.example.com to get to example.com. The SRV 536 record might look something like this: 538 _http2._tcp.example.com 86400 in srv 10 10 49080 www.example.com 540 To fully resolve http://example.com to the necessary components of an 541 ip address,transport protocol, and a port, a full service resolver 542 must make the following queries: 544 1. A query for _http2._tcp.example.com to name servers for 545 example.com will either return the SRV record or name servers for 546 _tcp.example.com. 548 2. A query is made where there is a zone cut for _tcp.example.com. 549 We now have the SRV record. We may also have an A record for 550 www.example.com if it appears in an additional information 551 section in the same zone. 553 3. If we do not have the A record for www.example.com, we will then 554 query for it separately. 556 Step 2 is a common step that is necessary today in many enterprise 557 deployments, even if the client being served is not within that 558 enterprise. The last step may actually be several steps if the 559 target domain is not in the same zone as the name found in the QNAME. 560 A check of one highly optimized common news site found ten separate 561 and distinct domains. Risking an average query response time of 562 60ms, use of SRV records could inject 600ms on the initial start up 563 for that site. 565 What we conclude is that the fundamental issue with SRV (and any 566 record where a zone split is likely) is that the service name 567 requires additional A records for a host to connect to the service 568 that may not be possible to provide in a single query. 570 Appendix B. Changes 572 This section to be removed prior to publication. 574 o 00 Initial Revision. 576 Author's Address 578 Eliot Lear 579 Cisco Systems GmbH 580 Richtistrasse 7 581 Wallisellen, ZH CH-8304 582 Switzerland 584 Phone: +41 44 878 9200 585 Email: lear@cisco.com