idnits 2.17.1 draft-ietf-6man-rpl-routing-header-02.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 13, 2011) is 4790 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 (-19) exists of draft-ietf-roll-rpl-18 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-04 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: September 14, 2011 Cisco Systems, Inc 6 D. Culler 7 UC Berkeley 8 V. Manral 9 IP Infusion 10 March 13, 2011 12 An IPv6 Routing Header for Source Routes with RPL 13 draft-ietf-6man-rpl-routing-header-02 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 14, 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 Type 4 Routing Headers . . . . . . . . . . . . 9 69 4.2. Processing Type 4 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 Type 4 Routing header (RH4) (to be 104 confirmed by IANA) for use 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 RH4 draws from that of the Type 0 Routing header (RH0) 115 [RFC2460]. However, RH4 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 RH4, a typical scenario in 118 LLNs using source routing. The compaction mechanism reduces 119 consumption of scarce resources such as channel capacity. 121 RH4 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 RH4 MUST implement a strict source route 124 policy where each and every IPv6 hop is specified within the datagram 125 itself. Second, a RH4 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 RH4 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 RH4. There are two cases that determine how 135 to include an RH4 with a datagram. 137 1. If the RH4 specifies the complete path from source to 138 destination, the RH4 should be included directly within the 139 datagram itself. 141 2. If the RH4 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 RH4 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 RH4 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 RH4 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 | RH4 | 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 RH4 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 RH4. 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 RH4 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 | RH4 | Src | Dst | Payload | 199 +------+------+------+------+------+--------//-+ 200 <--- Original Packet ---> 202 <--- Tunneled Packet ---> 204 Note that the outer header (including the RH4) 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 RH4 using tunneled-mode, the Border 212 Router would encapsulate the received datagram unmodified using IPv6- 213 in-IPv6 and include a RH4 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 RH4. BR1 encapsulates received datagrams 229 unmodified using IPv6-in-IPv6 and the RH4 is included in the outer 230 IPv6 header. 232 To help avoid IP-layer fragmentation, the RH4 header has a maximum 233 size of RH4_MAX_SIZE octets and links within a RPL domain SHOULD have 234 a MTU of at least 1280 + 40 (outer IP header) + RH4_MAX_SIZE (+ 235 additional extension headers or options needed within RPL domain) 236 octets. 238 3. Format of the RPL Routing Header 240 The Type 4 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=4| 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 RH4_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. Set to 4 (to be confirmed by 270 IANA). 272 Segments Left 8-bit unsigned integer. Number of route segments 273 remaining, i.e., number of explicitly listed 274 intermediate nodes still to be visited before 275 reaching the final destination. 277 CmprI 4-bit unsigned integer. Number of prefix octets 278 from each segment, except than the last segment, 279 that are elided. For example, a Type 4 Routing 280 header carrying full IPv6 addresses in 281 Addresses[1..n-1] sets CmprI to 0. 283 CmprE 4-bit unsigned integer. Number of prefix octets 284 from the segment that are elided. For example, a 285 Type 4 Routing header carrying a full IPv6 286 address in Addresses[n] sets CmprE to 0. 288 Pad 4-bit unsigned integer. Number of octets that 289 are used for padding after Address[n] at the end 290 of the Type 4 Routing header. 292 Address[1..n] Vector of addresses, numbered 1 to n. Each 293 vector element in [1..n-1] has size (16 - CmprI) 294 and element [n] has size (16-CmprE). 296 The Type 4 Routing header shares the same basic format as the Type 0 297 Routing header [RFC2460]. When carrying full IPv6 addresses, the 298 CmprI, CmprE, and Pad fields are set to 0 and the only difference 299 between the Type 4 and Type 0 encodings is the value of the Routing 300 Type field. 302 A common network configuration for a RPL domain is that all nodes 303 within a LLN share a common prefix. Type 4 Routing header introduces 304 the CmprI, CmprE, and Pad fields to allow compaction of the 305 Address[1..n] vector when all entries share the same prefix as the 306 IPv6 Destination Address field of the packet carrying the RH4. The 307 CmprI and CmprE field indicates the number of prefix octets that are 308 shared with the IPv6 Destination Address of the packet carrying the 309 RH4. The shared prefix octets are not carried within the Routing 310 header and each entry in Address[1..n-1] has size (16 - CmprI) octets 311 and Address[n] has size (16 - CmprE) octets. When CmprI or CmprE is 312 non-zero, there may exist unused octets between the last entry, 313 Address[n], and the end of the Routing header. The Pad field 314 indicates the number of unused octets that are used for padding. 315 Note that when CmprI and CmprE are both 0, Pad MUST carry a value of 316 0. 318 The Type 4 Routing header MUST NOT specify a path that visits a node 319 more than once. When generating a Type 4 Routing header, the source 320 may not know the mapping between IPv6 addresses and nodes. 321 Minimally, the source MUST ensure that IPv6 Addresses do not appear 322 more than once and the IPv6 Source and Destination addresses of the 323 encapsulating datagram do not appear in the Type 4 Routing header. 325 Multicast addresses MUST NOT appear in a Type 4 Routing header, or in 326 the IPv6 Destination Address field of a datagram carrying a Type 4 327 Routing header. 329 4. RPL Router Behavior 331 4.1. Generating Type 4 Routing Headers 333 To deliver an IPv6 datagram to its destination, a router may need to 334 generate a new Type 4 Routing header and specify a strict source 335 route. Routers SHOULD use IPv6-in-IPv6 tunneling, as specified in 336 [RFC2473] to include a new Type 4 Routing header in datagrams that 337 are sourced by other nodes. Using IPv6-in-IPv6 tunneling ensures 338 that the delivered datagram remains unmodified and that ICMPv6 errors 339 generated by a Type 4 Routing header are sent back to the router that 340 generated the routing header. 342 Performing IP-in-IP encapsulation may grow the datagram to a size 343 larger than the IPv6 min MTU of 1280 octets. To help avoid IP-layer 344 fragmentation caused by IP-in-IP encapsulation, links within a RPL 345 domain SHOULD be configured with a MTU of at least 1280 + 40 (outer 346 IP header) + RH4_MAX_SIZE (+ additional extension headers or options 347 needed within RPL domain) octets. 349 In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due 350 to the added cost and complexity required to process and carry a 351 datagram with two IPv6 headers. [I-D.hui-6man-rpl-headers] describes 352 how to avoid using IPv6-in-IPv6 tunneling in such specific cases and 353 the risks involved. 355 4.2. Processing Type 4 Routing Headers 357 As specified in [RFC2460], a routing header is not examined or 358 processed until it reaches the node identified in the Destination 359 Address field of the IPv6 header. In that node, dispatching on the 360 Next Header field of the immediately preceding header causes the 361 Routing header module to be invoked. 363 The function of Type 4 Routing header is intended to be very similar 364 to IPv4's Strict Source and Record Route option [RFC0791]. After the 365 routing header has been processed and the IPv6 datagram resubmitted 366 to the IPv6 module for processing, the IPv6 Destination Address 367 contains the next hop's address. When forwarding an IPv6 datagram 368 that contains a RH4 with a non-zero Segments Left value, if the IPv6 369 Destination Address is not on-link, a router SHOULD send an ICMP 370 Destination Unreachable (ICMPv6 Type 1) message with ICMPv6 Code set 371 to 7 (to be confirmed by IANA) to the packet's Source Address. An 372 ICMPv6 Code of 7 indicates that the IPv6 Destination Address is not 373 on-link and the router cannot satisfy the strict source route 374 requirement. When generating ICMPv6 error messages, the rules in 375 Section 2.4 of [RFC4443] must be observed. 377 To detect loops in the Type 4 Routing headers, a router MUST 378 determine if the Type 4 Routing header includes multiple addresses 379 assigned to any interface on that router. If such addresses appear 380 more than once and are separated by at least one address not assigned 381 to that router, the router MUST drop the packet and SHOULD send an 382 ICMP Parameter Problem, Code 0, to the Source Address. 384 The following describes the algorithm performed when processing a 385 Type 4 Routing header: 387 if Segments Left = 0 { 388 proceed to process the next header in the packet, whose type is 389 identified by the Next Header field in the Routing header 390 } 391 else { 392 compute n, the number of addresses in the Routing header, by 393 n = (((Hdr Ext Len * 8) - Pad - (16 - CmprE)) / (16 - CmprI)) + 1 395 if Segments Left is greater than n { 396 send an ICMP Parameter Problem, Code 0, message to the Source 397 Address, pointing to the Segments Left field, and discard the 398 packet 399 } 400 else { 401 decrement Segments Left by 1; 402 compute i, the index of the next address to be visited in 403 the address vector, by subtracting Segments Left from n 405 if Address[i] or the IPv6 Destination Address is multicast { 406 discard the packet 407 } 408 else if 2 or more entries in Address[1..n] are assigned to 409 local interface and are separated by at least one 410 address not assigned to local interface { 411 discard the packet 412 } 413 else { 414 swap the IPv6 Destination Address and Address[i] 416 if the IPv6 Hop Limit is less than or equal to 1 { 417 send an ICMP Time Exceeded -- Hop Limit Exceeded in 418 Transit message to the Source Address and discard the 419 packet 420 } 421 else { 422 decrement the Hop Limit by 1 424 resubmit the packet to the IPv6 module for transmission 425 to the new destination 426 } 427 } 428 } 429 } 431 5. RPL Border Router Behavior 433 RPL Border Routers (referred to as LBRs in 434 [I-D.ietf-roll-terminology]) are responsible for ensuring that a Type 435 4 Routing header is only used within the RPL domain it was created. 437 For datagrams entering the RPL domain, RPL Border Routers MUST drop 438 received datagrams that contain a Type 4 Routing header in the IPv6 439 Extension headers. 441 For datagrams exiting the RPL domain, RPL Border Routers MUST check 442 for a Type 4 Routing header. If Segments Left is 0, the router MUST 443 remove the RH4 from the datagram. If the RH4 was included using 444 tunneled mode and the RPL Border Router serves as the tunnel end- 445 point, removing the outer IPv6 header serves to remove the RH4 as 446 well. Otherwise, the RPL Border Router assumes that the RH4 was 447 included using transport mode and MUST remove the RH4 from the IPv6 448 header. If Segments Left is non-zero, the router MUST drop the 449 datagram. 451 6. Security Considerations 453 6.1. Source Routing Attacks 455 [RFC5095] deprecates the Type 0 Routing header due to a number of 456 significant attacks that are referenced in that document. Such 457 attacks include network discovery, bypassing filtering devices, 458 denial-of-service, and defeating anycast. 460 The RPL specification states that only Type 4 Routing Headers are 461 valid. Therefore, RPL domains are not vunerable to attacks using 462 Type 0 routing headers. Additionally, RPL Border Routers drop 463 datagrams entering or exiting the RPL domain that contain a Type 4 464 Routing header in the IPv6 Extension headers (see Section 5). 466 6.2. ICMPv6 Attacks 468 The generation of ICMPv6 error messages may be used to attempt 469 denial-of-service attacks by sending error-causing Type 4 Routing 470 headers in back-to-back datagrams. An implementation that correctly 471 follows Section 2.4 of [RFC4443] would be protected by the ICMPv6 472 rate limiting mechanism. 474 7. IANA Considerations 476 This document defines a new IPv6 Routing Type of 4 (to be confirmed 477 by IANA). 479 This document defines a new ICMPv6 Destination Unreachable Code of 7 480 (to be confirmed by IANA) to indicate that the router cannot satisfy 481 the strict source-route requirement. 483 8. Protocol Constants 485 RH4_MAX_SIZE 136 487 With a base header size of 8 octets, 136 octets will allow for up to 488 8 16-octet address entries in the Type 4 Routing header. More 489 entries are possible within 136 octets when compression is used. 491 9. Acknowledgements 493 The authors thank Richard Kelsey, Suresh Krishnan, Erik Nordmark, 494 Pascal Thubert, Tim Winter and Adrian Farrel for their comments and 495 suggestions that helped shape this document. 497 10. Changes 499 (This section to be removed by the RFC editor.) 501 Draft 02: 503 - Updated to send ICMP Destination Unreachable error only after 504 the RH4 has been processed. 506 - Updated psuedocode 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 11. References 518 11.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 11.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-18 (work in 552 progress), February 2011. 554 [I-D.ietf-roll-terminology] 555 Vasseur, J., "Terminology in Low power And Lossy 556 Networks", draft-ietf-roll-terminology-04 (work in 557 progress), September 2010. 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