Re: [v6ops] draft-chen-v6ops-ipv6-roaming (was: Checking an outcome on the list)

Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 12 November 2013 11:06 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBC311E812B for <v6ops@ietfa.amsl.com>; Tue, 12 Nov 2013 03:06:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.951
X-Spam-Level:
X-Spam-Status: No, score=-9.951 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oh-jPCsPQo-p for <v6ops@ietfa.amsl.com>; Tue, 12 Nov 2013 03:06:34 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF0111E80F5 for <v6ops@ietf.org>; Tue, 12 Nov 2013 03:06:27 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rACB6O6v003123; Tue, 12 Nov 2013 12:06:25 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D37FA205AF2; Tue, 12 Nov 2013 12:06:36 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C5F0F205AF1; Tue, 12 Nov 2013 12:06:36 +0100 (CET)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rACB6A2h000405; Tue, 12 Nov 2013 12:06:25 +0100
Message-ID: <52820BA2.8020001@gmail.com>
Date: Tue, 12 Nov 2013 12:06:10 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Hui Deng <denghui02@gmail.com>, "v6ops@ietf.org" <v6ops@ietf.org>
References: <0D5C911E-5EB3-4F1F-82B1-B2F486AE3E46@cisco.com> <527E1385.1020506@gmail.com> <CANF0JMCBHXDW0jtNufqAUwrUqrN5+nwqSXFe5q6SQr5+nySUDA@mail.gmail.com> <527FACE5.6040002@gmail.com> <CANF0JMAfPiz6nDRiR5W2NaUKSTYG9c48+xxJm=NSyEEy2CP33Q@mail.gmail.com> <5280F33F.4040605@gmail.com> <CANF0JMCBkVvzbWrp_aPik+BGyhexrZmPaEf=6wFSL0uR-gV3TA@mail.gmail.com>
In-Reply-To: <CANF0JMCBkVvzbWrp_aPik+BGyhexrZmPaEf=6wFSL0uR-gV3TA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [v6ops] draft-chen-v6ops-ipv6-roaming (was: Checking an outcome on the list)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2013 11:06:40 -0000

Hello Hui,

Le 12/11/2013 01:39, Hui Deng a écrit :
> Hi Alex, I may mis removed v6ops during my last reply, here I add
> again. I tried before, which does roam across couple of GGSNs area
> without broken.

In that experimentation, were the GGSNs belonging to the same operator,
or to different operators?

Did the terminal keep the same IPv6 address?

> I guess that your geting lost of the continuity might because that
> your mobile coverage is not very good,

Well, it is not that simple.  In one particular IPv4 trial the train
line is covered by several cellular networks, even when crossing
national border.


> after you drive into or train run into some no coverage area, then
> you need to reconnect with your data connection. this is quite usual
>  case in USA and EU, but not in Asia because of density living area.

I am not sure what you mean, but in EU many areas are well populated.

I have tried to roam with the IPv6 connection of a particular cellular
operator, by going from one country to another, and by switching on and
off the handset during travel: either imposed by flight procedures, or
because not enough battery.  In principle, the IPv6 roaming works fine
in several countries in the EU.

It all depends what we call 'roaming'.

What I have not tried is the following two scenarios:
- roam IPv6 from one country to the next, keeping same IPv6 operator,
   without switching off the handset.  Note whether or not the ongoing
   applications break at handover.  Maybe by car or by train.
- roam IPv6 from one IPv6 operator to another IPv6 operator, without
   switching off the handset.  Maybe not being mobile at all.

They can easily be tried.

Intuitively, I would say that applications get interrupted, because
there would be change in the IPv6 address allocated to the smartphone.

I may be wrong though.

Alex


> thanks for the discussion DENG Hui
>
>
> 2013/11/11 Alexandru Petrescu <alexandru.petrescu@gmail.com
> <mailto:alexandru.petrescu@gmail.com>>
>
> Hui,
>
> Thanks for the reply.
>
>
> Le 10/11/2013 23:25, Hui Deng a écrit :
>
> Alex, I guess that I am not clear in the last email. Home routed
>
> means that there is home GGSN (kind of anchor point),
>
>
> ok.
>
>
> wherever you go, the address is always the same if you keep visiting
> the internet, local/visiting SGSN will always tunnel your traffic
> back to the home GGSN,
>
>
> Ok, in principle, by specification.
>
>
> then your session won't break.
>
>
> But has one tried it in practice?
>
> I have tried it, and the sessions do seem to break when roaming:
> train and car roaming.
>
>
> In the case you turn off your mobile (such as flight to another
> country), after you landed, your phone will get IP address from your
> home GGSN as well, wherever you go in the visiting country, every
> SGSN in the visiting country will always tunnel your traffic back to
> your home GGSN, then your session won't break as well.
>
>
> I may agree that the network will tunnel back traffic to home
> operator.
>
> And I agree that in the plane roaming case, after switching the
> smartphone on/off/on, a new address will be acquired and thus
> sessions would break.
>
> On another hand, in the train or car roaming case, when the
> smartphone is _not_ turned off, the sessions still do break upon
> changing from one country to another.
>
> How about trying it and reporting?
>
> Also, I think this discussion is worth discussing publicly.  I am
> sorry if I may make statements that may sound too direct.
>
> Alex
>
> thanks for your discussion Best regards, DENG Hui
>
>
> 2013/11/10 Alexandru Petrescu <alexandru.petrescu@gmail.com
> <mailto:alexandru.petrescu@gmail.com>
> <mailto:alexandru.petrescu@__gmail.com
> <mailto:alexandru.petrescu@gmail.com>>>
>
>
> Hui,
>
> Thanks for the email.
>
> Le 10/11/2013 14:32, Hui Deng a écrit :
>
> Alex, thanks for your discussion in the list. Inline please, "==>"
>
>
> 2013/11/9 Alexandru Petrescu <alexandru.petrescu@gmail.com
> <mailto:alexandru.petrescu@gmail.com>
> <mailto:alexandru.petrescu@__gmail.com
> <mailto:alexandru.petrescu@gmail.com>> <mailto:alexandru.petrescu@
> <mailto:alexandru.petrescu@>__g__mail.com <http://gmail.com>
>
> <mailto:alexandru.petrescu@__gmail.com
> <mailto:alexandru.petrescu@gmail.com>>>>
>
>
> Le 07/11/2013 23:56, Fred Baker (fred) a écrit :
>
> We say we check f2f decisions on the mailing list to ensure that
> everyone had a chance to speak. Let's do that.
>
> In IETF 88, we discussed a number of drafts. Of these:
>
> [...]
>
> - Should draft-chen-v6ops-ipv6-roaming-______analysis be adopted as
> WG draft draft-ietf-v6ops-ipv6-roaming-______analysis?
>
>
>
>
> I support adoption of this draft.
>
> I just looked at it in some detail.
>
> I think it deserves enumerating a few practical use-cases where IPv6
> roaming occurs, including extremes like changing operator in same
> place, or through same operator but crossing a national border.
>
> I also wonder about which cellular technology is involved in this
> roaming: 3G, 4G, or CDMA.
>
> ==> Mobile communication whatever 3G,4G/CDMA could support session
> continuity if you really drive the car country by country. because it
> always home routed.(GGSN,PDSN,PDN GW)
>
>
> Even if it is 'home'-routed I think communications break.  (your use
> of the term 'home' is different than the 'Home Agent', I think).
>
> But I noticed when I am in a train and switch country the IP address
> of the mobile changes.  I have no Mobile IP in that mobile, so I have
> to restart the ongoing google maps, or the ongoing youtube.
>
> Even if I had Mobile IP software in the mobile terminal, I don't
> know what is the Home Agent address in the cellular operator
> network? Actually I suppose not any operator offers Home Agent
> address.
>
> In the roaming discussion there are at least two different cases: -
> I stay attached to home operator because that home operator is
> present in the visited country as well. - or I am offered the choice
> to switch to one in a list of different operators in that new
> country.
>
> For both these cases I think the IP address of the Mobile Terminal
> changes.
>
>
> And to expose that - just like in IPv4 - ongoing IPv6 sessions are
> breaking upon roaming.
>
> ==> As said in the above both IPv4 and IPv6 don't have signanificant
> issue about roaming
>
>
> It seems to me, Hui, you didnt try it.  There doesnt seem to be
> experimentatin behind this...
>
>
> This draft discussed several different cases like v4v6 pdp support in
> the roaming country et al. if every deployed mobile gateway/handset
> can support the latest version, then that won't be any issue.
>
>
> Does the latest version require the terminal to use Mobile IP
> software?
>
> Thanks,
>
> Alex
>
> Best regards, DENG Hui
>
>
> Alex
>
>
> I'll collect up the responses in a week and make a determination
> based on that. I'm interested in your viewpoint, whether positive or
> negative. If you would prefer to send it privately to
> v6ops-chairs@tools.ietf.org <mailto:v6ops-chairs@tools.ietf.org>
> <mailto:v6ops-chairs@tools.__ietf.org
> <mailto:v6ops-chairs@tools.ietf.org>> <mailto:v6ops-chairs@tools.
> <mailto:v6ops-chairs@tools.>__i__etf.org <http://ietf.org>
>
> <mailto:v6ops-chairs@tools.__ietf.org
> <mailto:v6ops-chairs@tools.ietf.org>>>, that works too.
>
>
>
> _____________________________________________________ v6ops mailing
> list v6ops@ietf.org <mailto:v6ops@ietf.org> <mailto:v6ops@ietf.org
> <mailto:v6ops@ietf.org>> <mailto:v6ops@ietf.org
> <mailto:v6ops@ietf.org> <mailto:v6ops@ietf.org
> <mailto:v6ops@ietf.org>>>
> https://www.ietf.org/mailman/______listinfo/v6ops
> <https://www.ietf.org/mailman/____listinfo/v6ops>
> <https://www.ietf.org/mailman/____listinfo/v6ops
> <https://www.ietf.org/mailman/__listinfo/v6ops>>
> <https://www.ietf.org/mailman/____listinfo/v6ops
> <https://www.ietf.org/mailman/__listinfo/v6ops>
> <https://www.ietf.org/mailman/__listinfo/v6ops
> <https://www.ietf.org/mailman/listinfo/v6ops>>>
>
>
>
> _____________________________________________________ v6ops mailing
> list v6ops@ietf.org <mailto:v6ops@ietf.org> <mailto:v6ops@ietf.org
> <mailto:v6ops@ietf.org>> <mailto:v6ops@ietf.org
> <mailto:v6ops@ietf.org> <mailto:v6ops@ietf.org
> <mailto:v6ops@ietf.org>>>
> https://www.ietf.org/mailman/______listinfo/v6ops
> <https://www.ietf.org/mailman/____listinfo/v6ops>
> <https://www.ietf.org/mailman/____listinfo/v6ops
> <https://www.ietf.org/mailman/__listinfo/v6ops>>
> <https://www.ietf.org/mailman/____listinfo/v6ops
> <https://www.ietf.org/mailman/__listinfo/v6ops>
> <https://www.ietf.org/mailman/__listinfo/v6ops
> <https://www.ietf.org/mailman/listinfo/v6ops>>>
>
>
>
>
>
>
>
>