Tobias Fiebig <tobias=40fiebig...@dmarc.ietf.org> wrote: > 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
Our own project (IPv4 Unicast Extensions) has had much more success at convincing implementers to improve their IP implementations, than we have had at convincing IETF WGs to approve documents clarifying how to make those improvements fully compatible with each other and well documented for network administrators and application authors. Perhaps you will experience the same effect. I think the number of hosts and routers on the global Internet which have IPv6 enabled and IPv4 disabled can probably be counted on one person's fingers and toes; see: https://ungleich.ch/en-us/cms/blog/2019/02/05/list-of-ipv6-only-services/ https://sites.ip-update.net/ But I understand the desire to have IPv6 nodes and protocols not rely on IPv4, both to reduce technical complexity and for political reasons. I think that it would be useful to get v6 implementations like Linux to ask and answer using NDP for IPv4-mapped or IPv4-compatible IPv6 addresses, when no IPv4 stack is configured in that implementation. Probably no sysctl would even be needed. Indeed, the Linux kernel should correctly *answer* any incoming IPv6 NDP queries about such addresses, even if an IPv4 stack IS configured in its kernel. Patches needed to do that, if it doesn't already work, would probably be accepted by the maintainers. Especially if you provided a patch to the kernel networking test-cases, which demonstrates the failure, and also demonstrates that your patch eliminates the failure. John Gilmore _______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
