> ... there is also a negative impact to the reference implementation of ntpd, which uses 127.x.y.0 to communicate with drivers ... 127.127.x.y, for what it's

> ... there is also a negative impact to the reference implementation of ntpd, which uses 127.x.y.0 to communicate with drivers ... 127.127.x.y, for what it's worth (cf. any of the individual "Type n" reference clock drivers' documentation pages linked from [0]). > ... but we believe that it's easy to change this in ntpd since other implementations don't use the same mechanism How easy do you believe it is to change (update) all of the dozens or possibly even hundreds of models of "embedded devices" (i.e., so-called "appliances" and such) built on or around ntpd that are deployed throughout the world but upgraded only rarely, if ever? (ntpd (i.e., the reference implementation) is slowly dying anyways, but that's beside the point.) One of the few benefits I can see from this proposal is that someone -- or a handful of someones, perhaps -- will make a nice sum of cash when they sell their future allocations (from 127/8) to AWS. With my network engineer hat on, I'd also be against this proposal and would rather see the resources spent migrating to IPv6 instead. --- [0]: https://doc.ntp.org/archives/4.2.8-series/refclock/ https://doc.ntp.org/archives/4.2.8-series/refclock/