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

Rajiv

On Mon, Jul 29, 2013 at 12:00 PM, Rajiv Asati (rajiva) <rajiva@cisco.com> wrote:
> Hi Cameron,
>
> Could you please share more details about 3a and 3b below?
>
>

Can you be more specific about the question?

Charging systems have a hard time to reconcile usage from 2 PDP
because they are 2 separate CDRs, 1 for each PDP.  Also, 2 PDP is 2x
as expensive in terms of signalling and licensing.

v4v6 as single PDP is not viable because not everything supports
release 8 in the GSM/3GPP ecosystem.  I tried to enable v4v6 for my
subscribers in my central database (HLR/HSS), and adding this
capability to all my subscribers made some existing ipv4 roaming
subscribers fail.   Why?  Because when my users attach into a roaming
partner network, their network downloads the capabilities of the
subscriber from my database (HLR/HSS)... and if one of the
capabilities includes v4v6, then the roaming partners's equipment
drops the users because they don't understand this term.

This is a roaming partner network device acting in a bad and
non-standard way.  It's a shame i have to turn off v4v6 globally
because of this issue.  There is one subscriber database, and because
some roaming partner gear fails, it is not safe to turn anywhere.  One
remediation is to limit attributes based on a whitelist / blacklist,
but this is not feature available today.

Luckily, the good people of v6ops have approved RFC6877 and Android
implemented it in 4.3 , so single v6 PDP works ok.

> WOuldn't the UE fallback to v4 PDP, if v4v6 PDP wasn't available?
>

Yes, it's supposed to work that way.  But, keep in mind what i said
above.  In the real world, it does not (for now, once everyone
upgrades maybe this wont be a problem).

Cameron

> Cheers,
> Rajiv
>
> -----Original Message-----
> From: Cameron Byrne <cb.list6@gmail.com>
> Date: Sunday, July 28, 2013 11:48 AM
> To: "Fred Baker (fred)" <fred@cisco.com>
> Cc: "v6ops@ietf.org" <v6ops@ietf.org>,
> "draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org"
> <draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org>
> Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis
>
>>As general feedback
>>
>>1. As others have noted, it is important to clarify that home routed
>>is the default case and local-breakout is only relavent for IMS, but
>>IMS based roaming and local breakout is yet to see its first
>>deployment, and may still be years in the future for roaming to work
>>this way.  So, local breakout is not  a real case and seems to be
>>causing more confusion.
>>
>>2.  There is a hazard in assuming the well known prefix is always
>>available.  Any device should not assume the well known prefix is
>>available.  This is essentially a misconfiguration that should not
>>occur.
>>
>>3.  What i have learned
>>
>>a.  dual-stack 2 PDP will never work, charging issues in the billing
>>system, and too much capacity wasted for no real gain
>>
>>b.  dual-stack 1 PDP (v4v6) will not work any time soon.  Enabling
>>this feature in the HSS/HLR breaks roaming and there is no way to
>>ensure this issue is fixed in the hundreds of networks that are
>>potentially impacted.  There are some backs to do on the home network
>>that can make this easier but not exposing partner networks to the new
>>release 8 features.
>>
>>c.  What does work and adds value (saves IPv4 address for the common
>>case of not-roaming) :  IPv6-only single PDP 464XLAT on the home
>>network, IPv4-only single PDP when roaming.  This is how i am moving
>>forward.  The when at home, the UE has default configs for ipv6-only
>>and when roaming the ue only attempts to connect using IPv4.  This
>>gets the vast majority of users in my home network off v4 and keeps
>>ipv4 for the complicated yet relatively small percentage of roaming
>>users.
>>
>>
>>
>>On Tue, Jul 9, 2013 at 5:45 AM,  <fred@cisco.com> wrote:
>>>
>>> A new draft has been posted, at
>>>http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis.
>>>Please take a look at it and comment.
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>_______________________________________________
>>v6ops mailing list
>>v6ops@ietf.org
>>https://www.ietf.org/mailman/listinfo/v6ops
>