Subject: RE: draft-daniel-dhc-ipv6in4-opt-03.txt

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Fri, 11 Jun 2004 15:57:44 +0200

Pekka, 

You keep saying this...

In this particular context I would assume that Juha was explicitly
referring to 3GPP usage - Could you be so kind
as to back you statement up with some hard facts that explains why
Isatap deployment is so very problematic in 3GPP environments - ? 

While draft-daniel-dhc-ipv6in4-opt-03.txt seems to be 
everything we're looking for in DHCP environments and *could*
be used in the 3GPP environment also, it may not be the obvious choice
there as addresses are allocated by means of PDP context activation mechanisms
and not by means of DHCP.

BR, Karen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Pekka Savola
> Sent: Saturday, May 29, 2004 7:51 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: draft-daniel-dhc-ipv6in4-opt-03.txt
> 
> 
> On Thu, 27 May 2004 [email-masked] wrote:
> > There is also a simpler, usable mechanism if v6-in-v4 tunneling is
> > needed in a 3GPP UE: ISATAP. That does not require DHCP
> > implementation in the UE. See Dave's comments here:
> > http://ops.ietf.org/lists/v6ops/v6ops.2004/msg00814.html
> 
> While ISATAP may be slightly simpler from the server's implementation 
> point-of-view, it has problems of its own.
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of ext Grubmair Peter
> > Sent: 27 May, 2004 14:52
> > To: V6ops_Discussion (E-mail)
> > Subject: draft-daniel-dhc-ipv6in4-opt-03.txt
> > 
> > 
> > Dear Sirs, 
> > I highly appreciated finding your draft 
> > concerning "DHCP Option for Configuring IPv6-over-IPv4 Tunnels" 
> > at IETF. 
> > To my mind this is one of the simplest form of a first transition 
> > for mobile (GPRS) operators to supply IPv6 to 
> > their customers. 
> > After finding the tunnel endpoint via your DHCP option 
> > a dual stack mobile phone can do autoconfiguration (or DHCPv6) 
> > accros the tunnel and obtain a globally unique IPv6 address, 
> > allthough its IPv4 address is only private. 
> > (no DAD is needed as link-local address is constructed from 
> > IPv4 address, which is unique within operators area). 
> > tunnel establishment at operator side could be done with adhoc mode
> > as described in >>Simple IPv6-in-IPv4 Tunnel Establishment Procedure
> > (STEP)<<
> > (draft-savola-v6ops-conftun-setup-02.txt)
> > this could be the m
> > I hope that your suggestion evolves to an RFC soon. 
> > Best regards 
> >    Peter Grubmair 
> > 
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
>

---

From: Pekka Savola <[email-masked]>
Date: Mon, 14 Jun 2004 14:02:45 +0300 (EEST)

> Isatap deployment is so very problematic in 3GPP environments - ? 

I've tried to explain these multiple times without all that much
success.  I think the worst problem is that everyone in the 3GPP
operator's network would be considered "on-link" with yourself is the
biggest problem.  I.e., direct tunneling between the 3GPP nodes.

The analogy of this approach would be connecting all the 3GPP users in
the operator's network in a single Ethernet LAN segment, and expecting
them to behave themselves with regard to each other (in particular,
note that Neighbor Discovery and many, many other protocols consider
such an environment "semi-trusted", e.g., by the use of link-local
messages and verifying that Hop Limit stays at 255).  This approach
gives me creeps.  Hence, I'd strongly prefer approaches where there
would be sufficient "insulation" from everyone else, e.g., by the use
of configured, bidirectional tunnels.

> While draft-daniel-dhc-ipv6in4-opt-03.txt seems to be everything
> we're looking for in DHCP environments and *could* be used in the
> 3GPP environment also, it may not be the obvious choice there as
> addresses are allocated by means of PDP context activation
> mechanisms and not by means of DHCP.

Yes, I don't think draft-daniel-dhc-ipv6in4-opt-03.txt is optimal in
3GPP.  You could do the discovery using DNS or a number of other
means.  Configuring the tunnel endpoint at the server's end is a
challenge not addressed in dhc-ipv6in4-opt either.  There are number
of possibilities to do that, though -- one is a pseudo-interface like
ISATAP's, the other is creating tunnels dynamically based on the
packets you receive, the one another looking up auth/identification
data from (3GPP or other) databases.