idnits 2.17.1 draft-hui-6lowpan-nd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 736. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 747. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 754. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 760. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 28, 2008) is 5751 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: 'ieee802.15.4' is defined on line 695, but no explicit reference was found in the text == Unused Reference: 'I-D.hui-6lowpan-hc' is defined on line 706, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802.15.4' == Outdated reference: A later version (-01) exists of draft-hui-6lowpan-hc-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hui 3 Internet-Draft Arch Rock Corporation 4 Intended status: Standards Track July 28, 2008 5 Expires: January 29, 2009 7 Neighbor Discovery and Autoconfiguration for Route-Over 6LoWPAN Networks 8 draft-hui-6lowpan-nd-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 29, 2009. 35 Abstract 37 This document specifies a simple version of IPv6 Neighbor Discovery 38 for route-over 6LoWPAN networks. 6LoWPAN ND allows nodes to discover 39 routers, discover network configuration parameters, and IPv6 prefixes 40 for use with stateless address autoconfiguration and context-based 41 6LoWPAN compression for IPv6 headers. This document also specifies 42 autoconfiguration mechanism for use in 6LoWPAN networks. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 48 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 49 3.1. Addressing and Prefix Model . . . . . . . . . . . . . . . 6 50 3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . 6 51 3.3. Autoconfiguration . . . . . . . . . . . . . . . . . . . . 8 52 4. 6LoWPAN ND Message Formats . . . . . . . . . . . . . . . . . . 10 53 4.1. Router Solicitation . . . . . . . . . . . . . . . . . . . 10 54 4.2. Router Advertisement . . . . . . . . . . . . . . . . . . . 11 55 4.3. Prefix Information Option . . . . . . . . . . . . . . . . 12 56 4.4. Prefix Summary Option . . . . . . . . . . . . . . . . . . 13 57 5. DHCPv6 Option Formats . . . . . . . . . . . . . . . . . . . . 15 58 5.1. DHCPv6 IA_6LOWPAN Option . . . . . . . . . . . . . . . . . 15 59 5.2. IA_6LOWPAN Prefix Option . . . . . . . . . . . . . . . . . 16 60 5.3. IA_6LOWPAN Local Interface Identifier Option . . . . . . . 16 61 6. Router and Prefix Discovery . . . . . . . . . . . . . . . . . 18 62 7. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 19 63 7.1. Stateless Autoconfiguration . . . . . . . . . . . . . . . 19 64 7.2. DHCPv6 Autoconfiguration . . . . . . . . . . . . . . . . . 19 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 68 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 69 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 71 Intellectual Property and Copyright Statements . . . . . . . . . . 24 73 1. Introduction 75 This document specifies the mechanisms necessary to configure a 76 route-over IPv6/6LoWPAN network. In a route-over configuration, the 77 link-local scope is defined by the radio transmission range. This is 78 in contrast to a mesh-under configuration where the link-local scope 79 is defined by the boundaries of the PAN and includes all nodes 80 within. Compared to mesh-under, a route-over configuration gives 81 nodes IP-level visibility into the underlying radio connectivity. 82 Using link-local addresses, nodes can address and communicate to 83 their radio neighbors directly without requiring any routing support. 84 Nodes can also communicate with their radio neighbors using link- 85 local multicast addresses. However, the underlying link-layer power 86 management protocol may preclude the use of broadcast operations. In 87 either case, the underlying link does not guarantee reflexive or 88 transitive reachability (as defined in [RFC4861]). For both route- 89 over and mesh-under, we assume that global routing prefixes used to 90 configure IPv6 addresses will often be assigned to all nodes in a 91 PAN. 93 6LoWPAN networks differ from traditional IPv6 networks in their 94 available resources. Nodes are often powered using autonomous power 95 sources with limited capacity. The IEEE 802.15.4 link supports up to 96 250 kbps with a 128 byte MTU, including the length byte. 97 Furthermore, due to the nature of wireless communication, nodes 98 within radio transmission range must share the wireless medium. 99 Microcontrollers typically coupled with IEEE 802.15.4 radios are also 100 limited in memory (typically less than 8KB RAM and 64KB ROM) and 101 computation capability (typically around 4MHz). In the most general 102 case, nodes cannot maintain state about all of its radio neighbors. 103 These resource constraints can prohibit many of the IPv6 ND 104 mechanisms specified in [RFC4861]. For example, neighbor 105 unreachability detection requires nodes to continuously communicate 106 with neighboring nodes and address resolution requires communication 107 to resolve the mapping between IPv6 and link-layer addresses. Both 108 also require nodes to maintain per-neighbor state. Duplicate address 109 detection requires nodes to communicate with all other nodes that may 110 utilize the same global routing prefix to configure and IPv6 address. 112 The severe resource constraints motivate us to develop a simplified 113 version of IPv6 ND optimized for 6LoWPAN networks. By making some 114 simplifying assumptions, we can remove the need for many of the 115 mechanisms defined in [RFC4861]. To remove the communication and 116 state requirements for Address Resolution, we require that an IPv6 117 address assigned to a 6LoWPAN interface has an IID derived from a 118 link-layer address. 6LoWPAN Neighbor Discovery assumes that th 119 uniqueness of link-layer addresses is maintained by other mechanisms 120 (e.g, upper-layer mechanisms such as DHCPv6 or lower-layer mechanisms 121 provided by IEEE 802.15.4). By assuming that the uniqueness of link- 122 layer addresses are maintained through other means, we do not require 123 nodes to perform duplicate address detection using neighbor 124 discovery. However, optimistic methods SHOULD be applied through 125 other means (e.g. through routing protocols or other registration 126 mechanisms). 6LoWPAN Neighbor Discovery also does not provide 127 Neighbor Unreachability Detection, expecting that application- 128 specific protocols will be used to discover and maintain reachability 129 with radio neighbors. 131 The basic mechanisms that 6LoWPAN Neighbor Discovery provides are 132 router discovery, prefix discovery, and parameter discovery. This 133 document specifies how to propagate prefix information over multiple 134 hops, for use with context-based header compression and stateless 135 address autoconfiguration. In contrast, IPv6 ND only specifies 136 operation over a single link and does not provide any means to 137 support context-based header compression. 139 This document also specifies address autoconfiguration for route-over 140 6LoWPAN networks. This document specifies a protocol for stateless 141 address autoconfiguration using prefix information carried in Router 142 Advertisements. This document also specifies stateful address 143 autoconfiguration using DHCPv6. 145 2. Terminology 147 6LoWPAN Host 149 A 6LoWPAN node that only sources or sinks IPv6 datagrams. 151 6LoWPAN Router 153 A 6LoWPAN node that forwards datagrams between arbitrary 154 source-destination pairs using a single 6LoWPAN/802.15.4 155 interface. A 6LoWPAN router may also serve as a 6LoWPAN host - 156 both sourcing and sinking IPv6 datagrams. 158 6LoWPAN Border Router 160 A standard IPv6 router that forwards datagrams between 161 different media, at least one of which is a 6LoWPAN/802.15.4 162 interface. 164 Mesh-Under 166 A 6LoWPAN network configuration where the link-local scope is 167 defined by the boundaries of the PAN and includes all nodes 168 within. 170 PAN 172 Personal Area Network. 174 Radio Neighbor 176 A node within radio transmission range. 178 Route-Over 180 A 6LoWPAN network configuration where the link-local scope is 181 defined by those nodes reachable over a single radio 182 transmission. Due to the time-varying characteristics of 183 wireless communication, the neighbor set may change over time 184 even when nodes maintain the same physical locations. 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 3. Overview 192 3.1. Addressing and Prefix Model 194 All IPv6 addresses MUST contain a 64-bit IID derived from IEEE 195 802.15.4 addresses. Either the IEEE EUI-64 or short address combined 196 with the PAN ID may be used to generate an IID, as specified in 197 [RFC4944]. By generating an IID from link-layer addresses, address 198 resolution becomes trivial as appropriate link-layer address can be 199 regenerated from the IID. As a result, no explicit communication is 200 required to resolve mappings between network- and link-layer 201 addresses. Note that the short address can be used go generate local 202 scope interface identifiers. 204 The uniqueness of link-layer addresses MUST be maintained by some 205 mechanism, but MAY be implemented in upper- or lower-layer services. 206 IEEE EUI-64 addresses are assumed to have global scope. Short IEEE 207 802.15.4 addresses may be assigned using link-layer mechanisms (e.g. 208 using an IEEE 802.15.4 PAN Coordinator). The short IEEE 802.15.4 209 addresses may also be derived using information provided in DHCPv6 210 responses when using DHCPv6. 212 6LoWPAN nodes within a PAN generally assign IPv6 addresses that are 213 common to the PA. By assigning the same prefix set, 6LoWPAN nodes 214 can utilize shared context to efficiently compress both source and 215 destination addresses in the IPv6 header. Nodes may autoconfigure 216 IPv6 addresses and compression context using stateless and/or 217 stateful (DHCPv6) mechanisms. 219 No prefix (other than the link-local prefix) may be considered on- 220 link. Because the IPv6 link model does not support transitive 221 reachability, one nodes view of the link-local scope may be different 222 than another node's view of link-local scope. As a result, any 223 prefix assigned to 6LoWPAN interfaces MUST be a /128. 225 6LoWPAN Border Routers route datagrams between different media, one 226 or more of which is a 6LoWPAN interface. Border Routers MUST 227 subscribe to the reserved subnet anycast address for each prefix 228 assigned to the PAN, as described in [RFC4291]. 6LoWPAN nodes can 229 communicate with an arbitrary border router using the reserved subnet 230 router anycast address for any of the global routing prefixes 231 assigned to the PAN. 233 3.2. Neighbor Discovery 235 This protocol addresses the following problems: 237 Router Discovery: How hosts locate routers that reside on an 238 attached link. 240 Prefix Discovery: How hosts discover the set of address prefixes 241 used for Stateless Address Autoconfiguration and 6LoWPAN IPv6 242 Header Compression. 244 Parameter Discovery: How a node learns parameters used for outgoing 245 packets, such as the initial hop limit value. 247 6LoWPAN Neighbor Discovery defines two different ICMP packet types 248 that mirror those used with IPv6 Neighbor Discovery: a Router 249 Advertisement message and a Router Solicitation message. 251 Each 6LoWPAN router periodically multicasts a Router Advertisement 252 message to announce its presence and availability. All 6LoWPAN nodes 253 learn of their presence through Router Advertisements and utilize its 254 containing information to configure themselves. Configured nodes 255 will advertise the latest information in its own Router 256 Advertisements to propagate the information over multiple hops. Note 257 that 6LoWPAN ND allows routers to configure other neighboring 258 routers. In contrast, IPv6 ND only allows routers to configure 259 hosts. While 6LoWPAN ND does not specify a routing protocol, routing 260 information MAY be included in Router Advertisements. 262 Routers manage the transmission period for Router Advertisements 263 using the Trickle algorithm [levis04trickle]. Routers set the 264 transmission period to MIN_RTR_ADVERT_INTERVAL when becoming an 265 advertising interface or there is new information to communicate. 266 After each transmission, the router doubles the transmission period 267 up to a maximum, MAX_RTR_ADVERT_INTERVAL. Given a transmission 268 period, nodes select a random offset by multiplying by a random 269 factor between MIN_RANDOM_FACTOR and MAX_RANDOM_FACTOR. 271 Using a Prefix Information Option, Router Advertisements may contain 272 one or more prefixes for use with 6LoWPAN-based IPv6 header 273 compression and stateless address autoconfiguration - fields within 274 the option indicate the particular uses of the prefix information. 275 Note that unlike IPv6 ND, no prefixes may be designated as on-link. 276 Because prefix information must propagate over multiple hops, the 277 Prefix Information Option includes a sequence number to indicate 278 freshness. Changing the prefix information represents a change in 279 information and the router resets its Router Advertisement 280 transmission period to MIN_RTR_ADVERT_INTERVAL. Nodes MAY include 281 only a subset of the prefix information in a Router Advertisement. 283 Like IPv6 ND, Router Advertisements contain flags that inform hosts 284 how to perform Address Autoconfiguration. Routers can specify 285 whether hosts should use DHCPv6 and/or stateless address 286 autoconfiguration. If DHCPv6 should be used, a flag in the Router 287 Advertisement indicates whether or not the node is acting as a DHCPv6 288 Relay. Advertisements also contain Internet parameters such as the 289 hop limit should use in outgoing packets. 291 Hosts may send Router Solicitations to request neighboring routers to 292 generate Router Advertisements more quickly, rather than waiting 293 until the next scheduled Router Advertisement transmission from those 294 routers. Hosts may either multicast the Router Solicitation to 295 generate Router Advertisements from multiple routers or unicast the 296 Router Solicitation to a particular router. 298 3.3. Autoconfiguration 300 All 6LoWPAN nodes MUST assign a link-local unicast address to their 301 6LoWPAN interface using an interface identifier derived from the IEEE 302 EUI-64 address. Using this link-local address, nodes can communicate 303 with other radio neighbors. 305 Through Router Advertisements, nodes may learn additional 306 autoconfiguration information. Nodes may learn information about 307 Internet parameters, such as the default hop limit value to place in 308 outgoing packets. Nodes may also learn the lifetime of the router 309 sending the Router Advertisement. 311 Router Advertisements may include one or more prefix information 312 options. Each prefix information entry contains a sequence number 313 that indicates its freshness. All 6LoWPAN nodes MUST accept the 314 newest prefix information. All 6LoWPAN routers MUST include that 315 prefix information in its Router Advertisement messages. Doing so 316 effectively allows the prefix information to propagate over multiple 317 hops to all 6LoWPAN nodes in a PAN. 319 Prefix Information entries within a Router Advertisement include a 320 flag to indicate whether those prefixes are intended to be used with 321 stateless address autoconfiguration. If so, nodes should form one or 322 more addresses using the prefix information, one using an interface 323 identifier derived from the IEEE EUI-64 address and, if available, 324 another using an interface identifier derived from the short IEEE 325 802.15.4 address. 327 Two flags in the Router Advertisement indicate if DHCPv6 should be 328 use to autoconfigure addresses or other configuration parameters. A 329 third flag indicates if the sending router is also serving as a 330 DHCPv6 Relay. All 6LoWPAN routers and border routers SHOULD serve as 331 a DHCPv6 Relay and all 6LoWPAN nodes are configured, by default, to 332 forward DHCPv6 requests to a subnet anycast address. Border routers 333 can either service DHCPv6 requests directly or act as a DHCPv6 Relay 334 and forward the request to the intended server. 336 To request an address, nodes unicast a DHCPv6 request to a 337 neighboring DHCPv6 Relay using link-local communication. The DHCPv6 338 Relay may be another 6LoWPAN router or a border router. In the 339 former case, the node simply forwards the payload on to the border 340 router. One subtle difference is that the node need not encapsulate 341 the DHPCv6 request in a DHCPv6 Relay header, as it can be 342 reconstructed using the DUID information contained in the request. 343 The border router, however, must properly expand the DHCPv6 Relay 344 header when forwarding it further or compress the header when 345 forwarding a reply back to a 6LoWPAN node. Note that DHCPv6 requires 346 nodes to form routes between them and one or more border routers. 348 Because this document specifies that an IID MUST be derived from a 349 link-layer address, DHCPv6 replies are composed of one or more 350 prefixes and up to one interface identifier. The latter allows the 351 DHCPv6 server to effectively assign short 16-bit addresses to 352 requesting nodes. Not carrying full IPv6 addresses makes the DHCPv6 353 response more compact. With the prefix information, 6LoWPAN nodes 354 autoconfigure addresses similar to stateless address 355 autoconfiguration described above. 357 As usual, DHCPv6 and stateless autoconfiguration MAY be used 358 together. For example, the DHCPv6 may provide the short address, 359 while stateless autoconfiguration provides the prefixes. 361 4. 6LoWPAN ND Message Formats 363 4.1. Router Solicitation 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Type | Code | Checksum | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Options ... 371 +-+-+-+-+-+-+-+-+-+-+-+- 373 Figure 1: Router Solicitation Message Format 375 IP Fields: 377 o Source Address: An IP address assigned to the sending interface. 379 o Destination Address: The link-local all-routers multicast address. 381 o Hop Limit: 255 383 ICMP Fields: 385 o Type: 133 387 o Code: 0 389 o Checksum: The ICMP checksum. See [RFC4443]. 391 Possible Options: None 393 Future versions of this protocol may define new option types. 394 Receivers MUST silently ignore any options they do not recognized and 395 continue processing the message. 397 4.2. Router Advertisement 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Type | Code | Checksum | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Cur Hop Limit |M|O|D|S| rsv | Router Lifetime | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Options ... 407 +-+-+-+-+-+-+-+-+-+-+-+ 409 Figure 2: Router Advertisement Message Format 411 IP Fields: 413 o Source Address: MUST be a link-local address assigned to the 414 interface when this message is sent. 416 o Destination Address: The link-local all nodes multicast address or 417 the Source Address of an invoking Router Solicitation. 419 o Hop Limit: 255 421 ICMP Fields: 423 o Type: 134 425 o Code: 0 427 o Checksum: The ICMP checksum. See [RFC4443]. 429 o Cur Hop Limit: 8-bit unsigned integer. The default value that 430 should be placed in the Hop Count field of the IP header for 431 outgoing IP packets. A value of zero means unspecified (by this 432 router). 434 o M: 1-bit "Managed address configuration" flag as specified in 435 [RFC4861]. 437 o O: 1-bit "Other configuration" flag as specified in [RFC4861]. 439 o D: 1-bit "DHCPv6 relay" flag. When set, it indicates that the 440 router is acting as a DHCPv6 Relay and is capable of forwarding 441 DHCPv6 requests to a DHCPv6 server. 443 o S: 1-bit "Router Solicitation" flag. When set, it indicates that 444 the router is requesting neighboring routers to generate Router 445 Advertisement messages. 447 o rsv: This field is unused. It MUST be initialized to zero by the 448 sender and MUST be ignored by the receiver. 450 o Router Lifetime: 16-bit unsigned integer as specified in 451 [RFC4861]. 453 Possible options: 455 o Prefix Information: One or more may appear in a Router 456 Advertisement message and indicate what prefixes to use for 457 stateless address autoconfiguration and/or 6LoWPAN IPv6 header 458 compression. 460 Future versions of this protocol may define new option types. 461 Receivers MUST silently ignore any options they do not recognized and 462 continue processing the message. 464 4.3. Prefix Information Option 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Type | Length |CID|V|A|D| rsv | Sequence | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | | 472 + Prefix + 473 | | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 Figure 3: Prefix Information Option Format 478 Fields: 480 o Type: 8-bit unsigned integer. TBD 482 o Length: 8-bit unsigned integer. 12 484 o CID: 2-bit unsigned integer. Identifies the specific context that 485 the prefix information pertains to for use with 6LoWPAN IPv6 486 Header Compression. 488 o V: 1-bit valid flag. When set, indicates that the prefix 489 information is valid and neighboring nodes should inspect the 490 option for newer information. 492 o D: 1-bit deprecated flag. Indicates that the prefix information 493 is deprecated. Nodes MUST unconfigure any IPv6 addresses assigned 494 to the 6LoWPAN interface using this prefix. However, nodes MUST 495 continue accepting packets using this context. 497 o A: 1-bit autonomous address-configuration flag. When set, 498 indicates that this prefix can be used for stateless address 499 autoconfiguration. 501 o rsv: This field is unused. It MUST be initialized to zero by the 502 sender and MUST be ignored by the receiver. 504 o Sequence: 8-bit signed integer. A sequence number used for 505 indicating freshness of the prefix information. Nodes MUST choose 506 the newest prefix information if the versions differ. 508 o Prefix: A 64-bit IPv6 prefix. A router SHOULD NOT send a prefix 509 option for the link-local prefix and a host SHOULD ignore such a 510 prefix option. 512 4.4. Prefix Summary Option 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Type | Length |CID|V|A|D| rsv | Sequence | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 |CID|V|A|D| rsv | Sequence |CID|V|A|D| rsv | Sequence | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 Figure 4: Prefix Summary Option Format 524 Fields: 526 o Type: 8-bit unsigned integer. TBD 528 o Length: 8-bit unsigned integer. 8 530 o CID: 2-bit unsigned integer. Identifies the specific context that 531 the prefix information pertains to for use with 6LoWPAN IPv6 532 Header Compression. 534 o V: 1-bit valid flag. When set, indicates that the prefix 535 information is valid and neighboring nodes should inspect the 536 option for newer information. 538 o D: 1-bit deprecated flag. Indicates that the prefix information 539 is deprecated. Nodes MUST unconfigure any IPv6 addresses assigned 540 to the 6LoWPAN interface using this prefix. However, nodes MUST 541 continue accepting packets using this context. 543 o A: 1-bit autonomous address-configuration flag. When set, 544 indicates that this prefix can be used for stateless address 545 autoconfiguration. 547 o rsv: This field is unused. It MUST be initialized to zero by the 548 sender and MUST be ignored by the receiver. 550 o Sequence: 8-bit signed integer. A sequence number used for 551 indicating freshness of the prefix information. Nodes MUST choose 552 the newest prefix information if the versions differ. 554 5. DHCPv6 Option Formats 556 5.1. DHCPv6 IA_6LOWPAN Option 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | option-type | option-length | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | | 564 + server-id + 565 | | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | | 568 + client-id + 569 | | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | options ... 572 +-+-+-+-+-+-+-+-+-+-+-+ 574 Figure 5: DHCPv6 IA_6LOWPAN Option Format 576 Fields: 578 o option-type: 16-bit unsigned integer. TBD. 580 o option-length: 16-bit unsigned integer. 12 + length of Options 581 field. 583 o server-id: 64-bit IEEE EUI-64 of the server. 585 o client-id: 64-bit IEEE EUI-64 of the client. 587 o options: Options associated with this 6LoWPAN IA. 589 Possible options: 591 o IA_6LOWPAN Prefix Option: One or more may appear in a IA_6LOWPAN 592 Option and indicates IPv6 addresses to assign to the 6LoWPAN 593 interface and the context for use with 6LoWPAN compression of IPv6 594 headers. 596 o IA_6LOWPAN Interface Identifier Option: Up to one may appear in a 597 IA_6LOWPAN Option and assigns a short address to a 6LoWPAN 598 interface. 600 Future versions of this protocol may define new option types. 601 Receivers MUST silently ignore any options they do not recognized and 602 continue processing the message. 604 5.2. IA_6LOWPAN Prefix Option 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | type | length | reserved | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | | 612 + prefix + 613 | | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | valid-lifetime | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Options ... 618 +-+-+-+-+-+-+-+-+-+-+-+ 620 Figure 6: IA_6LOWPAN Prefix Option Format 622 Fields: 624 o Type: 8-bit unsigned integer. TBD. 626 o Length: 8-bit unsigned integer. 32. 628 o Prefix: A 64-bit prefix. 630 o Valid-Lifetime: 32-bit unsigned integer. Valid lifetime of the 631 associated IPv6 address. 633 5.3. IA_6LOWPAN Local Interface Identifier Option 635 0 1 2 3 636 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 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | type | length | short-address | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | valid-lifetime | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Options ... 643 +-+-+-+-+-+-+-+-+-+-+-+ 644 Figure 7: IA_6LOWPAN Local Interface Identifier Option Format 646 Fields: 648 o Type: 8-bit unsigned integer. TBD. 650 o Length: 8-bit unsigned integer. 8. 652 o Short Address: Lower 16 bits of an Interface Identifier derived 653 from a short IEEE 802.15.4 address, which is equivalent to the 654 short address itself. 656 o Valid-Lifetime: 32-bit unsigned integer. Preferred lifetime of 657 the associated IPv6 address. 659 6. Router and Prefix Discovery 660 7. Autoconfiguration 662 7.1. Stateless Autoconfiguration 664 7.2. DHCPv6 Autoconfiguration 665 8. IANA Considerations 667 TODO. 669 9. Security Considerations 671 TODO. 673 10. References 675 10.1. Normative References 677 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 678 Requirement Levels", BCP 14, RFC 2119, March 1997. 680 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 681 Architecture", RFC 4291, February 2006. 683 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 684 Message Protocol (ICMPv6) for the Internet Protocol 685 Version 6 (IPv6) Specification", RFC 4443, March 2006. 687 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 688 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 689 September 2007. 691 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 692 "Transmission of IPv6 Packets over IEEE 802.15.4 693 Networks", RFC 4944, September 2007. 695 [ieee802.15.4] 696 IEEE Computer Society, "IEEE Std. 802.15.4-2006", 697 October 2006. 699 [levis04trickle] 700 Levis, Patel, Culler, and Shenker, "Trickle: A Self- 701 Regulating Algorithm for Code Propagation and Maintenance 702 in Wireless Sensor Networks", March 2004. 704 10.2. Informative References 706 [I-D.hui-6lowpan-hc] 707 Hui, J., "Compression Format for IPv6 Datagrams in 6LoWPAN 708 Networks", draft-hui-6lowpan-hc-00 (work in progress), 709 March 2008. 711 Author's Address 713 Jonathan W. Hui 714 Arch Rock Corporation 715 501 2nd St. Ste. 410 716 San Francisco, California 94107 717 USA 719 Phone: +415 692 0828 720 Email: jhui@archrock.com 722 Full Copyright Statement 724 Copyright (C) The IETF Trust (2008). 726 This document is subject to the rights, licenses and restrictions 727 contained in BCP 78, and except as set forth therein, the authors 728 retain all their rights. 730 This document and the information contained herein are provided on an 731 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 732 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 733 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 734 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 735 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 736 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 738 Intellectual Property 740 The IETF takes no position regarding the validity or scope of any 741 Intellectual Property Rights or other rights that might be claimed to 742 pertain to the implementation or use of the technology described in 743 this document or the extent to which any license under such rights 744 might or might not be available; nor does it represent that it has 745 made any independent effort to identify any such rights. Information 746 on the procedures with respect to rights in RFC documents can be 747 found in BCP 78 and BCP 79. 749 Copies of IPR disclosures made to the IETF Secretariat and any 750 assurances of licenses to be made available, or the result of an 751 attempt made to obtain a general license or permission for the use of 752 such proprietary rights by implementers or users of this 753 specification can be obtained from the IETF on-line IPR repository at 754 http://www.ietf.org/ipr. 756 The IETF invites any interested party to bring to its attention any 757 copyrights, patents or patent applications, or other proprietary 758 rights that may cover technology that may be required to implement 759 this standard. Please address the information to the IETF at 760 ietf-ipr@ietf.org.