[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Revised drafts -- Arch, AH, ESP

I am replying to Harold, as he is otherwise an intelligent and
thoughtful person who actually writes code, instead of merely
speculating about it.  Unfortunately, he has been confused by errors in
recent RFCs.

> From: "C. Harald Koch" <chk@utcc.utoronto.ca>
> TTL decrement is done when a packet arrives on an interface *and* leaves via
> an interface (possibly the same one). This includes a packet that arrives on
> an interface and then enters a tunnel, and a packet that is decapsulated and
> then re-encapsulated.  It does *not* include a packet locally originated or,
> for that matter, a packet that arrives destined to the local host.
>
> RFC 1853 is incorrect in this regard.

I firmly disagree with the last two sentences.  The issue is that any
node that performs "tunnelling" is a router, and must conform to routing
requirements.

When a locally originated packet is forwarded directly to the final
destination over a single interface, we consider that a "host"
operation, and do not expect the node to follow routing requirements.

When a locally originated packet is forwarded indirectly to the final
destination over a tunnel interface that is then re-forwarded (via
another interface) over intermediate nodes, that is an act of routing.
Thus, the node is acting as a "router".

This fact was ignored by the Mobile-IP revisionists, and also by the
IPv6 Neighbor Discovery revisionists.  It's just too bad that we get
proposed standards that do not conform to full standards, but that's
what happens when volunteers come along that have not considered nor
understood what has gone before.

As many of you know, I was involved in the original design and
implementation of IPv6 Neighbor Discovery, IP Mobility, and IP Security.
Most of the RFC text in all three fields was written by me, but recent
editors have mangled them.

In Mobile-IP, they went to great lengths to say that a Home Agent that
intercepted packets by proxy arp and then forwarded them down a tunnel
was not acting as a router, and that a Mobile Node that had a
"co-located" Foreign Agent was not acting as a router.  This is simply
egregious doublespeak.  Every node is either acting as a host or a
router, and there are no "other" kinds of nodes.

There were two principles of Neighbor Discovery that I stated in an
interim meeting would be removed over my dead body: integrated mobility
and security.  Both were removed without any public WG discussion by
secret fiat of the chairs, by secretly assigning the documents to
revisionists without telling me for over 2 months.

I have not read the final version(s) of Neighbor Discovery.  At the
outset, the revisionist had so little understanding of the basic design
principles that as many as 6 messages were being bounced around (where
ARP sufficed with only 2), there was no provision for security on the
local link during discovery, and all the router self-configuration
techniques had been stripped.

Anyway, one of the important integral design considerations of both
Neighbor Discovery and Mobility was that discovery packets that traverse
a tunnel should not exit onto a remote LAN.  However, in a conservative
design, a packet destined for the Home Agent through a Foreign Agent
tunnel should behave in exactly the same fashion as packet that was
locally generated and inserted into a local tunnel.

During Neighbor Discovery, the host sends a TTL of 1.  The Foreign Agent
will receive the datagram, and decrement the TTL as it inserts into the
tunnel (the outer TTL is set to the configurable IANA value of 64).
Likewise, a locally generated tunnel must decrement TTL to 0 when
inserting into the tunnel.  When it arrives at the Home Agent, the Home
Agent does not examine the TTL and does not drop the datagram when it is
destined for itself, but is prevented from forwarding.

To accomplish this symmetric behaviour, the inner TTL is decremented
before encapsulation.  This principle depended upon the requirement in
RFC-1122:

         3.2.1.7  Time-to-Live: RFC-791 Section 3.2

            A host MUST NOT send a datagram with a Time-to-Live (TTL)
            value of zero.

            A host MUST NOT discard a datagram just because it was
            received with TTL less than 2.

This is also described in RFC-1812:

    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 originate or forward a datagram with a Time-to-Live
       (TTL) value of zero.

       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.

Note that RFC-2002 does not conform to either host or router requirements:

>    If, after decapsulation, the inner datagram has TTL = 0, the
>    decapsulator MUST discard the datagram.

Furthermore, there is a happy by-product to my design that came out
during implementation.  Routing loops were more quickly eliminated.

Many systems cannot differentiate between a datagram that is locally
generated and one that has arrived and been decapsulated.  Early
implementations tried to check this by looking at the IP source to
decide whether it is local.  When the node is involved in a tunnel loop,
that node would keep inserting the datagram into the tunnel without
decrementing TTL.  This has an obvious flaw -- just think about it.

It all comes down to the old "be conservative in its sending behavior,
and liberal in its receiving behavior."  Sending a more conservative
TTL prevents currently known and future potential problems.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
Follow-Ups: