net_if: include pan id for eui-64/IID generation from short address

[cgundogan]

Currently, the link-local address generation is odd, due to some complications and confusions regarding the generation of the EUI-64/IID.
This PR fixes the problems (that we are facing with RPL right now) according to the discussion in #2508

IIDs generated from short addresses will be of the form 16_bit_PAN:00ff:fe00:16_bit_short_address, with an U/L-Bit set to 0.

[cgundogan]

@gebart can you have a look if this comes close to what we discussed in #2508 ?
@authmillenon I would also like to hear your opinion on this

[cgundogan]

ifconfig
Iface   0   HWaddr: 0x2300 Channel: 0 PAN ID: 0xabcd
            EUI-64: a9-cd-00-ff-fe-00-23-00
            Source address mode: short
            Transceivers:
             * native
            inet6 addr: fe80::abcd:ff:fe00:2300/128  scope: local
            inet6 addr: ff02::1:ff00:2300/128  scope: local [multicast]
            inet6 addr: ff02::1/128  scope: local [multicast]
            inet6 addr: ::1/128  scope: global
            inet6 addr: ff02::1:ff00:1/128  scope: local [multicast]
            inet6 addr: ff02::1a/128  scope: local [multicast]
            inet6 addr: abcd::abcd:ff:fe00:2300/128  scope: global
            inet6 addr: ff02::2/128  scope: local [multicast]

[miri64]

This is (and was always) somewhat confusing to me: static HC1 (introduced in the original 6LoWPAN RFC) states the address must be generated from the PAN ID as this PR introduces: https://tools.ietf.org/html/rfc4944#section-6

In IPHC this notion is dropped however: https://tools.ietf.org/html/rfc6282#section-3.2.2 (with no reference to the previous statement). As we only implement IPHC, I decided to go for the second approach since it simplifies a lot and makes 6LoWPAN much more independent from its lower layers.

In the end I think its up to the 6LoWPAN or IPv6 implementation to decide what to do, not the interfaces ;-) (that's why I put such things into the network layer implementations nowadays. See #2437)

[cgundogan]

well the problem is actually not really the missing pan_id in the IID, but the confusion about the u/l-Bit. That's why packets cannot be received in the rpl_example right now..
While packets are sent to an address A, the node who should own this address, has A with an inverted u/l-Bit configured, instead.. therefore packet drops occure.

[jnohlgard]

Actually I think you have this reversed, the EUI-64 (radio link layer extended address) should have the U/L bit set to signify a locally administered address, while the IPv6 IID should have the bit inverted, 0 means locally administered.

See https://supportforums.cisco.com/document/100566/understanding-ipv6-eui-64-bit-address and http://packetlife.net/blog/2008/aug/4/eui-64-ipv6/

[cgundogan]

its set later to 1. at this line the MAC/IID address is built with the pan_id, 00fffe00 and then the short address

[cgundogan]

note that for eui-64 addresses this line of code is not executed => force_generation is false

[cgundogan]

the final u/l-bit inversion is done in file ip.c at line 693

[miri64]

There should be no inversion at all for short address generated IIDs iirc.

[jnohlgard]

Can we close this?
There have appeared many arguments against including the PAN ID in EUI generation, especially since NSTF is going with the 0000:00ff:fe00:xxxx model.

[cgundogan]

NACK (: