On July 16-21, 2017, the IETF 99 conference will take place in Prague. What IETF is and how it works has been already explained by my colleague Ondřej Surý in Czech Cesta do hlubin IETF, Odkud pochází internetové standardy (aneb bylo jednou jedno RFC) or Vrána k vráně sedá aneb koťátka, dogy a nápoje v IETF. Ladislav Lhotka, in turn, described its unusual geeky atmosphere IETF: internet podle mručící většiny. So it is enough to mention that IETF is an organization that publishes Internet standards. Its goal is to create quality technical documentation that influences the development of the Internet and its applications.
The fruits of IETF’s work include, for example, standardization of the SMTP protocol for e-mail and the HTTPS, using which you are probably reading this article. However, the impact of IETF ideas on the world of computer networks is much broader. For example, users will unknowingly appreciate when their web browser correctly displays HTML pages where the author has forgotten to close a pair tag such as “<body>” using the tag “</body>”. Similarly, mail servers usually deliver e-mails even though the DNS information on the delivery server does not comply with the standard. This is possible thanks to the broad application of the Postel’s law, one of the basic principles of interpretation of Internet standards.
The law is named after Jon Postel (1943-1998) and appeared in the Internet Protocol standard in 1981 (that is the protocol that we all thoughtlessly abbreviate as IP today). The Postel’s law says: “an implementation should be conservative in its sending behavior, and liberal in its receiving behavior”.
In 1981, when the Internet was still in its infancy, the goal of the Poster’s law was to facilitate the interconnection of systems from different manufacturers by setting different criteria for sending and receiving of packets. When sending, the system should produce “conservatively” formatted packets, i.e. according to the standard. When receiving, on the other hand, the implementation should “go easy” on it and accept also packets that are not technically 100% correct, but their meaning is still clear.
This principle has been borrowed from the IP standard and widely applied to implementations of other protocols we encounter every day. An example of its application is the already mentioned display of an HTML page despite the missing “</ body>” tag (proof: see here).
It looks like a clear win for both the user and the Internet as a network of networks: everything works, they are happy. Or are they not?
The Postel’s law also has a downside, which is mainly encountered by developers who try to adhere to the commandments and be liberal when receiving. Difficulties arise from the fact that the law refers to “the meaning of the packet”, regardless of its formal conformity. This puts the developer in front of a difficult task of finding some meaning in a packet whose format is not described.
Let’s illustrate this on the DNS protocol: its standardized version allows the DNS server to send more information in one response:
A client’s query may look like this:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20394
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 6
;; QUESTION SECTION:
nic.cz. MX
A packet with the standard server’s response looks like this:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 111
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 6
;; QUESTION SECTION:
nic.cz. MX
;; ANSWER SECTION:
nic.cz. 1800 MX 10 mail.nic.cz.
nic.cz. 1800 MX 20 mx.nic.cz.
nic.cz. 1800 MX 30 bh.nic.cz.
;; ADDITIONAL SECTION:
bh.nic.cz. 1800 A 217.31.204.252
mail.nic.cz. 1800 A 217.31.204.67
mail.nic.cz. 1800 AAAA 2001:1488:800:400::400
mx.nic.cz. 1800 A 217.31.58.56
mx.nic.cz. 1800 AAAA 2001:1ab0:7e1e:c574:7a2b:cbff:fe33:7019
This is the standard: one query and one response with multiple items.
Now let’s imagine that the program receives a packet with a “query” field containing (at odds with the standard) two items:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2222
;; flags: rd ad; QUERY: 2, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
www.nic.cz. A
www.nic.cz. AAAA
What did the sender mean? Here the problems start, because two different developers can easily have a different interpretation of the rule “to be liberal when receiving”. The first developer would figure that the program should only respond to the first of the two queries because the standard does not say how it should respond to two queries at a time. The other developer, on the contrary, would think that although the standard does not prescribe the format of the response to two queries, the sender of the query probably wants to have information from all the queries in the “answer” field, so he would put the answers next to each other in one packet. Yet another developer would solve the problem by dividing the answers to each individual question into separate packets so that two packets would be sent in response to one query packet.
Which one is right? Actually nobody, because this behavior is not defined by the standard. The result is, of course, a mess, because the different implementations behave incompatibly.
The problem will escalate when the responsible workgroup will try to extend the original standard with support for “multiple queries at a time”, which has been meanwhile implemented differently by every developer. None of the implementations would give up its behavior, usually referring to the fact that “our users are dependent on the behavior of our implementation, and therefore we cannot change it”. So, eventually there will be either a standard nobody adheres to (because everybody sticks to their own inventions) or no standard at all, as it is impossible to reach even a rough consensus on its form.
This shows how the “liberal” part of the Postel’s law leads to the creation of mutually incompatible extensions, which make it more difficult to develop the protocol, and as a result, the Internet environment becomes rigid.
The rapid development of the Internet and online applications creates the need to adapt existing standards and come up with new ones. Therefore, the application of the Postel’s law to a specific problem is an issue that no IETF working group can avoid. It is always necessary to consider pros and cons: should be a certain property of the protocol firmly and strictly required, which may slow or disable its further development? Or should a certain part of the protocol deliberately remain unrestricted, open the door to Postel’s law and allow rapid development at the cost of incompatible extensions?
IETF currently has 126 working groups and their scope is very broad. The list and agenda of all working groups can be found here, where it is also possible to register in an e-mail conference of any working group and read not only about this year’s IETF discussions in Prague, but also about the future direction of work. The working groups are thus open to anyone who is familiar with the issue and is willing to dedicate their time to it.