Subject: [3gv6] FW: proposed 3gpp-ietf workshop

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Dec 2009 13:39:01 +0200

Jari Arkko wrote on the int-area list:
>
> Some time ago we talked about a possible meeting between the IETF and 
> the 3GPP. We now have more information about the goals of this 
> meeting, along with proposed logistics. The meeting would take place 
> in San Francisco, March 1-2, 2010. I realize that this is an 
> additional travel for some of us and within a month of the next IETF 
> meeting, but it is conveniently located for at least some of the 
> potential participants, as it happens after the 3GPP SA2 meeting which 
> is taking place also in San Francisco. Also, co-locating this meeting 
> with the IETF would not be easy, given the some other 3GPP meetings 
> happening at the same time, and due to lack of time in the IETF week 
> for an in-depth discussion of this topic. My recommendation is that we 
> take this opportunity to sit down with the 3GPP experts.
>
> Please comment both the content and other aspects by December 21st at 
> which time the ADs will make a final decision about this meeting. Are 
> these things what we want to achieve in the meeting? Is something 
> missing? Should we focus on some specific issues?
>
> Jari
>
> 3GPP-IETF WORKSHOP ON IPV6 IN CELLULAR NETWORKS
>
> The pool of remaining unallocated IPv4 address space is expected to be
> depleted in the coming years. At the same time new applications and
> connectivity options are multiplying the number of Internet users. For
> instance, billions of mobile phone users are expected to require IP
> connectivity in the coming years, either for traditional Internet
> services or the eventual move of circuit switched voice to IP.
>
> The lack of addresses will have many impacts in the short term. In the
> long term, the only viable model is to move to IPv6, as IPv6 allows a
> significantly larger number of devices to be addressed. Network
> operators and equipment vendors have been readying their systems to
> prepare for this. The pace of these preparations has picked up in recent
> year as the final end of IPv4 resources has become clearer. However,
> while IPv6 traffic is growing and there is widespread product support
> for IPv6, on a global scale IPv6 connectivity is still available only in
> a fraction of networks. Improving the situation requires time, effort,
> commercial incentives, and technology.
>
> The goal of this workshop is to allow experts from both 3GPP and IETF to
> discuss IPv6 deployment in the context of 3GPP cellular networks.
> Technology to provide IPv6 connectivity has existed for these networks
> for quite some time. 3GPP specifications dating back to late nineties
> provided the necessary standards to support standard dual stack
> operation, enabling both IPv4 and IPv6 connectivity. Most of the network
> components in the field today support this, and countless trials have
> been run. However, very few commercial deployments have turned IPv6 on
> to date. Part of the reason for this is that only a subset of terminals
> support IPv6, lack of need to do anything other than IPv4, and lack of
> content in the IPv6 Internet. However, these factors may now be changing
> with the increase in the number of users, the desire to run always-on
> and non-client & port hungry applications, and at least some content
> being available over IPv6.
>
> Nevertheless, as real-world deployments become closer, we are also
> starting to understand better what it takes to deploy IPv6. For
> instance, there is now a better understanding of what IPv6 deployment
> means in different contexts, be it the internal signaling network for
> the operators, user's communication with services offered by the
> operators, machine-to-machine networking, or IPv6 as a means to connect
> to various Internet services. The 3GPP is studying different scenarios
> for IPv6 deployment in the SA2 group. A draft report from this study
> will be available early next year. The assumption is that the existing
> 3GPP standards and dual stack operation are the cornerstones of the
> future deployments. However, it is known that at least some additional
> tools may be required on top of this. For instance, in some deployments
> it would be beneficial to employ prefix delegation, which is not a part
> of today's 3GPP standards.
>
> This workshop focuses on these scenarios and identifying possible areas
> where further specification work is required. The topics suitable for
> the meeting include:
>
> - Review of scenarios
> - Operational experience and state of the art
> - Gap analysis
> - Proposals for a work plan
>
> The workshop is a joint activity for both the IETF and the 3GPP. The
> workshop chairs are Fred Baker ([email-masked]) and Balazs Bertenyi
> ([email-masked]). The workshop chairs will develop a more
> detailed agenda. We expect the workshop to receive input from the SA2
> report (available January 29th, 2010) and from the community. We ask
> that the input on scenarios focuses on business needs that need to be
> supported, rather than detailed network designs or ask specific
> solutions. Input should be posted as Internet Drafts at
> http://www.ietf.org/id-info or 3GPP contributions at
> http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs
> The input should be available as soon as possible so that discussion can
> take place in the mailing list at
> https://www.ietf.org/mailman/listinfo/3gv6 The final input deadline is
> February 12th, 2010. The workshop chairs will send a follow-up with
> preliminary registration and document submission details.
>
> The workshop is expected validate and provide feedback on scenarios and
> produce a gap analysis and possible proposals for new work. In
> particular, the workshop should make a recommendation on what scenarios
> are common enough to require support from standards, and identify gaps
> that the current tool set has in supporting them. Note that the workshop
> is not a forum to create new IPv6 transition tools or the further
> development of existing ones. Working groups in the IETF are the right
> place for that. This workshop is also not the place to agree on specific
> changes to cellular network standards. Such changes are a topic for the
> 3GPP.  New work for either IETF or the 3GPP will be initiated through
> the usual processes.
>
> A report of the conclusions from the workshop will be posted as an
> Internet Draft. The draft will also be available at
> http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Report
>
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 17 Dec 2009 07:32:59 -0800 (PST)

Hi all,

Jari Arkko wrote:
>> However, it is known that at least some additional

I submitted a draft 
http://tools.ietf.org/id/draft-sarikaya-int-area-prefix-delegation-00.txt

which is about stateful prefix delegation in the hopes of helping cellular networks' transition to IPv6.

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 17 Dec 2009 14:44:24 -0800 (PST)

Hi Teemu,
  
  I hope you don't mind discussing on the list.

It seems you misunderstood the draft. DHCP PD is run between PDN Gateway as AR and DHCP server. When UE attaches, AR makes a prefix request and gets one or more /64s. 

Different address configuration techniques can be supported, in the draft we mentioned SLAAC. 

Regards,

Behcet

----- Original Message ----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Sent: Thu, December 17, 2009 2:54:38 PM
> Subject: RE: [3gv6] prefix delegation draft was: proposed 3gpp-ietf workshop
> 
> Hi,
> 
> I don't quite get how the UE gets shorter than /64 with what you describe, or is 
> that even a purpose? I mean is this about prefix delegation to access router, or 
> to cellular host, or both?
> 
> As the 23.401 does not currently support DHCPv6 based address configuration for 
> the EPS bearer, is the intent of chapter 3.2 describe how the host can use 
> RFC3633 to ask for prefix delegation after conducting SLAAC as defined in 
> 23.401? Or is intent to propose addition of DHCPv6 based address configuration 
> for the EPS bearer?
> 
> Thanks,
> 
> Teemu
> 
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]] On Behalf Of
> >ext Behcet Sarikaya
> >Sent: 17 December, 2009 17:33
> >To: [email-masked]
> >Subject: [3gv6] prefix delegation draft was: proposed 3gpp-ietf workshop
> >
> >Hi all,
> >
> >
> >
> >Jari Arkko wrote:
> >_______________________________________________
> >3gv6 mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/3gv6

---

From: Fred Baker <[email-masked]>
Date: Thu, 17 Dec 2009 15:01:08 -0800

Thanks. I have noted it in the agenda I'm collecting.

> http://tools.ietf.org/id/draft-sarikaya-int-area-prefix-delegation-00.txt

http://www.ipinc.net/IPv4.GIF

---

From: <[email-masked]>
Date: Fri, 18 Dec 2009 07:48:07 +0100

Hi Bechet,

This is fine as well. 

So DHCPv6 PD for PDN GWs being the point of the document, I'm now slightly afraid that people might be confusing these two discussions: delegating prefixes to PDN GW, and delegating prefxes to UE. Or perhaps they don't?

Then again, doesn't 3GPP specs support "prefix delegation to PDN GW" well enough already, after all, it's been there in products for years? Are there some gaps still or improvement needs?

The prefix delegation for UEs is definitely missing still.

Thank you,

Teemu
________________________________________
From: ext Behcet Sarikaya [[email-masked]]
Sent: Friday, December 18, 2009 12:44 AM
To: Savolainen Teemu (Nokia-D-MSW/Tampere)
Cc: [email-masked]
Subject: Re: [3gv6] prefix delegation draft was: proposed 3gpp-ietf workshop

Hi Teemu,

Regards,

Behcet

---

From: jouni korhonen <[email-masked]>
Date: Fri, 18 Dec 2009 14:43:59 +0200

Rel-8 3GPP specs support allocating prefixes from an external network to a PGW using DHCPv6 or AAA. However, this is not e.g. RFC3633 prefix delegation per se. Both AAA and DHCP based prefix assignment signaling till today is per mobile. However, using shorter prefix than /64 is not really prohibited (at least when using AAA)..

Cheers,
	Jouni

---

From: <[email-masked]>
Date: Fri, 18 Dec 2009 14:58:23 +0100

Hello,

This document deals also with some MN stateful configuration in section 3.2 at least. 
But actually, addressing architecture issues may be discussed during next IETF-3GPP workshop, at least to be sure current IETF and 3GPP specifications fullfil current and future needs.
IMHO how prefixes are delegated to PDN GW in various situations, roaming and mobility included, is a first issue. 
Some questions related to MN's addressing solutions is a second one: for example, How the address/prefix is allocated to the MN ? Is there a need for some various prefix sizes and under which conditions ?...
I also think that some prefix delegation for UE is required and several means may be envisaged: stateful addressing with DHPC or PCO-IE, stateless addressing.

David

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De 
> la part de [email-masked]
> Envoyé : vendredi 18 décembre 2009 07:48
> À : [email-masked]
> Cc : [email-masked]
> Objet : Re: [3gv6] prefix delegation draft was: proposed 
> 3gpp-ietf workshop
> 
> Hi Bechet,
> 
> This is fine as well. 
> 
> So DHCPv6 PD for PDN GWs being the point of the document, I'm 
> now slightly afraid that people might be confusing these two 
> discussions: delegating prefixes to PDN GW, and delegating 
> prefxes to UE. Or perhaps they don't?
> 
> Then again, doesn't 3GPP specs support "prefix delegation to 
> PDN GW" well enough already, after all, it's been there in 
> products for years? Are there some gaps still or improvement needs?
> 
> It seems you misunderstood the draft. DHCP PD is run between 
> PDN Gateway as AR and DHCP server. When UE attaches, AR makes 
> a prefix request and gets one or more /64s.
> 
> > I don't quite get how the UE gets shorter than /64 with what you 
> > describe, or is that even a purpose? I mean is this about prefix 
> > delegation to access router, or to cellular host, or both?
> >
> > As the 23.401 does not currently support DHCPv6 based address 
> > configuration for the EPS bearer, is the intent of chapter 3.2 
> > describe how the host can use
> > RFC3633 to ask for prefix delegation after conducting SLAAC 
> as defined 
> > in 23.401? Or is intent to propose addition of DHCPv6 based address 
> > configuration for the EPS bearer?
> >
> > Thanks,
> >
> > Teemu
> >
> > >From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > >Of ext Behcet Sarikaya
> > >> > it would be beneficial to employ prefix delegation, 
> which is not 
> > >> > a
> > >part
*********************************
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: Behcet Sarikaya <[email-masked]>
Date: Fri, 18 Dec 2009 07:40:22 -0800 (PST)

Hello,

----- Original Message ----
> From: "[email-masked]" <[email-masked]>
> To: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Fri, December 18, 2009 7:58:23 AM
> But actually, addressing architecture issues may be discussed during next 
> IETF-3GPP workshop, at least to be sure current IETF and 3GPP specifications 
> fullfil current and future needs.
> Some questions related to MN's addressing solutions is a second one: for 
> example, How the address/prefix is allocated to the MN ? Is there a need for 
> some various prefix sizes and under which conditions ?...

> I also think that some prefix delegation for UE is required 

The prefix delegation draft we are talking about is on prefix delegation for UE, AR gets prefixes for each UE that is attached and releases them when they handoff.

Maybe you mean prefix delegation by UE where UE becomes the requesting router (RR)? I think this is where Teemu is getting into.

In that area we do have some solutions in Mext WG for Network Mobility (Nemo) in the context of Mobile IPv6. Nemo MR does DHCP PD to get mobile network prefixes for the hosts that it is serving as router. 

Teemu's draft doesn't require a mobility protocol so it is for Simple IP and does stateless prefix allocation. 

Such a technique gives address configuration control to UE which might raise a lot of eyebrows :).

> and several means 
> may be envisaged: stateful addressing with DHPC 

With Nemo, please see draft-ietf-mext-nemo-pd. 

>or PCO-IE, stateless addressing.
> 

Regards,

Behcet

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 18 Dec 2009 08:41:48 -0800

Hello David,

[email-masked] wrote:
> But actually, addressing architecture issues may be discussed during
> next IETF-3GPP workshop, at least to be sure current IETF and 3GPP
> specifications fullfil current and future needs.
> IMHO how prefixes are delegated to PDN GW in various situations,
> roaming and mobility included, is a first issue.
> Some questions related to MN's addressing solutions is a second one:
> for example, How the address/prefix is allocated to the MN ? Is there a
> need for some various prefix sizes and under which conditions ?...
> I also think that some prefix delegation for UE is required and several
> means may be envisaged: stateful addressing with DHPC or PCO-IE,
> stateless addressing.

There's no such thing as stateless prefix delegation. 

Prefix delegation is necessarily stateful.

As to which signaling is used, since 3GPP relies entirely on IETF standard track mechanisms (DHCPv6 and IPv6 SLAAC) for IPv6 configuration matters, the use of a PCO for IPv6 prefix delegation is IMHO not an option. 

So we're left with DHCPv6 Prefix Delegation, and so far I haven't seen a convincing argument about its shortcomings. (for example, it allows delegation of prefixes of various sizes -- as requested by the UE depending on its needs and as per operator policy -- under any condition) 

Best,

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 18 Dec 2009 10:01:16 -0800

Hello Teemu,

[email-masked] wrote
> 
> Hi Julien,
> 
> 6RD calls similar functionality:" include automatic IPv6 prefix
> delegation to sites, stateless operation, simple provisioning..." So
> does your comment apply to that technology as well? If not, why not?

IMHO it applies. 6RD prefix delegation is an automatic stateful process that happens as a result of stateful IPv4 address allocation.
 
> I wonder if you have better name for this kind of prefix delegation? I
> mean a name that would better describe what the proposals do.
> "Implicit" might be a step to better direction, but its not fully
> implicit either as UE needs to find out the ISP prefix etc. "Static"
> does not sound good, as its not that static but e.g. bound to IPv4
> address as in 6RD...

I kind of like the "automatic" qualifier used in the text you quoted.

Best,

--julien

---

From: <[email-masked]>
Date: Sat, 19 Dec 2009 16:54:40 +0100

Hello,

Both needs have to be satisfied: in one case, how the AR retrieves prefixes and how the UE is configured with this prefixes. We may envisage that some DHCP prefix delegation with AR used as a DHCP relay may be used, even if mobility are not strictly required.
It seems that you distinguish some architectures where UE may have some "routing" functions and other ones, without such advanced functions. Can we consider to have only one architecture, whatever the type of terminals, allowing some various lengths prefixes allocation according the needs or the type of terminal.
Actually I do not see the real need of some"automatic prefix configuration" behind the UE when we may envisage some /60 prefix allocation to the UE for example.  

Best Regards
David 
________________________________________
De : Behcet Sarikaya [[email-masked]]
Date d'envoi : vendredi 18 décembre 2009 16:40
À : BINET David NCPI/NAD/TIP; [email-masked]
Cc : [email-masked]
Objet : Re: [3gv6] prefix delegation draft was: proposed 3gpp-ietf workshop

Hello,

----- Original Message ----

Regards,

Behcet

---

From: <[email-masked]>
Date: Sat, 19 Dec 2009 17:03:16 +0100

Hello Julien, 

Regarding stateless prefix delegation, maybe we can envisage some ND use and if required with some ND proxy functions if required. 
I agree that stateful prefix delegation is certainly a preferred solution.
As far as terminal vendors will embed some DHCPv6 functions with some ways to identify various terminals and network equipment inserts some DHCP relay functions , I agree with you that it is certainly the right solution to recommend for IPv6 integration.

Best regards
David
________________________________________
De : Laganier, Julien [[email-masked]]
Date d'envoi : vendredi 18 décembre 2009 17:41
À : BINET David NCPI/NAD/TIP; [email-masked]; [email-masked]
Cc : [email-masked]
Objet : RE: [3gv6] prefix delegation draft was: proposed 3gpp-ietf workshop

Hello David,

Best,

--julien

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 19 Dec 2009 09:54:50 -0800

FWIW, i like the idea of the UE acting as an L3 IPv6 node as well as
L2 bridge for any attached devices

> As far as terminal vendors will embed some DHCPv6 functions with some ways to identify various terminals and network equipment inserts some DHCP relay functions , I agree with you that it is certai…

FWIW, i like the idea of the UE acting as an L3 IPv6 node as well as
L2 bridge for any attached devices, this easily ties the user account
to one EPS bearer / PDP.   Then again, i don't like this /64 per EPS
bearer / PDP idea anyhow.  I think that is a legacy concept that may
need to be re-evaluated.  2^64 is more addresses than any GGSN / PGW
can handle.  It seems natural to me. IMHO,  that an APN instance on a
GGSN / PGW would be assigned a /64, not per bearer.