Subject: Comments on PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 28 Mar 2017 11:57:45 -0500

In addition to asking how is this draft helping with DHCPv6 Prefix
Delegation,

I suggest addition of the following references.

Where draft-pioxfolks-6man-pio-exclusive-bit-01 says:
>    There are several initiatives that propose network side practices
>    that provide customer isolation, enhanced operational scalability,
>    power efficiency, security and other benefits in IPv6 network
>    deployments.  Some of these involve isolating a host (or RA accepting
>    client node) so that the host is the only node to receive a specific
>    prefix, including
>
>    o  DHCPv6 Prefix Delegation to hosts (<https://tools.ietf.org/html/
>       draft-templin-v6ops-pdhost>), and
>
>    o  advertising a unique prefix per host via unique RAs.
>       (<https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-
>       per-host>).

it makes sense to add:

    o  Prefix Delegation extensions to ND protocol have been introduced
       in <draft-kaiser-nd-pd-02>, <draft-lutchann-ipv6-delegate-
       option-00> and <draft-haberman-ipngwg-auto-prefix-02>, and
       probably earlier.

Alex

Le 04/03/2017 à 06:31, Alexandre Petrescu a écrit :
> I do not oppose a slot presenting PIO-X if time allows.
>
> However, as I understand it, PIO-X has a single goal - that to
> accomodate 64share.
>
> I wonder whether PIO-X could work with DHCPv6-PD?  Would PIO-X help
> DHCPv6-PD deployment?
>
> This is what I am going to ask at the mic.
>
> Alex
>
>
>
> Le 01/03/2017 à 11:27, Erik Kline a écrit :
>> Ole,
>>
>> It's on me to get a -02 of PIO-X written and uploaded.  Might it be
>> possible to get 5 minutes on that?
>>
>> -ek
>>
>> On 27 February 2017 at 06:16, <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     The 6MAN chairs are planning the meeting in Chicago at IETF98.
>>
>>     If you have a draft you would like to discuss, please send your
>>     request for agenda time to the 6man chairs.   Please include in the
>>     request, the title of the presentation, file name of the draft, the
>>     speaker's name (and email), and how much time you would like.
>>
>>     We will prioritise drafts that are working group items and drafts
>>     that have been actively discussed on the list.
>>
>>     We expect at least half of each talk’s presentation time to be used
>>     for open discussion,
>>     please plan your presentation accordingly.
>>
>>     New drafts not discussed on the mailing list prior to the meeting,
>>     or drafts that do not appear to have support from the working group
>>     are unlikely to get time at the meeting.
>>
>>     Please have agenda items to us by 2017-03-15.
>>
>>     Regards,
>>
>>     Bob & Ole
>>
>>     --------------------------------------------------------------------
>>     IETF IPv6 working group mailing list
>>     [email-masked] <mailto:[email-masked]>
>>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>     <https://www.ietf.org/mailman/listinfo/ipv6>
>>     --------------------------------------------------------------------
>>
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 30 Mar 2017 10:48:59 -0500

Hi, authors of PIO-X,

My comment on the microphone:

This is an earlier draft I co-authored that uses RS/RA messages to do 
Prefix Delegation.

draft-kaiser-nd-pd-02

https://tools.ietf.org/html/draft-kaiser-nd-pd-02

I can resurrect it if necessary.

Alex

Le 28/03/2017 à 11:57, Alexandre Petrescu a écrit :
> <mailto:[email-masked]>
> >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >>
> >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>

---

From: Erik Kline <[email-masked]>
Date: Thu, 30 Mar 2017 18:18:15 -0500

I failed to explain myself at the mic, but I am thinking I need to state in
the document is the following:

    PIO-X and DHCPv6 PD are orthogonal

A network can serve a client a PIO-X *and* simultaneously answer any PD
requests from the same client.  They are not mutually exclusive nor are
they redundant.

In the model we tried to describe in the applicability statement, the
client has attached to the network, issued a vanilla RS, and the router
(perhaps doing PD on the client's behalf, or radius/diameter, or whatever)
has selected to send the client a PIO.  The extra bit just tells the client
that the PIO is not going to be given to anyone else (subject to various
lifetimes, etc).

If the client doesn't understand the X flag then it can still process the
PIO according to its existing code.  That's all.  No conflict with PD,
really.

On 30 March 2017 at 10:48, Alexandre Petrescu <[email-masked]>
wrote:

> IETF IPv6 working group mailing [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Fri, 31 Mar 2017 13:57:06 +0200

>requests from the same client.  They are not mutually exclusive nor are

We should try to avoid a situation like we currently have with DNS resolver
configuration. So if PIO-X has considerable overlap with PD then it is 
probably a bad idea.

Let me put up a strawman counter proposal. Instead of allocating a /64 to each
host, in my proposal a router allocates a /63. One /64 of the /63 will be
announced in the RA for SLAAC. The other will be available for PD. An 
unmodified host will use addresses from the SLAAC prefix. A PD aware client
will use addresses from the PD prefix.

The nice thing about PD is that is is future proof. If the 'host' has 
downstream interfaces, it can request additional prefixes using PD and
assign them to any downstream interfaces. The disadvanced of this proposal 
is that is wastes one bit.

(I guess the main worry is that this will grow out to general PD using RAs)

There is however one area where this proposal can do better than PD (but
currently it doesn't seem to do that).

The problem with PD for hosts is that actually forwarding packets to addresses
cover by the prefix is mostly undefined.

When a router receives a prefix using PD, when can expect the router to inject
the prefix in the local routing protocol and there is no issue with forwarding
traffic.

Hosts don't do that. Experience with CPEs that are required to behave as
hosts on their upstream interface shows that this leads to a lot of confusion.

So questions that I think this draft should clearly answer are

1) What happens if a router is rebooted? Does it have to store state on
   stable storage? Is there a way to signal to the host that it needs to do
   something. How does a router know the next hop for prefixes it handed out
   in the past. Can a router assign a new prefix to a host or does that
   have to be static/stable storage?

2) What happens if a host has a 'privacy event' and renumbers its MAC address,
   link local address and all IIDs. 

I think for 2) the draft currently says that this is not allowed, but I guess
that can be fixed.

I think for 1) the draft need to have clear enough language that implementors
will get it right. Otherwise we get the same mess as currently with PD.
There may be a simple way to fix 1) as well.

---

From: David Farmer <[email-masked]>
Date: Fri, 31 Mar 2017 07:36:16 -0500

I would say "might be" or "can be" orthogonal;  in my opinion, it would be
unfortunate and kind of pointless for a network to provide a /64 with PIO-X
and then only offer a /64 prefix through DHCPv6-PD, and in my opinion this
would be over-lapping, and not orthogonal.  However, if a network provided
a /64 via PIO-X and offered a /60, /56, or larger, prefix via DHCPv6-PD
that would make a lot of sense to me and would be orthogonal.

A question; would it be valid for a network offer a /64 via PIO-X and then
offer the /56 encompassing the /64 via DHCPv6-PD, I think it would be good
to cover this case, stating if it is valid or not, in any discussion of
concurrent use of PIO-X with DHCPv6-PD. I can see where some would think
it's a valid case, and others would not, clearly stating it's one way or
the other seems like a good idea in my opinion.

On Thu, Mar 30, 2017 at 6:18 PM, Erik Kline <[email-masked]> wrote:

> I failed to explain myself at the mic, but I am thinking I need to state
> in the document is the following:
>
> On 30 March 2017 at 10:48, Alexandre Petrescu <
> [email-masked]> wrote:
>
>> Hi, authors of PIO-X,
>>

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 31 Mar 2017 15:06:58 +0200 (CEST)

On Fri, 31 Mar 2017, David Farmer wrote:

> A question; would it be valid for a network offer a /64 via PIO-X and 
> then offer the /56 encompassing the /64 via DHCPv6-PD, I think it would 
> be good to cover this case, stating if it is valid or not, in any 
> discussion of concurrent use of PIO-X with DHCPv6-PD. I can see where 
> some would think it's a valid case, and others would not, clearly 
> stating it's one way or the other seems like a good idea in my opinion.

Having a /64 WAN prefix which is the first /64 in a PD /56 is a perfectly 
valid deployment case. That's the whole point of RFC6603 "PD exclude".

"The prefix exclusion mechanism is targeted at deployments where
    DHCPv6-based prefix delegation is used, but a single aggregated
    route/prefix has to represent one customer, instead of using one
    prefix for the link between the delegating router and the requesting
    router and another prefix for the customer network.  The mechanism
    defined in this specification allows a delegating router to use a
    prefix out of the delegated prefix set on the link through which it
    exchanges DHCPv6 messages with the requesting router, and is intended
    for use in networks where each requesting router is on its own
    layer-2 domain."

Using PIO-X on the /64 WAN RA is optional, but would be perfectly suited 
for this deployment scenario if all other aspects are fulfilled.

I don't see any argument why it would not valid, what would the arguments 
be for it not being valid use-case?

The only thing I can imagine is that when using PIO-X for the /64, you're 
basically anyway delegating the entire /56 to the device so why not just 
use the unnumbered model (TR-177 and RFC7084 WAA-7).

-- 
Mikael Abrahamsson    email: [email-masked]