]> Huawei Technologies France S.A.S.U.

18, Quai du Point du Jour Boulogne-Billancourt 92100 France ggx@gigix.net

Huawei Technologies

Beiqing Road, Haidian District Beijing 100095 China liguangpeng@huawei.com

Huawei Technologies Duesseldorf GmbH

Riesstrasse 25 Munich 80992 Germany zhe.lou@huawei.com

China Mobile

No. 53, Xibianmen Inner Street, Xicheng District Beijing 100053 China liupengyjy@chinamobile.com

Roquefort-les-Pins 06330 France pascal.thubert@gmail.com

Internet 6lo Working Group Internet-Draft This document specifies a topological addressing scheme, Path-Aware Semantic Addressing (PASA), that enables stateless IP packet forwarding. The forwarding decision is based solely on the destination address structure. This document focuses on carrying IP packets across an LLN (Low power and Lossy Network), in which the topology is quite static, the location of the nodes is fixed for long period of time, and the connection between the nodes is also rather stable. This document specifies the PASA architecture, along with the PASA address allocation, forwarding mechanism, routing header format, and IPv6 interconnection support.

Introduction There is an ongoing massive expansion of the network edge, driven by the "Internet of Things" (IoT), especially over Low power Lossy Networks (LLNs) which often, in the past, did not support IP packet transmission. Driven by the requirements stemming initiatives like Industry 4.0 , Smart Grid, and Smart City , among others, an increasing number of devices and "things" are being connected to the Internet. Sensors in plants/parking bays/mines/data-centers, temperature/humidity/flash sensors in buildings/museums, normally are located in a fixed position and are networked by low power and lossy links even in hardwired networks. Comparing with traditional scenarios, scalability of the (edge) network along with lower power consumption are key technical requirements. Moreover, large-scale Low power Lossy Networks (LLNs) are expected to be able to carry IPv6 packets over their links, together with an efficient access to native IPv6 domains. The work in , , , and Working Groups addresses many fundamental issues for those types of deployments, which can be considered an instantiation of what defines as "limited domains". For instance, the 6LoWPAN compression (, ) addresses the problem of IPv6 transmission over LLNs, making it possible to interconnect IPv6-based IoT networks and the Internet. introduces a framework for implementing multi-hop routing on an LLN using a compressed routing header, which works also with RPL (Routing Protocol for LLNs ). This technique enables the ability to forward IPv6 packets within the domain without the need of decompression. In addition, SCHC (Generic Framework for Static Context Header Compression and Fragmentation ) enables even more compression by using a common stateful static context. The aforementioned technologies, which when used in multi-hop network topologies leverage on the presence of a routing protocol, are suitable in generic IoT scenarios and LLN networks. These technologies leverage topology discovery and routing mechanisms, whereas there are several special-purpose networks, where routing protocols are not deployed and the networks are statically manageable (e.g. Power Line Communication (PLC) or Master-Slave/Token-Passing (MS/TP) , and Industrial IoT technologies like , etc.). In these kinds of deployments, topologies are planned in advance and well provisioned, with sensor nodes usually in fixed locations. This document introduces a topology-based addressing mechanism that allows, in the latter scenarios, to avoid the use of routing protocol in favor of a topological "stateless" forwarding algorithm (see ). Where the term "stateless" is used to indicate that there is no routing table, i.e. no state, to be looked-up in order to perform the forwarding operation, rather the destination address itself encodes the forwarding direction (see ). The syntax of the IPv6 addresses used in the present specification is unchanged, as for , however, the way addresses are assigned adds path awareness semantic to them, hence the name "Path-Aware Semantic Addressing". This specification document leverages on the 6Lo Routing Header (6LoRH) as defined in and LOWPAN_IPHC header compression . The use of other compression techniques is out of the scope of this document, and may be the object of separate specifications. The specified addressing is independent of Unique Local Addresses , which has a dependency on specific link-layer conventions . It is also different from stateful address allocation that requires all nodes to obtain addresses from a centralized DHCP server, which leads to increased network startup time and consumption of extra resources, such as bandwidth and energy. Path-Aware Semantic Addressing (PASA), defined in this document, relies on the neighbor discovery Generic Address Assignment Option (GAAO) in order to recursively assign addresses.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Definition of Terms

Address Assignment Function (AAF):

As defined in .

Tree Address Assignment Function (TAAF):

AAF defined in , this function assigns addresses using a tree policy where the address of a parent node is used as prefix for the addresses of its children. It is used by PASA Root and PASA Routers to assign addresses to their children.

PASA Root:

The PASA Root is the router responsible for the management of the whole PASA network and routing/forwarding both internal and external traffic. It uses an Address Assignment Function (AAF) and performs the address assignment for its children. The root node functions as gateway between the PASA Domain and the Internet, acting as what names 6LBR (6LoWPAN Border Router).

PASA Host:

A PASA Host is a node with no children (i.e., a leaf), it is what names 6LN (6LoWPAN Node). This node does not perform the AAF. It merely requests an address from its selected parent.

PASA Router:

A PASA Router is an internal node, different from the PASA Root, acting as a router, hence as what names 6LR (6LoWPAN Router). Before acting as a router, it will act as a PASA Host by acquiring an address. Then, similar to the PASA Root, it uses the AAF and performs the address assignment for its children. According to and , PASA Routers are expected to store in non-volatile memory state about address registration and assignment.

PASA Domain:

A network limited domain in which PASA is deployed.

Comprehensive Use Cases As mentioned in , provides some 6lo use cases with wired connectivity, tree-based topology, and no mobility requirement (cf. Table 2 of ). The usage of PASA is well suited for such use cases, which include Smart Grid, Smart Building, etc., were topologies remain unchanged for long period of time, and very often topology changes are known in advance. In this context PASA makes possible to have simple deployments that do not use a routing protocol.
On the contrary, in use cases that include mobility and less reliable links connectivity, the use of PASA is not a good fit, as topology changes in the context of PASA imply address renumbering.
The PASA solution utilizes stable topology information to allocate addresses for nodes, which enables stateless forwarding. It saves overhead of messages triggered by routing protocols and reduces RAM footprint for routing table storage. Thus, it reduces the overall energy consumption. The PASA forwarding logic is simple, enabling the solution being ported onto very constrained nodes. Yet, networks are unlikely to be immutable, changes, even at large time scale, happen (e.g., change of sensors, new smart-furniture, etc.). PASA can handle very easily changes at the edge (leaves) of the topology, but may require some reconfiguration for more important topology changes (see for details). In the following, a few use cases are discussed in-depth to demo the applicability of the PASA solution.

Smart Grid A typical smart grid network topology whose purpose is to distribute electricity to homes in a residential area consists of Smart Circuit Breaker (SCB), Phase Change Switch (PCS), Cable Branch Box (CBB) and Power Distribution Cabinet (PDC), as shown in . The PDC, containing a few SCBs, phase compensation units, sensors and actuators, is responsible for the power distribution towards CBBs. The CBB containing SCBs and sensors further distributes the power to PCS and eventually to the home. The smart grid power distribution network forms a typical tree topology, where the PLC technology is used to collect data (meter numbers, phases, etc.) and perform control/management of the overall system.

Smart Home Smart home or home domotics is another example, as shown in , where a PLC router (PLC-R) in each room is used to connect home appliances (boiler, dishwasher, fridge, etc.) and devices (lights, doorbell, sound boxes, etc.) to home network and sometimes to the Internet. The network can be further extended if a switch/router is connected. As it leverages the power line distribution, the network forms a typical tree topology as well. A typical smart home network is connected to the Internet through a Home Gateway (PLC router), which serves as the bridge between the home network and external services. Within the home, PLC routers, and most appliances are installed at fixed locations and generally remain stationary after deployment, although the network can be expanded over time by adding new smart devices. Smart home automation applications require any-to-any communication among devices to support monitoring, control, and coordination. In addition, because many smart devices are built on resource-constrained hardware, the communication stack should be lightweight and minimize Microcontroller Unit (MCU) and RAM usage. In this context, PASA is a good fit, since it does not require the network to run a stand-alone routing protocol.

Data Center Monitoring Data centers represent a significant infrastructure, requiring to be protected from environmental issues such as extreme temperature, high humidity, water leakage and high dust concentration, which can cause device failures. Therefore, it is critical to deploy sensors to monitor environmental factors to make sure data center is running efficiently. The network topology of the data center supervision system is hierarchical, and mainly consists of Network Management System (NMS), Supervision Center (SC), Field Supervision Unit (FSU), dumb and smart devices, as shown in . The smart devices refer to smart air conditioner, smart door lock and power equipment with embedded sensors to report their working status. The dumb devices refer to the many devices without embedded sensors, which require additional sensors to collect and update information of environment.

Both dumb and smart devices are connected to the FSU, which monitors and connects all devices of the whole floor. The number of ports on FSU is limited, where one FSU usually contains 8 analog input ports, 16 digital input ports, 4 digital output ports, 8 RS485 ports and 4 IP ports. The terminal devices report working status and environmental information to FSUs every 3 seconds. If values that are abnormal or above a certain threshold are detected, the FSU reports it to the SC immediately and keeps on reporting it in real-time for next couple of hours, until the manager issues new commands. The SC can be constructed as required. The FSU reports to the local SC first, then relays the message to the central SC for data analyzing and management. In this scenario, deployed devices (usually, 600-1000 sensors per floor), due to the shortage of ports and limitation of voltage supply, use additional power supply or batteries. Since battery replacement and maintenance are costly, it is desired to have low energy consumption for longer service life. We should not only reduce the power consumption on the device level, but also on the data transmission level. The data transmission also causes huge power consumption, which can be reduced by leveraging low power transmission protocol. The FSU connects to sensors with wired technology, such as , , , , and single pair Ethernet . Multiple FSUs will connect to hierarchical supervision centers and then make data communication with supervision platform by IPv6.

Industrial Operational Technology Networks The Operational Technology (OT) networks are not pure IP networks. Shop floors deploy fieldbus protocols such as Modbus, Profinet/IP, BacNET, CAN, etc. for process control using field devices (sensors and actuators). To improve automation, Industry 4.0 is looking at means to integrate process control in OT domain with the applications residing in IPv6 domains (the enterprise networks). This leads to three primary requirements: Continuity in connectivity between the end devices and applications, both of which follow different address structures. The OT networks are traditionally designed as layer-2 and OT operators are not expected to deploy or maintain IT style routing infrastructure, hence auto-configuration mechanisms for device addresses and reachability are preferred. The OT networks are also delay-intolerant; therefore, compact and lean message structures are favored over encapsulations to minimize processing and translation overheads. Using PASA, as specified in details later in this document, the following applies: The OT network is represented as a PASA Domain, interfacing with native IPv6 applications, e.g., Human-Machine Interface (HMI), Manufacturing Execution System (MES). In general, on industrial premises, devices are at fixed locations or cell-sites and the PASA tree hierarchy described in applies suitably. In an idealized PASA-based OT domain, a leaf-node could be a field device (sensor or actuator) that always connects to PLC serving as last node forwarding traffic to/from the leaves, i.e. sensors and actuators. Hence, the PLC will work as a PASA Router only for field devices supporting IPv6. For field devices not supporting IPv6, the PLC will assign PASA addresses for each of them, and then translate between IPv6 packets and the device protocol, making the devices appear as PASA Hosts within the enclosing PASA Domain. The border node may be at the root for any IT application requirement. Then the packet communication inside the PASA Domain will strictly follow PASA structure whereas communications with IPv6 domain networks will use the Border router for translations.

Architectural Overview PASA is an efficient topology-based network layer address assignment and packet forwarding mechanism. The overall design objective is centered on reducing the size of routing/forwarding tables by using a topological addressing scheme. PASA reduces the amount of information synchronization messages, so it actually reduces computation complexity during packets parsing and forwarding. As such, PASA may save communication energy in an IoT LLN network . Compared to RPL-based routing , PASA avoids the extra overhead of address assignment by integrating address assignment and tree forming together. Compared to RPL storing mode, PASA uses smaller forwarding tables, hence less memory, since there is no need to store topology information. Compared to RPL non-storing mode, PASA has lower overhead in terms of bandwidth since, instead of an explicit list of addresses, it encodes the path directly in the address itself. The overhead in both modes, while smaller compared to routing protocols not designed for 6LoWPAN environments, is still not negligible . PASA addressing has also lower overhead compared to BABEL, since there is no need to share a routing table among neighbors (, ). Each PASA node is aware of its own IPv6 address (see ), constructed with an IPv6 prefix and the PASA TAAF (see ). Inside the PASA Domain, nodes communicate with each other by using PASA addresses. It is a smaller addressing space compared to the huge /64 IPv6 addressing space, but enabling stateless forwarding using the PASA-6LoRH header (see ). When IPv6 communication occurs between nodes inside the PASA Domain and external IPv6 nodes, the border router, which plays as well the role of "root" in the addressing tree, performs header decompression (as per and ). Note that packets destined outside the PASA Domain do not need to use the header compression, since they can be easily forwarded to the root following the default gateway (see ). The architecture of PASA network is shown in .

In the PASA network, the 3 types of nodes, namely the PASA Root, the PASA Router and the PASA Host (See ), operate in the following manner:

PASA Root:

Since the root node is responsible for the whole PASA network and acts as gateway for external traffic, it also operates the translation between LOWPAN_IPHC and IPv6 formats (cf. ). It assigns addresses to its children using the TAAF. There is one root node in the PASA network.

PASA Router:

A PASA Router operates as the root of a subtree and as such it operates as a router forwarding traffic between its parent and its children according to the addressing. When handling a packet, if the destination is in one of its subtrees, it forwards the packet to the corresponding child, otherwise it simply sends it to its parent.

PASA Host:

A PASA Host is a node with no children, hence a leaf. It operates as a host, since it is either destination or source of every packet it handles. If it is the source of packets, it simply sends the packets to its parent.

The address assignment described in this document relies on the Generic Address Assignment mechanism described in (see ). The use of multicast messages is limited as for ; PASA does not require multicast communication. The PASA Root and PASA Routers have to act as IPv6 Routing Registrars (). Each node newly joining the network and acquiring a PASA address firstly needs to select a parent node by choosing among the nodes that replied with a Router Advertisement (RA) after an initial Router Solicitation (RS). In general, "first come first served" selection policy may be sufficient; however, some deployments may have tighter constraints on the 6LR selection, but enforcing such selection is beyond the scope of this document; can be used in such cases. Once the parent node is selected, the node asks for a PASA address. In its reply the parent will propose an address according to the node's role, which is indicated in the D-bit of the GAAO message (see ). The proposed address is algorithmically calculated using the PASA TAAF. The address assigner is the parent of the node and becomes as well the default gateway from a routing perspective (used for destinations that are not in the local PASA Domain). The node will then ignore replies from other 6LR neighbors. A node that, for any reason, reboots does not need to restart the whole procedure. According to and address registration state has to be stored in non-volatile memory, hence, when the nodes is up again there is no need to go through parent selection and address request, it can just re-register the previously obtained address. There are two distinct PASA features that allow PASA to be efficient, namely: PASA Tree Address Assignment Function (see ), Stateless Forwarding (see ), these features are separately discussed in the following.

PASA Address Assignment Per GAAO, the basic rules for the PASA address assignment include: PASA Root and PASA Routers run the TAAF to generate their children's addresses. The maximum length of the PASA address MUST NOT exceed 64 bits. In the following, a Tree-based AAF is specified for PASA. Since such a function is based on encodings that go dow to the single bit, addresses are show as binary bit strings in quotation marks, in order to provide clear specifications of how addresses are build.

Tree Address Assignment Function (TAAF) In the Tree Address Assignment Function the address of each node is prefixed by the address of their parent, starting from the root. Normally, the root role is assigned to the 6LBR when the LLN bootstraps. PASA Root MUST use the single bit address '1', i.e., using the IID of ::1 (see ). An example of a possible result of a PASA deployment is shown in .

Every PASA Router node maintains two indexes, one for the children that are also PASA Routers and one for the children that are hosts (starting at 0 for the first child in each role). The first index is named 'r', as of Routers, and the second 'h' as for Hosts. These two indexes MUST be stored in non-volatile memory along with address assignment state, so that in case of reboot a PASA-Router can continue its role without disrupting the addressing. PASA Routers' address MUST terminate with the bit '0', while PASA Hosts' address MUST terminate with the bit '1'.
The Tree Address Allocation Function TAAF(role,r,h) used in this document is defined as:

Where 'r' and 'h' are the two indexes defined above, respectively the PASA Routers and the PASA Hosts at this layer (starting at 0). The '+' symbol indicates a concatenation operation. The symbol '++' is the equivalent of the C language increment operator used as postfix, meaning that the value of the variable is increase after its use in the expression . The b() operation indicates the binary string of '1' with length equal to its argument, for instance b(3) returns '111' and b(0) returns an empty string. Taking the example of the topology in , TAAF works as follows. At the top level, the root has 4 children, two are PASA Routers and the other two are PASA Hosts. Starting from the left most node and moving to the right, the root node applies the TAAF as follows: For the first child, which is a PASA Router:

• Index 'r' is increased by one after its value '0' has been used in the expression and is now equal to 1 (r = 1).

For the second child, which is a PASA Host:

• Index 'h' is increased by one after its value '0' has been used in the expression and is now equal to 1 (h = 1).

For the third child, which is a PASA Router:

• Index 'r' is increased by one after its value '1' has been used in the expression and is now equal to 2 (r = 2).

For the fourth child, which is a PASA Host:

• Index 'h' is increased by one after its value '1' has been used in the expression and is now equal to 2 (h = 2).

The first level addresses have now been assigned. Let's now have a look to how the node 10 (the first PASA Router child of the root) applies the same allocation function. Note that node 10 will use its own 'r' and 'h' indexes initialized to 0. Starting again from the left most node, node 10 applies the TAAF as follows: For the first child, which is a PASA Router:

• Index 'r' is increased by one after its value '0' has been used in the expression and is now equal 1 (r = 1).

For the second child, which is a PASA Host:

• Index 'h' is increased by one after its value '0' has been used in the expression and is now equal 1 (h = 1).

For the third child, which is a PASA Router:

• Index 'r' is increased by one after its value '1' has been used in the expression and is now equal 2 (r = 2).

For the fourth child, which is a PASA Host:

• Index 'h' is increased by one after its value '0' has been used in the expression and is now equal 2 (h = 2).

Note how the children of the same parent all have the same prefix (10 in this example) and such parent will be their default gateway. TAAF algorithmically assigns addresses to the different nodes without the need to know the topology in advance. However, once the addresses have been assigned, TAAF encodes the topology in the addresses themselves, which enables stateless forwarding, but if used beyond the PASA Domain it exposes the internal topology. See for further details. TAAF creates unique addresses for each node, as such there is no need to perform Duplicate Address Detection (DAD) procedure.

Limitation on the Number of Child Nodes The maximum number of children of a node is determined by the specific AAF used. IEEE 802.15.5 has explored the use of a per-branch setup, which, however, incurs scalability problems . PASA allocation design is more flexible and extensible than the one proposed in IEEE 802.15.5. The TAAF defined in this document does not need any network-specific setup, though it is still limited by the maximum length of addresses. The largest address of the network will depend on the actual topology. Indeed, the maximum length of an address with TAAF grows linearly at each level of the tree with the number of siblings from the same parent. Let’s take again the example in and let’s assume that the children of node 10 are all hosts, for the largest address we need 2 bits to encode the parent node prefix (10 in this case) to which we need to add a number of '1' equal to the value of the h index which is the number of hosts minus one (because the first host has index 0), in this case since there are 4 hosts, the index value is 3 and we add the '111' string, hence the address length would be 6 (2 for the prefix, 3 to encode the 4th host address, and one for the final 1 that ends all hosts' addresses). In a more formal way the maximum address length at each level can be calculated as:

• Where 'r' and 'h' are the indexes counting respectively the PASA Routers and the PASA Hosts at this level.

Note that Max_length can never be more than 64 bits, the IID part of an IPv6 address. This means that, with TAAF, each PASA Router with an address of length N bits, can have maximum "64 - N - 1" children of the same type. This is because the construction of the addresses. Each new child's address starts with the address of the parent, which is N bits, and ends with one bit indicating the role (either PASA Router or PASA Host), and the whole length can be at maximum 64 bits, the IID of an IPv6 address. For deployments where parents connect to a large number of children, which are out of the scope of the present document, alternative solutions may be considered. For instance, a variant of TAAF can be designed to fulfill the requirement and optimize the address allocation (as previously described). Alternatively, the use of other algorithmically structured addressing schemes, like for instance , , and can be explored. Such approaches aim at simplifying routing and reduce forwarding state, however the effectiveness of the header compression may be impacted.

PASA TAAF Addresses and IPv6 Addresses Obtaining a full IPv6 address from a PASA address is pretty straightforward. First the PASA address is concatenated to the configured IPv6 prefix. Since the length of the PASA address is smaller than or equal to 64 bits (the Interface ID length in IPv6), the node needs to pad it with zeros ('0') used as most significant bit. The full IPv6 address will look like: IPv6 prefix + "000...000" + PASA (or in IPv6 notation <IPv6 Prefix>::<PASA>). This is equivalent of doing a coalescence operation as described in (see as well ). The PASA address is assigned by the PASA Root or PASA Router as previously described. The converse operation, from full IPv6 format to PASA format is very simple. Firstly, the configured IPv6 prefix is cut out. Secondly, on the remaining 64 bits, all leading zeros can be trimmed. Indeed, because all TAAF addresses are derived from the PASA Root, and since the latter has address '1', all TAAF generated addresses always start with '1' (See ). As such, trimming the leading zeros is a safe operation returning a PASA TAAF address. PASA does not prevent the normal checksum calculation for the transport layer (e.g., TCP or UDP) or IPsec encapsulation. Indeed, any PASA node is aware of its full IP address, which can be used for the calculation.

Forwarding in a PASA Network Communications within the PASA domain and communications with endpoints outside the PASA domain operate differently. The following sections specify the forwarding operations for both cases. The intra-domain forwarding decision depends on the TAAF previously introduced (see ).

Forwarding toward an endpoint in the PASA domain Packets destined to an endpoint in the PASA domain carry a PASA destination address in the PASA-6LoRH header, even in the case of packets arriving from endpoints ooutside the PASA Domain. Indeed, in this latter case, the PASA Root will perform header compression according to and also described in . Then, it will extract the PASA address of the destination, by removing the prefix and the leading '0's octets of the destination IID, and use it in the PASA-6LoRH header prepended to the original packet. In the specified TAAF algorithm the length of the addresses increases with the distance from the root, whose address has length 1 bit. The length function, indicated by Len(X), of a PASA address X, returns the number of bits between the most significant bit of the IID that is set to 1 and the least significant bit. For instance, for an address encoded on two octets, Len(b00010010) = 5.
Furthermore, the address of a PASA Router is the prefix of the addresses of all its children. The function PrefixOf(P,X) returns true is the address P is the prefix of of the address X. For instance, let's take the address b100 and b10010, in this case PrefixOf(b100, b10010) returns true as the first address is exactly the same as the most significative bits of the second address. Note that the order is important, PrefixOf(b10010,b100) returns false, since Len(b10010) is greater than Len(b100).
Such properties can be used to quickly take forwarding decisions. Indeed, when a PASA Router receives a packet destined the local PASA Domain, one of the following three cases arise: The length of the destination address is shorter than the address of the PASA Router. This means the destination is closer to the root and just forwarding to its parent is enough. The length of the destination address is equal to the address of the PASA Router. In this case the destination is either the PASA Router itself, or another node in a different branch of the tree. The PASA Router compares its address and the destination address. If they are equal, then the packet has reached its destination. Otherwise the packet has to be sent to the parent in order to reach the right branch. The length of the destination address is greater than the address of the PASA Router. In this case the destination is either in a sub-branch rooted in PASA Router itself or in a totally different branch of the tree. In the former case the packet has to be forwarded toward the correct child, in the latter just sent to the parent. In order to decide which operation to do, the PASA router compares its own address with the most significant bits of the destination address, in other words whether its own address is a prefix of the destination address. If there is a match, then a child is selected as next hop based on the remaining bits of the destination address, otherwise, the destination is in a totally different branch and the packet is sent to the parent. More formally, when a PASA node receives a packet, it performs the following sequence of actions (also see ): Get Destination Address from the PASA-6LoRH (abbreviated to DA) and the Node's Own Address (abbreviated to NOA). Go to step 2. If length of DA, is smaller than length of NOA, the packet MUST be sent to the parent node and exit. Otherwise, go to step 3. If length of DA is equal to length of NOA, go to step 4. Otherwise, go to step 5. If DA and NOA are the same, the packet arrived at destination and MUST be delivered to the transport layer, then exit. Otherwise, the packet MUST be sent to the parent node and exit. If PrefixOf(NOA,DA) is true go to step 6. Otherwise, the packet MUST be sent to parent node and exit. Calculate which child is the next hop address and forward packet to it. For each child check if PrefixOf(Child Address, DA). If true the packet MUST be sent to the selected child. Note that by construction, in TAAF, such expression is true only for single child. If any exception happens in the above steps, the packet MUST be dropped and an ICMPv6 "No Route to Host" notification MUST be sent back to the source address, according to .

| NOA == DA ? +--->+ \ / \ / | +-------+-------+ +-------+------+ | | no v yes | v +-+ | +-------+------+ | | | / \ no +-+ | + PrefixOf(NOA,DA)?+---------------------------->+ \ / | +-------+------+ | | yes | v v +---------+---------+ +-------------------+ | Forward to Child | | Forward to Parent | |PrefixOf(Child, DA)| +---------+---------+ | is true | | +---------+---------+ | |<-------------------------------------+ v +-+ | | +-+ ]]>

Forwarding toward an external IPv6 address When the packet is destined to an external IPv6 address, it is an outer-domain packet. In this case there is no need to use the PASA-6LoRH encapsulation. Indeed, since each node has a default gateway entry in the routing table, namely its parent, all PASA nodes (except the root) just send packets that are destined outside the PASA domain to their parent. Eventually all packets will reach the root node, which acts as border gateway. When the network forwarding operation is based on , the source node encapsulates the LOWPAN_IPHC packet with the IP-in-IP 6LoRH Header defined in Section 7 of . Where the encapsulator address is always the source address in the LOWPAN_IPHC header and the destination is always implicitly the root node. The latter will decapsulate and decompress the packet. Hence, according to the IP-in-IP 6LoRH will have the form depicted in .

Where the Length field is set to 1 to indicate that only the Hop Limit field is present. Such a header is positioned before LOWPAN_IPHC as shown in .

PASA-6LoRH Header PASA encodes path information into addresses to enable stateless forwarding. Such operation can be performed without touching the stateful forwarding procedure (based on the presence of a routing protocol like RPL), aka without modifying the 6LoWPAN architecture, rather leveraging on mechanisms already defined. In particular, by using the 6LoWPAN Routing Header in Page 1, defined in , it is possible to define a new Critical 6LoWPAN Routing Header Type, named PASA-6LoRH, that will be used by nodes to perform stateless PASA forwarding as described in .

PASA-6LoRH Sequence The extension octets typical sequence for a compressed 6LoWPAN packet with PASA Routing Header is shown in , following the specification of , where "Page 1" denotes the page dispatch as defined in .

Where: PASA-6LoRH: is the PASA specific extension. See for details. LOWPAN_IPHC: IPv6 compressed header according to . These two fields are followed by the packet payload. All nodes of a PASA Domain MUST recognize the PASA critical 6LoWPAN Routing Header and be able to handle the packets according to these specifications. Otherwise, packets can be dropped, hence disrupting communications.

PASA-6LoRH Format The format of the PASA-6LoRH header, is shown in .

Where: Reserved (Rsvd): Reserved for future use. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Size: indicates the length of the PASA address in octets. The Size equals N minus 1, which indicates that the length of the PASA address in PASA-6LoRH is at least 1 octet and no more than 8 octets. Octet 1 .. Octet N: the PASA destination address used for forwarding purposes. See for detailed forwarding operation. PASA addresses are aligned on the least significant bits. For instance, to encode the address b1011, which is the address of a host node since it terminates with '1', the corresponding octet would be b00001011 (or in hexadecimal: 0x0B), which is encoded as show in .

PASA-6LoRH and LOWPAN_IPHC co-existence In a PASA Domain every node has to use PASA and be able to compress/decompress PASA addresses according to this specification. The reference prefix of the PASA Domain represents a context that can be used to compress addresses in accordance to and decompress using the context and the coalescence procedure in . As such the simplest mode of co-existence of PASA-6LoRH with LOWPAN_IPHC is to use stateful address compression in the LOWPAN_IPHC header using the PASA context, then the PASA engine can just read the destination address from the LOWPAN_IPHC header, encoding it in the PASA_6LoRH header according to format previously described in . However, this mode of operation is sub-optimal because PASA-6LoRH already includes the destination address, hence, it can be completely elided from the LOWPAN_IPHC header. For nodes sending packets, the first step is to create a compressed packet using stateful compression, where the source PASA address is compressed using the context and the destination PASA address completely elided. The destination address is then encoded in the PASA-6LoRH in its shorter form. In case where the destination address is an address outside the PASA Domain, there is no need to use the PASA-6LoRH header, since the packet just needs to follow the default route until it reaches the root node (more details in ). The root node, when relaying a packet coming from outside the PASA Domain, compresses the source address in the LOWPAN_IPHC header according to specifications. The opposite operations need to be performed on the receiving node. Since the destination address is completely elided in LOWPAN_IPHC the IID is obtained by its encapsulation, in this case the PASA-6LoRH. The full destination address, including the IID, can be obtained via a coalescence operation with the PASA prefix in the context as described in Section 4.3.1 of . The source address is handled as defined in . As an example, let's assume that the PASA IPv6 prefix is 2001:db8::/64, as for the reference address will be 2001:db8:0:0. Let the PASA address in the PASA-6LoRH header be b111110, which in hexadecimal is 0x3E, then the complete IPv6 address is:

In notation the address is: 2001:db8::3e.

Nodes role indication PASA Routers and Hosts roles can be assigned similarly to IEEE 802.15.4 , which distinguishes between Full-Function Devices (FFD) and Reduced Function Devices (RFD). Such a role is notified using the 6LoWPAN Capability Indication Option (6CIO) as defined in and . In particular, a PASA Root will set the B-bit to indicate that it is a border router, a PASA Router will set the L-bit to indicate it is a router. Nodes with neither the B nor L bit set are considered PASA Hosts. Note that since PASA Routers MUST act as IPv6 Routing Registrars the E-bit of the 6CIO MUST be set as well.

PASA Address Configuration Procedure PASA address configuration leverages on the Generic Address Assignment Option . When a PASA node bootstraps, and if it has address configuration state in its non-volatile memory, it will re-register the address to its parent using procedures. Otherwise, if there is no configuration state in the non-volatile memory, it will multicast a Routing Solicitation (RS) and may receive one or more unicast Routing Advertisement (RA) messages from potential parents. The node can choose a parent on a "first come first served" basis and send a Neighbor Solicitation (NS), as for , with a GAAO option to request an address to the selected parent (see for an example of such option).

The requester MUST indicate its role as indicated in . If the node acts as a PASA Router it means that the address will be used to generate other addresses for the children. Otherwise, if the node acts as a PASA Host, the address will not be further delegated. The parent, acting as IPv6 ND Registrar will process the received GAAO message and act according to , and the corresponding GAAO message for the NA packet is generated. The NA message will carry the GAAO message with the AAF field set to the PASA TAAF value (see ). Furthermore, the R-bit of the GAAO message in the NA message MUST be set in order to request confirmation of address usage through explicit registration. The returning GAAO message will carry as well the PASA address that the parent assigns to its child using the procedures described in . The PASA address is appended to the GAAO message (see ) and its prefix length is indicated in the PfxLen field.

IANA Considerations This section requests that Internet Assigned Numbers Authority (IANA) registersvalues related to the PASA specification, in accordance with BCP 26 .

Critical 6LoWPAN Routing Header Type for PASA-6LoRH This document requires IANA to assign one value of the "Critical 6LoWPAN Routing Header Type" registry , to be used according to the specification in this document, as shown in . Value Description Reference TBD1 PASA-6LoRH [This Document]

PASA Address Assignment Function This document requires IANA to assign one value from the "Address Assignment Function" registry in the "Generic Address Assignment Option" registry group, as shown in and to be used according to the specification in this document. Value AAF Name Reference TBD2 PASA Tree Address Allocation Function [This Document] [Temporary NOTE: This registry is not yet existing. It is defined in on which this document relies.]

Deployments Considerations

Topology Changes Because PASA uses algorithmically generated addresses, based on the network topology, nodes do not generate and store forwarding table entries in the normal case. They are limited to have a default gateway and the ND table. One of the potential issues is the risk of renumbering of addresses in case of topology changes. Topology changes due to PASA Hosts joining and leaving have no real impact. It is just a matter to allocate new addresses, or re-use addresses previously assigned to PASA Host that left the network. More structural changes, where PASA Routers are added or removed have more impact. However, because of the applicability domain of PASA, the common case of topology change is known in advance and can be planned, so to reduce disruption due to renumbering (see ). Adding PASA Routers simply creates new branches in the logical tree and is not a disruptive operation. However, removing a PASA Router may require to partial renumbering the network, depending on the position of the PASA Router that is removed, and it may just involve a small branch of the tree.

Reliability Another type of topology change is the case of temporary link failures or temporary node failures, where the network is still able to provide connectivity through alternative links, which is strictly related to the underlying technology, the network topology, the deployed redundancy, and the expected reliability. Failures may raise the issue of topology changes and re-numbering. Such issues can be avoided, or at least mitigated, following the procedure in Section 5.7 of and keeping state in non-volatile memory. Reliability of external connectivity, with more than one node functioning as gateway, can be achieved in several ways. One simple solution is to use a multi topology approach, where each gateway acts as a root for a logically independent topology, identified via a different prefix. The multiple topologies can either be used at the same time or with a primary/backup policy. This solution is particularly suitable in case the PASA Domain is multihomed. An alternative solution is to separate root and gateway roles, setting up the topology so that some of the children of the root will also function as gateways, offering external connectivity. In this way traffic destined outside the local PASA Domain will still forwarded using a simple default route toward the root, and then sent outside when they reach one of the root's children or the root itself. This second solution allows to accommodate load balancing external connectivity through the selection of the nodes that offer gateway service. A third solution consists in creating a PASA Root backup with the same address using the Virtual Router Redundancy Protocol (VRRP ). However, in order to offer full resilience, the address allocation state in the primary PASA Root has to be duplicated in the secondary PASA Root. One last resort, to ensure reliability, is to use a routing protocol, however, such a solution, would annihilate the advantages of the PASA addressing scheme, namely the stateless forwarding. A more in-depth discussion about reliability, including the case of multiple roots, can be found in . Furthermore, specific reliability solutions depend as well on the specific Address Assignment Function used (different from the one presented in this document).

Security Considerations Communication in a PASA Domain is based on , , and , hence, the security considerations of those specifications apply here as well. This document re-uses mechanisms defined in and , as such the security considerations of both documents apply to this specification. In particular, the link layer SHOULD provide protection to prevent potential attacks, for instance using . Recommendations listed in Section 7 of SHOULD be applied as well to this specification. As discussed in , depending on the AAF in use, the number of available addresses may encounter some limitation. A rogue node may leverage on this knowledge to carry out address exhaustion attacks by impersonating different nodes and performing multiple registrations to specific PASA Routers. To mitigate such kind of attacks recommendations listed in Section 8 of SHOULD be applied as well to this specification. Alternatively cryptographic signatures (e.g., ) MAY be used. In some cases, ICMPv6 messages may be generated, hence the security considerations of MUST be applied to this document as well.

Privacy Considerations Depending on the AAF, the algorithmically built addresses may reveal topology information outside the PASA Domain. In particular the Tree Assignment Function (TAAF) specified in this specification reveals the path between the root and a node. For instance, let us take the example of the address 2001:db8::2b/64. Knowing that this address belongs to a PASA Domain using the AAF of this specification implies that the PASA address is 0x2b, which in binary form is b101011. The trailing bit 1 exposes the fact that this is a PASA Host, whose parent has the address 1010, meaning a PASA Router, whose parent is 10 (just looking at the preceding 0, cf. ), a PASA Router directly connected to the root. So, this leads to the path: 1 -> 10 -> 1010 -> 101011. This example is build based on the topology in . To conceal the topology of the PASA Domain, it is RECOMMENDED, to deploy address privacy protection mechanisms (e.g., using opaque addresses for external communications ), unless it is considered that topology disclosure does not represent a risk (e.g., private deployments).

Acknowledgements This document received many comments and help from community people. Erik Kline, Tommaso Pecorella, Esko Dijk, Dominique Barthel, Michael Richardson, Brian Carpenter, Hongyan Chen, did provide technical comments for this document. The authors would like to thank all of them. Thanks also to Carles Gomez for his thorough shepherd review of the document. Thanks to Eric Vyncke for the excellent AD review.

This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK] This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK] This specification introduces a new IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of Routing Protocol for Low-Power and Lossy Networks (RPL) data packet compression (RFC 6550). Using this dispatch type, this specification defines a method to compress the RPL Option (RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-IP technique, and is extensible for more applications. Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK] This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] Huawei Huawei This document specifies a new extension to the IPv6 Neighbor Discovery in Low Power and Lossy Networks (LLNs), enabling a node to request to be assigned an address or a prefix from neighbor routers. Such mechanism allows to algorithmically assign addresses and prefixes to nodes in a 6LoWPAN deployment. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification updates RFC 6775 -- the Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the Routing Registrars performing routing for host routes and/or proxy Neighbor Discovery in a low-power network. This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK] This specification updates RFC 4944 to introduce a new context switch mechanism for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) compression, expressed in terms of Pages and signaled by a new Paging Dispatch. As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK] RFC 6282 defines header compression in 6LoWPAN packets (where "6LoWPAN" refers to "IPv6 over Low-Power Wireless Personal Area Network"). The present document specifies a simple addition that enables the compression of generic headers and header-like payloads, without a need to define a new header compression scheme for each such new header or header-like payload. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Huawei Technologies, Beijing, P.R. China Huawei Technologies, Munich, Germany Huawei Technologies, Paris, France Institute of Telematics, Karlsruhe Institute of Technology (KIT) Institute of Telematics, Karlsruhe Institute of Technology (KIT) Huawei Research Center,Munich,Germany Huawei Research Center,Munich,Germany There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes. This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus. This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind. SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. This document describes the applicability of IPv6 over constrained-node networks (6lo) and provides practical deployment examples. In addition to IEEE Std 802.15.4, various link-layer technologies are used as examples, such as ITU-T G.9959 (Z-Wave), Bluetooth Low Energy (Bluetooth LE), Digital Enhanced Cordless Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near Field Communication (NFC), and Power Line Communication (PLC). This document targets an audience who would like to understand and evaluate running end-to-end IPv6 over the constrained-node networks for local or Internet connectivity. Power Line Communication (PLC), namely using electric power lines for indoor and outdoor communications, has been widely applied to support Advanced Metering Infrastructure (AMI), especially smart meters for electricity. The existing electricity infrastructure facilitates the expansion of PLC deployments due to its potential advantages in terms of cost and convenience. Moreover, a wide variety of accessible devices raises the potential demand of IPv6 for future applications. This document describes how IPv6 packets are transported over constrained PLC networks, such as those described in ITU-T G.9903, IEEE 1901.1, and IEEE 1901.2. 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. This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK] Babel is a loop-avoiding, distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol and obsoletes RFC 6126 and RFC 7557. This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. [STANDARDS-TRACK] This document defines version 3 of the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It obsoletes RFC 5798, which previously specified VRRP (version 3). RFC 5798 obsoleted RFC 3768, which specified VRRP (version 2) for IPv4. VRRP specifies an election protocol that dynamically assigns responsibility for a Virtual Router to one of the VRRP Routers on a LAN. The VRRP Router controlling the IPv4 or IPv6 address(es) associated with a Virtual Router is called the Active Router, and it forwards packets routed to these IPv4 or IPv6 addresses. Active Routers are configured with virtual IPv4 or IPv6 addresses, and Backup Routers infer the address family of the virtual addresses being advertised based on the IP protocol version. Within a VRRP Router, the Virtual Routers in each of the IPv4 and IPv6 address families are independent of one another and always treated as separate Virtual Router instances. The election process provides dynamic failover in the forwarding responsibility should the Active Router become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup Routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. Huawei Huawei Huawei Path-Aware Semantic Address (PASA), proposes to algorithmically assign addresses to nodes in a 6lo environment so to achieve stateless forwarding, hence, allowing to avoid using a routing protocol. PASA is more suitable for stable and static wireline connectivity, in order to avoid renumbering due to topology changes. Even in such kind of scenarios, reliability remains a concern. This memo tackles specifically reliability in PASA deployments, analyzing possible broad solution categories to solve the issue. IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec. [STANDARDS-TRACK] This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses).

Contributors China Mobile

No. 53, Xibianmen Inner Street, Xicheng District Beijing 100053 China longrong@chinamobile.com

Futurewei

USA kiranm@futurewei.com

adnanrashidpk@gmail.com