Subject: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update

From: <[email-masked]>
Date: Thu, 20 Sep 2012 09:00:38 +0200

Dear all,

We submitted this new I-D. 

Review and comments are more than welcome.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mercredi 19 septembre 2012 14:57
À : [email-masked]
Objet : I-D Action: draft-binet-v6ops-cellular-host-reqs-rfc3316update-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Internet Protocol Version 6 (IPv6) for Cellular Hosts
	Author(s)       : David Binet
                          Mohamed Boucadair
	Filename        : draft-binet-v6ops-cellular-host-reqs-rfc3316update-00.txt
	Pages           : 14
	Date            : 2012-09-19

Abstract:
   This document lists a set of IPv6-related requirements to be
   supported by cellular hosts.

   This document updates RFC3316.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-reqs-rfc3316update

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-reqs-rfc3316update-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: GangChen <[email-masked]>
Date: Thu, 20 Sep 2012 23:12:45 +0800

Hello Med,

Thanks for the work. I read the draft.
In general, the requirements have been structured as Basic
Connectivity, Advanced and APIs & Applications
Just wondering to know what release of cellular host the requirements
are targeting?
What’s the consideration to frame the context of each section?
I have noticed that some basic IPv6 capability is mentioned in the
part of Advanced Requirements.  That seems to me should belong to the
Basic part.

More details are as following.

2.  Basic Connectivity Requirements
REQ#1,
REQ#2,
REQ#3 and REQ#4 were already specified in 3GPP.
Not sure it would add much discussions to the draft.

REQ#6 and REQ#7 should be combined IMHO, because it provides same
outcome solving the issues related to compatibility of IPv4
applications.

REQ#8: I don't understand the purpose of embed a DNS64 function.
Especially, the sentence of "This allows to be compatible with DNSSEC"

REQ#10 I guess I-D.ietf-behave-nat64-discovery-heuristic should be
ranked as first priority compared to
I-D.boucadair-pcp-nat64-prefix64-option

REQ#11: Preferring native IPv6 doesn't always achieve good effect. It
may cause additional charge in some cases. Please refer to
http://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-00#page-3
case 4 for further information

One additional requirement maybe worth to add for the completeness:

REQ#XX The cellular device SHOULD embed a BIH function [RFC6535]
facilitating the communication between IPv4 application and IPv6
server

2.1.  WiFi Connectivity

It may be complementary to add one additional requirement, like

REQ#XX Prefix Delegation capabilities [RFC3633] MUST be supported on
the Wi-Fi interface.

3.  Advanced Requirements

 REQ#16,
 REQ#17,
 REQ#18,
 REQ#19 and REQ#20 may be proper to be shifted to "2. Basic
Connectivity Requirements", since those features are basic IPv6
capability

REQ#22:  it maybe proper to change the *SHOULD* to *MAY*

Best Regards

Gang

2012/9/20, [email-masked] <[email-masked]>:
> Objet : I-D Action:
> draft-binet-v6ops-cellular-host-reqs-rfc3316update-00.txt
>
>
> 	Filename        :
> draft-binet-v6ops-cellular-host-reqs-rfc3316update-00.txt
> 	Pages           : 14
> 	Date            : 2012-09-19
>
> Abstract:
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Sep 2012 15:32:44 +0000

> Especially, the sentence of "This allows to be compatible with DNSSEC"

Because a DNS64 translator has to spoof records in a zone, by definition it's impossible for these spoofed records to be validated. So in order for DNSSEC to function with NAT64, it is required that the resolver on the end device do the DNS64 translation. 

Of course, in order for it to do this, it needs to know the NAT64 prefix...

---

From: <[email-masked]>
Date: Fri, 21 Sep 2012 07:56:35 +0200

Hi Gang,

Thanks for the review. 

Please see inline.

Cheers,
Med 

>De : GangChen [mailto:[email-masked]] 
>Envoyé : jeudi 20 septembre 2012 17:13
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : IPv6 Ops WG
>Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update
>
>Hello Med,
>
>What's the consideration to frame the context of each section?

Med: The purpose of the draft is to have one place where an IPv6 profile for cellular device is device. There are several requirements on the UEs spread in various specification document. Listing those 3GPP spec is one part of the puzzle to define an IPv6 profile for cellular hosts.

>applications.>

Med: I see Ted already answered to this comment. 
>I-D.boucadair-pcp-nat64-prefix64-option

Med: Please refer to http://www.ietf.org/mail-archive/web/pcp/current/msg02273.html for the discussion I had with Teemu on this item.

>case 4 for further information

Med: I added a pointer to the MIF draft to record the issue.

>facilitating the communication between IPv4 application and IPv6

Med: As we have CLAT already listed there, what would be the motivation to include BIH?
I added a discussion note to the draft to record this point.    

>REQ#XX Prefix Delegation capabilities [RFC3633] MUST be supported on

Med: Wouldn't this be redundant with what is the features discussed in Section 4?

>Connectivity Requirements", since those features are basic IPv6

Med: I will check.

>REQ#22:  it maybe proper to change the *SHOULD* to *MAY*

Med: What is the rationale behind that change?

>> De : [email-masked] 
>[mailto:[email-masked]] De
>> la part de [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 21 Sep 2012 16:18:23 +0900

> Review and comments are more than welcome.

A couple of comments, having skimmed the draft:

1. Did you consider a requirement to support RFC 4191? Many people are
asking for the ability to support more-specific routes, especially in the
MIF working group.
2. REQ#28 says the device MUST (no less!) support ND proxy. I don't think
it's appropriate to say that an experimental RFC is a requirement.
Additionally, ND proxy is not fully baked, and it has issues with certain
topologies. We need a better solution than that.
3. REQ#32 says the device must also be an RFC-6204 compliant IPv6 CE
router. Are there no conflicts?

---

From: <[email-masked]>
Date: Fri, 21 Sep 2012 09:37:14 +0200

Dear Lorenzo,

Please see inline.

Cheers,
Med

________________________________
De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : vendredi 21 septembre 2012 09:18
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : IPv6 Ops WG
Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update

On Thu, Sep 20, 2012 at 4:00 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Review and comments are more than welcome.

1. Did you consider a requirement to support RFC 4191? Many people are asking for the ability to support more-specific routes, especially in the MIF working group.
[Med] We didn't considered it because there are some assumptions to be made: e.g., do we expect all interfaces are connected to networks managed by the same administrative entity? How to manage conflicts if distinct policies are sent? etc.

2. REQ#28 says the device MUST (no less!) support ND proxy. I don't think it's appropriate to say that an experimental RFC is a requirement. Additionally, ND proxy is not fully baked, and it has issues with certain topologies. We need a better solution than that.
[Med] RFC4389 is the best reference we can quote at this stage. Do you have a pointer to an I-D where these issues are discussed? We can add a pointer to that I-D.

3. REQ#32 says the device must also be an RFC-6204 compliant IPv6 CE router. Are there no conflicts?
[Med] We didn't done that analysis as we are considering also scenarios for fixed-mobile convergence where a CPE can be connected to a fixed network by default and in case of failure switch to the 3GPP network or scenario.
I would see some conflicts if we added a REQ for RFC6204-bis as it lists some transition mechanisms which are not required for mobile networks.

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 21 Sep 2012 17:38:32 +1000

A few quick comments on the drat having gone through it quickly.

1. Requirements 1 and 2 are sort of redundant in an IETF document. The
purpose od RFC 3316 was t specify IETF protocols that should be supported
by the cellular host. PDP context has nothing to do with IETF protocols
and functionally speaking it's outside of the IP stack. Therefore, I see
no reason for specifying this in an RFC. It's not harmful, but since it's
specified elsewhere, having such redundancy can lead to confusion if 3GPP
specs change for example. So it's best to remove them.

2. Same goes for the PCO. out of scope. It's no different than the IP
stack "finding" these parameters in a file that come from "somewhere".

3. Req 5, I suggest a MAY instead of a SHOULD.

4. for req 6 and 7. Are we sure this is a SHOULD? Are we effectively
requiring these functions for all deployments? It seems like a big
mandate, who's pushing for this? Just need to see that we have consensus
on this. I think Req 8 has the right keyword "MAY" and the same should
apply to 6 and 7 IMO.

5. REQ 9 and 10 are also too strong. This is a MAY by the definition of
keywords. It's an optimisation.

6. REQ 18 repeats 3316, although the reference has changed, so it's
redundant. 

7. REQ 19 conflicts with REQ 5, MAY Vs SHOULD. If they're both MAY I'm ok
with that. 

8. REQ 21 is completely redundant because this behaviour is mentioned in
RFC 3314, 3316 and 3GPP specs.

9. REQ 27: For 3GPP specs there are defined standards for discovering
their servers. Why would you list another mechanism not related to 3GPP?
The purpose of the draft is to address a specific deployment. General IETF
specs are available to all implementers and they can decide for themselves
what they want to implement on top of the base.

10. I disagree with REQ 28. This is an experimental RFC. If someone does
it that's fine, but no need to mandate it here.

11. REQ#29: "The cellular device MUST support Prefix Delegation
      capabilities [RFC3633 <http://tools.ietf.org/html/rfc3633>].
Particularly, it MUST behave as a
      Requesting Router."

=> Why? Where did this come from? I disagree with this requirement. It's
up to each implementation to decide that. At best, you could have a MAY
but it's completely redundant. And as a consequence, so is REQ 30.

12. REQ#31:  The cellular device SHOULD support Customer Side Translator
      (CLAT) [I-D.ietf-v6ops-464xlat
<http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-reqs-rfc3316upd
ate-00#ref-I-D.ietf-v6ops-464xlat>].

=> Why? Why SHOULD? Again, at best a MAY.

Thanks,
Hesham

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 21 Sep 2012 16:52:09 +0900

On Fri, Sep 21, 2012 at 4:37 PM, <[email-masked]> wrote:

> **
> [Med] We didn't considered it because there are some assumptions to be
> made: e.g., do we expect all interfaces are connected to networks managed
> by the same administrative entity? How to manage conflicts if distinct
> policies are sent? etc.
>
>
I don't understand. An interface is connected to only network, and the
cellular link is point-to-point. By definition, there can only be one
entity on the other side. Where's the conflict?

>   2. REQ#28 says the device MUST (no less!) support ND proxy. I don't
> think it's appropriate to say that an experimental RFC is a requirement.
> [Med] RFC4389 is the best reference we can quote at this stage. Do you
> have a pointer to an I-D where these issues are discussed? We can add a
> pointer to that I-D.
>
> There is no working solution at this time. This can be made to work when
tethering over the cellular link, but the ND proxy RFC is not the way to do
it. I think we need a new document to specify this.

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 21 Sep 2012 17:59:57 +1000

>think 
>[Med] RFC4389 is the best reference we can quote at
>  this stage. Do you have a pointer to an I-D where these issues are
>discussed? 
>  We can add a pointer to that I-D.
>
>
>
>
>
>
>tethering over the cellular link, but the ND proxy RFC is not the way to
>do it. I think we need a new document to specify this.

=> We don't even need a new document. It's implementation specific. As per
another thread iPad already has it. We should just remove the ND proxy
from this draft. People don't need us to tell them how to tether over a
single hop. 

Hesham

---

From: <[email-masked]>
Date: Fri, 21 Sep 2012 10:04:23 +0200

Re-,

Please see inline.

Cheers,
Med

Envoyé : vendredi 21 septembre 2012 09:52

On Fri, Sep 21, 2012 at 4:37 PM, <[email-masked]<mailto:[email-masked]>> wrote:
1. Did you consider a requirement to support RFC 4191? Many people are asking for the ability to support more-specific routes, especially in the MIF working group.
[Med] We didn't considered it because there are some assumptions to be made: e.g., do we expect all interfaces are connected to networks managed by the same administrative entity? How to manage conflicts if distinct policies are sent? etc.

I don't understand. An interface is connected to only network, and the cellular link is point-to-point. By definition, there can only be one entity on the other side. Where's the conflict?
[Med] Consider the case the MIFed device is connected to both a 3G network and WiFI hotspot simultaneously: if the hotspot and the 3G are managed by the same provider, then policies to offload (some of traffic) can be enforced using specific routes. But if these networks are not managed by same entities and each of them are sending specific routes, wouldn't be there potential conflict in the policies? What would be the behaviour of the device?

 2. REQ#28 says the device MUST (no less!) support ND proxy. I don't think it's appropriate to say that an experimental RFC is a requirement. Additionally, ND proxy is not fully baked, and it has issues with certain topologies. We need a better solution than that.
[Med] RFC4389 is the best reference we can quote at this stage. Do you have a pointer to an I-D where these issues are discussed? We can add a pointer to that I-D.
There is no working solution at this time. This can be made to work when tethering over the cellular link, but the ND proxy RFC is not the way to do it. I think we need a new document to specify this.

---

From: <[email-masked]>
Date: Fri, 21 Sep 2012 10:09:52 +0200

Re-,

It is not only for tethering but for CPE-like service offering (e.g., http://www.flybox-tn.com/). 

REQ#28 is under "device with LAN capabilities" section. We need to have a pointer to a solution to be embedded in the CPE for that case. 

Is there any reason what this should we left it implementation-specific?

Thanks. 

Cheers,
Med

>De : Hesham Soliman [mailto:[email-masked]] 
>Envoyé : vendredi 21 septembre 2012 10:00
>À : Lorenzo Colitti; BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : IPv6 Ops WG

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 21 Sep 2012 18:13:58 +1000

>REQ#28 is under "device with LAN capabilities" section. We need to have a
>pointer to a solution to be embedded in the CPE for that case.
>

=> Yes. For tethering, nothing is needed as it is implementation specific,
i.e. it is solved within one node.
As for other offers, there are two good reasons to not include this:

1. It's an experimental RFC.
2. Our role in this work is not to try to suggest new commercial offers
for these devices, it is to explain which of the _current_ IETF
specifications need to be supported to maintain a base level of
communication. 

Hesham

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 21 Sep 2012 17:14:23 +0900

On Fri, Sep 21, 2012 at 5:04 PM, <[email-masked]> wrote:

> **
>
> [Med] Consider the case the MIFed device is connected to both a 3G network
> and WiFI hotspot simultaneously: if the hotspot and the 3G are managed by
> the same provider, then policies to offload (some of traffic) can be
> enforced using specific routes. But if these networks are not managed by
> same entities and each of them are sending specific routes, wouldn't be
> there potential conflict in the policies? What would be the behaviour of
> the device?
>
> Longest-prefix match, just like it is today. If you want the wifi to have
preference, just announce more specifics on the wifi and you're done.

---

From: GangChen <[email-masked]>
Date: Fri, 21 Sep 2012 17:35:01 +0800

Hello Med,

>>Just wondering to know what release of cellular host the requirements

In a cellular context, the IPv6 capability is closely depending on 3GPP Release.
I guess it would help if the draft could identify the particular
context.

>>Not sure it would add much discussions to the draft.

Acknowledged. However, I guess the draft is supposed to document
something IETF-specific.Those requirements seem to belong
3GPP scope.

> Med: The purpose of the draft is to have one place where an IPv6 profile for
> cellular device is device. There are several requirements on the UEs spread
> in various specification document. Listing those 3GPP spec is one part of
> the puzzle to define an IPv6 profile for cellular hosts.
>
>>

Answer is expected on this point.

> Med: I see Ted already answered to this comment.

Yes. That answers my question. Thanks

> Med: Please refer to
> http://www.ietf.org/mail-archive/web/pcp/current/msg02273.html for the
> discussion I had with Teemu on this item.

I-D.boucadair-pcp-nat64-prefix64-option is a individual I-D
Only concern is we can't tell what would be available in the future.

> I added a discussion note to the draft to record this point.

They are working in a complementary way but different cases. 464xlat
is working for an IPv4 application talking to IPv4 servers going
through IPv6 network.
BIH is to enable an IPv4 application talking to IPv6 servers within an
IPv6 network.

> Med: Wouldn't this be redundant with what is the features discussed in

It's not redundant because the requirements of DHCP-PD would apply to
different chips.

BRs

Gang

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 21 Sep 2012 19:41:14 +1000

one more comment, I believe RFC 5555 is mentioned in LTE specs. It should
be listed as a MAY IMO.

Hesham

---

From: jouni korhonen <[email-masked]>
Date: Fri, 21 Sep 2012 13:27:49 +0300

Med,

> [Med] Consider the case the MIFed device is connected to both a 3G network and WiFI hotspot simultaneously: if the hotspot and the 3G are managed by the same provider, then policies to offload (som…

RFC4191 also brings in router preferences. You do not need to bother too much
with specific routes. Simple example to make cellular preference low and others
stay on default. More specific routes can be installed on those destinations 
you definitely want to flow through your cellular infra. We got some good results
with that, specifically when you configure your mobile to allow RC4191 extensions
only from your cellular interface (trivial e.g. on any Linux based device). So the
mobile operator still has the control. That has been dealt several times in Mif.

- Jouni

---

From: <[email-masked]>
Date: Fri, 21 Sep 2012 14:07:36 +0200

Dear Hesham,

Thanks for the review.

Please see inline. 

Cheers,
Med 

>Envoyé : vendredi 21 septembre 2012 09:39

Med: I see the point but we consider it from another perspective: We tried to answer to the question "What a device should support in order to be IPv6-compliant + be able to be connected to a3GPP network". There is no single document defining an IPv6 profile for cellular hosts/devices. We wanted a single document listed both IETF and 3GPP specification. 

>stack "finding" these parameters in a file that come from "somewhere".

Med: Same as above.

>3. Req 5, I suggest a MAY instead of a SHOULD.

Med: I just found this req conflicts with REQ#19. I will double check. 

>on this. I think Req 8 has the right keyword "MAY" and the same should

Med: These are important features to support if we want IPv6-only connectivity model to fly. 

>keywords. It's an optimisation.

Med: There are various reasons to have PCP as SHOULD: save the battery consumption, reduce keepalive message, Control and retrieve the lifetime of NAT bindings, ease NAT and firewall traversal for application embedding IP address and/or port number(s) in the application payload, allow for successful inbound communications and for the capability to control outgoing connections, control and retrieve the lifetime of NAT bindings (including implicit ones), allow NAT binding recovery, trigger applications to repairs their bindings whenever this is required.

>7. REQ 19 conflicts with REQ 5, MAY Vs SHOULD. If they're both 

Med: Thanks for catching this.

>their servers. Why would you list another mechanism not 

Med: This is an optional feature which would solve an issue of bootstrapping in a non-3GPP network. I have added a note in http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-reqs-rfc3316update-01: 

         [DISCUSSION NOTE: Since this is still an individual submission,
         should we remove this item?]

>it that's fine, but no need to mandate it here.

Med: This is for a CPE-like service. We need a solution for the issue discussed in that REQ. RFC4389 is what we have now. If there is any better ref, I can add it.

>but it's completely redundant. And as a consequence, so is REQ 30.

Med: REQ#29 and REQ#30 have been merged in -01 (http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-reqs-rfc3316update-01)

>=> Why? Why SHOULD? Again, at best a MAY.

Med: This is for the case where there is an IPv4 host connected behind the cellular CPE.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Sep 2012 12:14:42 +0000

> Med: These are important features to support if we want IPv6-only connectivity model to fly. 

My general reaction to the document is that the requirements are too weak and I would like to see them strengthened. I think requirement 8, for example, should be a SHOULD, not a MAY.  implementors can still ignore a SHOULD, but in doing so they are clearly leaving out an important feature, not just skipping something nobody cares very much about.

---

From: <[email-masked]>
Date: Fri, 21 Sep 2012 14:15:03 +0200

Re-,

I'm neutral on the support of this one. I added this new REQ to Section 3 to record it in the I-D:

         "REQ#28:  The cellular host MAY support [RFC5555]."

Thanks.

Cheers,
Med 

>Envoyé : vendredi 21 septembre 2012 11:41
>À : Hesham Soliman; BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : IPv6 Ops WG
>><http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-re
>qs-rfc3316up
>>d

---

From: <[email-masked]>
Date: Fri, 21 Sep 2012 14:21:30 +0200

Dear Ted,

I fully agree with this comment. 
We need input from the WG to "tune" the requirements.

Cheers,
Med 

>De : Ted Lemon [mailto:[email-masked]] 
>Envoyé : vendredi 21 septembre 2012 14:15
>Cc : Hesham Soliman; IPv6 Ops WG
>My general reaction to the document is that the requirements 
>are too weak and I would like to see them strengthened. I 
>think requirement 8, for example, should be a SHOULD, not a 
>MAY.  implementors can still ignore a SHOULD, but in doing so 
>they are clearly leaving out an important feature, not just 
>skipping something nobody cares very much about.

---

From: <[email-masked]>
Date: Fri, 21 Sep 2012 14:25:02 +0200

Hi Jouni,

That makes sense. 

I added a new REQ to Section 3 for RFC4191.

Thanks. 

Cheers,
Med 

>De : jouni korhonen [mailto:[email-masked]] 
>Envoyé : vendredi 21 septembre 2012 12:28
>Cc : Lorenzo Colitti; IPv6 Ops WG
>> I don't understand. An interface is connected to only 
>network, and the cellular link is point-to-point. By 
>definition, there can only be one entity on the other side. 
>Where's the conflict?
>> [Med] Consider the case the MIFed device is connected to 
>both a 3G network and WiFI hotspot simultaneously: if the 
>hotspot and the 3G are managed by the same provider, then 
>policies to offload (some of traffic) can be enforced using 
>specific routes. But if these networks are not managed by same 
>entities and each of them are sending specific routes, 
>wouldn't be there potential conflict    in the policies? What 
>would be the behaviour of the device? 
>
>>  2. REQ#28 says the device MUST (no less!) support ND proxy. 
>I don't think it's appropriate to say that an experimental RFC 
>is a requirement. Additionally, ND proxy is not fully baked, 
>and it has issues with certain topologies. We need a better 
>solution than that.
>> [Med] RFC4389 is the best reference we can quote at this 
>stage. Do you have a pointer to an I-D where these issues are 
>discussed? We can add a pointer to that I-D.
>> There is no working solution at this time. This can be made 
>to work when tethering over the cellular link, but the ND 
>proxy RFC is not the way to do it. I think we need a new 
>document to specify this.

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 21 Sep 2012 23:04:08 +1000

>Med: I see the point but we consider it from another perspective: We
>tried to answer to the question "What a device should support in order to
>be IPv6-compliant + be able to be connected to a3GPP network".

=> So why don't you talk about the radio interface? :) It's out of scope.
The PDP context is the same. It's out of scope for IETF.

>There is no single document defining an IPv6 profile for cellular
>hosts/devices. We wanted a single document listed both IETF and 3GPP
>specification.

=> There is, RFC 3316, which you're trying to update and it doesn't talk
about link layers. 
>connectivity model to fly.

=> But they're not the only way to support IPv6-only. There are many
different variations therefore SHOULD/MUST is way too strong. Please check
the definitions of should and must.

>Med: There are various reasons to have PCP as SHOULD: save the battery
>consumption, reduce keepalive message, Control and retrieve the lifetime
>of NAT bindings, ease NAT and firewall traversal for application
>embedding IP address and/or port number(s) in the application payload,
>allow for successful inbound communications and for the capability to
>control outgoing connections, control and retrieve the lifetime of NAT
>bindings (including implicit ones), allow NAT binding recovery, trigger
>applications to repairs their bindings whenever this is required.

=> I wasn't discussing the features of PCP, it's more about the keyword
used. Should means you basically have to support it unless you know
better. In practice everyone follows a should. It's not optional.

>Med: This is an optional feature which would solve an issue of
>bootstrapping in a non-3GPP network. I have added a note in
>http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-reqs-rfc3316upd
>ate-01: 
>
>Med: This is for a CPE-like service. We need a solution for the issue
>discussed in that REQ. RFC4389 is what we have now. If there is any
>better ref, I can add it.

=> I think I responded to this separately.

>Med: REQ#29 and REQ#30 have been merged in -01
>(http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-reqs-rfc3316up
>date-01)
>
>>

=> Again, I'm objecting to the level of support not the use case.

Hesham

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Sep 2012 13:13:56 +0000

> the definitions of should and must.

This response seems to be based on the assumption that many different device implementors will make many different choices, and that operators will therefore have to support every possible set of choices that may have been made when implementing each specific device.   This is the exact opposite of what a requirements document like this one is supposed to achieve.   The point of these requirements is to create a reasonable baseline set of expectations that operators can have about devices that will connect to their networks.   If, as a device implementor, you don't want to have to implement the recommended functionality, that's fine, but then you can't claim to support the requirements in the document.

Of course, a SHOULD requirement doesn't prevent you from claiming you support the document, unfortunately.   But at least is gives you a strong hint that the functionality is desirable, and its absence will mean that your device may not provide a good feature set on some operator networks.

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 21 Sep 2012 23:19:30 +1000

>This response seems to be based on the assumption that many different
>device implementors will make many different choices, and that operators
>will therefore have to support every possible set of choices that may
>have been made when implementing each specific device.   This is the
>exact opposite of what a requirements document like this one is supposed
>to achieve.   The point of these requirements is to create a reasonable
>baseline set of expectations that operators can have about devices that
>will connect to their networks.

=> And has there been on consensus on that mechanism? Because if there is
consensus on one approach then lets remove a few more requirements. The
current draft seems to select two approaches from what I remember.

>If, as a device implementor, you don't want to have to implement the
>recommended functionality, that's fine, but then you can't claim to
>support the requirements in the document.
>
>Of course, a SHOULD requirement doesn't prevent you from claiming you
>support the document, unfortunately.   But at least is gives you a strong
>hint that the functionality is desirable, and its absence will mean that
>your device may not provide a good feature set on some operator networks.

=> Of course, but some IETF consensus needs to be established before
selecting a couple of mechanisms and saying that's it!
Speaking of which, I'm assuming the IPv6 WG is going to review this draft
as well. 

Hesham

---

From: <[email-masked]>
Date: Fri, 21 Sep 2012 15:26:58 +0200

Re-,

Please see inline. 

Cheers,
Med 

>Envoyé : vendredi 21 septembre 2012 15:04
>=> So why don't you talk about the radio interface? :)

Med: is this related to IPv6? ;-)

 It's 
>out of scope.

Med: This is not a reason to not include it in the update. 

>the definitions of should and must.

Med: I'm aware of the definitions. If we indicate all important features as MAY, then there is little chance to see the feature supported. 

>=> Again, I'm objecting to the level of support not the use case.

Med: From a SP standpoint, I do think this disserves a "SHOULD". It seems we disagree on the level of the requirement. I need to hear from other WG members on what exact word to use.

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 21 Sep 2012 23:34:00 +1000

>Med: This is not a reason to not include it in the update.

=> But you're not responding to the reasons I stated above. It's out of
scope because it's not defined in IETF.

>Med: I'm aware of the definitions. If we indicate all important features
>as MAY, then there is little chance to see the feature supported.

=> I wasn't commenting on "all important features" I'm talking about
specific requirements. Please respond to the comment without generalising
it to something I didn't say.

Hesham

---

From: <[email-masked]>
Date: Fri, 21 Sep 2012 15:47:56 +0200

Re-,

Please see inline. 

Cheers,
Med 

>Envoyé : vendredi 21 septembre 2012 15:34

Med: Should we care about frontiers between SDOs when the goal is to ensure interoperability? IMHO, we should not. What we want to achieve with this document is to list a basic set of IPv6 requirements for cellular hosts no matter if the requirement is defined in IETF or 3GPP. 
My current take is: it is useful to have in one common place both IETF and non-IETF REQs. I see you don't agree with this position. 
This is still an individual submission. If the WG adopts this work, then we will record whatever the WG wants us to do: If the consensus is to drop those 3GPP-related requirements, then we will do it.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Sep 2012 13:56:26 +0000

On Sep 21, 2012, at 9:19 AM, Hesham Soliman <[email-masked]> wrote:
> And has there been on consensus on that mechanism? Because if there is

It would be inappropriate for the v6ops working group to pick a winner.   We are just supposed to talk about operations.   In that context, saying "you probably ought to support DNS64" is meaningful advice, because a device that doesn't support it isn't going to be able to do DNSSEC.   This would rule out an entire transition technology, or else rule out DNSSEC.

The situation is similar for other recommendations this document makes.   Can you maybe offer some motivation for your resistance to these requirements other than "this is too strong"?

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 21 Sep 2012 09:54:42 -0500

Hi Med,

Please kindly see inline.

Regards,

Behcet

On Fri, Sep 21, 2012 at 2:37 AM,  <[email-masked]> wrote:
> [Med] We didn't considered it because there are some assumptions to be made:
> e.g., do we expect all interfaces are connected to networks managed by the
> same administrative entity? How to manage conflicts if distinct policies are
> sent? etc.
>

I support Lorenzo on this. I think that RFC 4191 should be considered.
We have a draft on improving RFC 4191 which will make it more relevant
to UEs:

http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01

> [Med] RFC4389 is the best reference we can quote at this stage. Do you have
> a pointer to an I-D where these issues are discussed? We can add a pointer
> to that I-D.
>
> [Med] We didn't done that analysis as we are considering also scenarios for
> fixed-mobile convergence where a CPE can be connected to a fixed network by
> default and in case of failure switch to the 3GPP network or scenario.

I am confused about this fmc scenario.
When the device is connected to a fixed network, it does not need to
be CE router because in the fixed network there is already a CE
router.

What you are considering is a complicated scenario where the device
(UE) was CE router (because some IPv4-IPv6 transition technology
required it) and then it connects to a fixed network.

I am not sure if we should consider such scenarios. All I can say that
in fmc, UE needs to be UE not a CE router.

---

From: <[email-masked]>
Date: Fri, 21 Sep 2012 17:07:31 +0200

Hi Behcet,

Please see inline. 

Cheers,
Med 

>De : Behcet Sarikaya [mailto:[email-masked]] 
>Envoyé : vendredi 21 septembre 2012 16:55
>> Objet : Re: [v6ops] 
>draft-binet-v6ops-cellular-host-reqs-rfc3316update
>>

Med: I added a REQ for 4191 as indicated here: http://www.ietf.org/mail-archive/web/v6ops/current/msg14349.html. 

>I don't think
>stage. Do you have
>> 3. REQ#32 says the device must also be an RFC-6204 compliant 
>IPv6 CE router.
>> Are there no conflicts?

Med: I'm referring to a CPE which can be connected to cellular network on purpose.

>in fmc, UE needs to be UE not a CE router.

Med: As you know, the notion of FMC is too vague. Applogies if I used that term which induced confusion. The scenario I was describing is: a CPE can connect to both fixed and wirelss network based on the some criteria (failure, offload via mobile or fixed, etc.).

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 22 Sep 2012 11:01:26 +1000

>It would be inappropriate for the v6ops working group to pick a winner.
>We are just supposed to talk about operations.   In that context, saying
>"you probably ought to support DNS64" is meaningful advice, because a
>device that doesn't support it isn't going to be able to do DNSSEC.
>This would rule out an entire transition technology, or else rule out
>DNSSEC.
>
>The situation is similar for other recommendations this document makes.
>Can you maybe offer some motivation for your resistance to these
>requirements other than "this is too strong"?

=> My point is that we're effectively picking a winner. I didn't see any
discussion before about which mechanisms would be recommended and suddenly
we're saying CLAT is effectively a must implement in devices. The
consequences if this are grave and that's why we need to have consensus on
one or two approaches that would be recommended. If you think this WG
can't pick a winner then let BEHAVE do it with IPv6 for example. The
outcome of this draft should be a couple of mechanisms at most. So there
needs to be a discussion about what those are with 3GPP as well.

My argument doesn't boil down to "this is too strong" as you put it. It
boils down to "where is the consensus on chosen mechanisms?" where is the
discussion with other WGs and 3GPP? This needs to happen as it happened
with similar RFCs in the past like 3314, 3316 or 3574.

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 22 Sep 2012 11:05:22 +1000

>Med: Should we care about frontiers between SDOs when the goal is to
>ensure interoperability? IMHO, we should not.

=> Huh? Of course we should. This is _how_ you ensure interoperability by
telling people where to read the relevant specs for their implementation!
If you decide one algorithm here for PDP type selection and 3GPP decides
on another, what then?
So, best to avoid decisions for documents that you don't own. It's a
straight forward thing. What motivation do you have for putting this in an
IETF spec? 

>What we want to achieve with this document is to list a basic set of IPv6
>requirements for cellular hosts no matter if the requirement is defined
>in IETF or 3GPP.
> 
>My current take is: it is useful to have in one common place both IETF
>and non-IETF REQs. I see you don't agree with this position.
>This is still an individual submission. If the WG adopts this work, then
>we will record whatever the WG wants us to do: If the consensus is to
>drop those 3GPP-related requirements, then we will do it.

=> Sure, I'm assuming that you want it to be a WG draft and RFC later,
hence this is part of the consensus to accept it as a WG draft.

Hesham

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 22 Sep 2012 14:19:47 +0000

Med,

In the xlat document review it has been discussed numerous times that ND Proxy is an Experimental RFC and the Experimental tag is enough to disqualify the RFC as a reference in an Information document.   Other details have also been provided as to why the ND Proxy document is Experimental!  See

http://www.ietf.org/mail-archive/web/v6ops/current/msg13904.html

Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, September 21, 2012 3:37 AM
To: Lorenzo Colitti
Cc: IPv6 Ops WG
Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update

---

From: <[email-masked]>
Date: Mon, 24 Sep 2012 07:57:57 +0200

Dear Hesham,

Which alternative(s) to CLAT you are referring to? 

Thanks. 

Cheers,
Med 

>De : [email-masked] [mailto:[email-masked]] De 
>la part de Hesham Soliman
>Envoyé : samedi 22 septembre 2012 03:01
>À : Ted Lemon; IPv6 Ops WG

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 24 Sep 2012 16:09:00 +1000

>Which alternative(s) to CLAT you are referring to?

=> I don't think I suggested alternatives to CLAT specifically, can't see
that in the email quoted anyway.
I was questioning the wisdom/concensus/debate/ that went on before those
mechanisms were selected. I didn't see any discussion, especially in other
WGs who own those docs. As to alternatives to CLAT specifically I don't
really care what they are, I don't like the approach being taken to create
requirements on cellular hosts without any serious debate or IETF/3GPP
consensus behind it.

Hesham

---

From: <[email-masked]>
Date: Mon, 24 Sep 2012 10:42:58 +0200

Dear Hesham,

Some answer below
BR
David

> De : [email-masked] [mailto:[email-masked]] 
> De la part de Hesham Soliman
> Envoyé : lundi 24 septembre 2012 08:09
> À : BOUCADAIR Mohamed OLNC/NAD/TIP; Ted Lemon; IPv6 Ops WG
> => I don't think I suggested alternatives to CLAT 
> specifically, can't see that in the email quoted anyway.
> I was questioning the wisdom/concensus/debate/ that went on 
> before those mechanisms were selected. I didn't see any 
> discussion, especially in other WGs who own those docs. As to 
> alternatives to CLAT specifically I don't really care what 
> they are, I don't like the approach being taken to create 
> requirements on cellular hosts without any serious debate or 
> IETF/3GPP consensus behind it.

Actually, you are right that there is a lack of IETF/3GPP debate about requirements on cellular hosts. 
The goal of this draft is to instantiate this debate and to get an updated RFC about IPv6 cellular hosts profile. 
Regarding CLAT support, we are thinking it could be a solution to ensure that IPv4 communications can still be enabled when some IPv6 only connectivity is provided to the UE. We want to tackle IPv4 service continuity requirement while some IPv6 connectivity is set up and we are open to alternative solutions if any. 

> >>De : [email-masked] [mailto:[email-masked]] 
> De la part 
> >>de Hesham Soliman Envoyé : samedi 22 septembre 2012 03:01 À : Ted 
> >>Lemon; IPv6 Ops WG Objet : Re: [v6ops] 
> >>>On Sep 21, 2012, at 9:19 AM, Hesham Soliman 
> >>><[email-masked]>
> >>>wrote:
> >>=> My point is that we're effectively picking a winner. I 
> didn't see 
> >>any discussion before about which mechanisms would be 
> recommended and 
> >>suddenly we're saying CLAT is effectively a must implement 
> in devices. 
> >>The consequences if this are grave and that's why we need to have 
> >>consensus on one or two approaches that would be 
> recommended. If you 
> >>think this WG can't pick a winner then let BEHAVE do it 
> with IPv6 for 
> >>example. The outcome of this draft should be a couple of 
> mechanisms at 
> >>most. So there needs to be a discussion about what those 
> are with 3GPP 
> >>as well.
> >>
> >>My argument doesn't boil down to "this is too strong" as 
> you put it. 
> >>It boils down to "where is the consensus on chosen mechanisms?"
> >>where is the
> >>discussion with other WGs and 3GPP? This needs to happen as it 
> >>happened with similar RFCs in the past like 3314, 3316 or 3574.
> >>
> >>Hesham
> >>
> >>>
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Mon, 24 Sep 2012 13:27:22 +0200

Hi Hemant,

Please see inline
David
________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Hemant Singh (shemant)
Envoyé : samedi 22 septembre 2012 16:20
À : BOUCADAIR Mohamed OLNC/NAD/TIP; Lorenzo Colitti
Cc : IPv6 Ops WG
Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update

Med,

[David]  ND proxy solution as specified in RFC4389 is not the best solution for such need but until Prefix Delegation solution can be deployed in SP networks.

Without such solution and before Prefix Delegation can be used, IPv6 only connectivity for cellular hosts with LAN interface is not possible.

We can add some text about limitations of such solution if it can help and recommend to deploy and use Prefix Delegation ASAP.

Hemant

---

From: <[email-masked]>
Date: Mon, 24 Sep 2012 15:12:56 +0200

Re-,

We submitted a new version of the I-D integrating the comments received in the list. In particular, the following changes are made in -02:

* DNS64 requirement is now a SHOULD as suggested by Ted
* Add a new requirement to RFC5555 as suggested by H. Soliman
* Remove the requirement about ND Proxy but instead a new paragraph has been added to describe the problem raised to share /64
* Add a new requirement for RFC4191 as suggested by L. Colliti, Behcet and Jouni
* Correct a typo about DHCP client (3315).
* Welcome new co-authors

A detailed diff is available at: http://www.ietf.org/rfcdiff?url2=draft-binet-v6ops-cellular-host-reqs-rfc3316update-02

The new version is available at: http://tools.ietf.org/id/draft-binet-v6ops-cellular-host-reqs-rfc3316update-02.txt

Cheers,
Med

---

From: MAWATARI Masataka <[email-masked]>
Date: Tue, 25 Sep 2012 13:39:00 +0900

Dear authors,

I read throuth your draft.

Comment about REQ#6 and REQ#7 on -02 version regarding conveying
DNS server.

I heard that both of DHCPv6 client and RA options is not common on
3GPP mobile network at least for now.
This document describes that if RA options is not supported, the
cellular host should embed DHCPv6 client.  Will RA options have
more appreciated than DHCPv6 client on mobile?  However, both
requirements have same SHOULD.

Such a document should provide the clear preference and reasons
about that, in my opinion.

Kind Regards,
Masataka MAWATARI

* On Mon, 24 Sep 2012 15:12:56 +0200

---

From: jouni korhonen <[email-masked]>
Date: Tue, 25 Sep 2012 11:04:03 +0300

> 3GPP mobile network at least for now.

Specific to 3GPP, its "NAS" layer can deliver the mobile the DNS server
address among several other configuration things. Since NAS is in 3GPP's
hands it somehow gets preferred.. Currently as for Release-11 DHCPv6 is
still optional and RDNS is not there at all.

> about that, in my opinion.

The preference ordering is in the text already in a way in req#7 it
seems but could be more clear/strict.

- Jouni

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 25 Sep 2012 11:53:13 +0000

Jouni,

Trying to make sense of 3GPP's thought process here -  

* rel 10 includes DHCPv6 for PD, rel 11 keeps DHCPv6 (for NA!) optional.

* SLAAC is included (rel 8 onwards!), but complimentary RDNS stays excluded.

I guess 'simplification' is very subjective. ;-)

Cheers,
Rajiv

Sent from my Phone

---

From: jouni korhonen <[email-masked]>
Date: Tue, 25 Sep 2012 19:05:31 +0300

Rajiv,

> Trying to make sense of 3GPP's thought process here -  

Is there any sense in it? 

> * SLAAC is included (rel 8 onwards!), but complimentary RDNS stays excluded.

SLAAC has been there since like rel-99.

> I guess 'simplification' is very subjective. ;-)

;)

- Jouni

---

From: <[email-masked]>
Date: Thu, 27 Sep 2012 08:04:04 +0200

Dear Masataka, Jouni,

Please see inline. 

Cheers,
Med 

>Envoyé : mardi 25 septembre 2012 10:04
>À : MAWATARI Masataka
>Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]

Med: The new text for REQ#7 is:

   REQ#7: The cellular host SHOULD embed a DHCPv6 client [RFC3736]

                 If [RFC6106] is not supported, the cellular host SHOULD
                 retrieve DNS information using stateless DHCPv6
                 [RFC3736].

                 If the cellular host receives the DNS information in
                 several channels, the following preference order MUST
                 be followed:
                 1.     PCO
                 2.     RA
                 3.     DHCPv6

>>> We submitted a new version of the I-D integrating the 
>comments received in the list. In particular, the following 
>changes are made in -02:
>>> 
>>> * Remove the requirement about ND Proxy but instead a new 
>paragraph has been added to describe the problem raised to share /64
>>> A detailed diff is available at: 
>http://www.ietf.org/rfcdiff?url2=draft-binet-v6ops-cellular-hos
>t-reqs-rfc3316update-02
>>> 
>>> The new version is available at: 
>http://tools.ietf.org/id/draft-binet-v6ops-cellular-host-reqs-r
>fc3316update-02.txt
>>> 
>>> Cheers,
>>> Med
>>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 27 Sep 2012 21:24:25 +0900

>                  several channels, the following preference order MUST

Why does this order need to be specified in this document?

---

From: <[email-masked]>
Date: Thu, 27 Sep 2012 14:38:49 +0200

Dear Lonezo,

As there are several channels which may be used to provision the dns info, we thought it is useful to provide a guideline for the host which information to select.

This modification is only added in my local copy. If you think this is not a good idea or it does not make senses, etc, your comment is welcome.

Cheers,
Med

________________________________
De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : jeudi 27 septembre 2012 14:24
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : jouni korhonen; MAWATARI Masataka; [email-masked]
Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update

On Thu, Sep 27, 2012 at 3:04 PM, <[email-masked]<mailto:[email-masked]>> wrote:
                 If the cellular host receives the DNS information in
                 several channels, the following preference order MUST
                 be followed:
                 1.     PCO
                 2.     RA
                 3.     DHCPv6

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 27 Sep 2012 13:37:44 +0000

I actually don't mind this being listed, given that it is bout

Cheers,
Rajiv

Sent from my Phone

On Sep 27, 2012, at 8:39 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Dear Lonezo,

Cheers,
Med

Cc : jouni korhonen; MAWATARI Masataka; [email-masked]<mailto:[email-masked]>

Why does this order need to be specified in this document?
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Anupam Kapoor <[email-masked]>
Date: Fri, 28 Sep 2012 12:05:38 +0530

,----[ mohamed.boucadair ]
| Review and comments are more than welcome.
`----
,----[ draft-binet-v6ops-cellular-host-reqs-rfc3316update ]
|    REQ#3:  The cellular host MUST comply with the behavior defined in
|       [TS.23060] and [TS.24008] in terms of requested PDP context type.
|       In particular the cellular host MUST request an IPv6 PDP context
|       if the cellular host is IPv6-only and requesting an IPv4v6 PDP
|       context if the cellular host is dual stack or when the cellular
|       host is not aware of connectivity types requested by devices
|       connected to it (e.g., cellular host with LAN capabilities):
| 
|       *  If the requested PDP context IPv4v6 is not supported but IPv4
|          and IPv6 PDP types are allowed, the cellular host is configured
|          with an IPv4 address or an IPv6 prefix.  It MAY initiate
|          another PDP request than the one already activated for a given
|          APN.
| 
|       *  If the requested PDP type and subscription data allows only one
|          IP address family (IPv4 or IPv6), the cellular host MUST NOT
|          request a second PDP context to the same APN for the other IP
|          address family.
`----
multiple pdn connections to the same apn is allowed from the same
ue. may you please explain the reasoning for the second item above ?

thank you
kind regards
anupam

---

From: <[email-masked]>
Date: Fri, 28 Sep 2012 09:18:40 +0200

Hi Anupam

The second item does not question the capability to establish multiple pdn connexions for a given apn but as far as IPv6 introduction is concerned, the cellular host must not request a new PDN connexion for the other version of IP protocol (let say IPv4 for example) if registration data mandates only one IP adress family (IPv6 for example) for this cellular host. 

David  

> De la part de Anupam Kapoor
> Envoyé : vendredi 28 septembre 2012 08:36
> multiple pdn connections to the same apn is allowed from the 
> same ue. may you please explain the reasoning for the second 
> item above ?
> 
> thank you
> kind regards
> anupam