Fred I believe Pekka is comming from the linux implementation point of view which has only one pseudo-interface (sit0) to act as tunnel endpoint (at least that's what I see on my linux box). This is really the problem that leads to not being able to distinguish between tunneling mechanisms.
-vlad "Fred L. Templin" wrote: > > Pekka, > > Let me respond to the below from the perspective of ISATAP and 6to4 > tunnel mechanisms at work in the same machine. For example, let us > suppose that a 6to4 router is also acting as an ISATAP router. In this > case, there will be (at least) *two* distinct tunnel pseudo-interfaces; > one for 6to4 and one for ISATAP. These pseudo-interfaces *may* bind to > the same physical link, but they need not do so and (in practice) often > will not. > > In any case, however, the tunnel pseudo-interfaces are uniquely identified > by the IPv4 address assigned to each. As long as different IPv4 addresses > are assigned to the different tunnel pseudo-interfaces (a configuration > requirement for FreeBSD and Linux, at least), there will never be a case > of ambiguity such as the one you describe below. Note that if a single > physical link were used, this would mean assigning two or more IPv4 > addresses to the same link. But, all OS's I work with support this. > > Am I belaboring an already obvious point? > > Fred > [EMAIL PROTECTED] > > Pekka Savola wrote: > > > > First, let me point out a property of overloading protocol 41, from my > > draft: > > > > --8<-- > > There is a problem with multiple transition mechanisms if security is > > implemented. This may vary a bit from implementation to > > implementation. > > > > Consider three mechanisms using automatic tunneling: 6to4, ISATAP > > [ISATAP] and Automatic Tunneling using Compatible Addresses [MECH]. > > > > All of these use IP-IP (protocol 41) [IPIP] IPv4 encapsulation with, > > more or less, a pseudo-interface. > > > > When a router, which has any two of these enabled, receives an IPv4 > > encapsulated IPv6 packet: > > > > src_v4 = 10.0.0.1 > > dst_v4 = 20.20.20.20 > > src = 3ffe:ffff::1 > > dst = 2002:1010:1010::2 > > > > what can it do? How should it decide which transitionary mechanism > > this belongs to; there is no "transitionary mechanism number" in IPv6 > > or IPv4 header to signify this. > > > > Without any kind of security checks (in any of implemented methods) > > these often just "work" as the mechanisms aren't differentiated but > > handled in "one big lump". > > > > Configured tunneling [MECH] does not suffer from this as it is point- > > to-point, and based on src/dst pairs of both IPv4 and IPv6 addresses > > it can be deduced which logical tunnel interface is in the question. > > > > Solutions for this include not using more than one automatic > > tunneling mechanisms in the same system or binding different > > mechanisms to different IPv4 addresses. > > --8<-- > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
