I reviewed this document as a part of IESG document approvals this week.
I have to say that I found it difficult to decide whether to recommend the approval of this or not. We are in a difficult position, out of addresses, having to deploy NAT444, having to choose between the bad and even worse alternatives. It is hard for me to evaluate whether the proposed allocation will reduce pain more than it will cause pain elsewhere. In other words, is this making the Internet work better.
But there is clearly consensus in the operator community that we need this. However, I have one concern. The document is quite silent on the impacts. And there are negative impacts. For instance, anything that today checks for RFC 1918 space is potentially going to get a wrong answer tomorrow unless the code is changed to support the new private address space. And I don't know what things might be impacted. It is certainly possible for hosts to attempt to discover their externally visible IP addresses, query their access router for its external address, employ address testing in their NAT traversal solution (most non-trivial applications have one), and so on.
I did a quick check with a few pieces of software and found out that in at least some fraction of them there seems to be code that is testing for this stuff. I looked at the Linux kernel source, Asterisk SIP server, Skype, and the Chromium browser. I looked for decimal 192 and 168 on the same line either in the source code or strings from binaries, and then looked at the found instances myself to understand what they might be about. Skype produced an inconclusive or negative answer, I did not find these patterns in the binary. Asterisk clearly had code for testing addressing, hard coded to the current RFC 1918 addresses. Chromium had strings for 10/8 and 192.168/16 but it was hard to tell what it is using them for. Linux kernel used these addresses in many places but as far as I could tell, none of them were about testing, so they might be fine.
So what breaks if a test goes wrong? The true answer is that I don't know. But it is certainly possible that an application ends up not working because it chose to use an address that is not globally visible, or that some delays are incurred when addresses are tested in suboptimal order. And so on. Draft-well has a companion document, draft-bdgks, which sort of mentions this issue but dismisses it as bad implementation assumptions. I do not believe that is an appropriate assessment in a world where RFC 1918 status has been stable for a long time, and per evidence above, software in general seems to hardcode these addresses. This is reality, we need to face it. Draft-bdgks makes a much better argument when it states that the allocation of the new address space does not really change the impacts in this respect if NAT444 is deployed anyway but just using some otherwise agreed or bogon address space. This is true, but I think the official approval of new space from the IETF and
ARIN will make this practice more widely known and used. It is our responsibility to deal with the impacts.
So here's what I would like to propose. The document goes forward but we make a much clearer statement with regards to the implications both for applications out there, as well as for subsequent IETF work:
- what types of impacts may be felt by the rest of the network (not the ISP that is deploying NAT444)
- what kinds of application practices may be affected
- what IETF specifications may need revision due to this (e.g., do we need to revise ICE etc)
(It would have been even better if we had access to research that has looked at the various impacts in a rigorous manner. E.g., what's the likelihood of ISP - subscriber address collision in the different parts of the current RFC 1918 space vs. what is the likelihood of application failures with the new space. Not sure if we have time for that research now unless it already exists.)
Jari
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf