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

From: Erik Kline <[email-masked]>
Date: Sat, 29 Oct 2016 07:17:14 +0900

It still has several rough patches, but I've uploaded a -01 for discussion.

I'd still like to get 5-7 minutes on the agenda in Seoul, if that's feasible.

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 29 October 2016 at 07:14
Subject: New Version Notification for
draft-pioxfolks-6man-pio-exclusive-bit-01.txt
To: Mikael Abrahamsson <[email-masked]>, Erik Kline
<[email-masked]>, Mikael Abrahamsson <[email-masked]>

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
Document date:  2016-10-27
Group:          Individual Submission
Pages:          15
URL:
https://www.ietf.org/internet-drafts/draft-pioxfolks-6man-pio-exclusive-bit-01.txt
Status:
https://datatracker.ietf.org/doc/draft-pioxfolks-6man-pio-exclusive-bit/
Htmlized:
https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusive-bit-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-pioxfolks-6man-pio-exclusive-bit-01

Abstract:
   This document defines a new control bit in the IPv6 RA PIO flags
   octet that indicates that the node receiving this RA is the exclusive
   receiver of all traffic destined to any address within that prefix.

   Termed the eXclusive bit (or "X bit"), nodes that recognize this can
   perform some optimizations to save time and traffic (e.g. disable ND
   and DAD for addresses within this prefix) and more immediately pursue
   the benefits of being provided multiple addresses (vis.  [RFC7934]
   section 3).  Additionally, network infrastructure nodes (routers,
   switches) can benefit by minimizing the number of {link layer, IP}
   address pairs required to offer network connectivity (vis.  [RFC7934]
   section 9.3).

   Use of the X bit is backward compatible with existing IPv6 standards
   compliant implementations.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 31 Oct 2016 23:24:05 +0900

> Title:          IPv6 Router Advertisement Prefix Information Option

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.

---

From: Erik Kline <[email-masked]>
Date: Tue, 1 Nov 2016 00:46:37 +0900

On 31 October 2016 at 23:24, Lorenzo Colitti <[email-masked]> wrote:
> 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.
>
> 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
> 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.