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

[Lorenzo Colitti <[e-mail]>]

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

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