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

["Brzozowski, John" <[e-mail]>]

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

On Mon, Jan 4, 2016 at 4:00 AM, <[e-mail]<mailto:[e-mail]>> 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
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.
[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