Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-03.txt

From: [email-masked]
Date: Wed, 20 Feb 2013 15:22:10 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN
	Author(s)       : Cameron Byrne
                          Dan Drown
                          Ales Vizdal
	Filename        : draft-ietf-v6ops-64share-03.txt
	Pages           : 8
	Date            : 2013-02-20

Abstract:
   This document describes three methods for extending an IPv6 /64
   prefix from a User Equipment 3GPP radio interface to a LAN.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-64share-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-64share-03

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

---

From: <[email-masked]>
Date: Thu, 21 Feb 2013 11:42:53 +0100

Hi all,

This document proposes some means to enable some prefix sharing when PD is not enabled or possible but I do not clearly understand how to "consider" the various scenarios. For example, we will have some smartphones, some CPEs and other type of devices that may require such /64 prefix sharing  capabilities and do we have to consider that these different devices should support one given scenario. 
I think it would be more efficient and more simple to only consider one scenario (for example the second one) to simplify relationships and requirements towards UE vendors as well as UEs behaviors considering that such capability should be a temporary solution.
If several LAN interfaces are enabled on the UE, could we consider that some different scenarios could be retained by these different LAN interfaces ? For example, if there is some Wi-Fi LAN and some bluetooth LAN, is there any requirement about the IPv6 address to be configured or not on these various LAN interfaces. 

David        

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> De la part de [email-masked]
> Envoyé : jeudi 21 février 2013 00:22
> À : [email-masked]
> Cc : [email-masked]
> Objet : [v6ops] I-D Action: draft-ietf-v6ops-64share-03.txt
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
> 
_________________________________________________________________________________________________________________________

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: Vízdal Aleš <[email-masked]>
Date: Thu, 21 Feb 2013 13:22:03 +0100

Hi David,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, February 21, 2013 11:43 AM
> To: [email-masked]
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-03.txt
> 
>  Hi all,
> 
> This document proposes some means to enable some prefix sharing when PD is not
> enabled or possible but I do not clearly understand how to "consider" the various
> scenarios. 

Scenarios shall be understood as options, so you can pick the one that fits the most
to your use-case.

> For example, we will have some smartphones, some CPEs and other type of
> devices that may require such /64 prefix sharing  capabilities and do we have to
> consider that these different devices should support one given scenario.

If your use-case requires stable GUA address on the 3GPP link to not to affect any 
running services you might go for scenario 3, for a tethering box scenario 1 & 2 could 
be more appropriate. 

> I think it would be more efficient and more simple to only consider one scenario (for
> example the second one) to simplify relationships and requirements towards UE vendors
> as well as UEs behaviors considering that such capability should be a temporary
> solution.

What's the issue with multiple options available to them, so they can pick and choose?

> If several LAN interfaces are enabled on the UE, could we consider that some different
> scenarios could be retained by these different LAN interfaces ? For example, if there is
> some Wi-Fi LAN and some bluetooth LAN, is there any requirement about the IPv6
> address to be configured or not on these various LAN interfaces.

If several LAN interfaces are required to be numbered than DHCP-PD shall be used. In such 
a case this draft can only help if the LAN interfaces will be i.e. bridged.

To my experience, the tethering function is usually bound to one LAN interface (USB, WLAN, ...)
and the home CPEs are usually bridging wired & wireless LAN interfaces.

> David

Cheers,
Ales

---

From: <[email-masked]>
Date: Thu, 21 Feb 2013 15:07:48 +0100

Hi Ales,

Some comments below 

Cheers
David

> >  Hi all,
> > 
> > This document proposes some means to enable some prefix 
> sharing when 
> > PD is not enabled or possible but I do not clearly 
> understand how to 
> > "consider" the various scenarios.
> 
> Scenarios shall be understood as options, so you can pick the 
> one that fits the most to your use-case.
Actually I can have a use case in mind and vendors may have other use cases. At the end they may provide some devices compliant with RFCxxx but that will not answer my needs. 
> 
> > For example, we will have some smartphones, some CPEs and 
> other type 
> > of devices that may require such /64 prefix sharing  
> capabilities and 
> > do we have to consider that these different devices should 
> support one given scenario.
> 
> If your use-case requires stable GUA address on the 3GPP link 
> to not to affect any running services you might go for 
> scenario 3, for a tethering box scenario 1 & 2 could be more 
> appropriate. 
I would prefer to get a solution that answer all kinds of requirements, including global connectivity for all devices that get their IP connectivity thanks to mobile networks, than some specific solutions for sub-not so much defined use cases. I have the feeling that we create some scenarios because of some specific implementation in some devices. I do no think we should care so much about specific devices characteristics. 
 
> 
> > I think it would be more efficient and more simple to only consider 
> > one scenario (for example the second one) to simplify relationships 
> > and requirements towards UE vendors as well as UEs behaviors 
> > considering that such capability should be a temporary solution.
> 
Multiple options in one reference document leads to some variety in implementations and some possible issues for service delivery. As far as this document details a temporary solution before PD is possible/enabled, I think it should be as simple as possible. 

> 
> > If several LAN interfaces are enabled on the UE, could we consider 
> > that some different scenarios could be retained by these 
> different LAN 
> > interfaces ? For example, if there is some Wi-Fi LAN and some 
> > bluetooth LAN, is there any requirement about the IPv6 
> If several LAN interfaces are required to be numbered than 
> DHCP-PD shall be used. In such a case this draft can only 
> help if the LAN interfaces will be i.e. bridged.
> 
> To my experience, the tethering function is usually bound to 
> one LAN interface (USB, WLAN, ...) and the home CPEs are 
> usually bridging wired & wireless LAN interfaces.
It could be useful to make it clear in the document to avoid any possible misunderstanding and configuration issues.

---

From: Vízdal Aleš <[email-masked]>
Date: Thu, 21 Feb 2013 16:28:08 +0100

Hi David,

thanks for your feedback and please see below.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, February 21, 2013 3:08 PM
> To: Vízdal Aleš; [email-masked]
> Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-64share-03.txt
> 
> Hi Ales,
> 
> Some comments below
> 
> Cheers
> David
>
> Actually I can have a use case in mind and vendors may have other use cases. At the
> end they may provide some devices compliant with RFCxxx but that will not answer my
> needs.

You still can point them to RFC section/chapter if you're after that.

> I would prefer to get a solution that answer all kinds of requirements, including global
> connectivity for all devices that get their IP connectivity thanks to mobile networks,
> than some specific solutions for sub-not so much defined use cases. I have the feeling
> that we create some scenarios because of some specific implementation in some
> devices. I do no think we should care so much about specific devices characteristics.

I am not sure if this draft shall be perceived as 'a solution', to me it is describing the way
how to extend a prefix from one interface to another. A solution would need to go
bit further.

> Multiple options in one reference document leads to some variety in implementations
> and some possible issues for service delivery. As far as this document details a
> temporary solution before PD is possible/enabled, I think it should be as simple as
> possible.

OK, do you see any issue with any of the options specified in the document?
If so, please point it out.
 
> It could be useful to make it clear in the document to avoid any possible
> misunderstanding and configuration issues.
 
OK.

Cheers,
Ales

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 21 Feb 2013 07:58:47 -0800

David,

I believe i understand your concerns, but the whole idea here is that
64share is a well known set of hacks that are needed until DHCP-PD is
available in 3GPP networks.  The document is only informational.

> Actually I can have a use case in mind and vendors may have other use cases. At the end they may provide some devices compliant with RFCxxx but that will not answer my needs.

As an individual submission i only cared about use-case #3, since it
best fits my primary needs and we have running open source code.

As a working group document, we included more scenarios to capture
other needs as well.

> I would prefer to get a solution that answer all kinds of requirements, including global connectivity for all devices that get their IP connectivity thanks to mobile networks, than some specific so…

This is not a standards creation document.  It is also not a best
practice.  It is simply an informational document on what can be
achieved.  With this information on-hand, we believe 3GPP network
operators can deploy more IPv6 quicker.

>> > considering that such capability should be a temporary solution.

While the document is not a BCP, it does declare that the best
solution is DHCP-PD.  If you cannot do DHCP-PD, then there are 3
scenarios with various features and trade-offs that the WG has vetted
as viable.  The real goal here is to spur IPv6 deployment by removing
one more roadblock. These 3 scenarios are seen as highly achievable
with existing frameworks or already achieved (scenario #3).

CB

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 22 Feb 2013 11:22:00 -0800

v6ops,

I encourage you to have a look at the below draft.  We have received a
lot of feedback over the last few months since this was presented in
Atlanta.

I feel the current draft has received enough review and revision to
represent something that is pretty close to being mature enough for
WGLC.  If you have more feedback, please provide it so that we can
continue to make progress and understand the WG opinion and the
draft's maturity

Thanks,

Cameron