Subject: RE: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis- 0 9 .txt] ]

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Thu, 1 Apr 2004 12:59:07 +0200

-----Original Message-----
From: Fred Templin [mailto:[email-masked]]
Sent: 31. marts 2004 16:48
To: Karen E. Nielsen (AH/TED); 'Fred Templin'
Cc: 'Pekka Savola'; IPv6 Operations; 'JORDI PALET MARTINEZ'
Subject: RE: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-0 9 .txt] ]

Karen,
 
OK, if you must know it then I believe it is possible to run both 6to4 and
ISATAP from a single interface. Let's say a node wants to send a packet
to a 6to4 destination with prefix 2002:C001:0203::/48, i.e., a node that
is reached via a 6to4 router with unicast IP address 192.1.2.3 (neglecting
for the moment that 192.1.2.3 is non-global and used only as example).
If the node has, e.g., a route in its routing table such as:
 
   2002:C001:0203::/48 -> fe80::0200:5EFE:C001:0203 (via isatap0)
 
then the packet will go out the isatap0 interface using ISATAP encapsulation
based on the link-local ISATAP address from the routing table as the next-hop
toward the 6to4 router, and the 6to4 router will be unable to tell whether the
encapsulator used 6to4 or ISATAP.
 
In other words, if we view each 6to4 router as also an ISATAP router with a
link-local address on the "site" that includes the global IPv4 Internet, then it
really makes no difference whether we use a 6to4 interface or an ISATAP
interface for sending the packet.
 
In terms of receiving packets, if we view every global IPv4 address as a
"Potential Router", then the ISATAP decapsulation checks amount to
exactly the same (optional) checks suggested for 6to4 and, again, either
interface could be used to receive the packet with no differences.
 
This however takes us away from the simple and "secure" host-to-router usage of Isatap
in which IPv6 ingress filtering is achieved from networks where Ipv4 spoofing is prevented (of
which 3G is a prime example).
 
The fact that Isatap in host-router usage scenarios doesn't have the "relay-spoofing"/Ipv6 ingress filtering problems that 6to4 has, is one of the beauties of this simplitic usage
of Isatap and is in my opinion a strenght that should not be weakened.
 
I think that I would rather see good mechs with a set of, perhaps rigid, rules for how 
the various mechsnism should interact, than lowering the mechs to the lowest denominator in order
to make them all interact - but yes I also understand why this standpoint is arguable.
 
BR, Karen

---

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Mon, 5 Apr 2004 15:42:21 +0200

> > >Making it possible to send TTL=255 + LL packets from 
 > everywhere in the 
 > > >Internet breaks this assumption.
 > > 
 > > Well, we have made specific mention this assumption in 
 > past versions of
 > > the draft, e.g, see Security considerations in:
 > >   
 > > 
 > http://www.join.uni-muenster.de/Dokumente/drafts/draft-ietf-n
 > gtrans-isatap-03.txt
 > 
 > Too bad this was removed and apparently forgotten by many WG 
 > participatents :-(

Don't think it was forgotten. At least our implementation does
the checks. The IPv4 spoofing protection on edge routers is a valid
assumption and should be mandated anyway. But I agree that the
current spec could do with several changes like this one. I am trying
to put together a list of things which I would like to see in a new
version of the ISATAP spec.

/Karim