Subject: Re: PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01 and earlier draft-kaiser-nd-pd-02

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Apr 2017 11:17:42 -0400

Erik Kline <[email-masked]> wrote:
    > 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.

So, a client that doesn't understand the X bit will just think it's sharing
the link with other non-existant nodes, and will waste energy.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Apr 2017 12:50:47 -0400

> the link with other non-existant nodes, and will waste energy.

I remembered what was bothering me:  a client that doesn't understand the X
bit might be surprised that there is no router on the link with that
prefix.    Generally, clients configure default routes via LL addresses,
so I think that we are okay.

You say in section 5.3 that L=0, A=1 as SHOULD.
Is there a reason you wouldn't make that a MUST?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 3 Apr 2017 18:56:15 +0200 (CEST)

On Mon, 3 Apr 2017, Michael Richardson wrote:

> I remembered what was bothering me:  a client that doesn't understand 
> the X bit might be surprised that there is no router on the link with 
> that prefix.  Generally, clients configure default routes via LL 
> addresses, so I think that we are okay.

I have never seen a default route learnt by RA point to anything apart 
than the router LL address.

https://tools.ietf.org/html/rfc4861#page-19

4.2.  Router Advertisement Message Format
...
Source Address
                      MUST be the link-local address assigned to the
                      interface from which this message is sent.

So this can't happen any other way, right?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: james woodyatt <[email-masked]>
Date: Mon, 3 Apr 2017 14:41:12 -0700

> so I think that we are okay.

The draft makes no mention of it, but section 2.8 of RFC 4291 requires all routers to recognize the Subnet-Router anycast address for every subnet prefix it has advertised on the link. One imagines that a router sending PIO-X subnet prefixes to hosts would be therefore required to recognize the Subnet-Router anycast address for each one.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Apr 2017 20:25:47 -0400

Mikael Abrahamsson <[email-masked]> wrote:
    >> prefix.  Generally, clients configure default routes via LL addresses, so I
    >> think that we are okay.

    > I have never seen a default route learnt by RA point to anything apart than
    > the router LL address.

I believe I have, and I'm uncertain when/where; maybe they were statically configured.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 5 Apr 2017 09:17:07 +0200

Le 05/04/2017 à 02:25, Michael Richardson a écrit :
>>> I remembered what was bothering me:  a client that doesn't
>>> understand the X bit might be surprised that there is no router
>>> on the link with that prefix.  Generally, clients configure
>>> default routes via LL addresses, so I think that we are okay.
>
>> I have never seen a default route learnt by RA point to anything
>> apart than the router LL address.
>

In my setting most manually configured default routes are to ULAs, not
LLs, because these latter change each time the line cards change.

For the default route learnt from RA - indeed - can only be LL, as there
is no field in RA specifying the address to be used as default router
(it's got from the src field).  Maybe we want one(?)

Alex

>
> -- Michael Richardson <[email-masked]>, Sandelman Software
> Works -= IPv6 IoT consulting =-
>
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 5 Apr 2017 17:11:43 +0900

On Tue, Apr 4, 2017 at 6:41 AM, james woodyatt <[email-masked]> wrote:
>
> The draft makes no mention of it, but section 2.8 of RFC 4291 requires all
> routers to recognize the Subnet-Router anycast address for every subnet
> prefix it has advertised on the link. One imagines that a router sending
> PIO-X subnet prefixes to hosts would be therefore required to recognize the
> Subnet-Router anycast address for each one.
>

No, the RFC requires that the router recognize "the Subnet-Router Anycast
addresses for all interfaces for which it is configured to act as a
router". Because the router MUST NOT form any addresses in the PIO-X
subnet, there is no subnet-router anycast to configure in that subnet. The
host receiving the PIO-X prefix should recognize it instead, if forwarding
is turned on.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 5 Apr 2017 17:13:46 +0900

On Fri, Mar 31, 2017 at 9:36 PM, David Farmer <[email-masked]> wrote:

> 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.
>

Remember that the use case for this option is for networks that today
provide an entire /64, such as 3GPP networks and IPv6-prefix-per-host
networks. I agree that if the network already provides a /64 or more via
DHCPv6 PD, and the clients use it, there is no need to use PIO-X.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Apr 2017 11:50:42 -0400

Lorenzo Colitti <[email-masked]> wrote:
    > networks. I agree that if the network already provides a /64 or more
    > via DHCPv6 PD, and the clients use it, there is no need to use PIO-X.

A problem is that: RFC7204 and
https://www.broadband-forum.org/technical/download/TR-187_Issue-2.pdf

don't say a lot about what the upstream provider can expect from the
CPE.  Both say what the CPE should try, since they don't know what the
provider provides.

So it's unclear in the PPP(oE) case if we even need to number the PPP
link *at all*.  If the provider knew that the CPE would do DHCPv6 PD,
and number itself from the result, then it could avoid putting any PIO
into the RA on the PPP link.

I think that PIOX provides a nice compromise: clueful CPEs can use the
/64 for themselves (or for downstream tethering), and come back with
DHCPv6PD if they need more, and unaware ones will just use it for the
link.

It seems that if a PD occurs, that it ought to overlap the prefix given
out by PIOX, and use 6603.  I think we should recommend this a BCP for
some spaces.   I think that on 3GPP, that it MAY be a bad idea, because
the ISP has to reserve too much space for each customer (double to 16x the
space), and they may never (or infrequently) ever need the PD.

---

From: Fred Baker <[email-masked]>
Date: Wed, 5 Apr 2017 14:25:47 -0700

> On Apr 5, 2017, at 12:17 AM, Alexandre Petrescu <[email-masked]> wrote:
> 

In that particular case, RFC 8028 suggests using the source address from the IPv6 header.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Apr 2017 18:24:54 +0200

> In that particular case, RFC 8028 suggests using the source address from the IPv6 header.

But the src address of the IPv6 header of an RA can only be an LL 
address (can not be ULA or GUA), I think.

Alex