Intended status: Informational Expires: May 31, 2015 DONG-EUI Univ D-K. Kim KNU J-H. Choi Samsung Electronics Co., November 27, 2014

Transcription

1 6Lo Working Group Internet-Draft Intended status: Informational Expires: May 31, 2015 Y-G. Hong Y-H. Choi ETRI J-S. Youn DONG-EUI Univ D-K. Kim KNU J-H. Choi Samsung Electronics Co., November 27, 2014 Abstract Transmission of IPv6 Packets over Near Field Communication draft-hong-6lo-ipv6-over-nfc-03 Near field communication (NFC) is a set of standards for smartphones and portable devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than 10 cm. NFC standards cover communications protocols and data exchange formats, and are based on existing radio-frequency identification (RFID) standards including ISO/IEC and FeliCa. The standards include ISO/IEC and those defined by the NFC Forum. The NFC technology has been widely implemented and available in mobile phones, laptop computers, and many other devices. This document describes how IPv6 is transmitted over NFC using 6LowPAN techniques. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 31, Hong, et al. Expires May 31, 2015 [Page 1]

2 Internet-Draft IPv6 over NFC November 2014 Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust s Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction Conventions and Terminology Overview of Near Field Communication Technology Peer-to-peer Mode for IPv6 over NFC Protocol Stacks in IPv6 over NFC NFC-enabled Device Addressing NFC Packet Size and MTU Specification of IPv6 over NFC Protocol Stack Link Model Stateless Address Autoconfiguration Neighbor Discovery Header Compression Fragmentation and Reassembly Unicast Address Mapping Multicast Address Mapping Internet Connectivity Scenarios NFC-enabled Device Connected to the Internet Isolated NFC-enabled Device Network IANA Considerations Security Considerations References Normative References Informative References Authors Addresses Introduction NFC is a set of short-range wireless technologies, typically requiring a distance of 10 cm or less. NFC operates at MHz on ISO/IEC air interface and at rates ranging from 106 kbit/s to Hong, et al. Expires May 31, 2015 [Page 2]

3 Internet-Draft IPv6 over NFC November kbit/s. NFC always involves an initiator and a target; the initiator actively generates an RF field that can power a passive target. This enables NFC targets to take very simple form factors such as tags, stickers, key fobs, or cards that do not require batteries. NFC peer-to-peer communication is possible, provided both devices are powered. NFC builds upon RFID systems by allowing twoway communication between endpoints, where earlier systems such as contactless smart cards were one-way only. It has been used in devices such as mobile phones, running Android operating system, named with a feature called "Android Beam". In addition, it is expected for the other mobile phones, running the other operating systems (e.g., ios, etc.) to be equipped with NFC technology in the near future. Considering the potential for exponential growth in the number of heterogeneous air interface technologies, NFC would be widely used as one of the other air interface technologies, such as Bluetooth Low Energy (BT-LE), Wi-Fi, and so on. Each of the heterogeneous air interface technologies has its own characteristics, which cannot be covered by the other technologies, so various kinds of air interface technologies would be existing together. Therefore, it is required for them to communicate each other. NFC also has the strongest point (e.g., secure communication distance of 10 cm) to prevent the third party from attacking privacy. When the number of devices and things having different air interface technologies communicate each other, IPv6 is an ideal internet protocols owing to its large address space. Also, NFC would be one of the endpoints using IPv6. Therefore, This document describes how IPv6 is transmitted over NFC using 6LoWPAN techiques with following scopes. o Overview of NFC technologies; o Specifications for IPv6 over NFC; * Neighbor Discovery; * Addressing and Configuration; * Header Compression; * Fragmentation & Reassembly for a IPv6 datagram; RFC4944 [1] specifies the transmission of IPv6 over IEEE The NFC link also has similar characteristics to that of IEEE Many of the mechanisms defined in the RFC4944 [1] can be Hong, et al. Expires May 31, 2015 [Page 3]

4 Internet-Draft IPv6 over NFC November 2014 applied to the transmission of IPv6 on NFC links. This document specifies the details of IPv6 transmission over NFC links. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2]. 3. Overview of Near Field Communication Technology NFC technology enables simple and safe two-way interactions between electronic devices, allowing consumers to perform contactless transactions, access digital content, and connect electronic devices with a single touch. NFC complements many popular consumer level wireless technologies, by utilizing the key elements in existing standards for contactless card technology (ISO/IEC A&B and JIS-X ). NFC can be compatible with existing contactless card infrastructure and it enables a consumer to utilize one device across different systems. Extending the capability of contactless card technology, NFC also enables devices to share information at a distance that is less than 10 cm with a maximum communication speed of 424 kbps. Users can share business cards, make transactions, access information from a smart poster or provide credentials for access control systems with a simple touch. NFC s bidirectional communication ability is ideal for establishing connections with other technologies by the simplicity of touch. In addition to the easy connection and quick transactions, simple data sharing is also available Peer-to-peer Mode for IPv6 over NFC NFC-enabled devices are unique in that they can support three modes of operation: card emulation, peer-to-peer, and reader/writer. Peerto-peer mode enables two NFC-enabled devices to communicate with each other to exchange information and share files, so that users of NFCenabled devices can quickly share contact information and other files with a touch. Therefore, a NFC-enabled device can securely send IPv6 packets to any corresponding node on the Internet when a NFC-enabled gateway is linked to the Internet. Hong, et al. Expires May 31, 2015 [Page 4]

5 Internet-Draft IPv6 over NFC November Protocol Stacks in IPv6 over NFC The IP protocol can use the services provided by Logical Link Control Protocol (LLCP) in the NFC stack to provide reliable, two-way transport of information between the peer devices. Figure 1 depicts the NFC P2P protocol stack with IPv6 bindings to the LLCP. For data communication in IPv6 over NFC, an IPv6 packet SHALL be received at LLCP of NFC and transported to an Information Field in Protocol Data Unit (I PDU) of LLCP of the NFC-enabled peer device. Since LLCP does not support fragmentation and reassembly, Upper Layers SHOULD support fragmentation and reassembly. For IPv6 addressing or address configuration, LLCP SHALL provide related information, such as link layer addresses, to its upper layer. LLCP to IPv6 protocol Binding SHALL transfer the SSAP and DSAP value to the IPv6 over NFC protocol. SSAP stands for Source Service Access Point, which is 6-bit value meaning a kind of Logical Link Control (LLC) address, while DSAP means a LLC address of destination NFCenabled device. Application Layer Upper Layer Protocols Transport Layer Network Layer < IPv6-LLCP Binding NFC Logical Link Logical Link Control Protocol Layer (LLCP) < Activities Digital Protocol NFC Physical Layer RF Analog < Figure 1: Protocol Stack of NFC Hong, et al. Expires May 31, 2015 [Page 5]

6 Internet-Draft IPv6 over NFC November NFC-enabled Device Addressing NFC-enabled devices are identified by 6-bit LLC address. In other words, Any address SHALL be usable as both an SSAP and a DSAP address. According to NFCForum-TS-LLCP_1.1 [3], address values between 0 and 31 (00h - 1Fh) SHALL be reserved for well-known service access points for Service Discovery Protocol (SDP). Address values between 32 and 63 (20h - 3Fh) inclusively, SHALL be assigned by the local LLC as the result of an upper layer service request NFC Packet Size and MTU As mentioned in Section 3.2, an IPv6 packet SHALL be received at LLCP of NFC and transported to an Information Field in Protocol Data Unit (I PDU) of LLCP of the NFC-enabled peer device. The format of the I PDU SHALL be as shown in Figure DDDDDD 1100 SSSSSS N(S) N(R) Service Data Unit < bytes > < bytes (default) > Figure 2: Format of the I PDU in NFC The I PDU sequence field SHALL contain two sequence numbers: The send sequence number N(S) and the receive sequence number N(R). The send sequence number N(S) SHALL indicate the sequence number associated with this I PDU. The receive sequence number N(R) value SHALL indicate that I PDUs numbered up through N(R) - 1 have been received correctly by the sender of this I PDU and successfully passed to the senders SAP identified in the SSAP field. These I PDUs SHALL be considered as acknowledged. The information field of an I PDU SHALL contain a single service data unit. The maximum number of octets in the information field SHALL be determined by the Maximum Information Unit (MIU) for the data link connection. The default value of the MIU for I PDUs SHALL be 128 octets. The local and remote LLCs each establish and maintain distinct MIU values for each data link connection endpoint. Also, An LLC MAY announce a larger MIU for a data link connection by transmitting an MIUX extension parameter within the information field. Hong, et al. Expires May 31, 2015 [Page 6]

7 Internet-Draft IPv6 over NFC November Specification of IPv6 over NFC NFC technology sets also has considerations and requirements owing to low power consumption and allowed protocol overhead. 6LoWPAN standards RFC4944 [1], RFC6775 [4], and RFC6282 [5] provide useful functionality for reducing overhead which can be applied to BT-LE. This functionality comprises of link-local IPv6 addresses and stateless IPv6 address auto-configuration (see Section 4.3), Neighbor Discovery (see Section 4.4) and header compression (see Section 4.5). One of the differences between IEEE and NFC is that the former supports both star and mesh topology (and requires a routing protocol), whereas NFC can support direct peer-to-peer connection and simple mesh-like topology depending on NFC application scenarios because of very short RF distance of 10 cm or less Protocol Stack Figure 3 illustrates IPv6 over NFC. Upper layer protocols can be transport protocols (TCP and UDP), application layer, and the others capable running on the top of IPv6. Transport & Upper Layer Protocols Application Layer < IPv6 Network Layer Adaptation Layer for IPv6 over NFC < IPv6-LLCP Binding Logical Link Control Protocol NFC Link Layer (LLCP) < Activities NFC Digital Protocol Physical Layer RF Analog < Figure 3: Protocol Stack for IPv6 over NFC Adaptation layer for IPv6 over NFC SHALL support neighbor discovery, address auto-configuration, header compression, and fragmentation & reassembly. Hong, et al. Expires May 31, 2015 [Page 7]

8 Internet-Draft IPv6 over NFC November Link Model In the case of BT-LE, Logical Link Control and Adaptation Protocol (L2CAP) supports fragmentation and reassembly (FAR) functionality; therefore, adaptation layer for IPv6 over BT-LE do not have to conduct the FAR procedure. However, NFC link layer is similar to IEEE Adaptation layer for IPv6 over NFC SHOULD support FAR functionality. Therefore, fragmentation functionality as defined in RFC4944 [1] SHALL be used in NFC-enabled device networks. The NFC link between two communicating devices is considered to be a point-to-point link only. Unlike in BT-LE, NFC link does not consider star topology and mesh network topology but peer-to-peer topology and simple multi-hop topology. Due to this characteristics, 6LoWPAN functionality, such as addressing and auto-configuration, and header compression, is specialized into NFC Stateless Address Autoconfiguration A NFC-enabled device (i.e., 6LN) performs stateless address autoconfiguration as per RFC4862 [6]. A 64-bit Interface identifier (IID) for a NFC interface MAY be formed by utilizing the 6-bit NFC LLCP address (i.e., SSAP or DSAP) (see Section 3.3). In the viewpoint of address configuration, such an IID MAY guarantee a stable IPv6 address because each data link connection is uniquely identified by the pair of DSAP and SSAP included in the header of each LLC PDU in NFC. In the case of NFC-enabled device address, the "Universal/Local" bit MUST be set to 0 RFC4291 [7]. Only if the NFC-enabled device address is known to be a public address the "Universal/Local" bit can be set to 1. As defined in RFC4291, the IPv6 link-local address for a NFCenabled device is formed by appending the IID, to the prefix FE80::/64, as depicted in Figure zeros zeros SSAP < bits > Figure 4: IPv6 link-local address in NFC Hong, et al. Expires May 31, 2015 [Page 8]

9 Internet-Draft IPv6 over NFC November 2014 The tool for a 6LBR to obtain an IPv6 prefix for numbering the NFC network is can be accomplished via DHCPv6 Prefix Delegation (RFC3633 [8]) Neighbor Discovery Neighbor Discovery Optimization for 6LoWPANs (RFC6775 [4]) describes the neighbor discovery approach in several 6LoWPAN topologies, such as mesh topology. NFC does not consider complicated mesh topology but simple multi-hop network topology or directly connected peer-topeer network. Therefore, the following aspects of RFC6775 are applicable to NFC: 1. In a case that a NFC-enabled device (6LN) is directly connected to 6LBR, A NFC 6LN MUST register its address with the 6LBR by sending a Neighbor Solicitation (NS) message with the Address Registration Option (ARO) and process the Neighbor Advertisement (NA) accordingly. In addition, DHCPv6 is used to assigned an address, Duplicate Address Detection (DAD) is not required. 2. For sending Router Solicitations and processing Router Advertisements the NFC 6LNs MUST follow Sections 5.3 and 5.4 of the RFC Header Compression Header compression as defined in RFC6282 [5], which specifies the compression format for IPv6 datagrams on top of IEEE , is REQUIRED in this document as the basis for IPv6 header compression on top of NFC. All headers MUST be compressed according to RFC6282 encoding formats. If a 16-bit address is required as a short address of IEEE , it MUST be formed by padding the 6-bit NFC link-layer (node) address to the left with zeros as shown in Figure Padding(all zeros) NFC Addr Figure 5: NFC short adress format Hong, et al. Expires May 31, 2015 [Page 9]

10 Internet-Draft IPv6 over NFC November Fragmentation and Reassembly Fragmentation and reassembly (FAR) as defined in RFC4944, which specifies the fragmentation methods for IPv6 datagrams on top of IEEE , is REQUIRED in this document as the basis for IPv6 datagram FAR on top of NFC. All headers MUST be compressed according to RFC4944 encoding formats, but the default MTU of NFC is 128 bytes. This MUST be considered Unicast Address Mapping The address resolution procedure for mapping IPv6 non-multicast addresses into NFC link-layer addresses follows the general description in Section 7.2 of RFC4861 [9], unless otherwise specified. The Source/Target link-layer Address option has the following form when the addresses are 6-bit NFC link-layer (node) addresses. Option fields: Type: Type Length= Padding (all zeros) NFC Addr Figure 6: Unicast address mapping 1: for Source Link-layer address. 2: for Target Link-layer address. Length: This is the length of this option (including the type and length fields) in units of 8 octets. The value of this field is 1 for 6-bit NFC node addresses. NFC address: Hong, et al. Expires May 31, 2015 [Page 10]

11 Internet-Draft IPv6 over NFC November 2014 The 6-bit address in canonical bit order. This is the unicast address the interface currently responds to Multicast Address Mapping All IPv6 multicast packets MUST be sent to NFC Destination Address, 0x3F (broadcast) and filtered at the IPv6 layer. When represented as a 16-bit address in a compressed header, it MUST be formed by padding on the left with a zero. In addition, the NFC Destination Address, 0x3F, MUST not be used as a unicast NFC address of SSAP or DSAP. 5. Internet Connectivity Scenarios Padding(all zeros) Figure 7: Multicast address mapping As two typical scenarios, the NFC network can be isolated and connected to the Internet NFC-enabled Device Connected to the Internet One of the key applications by using adaptation technology of IPv6 over NFC is the most securely transmitting IPv6 packets because RF distance between 6LN and 6LBR SHOULD be within 10 cm. If any third party wants to hack into the RF between them, it MUST come to nearly touch them. Applications can choose which kinds of air interfaces (e.g., BT-LE, Wi-Fi, NFC, etc.) to send data depending characteristics of data. NFC SHALL be the best solution for secured and private information. Figure 8 illustrates an example of NFC-enabled device network connected to the Internet. Distance between 6LN and 6LBR SHOULD be 10 cm or less. If there is any of close laptop computers to a user, it SHALL becomes the 6LBR. Additionally, When the user mounts a NFCenabled air interface adapter (e.g., portable small NFC dongle) on the close laptop PC, the user s NFC-enabled device (6LN) can communicate the laptop PC (6LBR) within 10 cm distance. Hong, et al. Expires May 31, 2015 [Page 11]

12 Internet-Draft IPv6 over NFC November 2014 ************ 6LN LBR -----* Internet * CN (dis. 10 cm or less) ************ < NFC > <----- IPv6 packet > (IPv6 over NFC packet) Figure 8: NFC-enabled device network connected to the Internet 5.2. Isolated NFC-enabled Device Network In some scenarios, the NFC-enabled device network may transiently be a simple isolated network as shown in the Figure 9. 6LN LR LN (10 cm or less) (10 cm or less) < NFC > < NFC > (IPv6 over NFC packet) (IPv6 over NFC packet) Figure 9: Isolated NFC-enabled device network In mobile phone markets, applications are designed and made by user developers. They may image interesting applications, where three or more mobile phones touch or attach each other to accomplish outstanding performance. For instance, three or more mobile phones can play multi-channel sound of music together. In addition, attached three or more mobile phones can make an extended banner to show longer sentences in a concert hall. 6. IANA Considerations There are no IANA considerations related to this document. 7. Security Considerations The method of deriving Interface Identifiers from 6-bit NFC Link layer addresses is intended to preserve global uniqueness when it is possible. Therefore, it is to required to protect from duplication through accident or forgery. 8. References 8.1. Normative References [1] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE Networks", RFC 4944, September Hong, et al. Expires May 31, 2015 [Page 12]

13 Internet-Draft IPv6 over NFC November 2014 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March [3] "Logical Link Control Protocol version 1.1", NFC Forum Technical Specification, June [4] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November [5] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE Based Networks", RFC 6282, September [6] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September [7] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February [8] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December [9] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September Informative References [10] "Near Field Communication - Interface and Protocol (NFCIP- 1) 3rd Ed.", ECMA-340, June Authors Addresses Yong-Geun Hong ETRI 161 Gajeong-Dong Yuseung-Gu Daejeon Korea Phone: yghong@etri.re.kr Hong, et al. Expires May 31, 2015 [Page 13]

14 Internet-Draft IPv6 over NFC November 2014 Younghwan Choi ETRI 218 Gajeongno, Yuseong Daejeon Korea Phone: Joo-Sang Youn DONG-EUI University 176 Eomgwangno Busan_jin_gu Busan Korea Phone: Dongkyun Kim Kyungpook National University 80 Daehak-ro, Buk-gu Daegu Korea Phone: JinHyouk Choi Samsung Electronics Co., 129 Samsung-ro, Youngdong-gu Suwon Korea Phone: jinchoe@samsung.com Hong, et al. Expires May 31, 2015 [Page 14]

15 6Lo Working Group Internet-Draft Intended status: Standards Track Expires: September 11, 2017 K. Lynn, Ed. Verizon Labs J. Martocci Johnson Controls C. Neilson Delta Controls S. Donaldson Honeywell March 10, 2017 Transmission of IPv6 over MS/TP Networks draft-ietf-6lo-6lobac-08 Abstract Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 11, Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust s Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents Lynn, et al. Expires September 11, 2017 [Page 1]

16 Internet-Draft IPv6 over MS/TP (6LoBAC) March 2017 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction Profile for IPv6 over MS/TP Addressing Modes Maximum Transmission Unit (MTU) LoBAC Adaptation Layer Stateless Address Autoconfiguration IPv6 Link Local Address Unicast Address Mapping Multicast Address Mapping Header Compression IANA Considerations Security Considerations Acknowledgments References Appendix A. Abstract MAC Interface Appendix B. Consistent Overhead Byte Stuffing [COBS] Appendix C. Encoded CRC-32K [CRC32K] Appendix D. Example 6LoBAC Frame Decode Authors Addresses Introduction Master-Slave/Token-Passing (MS/TP) is a medium access control (MAC) protocol for the RS-485 [TIA-485-A] physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 [RFC2460] packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. The general approach is to adapt elements of the 6LoWPAN specifications [RFC4944], [RFC6282], and [RFC6775] to constrained wired networks, as noted below. An MS/TP device is typically based on a low-cost microcontroller with limited processing power and memory. These constraints, together with low data rates and a small MAC address space, are similar to those faced in 6LoWPAN networks. MS/TP differs significantly from 6LoWPAN in at least three respects: a) MS/TP devices are typically mains powered, b) all MS/TP devices on a segment can communicate directly so there are no hidden node or mesh routing issues, and c) the latest MS/TP specification provides support for large payloads, eliminating the need for fragmentation and reassembly below IPv6. Lynn, et al. Expires September 11, 2017 [Page 2]

17 Internet-Draft IPv6 over MS/TP (6LoBAC) March 2017 The following sections provide a brief overview of MS/TP, then describe how to form IPv6 addresses and encapsulate IPv6 packets in MS/TP frames. This specifcation (subsequently referred to as "6LoBAC") includes a REQUIRED header compression mechanism that is based on LOWPAN_IPHC [RFC6282] and improves MS/TP link utilization Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] Abbreviations Used ASHRAE: American Society of Heating, Refrigerating, and Air- Conditioning Engineers ( BACnet: An ISO/ANSI/ASHRAE Standard Data Communication Protocol for Building Automation and Control Networks CRC: MAC: MSDU: MTU: UART: Cyclic Redundancy Code Medium Access Control MAC Service Data Unit (MAC client data) Maximum Transmission Unit; the size of the largest network layer protocol data unit that can be communicated in a single network transaction Universal Asynchronous Transmitter/Receiver 1.3. MS/TP Overview This section provides a brief overview of MS/TP, as specified in ANSI/ASHRAE Standard [BACnet] Clause 9. The latest version of [BACnet] integrates changes to legacy MS/TP (approved as [Addendum_an]) that provide support for larger frame sizes and improved error handling. [BACnet] Clause 9 also covers physical layer deployment options. MS/TP is designed to enable multidrop networks over shielded twisted pair wiring. It can support network segments up to 1000 meters in length at a data rate of kbit/s, or segments up to 1200 meters in length at lower bit rates. An MS/TP interface requires only a UART, an RS-485 [TIA-485-A] transceiver with a driver that can be disabled, and a 5 ms resolution timer. The MS/TP MAC is typically implemented in software. Lynn, et al. Expires September 11, 2017 [Page 3]

18 Internet-Draft IPv6 over MS/TP (6LoBAC) March 2017 The differential signaling used by [TIA-485-A] requires a contentionfree MAC. MS/TP uses a token to control access to a multidrop bus. Only an MS/TP master node can initiate the unsolicited transfer of data, and only when it holds the token. After sending at most a configured maximum number of data frames, a master node passes the token to the next master node (as determined by MAC address). If present on the link, legacy MS/TP implementations (including any slave nodes) ignore the frame format defined in this specification. [BACnet] Clause 9 defines a range of Frame Type values used to designate frames that contain data and data CRC fields encoded using Consistent Overhead Byte Stuffing [COBS] (see Appendix B). The purpose of COBS encoding is to eliminate preamble sequences from the Encoded Data and Encoded CRC-32K fields. The Encoded Data is covered by a 32-bit CRC [CRC32K] (see Appendix C) that is also COBS encoded. MS/TP COBS-encoded frames have the following format: x55 0xFF Frame Type DA SA Length (MS octet first) Header CRC Encoded Data ( octets) Encoded CRC-32K (5 octets) optional 0xFF Figure 1: MS/TP COBS-Encoded Frame Format MS/TP COBS-encoded frame fields are defined as follows: Preamble two octet preamble: 0x55, 0xFF Frame Type one octet Destination Address one octet address Source Address one octet address Length two octets, most significant octet first Header CRC one octet Encoded Data octets (see Section 4 and Appendix B) Encoded CRC-32K five octets (see Appendix C) (pad) (optional) at most one octet of trailer: 0xFF Lynn, et al. Expires September 11, 2017 [Page 4]

19 Internet-Draft IPv6 over MS/TP (6LoBAC) March 2017 The Frame Type is used to distinguish between different types of MAC frames. The types relevant to this specification (in decimal) are: 0 Token 1 Poll For Master 2 Reply To Poll For Master 3 Test_Request 4 Test_Response IPv6 over MS/TP (LoBAC) Encapsulation Frame Types 8-31 and are reserved for assignment by ASHRAE. Frame Types designate COBS-encoded frames that convey Encoded Data and Encoded CRC-32K fields. See Section 2 for additional details. The Destination and Source Addresses are each one octet in length. See Section 3 for additional details. For COBS-encoded frames, the Length field indicates the size of the [COBS] Encoded Data field in octets, plus three. (This adjustment is required in order for legacy MS/TP devices to ignore COBS-encoded frames.) See Section 4 and Appendices for additional details. The Header CRC field covers the Frame Type, Destination Address, Source Address, and Length fields. The Header CRC generation and check procedures are specified in [BACnet] Annex G.1. Use of the optional 0xFF trailer octet is discussed in [BACnet] Clause Goals and Constraints The main goals of this specification are a) to enable IPv6 directly on wired end devices in building automation and control networks by leveraging existing standards to the greatest extent possible, and b) to co-exist with legacy MS/TP implementations. Co-existence allows MS/TP networks to be incrementally upgraded to support IPv6. In order to co-exist with legacy devices, no changes are permitted to the MS/TP addressing modes, frame header format, control frames, or Master Node state machine as specified in [BACnet] Clause Profile for IPv6 over MS/TP ASHRAE has assigned an MS/TP Frame Type value of 34 to indicate IPv6 over MS/TP (LoBAC) Encapsulation. This falls within the range of values that designate COBS-encoded data frames. Lynn, et al. Expires September 11, 2017 [Page 5]

20 Internet-Draft IPv6 over MS/TP (6LoBAC) March Mandatory Features [BACnet] Clause 9 specifies mandatory to implement features of MS/TP devices. E.g., it is mandatory that all MS/TP nodes respond to a Test_Request with a Test_Response frame. All MS/TP master nodes must implement the Master Node state machine and handle Token, Poll For Master, and Reply to Poll For Master control frames. 6LoBAC nodes are MS/TP master nodes that implement a Receive Frame state machine capable of handling COBS-encoded frames. 6LoBAC nodes must support a data rate of kbit/s and may support lower data rates as specified in [BACnet] Clause 9. The method of selecting the data rate is outside the scope of this specification Configuration Constants The following constants are used by the Receive Frame state machine. Nmin_COBS_length The minimum valid Length value of any LoBAC encapsulated frame: 5 Nmax_COBS_length The maximum valid Length value of any LoBAC encapsulated frame: Configuration Parameters The following parameters are used by the Master Node state machine. Nmax_info_frames The default maximum number of information frames the node may send before it must pass the token: 1 Nmax_master The default highest allowable address for master nodes: 127 The mechanisms for setting parameters or monitoring MS/TP performance are outside the scope of this specification. 3. Addressing Modes MS/TP node (MAC) addresses are one octet in length and assigned dynamically. The method of assigning MAC addresses is outside the scope of this specification. However, each MS/TP node on the link MUST have a unique address in order to ensure correct MAC operation. [BACnet] Clause 9 specifies that addresses 0 through 127 are valid for master nodes. The method specified in Section 6 for creating a MAC-address-derived Interface Identifier (IID) ensures that an IID of all zeros can never be generated. Lynn, et al. Expires September 11, 2017 [Page 6]

21 Internet-Draft IPv6 over MS/TP (6LoBAC) March 2017 A Destination Address of 255 (all nodes) indicates a MAC-layer broadcast. MS/TP does not support multicast, therefore all IPv6 multicast packets MUST be broadcast at the MAC layer and filtered at the IPv6 layer. A Source Address of 255 MUST NOT be used. Hosts learn IPv6 prefixes via router advertisements according to [RFC4861]. 4. Maximum Transmission Unit (MTU) Upon transmission, the network layer MTU is formatted according to Section 5 and becomes the MAC service data unit (MSDU). The MSDU is then COBS encoded by MS/TP. Upon reception, the steps are reversed. [BACnet] Clause 9 supports MSDUs up to 2032 octets in length. IPv6 [RFC2460] requires that every link in the internet have an MTU of 1280 octets or greater. Additionally, a node must be able to accept a fragmented packet that, after reassembly, is as large as 1500 octets. This specification defines an MTU length of at least 1280 octets and at most 1500 octets. Support for an MTU length of 1500 octets is RECOMMENDED. 5. LoBAC Adaptation Layer This section specifies an adaptation layer to support compressed IPv6 headers as specified in Section 10. IPv6 header compression MUST be implemented on all nodes. Implementations MAY also support Generic Header Compression [RFC7400] for transport layer headers. The LoBAC encapsulation format defined in this section describes the MSDU of an IPv6 over MS/TP frame. The LoBAC payload (i.e., an IPv6 packet) follows an encapsulation header stack. LoBAC is a subset of the LoWPAN encapsulation defined in [RFC4944] as updated by [RFC6282] so the use of "LOWPAN" in literals below is intentional. The primary difference between LoWPAN and LoBAC encapsulation is omission of the Mesh, Broadcast, Fragmentation, and LOWPAN_HC1 headers in the latter. All LoBAC encapsulated datagrams transmitted over MS/TP are prefixed by an encapsulation header stack consisting of a Dispatch value followed by zero or more header fields. The only sequence currently defined for LoBAC is the LOWPAN_IPHC header followed by payload, as shown below: IPHC Dispatch IPHC Header Payload Figure 2: A LoBAC Encapsulated LOWPAN_IPHC Compressed IPv6 Datagram Lynn, et al. Expires September 11, 2017 [Page 7]

22 Internet-Draft IPv6 over MS/TP (6LoBAC) March 2017 The Dispatch value is treated as an unstructured namespace. Only a single pattern is used to represent current LoBAC functionality. Pattern Header Type xxxxx LOWPAN_IPHC - LOWPAN_IPHC compressed IPv6 [RFC6282] Figure 3: LoBAC Dispatch Value Bit Pattern Other IANA-assigned 6LoWPAN Dispatch values do not apply to 6LoBAC unless otherwise specified. 6. Stateless Address Autoconfiguration This section defines how to obtain an IPv6 Interface Identifier. This specification distinguishes between two types of IID, MACaddress-derived and semantically opaque. A MAC-address-derived IID is the RECOMMENDED type for use in forming a link-local address, as it affords the most efficient header compression provided by the LOWPAN_IPHC [RFC6282] format specified in Section 10. The general procedure for creating a MAC-address-derived IID is described in [RFC4291] Appendix A, "Creating Modified EUI-64 Format Interface Identifiers", as updated by [RFC7136]. The Interface Identifier for link-local addresses SHOULD be formed by concatenating the node s 8-bit MS/TP MAC address to the seven octets 0x00, 0x00, 0x00, 0xFF, 0xFE, 0x00, 0x00. For example, an MS/TP MAC address of hexadecimal value 0x4F results in the following IID: A semantically opaque IID having 64 bits of entropy is RECOMMENDED for each globally scoped address and MAY be locally generated according to one of the methods cited in Section 12. A node that generates a 64-bit semantically opaque IID MUST register the IID with its local router(s) by sending a Neighbor Solicitation (NS) message with the Address Registration Option (ARO) and process Neighbor Advertisements (NA) according to [RFC6775]. An IPv6 address prefix used for stateless autoconfiguration [RFC4862] of an MS/TP interface MUST have a length of 64 bits. Lynn, et al. Expires September 11, 2017 [Page 8]

23 Internet-Draft IPv6 over MS/TP (6LoBAC) March IPv6 Link Local Address The IPv6 link-local address [RFC4291] for an MS/TP interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/ bits 54 bits 64 bits (zeros) Interface Identifier Unicast Address Mapping The address resolution procedure for mapping IPv6 non-multicast addresses into MS/TP MAC-layer addresses follows the general description in Section 7.2 of [RFC4861], unless otherwise specified. The Source/Target Link-layer Address option has the following form when the addresses are 8-bit MS/TP MAC-layer (node) addresses Type Length= x00 MS/TP Address Padding (all zeros) Option fields: Type: 1: for Source Link-layer address. 2: for Target Link-layer address. Length: This is the length of this option (including the type and length fields) in units of 8 octets. The value of this field is 1 for 8-bit MS/TP MAC addresses. MS/TP Address: The 8-bit address in canonical bit order [RFC2469]. This is the unicast address the interface currently responds to. Lynn, et al. Expires September 11, 2017 [Page 9]

24 Internet-Draft IPv6 over MS/TP (6LoBAC) March Multicast Address Mapping All IPv6 multicast packets MUST be sent to MS/TP Destination Address 255 (broadcast) and filtered at the IPv6 layer. When represented as a 16-bit address in a compressed header (see Section 10), it MUST be formed by padding on the left with a zero octet: x00 0xFF Header Compression 6LoBAC REQUIRES LOWPAN_IPHC IPv6 compression, which is specified in [RFC6282] and included herein by reference. This section will simply identify substitutions that should be made when interpreting the text of [RFC6282]. In general the following substitutions should be made: - Replace instances of "6LoWPAN" with "MS/TP network" - Replace instances of "IEEE address" with "MS/TP address" When a 16-bit address is called for (i.e., an IEEE "short address") it MUST be formed by padding the MS/TP address to the left with a zero octet: x00 MS/TP address If LOWPAN_IPHC compression [RFC6282] is used with context, the router(s) directly attached to the MS/TP segment MUST disseminate the 6LoWPAN Context Option (6CO) according to [RFC6775], Section IANA Considerations This document uses values previously reserved by [RFC4944] and [RFC6282] and makes no further requests of IANA. Note to RFC Editor: this section may be removed upon publication. Lynn, et al. Expires September 11, 2017 [Page 10]

25 Internet-Draft IPv6 over MS/TP (6LoBAC) March Security Considerations See [RFC8065] for a general discussion of privacy threats faced by constrained nodes. [RFC8065] makes a distinction between "stable" and "temporary" addresses. The former are long-lived and typically advertised by servers. The latter are typically used by clients and SHOULD be changed frequently to mitigate correlation of activities over time. Nodes that engage in both activities SHOULD support simultaneous use of multiple addresses per device. Globally scoped addresses that contain MAC-address-derived IIDs may expose a network to address scanning attacks. For this reason, it is RECOMMENDED that a 64-bit semantically opaque IID be generated for each globally scoped address in use according to, for example, [RFC3315], [RFC3972], [RFC4941], [RFC5535], or [RFC7217]. 13. Acknowledgments We are grateful to the authors of [RFC4944] and members of the IETF 6LoWPAN working group; this document borrows liberally from their work. Ralph Droms and Brian Haberman provided indispensable guidance and support from the outset. Peter van der Stok, James Woodyatt, Carsten Bormann, and Dale Worley provided detailed reviews. Stuart Cheshire invented the very clever COBS encoding. Michael Osborne made the critical observation that encoding the data and CRC32K fields separately would allow the CRC to be calculated on-the-fly. Alexandru Petrescu, Brian Frank, Geoff Mulligan, and Don Sturek offered valuable comments. 14. References Normative References [BACnet] American Society of Heating, Refrigerating, and Air- Conditioning Engineers, "BACnet - A Data Communication Protocol for Building Automation and Control Networks", ANSI/ASHRAE Standard , January 2016, < ashrae ?product_id= #jumps>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI /RFC2119, March 1997, < Lynn, et al. Expires September 11, 2017 [Page 11]

26 Internet-Draft IPv6 over MS/TP (6LoBAC) March 2017 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI /RFC2460, December 1998, < [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI /RFC3315, July 2003, < [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI /RFC3972, March 2005, < [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI /RFC4291, February 2006, < [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI /RFC4861, September 2007, < [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI /RFC4862, September 2007, < [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI /RFC4941, September 2007, < [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE Networks", RFC 4944, DOI /RFC4944, September 2007, < [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, DOI /RFC5535, June 2009, < [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE Based Networks", RFC 6282, DOI /RFC6282, September 2011, < Lynn, et al. Expires September 11, 2017 [Page 12]

27 Internet-Draft IPv6 over MS/TP (6LoBAC) March 2017 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI /RFC6775, November 2012, < [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI /RFC7136, February 2014, < [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI /RFC7217, April 2014, < [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7400, DOI /RFC7400, November 2014, < Informative References [Addendum_an] American Society of Heating, Refrigerating, and Air- Conditioning Engineers, "ANSI/ASHRAE Addenda an, at, au, av, aw, ax, and az to ANSI/ASHRAE Standard , BACnet - A Data Communication Protocol for Building Automation and Control Networks", July 2014, < _135_2012_an_at_au_av_aw_ax_az_Final.pdf>. [COBS] [CRC32K] Cheshire, S. and M. Baker, "Consistent Overhead Byte Stuffing", IEEE/ACM TRANSACTIONS ON NETWORKING, VOL.7, NO.2, April 1999, < Koopman, P., "32-Bit Cyclic Redundancy Codes for Internet Applications", IEEE/IFIP International Conference on Dependable Systems and Networks (DSN 2002), June 2002, < koopman/networks/dsn02/ dsn02_koopman.pdf>. [IEEE.802.3_2012] IEEE, " ", IEEE , DOI /ieeestd , January 2013, < opac?punumber= >. Lynn, et al. Expires September 11, 2017 [Page 13]