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?
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?
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
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.
Wait I don't get this.
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?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?
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
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.