Subject: [v6ops] draft-ietf-v6ops-ipv6-roaming-analysis WGLC

From: [email-masked]
Date: Sun, 27 Jul 2014 11:00:04 -0700

This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis.  
Please read it now. If you find nits (spelling errors, minor suggested
wording changes, etc), comment to the authors; if you find greater
issues, such as disagreeing with a statement or finding additional
issues that need to be addressed, please post your comments to the
list.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 28 Jul 2014 09:15:26 +0200 (CEST)

> believe it to be of operational utility, that is also an important

I have re-read the document. I still find it useful. However, when reading 
it I can't help of feeling that this document isn't ready for publication 
yet. It definitely needs a do-over when it comes to language and spelling.

Also, on the technical side, I feel the document could be clearer, but I 
don't know exactly how. I know my comment here isn't really helpful, apart 
from saying that the document might need more work.

One thing that came to mind though, would be a section on how to best 
provision users in HLR. At least one vendor I know of, doesn't support 
setting "IPv4v6" on a user in their HLR. In order to support all cases of 
"IPv4", "IPv6" and "IPv4+IPv6" (dual bearer) and "IPv4v6", one needed to 
give the user two profiles, one being IPv4+ext_pdp IPv6, and also 
IPv6+ext_pdp, otherwise the user couldn't connect using IPv6 only.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: GangChen <[email-masked]>
Date: Tue, 29 Jul 2014 10:26:07 +0800

> IPv6+ext_pdp, otherwise the user couldn't connect using IPv6 only.

Only the value IPv4v6 is allowed for ext_pdp. If HLR doesn't support
IPv4v6 setting(that is the most case pre-R9), in other words, it can't
set ext_pdp. It may not able to support all cases.

I guess one way to provision users if HLR can suppor ext_pdp:

two profiles:

#1:

  PDP-Context ::= SEQUENCE {
	pdp-ContextId	ContextId,
	pdp-Type		PDP-Type, IPv4 & IPv6
	pdp-Address	PDP-Address	OPTIONAL,
  ....
	apn-oi-Replacement	APN-OI-Replacement	OPTIONAL,
	-- this apn-oi-Replacement refers to the APN level apn-oi-Replacement and has
	-- higher priority than UE level apn-oi-Replacement.
	ext-pdp-Type	Ext-PDP-Type	OPTIONAL,
	-- contains the value IPv4v6 defined in 3GPP TS 29.060 [105], if the PDP can be
	-- accessed by dual-stack UEs
	ext-pdp-Address	 PDP-Address	OPTIONAL,
	-- contains an additional IP address in case of dual-stack static IP
address assignment
	-- for the UE.
	-- it may contain an IPv4 or an IPv6 address/prefix, and it may be present
	-- only if pdp-Address is present; if both are present, each parameter shall
	-- contain a different type of address (IPv4 or IPv6).
  ...
	 }

#2:

  PDP-Context ::= SEQUENCE {
	pdp-ContextId	ContextId,
	pdp-Type		PDP-Type, IPv4 & IPv6
	pdp-Address	PDP-Address	OPTIONAL,
  ....
	apn-oi-Replacement	APN-OI-Replacement	OPTIONAL,
	-- this apn-oi-Replacement refers to the APN level apn-oi-Replacement and has
	-- higher priority than UE level apn-oi-Replacement.
	 }

HLR sends ISR with #1 to vSGSN that above R9; otherwise, it sends #2
to vSGSN that is pre-R9

BRs

Gang

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 29 Jul 2014 07:10:20 +0200 (CEST)

> set ext_pdp. It may not able to support all cases.

Then I guess it's a matter of implementation. The HLR I was exposed to, 
did for 2G/3G show to the user that IPv4 could have ext_pdp_type IPv6, and 
this enabled IPv4 and IPv4v6 to work with this setting. If UE asked for 
IPv6 only PDP context that didn't work, so we had to add a profile that 
said "IPv6" without ext_pdp_context_type.

---

From: Ross Chandler <[email-masked]>
Date: Tue, 29 Jul 2014 23:14:26 +0100

On 29 Jul 2014, at 06:10, Mikael Abrahamsson <[email-masked]> wrote:

> Then I guess it's a matter of implementation. The HLR I was exposed to, did for 2G/3G show to the user that IPv4 could have ext_pdp_type IPv6, and this enabled IPv4 and IPv4v6 to work with this setting. If UE asked for IPv6 only PDP context that didn’t work, so we had to add a profile that said "IPv6" without ext_pdp_context_type.

We have to define two allowed PDP Types for the same APN, so that legacy IPv4 PDPs and IPv6 PDPs for 464xlat can both be requested for the same APN.

e.g. 

<hgppp:pdpcp=240;
HLR PACKET DATA PROTOCOL CONTEXT PROFILE DATA
PDPCP  APNID  EQOSID  VPAA  PDPCH    PDPTY  PDPID EPDPIND
240       80     1    NO             IPV4   25    NO
          76     1    NO             IPV4   26    NO
          74     1    NO             IPV4   31    NO
          73     1    NO             IPV4   32    NO  <-- testdata APN V4 
          73     1    NO             IPV6   50    NO  <-- testdata APN V6

If the Android UE APN Protocol is set to “IPv4/IPv6” with this it sets up parallel bearers to the GGSN/PGW.

I agree with Mikael that it might be worth having a section noting this behaviour. An operator doing 464xlat could have UEs connecting with dual-stack done over separate bearers when they’d prefer it to either be single bearer with legacy IPv4 or IPv6 with 464xlat.  This applies in the home and roaming case.

Ross

---

From: gangchen <[email-masked]>
Date: Mon, 14 Jul 2014 22:16:10 -0700

Mikael and Ross,

One section will be added according to the discussion. The following is 
proposed text.

Please kindly check.

Section 6. HLR/HSS User Profile Recommendation

A proper user profile configuration provides devices with good

tolerance to various scenarios. The following are examples to demonstrate

the setting.

Scenario 1: Support IPv6-only, IPv4-only and dual-stack devices

user profile #1:

          pdp-ContextId ContextId,

          pdp-Type PDP-Type-IPv4

   ....

          ext-pdp-Type Ext-PDP-Type

   ...

          }

user profile #2:

          pdp-ContextId ContextId,

          pdp-Type PDP-Type-IPv6

   ....

          }

Note: the full PDP-context list is referred to section 17.7.1 "Mobile 
Service date types" of TS29.002. User profile 1 and 2 share the same 
contextId.

Scenario 2: Support dual-stack devices with pre-R9 vSGSN access

user profile #1:

          pdp-ContextId ContextId,

          pdp-Type PDP-Type-IPv4

   ....

          ext-pdp-Type Ext-PDP-Type

   ...

          }

user profile #2:

          pdp-ContextId ContextId,

          pdp-Type PDP-Type-IPv4

   ....

          }

Note: User profile 1 and 2 share the same contextId.

HLR/HSS is able to identify pre-R9 vSGSN and only send user profile#2 to 
vSGSN.

BRs

Gang

On 07/29/2014 03:14 PM, Ross Chandler wrote:
>
> On 29 Jul 2014, at 06:10, Mikael Abrahamsson <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Then I guess it's a matter of implementation. The HLR I was exposed 
>> to, did for 2G/3G show to the user that IPv4 could have ext_pdp_type 
>> IPv6, and this enabled IPv4 and IPv4v6 to work with this setting. If 
>> UE asked for IPv6 only PDP context that didn't work, so we had to add 
>> a profile that said "IPv6" without ext_pdp_context_type.
>
> We have to define two allowed PDP Types for the same APN, so that 
> legacy IPv4 PDPs and IPv6 PDPs for 464xlat can both be requested for 
> the same APN.
>
> e.g.
>
> <hgppp:pdpcp=240;
> If the Android UE APN Protocol is set to "IPv4/IPv6" with this it sets 
> up parallel bearers to the GGSN/PGW.
>
> I agree with Mikael that it might be worth having a section noting 
> this behaviour. An operator doing 464xlat could have UEs connecting 
> with dual-stack done over separate bearers when they'd prefer it to 
> either be single bearer with legacy IPv4 or IPv6 with 464xlat.  This 
> applies in the home and roaming case.
>
> Ross
>
>

---

From: GangChen <[email-masked]>
Date: Wed, 30 Jul 2014 11:20:05 +0800

> said "IPv6" without ext_pdp_context_type.

If I understand correctly, the setting would be

#1 is IPv4 + ext_pdp_type; #2 is IPv6 only; Those two profiles have
same ContextId.

#1:

	pdp-Type		PDP-Type IPv4

#2:

	pdp-Type		PDP-Type, IPv6
  ....
	 }
	
BRs

Gang

---

From: Ross Chandler <[email-masked]>
Date: Wed, 30 Jul 2014 08:27:12 +0100

On 15 Jul 2014, at 06:16, gangchen <[email-masked]> wrote:

Gang,

Wording tweak below.  I hope haven’t altered the meaning.

A proper user profile configuration should provide deterministic network
control of the connectivity that can be set-up from the device:
IPv4-only, IPv6-only, dual-stack using separate bearers, or dual-stack
using a single beaerer. The HLR/HSS may have to apply extra logic
to achieve this.

It may be expected that the device could attempt to set-up connectivity by any
of the above means. 

The following are examples to demonstrate the settings for the scenarios
and decision criteria to apply when returning user profile information to 
the SGSN.

Ross

> One section will be added according to the discussion. The following is proposed text.
> Please kindly check.
> 
>  
> 
> A proper user profile configuration should provide devices with good
> 
> Note: the full PDP-context list is referred to section 17.7.1 "Mobile Service date types" of TS29.002. User profile 1 and 2 share the same contextId.
> 
>  
> 
> HLR/HSS is able to identify pre-R9 vSGSN and only send user profile#2 to vSGSN.
> 
> 
> BRs
> 
> Gang
>

---

From: GangChen <[email-masked]>
Date: Wed, 30 Jul 2014 16:32:34 +0800

> using a single beaerer. The HLR/HSS may have to apply extra logic

IMHO, we may have to avoid dual-stack using separate bearers. So I
make a minor revision on the texts as below.

A proper user profile configuration could provide deterministic
network control of
the connectivity requests from dual-stack, IPv4-only and IPv6-only
devices. It's desirable
that the network could set-up proper connectivity for any type of the
devices.The HLR/HSS may have to apply extra logic to achieve this.

BRs

Gang

>>>> did for 2G/3G show to the user that IPv4 could have ext_pdp_type IPv6,
>>>> and this enabled IPv4 and IPv4v6 to work with this setting. If UE asked
>>>> for IPv6 only PDP context that didn’t work, so we had to add a profile
>>>> that said "IPv6" without ext_pdp_context_type.
>>>
>>> We have to define two allowed PDP Types for the same APN, so that legacy
>>> IPv4 PDPs and IPv6 PDPs for 464xlat can both be requested for the same
>>> APN.
>>>
>>> e.g.
>>>
>>> <hgppp:pdpcp=240;
>>> I agree with Mikael that it might be worth having a section noting this
>>> behaviour. An operator doing 464xlat could have UEs connecting with
>>> dual-stack done over separate bearers when they’d prefer it to either be
>>> single bearer with legacy IPv4 or         IPv6 with 464xlat.  This

---

From: Ross Chandler <[email-masked]>
Date: Wed, 30 Jul 2014 12:15:50 +0100

Gang,

I agree that avoiding dual-stack should be part of the recommendation.
Reasons which we might want to also explicitly state: 

Separate bearers are undesirable because they hold up extra resources in 
the Radio Access, as well as in the GGSN. and it may complicate  the 
reconciliation of CDRs for a subscriber, particularly in the roaming case.

Regards,
Ross