Re: New Version Notification for draft-pioxfolks-6man-pio-exclusive-bit-01.txt

[Erik Kline <[e-mail]>]

On 31 October 2016 at 23:24, Lorenzo Colitti <[e-mail]> wrote:
> On Sat, Oct 29, 2016 at 7:17 AM, Erik Kline <[e-mail]> wrote:
>>
>> A new version of I-D, draft-pioxfolks-6man-pio-exclusive-bit-01.txt
>> has been successfully submitted by Erik Kline and posted to the
>> IETF repository.
>>
>> Name:           draft-pioxfolks-6man-pio-exclusive-bit
>> Revision:       01
>> Title:          IPv6 Router Advertisement Prefix Information Option
>> Exclusive Bit
>
>
> I like this for many reasons.
>
> It's a clear way to tell the host that it can use as many addresses from the
> prefix as it wishes without imposing any burden on the network.
> It's appropriate for the ipv6-prefix-per-host multi-user networks that are
> being discussed in v6ops at the moment. Those networks have to scale to many
> users, and hosts that support PIO-X will substantially reduce control plane
> and ND traffic.
> It also allows the use of things like RFC7278-style /64 sharing, which is
> useful to support support things like virtual machines and containers, or
> connection sharing, on such networks.
> It fills one of the holes left by RFC 7934 where the host doesn't really
> have a good way of knowing at what point additional addresses are going to
> create scalability issues on the network.
>
> I'm not too sure about the mode of operation where the routers use L3
> unicast on broadcast networks though. The mechanics there seem brittle and,
> at least as far as I can see, require all routers to know about all hosts at
> all times, which is not particularly reliable in the presence of lost RS
> packets or router crashes. I don't think we should define something that's
> not reliable by itself because otherwise sooner or later we'll have to
> define a VRRP extension for it. :-)
>
> It also leads to fallout in terms of flexibility, e.g., where PIO-X hosts
> can't send RSes from :: because otherwise they'd break this mode of
> operation, have to verify that there are no other hosts on the network, etc.
>
> It would be much simpler and clearer to (initially?) spec this for links
> where there is a strong guarantee that only one host will receive the RA,
> and even better, when there is a strong signal that the host is still on the
> network. 802.11 wifi is a perfect example of such a link, and there are many
> others. In fact, in pretty much any multi-user network has to implement
> client isolation of some sort, if for nothing else to protect from
> link-layer attacks.

Hmm, yeah.  I was trying to come up with right way to define such
applicability in the TBD 3.3 sections, but failed to come up with
anything good in time.

We can certainly remove all the awkward end-host validation text and
just say it has to trust that if it received a PIO-X then the network
is responsible for knowing what it's doing.

> I think a discussion in Seoul would be helpful to resolve these issues and
> make progress.