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

[Lorenzo Colitti <[e-mail]>]

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.

   1. 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.
   2. 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.
   3. 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.
   4. 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.

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