IETF Logo Mail Archive

Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis

Tore Anderson <tore@fud.no> Thu, 18 July 2013 07:17 UTC

Return-Path: <tore@fud.no>
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 0CD4421E808A for <v6ops@ietfa.amsl.com>; Thu, 18 Jul 2013 00:17:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 5uND4jVvlnO0 for <v6ops@ietfa.amsl.com>; Thu, 18 Jul 2013 00:17:28 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 08ED021F9FC8 for <v6ops@ietf.org>; Thu, 18 Jul 2013 00:17:22 -0700 (PDT)
Received: from www-data by greed.fud.no with local (Exim 4.80) (envelope-from <tore@fud.no>) id 1UziSm-0000d6-Lo; Thu, 18 Jul 2013 09:17:20 +0200
To: GangChen <phdgang@gmail.com>
X-PHP-Originating-Script: 0:main.inc
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Date: Thu, 18 Jul 2013 09:17:20 +0200
From: Tore Anderson <tore@fud.no>
In-Reply-To: <CAM+vMETh_FyroOGabGz=TgrtH53poxnu9qH7ZY5xiP-c7SMWZQ@mail.gmail.com>
References: <201307091245.r69Cj0Q08784@ftpeng-update.cisco.com> <88b3974ae0dcc67770c6ba6e29e09c7f@greed.fud.no> <CAM+vMETh_FyroOGabGz=TgrtH53poxnu9qH7ZY5xiP-c7SMWZQ@mail.gmail.com>
Message-ID: <806058568c3cd8d3600cb70bc520c10a@greed.fud.no>
X-Sender: tore@fud.no
User-Agent: Roundcube Webmail/0.7.2
Cc: v6ops@ietf.org
Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis
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: Thu, 18 Jul 2013 07:17:29 -0000

* GangChen

> Thanks for sharing your experience. Yes, you are right.
> There is no such issue if the subscriber's traffic get back to the
> gateway (e.g. GGSN) in the home network.
> The described failure case occurred when the subscriber get an address
> from the GGSN in the visited network. And traffic flows would be
> transmitted in a local-breakout manner.  3GPP allows such
> local-breakout because it has more efficient routing paths. 3GPP also
> specified another architecture called "SIPTO". It guarantees the
> subscriber would always select the closest GGSN to reside.

I see. When roaming, I always get an IP address that belongs to my home
provider (this goes both for IPv4 and IPv6), so I assume that it is the
home network's choice whether or not to enable this "use closest GGSN"
feature?

If so, I'd suggest adding some text that ensuring this feature is
disabled (at least for the IPv6 PDP type, if it is possible to
differentiate between the two) is a good way to prevent IPv6 subscribers
from experiencing problems when roaming in IPv4-only networks.

Tore

v2.23.0 | Report a Bug | By Email