idnits 2.17.1 draft-ietf-6man-rpl-routing-header-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 12, 2011) is 4573 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) == Unused Reference: 'I-D.hui-6man-rpl-headers' is defined on line 542, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN J. Hui 3 Internet-Draft Arch Rock Corporation 4 Intended status: Standards Track JP. Vasseur 5 Expires: April 14, 2012 Cisco Systems, Inc 6 D. Culler 7 UC Berkeley 8 V. Manral 9 IP Infusion 10 October 12, 2011 12 An IPv6 Routing Header for Source Routes with RPL 13 draft-ietf-6man-rpl-routing-header-04 15 Abstract 17 In Low power and Lossy Networks (LLNs), memory constraints on routers 18 may limit them to maintaining at most a few routes. In some 19 configurations, it is necessary to use these memory constrained 20 routers to deliver datagrams to nodes within the LLN. The Routing 21 for Low Power and Lossy Networks (RPL) protocol can be used in some 22 deployments to store most, if not all, routes on one (e.g. the 23 Directed Acyclic Graph (DAG) root) or few routers and forward the 24 IPv6 datagram using a source routing technique to avoid large routing 25 tables on memory constrained routers. This document specifies a new 26 IPv6 Routing header type for delivering datagrams within a RPL 27 domain. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 14, 2012. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Format of the RPL Routing Header . . . . . . . . . . . . . . . 7 67 4. RPL Router Behavior . . . . . . . . . . . . . . . . . . . . . 9 68 4.1. Generating Source Routing Headers . . . . . . . . . . . . 9 69 4.2. Processing Source Routing Headers . . . . . . . . . . . . 9 70 5. RPL Border Router Behavior . . . . . . . . . . . . . . . . . . 12 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 6.1. Source Routing Attacks . . . . . . . . . . . . . . . . . . 13 73 6.2. ICMPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . 13 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 76 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 82 1. Introduction 84 Routing for Low Power and Lossy Networks (RPL) is a distance vector 85 IPv6 routing protocol designed for Low Power and Lossy networks (LLN) 86 [I-D.ietf-roll-rpl]. Such networks are typically constrained in 87 resources (limited communication data rate, processing power, energy 88 capacity, memory). In particular, some LLN configurations may 89 utilize LLN routers where memory constraints limit nodes to 90 maintaining only a small number of default routes and no other 91 destinations. However, it may be necessary to utilize such memory- 92 constrained routers to forward datagrams and maintain reachability to 93 destinations within the LLN. 95 To utilize paths that include memory-constrained routers, RPL relies 96 on source routing. In one deployment model of RPL, necessary 97 mechanisms are used to collect routing information at more capable 98 routers and form paths from those routers to arbitrary destinations 99 within the RPL domain. However, a source routing mechanism supported 100 by IPv6 is needed to deliver datagrams. 102 This document specifies the Source Routing Header (SRH) for use 103 strictly within a RPL domain. 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 2. Overview 113 The format of SRH draws from that of the Type 0 Routing header (RH0) 114 [RFC2460]. However, SRH introduces mechanisms to compact the source 115 route entries when all entries share the same prefix with the IPv6 116 Destination Address of a packet carrying a SRH, a typical scenario in 117 LLNs using source routing. The compaction mechanism reduces 118 consumption of scarce resources such as channel capacity. 120 SRH also differs from RH0 in the processing rules to alleviate 121 security concerns that led to the deprecation of RH0 [RFC5095]. 122 First, routers processing SRH MUST implement a strict source route 123 policy where each and every IPv6 hop is specified within the datagram 124 itself. Second, a SRH header MUST only be used within a RPL domain. 125 RPL Border Routers, responsible for connecting RPL domains and IP 126 domains that use other routing protocols, MUST NOT allow datagrams 127 already carrying a SRH header to enter or exit the RPL domain. 128 Third, routers along the way MUST verify that loops do not exist with 129 in the source route. 131 To deliver a datagram, a router MAY specify a source route to reach 132 the destination using a SRH. There are two cases that determine how 133 to include an SRH with a datagram. 135 1. If the SRH specifies the complete path from source to 136 destination, the SRH should be included directly within the 137 datagram itself. 139 2. If the SRH only specifies a subset of the path from source to 140 destination, the router SHOULD use IPv6-in-IPv6 tunneling, as 141 specified in [RFC2473]. When tunneling, the router MUST prepend 142 a new IPv6 header and SRH to the original datagram. Use of 143 tunneling ensures that the datagram is delivered unmodified and 144 that ICMP errors return to the source of the SRH rather than the 145 source of the original datagram. 147 In a RPL network, Case 1 occurs when both source and destinations are 148 within a RPL domain and a single SRH header is used to specify the 149 entire path from source to destination, as shown in the following 150 figure: 152 +--------------------+ 153 | | 154 | (S) -------> (D) | 155 | | 156 +--------------------+ 157 RPL Domain 159 In the above scenario, datagrams traveling from source, S, to 160 destination, D, have the following packet structure: 162 +--------+---------+-------------//-+ 163 | IPv6 | Source | IPv6 | 164 | Header | Routing | Payload | 165 | | Header | | 166 +--------+---------+-------------//-+ 168 S's address is carried in the IPv6 Header's Source Address field. 169 D's address is carried in the last entry of SRH for all but the last 170 hop, when D's address is carried in the IPv6 Header's Destination 171 Address field of the packet carrying the SRH. 173 In a RPL network, Case 2 occurs for all datagrams that have either 174 source or destination outside the RPL domain, as shown in the 175 following diagram: 177 +-----------------+ 178 | | 179 | (S) -------> (BR1) -------> (D) 180 | | 181 +-----------------+ 182 RPL Domain 184 +-----------------+ 185 | | 186 | (D) <------- (BR1) <------- (S) 187 | | 188 +-----------------+ 189 RPL Domain 191 In the above scenario, datagrams that include the SRH in tunneled 192 mode have the following packet structure when traveling within the 193 RPL domain: 195 +--------+---------+--------+-------------//-+ 196 | Outer | Source | Inner | IPv6 | 197 | IPv6 | Routing | IPv6 | Payload | 198 | Header | Header | Header | | 199 +--------+---------+--------+-------------//-+ 200 <--- Original Packet ---> 201 <--- Tunneled Packet ---> 203 Note that the outer header (including the SRH) is added and removed 204 by the RPL Border Router. 206 Case 2 also occurs whenever a RPL router needs to insert a source 207 route when forwarding datagram. One such use case with RPL is to 208 have all RPL traffic flow through a Border Router and have the Border 209 Router use source routes to deliver datagrams to their final 210 destination. When including the SRH using tunneled mode, the Border 211 Router would encapsulate the received datagram unmodified using IPv6- 212 in-IPv6 and include a SRH in the outer IPv6 header. 214 +-----------------+ 215 | | 216 | (S) -------\ | 217 | \ | 218 | (BR1) 219 | / | 220 | (D) <------/ | 221 | | 222 +-----------------+ 223 RPL Domain 225 In the above scenario, datagrams travel from S to D through BR1. 226 Between S and BR1, the datagrams are routed using the DAG built by 227 RPL and do not contain a SRH. BR1 encapsulates received datagrams 228 unmodified using IPv6-in-IPv6 and the SRH is included in the outer 229 IPv6 header. 231 3. Format of the RPL Routing Header 233 The Source Routing Header has the following format: 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | CmprI | CmprE | Pad | Reserved | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | | 243 . . 244 . Addresses[1..n] . 245 . . 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Next Header 8-bit selector. Identifies the type of header 250 immediately following the Routing header. Uses 251 the same values as the IPv4 Protocol field 252 [RFC3232]. 254 Hdr Ext Len 8-bit unsigned integer. Length of the Routing 255 header in 8-octet units, not including the first 256 8 octets. Note that when Addresses[1..n] are 257 compressed (i.e. value of CmprI or CmprE is not 258 0), Hdr Ext Len does not equal twice the number 259 of Addresses. 261 Routing Type 8-bit selector. TBD by IANA. 263 Segments Left 8-bit unsigned integer. Number of route segments 264 remaining, i.e., number of explicitly listed 265 intermediate nodes still to be visited before 266 reaching the final destination. 268 CmprI 4-bit unsigned integer. Number of prefix octets 269 from each segment, except than the last segment, 270 (i.e. segments 1 through n-1) that are elided. 271 For example, a SRH carrying full IPv6 addresses 272 in Addresses[1..n-1] sets CmprI to 0. 274 CmprE 4-bit unsigned integer. Number of prefix octets 275 from the last segment (i.e. segment n) that are 276 elided. For example, a SRH carrying a full IPv6 277 address in Addresses[n] sets CmprE to 0. 279 Pad 4-bit unsigned integer. Number of octets that 280 are used for padding after Address[n] at the end 281 of the SRH. 283 Address[1..n] Vector of addresses, numbered 1 to n. Each 284 vector element in [1..n-1] has size (16 - CmprI) 285 and element [n] has size (16-CmprE). 287 The SRH shares the same basic format as the Type 0 Routing header 288 [RFC2460]. When carrying full IPv6 addresses, the CmprI, CmprE, and 289 Pad fields are set to 0 and the only difference between the SRH and 290 Type 0 encodings is the value of the Routing Type field. 292 A common network configuration for a RPL domain is that all nodes 293 within a LLN share a common prefix. The SRH introduces the CmprI, 294 CmprE, and Pad fields to allow compaction of the Address[1..n] vector 295 when all entries share the same prefix as the IPv6 Destination 296 Address field of the packet carrying the SRH. The CmprI and CmprE 297 field indicates the number of prefix octets that are shared with the 298 IPv6 Destination Address of the packet carrying the SRH. The shared 299 prefix octets are not carried within the Routing header and each 300 entry in Address[1..n-1] has size (16 - CmprI) octets and Address[n] 301 has size (16 - CmprE) octets. When CmprI or CmprE is non-zero, there 302 may exist unused octets between the last entry, Address[n], and the 303 end of the Routing header. The Pad field indicates the number of 304 unused octets that are used for padding. Note that when CmprI and 305 CmprE are both 0, Pad MUST carry a value of 0. 307 The SRH MUST NOT specify a path that visits a node more than once. 308 When generating a SRH, the source may not know the mapping between 309 IPv6 addresses and nodes. Minimally, the source MUST ensure that 310 IPv6 Addresses do not appear more than once and the IPv6 Source and 311 Destination addresses of the encapsulating datagram do not appear in 312 the SRH. 314 Multicast addresses MUST NOT appear in a SRH, or in the IPv6 315 Destination Address field of a datagram carrying a SRH. 317 4. RPL Router Behavior 319 4.1. Generating Source Routing Headers 321 To deliver an IPv6 datagram to its destination, a router may need to 322 generate a new SRH and specify a strict source route. Routers MUST 323 use IPv6-in-IPv6 tunneling, as specified in [RFC2473] to include a 324 new SRH in datagrams that are sourced by other nodes. Using IPv6-in- 325 IPv6 tunneling ensures that the delivered datagram remains unmodified 326 and that ICMPv6 errors generated by a SRH are sent back to the router 327 that generated the routing header. 329 To avoid fragmentation, it is desirable to employ MTU sizes that 330 allow for the header expansion (i.e. at least 1280 + 40 (outer IP 331 header) + SRH_MAX_SIZE), where SRH_MAX_SIZE is the maximum path 332 length for a given RPL network. To take advantage of this, however, 333 the communicating endpoints need to be aware of the MTU along the 334 path (i.e. through Path MTU Discovery). Unfortunately, the larger 335 MTU size may not be available on all links (e.g. 1280 octets on 336 6LoWPAN links). However, it is expected that much of the traffic on 337 these types of networks consists of much smaller messages than the 338 MTU, so performance degradation through fragmentation would be 339 limited. 341 4.2. Processing Source Routing Headers 343 As specified in [RFC2460], a routing header is not examined or 344 processed until it reaches the node identified in the Destination 345 Address field of the IPv6 header. In that node, dispatching on the 346 Next Header field of the immediately preceding header causes the 347 Routing header module to be invoked. 349 The function of SRH is intended to be very similar to IPv4's Strict 350 Source and Record Route option [RFC0791]. After the routing header 351 has been processed and the IPv6 datagram resubmitted to the IPv6 352 module for processing, the IPv6 Destination Address contains the next 353 hop's address. When forwarding an IPv6 datagram that contains a SRH 354 with a non-zero Segments Left value, if the IPv6 Destination Address 355 is not on-link, a router SHOULD send an ICMP Destination Unreachable 356 (ICMPv6 Type 1) message with ICMPv6 Code set to (TBD by IANA) to the 357 packet's Source Address. This ICMPv6 Code indicates that the IPv6 358 Destination Address is not on-link and the router cannot satisfy the 359 strict source route requirement. When generating ICMPv6 error 360 messages, the rules in Section 2.4 of [RFC4443] must be observed. 362 To detect loops in the SRH, a router MUST determine if the SRH 363 includes multiple addresses assigned to any interface on that router. 364 If such addresses appear more than once and are separated by at least 365 one address not assigned to that router, the router MUST drop the 366 packet and SHOULD send an ICMP Parameter Problem, Code 0, to the 367 Source Address. While this loop check does add significant per- 368 packet processing overhead, it is required to mitigate traffic 369 amplification attacks that led to the deprecation of RH0 [RFC5095]. 371 The following describes the algorithm performed when processing a 372 SRH: 374 if Segments Left = 0 { 375 proceed to process the next header in the packet, whose type is 376 identified by the Next Header field in the Routing header 377 } 378 else { 379 compute n, the number of addresses in the Routing header, by 380 n = (((Hdr Ext Len * 8) - Pad - (16 - CmprE)) / (16 - CmprI)) + 1 382 if Segments Left is greater than n { 383 send an ICMP Parameter Problem, Code 0, message to the Source 384 Address, pointing to the Segments Left field, and discard the 385 packet 386 } 387 else { 388 decrement Segments Left by 1; 389 compute i, the index of the next address to be visited in 390 the address vector, by subtracting Segments Left from n 392 if Address[i] or the IPv6 Destination Address is multicast { 393 discard the packet 394 } 395 else if 2 or more entries in Address[1..n] are assigned to 396 local interface and are separated by at least one 397 address not assigned to local interface { 398 send an ICMP Parameter Problem (Code 0) and discard the 399 packet 400 } 401 else { 402 swap the IPv6 Destination Address and Address[i] 404 if the IPv6 Hop Limit is less than or equal to 1 { 405 send an ICMP Time Exceeded -- Hop Limit Exceeded in 406 Transit message to the Source Address and discard the 407 packet 408 } 409 else { 410 decrement the Hop Limit by 1 412 resubmit the packet to the IPv6 module for transmission 413 to the new destination 414 } 415 } 416 } 417 } 419 5. RPL Border Router Behavior 421 RPL Border Routers (referred to as LBRs in 422 [I-D.ietf-roll-terminology]) are responsible for ensuring that a SRH 423 is only used within the RPL domain it was created. 425 For datagrams destined to the RPL Border Router, the router processes 426 the packet in the usual way. For instance, if the SRH was included 427 using tunneled mode and the RPL Border Router serves as the tunnel 428 endpoint, the router removes the outer IPv6 header, at the same time 429 removing the SRH as well. 431 Datagrams destined elsewhere within the same RPL domain are forwarded 432 to the correct interface. 434 Datagrams destined to nodes outside the RPL domain are dropped if the 435 outer-most IPv6 header contains a SRH. 437 6. Security Considerations 439 6.1. Source Routing Attacks 441 [RFC5095] deprecates the Type 0 Routing header due to a number of 442 significant attacks that are referenced in that document. Such 443 attacks include network discovery, bypassing filtering devices, 444 denial-of-service, and defeating anycast. 446 Because this document specifies that SRH is only for use within a RPL 447 domain, such attacks cannot be mounted from outside the RPL domain. 448 As described in Section 5, RPL Border Routers MUST drop datagrams 449 entering or exiting the RPL domain that contain a SRH in the IPv6 450 Extension headers. Furthermore, it is RECOMMENDED that non-RPL 451 routers and firewalls drop packets with a SRH by default. 453 6.2. ICMPv6 Attacks 455 The generation of ICMPv6 error messages may be used to attempt 456 denial-of-service attacks by sending error-causing SRH in back-to- 457 back datagrams. An implementation that correctly follows Section 2.4 458 of [RFC4443] would be protected by the ICMPv6 rate limiting 459 mechanism. 461 7. IANA Considerations 463 This document defines a new IPv6 Routing Type of TBD by IANA. 465 This document defines a new ICMPv6 Destination Unreachable Code of 466 TBD by IANA to indicate that the router cannot satisfy the strict 467 source-route requirement. 469 8. Acknowledgements 471 The authors thank Jari Arkko, Richard Kelsey, Suresh Krishnan, Erik 472 Nordmark, Pascal Thubert, and Tim Winter for their comments and 473 suggestions that helped shape this document. 475 9. Changes 477 (This section to be removed by the RFC editor.) 479 Draft 04: 481 - Updated text on recommendations for avoiding fragmentation. 483 - Clarify definition of CmprE where it is first mentioned. 485 - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. 487 - Update packet processing pseudocode to match the text on sending 488 back a parameter problem error. 490 - Recommend that non-RPL devices drop packets with SRH by default. 492 - Clarify packet structure figures. 494 - State that checking for cycles represents significant per-packet 495 processing. 497 Draft 03: 499 - Removed any presumed values that are TBD by IANA. 501 Draft 02: 503 - Updated to send ICMP Destination Unreachable error only after 504 the SRH has been processed. 506 - Updated pseudocode to reflect encoding changes in draft-01. 508 - Allow multiple addresses assigned to same node as long as they 509 are not separated by other addresses. 511 Draft 01: 513 - Allow Addresses[1..n-1] and Addresses[n] to have a different 514 number of bytes elided. 516 10. References 518 10.1. Normative References 520 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 521 September 1981. 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, March 1997. 526 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 527 (IPv6) Specification", RFC 2460, December 1998. 529 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 530 IPv6 Specification", RFC 2473, December 1998. 532 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 533 Message Protocol (ICMPv6) for the Internet Protocol 534 Version 6 (IPv6) Specification", RFC 4443, March 2006. 536 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 537 of Type 0 Routing Headers in IPv6", RFC 5095, 538 December 2007. 540 10.2. Informative References 542 [I-D.hui-6man-rpl-headers] 543 Hui, J., Thubert, P., and J. Vasseur, "Using RPL Headers 544 Without IP-in-IP", draft-hui-6man-rpl-headers-00 (work in 545 progress), July 2010. 547 [I-D.ietf-roll-rpl] 548 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 549 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 550 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 551 Lossy Networks", draft-ietf-roll-rpl-19 (work in 552 progress), March 2011. 554 [I-D.ietf-roll-terminology] 555 Vasseur, J., "Terminology in Low power And Lossy 556 Networks", draft-ietf-roll-terminology-06 (work in 557 progress), September 2011. 559 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 560 an On-line Database", RFC 3232, January 2002. 562 Authors' Addresses 564 Jonathan W. Hui 565 Arch Rock Corporation 566 501 2nd St. Ste. 410 567 San Francisco, California 94107 568 USA 570 Phone: +415 692 0828 571 Email: jhui@archrock.com 573 JP Vasseur 574 Cisco Systems, Inc 575 11, Rue Camille Desmoulins 576 Issy Les Moulineaux, 92782 577 France 579 Email: jpv@cisco.com 581 David E. Culler 582 UC Berkeley 583 465 Soda Hall 584 Berkeley, California 94720 585 USA 587 Phone: +510 643 7572 588 Email: culler@cs.berkeley.edu 590 Vishwas Manral 591 IP Infusion 592 Bamankhola, Bansgali 593 Almora, Uttarakhand 263601 594 India 596 Phone: +91-98456-61911 597 Email: vishwas@ipinfusion.com