[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. ]
Hi
Some comments on the tunnelling issues below.
> 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).
We are not mandating tunnelling for generic cases. However we
analysed each scenario and where it made sense we recommended
certain mechanisms such as tunnelling. Tunnelling is not a generic
solution for all our problems and we are not claiming that.
> 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.
It is not in conflict with any 3GPP goals. Note that the 3GPP operator
requires IPv6 for SIP-based IMS but this doc also covers generic access
(which is where we talk about tunnelling). On the contrary it helps
operators to start rolling out IPv6 without having to upgrade everything
all at once. This is an important issue which we have addressed. Also,
when a user roams to a network that does not support IPv6, the use of
ISATAP can allow access to IPv6 app.s. It is obvious that in the long
run native IPv6 access is the way to go. If that helps we can make
this more explicit.
>
> 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 can't be done. The user doesn't choose GGSNs.
> That is,
> as long as the
> 3GPP operator has basically one IPv6-aware GGSN, SGSN and
> HLR, IPv6 users
> are happy.
That is not correct. If you happen to go to the wrong SGSN/GGSN
you just don't get IPv6 service, independently from the fact
that there may be another SGSN/GGSN somewhere else in the
network supporting IPv6.
>
> 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..
You have left out the issue that when we're introducing a new
technology nowadays we don't do it all at once but gradually.
That means we will have to deal with IPv6 capable mobiles
trying to use IPv6 app.s even in areas where IPv6 native
connectivity is not possible. If we don't consider this case
then we won't be providing a full set of answers to 3GPP.
/Karim