Moin, I just had a stupid idea in the context of v4-w-v6-nh: Why don't we just do NDP? The obvious answer is: Because NDP does not support IPv4.
The more complex one is: Well, actually... why not? RFC4291 gives us 'IPv4-ComIPv4-Compatible IPv6 Addresspatible IPv6 Address[es]' in Sec. 2.5.5.1 to " assist in the IPv6 transition." (I know I am stretching things here... but bear with me...) Technically, there is nothing that keeps a v6 only router doing v4-w-v6 nh (possibly with RFC8950 behind) from sending a neighbor solicitation for "who has ::192.0.2.12" when it wants to forward a packet with an IPv4 next-hop. Similarly little keeps the host who holds 192.0.2.12 (and not even necessarily with IPv6 GUA!) from actually replying to that request with the appropriate v6 LL address. Technically, the v6 only router needs the following routes set: ip -6 r a ::192.0.2.0/120 dev eth0 ip -4 r a 192.0.2.12 via inet6 ::192.0.2.12 The above v6 route could also be a /128; However, if one would want to explicitly implement this, that preflen stuff should likely just be abstracted away. Anyway; I initially thought that this could be tested by just running an NDP proxy on 192.0.2.12, instructing it to reply to neighbor solicitations for ::192.0.2.12. However, it seems like, at least on linux and openbsd, the neighbor table refuses to get a static proxy entry for ::192.0.2.12. I then resorted to a simple: ip a a ::192.0.2.12/128 dev eth0 on the 'v4 only' host to simulate this behavior. Lo and beholt: 20:35:08.513764 IP6 2001:db8::1 > ff02::1:ff01:93e0: ICMP6, neighbor solicitation, who has ::192.0.2.12, length 32 20:35:08.513813 IP6 ::192.0.2.12 > 2001:db8::1: ICMP6, neighbor advertisement, tgt is ::192.0.2.12, length 32 Forwarding also worked as expected; Shoving 192.0.2.0/24 into my IGP, another host in V4LESS AS was actually able to use this path and ping 192.0.2.12 via the internal v4v6nh/rfc8950 constructed path (without on-path IPv4, not even on loopback ;-)). Looking at the linux code in net/ipv6/ndisc.c it also does not look to (very oblivious when it comes to C) me like it would be a lot of effort to add the following behavior: - If $sysctl is enabled, instead of ARP, send an NDP neighbor solicitation if there is an interface route with a v4 compatible prefix covering the address - If an NDP neighbor solicitation is received for a v4 compatible address on an interface that has the corresponding v4 address configured, reply with a neighbor advertisement The use-case here is (as recently discussed) RFC8950 on an IXP, where an RFC8950 router learns v4 routes over an RFC8950 session from the RS which only have v4 next-hops. The biggest issue, of course, is that this would mean at least some patch/support on the v4-only (or at least: non RFC8950) neighbor. However, technically (and very much for IXes already doing extensive ARP and NDP sponging), this could _technically_ also be done by the IX. That way, at least inbound (from the v4 only / non RFC8950 host) would be possible. Thoughts on this? Would it make sense to write up a draft on it, or is the general feeling more like 'meh'? With best regards, Tobias P.S.: I am cross-posting this rather widely, as it technically affects several WGs, i.e., intarea (where it imho belongs), v6ops (for obvious reasons), and grow (given the IX usecase/implication which would technically be a related document, if this itself is worth a document) _______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
