3 ms·

Huh? No, the MAC was never a part of the publicly-visible v6 address. I know you're talking about SLAAC, but SLAAC is just a convenient way of picking a unique

by Dagger2 19d ago

Huh? No, the MAC was never a part of the publicly-visible v6 address. I know you're talking about SLAAC, but SLAAC is just a convenient way of picking a unique address. Changing the address wouldn't result in e.g. the packet being sent to a different MAC. Even sending packets to link-local addresses still does NDP, rather than parse the MAC out of the address.

cyberax 19d ago
> Huh? No, the MAC was never a part of the publicly-visible v6 address. Yes, it was: https://www.rfc-editor.org/info/rfc3513/#section-2.5.4 https://www.rfc-editor.org/info/rfc3513/#section-2.5.4 The 64/64-bit split was in fact a result of (then planned) Bluetooth having 64 bit MACs. Moreover, the initial IPv6 RFCs did not have privacy extensions for SLAAC: https://www.rfc-editor.org/info/rfc2464/#section-4 https://www.rfc-editor.org/info/rfc2464/#section-4 > Even sending packets to link-local addresses still does NDP, rather than parse the MAC out of the address. It doesn't.
- fulafel 19d ago
  Broadly it's true that historically there was this idea for ethernet networks at least. It was always optional though. Even in that long obsolete rfc2464 it's described as the way to do SLAAC which was optional even in 1998. This kind of thing doesn't normally count as violation of layering though. In protocol design its common to leverage identifiers from lower layers for addressing. For example many workings of the internet would be hard to imaging with the rule that you could not use IP addresses and ports in upper level protocols (like DNS, P2P protocols, etc)
  - cyberax 18d ago
    The early RFCs were written more informally, so it's hard to say what was optional. However, the consensus was that SLAAC was supposed to be the main way to configure IPv6, along with fully manual configuration. > In protocol design its common to leverage identifiers from lower layers for addressing. Yes, that's why my email has the IP address of the mail server. And why my WhatsUp contains the IMEI of my phone.
- Dagger2 17d ago
  > It doesn't. ...it does. You can spend five seconds in tcpdump to see that it does: $ ping6 fe80::506c:e9ff:fe08:9ba3%eth0 11:58:48.741688 d6:57:10:b8:52:77 > 33:33:ff:08:9b:a3, ethertype IPv6 (0x86dd), length 86: fe80::d457:10ff:feb8:5277 > ff02::1:ff08:9ba3: ICMP6, neighbor solicitation, who has fe80::506c:e9ff:fe08:9ba3, length 32 11:58:48.742459 00:23:6e:5b:b8:2b > d6:57:10:b8:52:77, ethertype IPv6 (0x86dd), length 86: fe80::506c:e9ff:fe08:9ba3 > fe80::d457:10ff:feb8:5277: ICMP6, neighbor advertisement, tgt is fe80::506c:e9ff:fe08:9ba3, length 32 Notice how a) it's doing NDP, and b) the link-local is fe80::506c:e9ff:fe08:9ba3 while the MAC is 00:23:6e:5b:b8:2b? The "506c:e9ff:fe08:9ba3" part of the address isn't being treated as a MAC address by the protocol -- it's just some opaque bytes. Yes, those bytes can be picked by looking at a MAC address, but that's only one way to pick them and the protocol doesn't treat those bytes as having any particular significance, and in particular it never assumes they contain a MAC or tries to use them as an actual MAC, so it doesn't qualify as a layering violation.

by Dagger2 19d ago

cyberax 19d ago

> Huh? No, the MAC was never a part of the publicly-visible v6 address. Yes, it was: https://www.rfc-editor.org/info/rfc3513/#section-2.5.4 https://www.rfc-editor.org/info/rfc3513/#section-2.5.4 The 64/64-bit split was in fact a result of (then planned) Bluetooth having 64 bit MACs. Moreover, the initial IPv6 RFCs did not have privacy extensions for SLAAC: https://www.rfc-editor.org/info/rfc2464/#section-4 https://www.rfc-editor.org/info/rfc2464/#section-4 > Even sending packets to link-local addresses still does NDP, rather than parse the MAC out of the address. It doesn't.

fulafel 19d ago
Broadly it's true that historically there was this idea for ethernet networks at least. It was always optional though. Even in that long obsolete rfc2464 it's described as the way to do SLAAC which was optional even in 1998. This kind of thing doesn't normally count as violation of layering though. In protocol design its common to leverage identifiers from lower layers for addressing. For example many workings of the internet would be hard to imaging with the rule that you could not use IP addresses and ports in upper level protocols (like DNS, P2P protocols, etc)
- cyberax 18d ago
  The early RFCs were written more informally, so it's hard to say what was optional. However, the consensus was that SLAAC was supposed to be the main way to configure IPv6, along with fully manual configuration. > In protocol design its common to leverage identifiers from lower layers for addressing. Yes, that's why my email has the IP address of the mail server. And why my WhatsUp contains the IMEI of my phone.
Dagger2 17d ago
> It doesn't. ...it does. You can spend five seconds in tcpdump to see that it does: $ ping6 fe80::506c:e9ff:fe08:9ba3%eth0 11:58:48.741688 d6:57:10:b8:52:77 > 33:33:ff:08:9b:a3, ethertype IPv6 (0x86dd), length 86: fe80::d457:10ff:feb8:5277 > ff02::1:ff08:9ba3: ICMP6, neighbor solicitation, who has fe80::506c:e9ff:fe08:9ba3, length 32 11:58:48.742459 00:23:6e:5b:b8:2b > d6:57:10:b8:52:77, ethertype IPv6 (0x86dd), length 86: fe80::506c:e9ff:fe08:9ba3 > fe80::d457:10ff:feb8:5277: ICMP6, neighbor advertisement, tgt is fe80::506c:e9ff:fe08:9ba3, length 32 Notice how a) it's doing NDP, and b) the link-local is fe80::506c:e9ff:fe08:9ba3 while the MAC is 00:23:6e:5b:b8:2b? The "506c:e9ff:fe08:9ba3" part of the address isn't being treated as a MAC address by the protocol -- it's just some opaque bytes. Yes, those bytes can be picked by looking at a MAC address, but that's only one way to pick them and the protocol doesn't treat those bytes as having any particular significance, and in particular it never assumes they contain a MAC or tries to use them as an actual MAC, so it doesn't qualify as a layering violation.