-/* We support a variety of methods: userv-ipif, ipif on its own (when
- we run as root), SLIP to a pty, an external netlink daemon. There
- is a performance/security tradeoff. */
-
-/* When dealing with SLIP (to a pty, or ipif) we have separate rx, tx
- and client buffers. When receiving we may read() any amount, not
- just whole packets. When transmitting we need to bytestuff anyway,
- and may be part-way through receiving. */
-
-/* Each netlink device is actually a router, with its own IP
- address. We should eventually do things like decreasing the TTL and
- recalculating the header checksum, generating ICMP, responding to
- pings, etc. but for now we can get away without them. We should
- implement this stuff no matter how we get the packets to/from the
- kernel. */
-
-/* This is where we have the anti-spoofing paranoia - before sending a
- packet to the kernel we check that the tunnel it came over could
- reasonably have produced it. */
-
-#include <stdio.h>
-#include <string.h>
-#include <unistd.h>
-#include <fcntl.h>
+/* See RFCs 791, 792, 1123 and 1812 */
+
+/* The netlink device is actually a router. Tunnels are unnumbered
+ point-to-point lines (RFC1812 section 2.2.7); the router has a
+ single address (the 'router-id'). */
+
+/* This is where we currently have the anti-spoofing paranoia - before
+ sending a packet to the kernel we check that the tunnel it came
+ over could reasonably have produced it. */
+
+
+/* Points to note from RFC1812 (which may require changes in this
+ file):
+
+3.3.4 Maximum Transmission Unit - MTU
+
+ The MTU of each logical interface MUST be configurable within the
+ range of legal MTUs for the interface.
+
+ Many Link Layer protocols define a maximum frame size that may be
+ sent. In such cases, a router MUST NOT allow an MTU to be set which
+ would allow sending of frames larger than those allowed by the Link
+ Layer protocol. However, a router SHOULD be willing to receive a
+ packet as large as the maximum frame size even if that is larger than
+ the MTU.
+
+4.2.1 A router SHOULD count datagrams discarded.
+
+4.2.2.1 Source route options - we probably should implement processing
+of source routes, even though mostly the security policy will prevent
+their use.
+
+5.3.13.4 Source Route Options
+
+ A router MUST implement support for source route options in forwarded
+ packets. A router MAY implement a configuration option that, when
+ enabled, causes all source-routed packets to be discarded. However,
+ such an option MUST NOT be enabled by default.
+
+5.3.13.5 Record Route Option
+
+ Routers MUST support the Record Route option in forwarded packets.
+
+ A router MAY provide a configuration option that, if enabled, will
+ cause the router to ignore (i.e., pass through unchanged) Record
+ Route options in forwarded packets. If provided, such an option MUST
+ default to enabling the record-route. This option should not affect
+ the processing of Record Route options in datagrams received by the
+ router itself (in particular, Record Route options in ICMP echo
+ requests will still be processed according to Section [4.3.3.6]).
+
+5.3.13.6 Timestamp Option
+
+ Routers MUST support the timestamp option in forwarded packets. A
+ timestamp value MUST follow the rules given [INTRO:2].
+
+ If the flags field = 3 (timestamp and prespecified address), the
+ router MUST add its timestamp if the next prespecified address
+ matches any of the router's IP addresses. It is not necessary that
+ the prespecified address be either the address of the interface on
+ which the packet arrived or the address of the interface over which
+ it will be sent.
+
+
+4.2.2.7 Fragmentation: RFC 791 Section 3.2
+
+ Fragmentation, as described in [INTERNET:1], MUST be supported by a
+ router.
+
+4.2.2.8 Reassembly: RFC 791 Section 3.2
+
+ As specified in the corresponding section of [INTRO:2], a router MUST
+ support reassembly of datagrams that it delivers to itself.
+
+4.2.2.9 Time to Live: RFC 791 Section 3.2
+
+ Note in particular that a router MUST NOT check the TTL of a packet
+ except when forwarding it.
+
+ A router MUST NOT discard a datagram just because it was received
+ with TTL equal to zero or one; if it is to the router and otherwise
+ valid, the router MUST attempt to receive it.
+
+ On messages the router originates, the IP layer MUST provide a means
+ for the transport layer to set the TTL field of every datagram that
+ is sent. When a fixed TTL value is used, it MUST be configurable.
+