[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment
[ post by non-subscriber. with the massive amount of spam, it is easy to miss
and therefore delete posts by non-subscribers. if you wish to regularly
post from an address that is not subscribed to this mailing list, send a
message to <listname>-owner@ops.ietf.org and ask to have the alternate
address added to the list of addresses from which submissions are
automatically accepted. ]
You're assuming that roaming is done at L3. Roaming is normally
done at L2 so for example ISATAP is a relevant option.
/Karim
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
> Sent: den 24 juli 2003 14:35
> To: Pekka Savola
> Cc: v6ops@ops.ietf.org
> Subject: Re: 3gpp-analysis-04: Transition mechanisms at UEs;
> 3GPP IPv6
> deployment
>
>
> If UE that normally uses IPv6 roams to a provider that only supports
> IPv4, some kind of tunnel solution seems inevitable. ISATAP is
> certainly irrelevant, because the IPv4 provider won't provide
> ISATAP machinery by definition. So either the home provider will
> have to offer a tunnel broker or a 6to4 relay for use by its
> subscribers when they roam on IPv4. I don't think the IETF
> should worry about whether the UE has enough real estate for
> this option; that's a vendor choice.
>
> I suspect the UE will have less overhead to support 6to4 than
> to support a tunnel broker protocol.
>
> Brian--
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter
> Distinguished Engineer, Internet Standards & Technology, IBM
>
> NOTE: My email will soon change to brc@zurich.ibm.com
> Try that if you get failure messages.
>
> Pekka Savola wrote:
> >
> > Hi,
> >
> > This is a slightly related point to "The use of 6to4" issue raised
> > yesterday.
> >
> > Section 3.1 goes and analyzes the case where the 3GPP
> network does not
> > provide IPv6 support at great length.
> >
> > I strongly believe that:
> >
> > 1) we *MUST NOT* require or recommend the implementation
> of any automatic
> > tunneling methods such as 6to4 or ISATAP on 3GPP UE's. We
> SHOULD NOT
> > require or recommend the implement configured tunneling on
> UE's (but I can
> > be convinced otherwise).
> >
> > 2) The use of ISATAP is misguided in this space: it's
> only useful if the
> > 3GPP operator supports IPv6 (i.e. provides the ISATAP
> routers and other
> > infrastructure) but doesn't just have IPv6 SGSN's, GGSN's,
> etc. This
> > seems in direct conflict with 3GPP goals.
> >
> > 3) we should be able to assume that unless the 3GPP
> operator where the
> > user buys his service doesn't support IPv6, the user
> cannot use IPv6 on
> > his gadget. On the other hand, if the particular GGSN the user is
> > connected using IPv4 supports only IPv4, there is nothing
> stopping the
> > user from using some other GGSN for IPv6 support. That
> is, as long as the
> > 3GPP operator has basically one IPv6-aware GGSN, SGSN and
> HLR, IPv6 users
> > are happy.
> >
> > The reasons for these points are mainly:
> >
> > - The number of UE's is expected to be very high,
> > - The implementation footprint of UE's is expected to be
> very small, so
> > any extra code is difficult to justify,
> > - The upgradeability of UE's is poor, and we may not be
> able to retire
> > such mechanisms,
> > - We're concerned about 3GPP *deployment* not early
> trials or piloting
> > - There is a significant pressure for 3GPP operators to
> do IPv6 properly,
> > and we should rather work on getting on with *real* IPv6
> deployment than
> > fiddling around with transition mechanisms in this space.
> >
> > Of course, if the UE implements something like 6to4,
> there's nothing to
> > stop them. Just we shouldn't advocate that..
> >
> > This, I'd suggest major reworking of the parts of the section 3.1.
> >
> > ===8<====
> > 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes
> > [...]
> > However, the UE may attach to a 3GPP network, in which the SGSN
> > (Serving GPRS Support Node), the GGSN and the HLR
> (Home Location
> > Register) support IPv4 PDP contexts by default, but
> may not support
> > IPv6 PDP contexts. If the 3GPP network does not
> support IPv6 PDP
> > contexts, and an application on the UE needs to
> communicate with an
> > IPv6(-only) node, the UE may activate an IPv4 PDP context and
> > encapsulate IPv6 packets in IPv4 packets using a tunneling
> > mechanism. This might happen in very early phases of IPv6
> > deployment, or in IPv6 demonstrations and trials.
> >
> > The UE may be assigned a private or public IPv4
> address when the
> > IPv4 PDP context has been activated, although it is more likely
> > that it will receive a private address (due to the
> lack of public
> > IPv4 addresses). The use of private IPv4 addresses in the UE
> > depends on the support of these addresses by the tunneling
> > mechanism and the deployment scenario. In some cases,
> public IPv4
> > addresses are required (one example is 6to4
> [RFC3056]), but if the
> > tunnel endpoints are in the same private domain or the
> tunneling
> > mechanism works through IPv4 NAT (Network Address Translator),
> > private IPv4 addresses can be used (examples are [ISATAP] and
> > [TEREDO]). In general, if tunneling from the host is
> needed, ISATAP
> > and 6to4 are preferred and TEREDO is a mechanism of last resort
> > when neither of these are applicable.
> >
> > One deployment scenario example is using laptop
> computer and a UMTS
> > UE as a modem. IPv6 packets are encapsulated in IPv4
> packets in the
> > laptop computer and an IPv4 PDP context is activated. Although
> > "IPv6 in IPv4" tunneling can be either automatic or
> configured (by
> > the user), the first alternative is favored, because
> it is expected
> > that most UE users just want to use an application in their UE;
> > they might not even care, whether the network
> connection is IPv4 or
> > IPv6.
> > [...]
> >
> > 3.2.2 Tunneling outside the 3GPP Operator's Network
> > [...]
> > On the other hand, usage of dynamic tunneling, such as
> "6to4", can
> > also be considered, but scalability problems arise
> when thinking
> > about the great number of UEs in the 3GPP networks.
> The specific
> > limitation when applying "6to4" in 3GPP networks should also be
> > taken into account, as commented in 3.2.1. Other
> issues to keep in
> > mind with respect to the "6to4" mechanism are that
> reverse DNS is
> > not yet completely solved and there are some security
> > considerations associated with the use of "6to4" relay
> routers (see
> > [6to4SEC]). Moreover, in a later phase of the
> transition period,
> > there will be a need for assigning new, native IPv6
> addresses to
> > all "6to4" nodes in order to enable native IPv6 connectivity.
> >
> > --
> > Pekka Savola "You each name yourselves
> king, yet the
> > Netcore Oy kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A
> Clash of Kings
>