Currently odhpcd supports relay mode for ndp, offering the feature for proxying NS packets from external interface of the router to the internal interface, making outside ipv6 packets possible to be routed to internal hosts which has a global ipv6 address.
This works like a charm when a whole subnet has been delegated to the router by ISP router, but the ISP router did not have routing rules to route to subnet hosts, like this:
In this case, packets from PC A or from the internet could be routed, hopping on ISP router, then by proxyed NS and NA packets, being transmitted (not actually routed, right?) to router, and then to PC B and PC C. On the other hand, hopping on router, packets from internal subnet (PC B and PC C) could also be routed to PC A or to the internet.
However, my network use case is quite different from this scene, and thus reqires more features on odhcpd. Our school network does not even delegate 64-bit prefixes to our hosts, it delegates addresses using SLAAC in the 64-bit prefixed subnet. The network structure works like this:
So running a router to extend my local link actually forms a network in such a way that one same 64-bit prefixed subnet owns 2 separated links, my internal one that connects my devices with my router ,and the external one that connects my router with the school router. I do not have any control over the school router, so I can't change this.
Running odhcpd in relay mode does help a lot in this case, Let me analyze the situation
My internal link hosts could send packets to each other and to my router without any problem. (Of course)
AAAA::4, AAAA::5, AAAA:::3 could ping each other
My router could send packets to external link hosts through external interface without any problem (Of course)
AAAA::3, AAAA::2, AAAA::1 could ping each other
My internal link hosts takes my router as default routing target, and my router takes school router as default, so packets from interal link (PC B and C) to internet targets (eg. ipv6.google.com, targets outside the AAAA::/64 subnet) could be routed right.
NS packets from external link would be proxyed to the internal link by odhcpd, so packets routed from the internet through school router and packets from other external link hosts (PC A) could be successfully sent to my router and then routed to the correct target host.
AAAA::4 and ipv6.google.com could ping each other
But NS packets from internal link would not be proxyed to the external link, and default routing rules promoted to internal link hosts do not have a router for AAAA::/64 subnet, so packets from interal link hosts (PC B and C) to external link hosts (PC A) could not be tranmitted right.
ping from AAAA::4 to AAAA::2 yeild destination unreachable (icmp-echo-request packets could not be sent)
ping from `AAAA::2 to AAAA::4 could not receive response (icmp-echo-request packets are sent and received, but icmp-echo-reply could not be sent back)
So in this use case, the most elegant way working out of this would be providing odhcpd the feature to proxy ndp packets from interal interface back to external interface, that's why I'm here firing a feature request, would you consider about it?
Hi, there.
Currently
odhpcdsupportsrelaymode forndp, offering the feature for proxying NS packets from external interface of the router to the internal interface, making outside ipv6 packets possible to be routed to internal hosts which has a global ipv6 address.This works like a charm when a whole subnet has been delegated to the router by ISP router, but the ISP router did not have routing rules to route to subnet hosts, like this:
In this case, packets from PC A or from the internet could be routed, hopping on ISP router, then by proxyed NS and NA packets, being transmitted (not actually routed, right?) to router, and then to PC B and PC C. On the other hand, hopping on router, packets from internal subnet (PC B and PC C) could also be routed to PC A or to the internet.
However, my network use case is quite different from this scene, and thus reqires more features on
odhcpd. Our school network does not even delegate 64-bit prefixes to our hosts, it delegates addresses using SLAAC in the 64-bit prefixed subnet. The network structure works like this:So running a router to extend my local link actually forms a network in such a way that one same 64-bit prefixed subnet owns 2 separated links, my internal one that connects my devices with my router ,and the external one that connects my router with the school router. I do not have any control over the school router, so I can't change this.
Running
odhcpdin relay mode does help a lot in this case, Let me analyze the situationAAAA::4,AAAA::5,AAAA:::3could ping each otherAAAA::3,AAAA::2,AAAA::1could ping each otheripv6.google.com, targets outside theAAAA::/64subnet) could be routed right.odhcpd, so packets routed from the internet through school router and packets from other external link hosts (PC A) could be successfully sent to my router and then routed to the correct target host.AAAA::4andipv6.google.comcould ping each otherAAAA::/64subnet, so packets from interal link hosts (PC B and C) to external link hosts (PC A) could not be tranmitted right.AAAA::4toAAAA::2yeilddestination unreachable(icmp-echo-requestpackets could not be sent)`AAAA::2toAAAA::4could not receive response (icmp-echo-requestpackets are sent and received, buticmp-echo-replycould not be sent back)So in this use case, the most elegant way working out of this would be providing odhcpd the feature to proxy ndp packets from interal interface back to external interface, that's why I'm here firing a feature request, would you consider about it?
Cheers, Chaserhkj
Attachment:
my odhcpd configuration