4 ms·

NO! Please do not distract people from converting to IPv6. We do use 127.#.x.x on both client and server-side for IP-ifying IIoT sensor and controllers for rev

• schoen 5y ago
  Hi Cetin, I also got your e-mail that you sent to me and my co-authors. People might be confused by the "ietf.org" in the URL, but this document is a draft, with the status of a proposal, not an IETF standard. Anyone can propose an Internet-Draft at IETF. Each of our drafts refers to "formerly reserved" address space because that will be the status of the address space if that draft is adopted. Hearing about existing uses of all of the categories of address space that we are proposing to unreserve is useful feedback to inform the conversation. For example, we are also proposing to unreserve 240/4. There are existing unofficial private uses of 240/4. We know a little bit about them, and we would love to know more about them. Unlike the prior attempts to unreserve 240/4 at IETF back in 2008, our drafts not only do not take a position on an allocation procedure or timeline, but are also silent on whether the proposed unreserved blocks should be used as public or private IPv4 address space. A possible outcome for 127/8 would be to formally designate it as a new kind of private address space (which is no longer assumed to have host scope). That outcome might be compatible with uses like yours and might even be useful because it would bring other devices' behavior more in line with your use (I don't know if that's the case offhand, because I don't know whether your setup sends packets with these addresses over the wire, or just inside of tunnels). When we propose a change like this, or when anyone proposes a change to protocols at IETF, we are asking for feedback and also for more information about existing use cases that are affected, positively or negatively, by the proposal. We might not abandon the proposal on the basis of negative impacts (for example, there is also a negative impact to the reference implementation of ntpd, which uses 127.x.y.0 to communicate with drivers, but we believe that it's easy to change this in ntpd since other implementations don't use the same mechanism), but we would at least consider modifying it, and information about specific impacts could also inform IETF's conversation about the proposal. We (and lots of other people) have also proposed OS changes in advance of standards changes, but there, too, we are mindful of not wanting to break existing uses, and there, too, knowing about existing uses is helpful. Overall, I think your claim that we "assume one can just take the space back" is too strong.
  • jlgaddis 5y ago
    > ... 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/