Transmission of IPv6 Packets over Power Line Communication (PLC) Networks
Extracted elements (24)
RFC 4944's 16-bit datagram tag is considered sufficient for constrained PLC because the data rate is much lower than the high-rate scenario in RFC 4963 where 16-bit IP identification fields are insufficient to prevent incorrectly assembled fragments.
A PLC node distinguishes IPv6 PDUs from non-IPv6 PDUs using the equivalent of an Ethertype: RFC 7973 defines Ethertype 'A0ED' for LoWPAN encapsulation (carried in the IE field for IEEE 1901.2/G.9903), while IEEE 1901.1 uses MSDU type value 49 for IP packets.
A 48-bit MAC address MUST first be extended to a 64-bit IID by inserting 0xFFFE at the fourth and fifth octets as specified in RFC 2464. The IPv6 IID is derived from the 64-bit IID by inverting the U/L bit.
For address registration in mesh-under mode, a PLC device MUST register its addresses by sending a unicast NS message with an ARO or EARO directly to the 6LBR; DAR/DAC or EDAR/EDAC messages are not required.
For address registration in route-over mode, a PLC device MUST register its addresses by sending a unicast link-local NS to the 6LR. Non-link-local addresses MUST be registered via ARO or EARO in DAR or EDAR messages.
For dissemination of context information, RAs MUST be used as per RFC 6775. The 6LoWPAN context option (6CO) MUST be included in the RA to disseminate the Context IDs used for prefix and/or address compression.
For IEEE 1901.1 12-bit short addresses, the 64-bit IID MUST be derived by inserting 0xFFFE into the 48-bit pseudo-address formed from 24-bit NID and 12-bit TEI, resulting in YYYY:YYFF:FE00:0XXX.
For IEEE 1901.2 and ITU-T G.9903, the 64-bit IID MUST be derived from the 16-bit PAN ID, zero bits, and 16-bit short address by inserting 0xFFFE, forming: 16_bit_PAN:00FF:FE00:16_bit_short_address.
For PLC devices compliant with RFC 8505, the 'R' flag in the EARO MUST be set when sending NSs in order to extract the status information in the replied NAs from the 6LR.
For privacy reasons, the IID derived from the MAC address SHOULD only be used for link-local address configuration. A PLC host SHOULD use the IID derived from the short link-layer address for public network communication to avoid exposing the MAC address.
If DHCPv6 is used to assign addresses or the IPv6 address is derived from a unique long or short link-layer address, Duplicate Address Detection (DAD) SHOULD NOT be utilized. Otherwise, DAD MUST be performed at the 6LBR or proxied by the routing registrar.
If the configured MTU is smaller than 1280 octets (e.g., in high-noise IEEE 1901.1/1901.2 environments), the fragmentation and reassembly defined in RFC 4944 MUST be used. For ITU-T G.9903 (fixed 400-octet MAC payload), adaptation-layer fragmentation per RFC 4944 MUST always be provided.
In scenarios where physical attacks are considered relatively highly possible, per-device credentials SHOULD be used. When group-shared symmetric keys are used, a compromised device puts the whole network or large parts of it at risk.
The hash algorithm for IID generation SHOULD be SHA256, using the version number, the PAN ID or NID, and the short address as input, with the 256-bit output truncated to 64 bits for the IID.
When the PLC MAC MTU cannot support the 1280-octet IPv6 packet, headers MUST be compressed according to the encoding formats specified in RFC 6282, including the Dispatch Header, LOWPAN_IPHC, and the compression residue carried inline.
When using IIDs derived from short addresses and choosing to comply with the U/L and I/G bit semantics, these two bits MUST both be set to zero, and MUST NOT be a valid part of the PAN ID or NID.
IP addresses derived from short link-layer addresses without sufficient entropy are vulnerable to address scanning and tracking. Other schemes such as limited DHCPv6 lease periods, CGAs (RFC 3972), Temporary Address Extensions (RFC 8981), HBAs (RFC 5535), or semantically opaque addresses (RFC 7217) SHOULD be used to enhance IID privacy.
For IEEE 1901.1 with 12-bit short addresses, the header compression SAM/DAM mode '10' is modified: 16 bits are carried inline representing 0000:00ff:fe00:0XXX, where the first 4 bits of the 16-bit inline value are zero and 0XXX encodes the 12-bit short address.
PLC devices have a globally unique long address of 48 bits (IEEE 1901.1) or 64 bits (IEEE 1901.2, ITU-T G.9903) and a short address of 12 bits (IEEE 1901.1) or 16 bits (IEEE 1901.2, ITU-T G.9903). Devices join using the long address and communicate using the short address after joining.
The MTU for ITU-T G.9903 is 400 octets, insufficient for IPv6's minimum 1280-octet MTU, requiring fragmentation and reassembly at the adaptation layer. IEEE 1901.1 supports up to 2031 octets and IEEE 1901.2 supports up to 1576 octets, but smaller MTUs may be configured in high-noise environments.
Due to the high accessibility of power grids, PLC is susceptible to eavesdropping. Link-layer security mechanisms including payload encryption and device authentication are required. An on-path malicious PLC device could eavesdrop or modify packets without confidentiality and integrity mechanisms.
Mutual authentication of a PLC network and new devices is important to prevent malicious devices from joining. Methods include TLS/DTLS Profile (RFC 7925), Constrained Join Protocol CoJP (RFC 9031), Zero-Touch Secure Join, and EAP methods via PANA (RFC 5191). No specific mechanism is mandated.
The IPv6 link-local address for a PLC interface is formed by appending the IID to the FE80::/64 prefix: 10 bits (1111111010), 54 zero bits, and 64 bits of Interface Identifier.
The Unicast Address Mapping option for IEEE 1901.2 and ITU-T G.9903 in NS/NA messages is 8 octets: Type (8 bits), Length=1 (8 bits), PAN ID (16 bits), 16-bit Padding (zeros), and Short Address (16 bits).