Subject: Re: [dhcwg] [3gv6] about Prefix delegation in 3GPP EPC networks

From: <[email-masked]>
Date: Thu, 8 Apr 2010 21:03:15 +0200

Hi,

I believe network sharing cannot be blocked without full control of the UE, as e.g. for current phones you can download applications that implement IPv4 NAT for connection sharing. Such applications could as well implement IPv6 NAT.

Making, by policy, IPv6 addresses a locally scarce resource will likely lead to adoption of IPv4 tools to IPv6 domain.

Wouldn't it be better instead to charge for excess traffic volumes/faster bandwidth/better QoS than make people's life hard by artificially limiting available addresses needed for numbering?

Best regards,

Teemu

----- Original message -----
> Hi, Teemu,
>
> I am afraid the shortest prefix length that a UE can request has to be
> added to the subscription data. Thus we can apply appropriate charging
> policy to the UE requesting shorter prefix. In this way, network sharing
> abusing can be avoided. If you want network sharing, you have to pay
> more.
>
> Best Regards,
> --------------------------------------------------------------------------------
> Zhenqiang Li
> 13911635816
> Department of Network Technology
> China Mobile Research Institute
> 2010-04-08
>
> --------------------------------------------------------------------------------
>
> 发件人： [email-masked]<mailto:[email-masked]>
> 发送时间： 2010-04-02 00:47:34
> 收件人： [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> 抄送： [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> 主题： Re: [3gv6] about Prefix delegation in 3GPP EPC networks
>
> Hi all,
>
> The prefix delegation needs to be available for standard subscriptions..
> Or else people having standard subscriptions will have to manage with ND
> proxy. There is no need for separate subscription in order to run NAT44
> on UE, right? So there should be no need for special subscription in
> IPv6 cellular router case either, right?
>
> Separate APN could be supported with standard subscriptions as well; UEs
> can have multiple parallel PDN connections.
>
> To conserve, maybe the usual "Internet APN" could have longer prefix,
> like /60 or so, and shorter like /48 would require something special?
>
> If prefix delegation is made completely as premium service, I could bet
> other mechanisms for network sharing will prevail..
>
> Best regards,
>
> Teemu
>
>
> ----- Original message -----
> > Hi Zhenqiang,
> >
> >
> > >
> > > Using different APN for different prefix length is not practical.
> > > Usually, We do not set too many APNs in the field network. It is
> not
> > > convenient for the UE to change one APN to another if it wants a
> > > different length prefix. Usually, differnt APN is set for different
> > > service.  UEs connected to the same APN may want to get different
> > > length prefixes due to differnt networks behind them.
> >
> >
> > ...FB: Could you detail the deployment scenario a bit more? From what
> > I've heard so far, the expectation is that subscriptions which will
> use
> > shorter/multiple prefixes will be different from the typical service
> > subscription of a mobile-phone user, e.g. those subscriptions would
> be
> > broadband-home-router type devices using LTE to connect to the
> network.
> > Hence the approach of using different APNs. You obviously have a
> > different deployment model in mind.
> >
> > Appreciate your thoughts.
> >
> > Thanks, Frank
> >
> > >
> > >
> > >
> > >
> >
> -----------------------------------------------------------------------
> > > ---------
> > >
> > > Zhenqiang Li
> > > 13911635816
> > > Department of Network Technology
> > > China Mobile Research Institute
> > > 2010-04-01
> > >
> > >
> >
> -----------------------------------------------------------------------
> > > ---------
> > >
> > > 发件人： Frank Brockners (fbrockne)
> > > 发送时间： 2010-03-30 15:50:07
> > > 收件人： [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> > > 抄送： [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> > Dhananjay
> > > Patki (dhpatki)
> > > 主题： RE: [3gv6] about Prefix delegation in 3GPP EPC networks
> > >
> > > Hi Zhenqiang Li,
> > >
> > > please see some thoughts inline.. (Suresh will probably add more)
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On
> Behalf
> > > Of
> > > > [email-masked]<mailto:[email-masked]>
> > > > Subject: [3gv6] about Prefix delegation in 3GPP EPC networks
> > > >
> > > > Dear Suresh,
> > > >
> > > > Nice meeting you at IETF 77.
> > > >
> > > > First of all, I agree with you that it is good for a UE to use a
> > > > shorter prefix to meet the situation, rather than using
> multiple /64
> > > > prefixes.
> > >
> > > ...FB: there's been several discussions at this past IETF on this
> > > particular topic - and the approach which seems to have wide
> support
> > is
> > > that for Release 10, one would support a model where one PDN
> > connection
> > > would continue to be represented by a *single* prefix. This prefix
> > > could
> > > be shorter that /64. This means that we can still hand out multiple
> > > prefixes to the UE, but it would always be possible to aggregate
> all
> > of
> > > them into a single prefix. We'd continue using SLAAC for assigning
> the
> > > /64 for the UE (or better PDN-Connection-link) and would hand out
> the
> > > remainder of the "shorter prefix" using DHCP PD. This will keep
> > changes
> > > to the current architecture to a minimum (incl. PCC will need to
> deal
> > > with only a single prefix in its rules). More complex alternatives
> > > would
> > > be explored in future releases (i.e. Release 11 and onwards).
> > >
> > > I'm working on updating the contributions S2-101176, S2-101177,
> > > S2-101178 that were submitted "for information" to the last 3GPP
> SA2
> > > meeting to reflect these changes (which are only small deltas to
> the
> > > current versions, so hope to have them available for discussion in
> the
> > > next few days) (You can find the submitted version at
> > >
> http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_78_San_Francisco/Docs/)
> > >
> > > >
> > > > Some additional comments about your draft:
> > > > 1. Where to store the prefix length that you reserved for each
> UE?
> > > > 2. How to validate the request from UE to avoid address abusing?
> > >
> > > ...FB: The expected approach is that shorter prefixes would be
> handled
> > > as a capability of the APN. This way you also won't have any issues
> > > with
> > > "abuse" - each UE (for a particular APN supporting shorter
> prefixes)
> > > could use DHCPv6 PD to request portions of the prefix.
> > >
> > >
> > > > 3. The proposed method in your draft seems address wasting,
> because
> > > you
> > > > reserve /x (x  < 64) prefix for each UE. It is better to store
> the
> > > > minimum length that a UE can apply, and assign the proper lengh
> to
> > UE
> > > > based on the available adrress pool, the minimum length the UE
> can
> > > > apply, and the length the UE actually requests.
> > >
> > > ...FB: If we do things on a per APN basis (as mentioned above), one
> > > would expect that only those UEs who need shorter prefixes would
> use
> > > the
> > > particular APN, so the amount of "wasted" addresses would be
> > relatively
> > > small. That said, the approach would just be for Release 10 (we
> just
> > > have two more meetings to get this off the ground) - more optimal
> > > approaches could be studied in future releases.
> > >
> > > Regards, Frank
> > >
> > > > 4. Are there any other alternatives besides DHCPv6-PD? I listed
> some
> > > > potential solutions in a 3GPP document. What is your opinion to
> > them?
> > > >
> > > > Best Regards,
> > > > Zhenqiang Li
> > > > 13911635816
> > > > Department of Network Technology
> > > > China Mobile Research Institute
> > > > 2010-03-26
> > > > _______________________________________________
> > > > 3gv6 mailing list
> > > > [email-masked]<mailto:[email-masked]>
> > > > https://www.ietf.org/mailman/listinfo/3gv6
> > _______________________________________________
> > 3gv6 mailing list
> > [email-masked]<mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/3gv6
> >

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Apr 2010 15:49:57 -0400

> Wouldn't it be better instead to charge for excess traffic volumes/faster bandwidth/better QoS than make people's life hard by artificially limiting available addresses needed for numbering? 

Yes, it would.   In addition to the objection you raised, which by itself would be sufficient, using shorter prefixes breaks things like CGA, and hence is exceedingly undesirable.

---

From: <[email-masked]>
Date: Fri, 9 Apr 2010 15:08:36 +0200

Hi,

I agree with Teemu. I am not sure there should be some direct relationship between prefix size and charging. People with only UE may use more bandwidth than people with some LAN.
It may be the case in some cases but I do not think it is a must. The most important issue is to find some way to dynamically allocate the right prefix size according the UE or maybe the services a consumer may want to use. From an addressing point of view, I do not think it is a good way to allocate or "reserve" some shorter prefixes than /64 for all UEs given the fact that some UEs may not require such prefixes. A first step could consist in identifying dongles, handsets, boxes, sensors..but it may be not enough in the future.

David

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : jeudi 8 avril 2010 21:03
À : [email-masked]; [email-masked]; [email-masked]
Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [dhcwg] [3gv6] about Prefix delegation in 3GPP EPC networks

Hi,

Best regards,

Teemu

----- Original message -----
> abusing can be avoided. If you want network sharing, you have to pay

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 12 Apr 2010 19:46:02 -0400

Hi Teemu,

On 10-04-08 03:03 PM, [email-masked] wrote:
> Hi,
> 
> I believe network sharing cannot be blocked without full control of the 
> UE, as e.g. for current phones you can download applications that 
> implement IPv4 NAT for connection sharing. Such applications could as 
> well implement IPv6 NAT.
> 
> Making, by policy, IPv6 addresses a locally scarce resource will likely 
> lead to adoption of IPv4 tools to IPv6 domain.

Fully agree. This is one of the motivations of moving to IPv6. If we 
give this up, we might as well stick to IPv4 NAT.

> 
> Wouldn't it be better instead to charge for excess traffic 
> volumes/faster bandwidth/better QoS than make people's life hard by 
> artificially limiting available addresses needed for numbering?

Again, fully agree.

Cheers
Suresh

---

From: jouni korhonen <[email-masked]>
Date: Tue, 13 Apr 2010 09:38:02 +0300

Fully agree with Teemu and if possible we should avoid running into those traps by all means.

- JOuni

On Apr 8, 2010, at 10:03 PM, <[email-masked]> <[email-masked]> wrote:

> > 发件人： [email-masked] 
> > 收件人： [email-masked]; [email-masked]; 
> > [email-masked] 
> > 抄送： [email-masked]; [email-masked]; [email-masked]; 
> > [email-masked] 
> > > > 收件人： [email-masked]; [email-masked] 
> > > > 抄送： [email-masked]; [email-masked]; [email-masked]; 
> > > Dhananjay 
> > > > Patki (dhpatki) 
> > > > > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf 
> > > > Of 
> > > > > [email-masked] 
> > > > > [email-masked] 
> > > [email-masked] 
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg