3 ms·

Morass, mess, broadcast/multicast, etc aside (seems more like complaints of complexity than layering), IPv4+ARP is the textbook example of a layering violation.

Morass, mess, broadcast/multicast, etc aside (seems more like complaints of complexity than layering), IPv4+ARP is the textbook example of a layering violation. When you do want to violate, having the L2 info in the L3 packet is still cleaner than L3 info in L2. One is a protocol carrying its own glue in itself, the other is a protocol using different protocols (per L2) to discover the glue the same way it could have itself anyways. It's certainly convenient of course, but that doesn't make it cleaner layering. It also gives a consistent answer for different L2s e.g. cellular links because of this.

cyberax 18d ago
Whut? IPv4 is an example of _correct_ layering. The hardware address is a detail that does not leak into upper layers. It's confined purely to the network layer. In contrast, with IPv6 the whole 64/64 separation is a result of leaking the MAC address into upper protocols. Indeed, MAC was supposed to be a part of the publicly visible IPv6 addresses for hosts!
- Dagger2 18d 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 18d 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 17d 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 17d 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 16d 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.
- zamadatix 17d ago
  A network layering violation is when a protocol at one layer relies on its information being carried in protocols on other layers. It's not just when the addressing bits happen to match between layers, which would be done by the host locally without a separate L2 protocol anyways. Nor was what you're discussing a requirement of IPv6, it was an optional addressing scheme. Nor did it take on as a popular option. Nor does it do anything to explain why IPv4 leaking address resolution down instead of self containing it is supposed to be a correct example.
  - cyberax 17d ago
    > A network layering violation is when a protocol at one layer relies on its information being carried in protocols on other layers. That's exactly what's happening in IPv6. The host address leaks information about the underlying hardware into higher-level protocols. For example, you can't use a /80 site prefix because there aren't enough bits left for the hardware address mapping. In contrast, IPv4 works just fine over Ethernet that has more MACs than the entire IPv4 address space. > Nor was what you're discussing a requirement of IPv6, it was an optional addressing scheme. It was a requirement initially. > Nor does it do anything to explain why IPv4 leaking address resolution down instead of self containing it is supposed to be a correct example. WTF is "leaking down"? The higher protocol levels are supposed to use lower protocol levels. "Leaking down" would mean, for example, that you need to set MACs of your network cards to be equal to IPv4 addresses.
    - zamadatix 17d ago
      > That's exactly what's happening in IPv6. The host address leaks information about the underlying hardware into higher-level protocols I think there is still confusion what "A network layering violation is when a protocol at one layer relies on its information being carried in protocols on other layers" means. As a practical examples: "Reading a book has a main character 'John' in it and deciding to use that as your name in your speech" is not a layering violation for speech. At no point does anyone need to read to understand your name is John while speaking with you nor does anything break when you change your mind and decide to be called Andsynstd even though it has never been written in a book written in a book. "You can find my name if you read that book over there" is a layering violation. They have to stop using speech with you, switch to reading the book at a completely different layer of communication, and then suddenly start calling you John in speech even though it was never communicated in speech. If they just say "what's your name" and you say "John" they don't need to get any information from outside the network layer, regardless if the bits in your response also contained your L2 address or not. In your example, that you read your hardware as one option to come up with your address does not force anyone on the network to use a protocol other than IPv6 to learn your address and talk with you. The litmus test for this is "if you replace Ethernet with a different L2 which can't transport any protocol but L3 protocols on top of it, can you still resolve addresses?" If the answer is no then it's handled externally, if the external handling happens on L2 then it's a layering violation. > It was a requirement initially. Not at all. From section 2.4.1 of RFC 1884 in 1995, which introduced the concept of IPv6 addressing architecture you can continue reading past the paragraph mentioning the example of a link-local derived address to see it was never the only example: Another unicast address format example is where a site or organization requires additional layers of internal hierarchy. In this example the subnet ID is divided into an area ID and a subnet ID. Its format is: | s bits | n bits | m bits | 128-s-n-m bits | +----------------------+---------+--------------+-----------------+ | subscriber prefix | area ID | subnet ID | interface ID | +----------------------+---------+--------------+-----------------+ This technique can be continued to allow a site or organization to add additional layers of internal hierarchy. It may be desirable to use an interface ID smaller than a 48-bit IEEE 802 MAC address to allow more space for the additional layers of internal hierarchy. These could be interface IDs which are administratively created by the site or organization. > WTF is "leaking down"? The higher protocol levels are supposed to use lower protocol levels. Hopefully this is already explained in the part about what a layering violation actually is, but the problem is indeed not related to IPv4 riding on top of an L2. Oblivious transport of higher layers is the point of abstracted layers. The problem is ARP, an L2 protocol, is not oblivious to the information of the layers above it, such as L3 IP information, breaking the abstraction. IPv6 corrected this, the neighbor exchange information is always encapsulated in an L3 packet.
amluto 18d ago
Sticking L2 into L3 means that L3 needs the ability to communicate with nodes with as-yet-unknown L2 addresses and that L3 nodes that don’t have an L3 address yet need to be able to transmit L3 packets. Both of these are quite messy, and APR completely avoids these problems. (I am not, however, defending DHCPv4 - that has some of the same problem.)
- zamadatix 17d ago
  ARP does not avoid this problem at all, it broadcasts until enough L2 information is exchanged to unicast (which usually happens to also be the point the L3 information is resolved). This is the same broadcast-then-unicast process ND uses, except ND can also start as a multicast forward if MLD is supported (naturally falling back to broadcast on the switch if not).
  - amluto 17d ago
    You’re misunderstanding my point. ARP is a protocol that makes perfect sense even when spoken by hosts that only know their own MAC addresses and do not yet know their IPv4 addresses. IPv6 ND is IPv6 except it has the weird edge case in that it is spoken between hosts that may not know their own IPv6 addresses. So you end up with delights like the “unspecified address) built into IPv6.
    - zamadatix 17d ago
      If I'm 192.168.129.10 and I want to resolve who 192.168.129.17 is, I make an ARP with the destination as ff:ff:ff:ff:ff:ff. This is a placeholder L2 destination which just means "everyone". I likely need to do something completely different when not on Ethernet (which is surprisingly common when you get beyond PCs on a LAN) and that may or may not involve ARP but we'll stick with ARP on Ethernet for now. If I'm 2600::10 and I want to resolve who 2600::17 is, the IPv6 destination for the ND packet is set to FF02::1:FF00:17. This is a union of the multicast range with part of the destination address (so the request can almost always only go straight to the 2600::17 node rather than using a placeholder to blast to everyone). If Ethernet is in use, the L2 destination is derived and set to 33:33:FF:00:00:17 by and for the same reasoning. Different addresses will be derived e.g. for 2600::18 If I don't know my address yet (say, for DAD in this example), ARP actually uses a second made up address "0.0.0.0" for the source IP which just means unspecified. In ND, I do the same to be able to DAD my link local address by saying I'm :: (also all 0s) but at least the destination is still not ff:ff:ff:ff:ff:ff. As a bonus, since ND only uses the link local address as the source for ND, DAD for the link local address is the only time the source address can be unknown. DAD for any number of unicast addresses will always have the link local to put as the source, even if they are not in the same subnet in the L2.

cyberax 18d ago

Whut? IPv4 is an example of _correct_ layering. The hardware address is a detail that does not leak into upper layers. It's confined purely to the network layer. In contrast, with IPv6 the whole 64/64 separation is a result of leaking the MAC address into upper protocols. Indeed, MAC was supposed to be a part of the publicly visible IPv6 addresses for hosts!

Dagger2 18d 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 18d 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 17d 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 17d 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 16d 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.
zamadatix 17d ago
A network layering violation is when a protocol at one layer relies on its information being carried in protocols on other layers. It's not just when the addressing bits happen to match between layers, which would be done by the host locally without a separate L2 protocol anyways. Nor was what you're discussing a requirement of IPv6, it was an optional addressing scheme. Nor did it take on as a popular option. Nor does it do anything to explain why IPv4 leaking address resolution down instead of self containing it is supposed to be a correct example.
- cyberax 17d ago
  > A network layering violation is when a protocol at one layer relies on its information being carried in protocols on other layers. That's exactly what's happening in IPv6. The host address leaks information about the underlying hardware into higher-level protocols. For example, you can't use a /80 site prefix because there aren't enough bits left for the hardware address mapping. In contrast, IPv4 works just fine over Ethernet that has more MACs than the entire IPv4 address space. > Nor was what you're discussing a requirement of IPv6, it was an optional addressing scheme. It was a requirement initially. > Nor does it do anything to explain why IPv4 leaking address resolution down instead of self containing it is supposed to be a correct example. WTF is "leaking down"? The higher protocol levels are supposed to use lower protocol levels. "Leaking down" would mean, for example, that you need to set MACs of your network cards to be equal to IPv4 addresses.
  - zamadatix 17d ago
    > That's exactly what's happening in IPv6. The host address leaks information about the underlying hardware into higher-level protocols I think there is still confusion what "A network layering violation is when a protocol at one layer relies on its information being carried in protocols on other layers" means. As a practical examples: "Reading a book has a main character 'John' in it and deciding to use that as your name in your speech" is not a layering violation for speech. At no point does anyone need to read to understand your name is John while speaking with you nor does anything break when you change your mind and decide to be called Andsynstd even though it has never been written in a book written in a book. "You can find my name if you read that book over there" is a layering violation. They have to stop using speech with you, switch to reading the book at a completely different layer of communication, and then suddenly start calling you John in speech even though it was never communicated in speech. If they just say "what's your name" and you say "John" they don't need to get any information from outside the network layer, regardless if the bits in your response also contained your L2 address or not. In your example, that you read your hardware as one option to come up with your address does not force anyone on the network to use a protocol other than IPv6 to learn your address and talk with you. The litmus test for this is "if you replace Ethernet with a different L2 which can't transport any protocol but L3 protocols on top of it, can you still resolve addresses?" If the answer is no then it's handled externally, if the external handling happens on L2 then it's a layering violation. > It was a requirement initially. Not at all. From section 2.4.1 of RFC 1884 in 1995, which introduced the concept of IPv6 addressing architecture you can continue reading past the paragraph mentioning the example of a link-local derived address to see it was never the only example: Another unicast address format example is where a site or organization requires additional layers of internal hierarchy. In this example the subnet ID is divided into an area ID and a subnet ID. Its format is: | s bits | n bits | m bits | 128-s-n-m bits | +----------------------+---------+--------------+-----------------+ | subscriber prefix | area ID | subnet ID | interface ID | +----------------------+---------+--------------+-----------------+ This technique can be continued to allow a site or organization to add additional layers of internal hierarchy. It may be desirable to use an interface ID smaller than a 48-bit IEEE 802 MAC address to allow more space for the additional layers of internal hierarchy. These could be interface IDs which are administratively created by the site or organization. > WTF is "leaking down"? The higher protocol levels are supposed to use lower protocol levels. Hopefully this is already explained in the part about what a layering violation actually is, but the problem is indeed not related to IPv4 riding on top of an L2. Oblivious transport of higher layers is the point of abstracted layers. The problem is ARP, an L2 protocol, is not oblivious to the information of the layers above it, such as L3 IP information, breaking the abstraction. IPv6 corrected this, the neighbor exchange information is always encapsulated in an L3 packet.

amluto 18d ago

Sticking L2 into L3 means that L3 needs the ability to communicate with nodes with as-yet-unknown L2 addresses and that L3 nodes that don’t have an L3 address yet need to be able to transmit L3 packets. Both of these are quite messy, and APR completely avoids these problems. (I am not, however, defending DHCPv4 - that has some of the same problem.)

zamadatix 17d ago
ARP does not avoid this problem at all, it broadcasts until enough L2 information is exchanged to unicast (which usually happens to also be the point the L3 information is resolved). This is the same broadcast-then-unicast process ND uses, except ND can also start as a multicast forward if MLD is supported (naturally falling back to broadcast on the switch if not).
- amluto 17d ago
  You’re misunderstanding my point. ARP is a protocol that makes perfect sense even when spoken by hosts that only know their own MAC addresses and do not yet know their IPv4 addresses. IPv6 ND is IPv6 except it has the weird edge case in that it is spoken between hosts that may not know their own IPv6 addresses. So you end up with delights like the “unspecified address) built into IPv6.
  - zamadatix 17d ago
    If I'm 192.168.129.10 and I want to resolve who 192.168.129.17 is, I make an ARP with the destination as ff:ff:ff:ff:ff:ff. This is a placeholder L2 destination which just means "everyone". I likely need to do something completely different when not on Ethernet (which is surprisingly common when you get beyond PCs on a LAN) and that may or may not involve ARP but we'll stick with ARP on Ethernet for now. If I'm 2600::10 and I want to resolve who 2600::17 is, the IPv6 destination for the ND packet is set to FF02::1:FF00:17. This is a union of the multicast range with part of the destination address (so the request can almost always only go straight to the 2600::17 node rather than using a placeholder to blast to everyone). If Ethernet is in use, the L2 destination is derived and set to 33:33:FF:00:00:17 by and for the same reasoning. Different addresses will be derived e.g. for 2600::18 If I don't know my address yet (say, for DAD in this example), ARP actually uses a second made up address "0.0.0.0" for the source IP which just means unspecified. In ND, I do the same to be able to DAD my link local address by saying I'm :: (also all 0s) but at least the destination is still not ff:ff:ff:ff:ff:ff. As a bonus, since ND only uses the link local address as the source for ND, DAD for the link local address is the only time the source address can be unknown. DAD for any number of unicast addresses will always have the link local to put as the source, even if they are not in the same subnet in the L2.