Subject: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host

From: [email-masked]
Date: Sun, 3 Jan 2016 11:00:21 -0800

And now for something a little different. I'd like to invite focused
discussion of draft-ietf-v6ops-unique-ipv6-prefix-per-host, which we
adopted at IETF 94

Slides are at
https://www.ietf.org/proceedings/94/slides/slides-94-v6ops-4.pdf.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 4 Jan 2016 14:36:59 +0900

> https://www.ietf.org/proceedings/94/slides/slides-94-v6ops-4.pdf.

As I said before, I think it's a great approach. The alternative/current
approach of IPv6 on wifi relies on sharing a /64 between untrusted devices
belonging to lots of different customers. That is a security nightmare that
ends up in the network having to maintain lots of state and perform lots of
layering violations (DAD proxying, ND snooping, etc.) This is much better -
everything is plain layer 3 with no hacks, and the user gets a full /64.

Comments:

The draft is targeted to BCP but it is also a description of a particular
solution. That doesn't work well in some places, notably where it says that
the solution uses a captive portal. I don't think there will be consensus
to say that a captive portal is BCP compared to, say, 802.1x, hotspot 2.0,
etc. I think its BCP status should be limited to public wifi networks or in
general for networks where subscriber isolation is a strong requirement.
This is not applicable to home networks, for example; many home networks
don't provide address space in most home networks to support it.

I'd like this draft to cite draft-ietf-v6ops-host-addr-availability, since
/64 per host is not only simpler for the operator, it's better for hosts as
well. On a related note, please remove all mention of the singular "IPv6
address" or "/128 address". Many (all?) common implementations configure
both stable and privacy addresses by default, so that text is incorrect.
For example, change "to select its /128 unique address" to "form global
IPv6 addresses". Also change "it will assign itself a 128 bit IPv6 address
using SLAAC" to "it will form one or more IPv6 addresses using SLAAC". This
happens in lots of places.

The draft should be a bit more explicit on whether communication between
devices is allowed (I assume yes?), and if so, how (I assume the packet is
tunneled to WLAN-GW and then tunneled back to the other device?).

The draft recommends an RA interval of 300s and preferred lifetime of
1800s. But draft-ietf-v6ops-reducing-ra-energy-consumption recommends
"approximately 7 RAs per hour", and lifetimes of "roughly 45-90 minutes".
The two should be made consistent, or the difference should be justified.
We shouldn't be putting out two BCPs with different recommendations.

I don't understand the text "To accomodate this the WLAN-GW can
periodically perform a Subscriber Host Connectivity Verification (i.e.
periodically ping each IPv6 UE...)". It seems to me that the the whole
point of this approach is that the WLAN-GW doesn't need to know the
individual IPv6 addresses formed by the hosts. Also, there's no guarantee
that devices will respond to ping. I think better solutions are:

   -
   - The AP could inform the WLAN-GW of when a subscriber disappeared.
   - The WLAN-GW could time out any GRE interface that had not received any
   packets in the last X minutes, or if the customer's /64 prefix had not
   originated any packets in the last X minutes.

Again, the "subscriber host connectivity" solution would be fine in an
informational document describing a particular solution, but not for a BCP.

Cheers,
Lorenzo

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 4 Jan 2016 17:03:27 +0900

On Mon, Jan 4, 2016 at 4:49 PM, VAN DE VELDE, Gunter (Gunter) <
[email-masked]> wrote:

>    - The WLAN-GW could time out any GRE interface that had not received
>    any packets in the last X minutes, or if the customer's /64 prefix had not
> <>end snip<>
> Yes, this process is indeed a mistake in added in this text. What is
> happening in reality is a ND exchange check if the subscriber is still
> alive.
>

But even for an ND exchange, the WLAN-GW needs to keep state on the IPv6
address(es) used by the client.

Which one? It can't use the global addresses, since to find out what they
are it would have to resort to ugly hacks like DAD snooping or traffic
snooping - and even then there is no reliable way to know if an address has
been deleted by the host (e.g., if a privacy address timed out).

I suppose it could use the link-local address that was used to send the RS
(on the assumption that link-local addresses never change), but if so, the
draft should document it explicitly.

---

From: Tore Anderson <[email-masked]>
Date: Mon, 4 Jan 2016 13:41:35 +0100

* [email-masked]

> discussion of draft-ietf-v6ops-unique-ipv6-prefix-per-host, which we

FWIW, I sent some feedback to the list on the 28th of October, which
wasn't answered* or incorporated in the new revision of the draft as far
as I can tell. I'll therefore repeat them below.

* Except for point #2 regarding the draft improperly suggesting that
  when IA_PD is available the M-flag should be set to 1. This did cause
  some discussion on whether or not RA flags have any relation to IA_PD
  availability to begin with, but I don't think there was any
  disagreement about my initial point about tying IA_PD with the M-flag
  specifically not being appropriate.

  Easiest way to fix this in the draft is IMHO just to remove «, this
  flag may be set to 1 in the future if/when DHCPv6 prefix this flag
  may be set to 1 in the future if/when DHCPv6 prefix)». (Just noticed
  this will also get rid of an unmatched parenthesis.)

Tore

------

1) Section 4.2 mentions that DAD is used, but it is not clear to me how
this will work for LLAs. If two UEs (potentially attached to different
APs) are using the same link-local address, how will they see each
others DAD messages? Proxy-ND on the WLAN-GW? Or if the WLAN-GW does
not relay DAD messages across the split BUM horizon, how will it deal
with the possiblity of two unique UEs both using the same LLA? I'm
guessing that in a large-scale deployment, the chances of two UEs
having statically configured, e.g., fe80::1 is quite likely.

2) Regarding the following text in Section 4.2:

>   o  M-flag = 0 (UE/subscriber address is not managed through DHCPv6),
>      this flag may be set to 1 in the future if/when DHCPv6 prefix
>      delegation support over Wi-Fi is desired)  

As I understand it (and I do stress that), the M-flag indicates whether
or not *addresses* are available via DHCPv6 (RFC 4861 s4.2). Prefixes
(IA_PD) is something different. Therefore, assuming that availability of
IA_PD is signalled using RA flags to begin with, then it is "other
configuration" and thus signalled with the O-flag, not the M-flag. I
know of at least one wireline ISP that has such a deployment, i.e.,
they support DHCPv6 IA_PD but not IA_NA/IA_TA, and they signal this
using M=0 + O=1.

3) The draft describes tunneling traffic in a stateless manner. I take
that to mean that the APs and WLAN-GW will be incapable of performing
reassembly at tunnel egress (and by extension that they won't fragment
GRE packets on ingress either). That in turn means that you either 1)
need to allow for jumbo frames in the transport network between the
WLAN-GW and the APs, or 2) provide UEs with a reduced MTU (which
implies the RA MTU option should be used and possibly also TCP-MSS
clamping at the WLAN-GW). Since this is an operational guidance
document I believe this is something that should be discussed.

4) Is UE roaming between APs/BSSIDs supported, and if so how does this
work? As I understand it, the WLAN-GW will have 1 GRE interface per AP,
so if a UE roams from one AP to another, its MAC address and all of its
associated IPv6 addresses will (from the WLAN-GW's POV) move from one
GRE interface to another, which would in turn require the WLAN-GW to
somehow notice this and move the associated /64 and any NDP entries
from the previous GRE interface to the current one. Right? If so, some
discussion on how that happens would be appreciated (or at least a
statement that "secret vendor sauce is assumed to be applied here" if
that is indeed the case).

5) This is just a thought, but regarding the operational consideration
in section 5 regarding supporting privacy addresses: Would it be
possible for the WLAN-GW to simply send all traffic destined for the
UE's dedicated /64 to the UE's MAC address without maintaining ND
entries for each address in use? This way, a single UE could use
gazillions of IPv6 addresses without risking resource exhaustion in the
WLAN-GW. OTOH, maybe that would cause problems for UEs that are
providing tethering to downstream hosts using layer-2 bridging?

6) Some editorial nits I noticed (although I wasn't specifically
looking for them): Missing «.» at the end of page 7, s/Lawfull/Lawful/
on page 12.

---

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 4 Jan 2016 13:39:19 +0000

From: v6ops <[email-masked]<mailto:[email-masked]>> on behalf of Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 4, 2016 at 00:36
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: v6ops <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host

On Mon, Jan 4, 2016 at 4:00 AM, <[email-masked]<mailto:[email-masked]>> wrote:
And now for something a little different. I'd like to invite focused
discussion of draft-ietf-v6ops-unique-ipv6-prefix-per-host, which we
adopted at IETF 94

Slides are at

As I said before, I think it's a great approach. The alternative/current approach of IPv6 on wifi relies on sharing a /64 between untrusted devices belonging to lots of different customers. That is a security nightmare that ends up in the network having to maintain lots of state and perform lots of layering violations (DAD proxying, ND snooping, etc.) This is much better - everything is plain layer 3 with no hacks, and the user gets a full /64.

Comments:

The draft is targeted to BCP but it is also a description of a particular solution. That doesn't work well in some places, notably where it says that the solution uses a captive portal. I don't think there will be consensus to say that a captive portal is BCP compared to, say, 802.1x, hotspot 2.0, etc. I think its BCP status should be limited to public wifi networks or in general for networks where subscriber isolation is a strong requirement. This is not applicable to home networks, for example; many home networks don't provide address space in most home networks to support it.
[jjmb] perhaps we can separate the captive portal pieces out in a separate document.  After speaking to you and several others BCPing the technical bits appears to have value beyond public Wi-Fi networks, enterprise environments come to mind.

I'd like this draft to cite draft-ietf-v6ops-host-addr-availability, since /64 per host is not only simpler for the operator, it's better for hosts as well. On a related note, please remove all mention of the singular "IPv6 address" or "/128 address". Many (all?) common implementations configure both stable and privacy addresses by default, so that text is incorrect. For example, change "to select its /128 unique address" to "form global IPv6 addresses". Also change "it will assign itself a 128 bit IPv6 address using SLAAC" to "it will form one or more IPv6 addresses using SLAAC". This happens in lots of places.
[jjmb] we will factor these comments into our update that is underway.  I think we can accommodate the spirit of this request.

The draft should be a bit more explicit on whether communication between devices is allowed (I assume yes?), and if so, how (I assume the packet is tunneled to WLAN-GW and then tunneled back to the other device?).
[jjmb] device to device to supported, however, IIRC we do not make any assumptions around whether this is supported by default.  We could/should add text that describes how one might prevent device to device communications, where applicable/required.  Since every host has its own prefix the WLAN-GW might play a role in managing device to device communications.  Note – the typical use case that exists with IPv4 does not necessarily apply to IPv6.  Specifically where hosts see link local multicast and other communications that allow hosts to see other hosts.  Further, prefix scanning for IPv6 while possible is unlikely.  I will confer with Gunter and others to see what we should add here.

The draft recommends an RA interval of 300s and preferred lifetime of 1800s. But draft-ietf-v6ops-reducing-ra-energy-consumption recommends "approximately 7 RAs per hour", and lifetimes of "roughly 45-90 minutes". The two should be made consistent, or the difference should be justified. We shouldn't be putting out two BCPs with different recommendations.
[jjmb] you and I have discussed this extensively offline.  We can do our best to harmonize here, I cannot promise that will be the case.  Let’s talk offline and see what we can come up with.  A great deal of thought has gone into these values, which has included your input.  Environments like public Wi-Fi have to support a wide range of device types, as such we need to ensure that values are recommended that allow for maximum interoperability.

I don't understand the text "To accomodate this the WLAN-GW can periodically perform a Subscriber Host Connectivity Verification (i.e. periodically ping each IPv6 UE...)". It seems to me that the the whole point of this approach is that the WLAN-GW doesn't need to know the individual IPv6 addresses formed by the hosts. Also, there's no guarantee that devices will respond to ping. I think better solutions are:
[jjmb] true but the WLAN-GW still needs to maintain its neighbor table.  I forget the context here, I will review the text again and send more substantive comments if required.

  *   The AP could inform the WLAN-GW of when a subscriber disappeared.

[jjmb] one overarching goal is to minimize the amount of complexity in the AP to support IPv6.

  *   The WLAN-GW could time out any GRE interface that had not received any packets in the last X minutes, or if the customer's /64 prefix had not originated any packets in the last X minutes.

[jjmb] FYI – a GRE tunnel is for an AP which may serving n+1 clients.  If this were to happen then other clients might inadvertently be impacted.
Again, the "subscriber host connectivity" solution would be fine in an informational document describing a particular solution, but not for a BCP.
[jjmb] I do not disagree, we will see what we can come up with.

Cheers,
Lorenzo

---

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 4 Jan 2016 13:46:43 +0000

Tore apologies, I thought I/we replied to all comments that required a
reply.  We have all the feedback and will factor in as part of our update.
 See below for more.

John
+1-484-962-0060

-----Original Message-----
From: v6ops <[email-masked]> on behalf of Tore Anderson
<[email-masked]>
Date: Monday, January 4, 2016 at 07:41
To: Fred Baker <[email-masked]>
Cc: v6ops <[email-masked]>
Subject: Re: [v6ops] Focused discussion:
draft-ietf-v6ops-unique-ipv6-prefix-per-host

>  when IA_PD is available the M-flag should be set to 1.
[jjmb] I respectfully disagree, I have built a very large IPv6 deployment
based on this.  Experience tells me it works.  I (Comcast hat on) will
continue to use these bit in this manner.
>This did cause
[jjmb] lots of discussion that I read and largely disagreed with, see
comment above.   This ship has sailed, we all must now agree to disagree.
Let’s not start another tidal wave of emails on this topic.
>  this will also get rid of an unmatched parenthesis.)
[jjmb] I currently have no intention of removing reference to M/O bit = 1
and the use of stateful DHCPv6 for PD.  This is how the same will be
deployed, the document will reflect reality.  If I misunderstood your
comments I apologize.
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 Jan 2016 16:14:02 +0000

Hi, I don't see how this discussion should go forward without a comparison
with what AERO already provides. AERO has been around for a long time
and has a comprehensive specification on how DHCPv6-PD works over
tunnels. It includes solutions for mobility, route optimization, reliability
and fault tolerance, security, multiple interfaces and prefix per host
considerations. Although the base AERO spec calls for GUE as the default
encapsulation, operation over GRE is specified in a companion document:

https://datatracker.ietf.org/doc/draft-templin-aeromin/

I think the authors of unique-ipv6-prefix-per-host need to explain why
a different approach than AERO is needed.

Thanks - Fred
[email-masked]

> From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Sunday, January 03, 2016 11:00 AM
> To: [email-masked]
> Subject: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 4 Jan 2016 10:17:33 -0800

> https://www.ietf.org/proceedings/94/slides/slides-94-v6ops-4.pdf.
Form the draft:

"While this work was originally conceived in the context of large
scale Wi-Fi networks, the scope of applicability is much broader."

This is completely true, however most of the draft seems to focus on
the Wi-Fi application. At Facebook, for instance, we intend to deploy
64-bit prefixes on all host in data center which has nothing to do
with Wi-Fi. It might be good if the draft were more generic in this
regard (or renamed if it is expressly intended to solve an issue for
Wi-Fi).

Thanks,
Tom

---

From: Mark Smith <[email-masked]>
Date: Tue, 5 Jan 2016 06:48:13 +1100

Hi,

> https://www.ietf.org/proceedings/94/slides/slides-94-v6ops-4.pdf.

I agree with points others have made.

The title sounds like a BCP title, however the content reads like a
recipe/howto for a specific deployment scenario.

I think there are general and non-Wifi specific parts that should be
separated. Reflecting on the number and content of recent discussions
around hosts using DHCPv6-PD, I think there needs to be an ID on that
topic. Fred's draft seems to be mostly there, although multicast/MLD needs
to be covered.

https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/

Finally, although it in some ways is out of scope, I'd never want to see a
BCP of any kind proposing that all of Wifi's security mechanisms are turned
off, because WiFi traffic is so easy to packet capture everything when
security is switched off.

Regards,
Mark.

---

From: David Farmer <[email-masked]>
Date: Mon, 4 Jan 2016 19:55:48 -0600

On 1/4/16 07:39 , Brzozowski, John wrote:
>
> From: v6ops <[email-masked] <mailto:[email-masked]>> on
...
>     The draft is targeted to BCP but it is also a description of a
>     particular solution. That doesn't work well in some places, notably
>     where it says that the solution uses a captive portal. I don't think
>     there will be consensus to say that a captive portal is BCP compared
>     to, say, 802.1x, hotspot 2.0, etc.
...
>
> [jjmb] perhaps we can separate the captive portal pieces out in a
> separate document.  After speaking to you and several others BCPing the
> technical bits appears to have value beyond public Wi-Fi networks,
> enterprise environments come to mind.

I think that is an excellent idea and there is even a newly chartered 
(announced today) captive portal working group that is probably a better 
place for the captive portal pieces anyway.

https://datatracker.ietf.org/wg/capport/charter/

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 5 Jan 2016 03:53:48 +0000

AERO may address some of the same requirements and some of the use cases
however, there are differences in implementation and deployment models in
our draft that simply suit our needs better. I have no plans to perform a
comparison between the two nor is AERO something we are considering.  I
respect the fact that AERO has been around for some time, however, it does
not appear to be widely deployed.  Please keep me honest if this is not
the case.  Also I am not aware of diverse implementations of the same.
Just because it is exists does not mean it is the best solution for every
deployment model or use case.

What is document in our draft is what will be deployed.

John
+1-484-962-0060

-----Original Message-----
From: v6ops <[email-masked]> on behalf of Fred Templin
<[email-masked]>
Date: Monday, January 4, 2016 at 11:14
To: Fred Baker <[email-masked]>, v6ops <[email-masked]>
Subject: Re: [v6ops] Focused discussion:
draft-ietf-v6ops-unique-ipv6-prefix-per-host

>> Subject: [v6ops] Focused discussion:

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 5 Jan 2016 03:55:20 +0000

Thanks Tom we will factor this in, I agree the I-D today is heavy on the
Wi-Fi references.  I believe we can make the technical bits more generic.

John
+1-484-962-0060

-----Original Message-----
From: v6ops <[email-masked]> on behalf of Tom Herbert
<[email-masked]>
Date: Monday, January 4, 2016 at 13:17
To: Fred Baker <[email-masked]>
Cc: v6ops <[email-masked]>
Subject: Re: [v6ops] Focused discussion:
draft-ietf-v6ops-unique-ipv6-prefix-per-host

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 5 Jan 2016 03:56:35 +0000

Thanks David.

John
+1-484-962-0060

-----Original Message-----
From: David Farmer <[email-masked]>
Organization: University of Minnesota
Reply-To: David Farmer <[email-masked]>
Date: Monday, January 4, 2016 at 20:55
To: John Jason Brzozowski <[email-masked]>, Lorenzo
Colitti <[email-masked]>,
"[email-masked]"
<[email-masked]>
Cc: David Farmer <[email-masked]>, v6ops <[email-masked]>
Subject: Re: [v6ops] Focused discussion:
draft-ietf-v6ops-unique-ipv6-prefix-per-host

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Jan 2016 18:50:26 +0000

Hi John,

> From: Brzozowski, John [mailto:[email-masked]]
> Sent: Monday, January 04, 2016 7:54 PM
> To: Templin, Fred L; [email-masked]; [email-masked]

So, you are saying "your way is better" when you have not even looked at
AERO?

> not appear to be widely deployed.

That is irrelevant.

> Please keep me honest if this is not

Wouldn't it make sense then to then to investigate a use case analysis for
your use case?

> What is document in our draft is what will be deployed.

Wow - doesn't seem like a very open-minded position and ignores
emerging IETF works. Are you saying that existing and emerging
works should be ignored, and a new solution blessed with no use
case analysis?

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Jan 2016 18:51:32 +0000

Hi Mark,

I am in the process of working in some text on multicast/MLD and will submit an
update later today.

Thanks - Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Monday, January 04, 2016 11:48 AM
To: Fred Baker (fred)
Cc: v6ops list
Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host

Hi,

The title sounds like a BCP title, however the content reads like a recipe/howto for a specific deployment scenario.

I think there are general and non-Wifi specific parts that should be separated. Reflecting on the number and content of recent discussions around hosts using DHCPv6-PD, I think there needs to be an ID on that topic. Fred's draft seems to be mostly there, although multicast/MLD needs to be covered.

Finally, although it in some ways is out of scope, I'd never want to see a BCP of any kind proposing that all of Wifi's security mechanisms are turned off, because WiFi traffic is so easy to packet capture everything when security is switched off.

Regards,
Mark.

> v6ops mailing list
> [email-masked]<mailto:[email-masked]>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 6 Jan 2016 00:24:56 +0000

> On Jan 5, 2016, at 10:50 AM, Templin, Fred L <[email-masked]> wrote:
> 

I'm sorry, no, it is relevant. We're not talking about IPv5, IPv7, TUBA, RFC 3053, RFC 5572, ISATAP (which one actually can describe as widely deployed or having once been widely deployed) or quite a long list of other technologies.

In a draft whose primary purpose (BCP) is to ask network administrators to not restrict hosts or host interfaces to a single address, discussing a technology that might or might not have promise but is not widely received as a common current practice is at best irrelevant.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jan 2016 00:35:27 +0000

Hi Fred,

> From: Fred Baker (fred) [mailto:[email-masked]]
> Sent: Tuesday, January 05, 2016 4:25 PM
> To: Templin, Fred L
> Cc: John Brzozowski; [email-masked]
> I'm sorry, no, it is relevant. We're not talking about IPv5, IPv7, TUBA, RFC 3053, RFC 5572, ISATAP (which one actually can describe as
> widely deployed or having once been widely deployed) or quite a long list of other technologies.

To be fair, AERO is about IPv6 and DHCPv6 Prefix Delegation - not some
weird new IP protocol version. Likening it to IPv5, IPv7, TUBA, etc. is
therefore inappropriate.

Thanks - Fred

> In a draft whose primary purpose (BCP) is to ask network administrators to not restrict hosts or host interfaces to a single address,
> discussing a technology that might or might not have promise but is not widely received as a common current practice is at best
> irrelevant.

---

From: David Farmer <[email-masked]>
Date: Tue, 5 Jan 2016 18:39:54 -0600

> weird new IP protocol version. Likening it to IPv5, IPv7, TUBA, etc. is

Doesn't it also include automatic tunneling, and require end client 
software to support it?

>> discussing a technology that might or might not have promise but is not widely received as a common current practice is at best

What? wait a sec, isn't that draft-ietf-v6ops-host-addr-availability.

This is draft-ietf-v6ops-unique-ipv6-prefix-per-host, and is something 
different, its related, but most definitely different.

In my view AERO and this draft are working in slightly overlapping, but 
different solution spaces.

--

---

From: joel jaeggli <[email-masked]>
Date: Tue, 5 Jan 2016 16:40:31 -0800

On 1/5/16 4:24 PM, Fred Baker (fred) wrote:
>
> In a draft whose primary purpose (BCP) is to ask network
> administrators to not restrict hosts or host interfaces to a single
> address, discussing a technology that might or might not have promise
> but is not widely received as a common current practice is at best
> irrelevant.

I tend to concur, if you're going to provide advice to an operator
audience that strikes at current practice, relevance  involves present
usage.

joel

> 
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jan 2016 00:46:56 +0000

Hi David,

> From: David Farmer [mailto:[email-masked]]
> Sent: Tuesday, January 05, 2016 4:40 PM
> To: Templin, Fred L; Fred Baker (fred)
> Cc: David Farmer; [email-masked]; John Brzozowski

AERO is typically used with automatic tunneling, but the functions can also be applied
to native multi-access links with no tunneling. Yes, client software is used for managing
prefix delegation server associations, for mobility management, etc. But, standard
DHCPv6 PD also requires client-side software, so I'm not sure I see a problem?

> different solution spaces.

We don't know that without a use case analysis.

Thanks - Fred

---

From: David Farmer <[email-masked]>
Date: Tue, 5 Jan 2016 19:28:03 -0600

...
> We don't know that without a use case analysis.

Well as I read this, this doesn't implement DHCPv6 PD. Furthermore, it 
doesn't need any client software.  It uses SLAAC and responds to each 
IPv6 ND Router Solicitation with a unicast Router Advertisement with 
different prefix for each client.  It provides DNS server info with 
RADNS and stateless DHCPv6 if the client send a request.

The client requirement are just standard SLAAC, and RADNS or stateless 
DHCPv6, that is it.  No DHCPv6 PD client needed, am I missing something?

There is a bunch of WiFi parts too, just like AERO has tunnel stuff, but 
that is fairly standard WiFi infrastructure bits.

So, there is a really quick use case analysis for you and I'll 
reiterate; in my view AERO and this draft are working in slightly 
overlapping, but different solution spaces.

Thanks.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jan 2016 15:42:25 +0000

Hi David,

> Sent: Tuesday, January 05, 2016 5:28 PM

How would an unmodified client know that the prefix it receives in
a unicast RA is in fact uniquely assigned for the client's exclusive use
and not advertised to any other client?

> DHCPv6, that is it.  No DHCPv6 PD client needed, am I missing something?

I think so. An unmodified client receiving a PIO with (A=1, L=0) would have
no way of knowing that the prefix is being delegated for its own exclusive
use and that the prefix would not be advertised to other clients.

> that is fairly standard WiFi infrastructure bits.

I thought this work was based on tunneling, too? And, AERO can run fine
over WiFi just the same as over any link-layer technology.

> overlapping, but different solution spaces.

I don't see how multi-addressing in the spirit of "host-addr-availabiity"
can be supported on an unmodified client. There would need to be
additional specification telling the client what to do when it receives
a PIO with (A=1,L=0). But then, the document becomes a spec and
not an informational. And, clients would have to be modified.

Thanks - Fred

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 6 Jan 2016 16:30:03 +0000

Belated comments on this useful draft...

I am confused by the wording of 'IPv6 only experience even if IPv4 support is present'

It appears to me that the security among users only relies on the AP in isolation mode (or split-horizon)... This makes the I-D mainly relevant to your use case :-(

It is not clear whether the UE will always receive the same /64 even when 'roaming' within the community WiFi as it would have privacy implications.

Section 4.3.2, do we have data backing that most OS still do DNS request over IPv4?

Section 5, I must admit that I do not understand why the GW has to send periodic unsolicited (unicast I hope to get the WiFi ACK) RA... Why not wait for the RS by the UE?

Section 5, when the GW 'pings' the UE, does it use ICMP? Or plain NS ? Can the AP leverage any WiFi polling?

A big  advantage  (which is not described) is that there will be a minimum of NDP multicast traffic which is a pain over WiFI cfr draft-vyncke-6man-mcast-not-efficient-01

Cosmetic:

  *   ASCII art topology would increase the readability of section 3 or move the ASCII art from section 4 in section 3 or remove section 3 or ...
  *   Any chance to replace the HTTP captive portal by a more secure HTTPS captive portal (and I know the issue with certificates are not easy). Or remove it => too specific

I also agree with:

  *   Lorenzo & Tom Herbert: the scope is much broader => the I-D should be made less specific
  *   David: this has nothing to do with AERO :-)

Finally, I cannot refrain from thinking that there are several I-D (including this one) attempting to fix NDP...

Hope this helps

-éric

---

From: David Farmer <[email-masked]>
Date: Wed, 6 Jan 2016 11:33:20 -0600

> and not advertised to any other client?

That's the whole point the client doesn't need to know its been uniquely 
assigned the whole prefix to assign it the whole prefix. The client 
doesn't actually guarantee the uniqueness anyway.  It's perfectly fine 
for client to be blissfully ignorant of that fact.

Don't get me wrong I'm not saying I don't want clients to do DHCPv6 PD, 
but they just don't have to just to get a whole /64 assigned to them. 
Are there things the client can do if it knows sure.  Should the client 
know, if it can deal with that knowledge, sure.  However, the client 
doesn't have to know, especially if it doesn't know how to deal with 
that knowledge anyway.

> use and that the prefix would not be advertised to other clients.

Why does it have to care?  If it cares, it can do DHCPv6 PD, but it 
doesn't have to.  You seem to think it has to care, why?

> over WiFi just the same as over any link-layer technology.

The CAPWAP stuff is its own separate thing, already specified.  There 
may be some unique ways it's used here but that's separate, this is the 
point others have made, and I agree.  There is some stuff that needs to 
be tweezed apart but its a good start.

> not an informational. And, clients would have to be modified.

I disagree with the first part but agree with at least part of the 
second part.  I'm starting to think that we need a real standards track 
document not just a BCP, at least for PIO with (A=1, L=0) not because it 
needs to really fundamentally makes changes.  But I'm worried some 
people will not take this serious without it being standards track.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jan 2016 18:40:06 +0000

Hi David,

> Sent: Wednesday, January 06, 2016 9:33 AM

OK, I see - so, the client (not knowing that the prefix has been delegated
for its own exclusive use) autoconfigures addresses from the prefix
(because the PIO had A=1) and assigns them to the WiFi interface and
not to some internal virtual interface. That means that the client needs
to send a multicast NS(DAD) over the WiFi interface for every such
address that it autoconfigures. That is different than what we have
been talking about regarding "host-addr-availability".

One thing I see missing in the draft however is that the client also needs
to do DAD for its link-local address before it does anything else - right?

> doesn't have to.  You seem to think it has to care, why?

OK, so the base specification calls for the client to do SLAAC autoconfiguration
of addresses from the advertised prefix and then assign the addresses to the
WiFi interface after it joins the MLD solicited-node multicast group and sends
a multicast NS(DAD) for each such address. Again, that is different than what
we have been talking about in "host-addr-availability".

> I disagree with the first part

I was referring to the language in "host-addr-availability" that allows
the client to assign addresses from the delegated prefix to internal
interfaces such as a loopback. For an unmodified client that does
not know that it is being granted the entire prefix based on just
(A=1;L=0) in the PIO, that option is not available. So, really, the
two documents in question need to be interpreted in a mutually
exclusive fashion which I think you indicated in an earlier message.

> but agree with at least part of the second part.
> I'm starting to think that we need a real standards track

I agree with standards-track, but I thought standards-track documents
are out of scope for v6ops?

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jan 2016 18:45:54 +0000

Hi David,

> The CAPWAP stuff is its own separate thing, already specified.

You indicated CAPWAP, which is something I asked about a while back. Is
the SoftGRE stuff one and the same as CAPWAP, or something different?
If different, why not just use CAPWAP?

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jan 2016 20:01:51 +0000

I have what I hope will be a simple question: what if two or more UEs configure
identical IPv6 link-local addresses - will the WLAN-GW be able to tell them apart?
Asked another way, what kind of unique node identifier does the WLAN-GW
expect each UE to provide in the initial RS?

Thanks - Fred

---

From: David Farmer <[email-masked]>
Date: Wed, 6 Jan 2016 16:32:38 -0600

> If different, why not just use CAPWAP?

Sorry, I guess I misspoke, right SoftGRE. :)  SoftGRE, EoGRE, CAPWAP, 
etc... are all more or less equivalent in my mind, a tunneling overlay 
technology of some kind.  Personally, I prefer to VXLAN these days, but 
YMMV.

The IPv6 bits are what interested me, and obviously what I paid 
attention too.

---

From: David Farmer <[email-masked]>
Date: Wed, 6 Jan 2016 16:54:08 -0600

> been talking about regarding "host-addr-availability".

Well not really, what I've been saying all along 
"host-addr-availability" isn't really about DHCPv6 PD that's just one 
way to accomplish it's real intent.  It is the one way that has everyone 
in a tizzy, but its only one way.

> we have been talking about in "host-addr-availability".

Yes and No, "host-addr-availability" is BCP telling networks DO NOT 
limit host to one address, one way to do that is assign each host a /64, 
this is one way to accomplish that.  So yes different, but still related.

> exclusive fashion which I think you indicated in an earlier message.

I wouldn't go as far as mutually exclusive, but yes they are separate 
issues, that at least touch each other if not overlap some. :)

> are out of scope for v6ops?

Yep, we will have to deal with that issue, but lets tweeze things apart 
first then figure out who needs to do what.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 7 Jan 2016 11:54:38 +0000

As all subscribers have a dedicated tunnel to the GW, this translates (to
me) into each subscriber has its own layer-2 link, so, no need to do DAD
as there is a unique UE per subscriber (my reading but I am not 100% sure).

If more than one UA can exist per tunnel, then indeed, Fred, you are right

-éric

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Jan 2016 15:47:39 +0000

Hi Gunter,

OK, so you are saying that the MAC address of the UE is used as the UE identifier.
But, both link-local and MAC addresses can be readily spoofed by an attacker,
either to steal the service of the legitimate node or to deny service to the
legitimate node. In order to avoid that, the UE would have to have some form
of identifier that cannot be spoofed, or sign its messages using a certificate
provisioned by the service provider - even though captive portal is being
used to authenticate the user.

Thanks - Fred

> From: VAN DE VELDE, Gunter (Gunter) [mailto:[email-masked]]
> Sent: Thursday, January 07, 2016 1:51 AM
> To: Templin, Fred L; [email-masked]
> Cc: [email-masked] WG
> The WLAN-GW should not care about overlap here, there is a split horizon function and the wlan-gw should be able to handle
> overlapping IPs. Link-local address may be stored to e.g. use when sending RA, but it should not be used as a key, that is the role of
> the MAC address. So as long as MAC addresses don't overlap there should not be a problem distinguishing UEs.
> 
> 
> That being said, it would be unlikely to happen since link-local addresses in a WiFi context are mostly EUI-64 based and thus encode
> the MAC address which as stated should be unique.
> 
> Kind Regards,
> G/
> 
> 
> 
> 
> 
> 
> On 06/01/16 21:01, "Templin, Fred L" <[email-masked]> wrote:
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Jan 2016 16:16:09 +0000

So, are you saying there is an exploitable vulnerability in v4 community WiFi that
carries forward into v6?

Thanks - Fred

> From: VAN DE VELDE, Gunter (Nokia - BE) [mailto:[email-masked]]
> Sent: Thursday, January 07, 2016 8:13 AM
> This seems no different as with v4 technology at community Wi-Fi…
> 
> G/
> 
> 
> 
> On 07/01/16 16:47, "Templin, Fred L" <[email-masked]> wrote:
> 
> >Hi Gunter,
> >

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Jan 2016 16:56:39 +0000

Hi Gunter,

Maybe I am not understanding you correctly. There may be many APs (100's, 1000's, etc.)
associated with a single WLAN-GW - correct? At each AP, a UE presents itself using its
MAC address and initially sends out an RS using an IPv6 link-local address most likely
derived from the MAC address. The AP (acting in bridge mode) then forwards the
RS to the WLAN-GW which needs to have some way of knowing that the RS came
from an authentic source. (You have said that the MAC address is the identifier for
the UE - but, does the WLAN-GW see the MAC address, or does it only see the
link-local address?)

Now, consider a UE 'A' associated with AP 'X' and a UE 'B' associated with AP 'Y'.
A is the authentic owner of MAC address 'M'. When A associates with X, the
WLAN-GW goes through the authentication procedures based on the MAC
address M (or the IPv6 link-local address associated with MAC address M).
But now, B associates with Y and also uses MAC address M. (Or, maybe B
associates with Y before A associates with X.) What is to stop B from spoofing
the MAC address in this way and DoS'ing A?

Thanks - Fred

> Sent: Thursday, January 07, 2016 8:37 AM
> I am saying that there is no difference between v4 and v6 behaviour on a WiFi (or even most other L2 network type’s) network when
> MAC address clash. It is not a new problem and same techniques used in v4 can be used in the v6 realm. Clearly when two devices
> have the same MAC address on the same L2 network something is goofed up.
> 
> 
> G/
> 
> 
> 
> 07/01/16 17:16, "Templin, Fred L" <[email-masked]> wrote:
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Jan 2016 17:34:57 +0000

Hi Gunter,

> Sent: Thursday, January 07, 2016 9:14 AM
> On 07/01/16 17:56, "Templin, Fred L" <[email-masked]> wrote:
> 
> >Hi Gunter,
> >
> >associated with a single WLAN-GW - correct?
> 
> GV> Yep, there can be indeed. I start to see where the confusion came from.

MAC address spoofing is MAC address spoofing - whether there is 1 AP or 1000,
and whether there is mobility or no mobility. I don't think there is any confusion.
Where I am trying to understand is whether completely unmodified and COTS
UEs can be used without there being a danger of MAC address spoofing DoS,
or whether the UEs need to be enrolled in the service offered by the
community WiFi provider. By "enrolled", I mean entered into the provider's
PKI and given a cert, or something like that.

Thanks - Fred

> >At each AP, a UE presents itself using its
> GV> AP is bridging from wifi to GRE tunnel, so the WLAN-GW sees MAC address indeed
> 
> >
> GV> both AP’s use their own different SoftGRE tunnel to the WLAN-GW, and that is how WLAN-GW finds out they are different
> because the tunnel can be part of the key. Ofcours UE mobility and other advanced features can be enabled on the WLAN-GW using
> alternate authentication mechanisms, but that is beyond the scope of this particular draft as that drives pretty far into vendor
> capability territory and i believe that is beyond v6ops scope.
> 
> Be well,
> G/
> 
> >

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Jan 2016 17:55:24 +0000

People have asked about overlap between this work and AERO. The overlap
is in the way SoftGRE works in comparison with the AERO link model. SoftGRE
to my understanding is just another example of a Non-Broadcast, Multiple
Access (NBMA) tunnel virtual overlay in exactly the same fashion as for AERO.
The AP is analogous to the AERO Client, and the WLAN-GW is analogous to
the AERO Server. That the APs are bridging instead of providing a terminus
for prefix delegation is unique to this work, and not covered by AERO. But,
the tunnel virtual link model is one and the same.

That said, AERO can benefit this work through the manner in which multiple
WLAN-GWs can be networked to create a global routing system that can
sustain UE-to-prefix associations wherever the UEs happen to pop up in
the global community WiFi routing structure. It can be handled through
the addition of a new construct which I am calling the "WLAN-RELAY",
which is analogous to the AERO Relay, and through the introduction of
a private BGP instance that keeps track of all UE-to-WLAN-GW associations.
 I explained how this all works in my message to Gert several messages back,
and I would like to offer this as input to the authors of this draft:

https://mailarchive.ietf.org/arch/msg/v6ops/jN0vAnHPchobrHTp22tjQbFjGN4
https://datatracker.ietf.org/doc/draft-templin-aerolink/

Thanks - Fred

---

From: "VAN DE VELDE, Gunter (Gunter)" <[email-masked]>
Date: Mon, 4 Jan 2016 07:49:08 +0000

<>snip<>

  *

<>end snip<>

Yes, this process is indeed a mistake in added in this text. What is happening in reality is a ND exchange check if the subscriber is still alive. It was only list of corrections to make in the next revision of the text.
With DHCPv6 we have the Address lifetime as additional parameter, but we are not speaking about DHCPv6 in this draft due to lack of support for critical mass of UE's.

The AP is simple device with little control logic… most commonly it is for community Wifi simply bridging from Wireless to a tunnel ( to a GRE) and the Wireless Lan controller does all the smartness of the subscriber management. That way the wireless LAN controller doe not have to rely upon fancy features available on the AP.

G/

---

From: "VAN DE VELDE, Gunter (Gunter)" <[email-masked]>
Date: Thu, 7 Jan 2016 09:50:57 +0000

Hi Fred,

The WLAN-GW should not care about overlap here, there is a split horizon function and the wlan-gw should be able to handle overlapping IPs. Link-local address may be stored to e.g. use when sending RA, but it should not be used as a key, that is the role of the MAC address. So as long as MAC addresses don't overlap there should not be a problem distinguishing UEs.

That being said, it would be unlikely to happen since link-local addresses in a WiFi context are mostly EUI-64 based and thus encode the MAC address which as stated should be unique.

Kind Regards,
G/

---

From: "VAN DE VELDE, Gunter (Nokia - BE)" <[email-masked]>
Date: Thu, 7 Jan 2016 16:12:38 +0000

Hi Fred,

G/

---

From: "VAN DE VELDE, Gunter (Nokia - BE)" <[email-masked]>
Date: Thu, 7 Jan 2016 16:37:03 +0000

I am saying that there is no difference between v4 and v6 behaviour on a WiFi (or even most other L2 network type’s) network when MAC address clash. It is not a new problem and same techniques used in v4 can be used in the v6 realm. Clearly when two devices have the same MAC address on the same L2 network something is goofed up. 

G/

---

From: "VAN DE VELDE, Gunter (Nokia - BE)" <[email-masked]>
Date: Thu, 7 Jan 2016 17:13:54 +0000

>the MAC address in this way and DoS'ing A?

GV> both AP’s use their own different SoftGRE tunnel to the WLAN-GW, and that is how WLAN-GW finds out they are different because the tunnel can be part of the key. Ofcours UE mobility and other advanced features can be enabled on the WLAN-GW using alternate authentication mechanisms, but that is beyond the scope of this particular draft as that drives pretty far into vendor capability territory and i believe that is beyond v6ops scope.

Be well,
G/