Transmission of IPv6 Packets over ITU-T G.9959 Networks
Extracted elements (31)
HomeIDs and NodeIDs are allocated by a network controller, creating a single point of failure; identifier validity is limited to the lifetime of network membership. High-reliability deployments may benefit from a redundant network controller.
The 0xFFFF infinite-lifetime extension is needed for island-mode networks whose network controller (e.g., a battery-powered remote control) may be sleeping and unable to perform periodic prefix renewal, making a finite lifetime impractical.
The IID format 0000:00ff:fe00:YYXX was chosen to enable efficient IPv6 header compression: the fixed pattern allows addresses to be reconstructed from the 8-bit NodeID alone, minimizing over-the-air bytes in constrained G.9959 networks.
When applying RFC 6282 or RFC 7400 to G.9959, '802.15.4' is replaced by 'G.9959', '802.15.4 short address' by '<Interface><G.9959 NodeID>', and '802.15.4 PAN ID' by 'G.9959 HomeID'. 64-bit 802.15.4 address details do not apply.
A node implementing RFC 7400 GHC MUST probe its peers for GHC support before applying GHC compression.
A node MUST NOT compute the NodeID from the IID if the first 6 bytes of the IID do not comply with the format 0000:00ff:fe00; in that case, RFC 6775 address resolution mechanisms apply.
An expired CID and its associated prefix MUST NOT be reset; they must be retained in receive-only mode. If a sleeping node uses an expired CID, the ABR MUST return an RA with fresh context information to the originator.
An implementation for mesh-under operation MUST use RFC 6775 mechanisms for managing IPv6 prefixes and CID context information. RFC 6775 DAD MUST NOT be used in mesh-under, since the G.9959 inclusion process guarantees NodeID uniqueness.
An IPv6 host MUST construct its link-local IPv6 address from the link-layer-derived IID in order to facilitate IP header compression as described in RFC 6282.
If DHCPv6-based addressing is used, the DHCPv6 client MUST use a DUID of type DUID-UUID (RFC 6355), with the UUID generated as a 47-bit random number-based UUID per RFC 4122 Section 4.5, and stored persistently.
Implementations claiming conformance MUST enable G.9959 shared network key security. For applications with high confidentiality or integrity requirements, additional application-layer security (e.g., IPsec, TLS) SHOULD be applied.
In route-over environments, IPv6 hosts MUST use RFC 6775 address registration. Route-over RFC 6775 requirements apply with no modifications.
IPv6 header compression per RFC 6282 MUST be supported by all implementations. Generic Header Compression (GHC) per RFC 7400 MAY additionally be supported.
IPv6 multicast packets MUST be carried via G.9959 broadcast: the destination HomeID MUST be the network HomeID and the destination NodeID MUST be the broadcast NodeID 0xff.
IPv6 packets MUST be transmitted using G.9959 transmission profile R3 or higher, which provides segmentation and reassembly for payloads up to 1350 octets.
Mesh-under networks MUST NOT use RFC 6775 address registration. However, RFC 6775 address registration MUST be used if the first 6 bytes of the IID do not conform to the link-layer-derived format.
The default YY value in the IID MUST be zero. A node MAY use non-zero YY values to instantiate multiple IPv6 interfaces. The YY value MUST be ignored when computing the NodeID (XX) from an IID.
The link-layer-derived IID (0000:00ff:fe00:YYXX) MUST be used whether autoconfiguring a ULA IPv6 address (RFC 4193) or a globally routable IPv6 address (RFC 3587) in G.9959 subnets.
The RA Router Lifetime value 0xFFFF MUST be interpreted as infinite lifetime. This value MUST NOT be used by ABRs; it is reserved for sleeping island-mode network controllers such as battery-powered remote controls.
The Universal/Local (U/L) bit in the IID used for the IPv6 link-local address MUST be set to zero, consistent with the fact that the G.9959 NodeID is not globally unique.
When a CID is obsoleted (lifetime set to zero), the CID MUST NOT be reused immediately; the next vacant CID should be assigned instead. Header compression based on CIDs MUST NOT be used for RA messages carrying context information.
When a node does not support or when M flag is 0, the node MUST use link-layer-derived addressing. When M flag support is present and M=1, the node MUST use DHCPv6-based addressing and MUST comply fully with RFC 6775.
DHCPv6 decouples the IPv6 address from the link-layer address and can provide enhanced privacy via short lease periods and fresh address assignments, but non-link-layer-derived IIDs cannot be compressed, increase datagram size, and require more frequent CID updates that can drain battery life on sleeping nodes.
Link-layer-derived IIDs may enable device tracking across global prefix changes. However, the risk from G.9959 specifically is limited because the link-layer address is only 8 bits rather than the 48 or 64 bits common on other link layers.
A G.9959 NodeID is mapped to an IEEE EUI-64-style IID as: IID = 0000:00ff:fe00:YYXX, where XX is the 8-bit NodeID and YY is a 1-byte interface discriminator (default zero). Multiple IPv6 interfaces may be instantiated by using non-zero YY values.
Only one dispatch value is defined for G.9959: pattern '01 1xxxxx' identifies 6LoWPAN_IPHC (IPv6 Header Compression per RFC 6282). Other IANA-assigned 6LoWPAN dispatch values do not apply to this document.
G.9959 uses AES for authentication and encryption of frames and employs challenge-response handshaking to prevent replay attacks. Devices communicating outside the PAN (e.g., billing or safety-critical products) SHOULD additionally use end-to-end security such as IPsec or TLS.
IID derivation from 8-bit NodeIDs preserves intra-network uniqueness but offers no protection against forgery. Neighbor Discovery is susceptible to threats per RFC 3756, and mesh routing introduces additional ad hoc routing threats per [KW03]. Mandatory link-layer security with a shared key mitigates the majority of these threats.
The 6LoWPAN Dispatch Header consists of: 6LoWPAN CmdCls (1 octet, MUST be 0x4F), Dispatch (1 octet identifying the following header type), and a Type-specific header. Frames with CmdCls other than 0x4F MUST be ignored.
The Source/Target Link-layer Address option for G.9959 is 8 octets: Type (1 octet), Length=1 (1 octet), 0x00 padding (1 octet), NodeID (1 octet), followed by 4 octets of zero padding.
When a 16-bit address is required for header compression, it MUST be formed by prepending a 1-byte Interface label to the 1-byte G.9959 NodeID. If Interface is zero (default), all corresponding IPv6 address bytes may be elided.