[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Revised drafts -- Arch, AH, ESP
> I am replying to Harald, 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.
Actually, I think I understand the confusion now. Mobile-IP and VPNs have
completely different ideas about the definition and use of IP-in-IP tunnels.
I think of VPN-style tunnels as the logical equivalent of a Layer 2 Link
between two systems, and it should be treated as such. The TTL processing
requirements for feeding IP packets into Layer 2 interfaces are clearly
defined as in my previous message.
I have never seen an IP stack that couldn't tell the difference between a
locally-sourced packet and a packet that arrived on another interface;
specifically, all IP stacks that I've worked with have a BSD-style ipforward()
function that is the connection between input() and output(), and is the only
code that can spell "ttl".
Actually, implementations of IP-in-IP tunnelling that I've seen can't tell the
difference between a physical interface and a tunnelling interface, and so
wouldn't be able to change their TTL behaviour based on that difference!
Now, Mobile-IP is a strange beast, one that I have not studied. Of course,
I've also never *needed* Mobile-IP, despite using machines that regularly
change their IP address and/or move around in space-time. However, I bow to
wiser experts than I with regards to this issue, which was previously argued
(and settled) as a result of forwarding the IPsec documents to the IESG.
--
Harald Koch <chk@utcc.utoronto.ca>
References: