If I understand correctly, traditional IPv6 flow is:
* A host configures its own IP address via SLAAC
* The host sends a packet to its gateway with some destination address
* The gateway forwards the packet to the Internet
* Eventually, a response packet arrives to the gateway
* At this point, the gateway does neighbour discovery to try to figure out how to send the packet to the host
* The gateway might drop the packet or delay forwarding it until neighbour discovery completes
Why couldn't we change the flow to:
* A host configures its own IP address via SLAAC
* The host sends a packet to its gateway with some destination address
* The gateway forward the packet, and at the same time starts neighbour discovery because almost all computers which send outgoing packets will eventually receive some incoming packet
* When the response packet arrives, neighbour discovery is likely already done, or if not it got a good head start
Isn't this the obvious solution which wouldn't require changes to hosts or new protocols, just a small tweak to the router? Usually, when there's a seemingly obvious simple solution to a real problem and that solution hasn't been implemented by any of the clever people working in networking standards, there's a good reason and the solution isn't as simple as it seems. So what am I missing?
Apparently it's not good to require the router to start a new multicast address resolution on seeing unknown sources. It could be spelled out more but the text "This is particularly relevant for anycast and proxy addresses, where more than one node may be capable of responding" says that in some circumstances a lot of link local addresses might correspond to a single global address, and there could be a lot of traffic generated. So it's better to have the host opt-in to the prepopulating of the STALE entries.
"STALE allows the router to use the information it has already learned without requiring a new multicast address-resolution operation. The router can subsequently verify reachability using the normal Neighbour Discovery mechanisms."
My assumption is this isn't the way it works because it would be doing work up front, when it's not clear that the return will be necessary at all (think UDP). The response could be some time in the distant future or never, keeping the mapping in memory could be a problem (IPv6 design is 30 years old... and fast memory was even more expensive back then).
Even weirder: when the router forwards the packet from the host to the Internet, it already sees both the source IPv6 and MAC address, so it could store them.
Maybe there are some weird situations where a host that just got its own IP address starts proxying for a third node that wants return packets to asymmetrically bypass the host?
This is what I don't understand. I'll be the first to stand up and say there's a lot about IPv6 I don't know, but why can't/doesn't the router learn how to talk to the host when the host sends that outbound packet?
I'm guessing it's one of those completely over-engineered bits about IPv6 that is that way just because they wanted to engineer in so much complexity almost for the sake of it
Im mildly confused as well, there is an even more immediate shortcut that I've certainly implemented before. in arp its not unusual to to just create a ip->mac binding from the source information in the ethernet header. where this potentially breaks down if we start looking at issues of trust. but its already the case in ND that we trust the endpoint to have executed the state machine to search for duplicates. so what's preventing us from doing the same thing here? maybe just layering concerns?
This was my immediate thought as well. Though I have not thought through any of the details, it did occur to me that the information needed would be in the "source" section of the header. I wonder if it is too much work to validate it somehow before using it?
I haven't ever done any programming at this layer of the stack, so I'm purely spitballing.
I’ve always thought that IPv6 has dramatically worse layering than IPv4. In IPv4 over Ethernet, there’s ARP, which layers over plain Ethernet, and IPv4 sits on top of the combination of ARP+Ethernet.
In the IPv6 world, neighbor discovery is IPv6, but only sort of, because the participants don’t necessarily have real addresses. So it’s a mess.
IPv6 link local layers over Ethernet the same way Arp does. Both contain a source/dest MAC which is used for forwarding, both contain the relevant neighbor info. If anything, keeping the protocol's self-discovery messages wrapped in the protocol itself is actually cleaner layering at the cost of complexity (the extra link local signalling addresses).
It really is not. There's a whole morass with possibly overlapping "on link" networks that nobody can implement correctly on the first try.
Then there's this whole pretend "it's not broadcast but multicast" song-and-dance with ND in IPv6. In IPv4/ARP the separation is clean, and no lower protocol details leak into the IP layer.
Link-local addresses were also meant to be used for LAN-only apps. Except that it quickly turned out that you can't actually use them reliably because some interfaces (like PPP tunnels) do not _have_ MACs.
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.
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!
Technically, there's no broadcast in IPv6, so the host is supposed to join the local multicast group and do the neighbor discovery flow to find the "on link" address. And it's not guaranteed that the network is "symmetric".
Technically, this is also true for IPv4. You can have a proxy-ARP host impersonating the sender, but since it had never been fully specced, nobody cares about this scenario.
Wild guess: packet forward is implemented in hardware while arp/nd is software, with probably some things (think "hardware interrupt" or something alike) that allows hardware to "call" the software stack (for instance, when the link-layer addr is unknown)
So, to implement what you said, we need more than a simple router upgrade: we'd need to change the hardware, so that when a packet is forwarded from a source that's not in the mac table, the software can (asynchronously) perform an arp/nd lookup
There is probably a world of issue behind that behavior, but I do not know
Great guess, not sure why it's at the bottom of the responses so far :).
You can either have the hardware do additional lookups for every packet it processes or you can just follow the normal process for the very first packet from that IP. Or, exactly what this article is about for the best of both worlds.
Advanced ASICs usually go down a different path of offering the ability to validate the ND process (to prevent spoofing) rather than doing even more to trust whatever is sent. This is compatible with the way GRAND works, making it a win-win-win approach.
Started reading,
the text is dreadfully lengthy, hard to stay concentrate on due to all the filler and mindlessly arranged words that obscure the actual content,
notice AI tell signs.
Stop reading,
paste into Pangram,
mostly AI,
scroll down on the text,
find this:
> Note: The author used AI tools to assist with drafting and language. The technical work, analysis and conclusions are the author’s own. For more information about our policy on AI-generated content, see our Contributing to RIPE Labs page.
Do better RIPE. I assumed RIPE had some standard. If you decide to not have any standards, at the very least put the AI disclaimer at the top so I don't waste my time on slop. It's disrespectful.
Does anyone have an article about NDP and GRAND that is not slop and worth sharing and reading?
If I understand correctly, traditional IPv6 flow is:
Why couldn't we change the flow to: Isn't this the obvious solution which wouldn't require changes to hosts or new protocols, just a small tweak to the router? Usually, when there's a seemingly obvious simple solution to a real problem and that solution hasn't been implemented by any of the clever people working in networking standards, there's a good reason and the solution isn't as simple as it seems. So what am I missing?"STALE allows the router to use the information it has already learned without requiring a new multicast address-resolution operation. The router can subsequently verify reachability using the normal Neighbour Discovery mechanisms."
Maybe there are some weird situations where a host that just got its own IP address starts proxying for a third node that wants return packets to asymmetrically bypass the host?
I'm guessing it's one of those completely over-engineered bits about IPv6 that is that way just because they wanted to engineer in so much complexity almost for the sake of it
I haven't ever done any programming at this layer of the stack, so I'm purely spitballing.
In the IPv6 world, neighbor discovery is IPv6, but only sort of, because the participants don’t necessarily have real addresses. So it’s a mess.
Then there's this whole pretend "it's not broadcast but multicast" song-and-dance with ND in IPv6. In IPv4/ARP the separation is clean, and no lower protocol details leak into the IP layer.
Link-local addresses were also meant to be used for LAN-only apps. Except that it quickly turned out that you can't actually use them reliably because some interfaces (like PPP tunnels) do not _have_ MACs.
It's a mess.
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!
Technically, there's no broadcast in IPv6, so the host is supposed to join the local multicast group and do the neighbor discovery flow to find the "on link" address. And it's not guaranteed that the network is "symmetric".
Technically, this is also true for IPv4. You can have a proxy-ARP host impersonating the sender, but since it had never been fully specced, nobody cares about this scenario.
So, to implement what you said, we need more than a simple router upgrade: we'd need to change the hardware, so that when a packet is forwarded from a source that's not in the mac table, the software can (asynchronously) perform an arp/nd lookup
There is probably a world of issue behind that behavior, but I do not know
You can either have the hardware do additional lookups for every packet it processes or you can just follow the normal process for the very first packet from that IP. Or, exactly what this article is about for the best of both worlds.
Advanced ASICs usually go down a different path of offering the ability to validate the ND process (to prevent spoofing) rather than doing even more to trust whatever is sent. This is compatible with the way GRAND works, making it a win-win-win approach.
Started reading, the text is dreadfully lengthy, hard to stay concentrate on due to all the filler and mindlessly arranged words that obscure the actual content, notice AI tell signs.
Stop reading, paste into Pangram, mostly AI,
scroll down on the text, find this:
> Note: The author used AI tools to assist with drafting and language. The technical work, analysis and conclusions are the author’s own. For more information about our policy on AI-generated content, see our Contributing to RIPE Labs page.
Do better RIPE. I assumed RIPE had some standard. If you decide to not have any standards, at the very least put the AI disclaimer at the top so I don't waste my time on slop. It's disrespectful.
Does anyone have an article about NDP and GRAND that is not slop and worth sharing and reading?