Draft: Alternative to base the 6LoWPAN IPv6 interface identity on the EUI-64 extended address

Motivation:

ns-3 derived the lr-wpan IPv6 interface identifier from the 16-bit short address via a non-standard "pseudo-48-bit MAC." This change bases the identity on the stable 64-bit EUI-64 extended address — matching real 6LoWPAN/Thread stacks and RFC 4944/6775 — while preserving short-address-derived global addresses and 16-bit IPHC compression, and adding an opt-in switch to keep the short-address link-local for scenarios that want it.

Changes

• EUI-64 interface identity (lr-wpan). LrWpanNetDevice::GetAddress() now returns the 64-bit extended address, so the IPv6 link-local is EUI-64-based. The pseudo-48-bit MAC and its PseudoMacAddressMode attribute are removed; broadcast/multicast and received frames now use real Mac16 addresses.

• Generic link-layer address provider (network). New LinkLayerAddressProvider — a single, callback-configured aggregable object — lets a device expose its additional link-layer addresses to upper layers via GetObject<>(), returned as a preference-ordered std::vector

  with no concrete-device dependency in the generic stack. It is deliberately device-agnostic (no "short-address" assumption), so it also serves multi-address devices such as Bluetooth LE. lr-wpan aggregates one advertising {short, extended}; SixLowPanNetDevice aggregates one that forwards the underlying device's addresses through the wrapper.

• Short-address-derived globals preserved. SLAAC (Ipv6AddressHelper::Assign, generic autoconfiguration) and 6LoWPAN-ND form the global IID from LinkLayerAddressProvider::GetAutoconfiguredAddress() — the 16-bit short when assigned (…:ff:fe00:XXXX, keeping 16-bit IPHC compression), otherwise the EUI-64. Ethernet/CSMA is unaffected (still uses its 48-bit MAC).

• Variable-width ND link-layer option (internet). Icmpv6OptionLinkLayerAddress now deserializes 2-, 6- and 8-byte link-layer addresses correctly (it previously assumed 6 bytes and crashed on the 8-byte EUI-64), using the receiving device's address length as a hint. RFC 4861 §4.6.1-compliant, wire format unchanged, Ethernet behavior identical.

• lr-wpan dual-mode Send/Receive. Send() selects short vs. extended 802.15.4 addressing from the destination address type; the receive path presents the source address per the frame's source-addressing mode (also fixes a latent bug that keyed off the destination mode).

• mesh-under (6LoWPAN). The mesh header now carries addresses consistent with the EUI-64 identity (RFC 4944 §5.2 permits 16- or 64-bit originator/final-destination); mesh-under forwarding works again.

• Opt-in 16-bit link-local (UseMinimalLinkLocalId). New SixLowPanNetDevice::UseMinimalLinkLocalId() (and a matching SixLowPanHelper::UseMinimalLinkLocalId(NetDeviceContainer)) selects the short-address-derived link-local (fe80::ff:fe00:XXXX) instead of the default EUI-64. It reuses the provider's preferred address, falls back to the EUI-64 when no short address is assigned (FF:FF/FF:FE) or on non-802.15.4 devices, and must be called before the interface is brought up.

• No behavior change for existing scenarios. Associated nodes still get short-derived globals with identical IPv6 addresses; the default link-local stays EUI-64. All lr-wpan / 6LoWPAN / internet-ND suites pass. The example-ping-lr-wpan reference log is updated to reflect the EUI-64 MAC identity (IPv6 addresses unchanged).

Known limitations / follow-ups

• mesh-under uses extended (64-bit) mesh-header addresses (RFC-legal, larger header). A faithful 16-bit-short mesh would need per-neighbor short-address resolution (not implemented).
• The link-local and any global formed before a short address is assigned use the EUI-64 fallback and are not re-derived if the short address arrives or changes later (runtime address-change reaction not implemented). This applies to UseMinimalLinkLocalId too — it takes effect only when the short address is present at interface set-up.

Code generated with the help of Claude Opus 5