RE: 3gpp-analysis-05: miscellaneous non-critical issues

[Soliman Hesham <H.Soliman@flarion.com>]

 > Do you have an alternate wording suggestion in mind which 
 > would keep the
 > essence of the original text (including "don't tunnel from 
 > UE")?  This
 > doesn't and is unacceptable to me..

=> I didn't ask to have "don't tunnel from the UE"
in the text. I was commenting on the new text.
I don't think the draft should include opinions on how 
easy it is to upgrade to V6 and whether that involves
SW or HW upgrades. It's not useful. 

My other comment is on the roaming case. Specific answer
below.

 > 
 > On Sun, 28 Sep 2003, Soliman Hesham wrote:
 > >  > *)
 > >  >     However, the UE may attach to a 3GPP network, in which 
 > >  > the Serving
 > >  >     GPRS Support Node (SGSN), the GGSN and the Home 
 > Location Register
 > >  >     (HLR) support IPv4 PDP contexts, 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. 
 > > 
 > > => Please remove this sentence. This is an opinion and does not
 > > apply to the roaming case where the home operator has deployed
 > > IPv6 but the visited operator didn't.
 > >
 > >   To 
 > >  > generally
 > >  >     solve this problem (IPv6 not available in the 3GPP 
 > network), this
 > >  >     document strongly recommends the 3GPP operators to 
 > deploy basic
 > >  >     IPv6 support in their GPRS networks, 
 > > 
 > > => This does not apply to the roaming case, so it doesn't solve
 > > the problem stated above.
 > 
 > These are two quotes are intentional.  IPv6 support will 
 > work when the
 > visited networks also have upgraded to this minimal IPv6 
 > support.  

=> (drifting from the original comment but I'll answer 
this as a side issue). Supporting PDP type V6 is not a 
minimal support because it implies that the network behind
the SGSN supports v6, i.e. GGSN, DNS ...etc.

   That's 
 > also expected to happen during the early phases of 
 > transition.  If the 
 > operator doesn't care about IPv6 users at all, the users can 
 > just stay out 
 > of those networks.

=> The point is: Your operator cares about v6 and wants 
to offer you the services that IPv6 enables while you're
roaming. It is not relevant how the visited operator feels
about v6. So to work around this, you need to use something
to enable you to tunnel to a router in the home network. 
IMO ISATAP fits nicely in this model. But the point is, 
requiring an operator to support v6 will not necessarily
eliminate tunneling when the UE roams to another network
(whose managers don't want to support v6 and will implement
v6ops recommendations). 


 > 
 > We discussed previously several other options, such as 
 > trying to open the
 > IPv6 PDP context to an operator (if there are many) which in 
 > fact supports
 > IPv6.  This would be useful in the case that 3G + IPv6 gains market
 > momentum as there are typically multiple networks in a 
 > region one could
 > roam to.  I'm not sure how many of those ended up in the document.
 > 
 > The bottom line is that as we deploy dual stack UE's, when IPv6 isn't
 > supported in the visited network, one can just use IPv4 if 
 > all the tricks
 > fail.  

=> So , "other tricks" do not include tunneling? Why not?

  No tunneling needed at the UE.  Further, tunneling at 
 > the UE is 
 > counter-productive, as it doesn't give the *visited networks* _any_ 
 > incentive to deploy IPv6 in the first price, which is the number one 
 > priority.

=> But in this case the visited network doesn't care about 
v6. I'm not sure how eliminating the use of V6 through 
a tunnel will give the visited network an incentive to
deploy v6.

Hesham