idnits 2.17.1 draft-ietf-6man-rpl-routing-header-03.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 (March 29, 2011) is 4777 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-05 Summary: 1 error (**), 0 flaws (~~), 2 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: September 30, 2011 Cisco Systems, Inc 6 D. Culler 7 UC Berkeley 8 V. Manral 9 IP Infusion 10 March 29, 2011 12 An IPv6 Routing Header for Source Routes with RPL 13 draft-ietf-6man-rpl-routing-header-03 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 September 30, 2011. 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. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 15 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 77 10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 80 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 83 1. Introduction 85 Routing for Low Power and Lossy Networks (RPL) is a distance vector 86 IPv6 routing protocol designed for Low Power and Lossy networks (LLN) 87 [I-D.ietf-roll-rpl]. Such networks are typically constrained in 88 resources (limited communication data rate, processing power, energy 89 capacity, memory). In particular, some LLN configurations may 90 utilize LLN routers where memory constraints limit nodes to 91 maintaining only a small number of default routes and no other 92 destinations. However, it may be necessary to utilize such memory- 93 constrained routers to forward datagrams and maintain reachability to 94 destinations within the LLN. 96 To utilize paths that include memory-constrained routers, RPL relies 97 on source routing. In one deployment model of RPL, necessary 98 mechanisms are used to collect routing information at more capable 99 routers and form paths from those routers to arbitrary destinations 100 within the RPL domain. However, a source routing mechanism supported 101 by IPv6 is needed to deliver datagrams. 103 This document specifies the Source Routing Header (SRH) for use 104 strictly within a RPL domain. 106 1.1. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 2. Overview 114 The format of SRH draws from that of the Type 0 Routing header (RH0) 115 [RFC2460]. However, SRH introduces mechanisms to compact the source 116 route entries when all entries share the same prefix with the IPv6 117 Destination Address of a packet carrying a SRH, a typical scenario in 118 LLNs using source routing. The compaction mechanism reduces 119 consumption of scarce resources such as channel capacity. 121 SRH also differs from RH0 in the processing rules to alleviate 122 security concerns that lead to the deprecation of RH0 [RFC5095]. 123 First, routers processing SRH MUST implement a strict source route 124 policy where each and every IPv6 hop is specified within the datagram 125 itself. Second, a SRH header MUST only be used within a RPL domain. 126 RPL Border Routers, responsible for connecting RPL domains and IP 127 domains that use other routing protocols, MUST NOT allow datagrams 128 already carrying a SRH header to enter or exit the RPL domain. 129 Third, to avoid some attacks that lead to the deprecation of RH0, 130 routers along the way MUST verify that loops do not exist with in the 131 source route. 133 To deliver a datagram, a router MAY specify a source route to reach 134 the destination using a SRH. There are two cases that determine how 135 to include an SRH with a datagram. 137 1. If the SRH specifies the complete path from source to 138 destination, the SRH should be included directly within the 139 datagram itself. 141 2. If the SRH only specifies a subset of the path from source to 142 destination, router SHOULD use IPv6-in-IPv6 tunneling, as 143 specified in [RFC2473]. When tunneling, the router MUST prepend 144 a new IPv6 header and SRH to the original datagram. Use of 145 tunneling ensures that the datagram is delivered unmodified and 146 that ICMP errors return to the source of the SRH rather than the 147 source of the original datagram. 149 In a RPL network, Case 1 occurs when both source and destinations are 150 within a RPL domain and a single SRH header is used to specify the 151 entire path from source to destination, as shown in the following 152 figure: 154 +--------------------+ 155 | | 156 | (S) -------> (D) | 157 | | 158 +--------------------+ 159 RPL Domain 161 In the above scenario, datagrams traveling from source, S, to 162 destination, D, have the following packet structure: 164 +------+------+------+--------//-+ 165 | IPv6 | IPv6 | IPv6 | Packet | 166 | Src | Dst | SRH | Payload | 167 +------+------+------+--------//-+ 169 S's address is carried in the IPv6 Source Address field. D's address 170 is carried in the last entry of SRH for all but the last hop, when 171 D's address is carried in the IPv6 Destination Address field of the 172 packet carrying the SRH. 174 In a RPL network, Case 2 occurs for all datagrams that have either 175 source or destination outside the RPL domain, as shown in the 176 following diagram: 178 +-----------------+ 179 | | 180 | (S) -------> (BR1) -------> (D) 181 | | 182 +-----------------+ 183 RPL Domain 185 +-----------------+ 186 | | 187 | (D) <------- (BR1) <------- (S) 188 | | 189 +-----------------+ 190 RPL Domain 192 In the above scenario, datagrams that include the SRH in tunneled 193 mode have the following packet structure when traveling within the 194 RPL domain: 196 +------+------+------+------+------+--------//-+ 197 | IPv6 | IPv6 | IPv6 | IPv6 | IPv6 | Packet | 198 | Src | Dst | SRH | Src | Dst | Payload | 199 +------+------+------+------+------+--------//-+ 200 <--- Original Packet ---> 202 <--- Tunneled Packet ---> 204 Note that the outer header (including the SRH) is added and removed 205 by the RPL Border Router. 207 Case 2 also occurs whenever a RPL router needs to insert a source 208 route when forwarding datagram. One such use case with RPL is to 209 have all RPL traffic flow through a Border Router and have the Border 210 Router use source routes to deliver datagrams to their final 211 destination. When including the SRH using tunneled-mode, the Border 212 Router would encapsulate the received datagram unmodified using IPv6- 213 in-IPv6 and include a SRH in the outer IPv6 header. 215 +-----------------+ 216 | | 217 | (S) -------\ | 218 | \ | 219 | (BR1) 220 | / | 221 | (D) <------/ | 222 | | 223 +-----------------+ 224 RPL Domain 226 In the above scenario, datagrams travel from S to D through BR1. 227 Between S and BR1, the datagrams are routed using the DAG built by 228 RPL and do not contain a SRH. BR1 encapsulates received datagrams 229 unmodified using IPv6-in-IPv6 and the SRH is included in the outer 230 IPv6 header. 232 To help avoid IP-layer fragmentation, the SRH header has a maximum 233 size of SRH_MAX_SIZE octets and links within a RPL domain SHOULD have 234 a MTU of at least 1280 + 40 (outer IP header) + SRH_MAX_SIZE (+ 235 additional extension headers or options needed within RPL domain) 236 octets. 238 3. Format of the RPL Routing Header 240 The Source Routing Header has the following format: 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | CmprI | CmprE | Pad | Reserved | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | 250 . . 251 . Addresses[1..n] . 252 . . 253 | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Next Header 8-bit selector. Identifies the type of header 257 immediately following the Routing header. Uses 258 the same values as the IPv4 Protocol field 259 [RFC3232]. 261 Hdr Ext Len 8-bit unsigned integer. Length of the Routing 262 header in 8-octet units, not including the first 263 8 octets. Hdr Ext Len MUST NOT exceed 264 SRH_MAX_SIZE / 8. Note that when Addresses[1..n] 265 are compressed (i.e. value of CmprI or CmprE is 266 not 0), Hdr Ext Len does not equal twice the 267 number of Addresses. 269 Routing Type 8-bit selector. TBD by IANA. 271 Segments Left 8-bit unsigned integer. Number of route segments 272 remaining, i.e., number of explicitly listed 273 intermediate nodes still to be visited before 274 reaching the final destination. 276 CmprI 4-bit unsigned integer. Number of prefix octets 277 from each segment, except than the last segment, 278 that are elided. For example, a SRH carrying 279 full IPv6 addresses in Addresses[1..n-1] sets 280 CmprI to 0. 282 CmprE 4-bit unsigned integer. Number of prefix octets 283 from the segment that are elided. For example, a 284 SRH carrying a full IPv6 address in Addresses[n] 285 sets CmprE to 0. 287 Pad 4-bit unsigned integer. Number of octets that 288 are used for padding after Address[n] at the end 289 of the SRH. 291 Address[1..n] Vector of addresses, numbered 1 to n. Each 292 vector element in [1..n-1] has size (16 - CmprI) 293 and element [n] has size (16-CmprE). 295 The SRH shares the same basic format as the Type 0 Routing header 296 [RFC2460]. When carrying full IPv6 addresses, the CmprI, CmprE, and 297 Pad fields are set to 0 and the only difference between the SRH and 298 Type 0 encodings is the value of the Routing Type field. 300 A common network configuration for a RPL domain is that all nodes 301 within a LLN share a common prefix. The SRH introduces the CmprI, 302 CmprE, and Pad fields to allow compaction of the Address[1..n] vector 303 when all entries share the same prefix as the IPv6 Destination 304 Address field of the packet carrying the SRH. The CmprI and CmprE 305 field indicates the number of prefix octets that are shared with the 306 IPv6 Destination Address of the packet carrying the SRH. The shared 307 prefix octets are not carried within the Routing header and each 308 entry in Address[1..n-1] has size (16 - CmprI) octets and Address[n] 309 has size (16 - CmprE) octets. When CmprI or CmprE is non-zero, there 310 may exist unused octets between the last entry, Address[n], and the 311 end of the Routing header. The Pad field indicates the number of 312 unused octets that are used for padding. Note that when CmprI and 313 CmprE are both 0, Pad MUST carry a value of 0. 315 The SRH MUST NOT specify a path that visits a node more than once. 316 When generating a SRH, the source may not know the mapping between 317 IPv6 addresses and nodes. Minimally, the source MUST ensure that 318 IPv6 Addresses do not appear more than once and the IPv6 Source and 319 Destination addresses of the encapsulating datagram do not appear in 320 the SRH. 322 Multicast addresses MUST NOT appear in a SRH, or in the IPv6 323 Destination Address field of a datagram carrying a SRH. 325 4. RPL Router Behavior 327 4.1. Generating Source Routing Headers 329 To deliver an IPv6 datagram to its destination, a router may need to 330 generate a new SRH and specify a strict source route. Routers SHOULD 331 use IPv6-in-IPv6 tunneling, as specified in [RFC2473] to include a 332 new SRH in datagrams that are sourced by other nodes. Using IPv6-in- 333 IPv6 tunneling ensures that the delivered datagram remains unmodified 334 and that ICMPv6 errors generated by a SRH are sent back to the router 335 that generated the routing header. 337 Performing IP-in-IP encapsulation may grow the datagram to a size 338 larger than the IPv6 min MTU of 1280 octets. To help avoid IP-layer 339 fragmentation caused by IP-in-IP encapsulation, links within a RPL 340 domain SHOULD be configured with a MTU of at least 1280 + 40 (outer 341 IP header) + SRH_MAX_SIZE (+ additional extension headers or options 342 needed within RPL domain) octets. 344 In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due 345 to the added cost and complexity required to process and carry a 346 datagram with two IPv6 headers. [I-D.hui-6man-rpl-headers] describes 347 how to avoid using IPv6-in-IPv6 tunneling in such specific cases and 348 the risks involved. 350 4.2. Processing Source Routing Headers 352 As specified in [RFC2460], a routing header is not examined or 353 processed until it reaches the node identified in the Destination 354 Address field of the IPv6 header. In that node, dispatching on the 355 Next Header field of the immediately preceding header causes the 356 Routing header module to be invoked. 358 The function of SRH is intended to be very similar to IPv4's Strict 359 Source and Record Route option [RFC0791]. After the routing header 360 has been processed and the IPv6 datagram resubmitted to the IPv6 361 module for processing, the IPv6 Destination Address contains the next 362 hop's address. When forwarding an IPv6 datagram that contains a SRH 363 with a non-zero Segments Left value, if the IPv6 Destination Address 364 is not on-link, a router SHOULD send an ICMP Destination Unreachable 365 (ICMPv6 Type 1) message with ICMPv6 Code set to (TBD by IANA) to the 366 packet's Source Address. This ICMPv6 Code indicates that the IPv6 367 Destination Address is not on-link and the router cannot satisfy the 368 strict source route requirement. When generating ICMPv6 error 369 messages, the rules in Section 2.4 of [RFC4443] must be observed. 371 To detect loops in the SRH, a router MUST determine if the SRH 372 includes multiple addresses assigned to any interface on that router. 374 If such addresses appear more than once and are separated by at least 375 one address not assigned to that router, the router MUST drop the 376 packet and SHOULD send an ICMP Parameter Problem, Code 0, to the 377 Source Address. 379 The following describes the algorithm performed when processing a 380 SRH: 382 if Segments Left = 0 { 383 proceed to process the next header in the packet, whose type is 384 identified by the Next Header field in the Routing header 385 } 386 else { 387 compute n, the number of addresses in the Routing header, by 388 n = (((Hdr Ext Len * 8) - Pad - (16 - CmprE)) / (16 - CmprI)) + 1 390 if Segments Left is greater than n { 391 send an ICMP Parameter Problem, Code 0, message to the Source 392 Address, pointing to the Segments Left field, and discard the 393 packet 394 } 395 else { 396 decrement Segments Left by 1; 397 compute i, the index of the next address to be visited in 398 the address vector, by subtracting Segments Left from n 400 if Address[i] or the IPv6 Destination Address is multicast { 401 discard the packet 402 } 403 else if 2 or more entries in Address[1..n] are assigned to 404 local interface and are separated by at least one 405 address not assigned to local interface { 406 discard the packet 407 } 408 else { 409 swap the IPv6 Destination Address and Address[i] 411 if the IPv6 Hop Limit is less than or equal to 1 { 412 send an ICMP Time Exceeded -- Hop Limit Exceeded in 413 Transit message to the Source Address and discard the 414 packet 415 } 416 else { 417 decrement the Hop Limit by 1 419 resubmit the packet to the IPv6 module for transmission 420 to the new destination 421 } 422 } 423 } 424 } 426 5. RPL Border Router Behavior 428 RPL Border Routers (referred to as LBRs in 429 [I-D.ietf-roll-terminology]) are responsible for ensuring that a SRH 430 is only used within the RPL domain it was created. 432 For datagrams entering the RPL domain, RPL Border Routers MUST drop 433 received datagrams that contain a SRH in the IPv6 Extension headers. 435 For datagrams exiting the RPL domain, RPL Border Routers MUST check 436 for a SRH. If Segments Left is 0, the router MUST remove the SRH 437 from the datagram. If the SRH was included using tunneled mode and 438 the RPL Border Router serves as the tunnel end-point, removing the 439 outer IPv6 header serves to remove the SRH as well. Otherwise, the 440 RPL Border Router assumes that the SRH was included using transport 441 mode and MUST remove the SRH from the IPv6 header. If Segments Left 442 is non-zero, the router MUST drop the datagram. 444 6. Security Considerations 446 6.1. Source Routing Attacks 448 [RFC5095] deprecates the Type 0 Routing header due to a number of 449 significant attacks that are referenced in that document. Such 450 attacks include network discovery, bypassing filtering devices, 451 denial-of-service, and defeating anycast. 453 Because this document specifies that SRH is only for use within a RPL 454 domain, such attacks cannot be mounted from outside the RPL domain. 455 As described in Section 5, RPL Border Routers MUST drop datagrams 456 entering or exiting the RPL domain that contain a SRH in the IPv6 457 Extension headers. 459 6.2. ICMPv6 Attacks 461 The generation of ICMPv6 error messages may be used to attempt 462 denial-of-service attacks by sending error-causing SRH in back-to- 463 back datagrams. An implementation that correctly follows Section 2.4 464 of [RFC4443] would be protected by the ICMPv6 rate limiting 465 mechanism. 467 7. IANA Considerations 469 This document defines a new IPv6 Routing Type of TBD by IANA. 471 This document defines a new ICMPv6 Destination Unreachable Code of 472 TBD by IANA to indicate that the router cannot satisfy the strict 473 source-route requirement. 475 8. Protocol Constants 477 SRH_MAX_SIZE 136 479 With a base header size of 8 octets, 136 octets will allow for up to 480 8 16-octet address entries in the SRH. More entries are possible 481 within 136 octets when compression is used. 483 9. Acknowledgements 485 The authors thank Richard Kelsey, Suresh Krishnan, Erik Nordmark, 486 Pascal Thubert, and Tim Winter for their comments and suggestions 487 that helped shape this document. 489 10. Changes 491 (This section to be removed by the RFC editor.) 493 Draft 03: 495 - Removed any presumed values that are TBD by IANA. 497 Draft 02: 499 - Updated to send ICMP Destination Unreachable error only after 500 the SRH has been processed. 502 - Updated psuedocode to reflect encoding changes in draft-01. 504 - Allow multiple addresses assigned to same node as long as they 505 are not separated by other addresses. 507 Draft 01: 509 - Allow Addresses[1..n-1] and Addresses[n] to have a different 510 number of bytes elided. 512 11. References 514 11.1. Normative References 516 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 517 September 1981. 519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 520 Requirement Levels", BCP 14, RFC 2119, March 1997. 522 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 523 (IPv6) Specification", RFC 2460, December 1998. 525 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 526 IPv6 Specification", RFC 2473, December 1998. 528 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 529 Message Protocol (ICMPv6) for the Internet Protocol 530 Version 6 (IPv6) Specification", RFC 4443, March 2006. 532 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 533 of Type 0 Routing Headers in IPv6", RFC 5095, 534 December 2007. 536 11.2. Informative References 538 [I-D.hui-6man-rpl-headers] 539 Hui, J., Thubert, P., and J. Vasseur, "Using RPL Headers 540 Without IP-in-IP", draft-hui-6man-rpl-headers-00 (work in 541 progress), July 2010. 543 [I-D.ietf-roll-rpl] 544 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 545 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 546 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 547 Lossy Networks", draft-ietf-roll-rpl-19 (work in 548 progress), March 2011. 550 [I-D.ietf-roll-terminology] 551 Vasseur, J., "Terminology in Low power And Lossy 552 Networks", draft-ietf-roll-terminology-05 (work in 553 progress), March 2011. 555 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 556 an On-line Database", RFC 3232, January 2002. 558 Authors' Addresses 560 Jonathan W. Hui 561 Arch Rock Corporation 562 501 2nd St. Ste. 410 563 San Francisco, California 94107 564 USA 566 Phone: +415 692 0828 567 Email: jhui@archrock.com 569 JP Vasseur 570 Cisco Systems, Inc 571 11, Rue Camille Desmoulins 572 Issy Les Moulineaux, 92782 573 France 575 Email: jpv@cisco.com 577 David E. Culler 578 UC Berkeley 579 465 Soda Hall 580 Berkeley, California 94720 581 USA 583 Phone: +510 643 7572 584 Email: culler@cs.berkeley.edu 586 Vishwas Manral 587 IP Infusion 588 Bamankhola, Bansgali 589 Almora, Uttarakhand 263601 590 India 592 Phone: +91-98456-61911 593 Email: vishwas@ipinfusion.com