idnits 2.17.1 draft-lynn-6man-6lobac-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 == Line 176 has weird spacing: '...Address one o...' -- The document date (October 10, 2011) is 4580 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'BACnet' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance Working Group K. Lynn, Ed. 3 Internet-Draft Consultant 4 Intended status: Standards Track J. Martocci 5 Expires: April 12, 2012 Johnson Controls 6 C. Neilson 7 Delta Controls 8 S. Donaldson 9 Honeywell 10 October 10, 2011 12 Transmission of IPv6 over MS/TP Networks 13 draft-lynn-6man-6lobac-02 15 Abstract 17 MS/TP (Master-Slave/Token-Passing) is a contention-free access method 18 for the TIA-485-A physical layer that is used extensively in building 19 automation networks. This document describes the frame format for 20 transmission of IPv6 packets and the method of forming link-local and 21 statelessly autoconfigured IPv6 addresses on MS/TP networks. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 12, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. MS/TP Mode for IPv6 . . . . . . . . . . . . . . . . . . . . . 6 59 3. Addressing Modes . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . . . 7 61 5. LoBAC Adaptation Layer . . . . . . . . . . . . . . . . . . . . 7 62 6. Stateless Address Autoconfiguration . . . . . . . . . . . . . 9 63 7. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . 10 64 8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 10 65 9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 11 66 10. Header Compression . . . . . . . . . . . . . . . . . . . . . . 11 67 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 70 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 14.1. Normative References . . . . . . . . . . . . . . . . . . 12 72 14.2. Informative References . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 75 1. Introduction 77 MS/TP (Master-Slave/Token-Passing) is a contention-free access method 78 for the [TIA-485-A] physical layer that is used extensively in 79 building automation networks. This document describes the frame 80 format for transmission of IPv6 [RFC2460] packets and the method of 81 forming link-local and statelessly autoconfigured IPv6 addresses on 82 MS/TP networks. The general approach is to adapt elements of the 83 6LoWPAN [RFC4944] specification to constrained wired networks. 85 An MS/TP device is typically based on a low-cost microcontroller with 86 limited processing power and memory. Together with low data rates 87 and a small address space, these constraints are similar to those 88 faced in 6LoWPAN networks and suggest some elements of that solution 89 might be applied. MS/TP differs significantly from 6LoWPAN in at 90 least three respects: a) MS/TP devices typically have a continuous 91 source of power, b) all MS/TP devices on a segment can communicate 92 directly so there are no hidden node or mesh routing issues, and c) 93 proposed changes to MS/TP will support payloads of up to 1500 octets, 94 eliminating the need for link-layer fragmentation and reassembly. 96 The following sections provide a brief overview of MS/TP, then 97 describe how to form IPv6 addresses and encapsulate IPv6 packets in 98 MS/TP frames. This document also specifies a header compression 99 mechanism, based on [RFC6282], that is recommended in order to make 100 IPv6 practical on low speed MS/TP networks. 102 1.1. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 1.2. Abbreviations Used 110 ASHRAE: American Society of Heating, Refrigerating, and Air- 111 Conditioning Engineers (http://www.ashrae.org) 113 BACnet: An ISO/ANSI/ASHRAE Standard Data Communication Protocol 114 for Building Automation and Control Networks 116 CRC: Cyclic Redundancy Check 118 MAC: Medium Access Control 120 MSDU: MAC Service Data Unit (MAC client data) 122 UART: Universal Asynchronous Transmitter/Receiver 124 1.3. MS/TP Overview 126 This section provides a brief overview of MS/TP, which is specified 127 in Clause 9 of ANSI/ASHRAE 135-2010 [BACnet] and included herein by 128 reference. [BACnet] also covers physical layer deployment options. 130 MS/TP is designed to enable multidrop networks over shielded twisted 131 pair wiring. It can support segments up to 1200 meters in length or 132 data rates up to 115,200 baud (at this highest data rate the segment 133 length is limited to 1000 meters). An MS/TP link requires only a 134 UART, a 5ms resolution timer, and a [TIA-485-A] transceiver with a 135 driver that can be disabled. These features combine to make MS/TP a 136 cost-effective field bus for the most numerous and least expensive 137 devices in a building automation network. 139 The differential signaling used by [TIA-485-A] requires a contention- 140 free MAC. MS/TP uses a token to control access to a multidrop bus. 141 A master node may initiate the transmission of a data frame when it 142 holds the token. After sending at most a configured maximum number 143 of data frames, a master node passes the token to the next master 144 node (as determined by node address). Slave nodes transmit only when 145 polled and are not considered part of this specification. 147 MS/TP frames have the following format*: 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | 0x55 | 0xFF | Frame Type* | DA | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | SA | Length (MS octet first) | Header CRC | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 / 157 / Data* 158 / 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Extended Data CRC* (LS octet first) | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | optional 0xFF | 163 +-+-+-+-+-+-+-+-+ 165 Figure 1: MS/TP Frame Format 167 *Note: BACnet [Addendum_an], now in public review, assigns a new 168 Frame Type for IPv6, extends the maximum length of the Data field to 169 1500 octets, and specifies a 32-bit Extended Data CRC. The Data and 170 Extended Data CRC fields are present only if Length is non-zero. 172 The MS/TP frame fields have the following descriptions**: 174 Preamble two octet preamble: 0x55, 0xFF 175 Frame Type one octet 176 Destination Address one octet address 177 Source Address one octet address 178 Length two octets, most significant octet first 179 Header CRC one octet 180 Data 0 - 1500 octets** 181 (present only if Length is non-zero) 182 Extended Data CRC four octets**, least significant octet first 183 (present only if Length is non-zero) 184 (pad) (optional) at most one octet of trailer: 0xFF 186 The Frame Type is used to distinguish between different types of MAC 187 frames. Currently defined types (in decimal) are: 189 00 Token 190 01 Poll For Master 191 02 Reply To Poll For Master 192 ... 193 10 IPv6 over MS/TP Encapsulation** 195 **See previous note regarding the BACnet [Addendum_an] change proposal 196 to support IPv6 over MS/TP Encapsulation. 198 Frame Types 11 through 127 are reserved for assignment by ASHRAE. 199 All master nodes MUST understand Token, Poll For Master, and Reply to 200 Poll For Master frames. See Section 2 for additional details. 202 The Destination and Source Addresses are each one octet in length. 203 See Section 3 for additional details. 205 The Length field specifies the length of the Data field in octets and 206 is transmitted most significant octet first. See Section 4 for 207 additional details. 209 The Header CRC field covers the Frame Type, Destination Address, 210 Source Address, and Length fields. The Header CRC generation and 211 check procedures are specified in [BACnet]. 213 The Data and Extended Data CRC fields are conditional on the Frame 214 Type and the Length. (Note: The Data and Extended Data CRC fields 215 will always be present in frames specified by this document.) The 216 Extended Data CRC generation and check procedures are specified in 217 the BACnet [Addendum_an] change proposal. 219 1.4. Goals and Non-goals 221 The primary goal of this specification is to enable IPv6 directly to 222 wired end devices in building automation and control networks, while 223 leveraging existing standards to the greatest extent possible. A 224 secondary goal is to co-exist with legacy MS/TP implementations. 225 Only the minimum changes necessary to support IPv6 over MS/TP are 226 proposed in BACnet [Addendum_an] (see note in Section 1.3). 228 Non-goals include making changes to the MS/TP frame header format, 229 control frames, Master Node state machine, or addressing modes. 230 Also, while the techniques described here may be applicable to other 231 data links, no attempt is made to define a general design pattern. 233 2. MS/TP Mode for IPv6 235 The BACnet [Addendum_an] change proposal allocates a new MS/TP Frame 236 Type from the ASHRAE reserved range to indicate IPv6 encapsulation. 237 The new Frame Type for IPv6 over MS/TP Encapsulation is 10 (0x0A). 239 All MS/TP master nodes (including those that support IPv6) must 240 understand Token, Poll For Master, and Reply to Poll For Master 241 control frames and support the Master Node state machine as specified 242 in [BACnet]. MS/TP master nodes that support IPv6 must also support 243 the Receive Frame state machine as specified in [BACnet] and extended 244 by [Addendum_an]. 246 3. Addressing Modes 248 MS/TP node (link-layer) addresses are one octet in length. The 249 method of assigning node addresses is outside the scope of this 250 document. However, each MS/TP node on the link MUST have a unique 251 address or a misconfiguration condition exists. 253 [BACnet] specifies that addresses 0 through 127 are valid for master 254 nodes. The method specified in Section 6 for creating the Interface 255 Identifier (IID) ensures that an IID of all zeros can never result. 257 A Destination Address of 255 (0xFF) denotes a link-level broadcast 258 (all nodes). A Source Address of 255 MUST NOT be used. MS/TP does 259 not support multicast, therefore all IPv6 multicast packets MUST be 260 sent as link-level broadcasts and filtered at the IPv6 layer. 262 This document assumes that each MS/TP link maps to a unique IPv6 263 subnet prefix. Hosts learn IPv6 prefixes via router advertisements 264 according to [RFC4861]. 266 4. Maximum Transmission Unit (MTU) 268 The BACnet [Addendum_an] change proposal specifies that the MSDU be 269 increased to 1500 octets and covered by a 32-bit CRC. This is 270 sufficient to convey an MTU of at least 1280 octets as required by 271 IPv6 without the need for link-layer fragmentation and reassembly. 273 However, the relatively low data rates of MS/TP still make a 274 compelling case for header compression. An adaptation layer to 275 indicate compressed or uncompressed IPv6 headers is specified below 276 in Section 5 and the compression scheme is specified in Section 10. 278 5. LoBAC Adaptation Layer 280 The encapsulation formats defined in this section (subsequently 281 referred to as the "LoBAC" encapsulation) comprise the payload (MSDU) 282 of an MS/TP frame. The LoBAC payload (e.g., an IPv6 packet) follows 283 an encapsulation header stack. LoBAC is a subset of the LoWPAN 284 encapsulation defined in [RFC4944], therefore the use of "LOWPAN" in 285 literals below is intentional. The primary differences between LoBAC 286 and LoWPAN are: a) exclusion of the Fragmentation, Mesh, and 287 Broadcast headers, and b) use of LOWPAN_IPHC [RFC6282] in place of 288 LOWPAN_HC1 header compression (which is deprecated by [RFC6282]). 290 All LoBAC encapsulated datagrams transmitted over MS/TP are prefixed 291 by an encapsulation header stack. Each header in the stack consists 292 of a header type followed by zero or more header fields. Whereas in 293 an IPv6 header the stack would contain, in the following order, 294 addressing, hop-by-hop options, routing, fragmentation, destination 295 options, and finally payload [RFC2460]; in a LoBAC encapsulation the 296 analogous sequence is (optional) header compression and payload. The 297 header stacks that are valid in a LoBAC network are shown below. 299 A LoBAC encapsulated IPv6 datagram: 301 +---------------+-------------+---------+ 302 | IPv6 Dispatch | IPv6 Header | Payload | 303 +---------------+-------------+---------+ 305 A LoBAC encapsulated LOWPAN_IPHC compressed IPv6 datagram: 307 +---------------+-------------+---------+ 308 | IPHC Dispatch | IPHC Header | Payload | 309 +---------------+-------------+---------+ 311 All protocol datagrams (e.g., IPv6 or compressed IPv6 headers) SHALL 312 be preceded by one of the valid LoBAC encapsulation headers. This 313 permits uniform software treatment of datagrams without regard to 314 their mode of transmission. 316 The definition of LoBAC headers consists of the dispatch value, the 317 definition of the header fields that follow, and their ordering 318 constraints relative to all other headers. Although the header stack 319 structure provides a mechanism to address future demands on the LoBAC 320 (LoWPAN) adaptation layer, it is not intended to provided general 321 purpose extensibility. This format document specifies a small set of 322 header types using the header stack for clarity, compactness, and 323 orthogonality. 325 5.1. Dispatch Type and Header 327 A LoBAC Dispatch type begins with a "0" bit followed by a "1" bit. 328 The Dispatch type and header are shown here: 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 |0|1| Dispatch | Type-specific header 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Dispatch 6-bit selector. Identifies the type of header 337 immediately following the Dispatch Header. 339 Type-specific header A header determined by the Dispatch Header. 341 Figure 2: Dispatch Type and Header 343 The Dispatch value may be treated as an unstructured namespace. Only 344 a few symbols are required to represent current LoBAC functionality. 345 Although some additional savings could be achieved by encoding 346 additional functionality into the dispatch octet, these measures 347 would tend to constrain the ability to address future alternatives. 349 Pattern Header Type 350 +------------+-----------------------------------------------------+ 351 | 00 xxxxxx | NALP - Not a LoWPAN (LoBAC) frame | 352 | 01 000000 | ESC - Additional Dispatch octet follows | 353 | 01 000001 | IPv6 - Uncompressed IPv6 Addresses | 354 | ... | reserved - Defined or reserved by [RFC4944] | 355 | 01 1xxxxx | LOWPAN_IPHC - LOWPAN_IPHC compressed IPv6 [RFC6282] | 356 | 1x xxxxxx | reserved - Defined or reserved by [RFC4944] | 357 +------------+-----------------------------------------------------+ 359 Figure 3: Dispatch Value Bit Patterns 361 NALP: Specifies that the following bits are not a part of the LoBAC 362 encapsulation, and any LoBAC node that encounters a Dispatch 363 value of 00xxxxxx shall discard the packet. Non-LoBAC protocols 364 that wish to coexist with LoBAC nodes should include an octet 365 matching this pattern immediately following the MS/TP header. 367 ESC: Specifies that the following header is a single 8-bit field for 368 the Dispatch value. It allows support for Dispatch values larger 369 than 127 (see [RFC6282] section 5). 371 IPv6: Specifies that the following header is an uncompressed IPv6 372 header [RFC2460]. 374 LOWPAN_IPHC: A value of 011xxxxx specifies a LOWPAN_IPHC compression 375 header (see Section 10.) 377 Reserved: A LoBAC node that encounters a Dispatch value in the range 378 01000010 through 01011111 or 1xxxxxxx SHALL discard the packet. 380 6. Stateless Address Autoconfiguration 382 This section defines how to obtain an IPv6 Interface Identifier. The 383 general procedure is described in Appendix A of [RFC4291], "Creating 384 Modified EUI-64 Format Interface Identifiers". 386 The Interface Identifier may be based on an [EUI-64] identifier 387 assigned to the device (but this is not typical for MS/TP). In this 388 case, the Interface Identifier is formed from the EUI-64 by inverting 389 the "u" (universal/local) bit according to [RFC4291]. This will 390 result in a globally unique Interface Identifier. 392 If the device does not have an EUI-64, then the Interface Identifier 393 MUST be formed by concatenating its 8-bit MS/TP node address to the 394 seven octets 0x00, 0x00, 0x00, 0xFF, 0xFE, 0x00, 0x00. For example, 395 an MS/TP node address of hexadecimal value 0x4F results in the 396 following Interface Identifier: 398 |0 1|1 3|3 4|4 6| 399 |0 5|6 1|2 7|8 3| 400 +----------------+----------------+----------------+----------------+ 401 |0000000000000000|0000000011111111|1111111000000000|0000000001001111| 402 +----------------+----------------+----------------+----------------+ 404 Note that this results in the universal/local bit set to "0" to 405 indicate local scope. 407 An IPv6 address prefix used for stateless autoconfiguration [RFC4862] 408 of an MS/TP interface MUST have a length of 64 bits. 410 7. IPv6 Link Local Address 412 The IPv6 link-local address [RFC4291] for an MS/TP interface is 413 formed by appending the Interface Identifier, as defined above, to 414 the prefix FE80::/64. 416 10 bits 54 bits 64 bits 417 +----------+-----------------------+----------------------------+ 418 |1111111010| (zeros) | Interface Identifier | 419 +----------+-----------------------+----------------------------+ 421 8. Unicast Address Mapping 423 The address resolution procedure for mapping IPv6 non-multicast 424 addresses into MS/TP link-layer addresses follows the general 425 description in Section 7.2 of [RFC4861], unless otherwise specified. 427 The Source/Target Link-layer Address option has the following form 428 when the addresses are 8-bit MS/TP node (link-layer) addresses. 430 0 1 431 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Type | Length=1 | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | 0x00 | MS/TP Address | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | | 438 +- Padding -+ 439 | (all zeros) | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 Option fields: 444 Type: 446 1: for Source Link-layer address. 448 2: for Target Link-layer address. 450 Length: This is the length of this option (including the type and 451 length fields) in units of 8 octets. The value of this field is 1 452 for 8-bit MS/TP node addresses. 454 MS/TP Address: The 8-bit address in canonical bit order [RFC2469]. 455 This is the unicast address the interface currently responds to. 457 9. Multicast Address Mapping 459 All IPv6 multicast packets MUST be sent to MS/TP Destination Address 460 255 (broadcast) and filtered at the IPv6 layer. When represented as 461 a 16-bit address in a compressed header (see Section 10), it MUST be 462 formed by padding on the left with a zero: 464 0 1 465 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | 0x00 | 0xFF | 468 +-+-+-+-+-+-+-+-+---------------+ 470 10. Header Compression 472 LoBAC uses LOWPAN_IPHC IPv6 compression, which is specified in 473 [RFC6282] and included herein by reference. This section will simply 474 identify substitutions that should be made when interpreting the text 475 of [RFC6282]. 477 In general the following substitutions should be made: 479 * Replace "6LoWPAN" with "MS/TP network" 481 * Replace "IEEE 802.15.4 address" with "MS/TP address" 483 When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short 484 address") it MUST be formed by padding the MS/TP address to the left 485 with a zero: 487 0 1 488 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | 0x00 | MS/TP address | 491 +-+-+-+-+-+-+-+-+---------------+ 493 11. IANA Considerations 495 This document uses values previously reserved by [RFC4944] and 496 [RFC6282] and makes no further requests of IANA. 498 Note to RFC Editor: this section may be removed upon publication. 500 12. Security Considerations 502 The method of deriving Interface Identifiers from MAC addresses is 503 intended to preserve global uniqueness when possible. However, there 504 is no protection from duplication through accident or forgery. 506 13. Acknowledgments 508 We are grateful to the authors of [RFC4944] and members of the IETF 509 6LoWPAN working group; this document borrows extensively from their 510 work. 512 14. References 514 14.1. Normative References 516 [BACnet] American Society of Heating, Refrigerating, and Air- 517 Conditioning Engineers, "BACnet, A Data Communication 518 Protocol for Building Automation and Control Networks 519 (ANSI Approved)", ANSI/ASHRAE 135-2010, April 2011. 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, March 1997. 524 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 525 (IPv6) Specification", RFC 2460, December 1998. 527 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 528 Architecture", RFC 4291, February 2006. 530 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 531 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 532 September 2007. 534 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 535 Address Autoconfiguration", RFC 4862, September 2007. 537 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 538 "Transmission of IPv6 Packets over IEEE 802.15.4 539 Networks", RFC 4944, September 2007. 541 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 542 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 543 September 2011. 545 14.2. Informative References 547 [Addendum_an] 548 ASHRAE, "BSR/ASHRAE Addendum an to ANSI/ASHRAE Standard 549 135-2010, BACnet - A Data Communication Protocol for 550 Building Automation and Control Networks (Advisory Public 551 Review Draft)", September 2011, 552 . 554 [EUI-64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 555 Registration Authority", March 1997, . 558 [RFC2469] Narten, T. and C. Burton, "A Caution On The Canonical 559 Ordering Of Link-Layer Addresses", RFC 2469, 560 December 1998. 562 [TIA-485-A] 563 Telecommunications Industry Association, "TIA-485-A, 564 Electrical Characteristics of Generators and Receivers for 565 Use in Balanced Digital Multipoint Systems (ANSI/TIA/ 566 EIA-485-A-98) (R2003)", March 2003. 568 Authors' Addresses 570 Kerry Lynn (editor) 571 Consultant 573 Phone: +1 978 460 4253 574 Email: kerlyn@ieee.org 576 Jerry Martocci 577 Johnson Controls, Inc. 578 507 E. Michigan St 579 Milwaukee, WI 53202 580 USA 582 Phone: +1 414 524 4010 583 Email: jerald.p.martocci@jci.com 585 Carl Neilson 586 Delta Controls, Inc. 587 17850 56th Ave 588 Surrey, BC V3S 1C7 589 Canada 591 Phone: +1 604 575 5913 592 Email: cneilson@deltacontrols.com 594 Stuart Donaldson 595 Honeywell Automation & Control Solutions 596 6670 185th Ave NE 597 Redmond, WA 98052 598 USA 600 Email: stuart.donaldson@honeywell.com