Subject: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi-svcs-03

From: Hui Deng <[email-masked]>
Date: Wed, 21 Mar 2012 16:17:56 +0800

Hello authors,

Thanks for writing this draft, I have several comments below:
1) I searched the whole document, only 2,3 place have mentioned IPv6,
don't know whether it is related to v6ops, considering Intarea?

2) It is a good tutorial for people who start to work on wifi. would that
be possible
to describe each section related to IETF work such as mentioning capwap,
EAP, pmip6/GTP,diameter et al.

3) Recent wifi authentication work mostly is based on portal, but guess
future would be based on EAP
to have some disucssion on this would be helpful?

Best,

-Hui

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 21 Mar 2012 18:39:30 -0700

Hi Hui,

Thanks for your comments. SP WIFI is one of the key focus areas for all most
every mobility operator. Wi-Fi Offload is the topic of interest, with
significant vendor and operator interest in this space. Correct me, how many
million hotspots you guys have deployed last year ? The spec tries to
identify what it takes to enable that service, the protocol choice, mobility
considerations, IPv6 transitioning and other aspects. We are still working
on additional updates, that should complete all the IPv6 considerations.

>  It is a good tutorial for people who start to work on wifi. would that be
possible to describe each section related to IETF work such as mentioning
capwap, EAP, pmip6/GTP,diameter et al.
:)  You missed the point, Hui. This is not a tutorial, come on. This is
about enabling a service.

> Recent wifi authentication work mostly is based on portal, but guess future
would be based on EAP to have some disucssion on this would be helpful?

It is true that 802.1x/EAP is the way to go, but as you are aware, not all
terminals are 802.1x compliant and many operators are not willing to enforce
this at this time. You/CMCC as an operator understands these challenges as
well, so we may have to address the Web Auth issue and provided the
recommendations.

Regards
Sri

On 3/21/12 1:17 AM, "Hui Deng" <[email-masked]> wrote:

> 2) It is a good tutorial for people who start to work on wifi. would that be
> possible
> to describe each section related to IETF work such as mentioning capwap, EAP,
> pmip6/GTP,diameter et al.
>  
> 3) Recent wifi authentication work mostly is based on portal, but guess future
> would be based on EAP
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Hui Deng <[email-masked]>
Date: Thu, 22 Mar 2012 10:00:11 +0800

Hi Sri,

Thanks for your reply.
I would agree today SP WIFI offload become one of top issues discussed
everywhere GSMA/WBA/WFA/3GPP/SMALL CELL.. we have deployed couple of
million APs last year. agree your points that IETF could also help to
enhance the such Internet access expansion especially taking on IPv6
consideration. Your work could be a good start for that direction.
Let's have wifi network support IPv6. thanks for your contribution

-Hui

2012/3/22 Sri Gundavelli <[email-masked]>

> Hi Hui,
>
> Thanks for your comments. SP WIFI is one of the key focus areas for all
> most every mobility operator. Wi-Fi Offload is the topic of interest, with
> significant vendor and operator interest in this space. Correct me, how
> many million hotspots you guys have deployed last year ? The spec tries to
> identify what it takes to enable that service, the protocol choice,
> mobility considerations, IPv6 transitioning and other aspects. We are still
> working on additional updates, that should complete all the IPv6
> considerations.
>
>
>
> >  It is a good tutorial for people who start to work on wifi. would that
> be possible to describe each section related to IETF work such as
> mentioning capwap, EAP, pmip6/GTP,diameter et al.
> > Recent wifi authentication work mostly is based on portal, but guess
> future would be based on EAP to have some disucssion on this would be
> helpful?
>
> terminals are 802.1x compliant and many operators are not willing to
> enforce this at this time. You/CMCC as an operator understands these
> challenges as well, so we may have to address the Web Auth issue and
> provided the recommendations.
>
>
>
> Regards
> Sri
>
>
>
>
> ------------------------------

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 22 Mar 2012 10:51:05 -0500

On Wed, Mar 21, 2012 at 8:39 PM, Sri Gundavelli <[email-masked]> wrote:
> significant vendor and operator interest in this space.

Wi-Fi ofload is FMC (fixed mobile convergence).

Profiting the occasion, I invite everybody to FMC side meeting on
Tuesday at 19:30, the room is TBA.

> Correct me, how many

Yes, part of FMC.

Regards,

Behcet

---

From: "George, Wes" <[email-masked]>
Date: Sat, 24 Mar 2012 08:58:23 -0400

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sri Gundavelli
Sent: Wednesday, March 21, 2012 9:40 PM
To: Hui Deng; [email-masked]
Subject: Re: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi-svcs-03

how many million hotspots you guys have deployed last year ? The spec tries to identify what it takes to enable that service, the protocol choice, mobility considerations, IPv6 transitioning and other aspects. We are still working on additional updates, that should complete all the IPv6 considerations.

[WEG] Allow me to provide some more specific feedback about what's missing in terms of IPv6 considerations.

A deployment of this type MUST be planning for IPv6 on day one, and we'd be doing a disservice to not explicitly state that so that those using this as a guide include this in their requirements to their vendors.

When you are deploying "millions of hotspots" you had better be prepared to manage them via IPv6... ONLY. By manage, I mean everything from remote configuration, OSS/polling, software management, etc.

This also extends to if you are using something like GRE or L2TP tunneling to carry traffic from an AP back to a wifi core to manage mobility and other things -- that tunneling MUST be done over IPv6. These deployments are simply too large and there are already too many overlapping uses of 1918 space for it to be realistic to think that it will be possible to give these APs even one IPv4 address for those uses. This consideration will seem very familiar to those of us who have been on the wrong end of a discussion involving trying to make 50K cell towers IP-reachable, and stunned to find out that key pieces of equipment and software say, "huh? What's IPv6?"

And of course, it MUST be able to carry IPv6 data from end hosts (the actual users). While Wifi is a layer 2 protocol, there are enough interactions between Layer 2 and 3 that IPv6 support should be explicitly indicated. I've been personally burned by this in such a way as to not want to simply assume that it'll just work because wifi vendors will be smart enough to do the right thing.

Naturally, if you'd like to be backwards compatible, you SHOULD support IPv4 for all of the above, but you MUST support IPv6 and you MUST NOT require IPv4 for proper and complete function. RFC6540 (in AUTH48) says more or less exactly this. You're welcome to cite it :-)

Thanks,

Wes George

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 24 Mar 2012 07:35:52 -0700

On Mar 24, 2012 5:59 AM, "George, Wes" <[email-masked]> wrote:
> Subject: Re: [v6ops] Comments on
draft-gundavelli-v6ops-community-wifi-svcs-03
>
>
>
> how many million hotspots you guys have deployed last year ? The spec
tries to identify what it takes to enable that service, the protocol
choice, mobility considerations, IPv6 transitioning and other aspects. We
are still working on additional updates, that should complete all the IPv6
considerations.
>
> [WEG] Allow me to provide some more specific feedback about what’s
missing in terms of IPv6 considerations.
>
>
>
> A deployment of this type MUST be planning for IPv6 on day one, and we’d
be doing a disservice to not explicitly state that so that those using this
as a guide include this in their requirements to their vendors.
>
>
>
> When you are deploying "millions of hotspots" you had better be prepared
to manage them via IPv6... ONLY. By manage, I mean everything from remote
configuration, OSS/polling, software management, etc.
>
> This also extends to if you are using something like GRE or L2TP
tunneling to carry traffic from an AP back to a wifi core to manage
mobility and other things -- that tunneling MUST be done over IPv6. These
deployments are simply too large and there are already too many overlapping
uses of 1918 space for it to be realistic to think that it will be possible
to give these APs even one IPv4 address for those uses. This consideration
will seem very familiar to those of us who have been on the wrong end of a
discussion involving trying to make 50K cell towers IP-reachable, and
stunned to find out that key pieces of equipment and software say, “huh?
What’s IPv6?”
>
>
>
> And of course, it MUST be able to carry IPv6 data from end hosts (the
actual users). While Wifi is a layer 2 protocol, there are enough
interactions between Layer 2 and 3 that IPv6 support should be explicitly
indicated. I've been personally burned by this in such a way as to not want
to simply assume that it'll just work because wifi vendors will be smart
enough to do the right thing.
>
>
>
> Naturally, if you'd like to be backwards compatible, you SHOULD support
IPv4 for all of the above, but you MUST support IPv6 and you MUST NOT
require IPv4 for proper and complete function. RFC6540 (in AUTH48) says
more or less exactly this. You're welcome to cite it :-)
> Wes George

^^^^^^^^

Yes, please add ALL of that. Wes hit the nail on the head.

Cb
> This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely
for the use of the individual or entity to which it is addressed. If you
are not the intended recipient of this E-mail, you are hereby notified that
any dissemination, distribution, copying, or action taken in relation to
the contents of and attachments to this E-mail is strictly prohibited and
may be unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any copy of
this E-mail and any printout.

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 25 Mar 2012 03:12:00 -0700

Hi Wes/Cameron,

I agree with your comments. The use of IPv6 should be a day-1 requirement;
all the considerations around addressing models (Per mobile OR shared IPv6
prefix), IPv6 tunnel transport, or even IPv6-based control plane when used
... all are important considerations. I agree with this.

Regards
Sri

On 3/24/12 5:58 AM, "George, Wes" <[email-masked]> wrote:

> how many million hotspots you guys have deployed last year ? The spec tries to
> considerations, IPv6 transitioning and other aspects. We are still working on
> additional updates, that should complete all the IPv6 considerations.
> [WEG] Allow me to provide some more specific feedback about what¹s missing in
> terms of IPv6 considerations.
>  
> A deployment of this type MUST be planning for IPv6 on day one, and we¹d be
> doing a disservice to not explicitly state that so that those using this as a
> guide include this in their requirements to their vendors.
>  
> When you are deploying "millions of hotspots" you had better be prepared to
> manage them via IPv6... ONLY. By manage, I mean everything from remote
> This also extends to if you are using something like GRE or L2TP tunneling to
> carry traffic from an AP back to a wifi core to manage mobility and other
> things -- that tunneling MUST be done over IPv6. These deployments are simply
> too large and there are already too many overlapping uses of 1918 space for it
> to be realistic to think that it will be possible to give these APs even one
> IPv4 address for those uses. This consideration will seem very familiar to
> those of us who have been on the wrong end of a discussion involving trying to
> make 50K cell towers IP-reachable, and stunned to find out that key pieces of
> equipment and software say, ³huh? What¹s IPv6?²
>  
> And of course, it MUST be able to carry IPv6 data from end hosts (the actual
> users). While Wifi is a layer 2 protocol, there are enough interactions
> between Layer 2 and 3 that IPv6 support should be explicitly indicated. I've
> been personally burned by this in such a way as to not want to simply assume
> that it'll just work because wifi vendors will be smart enough to do the right
> thing.
>  
> Naturally, if you'd like to be backwards compatible, you SHOULD support IPv4
> for all of the above, but you MUST support IPv6 and you MUST NOT require IPv4
> for proper and complete function. RFC6540 (in AUTH48) says more or less
> exactly this. You're welcome to cite it :-)
>  
> Thanks,
> Wes George
> 
> 
> copyright belonging to Time Warner Cable. This E-mail is intended solely for
> the use of the individual or entity to which it is addressed. If you are not
> the intended recipient of this E-mail, you are hereby notified that any
> dissemination, distribution, copying, or action taken in relation to the
> contents of and attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify the sender
> immediately and permanently delete the original and any copy of this E-mail
> and any printout.
>