When tunnels are well-scoped and rather static, or accompanied with
tightly coupled control planes which can include their own control-level
loop prevention during setup, tunnel loops on data packets are less
likely - which is probably why you do not see much extra effort at an
optimized check for them on the data path. Loops are more likely when
tunnels encapsulations are used liberally, automatically, and allowed to
operate in a multihop fashion. The future may be different, but at the
moment I believe we see less of this kind of situation in practice.
- Mark
Chan-Wah Ng wrote:
Hello Pekka,
Thank you for the response.
On Tue, 2008-10-28 at 08:07 +0200, Pekka Savola wrote:
On Tue, 28 Oct 2008, Chan-Wah Ng wrote:
We have written a draft on the formation of tunnel loops, and possible
approaches on loop detection.
As it is a general problem for tunneling protocols, the draft was
written for intarea. However, there has been recent discussions on the
Mobility Extension WG on the HA loop threat, and even more recently in
3GPP CT1. Hence, this announcement is cross-posted to Mext as well.
We would like to solicit for comments on the draft, and suggestions on
possible way forward.
As you point out, IPv6 tunnel spec already has tunnel encapsulation
limit, which you point out, could be even better. But my concern is
how much this is a problem in practise. Among those IPv6 tunnel
implementations I've looked at, none of them implemented tunnel
encapsulation limit. I wonder -- if they didn't bother to implement
that, what would make them to bother implement this?
AFAIK, Linux has always implemented the TEL option
in /net/ipv6/ip6_tunnel.c since the early 2.6.0 days.
In any case, a lack of implementation should not be used as an argument
against a possible fix to the problem -- especially if it is IPv6 we are
talking about (which is still far from being as pervasive as it should
be).
As to whether there is a practical need to fix this problem, it is up to
the IETF community to decide. The information I can provide to help make
that decision is both Mext WG and 3GPP CT1 has acknowledged it as a
problem.
/rgds
/cwng
It appears there was a -00 I-D in IPng WG in 2002, which the probable
intent of getting the IPv6 tunnel spec to draft standard, but the work
dried up.
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
