INTERNET-DRAFT L. Maqueda Intended Status: Experimental KTH Expires: August 21, 2011 G. Maguire KTH March 7, 2011 Guidelines for the Operation of a 6LoWPAN-ND Proxy Gateway draft-maqueda-6lowpan-pgw-00 Abstract The IETF 6LoWPAN working group has defined a number of optimizations to adapt traditional IPv6 Neighbor Discovery for Low-power and Lossy Networks (LLNs). As these two ND protocols are incompatible, and Neighbor Discovery has link-local scope, a side effect of these optimizations is that communication between Full Function Devices (FFDs) and 6LoWPAN nodes (6LNs) becomes impossible within the same link, unless the proper proxy mechanisms are applied. This document specifies guidelines for such proxy mechanisms to enable transparent communication between FFDs and 6LNs within the same network link. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Maqueda & Maguire Expires August 21, 2011 [Page 1] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 Copyright and License Notice Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Application scenario . . . . . . . . . . . . . . . . . . . 6 2. 6LP-GW Operations . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. 6LP-GW Operational Overview . . . . . . . . . . . . . . . 7 2.2. 6LP-GW Initialization . . . . . . . . . . . . . . . . . . 8 2.3. Processing Neighbor Solicitation Messages . . . . . . . . 8 2.3.1. NS Messages Originating in IEEE 802.15.4 Segment . . 9 2.3.1.1. Multicast NS . . . . . . . . . . . . . . . . . . 9 2.3.1.2. Unicast NS not Containing an ARO Option . . . . 9 2.3.1.3. Unicast NS Containing an ARO Option . . . . . . 9 2.3.1.4. Performing DAD on Behalf of 6LoWPAN Nodes . . 13 2.3.2. NS Messages Originating in IEEE 802.3 Segment . . . 15 2.3.2.1. Unicast NS . . . . . . . . . . . . . . . . . . 15 2.3.2.2. Multicast NS . . . . . . . . . . . . . . . . . 16 2.4. Processing Neighbor Advertisement Messages . . . . . . . 17 2.4.1. NA Messages Originating in IEEE 802.15.4 Segment . 17 2.4.2. NA Messages Originating in IEEE 802.3 Segment . . . 17 2.4.2.1. Unicast NA . . . . . . . . . . . . . . . . . . 18 2.4.2.2. Multicast NA . . . . . . . . . . . . . . . . . 18 2.5. Processing RS Messages . . . . . . . . . . . . . . . . . 19 2.5.1. RS Originating in IEEE 802.15.4 Segment . . . . . . 19 2.5.2. RS Originating in IEEE 802.3 Segment . . . . . . . 19 2.6. Processing RA Messages . . . . . . . . . . . . . . . . . 19 2.6.1. RA Messages Originating in IEEE 802.15.4 Segment . 20 2.6.2. RA Messages Originating in IEEE 802.3 Segment . . . 20 2.7. Processing a Redirect . . . . . . . . . . . . . . . . . 21 3. Optional Features . . . . . . . . . . . . . . . . . . . . . . 21 3.1. Processing of Optional 6LoWPAN-ND Features . . . . . . . 21 3.1.1. Multihop Prefix and Context Distribution . . . . . 22 Maqueda & Maguire Expires August 21, 2011 [Page 2] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 3.1.2. Multihop DAD . . . . . . . . . . . . . . . . . . . 22 3.2. Optional 6LP-GW Operation and Optimizations . . . . . . 23 3.2.1. RS-triggered DAD Optimization . . . . . . . . . . . 23 3.2.1.1. Changes to RS processing . . . . . . . . . . . 24 3.2.1.2. Changes to Unicast NS with ARO processing . . 24 3.2.1.3. Changes to DAD on behalf of 6LoWPAN nodes . . 25 3.2.2. ICMPv6 option filtering . . . . . . . . . . . . . . 25 3.2.3. 6LoWPAN-side Routing . . . . . . . . . . . . . . . 26 3.2.4. 6LRs seen as hosts by FFDs . . . . . . . . . . . . 26 4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . 27 8.2. Informative References . . . . . . . . . . . . . . . . . 28 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction RFC 4994 [RFC4944] defines an adaptation layer (6LoWPAN) that enables the transmission of IPv6 packets over IEEE 802.15.4 media. However, traditional IPv6 Neighbor Discovery [RFC4861] has proved to be unsuitable for IEEE 802.15.4 links due to its physical and link-layer properties, and to the nature of the target devices 6LoWPAN is intended for. For these reasons, the IETF 6LoWPAN working group suggested a number of improvements/changes to [RFC4861] in draft-ietf-6lowpan-nd [I-D.ietf-6lowpan-nd] in order to adapt traditional IPv6 Neighbor Discovery for 6LoWPAN networks. Although these modifications allow for a more efficient use of each 6LoWPAN node's resources, they cause Neighbor Discovery for IPv6 to be incompatible with this modified version. This incompatibility represents an important constraint for the integration of 6LoWPAN into existing IPv6 networks since it precludes the coexistence of FFDs and 6LoWPAN nodes (6LNs) within the same network link. This document provides guidelines to overcome this problem, by specifying the proxy operations required to enable transparent communication between FFDs and 6LNs within the same link. It is important to note that the operation described here neither requires modifications to the ND protocol nor human intervention, while permitting each type of device to achieve the maximum benefits of its particular Neighbor Discovery protocol. Maqueda & Maguire Expires August 21, 2011 [Page 3] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 1.1. 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 RFC 2119 [RFC2119]. This document requires readers to be familiar with terms and concepts described in [RFC5942], [RFC4861], [RFC4862], [RFC4919], [RFC4944], and [I-D.ietf-6lowpan-nd]. For clarity reasons, a short description of these terms and their corresponding abbreviations is given below. Note that some of these terms override their definitions in the above mentioned documents. 6LP-GW 6LoWPAN Proxy-Gateway. The logic in charge of performing the operations described in this document, grouped as a functional unit. Note that this logic can be implemented in different ways (for example as a separate device or as part of any existing device with forwarding capabilities), as long as at least the two required interfaces (IEEE 802.15.4 and IEEE 802.3) are available. LLN Low-power and Lossy Network [RFC5867]. IPv6-ND IPv6 Neighbor Discovery protocol [RFC4861]. 6LoWPAN-ND 6LoWPAN Neighbor Discovery protocol [I-D.ietf-6lowpan-nd]. ND Neighbor Discovery protocol, either 6LoWPAN-ND or IPv6-ND [RFC4861], [I-D.ietf-6lowpan-nd]. ARO Address Registration option [I-D.ietf-6lowpan-nd]. ABRO Authoritative Border Router option [I-D.ietf-6lowpan-nd]. 6CO 6LoWPAN Context option [I-D.ietf-6lowpan-nd]. PIO Prefix Information option [RFC4861]. SLLAO Source Link-Layer Address option [RFC4861]. TLLAO Target Link-Layer Address option [RFC4861]. 6LR An intermediate router in the LoWPAN that communicates with other 6LoWPAN routers in the same LoWPAN. 6LoWPAN routers are present only in route-over topologies [I-D.ietf-6lowpan-nd]. Maqueda & Maguire Expires August 21, 2011 [Page 4] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 6LBR A border router located at the junction of separate 6LoWPAN networks or between a 6LoWPAN network and another IP network. There may be one or more 6LBRs at the 6LoWPAN network boundary. A 6LBR is the responsible authority for IPv6 Prefix propagation for the 6LoWPAN network it is serving. An isolated LoWPAN also contains a 6LBR in the network, which provides the prefix(es) for the isolated network [I-D.ietf-6lowpan-nd]. 6R 6LoWPAN Router, either a 6LR or 6LBR. 6LH 6LoWPAN Host, in contrast with a 6R. 6LN A 6LoWPAN Node is any host or router participating in a LoWPAN. This term is used when referring to situations in which either a 6LH or 6R can play the role described [I-D.ietf-6lowpan-nd]. RR Regular IPv6 router, in contrast with a 6R Router Either a RR or 6R Link A network segment within which all nodes share the same prefix and communication at the IP layer using link-local addresses is possible, regardless of the nature of such addresses or the number of hops required for such communication. 1.2. Assumptions [I-D.ietf-6lowpan-nd] states that the IPv6-ND protocol optimizations it introduces are compatible with both mesh-under and route-over topologies. The guidelines described here do not affect this compatibility, therefore no assumptions regarding topology will be made unless specifically specified. However, section 3 describes some features that may be of special interest for implementations in the case of route-over topologies. The link-layer scenario considered here consists only of IEEE 802.15.4 and IEEE 802.3 links. However, the techniques described here may also be applicable to other types of media as long as IPv6- ND is used in one segment while 6LoWPAN-ND is used in the other, but further considerations of such media are out of the scope of this document. For the same reasons, the mechanisms described here may be used for interconnecting more than two link-layer media, but this is also out of the scope of the present document. Thus for the remainder of this Maqueda & Maguire Expires August 21, 2011 [Page 5] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 document, only a two port device with one interface being IEEE 802.3 and the other interface being IEEE 802.15.4 will be explicitly considered. As noted earlier, the 6LP-GW logic could be integrated in a router. The term "MAC address" will be used indiscriminately in the present document, referring to both 64-bit (IEEE 802.15.4) and 48-bit (IEEE 802.3) MAC addresses since there is an IEEE defined direct mapping from 48-bit MAC addresses to 64-bit addresses [EUI-64]. Due to the nature of the 6LP-GW, the availability of a forwarding mechanism between the two interfaces is assumed. However, there is no assumption regarding this forwarding mechanism, which could be implemented at either layer 2 or 3. Note that, the choice of this forwarding mechanism, need not impose a specific network topology as long as it is applied properly. 6LoWPAN supports different compression mechanisms which may be used or not. This document does not make any assumption regarding compression. However, if compression is used, the 6LP-GW will be responsible for compressing and decompressing packets as required. Some of the new features 6LoWPAN-ND introduces are defined in [I-D.ietf-6lowpan-nd] as optional. The treatment of such optional features is also considered optional in this document, but the implementation of such features would be required if they are implemented and used in the 6LoWPAN network. This memo assumes the presence of (at least) one IPv6 router (RR) having (at least) one IPv6 address. The 6LP-GW is assumed to keep track of the IPv6 address(es) of the RR(s) in order to properly receive packets directed to the RR(s) or generate packets on behalf of the RR(s). However, how to carry out this RR-address tracking is beyond the scope of this document (although some advice is provided in section 2.6.2). 1.3. Application scenario The scenario proposed here assumes that the 6LP-GW is placed at some point between a RR and a 6LoWPAN network. The 6LP-GW extends the RR's functionality by adding an IEEE 802.15.4 interface in addition to the RR's existing interfaces (typically IEEE 803.3 and IEEE 802.11). This added interface, together with the forwarding and proxy mechanisms logically turns the RR into a 6LBR, enabling 6LoWPAN devices to share the same network segment as any other FFD, without requiring any further special treatment. Therefore the 6LP-GW MUST perform all the operations necessary to enable ordinary IPv6 hosts to communicate with 6LoWPAN hosts and vice versa. Figure 1 illustrates Maqueda & Maguire Expires August 21, 2011 [Page 6] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 a possible application scenario. +------------+ | | | eth0+-- IEEE 802.3 ((( V | | | | ...| V ))) IEEE 802.15.4 +--(6LN) | | +--------+ | | ethN+--+ 6LP-GW +--+ ((( V | | +--------+ | | | +--(6LN) | RR | V ))) IEEE 802.11 ((( v | | | | | w0+--+ +--(6LN) | | +------------+ Figure 1: 6LP-GW Application Scenario 2. 6LP-GW Operations The operations described in this section are considered the minimum required for correct behavior of the 6LP-GW (and thus, the whole network segment). However, section 3 explains some optional features that may be of interest for particular applications. 2.1. 6LP-GW Operational Overview To enable the operations described above ND packets reaching the 6LP-GW MUST be processed, modified, and, in some cases, hijacked. The 6LP-GW together with the RR will be seen from the 6LoWPAN side as a 6LBR. In contrast, from the IPv6 side, it is impossible to distinguish between FFDs and 6LoWPAN nodes. Regarding forwarding, an appropriate MAC translation mechanism MUST be applied when required, since IEEE 802.15.4 MAC addresses are 64 bits long while IEEE 802.3 MAC addresses are 48 bits long. Note that the 6LP-GW is invisible for any of the link segments it internetworks, meaning that it does not need to have either an IPv6 address or a MAC address. Of course the device MAY have an IPv6 address and MAC address associated with an interface, this could be used for management of the device (including loading new software into it), but this functionality lies outside the scope of this document. Additionally, decompression and compression are performed by the 6LP-GW on incoming and outgoing packets when appropriate. Note also that the proxy mechanisms described below consider only the Maqueda & Maguire Expires August 21, 2011 [Page 7] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 case of packets traversing from one segment to the other. The 6LP-GW SHOULD NOT forward unicast packets directed to the same segment they came from, unless the optional routing feature described in section 3.2.3 is implemented. In addition, some ND options (mainly SLLAO and TLLAO) will require extra processing in order to translate from 48-bit MAC addresses into 64-bit MAC addresses and vice-versa, depending on which segment the packets containing these options originate from. This translation MUST occur whenever a ND option contains a link-layer address. In all cases, validity checks of the incoming ND messages SHOULD be performed as specified in the corresponding ND document or draft. The specific way to process a ND message will depend on which segment it originates from. 2.2. 6LP-GW Initialization In addition to the data structures required for the chosen forwarding mechanism, the 6LP-GW MUST maintain a Neighbor Cache (NC) just as if it were a 6LR (or 6LBR). The maintenance procedures for this cache extend those described in [I-D.ietf-6lowpan-nd]. This means that the 6LP-GW MUST create/refresh entries when receiving Neighbor Solicitation messages (NS) and it MUST also remove Neighbor Cache Entries (NCEs) when the registration lifetime expires. Receiving an ARO with zero lifetime will cause the 6LP-GW to immediately delete the corresponding NCE. In addition, every NCE MUST contain an ARO-pending flag and a Duplicate Address Detection (DAD) timer, whose meanings will be explained later in this section. In case context-based header compression is used [I-D.ietf-6lowpan-hc], the 6LP-GW SHOULD also perform context information maintenance and dissemination just as if it were a 6LBR. At bootstrapping, the 6LP-GW initializes all the data structures needed to create and maintain both NC and Context information. Note that an implementation MAY merge together the chosen forwarding mechanism and NC maintenance. 2.3. Processing Neighbor Solicitation Messages Neighbor Solicitation messages that reach the 6LP-GW may have originated for different purposes. The appropriate way to process them depends on this purpose and it will differ depending on their origin and their structure. We will consider those originating in the IEEE 802.15.4 segment in section 2.3.1 and those originating in the IEEE 802.3 segment in section 2.3.2. Maqueda & Maguire Expires August 21, 2011 [Page 8] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 2.3.1. NS Messages Originating in IEEE 802.15.4 Segment The processing of the three different types of NS messages that can arrive at the 6LP-GW from the IEEE 802.15.4 segment is defined in the paragraphs below. 2.3.1.1. Multicast NS A multicast NS can only be sent for the purpose of address resolution. While 6LoWPAN hosts (6LHs) do not perform it, 6Rs MAY do address resolution and therefore this type of NS SHOULD be forwarded unchanged to the IEEE 802.3 interface (with the appropriate MAC translation). 2.3.1.2. Unicast NS not Containing an ARO Option As defined in [RFC4861], unicast NSs without ARO are sent as probes to test for reachability. Considering that 6LHs do not maintain NCEs for other hosts, but only for 6Rs, it is unlikely that any 6LH sends a unicast NS to any node other than a 6R. However, nothing in [I- D.ietf-6lowpan-nd] precludes 6Rs from sending this type of message to any kind of node. Therefore, a unicast NS message not containing an ARO option MUST be forwarded to the IEEE 802.3 interface unchanged (apart from the appropriate MAC translation) so that it can be processed and responded to by the recipient as defined in [RFC4861] (if the originator of the NS was a 6LH, the recipient will be the RR, if it was a 6R, the recipient could be any node). 2.3.1.3. Unicast NS Containing an ARO Option Unicast NS messages containing an ARO option are sent as part of the registration procedure. As these messages are only sent to 6Rs, and the 6LP-GW together with the RR is seen as a 6LBR, it is likely that the 6LP-GW will receive such messages having as their destination IPv6 address the RR's IPv6 address. Therefore, the 6LP-GW MUST perform the normal operations of a 6R when receiving this type of messages directed to the RR, i.e., the NS message MUST be processed as specified in section 6.5 of [I-D.ietf-6lowpan-nd] in terms of validity checking and NC maintenance, but with some differences as will be explained below. If the IPv6 destination address of the NS message including an ARO does not match the RR's IPv6 address, then the packet MUST be discarded. If, for some reason, the RR's IPv6 address is unknown when the NS arrives, then the packet MUST also be discarded. At this point it is important to note two issues that can impact design decisions: Maqueda & Maguire Expires August 21, 2011 [Page 9] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 o Unicast NS messages sent for address registration also have the purpose of performing reachability detection (generally referred to as network unreachability detection-NUD) to determine the reachability of the router [I-D.ietf-6lowpan-nd]. o As the 48-bit EUI space is a subset of the 64-bit EUI space, the 64-to-48 bit MAC address mapping can lead to duplicate addresses. Therefore, the 6LP-GW MUST perform DAD on behalf of 6LoWPAN nodes when registering addresses. For the above reasons, the 6LP-GW MUST perform not only the registration procedure, but also perform both DAD (in the IPv6-ND way on the IEEE 802.3 interface) and NUD; with both DAD and NUD performed on behalf of the 6LoWPAN node that is trying to register its address. In order to perform DAD, the 6LP-GW MUST send a NS, formatted as explained in [RFC4862]. The target address of this NS will be the address being registered and the destination address will be the Solicited-node multicast address of this address. For NUD, the NS message originated in the IEEE 802.15.4 segment MUST be forwarded to the IEEE 802.3 segment, so a subsequent Neighbor Advertisement message (NA) response confirms the reachability of the router. However, DAD is an expensive process as waiting for messages that are not going to receive responses can only be terminated by a timeout [VATMAG98] and it can not be performed in parallel with NUD due to the risk of duplicate addresses. As waiting for both to complete sequentially may delay the autoconfiguration process too much, it is RECOMMENDED to perform DAD only upon registration and then, NUD upon re-registration. Figure 3 describes the registration procedure and section 2.3.1.4 details the DAD process. Maqueda & Maguire Expires August 21, 2011 [Page 10] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 +-----------+ |Unicast NS | |with valid | |ARO & SLLAO| +-----------+ | | V / \ / \ / \ / \ +----------+ / NCE \ N /Space \ N |Respond NA| \Exists?/---------->\in NCE?/----->|with ARO. | \ / \ / |status = 2| \ / \ / +----------+ | | | Y | Y V V / \ +-----------+ / \ |Create NCE.| N / Same \ |ARO-pending| +------------\EUI-64?/ |flag = 1. | | \ / |NCE state =| | \ / |TENTATIVE | | | +-----------+ | | Y | V V V +-----------+ +----------------+ +----------------+ |Respond NA | |Refresh Lifetime| |Multicast NS for| |with ARO. | |ARO-pending | |DAD in the IEEE | |status = 1 | |flag = 1.Forward| |802.3 segment. | |(duplicate)| |NS to IEEE 802.3| |Start DAD timer | | | |segment | | | +-----------+ +----------------+ +----------------+ Figure 2: NS with ARO Processing Optionally, it is possible to speed-up the registration procedure by performing DAD upon reception of the first Router Solicitation (RS) message (RS-triggered DAD), instead of delaying it until receiving a NS. This feature adds some complexity as will be explained in section 3.2.1. Considering all of the above, upon receipt of a NS message containing valid ARO and a SLLAO options, the 6LP-GW MUST behave as follows (see figure 3). The 6LP-GW searches its NC for a NCE with same IPv6 address as the IPv6 source address of the incoming NS message; if no matching NCE is Maqueda & Maguire Expires August 21, 2011 [Page 11] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 found, then the 6LP-GW creates a new NCE for the node being registered. If there is no space left in the NC, then the registration fails and the 6LP-GW generates a NA including an ARO with status = 2, as specified in section 6.5.2 of [I-D.ietf-6lowpan-nd]. If there is space available in the NC, then a new entry is created with a state value of TENTATIVE and the ARO-pending flag is set to 1. In this final case a NA is not generated in response, but rather the 6LP-GW performs DAD on the IEEE 802.3 segment on behalf of the node that is trying to register, similar to section 5.4 of [RFC4862]. This DAD process is detailed in the next section (2.3.1.4). If there is a matching NCE, then if the NCE MAC address encoded in EUI-64 differs from the MAC address present in the EUI-64 field of the ARO, the address is a duplicate and the 6LP-GW must generate and send a NA message including an ARO with status = 1 (duplicate), as specified in section 6.5.2 of [I-D.ietf-6lowpan-nd}. If the EUI-64 is the same as present in the ARO and the NCE state is REGISTERED, then this is the case of a re-registration and, therefore, the ARO-pending flag must be set to 1, the registration lifetime must be refreshed, and the received NS message MUST be forwarded to the IEEE 802.3 segment in order to perform NUD (note that the NA message produced in response will be intercepted later - see section 2.4.2). A special case could happen if a 6LN whose registration is in progress (i.e., it has sent a NS with an ARO but the DAD procedure has not completed, hence no NA has been sent in response yet) sends a second NS with ARO. This situation happens if there is a matching NCE, with the same EUI-64, but the NCE state is TENTATIVE. In this case the 6LP-GW SHOULD simply discard the NS with ARO. Note that in some cases of the above procedure, the 6LP-GW responds with NAs on behalf of the RR. Therefore, for every packet being generated in the 6LP-GW in this situation, the Router flag MUST be 1 and the IPv6 source address MUST be the IPv6 address of the RR attached to the 6LP-GW. This address already should be known due to the previous RS and RA exchange. It is also important to note that TENTATIVE entries MUST be timed out TENTATIVE_NCE_LIFETIME seconds after their creation in order to leave space in the NC for other hosts, as specified in [I-D.ietf-6lowpan-nd]. Maqueda & Maguire Expires August 21, 2011 [Page 12] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 2.3.1.4. Performing DAD on Behalf of 6LoWPAN Nodes DAD SHOULD be performed as specified in [RFC4862] and this specification assumes the existence of the variables RetransTimer (defined in [RFC4861]) and DupAddrDetectTransmits (defined in [RFC4862]). Figure 3 illustrates the DAD operation described in this section. The 6LP-GW MUST maintain a DAD timer for each NCE in the NC. A DAD timer will be started when the corresponding NS is sent. If no NA is received before the expiration of RetransTimer, then the 6LP-GW will either send another NS or end the DAD process, depending on the value of DupAddrDetectTransmits. If the DAD process completes successfully (i.e., no duplicate instance of this address is detected), then the 6LP-GW changes the state of the corresponding NCE to REGISTERED, and sets the ARO-pending flag to 0. In addition, the information contained in the NCE will be used to generate and send a NA message with an ARO option with status = 0 (success). If DAD failed, then a NA with ARO option and status = 1 (duplicate) MUST be generated and sent to the node (in the IEEE 802.15.4 segment) that originated the registration request. This message MUST be sent as specified in section 6.5.2 of [I-D.ietf-6lowpan-nd]. After sending this message, the NCE can be deleted. Note that implementations MAY mark the NCE for deletion and then delete it in next stage in order to avoid race conditions instead of deleting it immediately. Note also that, when using the (optional) RS-triggered DAD, neither the response will be sent or the NCE will be deleted when DAD completes unless a NS with an ARO option arrives at the 6LP-GW. Section 3.2.1 will explain this behavior in detail. Maqueda & Maguire Expires August 21, 2011 [Page 13] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 +---------------------+ |Send multicast NS for| |DAD in the IEEE 802.3| |segment. | |Start DAD timer | +---------------------+ | | V / \ /NA in\ +----------+ /response Y | | +--->\to DAD?/------->|DAD failed| | \ / | | | \ / +----------+ | | | | | N | | V V | / \ +------------+ | / DAD \ |Send NA with| | N / timer \ |ARO. | +----\expired? |status = 1 | \ / |(duplicate) | \ / +------------+ | | | Y | V V +-------------+ +----------+ | | | | |DAD succeeded| |Delete NCE| | | | | +-------------+ +----------+ | | V +----------------------+ |Send NA with ARO. | |status = 0. | |NCE state = REGISTERED| |ARO-pending flag = 0 | +----------------------+ Figure 3: DAD performed on behalf of 6LoWPAN nodes. The diagram illustrates the process assuming DupAddrDetectTransmits = 1. Maqueda & Maguire Expires August 21, 2011 [Page 14] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 2.3.2. NS Messages Originating in IEEE 802.3 Segment As stated in [RFC4861] and [RFC4862], two different types of NS may arrive to the IEEE 802.3 interface: unicast and multicast NSs. These messages can be sent with three different purposes: Address Resolution, NUD, or DAD. For Address Resolution or DAD, the NS messages are sent to the Solicited-node multicast address, while for NUD, the NS messages are unicast. 6LoWPAN hosts (6LHs) should respond to the unicast NS messages, but as they do not join the Solicited-node multicast group, hence do not listen to the Solicited-node multicast address and, therefore, they will not respond to these multicast NS messages. In contrast, 6LoWPAN Routers (6Rs) do join the Solicited-node multicast group (hence they listen to the Solicited-node multicast address) and thus they should do respond to both, unicast and multicast NS messages. Note here that the 6LP-GW is aware of every node that is currently reachable in the IEEE 802.15.4 segment due to the registration process. 2.3.2.1. Unicast NS Unicast NS messages are sent for NUD. These messages MAY be forwarded unchanged (except for the appropriate MAC translation) to the IEEE 802.15.4 segment in order that the target nodes could respond to the NS with a NA. However, as 6LoWPAN nodes are registered with the 6LP-GW, the information contained in its NC is a priori sufficient to generate the response on behalf of the target nodes. Thus, the 6LP-GW SHOULD generate this response so that the wireless nodes save energy as they neither need to receive nor send the NS and NA messages, respectively. It is important to note that 6LoWPAN nodes only register non-link-local addresses with routers; thus, if the incoming NS's destination address is a link-local address, the 6LP-GW SHOULD generate a link-local (EUI-64-based) IPv6 address for every different EUI-64 address stored in its NC in order to compare it against the destination address of the incoming NS prior to send the corresponding response. Maqueda & Maguire Expires August 21, 2011 [Page 15] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 2.3.2.2. Multicast NS Multicast NSs are sent to perform Address Resolution or DAD. These messages invoke responses from 6Rs, but not from 6LHs (since as noted above 6LHs do not join the Solicited-node multicast group). The 6LP-GW may be aware of which entries in its NC correspond to 6Rs due to previously intercepted NA (Router flag) or RA messages and thus, the 6LP-GW MAY forward these multicast NS messages only to these 6Rs (and behave as specified below for hosts). However, this approach is unreliable since it requires that all 6R nodes have previously sent at least one NA or RA message. As result a similar approach as used for unicast NS messages is RECOMMENDED, i.e., for every multicast NS message arriving on the IEEE 802.3 interface, the 6LP-GW SHOULD generate an appropriate NA in response (if required), according to the contents of its NC, as follows. If the target address present in the NS is not a link-local address, then the 6LP-GW MUST search for it in the NC. If the target address is a link-local address, then a link-local (EUI-64 based) address MUST be generated for each NCE present in the NC (according to the link layer address present in the NCEs, according to [RFC4944] and compared to the target address of the incoming NS (since link-local addresses are not registered with 6Rs). If there is a matching NCE whose state is REGISTERED (regardless of the nature of the target address), then the 6LP-GW MUST generate a NA message in response and send it through the IEEE 802.3 interface. Such an NA message is generated based on the contents of the corresponding NCE, mainly as specified in section 7.2.4 of [RFC4861]: o If the source address of the NS is the unspecified address, then the destination IPv6 address MUST be the all-nodes multicast address. Otherwise, the destination address MUST be the source address of the NS. o The target address of the NA MUST be copied from the NS message. o The Router flag SHOULD be set to the NCE's isRouter flag value unless the optional feature described in section 3.2.4 is implemented (in that case the isRouter flag will always be zero). o If the source of the NS is the unspecified address, the node MUST set the Solicited flag to zero. Otherwise the Solicited flag MUST be set to 1. Maqueda & Maguire Expires August 21, 2011 [Page 16] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 o The Override flag SHOULD be set to 1, as RECOMMENDED for this case in section 7.2.4 of [RFC4861]. o The NA MUST include a TLLAO containing the link-layer address of the node in the NCE, since the 6LP-GW is sending this message "on behalf" of a node receiving a multicast NS message. If there is a matching NCE whose state is TENTATIVE, then the 6LP-GW MUST NOT respond with a NA [RFC4862] section 5.4.3. If the source IPV6 address of the NS is not the unspecified address, then the NS has been sent for address resolution and SHOULD be discarded. If the source address of the NS is the unspecified address, then the sender is trying to configure a duplicate address. If no NS for DAD has been sent yet on behalf of the corresponding 6LN, the 6LP-GW SHOULD generate a NA including an ARO option with status value = 1, send it to the corresponding 6LN whose address is in the NCE, and delete the NCE. 2.4. Processing Neighbor Advertisement Messages NA messages are typically generated in response to NS messages. This section specifies the required processing of the different types of NA messages that may arrive at the 6LP-GW. 2.4.1. NA Messages Originating in IEEE 802.15.4 Segment NA messages may arrive on the IEEE 802.15.4 interface for different purposes. Regardless of the nature of the incoming NA, the 6LP-GW SHOULD update the isRouter flag in the NCE matching the source address of this NA message and forward the NA message to the IEEE 802.3 interface. Note that if the recommendation proposed in section 2.3.2.2 is followed, then 6LoWPAN nodes will be unlikely to send NA messages in response to NS messages coming from the IEEE 802.3 segment (as the 6LP-GW will not have forwarded the NS to them, hence they do not need to respond). 2.4.2. NA Messages Originating in IEEE 802.3 Segment NA messages originating in the IEEE 802.3 segment can arrive at the 6LP-GW for different reasons, depending on whether they are unicast or multicast. Maqueda & Maguire Expires August 21, 2011 [Page 17] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 2.4.2.1. Unicast NA A unicast NA message could only be originated as result of a unicast NS message sent from the IEEE 802.15.4 segment. The original NS message could be either a probe sent for reachability confirmation or part of the registration process. In order to distinguish between these two cases, if the source IPv6 address of the NA is the IPv6 address of the RR, then the 6LP-GW searches its NC for a NCE matching the destination address of the NA. If a matching entry having the ARO-pending flag set to 1 is found, then the incoming NA is the final part of the registration process of a node. In this case, the ARO-pending flag MUST be set to 0 and the NA forwarded (with the appropriate MAC translation) to the IEEE 802.15.4 interface. If the NCE state is other than REGISTERED, it MUST be set to REGISTERED. In addition, an ARO option containing a status value of 0 MUST be appended to the NA before forwarding it to the IEEE 802.15.4 interface. If the IPv6 source address of the NA is other than the IPv6 address of the RR, or if the NCE matching the destination IPv6 address of the NA has its ARO-pending flag set to 0, then the NA message SHOULD be forwarded unchanged (except for the appropriate MAC translation) since it is responding to a NS sent for NUD. If no NCE matching the search criteria is found, the message SHOULD be discarded. 2.4.2.2. Multicast NA Multicast NA messages that may arrive to the 6LP-GW on the IEEE 802.3 interface originated either for quick information propagation (if the link-layer address of the sender changed) or as a response to a NS sent for DAD (meaning that there is a duplicate). If the target address in the NA message corresponds to a NCE whose state is TENTATIVE, then DAD failed for that NCE. In this case, the 6LP-GW will generate a new NA on behalf of the RR it is attached to, with an ARO option containing a status value of 1. This packet MUST be sent on the IEEE 802.15.4 interface according to [I-D.ietf-6lowpan-nd] section 6.5.2. If there is no TENTATIVE NCE whose IPv6 address matches the target, then this packet was sent for quick information propagation and it SHOULD be discarded due to its minor importance for 6LoWPAN nodes. However, implementations MAY forward this type of message unchanged (except for the appropriate MAC translation) so that 6LNs can update their NCs quickly. Maqueda & Maguire Expires August 21, 2011 [Page 18] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 2.5. Processing RS Messages In IPv6-ND, RS messages are sent during bootstrapping and they are mainly multicast; hence the IPv6 source address MAY be the unspecified address and the SLLAO SHOULD be included when the IPv6 source address is not the unspecified address as specified in [RFC4861]. In contrast, [I-D.ietf-6lowpan-nd] specifies that routers are not required to send periodic RA messages, therefore, hosts will send RS messages in order to maintain their prefixes and registration lifetimes; these RS will be unicast (unless the link-layer address of the router is not known) and MUST include the SLLAO option. Note that the whole network bootstrapping process can be optimized by extending the processing of RS messages as proposed in section 3.2.1. 2.5.1. RS Originating in IEEE 802.15.4 Segment RS messages originating in the IEEE 802.15.4 segment may be unicast or multicast, but they MUST include a SLLAO option so that the router can always respond with a unicast RA. If for any reason a RS message arriving at the 6LP-GW does not include a SLLAO option, that message MUST be discarded. As, RRs on the IEEE 802.3 segment can process these messages without requiring any special treatment from the 6LP-GW, RS messages from the IEEE 802.15.4 segment MUST forwarded unchanged (except for the appropriate MAC translation). 2.5.2. RS Originating in IEEE 802.3 Segment RS messages coming from the IEEE 802.3 segment will be silently discarded if the source address is the unspecified address. If no SLLAO option is included, then the 6LP-PG will modify the RS by appending a SLLAO option with the link-layer address of the originator of the RS prior to forward it to the IEEE 802.15.4 segment. Note that the ICMPv6 checksum will need to be recalculated. Section 3.2.4 describes an alternative treatment of these messages that may be of interest for certain applications. 2.6. Processing RA Messages If optional 6LoWPAN features such as the use of the ABRO or 6CO options are enabled, then the treatment of RA messages is as detailed in section 3.1, otherwise, the processing of RAs is performed as follows. Maqueda & Maguire Expires August 21, 2011 [Page 19] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 2.6.1. RA Messages Originating in IEEE 802.15.4 Segment RA messages originating in the IEEE 802.15.4 segment MAY be forwarded untouched (except for the appropriate MAC translation). 2.6.2. RA Messages Originating in IEEE 802.3 Segment As seen in previous sections, there are several situations where the 6LP-GW needs to send messages on behalf of the RR. As RAs originating in the IEEE 802.3 segment are necessarily sent by the RR, the 6LP-GW SHOULD save both, the source MAC address and the source IPv6 address of such RA messages for subsequent use. Note here that the RR may have more than one IPv6 address and/or MAC address and therefore, when saving these RR's addresses the 6LP-GW SHOULD perform some out-of-scope management on such addresses in order to ensure both, that the addresses do not reach an obsolete state, and that they are not unnecessarily overwritten when RAs are sent from a different source address. Apart from performing the proper management of source MAC and IPv6 addresses, RAs originating in the IEEE 802.3 segment SHOULD be forwarded to the IEEE 802.15.4 interface, with the following considerations: o [RFC4861] states that a RR MAY unicast solicited RAs when the corresponding RS's source address is not the unspecified address, but the usual case is to multicast these RAs to the all-nodes multicast address. While no harm can result from forwarding these multicast messages (i.e., they will reach their destination and accomplish their purpose), one of the main goals of [I-D.ietf-6lowpan-nd] is to reduce multicast traffic. Therefore implementations MAY choose to add a flag to the NCEs (awaiting-RA) in order to mark NCEs soliciting RAs (upon receiving RSs from those 6LNs, and prior to forward these RSs, as specified in section 2.5.1) so that the 6LP-GW can change the destination address of RAs to the address of the 6LN in the marked NCE. Since RRs MUST delay the sending of RAs and they MAY send one RA to respond to several RSs [RFC4861], if more than one 6LN is marked as "awaiting-RA", then the 6LP-GW MUST send a unicast RA per marked NCE, clearing the NCEs' "awaiting-RA" flag when dispatching the corresponding RA. o 6Rs only need to send periodic RAs if they choose to distribute prefix and/or context information across a route-over topology (see section 3.1.1). In contrast, RRs will send unsolicited periodic RAs as specified in [RFC4861]. If optional context or prefix distribution is performed, these RA messages SHOULD be forwarded (applying the corresponding processing, as mentioned Maqueda & Maguire Expires August 21, 2011 [Page 20] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 above and/or in section 3.1) to the IEEE 802.15.4 segment. If no optional context or prefix distribution is performed, then an implementation MAY filter out these periodic RA messages (for example, using the "awaiting-RA" flag in NCEs, so that the RA is discarded if no NCE with this flag set is present in the NC). o According to [I-D.ietf-6lowpan-nd], the SLLAO option MUST be included in the RA message. However, this option MAY be omitted in RAs sent by RRs, as stated in [RFC4861], therefore the 6LP-GW MUST include this option in RA messages originating in the IEEE 802.3 segment that do not contain a SLLAO option, prior to forward them to the IEEE 802.15.4 segment. o All prefixes other than the link-local (FE80::) prefix are assumed to be off-link in 6LoWPAN-ND and 6LoWPAN hosts will ignore any PIO option whose 'L' (on-link) flag is set ([I-D.ietf-6lowpan-nd] sections 5.4 and 5.7 respectively). However, RRs usually advertise global prefixes with the 'L' flag set in the PIO option within the local network. Considering that the PIO option in RA messages is the only way hosts have to acquire a global address (in the absence of other mechanisms such as DHCPv6 for address configuration) and that the same prefix which is considered to be on-link in the IEEE 802.3 segment is assumed to be off-link in the IEEE 802.15.4 segment, the 6LP-GW MUST always clear this 'L' flag in the PIO option for every RA originating in the IEEE 802.3 segment and directed to the IEEE 802.15.4 segment. Note that inclusion of a new SLLAO option or the modification of the PIO option necessitates recomputation of ICMPv6 checksum. 2.7. Processing a Redirect According to [I-D.ietf-6lowpan-nd], redirects are not used by 6LoWPAN-ND in route-over topologies, but they MAY be used in mesh-under topologies. Therefore, these messages SHOULD be forwarded unchanged, regardless of the incoming interface. Some implementations MAY provide mechanisms for manual configuration allowing the user to disable the forwarding of Redirect messages in route-over topologies. 3. Optional Features 3.1. Processing of Optional 6LoWPAN-ND Features This section describes the operations required to process the features defined as "optional" in [I-D.ietf-6lowpan-nd]. Maqueda & Maguire Expires August 21, 2011 [Page 21] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 3.1.1. Multihop Prefix and Context Distribution Despite the 6CO and ABRO options being described as optional features, their processing by the 6LP-GW is RECOMMENDED. While 6CO provides for context-based compression ([I-D.ietf-6lowpan-hc]), ABRO is mandatory for this context dissemination across route-over topologies. Both options SHOULD be included by the 6LP-GW (one ABRO and one or more 6COs) in RA messages addressed to the IEEE 802.15.4 segment. In order to do so, the 6LP-GW MUST behave similarly to the description in [I-D.ietf-6lowpan-nd] sections 7 and 8, with the following considerations: o The 6LP-GW is in charge of performing all the tasks related to context information maintenance, as if it were a 6LBR, as per [I-D.ietf-6lowpan-nd] Section 7.2. o The 6LBR Address in the ABRO option is the address of the RR that the 6LP-GW is attached to. o The 6LP-GW MUST maintain the ABRO version number in stable storage and be aware not only of its own 6CO options, but also of the changes regarding the PIO in the RAs coming from the RR. 3.1.2. Multihop DAD 6LoWPAN-ND only requires DAD if non-EUI-64 based addresses are used. Multihop DAD in 6LOWPAN-ND is required when non-EUI-64 based addresses are used in a route over topology and more than one 6R is present in the network. Since in our case both 64 and 48-bit MAC addresses are mixed in the same network, the 6LP-GW MUST always perform DAD on behalf of 6LNs (even if 6LNs only use EUI-64 based addresses). For this reason, 6LP-GW implementations are RECOMMENDED to provide mechanisms for supporting multihop DAD in route-over topologies. Multihop DAD is performed via two new messages described in [I-D.ietf-6lowpan-nd], Duplicate Address Request (DAR) and Duplicate Address Confirmation (DAC). 6LRs send DARs to the 6LBR when they receive a NS with an ARO option from hosts. The 6LBR responds with a DAC after searching for the address contained in the DAR in its NC. The DAC message contains a status field whose value indicates whether the address is a duplicate or not. Finally, the 6LR responds with a NA with an ARO option (whose status value depends on the status value of the received DAC) to the host which sent the original NS with an ARO. Maqueda & Maguire Expires August 21, 2011 [Page 22] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 In our case, the 6LP-GW SHOULD act as a 6LBR, processing the DAR as specified in [I-D.ietf-6lowpan-nd] section 8.2.1 and responding with a DAC as specified in [I-D.ietf-6lowpan-nd] section 8.2.4. However, the 6LP-GW will not only compare the IPv6 address contained in the DAR message against entries in its NC, but will also have to perform a traditional DAD on the IEEE 802.3 interface to ensure the uniqueness of the address in the complete network. Therefore, the 6LP-GW SHOULD maintain the information in the DAR message until DAD has finished. The RECOMMENDED way to implement this is by creating a TENTATIVE NCE (just as done upon the arrival of a NS with an ARO). Note that in this case, the ARO-pending flag in the NCE MUST NOT be set to 1, since neither a NS with an ARO has been received nor a NA with ARO needs to be sent in response. Instead, another flag, for example DAR-pending, SHOULD be added to each NCE in order to process that entry properly (i.e., sending a DAC) once DAD has completed. Note that all of the above is compatible with the operations regarding regular address registration (section 2.3.1.3) and even with the RS-triggered DAD Optimization described in section 3.2.1. The reason is that Multihop DAD is only performed when a host tries to register with a 6LR, while the regular registration process occurs whenever a host tries to register directly with the 6LBR. 3.2. Optional 6LP-GW Operation and Optimizations This section suggests some optional optimizations for the operations proposed in this document that may be of interest for certain implementations. 3.2.1. RS-triggered DAD Optimization As mentioned in previous sections, it is possible to speed up the bootstrapping procedure by triggering DAD on behalf of 6LoWPAN nodes upon reception of the first RS message, instead of waiting until the reception of a NS with an ARO option (i.e., the message actually sent for DAD). Considering the long delay required for DAD, the implementation of this feature is RECOMMENDED. Implementing this feature requires a few modifications to the operation described in sections 2.3.1.3, 2.3.1.4, and 2.5.1, regarding the processing of NS messages with an ARO option, the way DAD is performed on behalf of 6LoWPAN nodes, and the processing of RS messages originated in the IEEE 802.15.4 segment respectively. These modifications are described below. In addition, a new NCE state, DUPLICATE, is required in order to mark Maqueda & Maguire Expires August 21, 2011 [Page 23] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 NCEs whose IPv6 address is not unique but that can not be deleted yet (i.e., they are still required for specific reasons). 3.2.1.1. Changes to RS processing If this optimization is implemented, then the 6LP-GW will try to create a NCE upon arrival of the first RS message (originating in the IEEE 802.15.4 segment) and then it will send a multicast NS to perform DAD, as specified in [RFC4862]. This newly created NCE must have its ARO-pending flag set to 0 and its state set to TENTATIVE. If there is no space left in the NC or if the NCE already exists, then the 6LP-GW should omit this step (i.e., neither try to create the NCE nor send the NS for DAD). Note that this extra processing MUST be performed in addition to forwarding the incoming RS to the IEEE 802.3 segment (i.e., first, forwarding the RS message, then creating the NCE and performing DAD, if possible). Note that no delay is needed before sending the NS for DAD after reception of the RS message, since nodes will wait a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY before sending their first RS [RFC4861]. 3.2.1.2. Changes to Unicast NS with ARO processing When receiving a NS with an ARO option, it is highly probable that the NCE already exists (with the same EUI-64 as the one present in the ARO EUI-64 field). In that case, the 6LP-GW SHOULD check the NCE state; if the NCE state is REGISTERED, this is the case of a re-registration and thus, proceed as in section 2.3.1.3 for the same case. In case the state is TENTATIVE, that means that either DAD has not completed yet, or it has completed successfully (as otherwise the state would be DUPLICATE instead of TENTATIVE). If DAD has not completed yet, then the 6LP-GW will simply set the ARO-pending flag to 1. If DAD has completed successfully, the 6LP-GW will refresh the NCE Lifetime, set the ARO-pending flag to 1 and forward the NS message to the IEEE 802.15.4 segment. In case the NCE state is DUPLICATE, a NA with an ARO option having status = 1 MUST be sent to the 6LN that originated the registration. After that, the NCE SHOULD be deleted (or marked for deletion). If the NCE does not exist when a NS with an ARO option arrives, or if it exists but with a different EUI-64 than the present in the ARO option, the 6LP-GW MUST behave as described in section 2.3.1.3 (figure 2) for those cases. Maqueda & Maguire Expires August 21, 2011 [Page 24] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 3.2.1.3. Changes to DAD on behalf of 6LoWPAN nodes DAD is performed as described in section 2.3.1.4, with the only differences taking place right after its completion. If the DAD process completes successfully, then the 6LP-GW MUST check the ARO-pending flag. If set, it MUST be cleared and a NA with an ARO having its status field set to 0 MUST be sent to the 6LN that originated the registration. If the ARO-pending flag is not set, the 6LP-GW MUST perform no change to the NCE until a NS with ARO arrives. In case DAD fails, if the ARO-pending flag is not set, the 6LP-GW MUST change the NCE state to DUPLICATE. In contrast, if the ARO-pending flag was set, the 6LP-GW MUST send a NA with ARO having its status field set to 1 (duplicate). After that the NCE SHOULD be deleted (or marked for deletion). 3.2.2. ICMPv6 option filtering Some of the options contained mainly in RA messages could be considered irrelevant for 6LoWPAN networks. Therefore, it may be of interest for implementations to filter out these options, reducing the packet size and therefore reducing power consumption by the IEEE 802.15.4 nodes for their delivery and processing. Examples of options that can be filtered are the Recursive DNS Server Option (defined in [RFC6106]) or the Flags Expansion Option (defined in [RFC5175]). Note that SLLAO, MTU, and PIO options MUST NOT be filtered out. The RECOMMENDED way to perform this filtering would be to simply remove all the options in RA messages originating in the IEEE 802.3 segment that are to be forwarded to the IEEE 802.15.4 except for the following options: SLLAO, MTU, and PIO. However, the list of options that are filtered may differ between implementations; it may even be desirable to allow this list to be manually configured. It is also possible to filter out irrelevant options of messages originating in the IEEE 802.15.4 segment and directed to the IEEE 802.3 interface, such as the ARO, 6CO, and ABRO. However, this filtering is of minor interest since the receiving and processing power saving would occur in a device that is likely to be plugged into the power mains. Maqueda & Maguire Expires August 21, 2011 [Page 25] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 3.2.3. 6LoWPAN-side Routing An interesting feature for route-over topologies is to provide some sort of routing protocol such as RPL ([I-D.ietf-roll-rpl]) on the IEEE 802.15.4 side of the 6LP-GW. Although this feature is not necessary for the correctness of the protocol (the 6LP-GW could simply rely on 6LRs), it will reduce the traffic, hence enhancing the performance of the network. Implementations MAY advantage of the routing protocol by letting the 6LP-GW "pretend" that it is the 6LBR or even provide an IPv6 address to the IEEE 802.15.4 interface. However, specific details regarding implementation of this feature are beyond the scope of this document. It is important to note that this feature is also useful to prevent loops in the network and, unless the feature is used, there SHOULD be some out-of-scope mechanism provided for this purpose, such as for example the use of the Spanning Tree Protocol (STP) [BRIDGES] for layer-2 forwarding. 3.2.4. 6LRs seen as hosts by FFDs 6LRs will never be the first hop for FFDs since the RR will be always in between FFDs and 6LRs. This document tries to equate 6LoWPAN nodes with their homologue FFD nodes. However, some implementations may find the fact that 6LRs are seen as routers by FFDs to be useless. Therefore it is possible for the 6LP-GW to mask the router nature of 6LRs so that they are seen by FFDs as simple hosts. To do so, the 6LP-GW MAY discard RS messages coming from the IEEE 802.3 segment and RA messages originating in the IEEE 802.15.4 segment instead of forwarding them. In addition, the isRouter flag of NA messages coming from or being sent on behalf of 6LNs SHOULD be set to 0 prior to sending them to the IEEE 802.3 segment. 4. Security Considerations The security considerations of Neighbor Discovery for IPv6 [RFC4861] and Neighbor Discovery Optimization for Low-power and Lossy Networks [I-D.ietf-6lowpan-nd] apply. When performing DAD on behalf of 6LNs, race conditions involving creating-deleting-NCEs cycles may occur. This problem can be solved by adding a new NCE state (as in section 3.2.1) in order to mark NCEs for deletion instead of deleting them immediately. Maqueda & Maguire Expires August 21, 2011 [Page 26] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 5. IANA Considerations No actions are required from IANA as result of the publication of this document. 6. Contributors Nicolas Mechin contributed significantly to the production of this document by providing guidance, useful insights, and thorough reviews. 7. Acknowledgments Thanks to Zach Shelby and Pascal Thubert for their reviews and instrumental advice. 8. References 8.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942, July 2010. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4919] Kushalnagar, N., Montenegro, G. and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, August 2007. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. [I-D.ietf-6lowpan-nd] Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor Discovery Optimization for Low-power and Lossy Networks", draft-ietf-6lowpan-nd-15, December 2010. Maqueda & Maguire Expires August 21, 2011 [Page 27] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 8.2. Informative References [EUI-64] IEEE Standards Association, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority" [I-D.ietf-6lowpan-hc] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-13 (work in progress), September 2010. [I-D.ietf-roll-rpl] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-17 (work in progress), December 2010. [RFC5175] Haberman, B. and R. Hinden, "IPv6 Router Advertisement Flags Option", RFC 5175, March 2008. [RFC5867] Martocci, J., De Mil, P. and N. Riou, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010. [RFC6106] Jeong, J., Park, S., Beloeil, L. and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010. [VATMAG98] Vatn, J and G. Maguire, "The effect of using co-located care-of addresses on macro handover latency", Fourteenth Nordic Tele-traffic Seminar (NTS 14), August 1998. [BRIDGES] IEEE Computer Society, "IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges", IEEE Std 802.1D (Revision of IEEE Std 802.1D- 1998), 2004. Maqueda & Maguire Expires August 21, 2011 [Page 28] Internet-Draft 6LoWPAN-ND Proxy-Gateway March 7, 2011 Contributors' Addresses Nicolas Mechin Sen.se 10, rue Saint Sebastien 75011 Paris France Phone : +33 681 041 721 Email : nicolas@sen.se Authors' Addresses Luis Maqueda Ara Royal Institute of Technology (KTH) Sen.se Emmylundsvaegen 5 SE-171 72 Solna Sweden Email: lc.maqueda@gmail.com Gerald Q. Maguire Jr. School of Information and Communication Technology (ICT) Royal Institute of Technology (KTH) Electrum 229 SE-164 40 Kista Sweden Email: maguire@kth.se Maqueda & Maguire Expires August 21, 2011 [Page 29]