Subject: draft-pioxfolks-6man-pio-exclusive-bit-02.txt

From: DY Kim <[email-masked]>
Date: Mon, 8 Jan 2018 10:26:36 +0900

Hi,

Could anyone enlighten me on the status of this document? Is the issue still being pushed? Or is the issue put away from the WG?

draft-pioxfolks-6man-pio-exclusive-bit-02.txt

---
DY

---

From: james woodyatt <[email-masked]>
Date: Mon, 8 Jan 2018 11:41:55 -0800

On Jan 7, 2018, at 17:26, DY Kim <[email-masked]> wrote:
> 
> draft-pioxfolks-6man-pio-exclusive-bit

"Expires: September 28, 2017”

Looks to me like one of a group of dead stones all proposing similar advances. Maybe their authors are waiting to see if they have any aji.

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

---

From: Ole Troan <[email-masked]>
Date: Tue, 9 Jan 2018 15:21:12 +0100

Given that the majority on this list aren't native speakers of the English language, I would encourage everyone to avoid colloquialisms.
At least I don't get the reference to "dead stones" or "aji".

Cheers,
Ole

> On 8 Jan 2018, at 20:41, james woodyatt <[email-masked]> wrote:
> 
> --james woodyatt <[email-masked]>
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 09 Jan 2018 16:28:34 +0100

+1

Is not only for this list, I think it will be very useful in IETF exploders to remember that the majority aren’t native speakers.

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Ole Troan <[email-masked]>
Fecha: martes, 9 de enero de 2018, 15:21
Para: james woodyatt <[email-masked]>
CC: <[email-masked]>
Asunto: Re: draft-pioxfolks-6man-pio-exclusive-bit-02.txt

    Cheers,
    Ole

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 9 Jan 2018 15:42:31 +0000

> Given that the majority on this list aren't native speakers of the English
> language, I would encourage everyone to avoid colloquialisms.

I suspect most native speakers of English aren't familiar with these terms either. They're metaphors from the Japanese game of Go, and are not English-language colloquialisms (i.e., Go metaphors are not commonly used in English -- at least not where I'm from). 
Barbara

> > Looks to me like one of a group of dead stones all proposing similar
> advances. Maybe their authors are waiting to see if they have any aji.
> >
> >

---

From: Alejandro Acosta <[email-masked]>
Date: Tue, 9 Jan 2018 12:23:33 -0400

right.., and sometimes colloquialisms often are used only in certain
regions.

---

From: james woodyatt <[email-masked]>
Date: Tue, 9 Jan 2018 09:59:24 -0800

On Jan 8, 2018, at 11:41, james woodyatt <[email-masked]> wrote:
> On Jan 7, 2018, at 17:26, DY Kim <[email-masked] <mailto:[email-masked]>> wrote:
>> 

My apologies for the cryptic metaphor. I should have more expressed myself more plainly.

I meant to say: this expired draft is similar to others the working group has seen over the years, and while the group does not currently seem to be discussing or expressing much in the underlying concepts, the topic seems to recur with sufficient frequency that the authors may be waiting for the periodic resurgence of interest in such concepts to refresh the draft or combine it with others to make a newly refined proposal.

More words, but perhaps more comprehensible.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 9 Jan 2018 19:49:18 +0000

Hi James,

I was thinking too that some kind of document combination could find traction
until I realized that DHCPv6 Prefix Delegation messages could be combined with
IPv6 ND RS/RA messages as a single unified service instead of two independent
services. All it would take would be the definition of a new IPv6 ND message
option code. I have a draft out on this:

https://datatracker.ietf.org/doc/draft-templin-6man-dhcpv6-ndopt/

Thanks - Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of james woodyatt
Sent: Tuesday, January 09, 2018 9:59 AM
To: DY Kim <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-pioxfolks-6man-pio-exclusive-bit-02.txt

On Jan 8, 2018, at 11:41, james woodyatt <[email-masked]<mailto:[email-masked]>> wrote:
On Jan 7, 2018, at 17:26, DY Kim <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: David Farmer <[email-masked]>
Date: Tue, 9 Jan 2018 14:12:25 -0600

Well actually I think this was waiting on a couple things;

First was draft-ietf-v6ops-unique-ipv6-prefix-per-host which is now RFC8273
https://tools.ietf.org/html/rfc8273

The other was draft-ietf-6man-ndpioiana, which just completed last call
https://tools.ietf.org/html/draft-ietf-6man-ndpioiana

So, personally I'd like to see this one get moving again, I'd suggest a
rewrite it to not update RFC4861 but to add the flag to the registry that
will be created shortly assuming the IESG progresses
draft-ietf-6man-ndpioiana.

Thanks.

On Tue, Jan 9, 2018 at 11:59 AM, james woodyatt <[email-masked]> wrote:

> I meant to say: this expired draft is similar to others the working group
> has seen over the years, and while the group does not currently seem to be
> discussing or expressing much in the underlying concepts, the topic seems
> to recur with sufficient frequency that the authors may be waiting for the
> periodic resurgence of interest in such concepts to refresh the draft or
> combine it with others to make a newly refined proposal.
>

-- 
===============================================
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: DY Kim <[email-masked]>
Date: Wed, 10 Jan 2018 07:25:31 +0900

As a one from North-East Asia (FEA), I find sometimes interesting or even a bit baffled that almost everything from this area is known to the westerners to be of Japanese origin. Perhaps, similarly like everything odd or peculiar is called ‘French’ in the western world…?

I’m not a Chinese, but, to be fair, many things in this area could be ascribed to China as the origin, like this Go. 

It is to be admitted, though, Japanese terms seem to be a global norm by now, perhaps because many NEA cultural things have been introduced through Japan during the modern times…

On the other hand, it is not to be believed that everything is of Chinese origin, for the culture in this area consists roughly of peasant-origin (Han-Chinese) and nomad-origin (Mongols, Manchu, Corea, Japan, …).

…

---
DY

> On 10 Jan 2018, at 00:42, STARK, BARBARA H <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Wed, 10 Jan 2018 07:34:11 +0900

Fortunately, I had gotten the point. In the emerging AI era, it might not hurt if people get more familiar with the game Go, like many have been with Chess…

https://en.wikipedia.org/wiki/AlphaGo_versus_Lee_Sedol

https://en.wikipedia.org/wiki/List_of_Go_terms#Aji

---
DY

> On 10 Jan 2018, at 02:59, james woodyatt <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Jan 2018 11:36:17 +1300

Yes, according to Wikipedia Go "was invented in ancient China more than 2,500 years ago". (Also: "Chess is believed to have originated in India sometime before the 7th century... (A minority view holds that chess originated in China.)"

Regards
   Brian

---

From: DY Kim <[email-masked]>
Date: Wed, 10 Jan 2018 07:46:39 +0900

As far as I know, a number of documents deal with similar problems:

  https://tools.ietf.org/html/rfc8273
  https://tools.ietf.org/html/draft-templin-v6ops-pdhost-18
  https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusive-bit-02
  https://datatracker.ietf.org/doc/draft-templin-6man-dhcpv6-ndopt/

I thought it might be a good idea to tackle the problem space in a common pool and possibly combine/merge some of these (and other) related documents into a single one or into a more organized series.
  
---
DY

> On 10 Jan 2018, at 04:49, Templin, Fred L <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Wed, 10 Jan 2018 07:47:39 +0900

…. personally, doubt it…

---
DY

> On 10 Jan 2018, at 07:36, Brian E Carpenter <[email-masked]> wrote:
> 
> A minority view holds that chess originated in China.

---

From: DY Kim <[email-masked]>
Date: Wed, 10 Jan 2018 07:52:30 +0900

In fact, Chess is similar to the Chinsese Xiangqi.

  https://en.wikipedia.org/wiki/Xiangqi

So similar that… the minority opinion could be the truth.

A theory could be that, since Europeans obviously cannot understand the Chinese characters, they instead formed shapes to each play roles… ; horses, soldier, queen… etc…

---
DY

> On 10 Jan 2018, at 07:47, DY Kim <[email-masked]> wrote:
> 
> …. personally, doubt it…
> 
> ---
> DY
>

---

From: Bob Hinden <[email-masked]>
Date: Tue, 9 Jan 2018 15:06:08 -0800

David,

> On Jan 9, 2018, at 12:12 PM, David Farmer <[email-masked]> wrote:
> 

draft-ietf-6man-ndpioiana  should being going to the IESG in a day or so.  I am finishing up the writeup and expecting a new draft from the author.

Bob

> 
> So, personally I'd like to see this one get moving again, I'd suggest a rewrite it to not update RFC4861 but to add the flag to the registry that will be created shortly assuming the IESG progresses draft-ietf-6man-ndpioiana.
> 
> Thanks.
> 
> 
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 10 Jan 2018 12:15:54 +0100 (CET)

On Tue, 9 Jan 2018, David Farmer wrote:

> rewrite it to not update RFC4861 but to add the flag to the registry 
> that will be created shortly assuming the IESG progresses 

thanks for the support. As a co-author, I still believe the X bit is of 
use in several cases.

Me and Erik are going to have a chat on how we would like to proceed 
(we've both been on vacation), but as you stated in your email, things 
have now progressed that clears some issues we were not sure how to 
handle, and also some deployment scenarios are now RFC where the X bit 
might be of use.

So we welcome other feedback and support/suggestions for the draft. For 
instance, should we keep the draft just describing the on-wire format and 
what hosts should do, and leave out how/why the router does what it does 
etc? There is quite a lot of text about router internal state machines 
etc, which strictly is not needed for a draft that describes the on-wire 
format and what hosts should do when they get one of these.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: DY Kim <[email-masked]>
Date: Thu, 11 Jan 2018 06:49:45 +0900

In order to keep the idea generically applicable to other use cases, it might be better to confine the draft to its core part, I’d think.

As for the associated router as well as host behaviors, in which I might be quite interested, might better be dealt with in a separate document, I’d think.

After all is done, we might know how much of the drafts be ultimately incorporated into the IPv6 ND itself.

Just my quick thought.

---
DY

> On 10 Jan 2018, at 20:15, Mikael Abrahamsson <[email-masked]> wrote:
> 
> For instance, should we keep the draft just describing the on-wire format and what hosts should do, and leave out how/why the router does what it does etc? There is quite a lot of text about router internal state machines etc, which strictly is not needed for a draft that describes the on-wire format and what hosts should do when they get one of these.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 11 Jan 2018 09:53:30 +0900

> draft-ietf-6man-ndpioiana.

Before we start discussing this again, let's consider whether we want to
have another /64 debate.

If we start discussing this proposal, I suspect we'll find that there is a
camp that will insist that any per-host prefix MUST be /64 (or /64 or
shorter), and another camp that says that the prefix length should be
determined by the network and can be any length up to and including /128.

If that ends up happening, it is likely that we'll never reach consensus
and thus discussing this proposal could just end up being a waste of the
WG's time.

---

From: DY Kim <[email-masked]>
Date: Thu, 11 Jan 2018 09:57:49 +0900

I’d suggest to start the discussion, first under the condition that the per-host prefix be /64.

As for the other option, I’d suggest we take the issue separately and take more time to tackle, like as a ‘Classless IPv6’ topic.

---
DY

> On 11 Jan 2018, at 09:53, Lorenzo Colitti <[email-masked]> wrote:
> 
> Before we start discussing this again, let's consider whether we want to have another /64 debate.
> 
> If we start discussing this proposal, I suspect we'll find that there is a camp that will insist that any per-host prefix MUST be /64 (or /64 or shorter), and another camp that says that the prefix length should be determined by the network and can be any length up to and including /128.
> 
> If that ends up happening, it is likely that we'll never reach consensus and thus discussing this proposal could just end up being a waste of the WG's time.

---

From: Erik Kline <[email-masked]>
Date: Thu, 11 Jan 2018 09:58:28 +0900

On 11 January 2018 at 09:53, Lorenzo Colitti <[email-masked]> wrote:
> If that ends up happening, it is likely that we'll never reach consensus and
> thus discussing this proposal could just end up being a waste of the WG's
> time.

This is the real reason I personally have been holding off on any
updates.  Hallway conversations where folks mentioned wanting to use
PIO-X to send /80s to hosts dredged up all this again for me, and I
didn't want to participate in furthering it.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Jan 2018 14:45:55 +1300

> As for the other option, I’d suggest we take the issue separately and take more time to tackle, like as a ‘Classless IPv6’ topic.

IPv6 routing is already classless [BCP198, https://tools.ietf.org/html/rfc7608]. I don't really see why we'd make any assumption about prefix length when discussing a PIO bit assignment. If they are not completely orthogonal questions, there's a design error of some kind.

   Brian

---

From: Erik Kline <[email-masked]>
Date: Thu, 11 Jan 2018 13:17:29 +0900

But the issue at hand isn't really routing; it's addressing.

---

From: David Farmer <[email-masked]>
Date: Wed, 10 Jan 2018 23:37:14 -0600

On Wed, Jan 10, 2018 at 6:58 PM, Erik Kline <[email-masked]> wrote:

> that
> and

I like what RFC8273 says, it's currently a /64 prefix. Saying more than
that is asking for an argument, and I suspect you will get it.

Furthermore, with the A flag set, for the prefix to be anything other than
/64 requires updating all implementations of SLAAC, not just adding a new
flag in the RA. In theory, you could have a prefix of any length with the A
flag cleared and and the X flag set, but then someone needs to tell me how
a host is suppose to generate an IID to go with the prefix. There is no
need to update SLACC to let a host know the prefix is exclusively allocated
to it.

I suspect we will eventually update SLACC to allow the auto generation of
addresses for prefixes other that /64, but for now that is the effective
requirement. There is no good reason to change that as part of this work.

Something we might want to consider as part of this work is to allow
unicast unsolicited RAs with X=1.  For backwards compatibility, you might
want to have the host respond to the solicited RA, which can already be
unicast. If the host responds then the router can send the unsolicited RAs
via unicast. Instead of sending the unsolicited RAs as an ip-layer (layer
3) multicast to the all-nodes group but using RFC6085 and the unicast
link-layer (layer2) destination of the host receiving the exclusive use
prefix as described in RFC8273. If the host doesn't respond then the
unsolicited RAs should be sent as described in RFC8273.

That way the X flag signals to the host that the prefix is for its
exclusive use, and the host signals back to send future unsolicited RAs via
unicast. If the host doesn't understand the X flag it won't signal back and
the unsolicited RAs are sent as described in RFC8273.

Thanks.

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

---

From: Erik Kline <[email-masked]>
Date: Thu, 11 Jan 2018 17:06:25 +0900

On 11 January 2018 at 14:37, David Farmer <[email-masked]> wrote:
> I like what RFC8273 says, it's currently a /64 prefix. Saying more than that
> is asking for an argument, and I suspect you will get it.
>
> flag cleared and and the X flag set, but then someone needs to tell me how a
> host is suppose to generate an IID to go with the prefix. There is no need
> to update SLACC to let a host know the prefix is exclusively allocated to
> it.
>
> Something we might want to consider as part of this work is to allow unicast
> unsolicited RAs with X=1.  For backwards compatibility, you might want to
> have the host respond to the solicited RA, which can already be unicast. If
> the host responds then the router can send the unsolicited RAs via unicast.
> Instead of sending the unsolicited RAs as an ip-layer (layer 3) multicast to
> the all-nodes group but using RFC6085 and the unicast link-layer (layer2)
> destination of the host receiving the exclusive use prefix as described in
> RFC8273. If the host doesn't respond then the unsolicited RAs should be sent
> as described in RFC8273.
>
> That way the X flag signals to the host that the prefix is for its exclusive
> use, and the host signals back to send future unsolicited RAs via unicast.
> If the host doesn't understand the X flag it won't signal back and the
> unsolicited RAs are sent as described in RFC8273.

There is a kind of conflation of things with this -X flag.  In the
RFC8273 case the signal the client needs is "you are the only
non-infrastructure node on this link (unless I (we), the router(s),
give you an ND redirect telling you otherwise)", no matter how client
isolation is actually implemented.  And in this sense it feels like it
should be a flag in the RA EFO.

It's only a minor leap from there to also say "and oh BTW nobody but
you, gentle client node, will be using this PIO so feel free to
address yourself with abandon".

Having just a PIO-X flag instead opens up a universe of complexity,
for those who want to implement and support it, to try to be super
clever and deliver unique RAs per client and so forth.

These are subtly different signals.  I often find myself kinda leaning
in favor of the former, as the latter seems fraught with peril.

---

From: Ole Troan <[email-masked]>
Date: Thu, 11 Jan 2018 09:34:35 +0100

> clever and deliver unique RAs per client and so forth.

The PIO-X came out of the realisation that it was all point to point links anyway (I know there are exceptions, but bear with me).
I.e. we stop emulating a broadcast medium and map the IP network directly to the "physical" topology.
Imagine what happens if you move IP forwarding to the edge, and do IP forwarding on the wireless access point, or on the last bridge connecting the hosts.

Iff you are in that scenario, you can do a few optimisations. The router can skip address resolution, pretty much most of ND (the host's prefix is an entry in the FIB with the nexthop being the host's link-local address as opposed to an entry pointing to a glean adjacency). Now if you gotten to this point, you might as well inform the node at the other end about it, so that the node can use the prefix any which way it likes, including numbering other links (or VMs or whatever).

Ole

---

From: Erik Kline <[email-masked]>
Date: Thu, 11 Jan 2018 17:45:29 +0900

> Iff you are in that scenario, you can do a few optimisations. The router can skip address resolution, pretty much most of ND (the host's prefix is an entry in the FIB with the nexthop being the hos…

These were indeed the motivations for the work.

In the time since it was first presented, however, it's become clear
to me that some folks may just want to use it to give /80s, /96s,
/120s, etc to hosts.

---

From: DY Kim <[email-masked]>
Date: Thu, 11 Jan 2018 18:55:47 +0900

That jar is already open through RFC8273, isn’t it? Am I mistaken?

---
DY

> On 11 Jan 2018, at 17:45, Erik Kline <[email-masked]> wrote:
>

---

From: Erik Kline <[email-masked]>
Date: Thu, 11 Jan 2018 19:03:51 +0900

Nope.  https://tools.ietf.org/html/rfc8273#section-4 refers
specifically to a /64.  Anything else would have required host-side
changes.

---

From: DY Kim <[email-masked]>
Date: Thu, 11 Jan 2018 19:05:54 +0900

Or if I’m mistaken on this point, then why not mandate in your draft that the use of the scheme is limited to the case of /64, if you’re worried about the mal-use you’re not supporting.

---
DY

> On 11 Jan 2018, at 18:55, DY Kim <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Thu, 11 Jan 2018 19:06:32 +0900

OK, I’m mistaken.

---
DY

> On 11 Jan 2018, at 19:03, Erik Kline <[email-masked]> wrote:
>

---

From: Ole Troan <[email-masked]>
Date: Thu, 11 Jan 2018 11:12:55 +0100

Erik,

> to me that some folks may just want to use it to give /80s, /96s,

I think, as Brian also so eloquently said, that the prefix length is an orthogonal issue to defining PIO-X.

Best regards,
Ole

---

From: DY Kim <[email-masked]>
Date: Thu, 11 Jan 2018 19:14:26 +0900

With no intention to fire another thread of debate….

Then, does this roughly mean that we have a situation that the IPv6 Addressing is glassful while the IPv6 routing is classless?

---
DY

> On 11 Jan 2018, at 13:17, Erik Kline <[email-masked]> wrote:
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 11 Jan 2018 19:33:16 +0900

> orthogonal issue to defining PIO-X.

The question is whether there is rough consensus that it's orthogonal. I
definitely don't think so. We shouldn't be defining an option that allows
networks to limit hosts to only one IP address, for example.

---

From: Ole Troan <[email-masked]>
Date: Thu, 11 Jan 2018 12:03:19 +0100

> The question is whether there is rough consensus that it's orthogonal. I definitely don't think so. We shouldn't be defining an option that allows networks to limit hosts to only one IP address, for example.

This line of reasoning can be used to block just about any work in the IETF.
While we, as the IETF, as far as possible should try to ensure a balance in our technical specifications to allow the tussle to play out fairly, I think your arguments have taken this outside of IETF's remit.

Let's discuss the document on its merits.
And may I suggest that we avoid reopening the 64-bit boundary debate.

Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 11 Jan 2018 11:21:11 +0000

On Thu, 11 Jan 2018, 20:03 Ole Troan, <[email-masked]> wrote:

> While we, as the IETF, as far as possible should try to ensure a balance
> in our technical specifications to allow the tussle to play out fairly, I
> think your arguments have taken this outside of IETF's remit.
>

It's not outside the IETF's remit. IETF best practices say that one IP
address per host is not recommended. Why would we define a mechanism to
assign IP addresses that does not follow these best practices?

> And may I suggest that we avoid reopening the 64-bit boundary debate.

Unfortunately I don't think we can separate the merits of this document
from that debate.

---

From: DY Kim <[email-masked]>
Date: Thu, 11 Jan 2018 20:32:33 +0900

This draft is about assigning an exclusive prefix, not just a single address, as I read it.

---
DY

> On 11 Jan 2018, at 20:21, Lorenzo Colitti <[email-masked]> wrote:
> 
> It's not outside the IETF's remit. IETF best practices say that one IP address per host is not recommended. Why would we define a mechanism to assign IP addresses that does not follow these best practices?
> 
> Unfortunately I don't think we can separate the merits of this document from that debate.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 11 Jan 2018 20:47:08 +0900

Right. Hence my earlier assertion that we will disagree on what length of
prefixes should be allowed. A single address is just a prefix of length 128.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Jan 2018 13:12:11 +0100

Le 11/01/2018 à 01:53, Lorenzo Colitti a écrit :
> On Wed, Jan 10, 2018 at 5:12 AM, David Farmer <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     So, personally I'd like to see this one get moving again, I'd
>     suggest a rewrite it to not update RFC4861 but to add the flag to
>     the registry that will be created shortly assuming the IESG
>     progresses draft-ietf-6man-ndpioiana.
> 
> 
> If we start discussing this proposal, I suspect we'll find that there is 
> a camp that will insist that any per-host prefix MUST be /64 (or /64 or 

There is an additional dimension than just the /64 vs arbitrary length.

DHCPv6 already has a "Prefix Exclude" option.  It's trialled in mobile 
networks and required by 3GPP.

Let us use it.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Jan 2018 13:16:38 +0100

> This draft is about assigning an exclusive prefix, not just a single address, as I read it.

Yes, and there is another way to assign a prefix to a Host, which is 
exclusive for that Host (and not for the link).

That means is DHCPv6 Prefix Delegation with Prefix Exclude option.

Why making another way to do it?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Jan 2018 13:34:57 +0100

Le 11/01/2018 à 11:14, DY Kim a écrit :
> Then, does this roughly mean that we have a situation that the IPv6
> Addressing is classful while the IPv6 routing is classless?

Roughly.

And since you and others put it that way, let's give a name to them: 
"class 64" addresses.

Class 64 addresses are formed from a prefix and Interface ID whose 
length is 64, respectively.

Routing to class 64 addresses could be classful or could be classless.

IP/MAC resolution protocol with class 64 addresses could be classful or 
could be classless.

This ambiguity some advantages and some inconvenients.

Alex

---

From: DY Kim <[email-masked]>
Date: Thu, 11 Jan 2018 21:35:20 +0900

Less than and equal to 64.

---
DY

> On 11 Jan 2018, at 20:47, Lorenzo Colitti <[email-masked]> wrote:
> 
> Right. Hence my earlier assertion that we will disagree on what length of prefixes should be allowed.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Jan 2018 13:40:34 +0100

> Less than and equal to 64.

But if the prefix length is 63, what is the length of the Interface ID?

On which link is that?

All IP-over-foo RFCs use IID length 64.

Alex

---

From: DY Kim <[email-masked]>
Date: Thu, 11 Jan 2018 21:40:47 +0900

If I’m not wrong, host support of DHCPv6 is not mandatory while SLAAC is.

And moreover, why should it hurt if there’s an alternative. All the better if the market is given more choices….

---
DY

> On 11 Jan 2018, at 21:16, Alexandre Petrescu <[email-masked]> wrote:
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Jan 2018 13:41:40 +0100

Le 11/01/2018 à 11:33, Lorenzo Colitti a écrit :
> On Thu, Jan 11, 2018 at 7:12 PM, Ole Troan <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> definitely don't think so. We shouldn't be defining an option that 
> allows networks to limit hosts to only one IP address, for example.

I agree.

Alex

---

From: DY Kim <[email-masked]>
Date: Thu, 11 Jan 2018 21:45:24 +0900

IID length, 64. The host is given two prefixes for disposal.

If you don’t like this degenerate case, they let the draft confine to /64 only.

My point might be:

  - Let the draft move on.
  - Avoid the IID boundary debate for the time being, as Ole(?) suggested.

---
DY

> On 11 Jan 2018, at 21:40, Alexandre Petrescu <[email-masked]> wrote:
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Jan 2018 13:50:51 +0100

> If I’m not wrong, host support of DHCPv6 is not mandatory while SLAAC

Err?  Is that marked in some RFC that I missed?

But I do agree that numerous smartphones do have SLAAC builtin and if
you want to add DHCP you risk breaking it (through it out of the window, 
even though it costs money).

I also agree that SLAAC has much part built-in in linux and BSD kernels, 
whereas DHCP is mostly in userspace.

> And moreover, why should it hurt if there’s an alternative. All the
> better if the market is given more choices….

I agree having choice is good.

But how to make sure that once that choice is given, i.e. deliver RFC, 
people will actually go and put it in systems?  Will cellular operators 
implement it?  Will smartphones implement it?  Is it easy to implement? 
Will router manufacturers implement in in big proprietary platforms (not 
small open source like OpenWRT)?  Well someone push hard for the doc 
everywhere, and at IETF?

(from my side the answers are: yes, it is easy to implement in radvd and 
in linux kernel; yes, a particular smartphone implementer could do it 
for numerous smartphones; a cellular operator I know may not do it, 
because there is already DHCPv6 Prefix Exclude option; for router 
manufacturers implementing PIO-X in big platforms: I dont know).

Alex

> --- DY

---

From: DY Kim <[email-masked]>
Date: Thu, 11 Jan 2018 21:52:25 +0900

If we limit the scope of this draft to /64, it’s not about a single address anymore; it’s about a prefix with which the host can generate a bunch of addresses.

---
DY

> On 11 Jan 2018, at 21:41, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
>> On Thu, Jan 11, 2018 at 7:12 PM, Ole Troan <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Jan 2018 13:55:31 +0100

> IID length, 64. The host is given two prefixes for disposal.

But I thought the whole point of PIO-X is precisely to just advertise 
one prefix to the Host, not two.

> If you don’t like this degenerate case, they let the draft confine to /64 only.

I agree, along the Intended status.

I agree.

Alex

---

From: DY Kim <[email-masked]>
Date: Thu, 11 Jan 2018 21:58:12 +0900

Why should you bother with such concerns? Whether a choice will be widely used or not should really be a matter of market decision.

---
DY

> On 11 Jan 2018, at 21:50, Alexandre Petrescu <[email-masked]> wrote:
> 
> But how to make sure that once that choice is given, i.e. deliver RFC, people will actually go and put it in systems?  Will cellular operators implement it?  Will smartphones implement it? Is it easy to implement? Will router manufacturers implement in in big proprietary platforms (not small open source like OpenWRT)?  Well someone push hard for the doc everywhere, and at IETF?

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Jan 2018 14:58:51 +0100

Le 11/01/2018 à 13:58, DY Kim a écrit :
> Why should you bother with such concerns? Whether a choice will be
> widely used or not should really be a matter of market decision.

I bother about such concerns because I want the proposals that I support 
to succeed.

I think about all these RFCs that have not succeeded and just sit there.

Alex

>> But how to make sure that once that choice is given, i.e. deliver
>> RFC, people will actually go and put it in systems?  Will cellular
>> operators implement it?  Will smartphones implement it? Is it easy
>> to implement? Will router manufacturers implement in in big
>> proprietary platforms (not small open source like OpenWRT)?  Well
>> someone push hard for the doc everywhere, and at IETF?
> 
>

---

From: Ole Troan <[email-masked]>
Date: Thu, 11 Jan 2018 15:19:18 +0100

> Right. Hence my earlier assertion that we will disagree on what length of prefixes should be allowed. A single address is just a prefix of length 128.

Sigh. We have to be able to separate what's protocol what is policy.
This document does not need to say a single thing about prefix length. Only describe protocol mechanism.

Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 11 Jan 2018 23:38:18 +0900

On Thu, Jan 11, 2018 at 11:19 PM, Ole Troan <[email-masked]> wrote:

> > Right. Hence my earlier assertion that we will disagree on what length
> of prefixes should be allowed. A single address is just a prefix of length
> 128.
>

Do we? The extremely heated discussions we all had on 4291bis suggest that
the we're either not very good at that or do not see it as a goal. And it's
not just in the WG, either - actually, if you recall, the majority of the
controversy happened in IETF last call, /after/ the WG had called the
document done. It went all the way to the IESG before the AD declared lack
of consensus. And all that over a change in the wording around an
ambiguously-defined parameter called the interface identifier.

---

From: Peter Hessler <[email-masked]>
Date: Thu, 11 Jan 2018 15:46:24 +0100

On 2018 Jan 11 (Thu) at 23:38:18 +0900 (+0900), Lorenzo Colitti wrote:
:On Thu, Jan 11, 2018 at 11:19 PM, Ole Troan <[email-masked]> wrote:
:
:> > Right. Hence my earlier assertion that we will disagree on what length
:> of prefixes should be allowed. A single address is just a prefix of length
:> 128.
:>
:> Sigh. We have to be able to separate what's protocol what is policy.
:>
:
:Do we? The extremely heated discussions we all had on 4291bis suggest that
:the we're either not very good at that or do not see it as a goal. And it's
:not just in the WG, either - actually, if you recall, the majority of the
:controversy happened in IETF last call, /after/ the WG had called the
:document done. It went all the way to the IESG before the AD declared lack
:of consensus. And all that over a change in the wording around an
:ambiguously-defined parameter called the interface identifier.

Mandating a /64 as the only acceptable prefix size *in the protocol* is
utterly ridiculous.

-- 
Speak softly and carry a +6 two-handed sword.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 11 Jan 2018 23:55:54 +0900

> Mandating a /64 as the only acceptable prefix size *in the protocol* is

QED.

---

From: David Farmer <[email-masked]>
Date: Thu, 11 Jan 2018 09:08:21 -0600

On Thu, Jan 11, 2018 at 2:06 AM, Erik Kline <[email-masked]> wrote:

> suggest a
> >> > a
> unicast
> exclusive

EFO? I think I'm missing context.

> in favor of the former, as the latter seems fraught with peril.

I'm not entirely getting where you think this should go?

If you set the X flag and send the RA to all hosts, then how do the hosts
know which host the X flag is directed at?

Thanks

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 11 Jan 2018 15:32:38 +0000

Lorenzo Colitti wrote:
> of prefixes should be allowed. A single address is just a prefix of
> length 128.

I'm unclear that we need to have this discussion.  RFC4862 managed to
reach consensus without referring to /64.

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 12 Jan 2018 00:35:15 +0900

> reach consensus without referring to /64.

RFC 4862 was written 10 years ago.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 11 Jan 2018 16:41:53 +0100 (CET)

On Thu, 11 Jan 2018, David Farmer wrote:

> If you set the X flag and send the RA to all hosts, then how do the 
> hosts know which host the X flag is directed at?

They don't. If you're sending an identical RA PIO-X packet to multiple 
hosts then you're going to end up in a situation where things won't work.

The X bit means "you have exclusive use of this PIO". Sending this to 
multiple hosts is wrong.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Jan 2018 16:50:12 +0100

Le 11/01/2018 à 16:35, Lorenzo Colitti a écrit :
> On Fri, Jan 12, 2018 at 12:32 AM, Nick Hilliard <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>> Right. Hence my earlier assertion that we will disagree on what
>> length of prefixes should be allowed. A single address is just a
>> prefix of length 128.
> 
> I'm unclear that we need to have this discussion.  RFC4862 managed
> to reach consensus without referring to /64.
> 
> 

You mean 20 years ago(?)

RFC 4862 year 2007 is protocol working with any prefix length.  It
became so by removing a stronger stance of 64 in RFC 2462 of year 1998,
even if that stance was not that strong at that time either.

In this direction, RFC-PIOX would be even more independent of 64.

Alex

> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Jan 2018 16:17:52 +0000

It seems to me that PIO-X is currently driven completely by the router and the
host is a passive recipient . The host does not ask the router to return an RA
with a PIO-X; the router includes the PIO-X of its own accord.

What about letting the host include a PIO-X in its RS messages as a means of
requesting a prefix, and the router responds with an RA with a corresponding
PIO-X if the host's request was acceptable? That way, the host becomes an
active participant in the prefix delegation procedure.

Thanks - Fred

---

From: David Farmer <[email-masked]>
Date: Thu, 11 Jan 2018 10:26:05 -0600

> The X bit means "you have exclusive use of this PIO". Sending this to

So then we either need to use the technique described in RFC8273 or we need
a protocol change to allow the unicast of unsolicited RAs, which was my
earlier point. I suppose you could eliminate the unsolicited RAs all
together, having the host solicit the RA again and again, but that's a
protocol change too.

Section 5.3,  sender requirements, says;

   When a router transmits an RA containing one or more PIO-X options it
   SHOULD unicast the PIO-X RA to its intended recipient at the IPv6
   layer and, if applicable, at the link-layer.

RFC4861 only allows for the unicast of solicited RAs, unsolicited RA are to
be sent to the all hosts, now you can use the technique described in
RFC8273, but section 5.3 simply says the sender "SHOULD unicast the the
PIO-X RA."  That is an over simplification, I think more details are needed.

Thanks.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Jan 2018 16:41:24 +0000

>So then we either need to use the technique described in RFC8273 or we need a protocol change to allow the unicast of unsolicited RAs, which was my earlier point. I suppose you could eliminate the >unsolicited RAs all together, having the host solicit the RA again and again, but that's a protocol change too.

RFC5214 has it such that all RAs are solicited and unicast. And, the host does
RS/RA repetitively to refresh prefix and default router lifetimes.

Thanks - Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of David Farmer
Sent: Thursday, January 11, 2018 8:26 AM
To: Mikael Abrahamsson <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: draft-pioxfolks-6man-pio-exclusive-bit-02.txt

On Thu, Jan 11, 2018 at 9:41 AM, Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, 11 Jan 2018, David Farmer wrote:
If you set the X flag and send the RA to all hosts, then how do the hosts know which host the X flag is directed at?

They don't. If you're sending an identical RA PIO-X packet to multiple hosts then you're going to end up in a situation where things won't work.

The X bit means "you have exclusive use of this PIO". Sending this to multiple hosts is wrong.

So then we either need to use the technique described in RFC8273 or we need a protocol change to allow the unicast of unsolicited RAs, which was my earlier point. I suppose you could eliminate the unsolicited RAs all together, having the host solicit the RA again and again, but that's a protocol change too.

RFC4861 only allows for the unicast of solicited RAs, unsolicited RA are to be sent to the all hosts, now you can use the technique described in RFC8273, but section 5.3 simply says the sender "SHOULD unicast the the PIO-X RA."  That is an over simplification, I think more details are needed.

Thanks.

David Farmer               Email:[email-masked]<mailto:[email-masked]>

---

From: David Farmer <[email-masked]>
Date: Thu, 11 Jan 2018 10:54:12 -0600

On Thu, Jan 11, 2018 at 10:41 AM, Templin, Fred L <[email-masked]

> >So then we either need to use the technique described in RFC8273 or we
> need a protocol change to allow the unicast of unsolicited RAs, which was
> my earlier point. I suppose you could eliminate the >unsolicited RAs all

Ok, that's another technique that could be specified for use with PIO-X,
but since RFC5214 doesn't update RFC4861, that implies to me currently that
technique is limited only to the scope of RFC5214 (ISATAP).  To my point,
if that technique is to be used generically hosts and routers need to know
when to use it over classic RS/RA with unsolicited RAs.

Thanks.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Jan 2018 17:11:01 +0000

RFC5214 is an example of an “IP-over-foo” (IP over specific link layers) document.
RFC4861 permits IP-over-foo documents to specify operation of the ND protocol
on specific link types:

   “Unless specified otherwise (in a document that covers operating IP
   over a particular link type) this document applies to all link types.”

So, you are right that PIO-X would need to update RFC4861 in order to apply
to general link types that adhere to the letter of RFC4861. But, that would not
be necessary for IP-over-foo documents like ISATAP and AERO.

Thanks - Fred

From: David Farmer [mailto:[email-masked]]
Sent: Thursday, January 11, 2018 8:54 AM
To: Templin, Fred L <[email-masked]>
Cc: Mikael Abrahamsson <[email-masked]>; 6man <[email-masked]>
Subject: Re: draft-pioxfolks-6man-pio-exclusive-bit-02.txt

Thanks - Fred

Ok, that's another technique that could be specified for use with PIO-X, but since RFC5214 doesn't update RFC4861, that implies to me currently that technique is limited only to the scope of RFC5214 (ISATAP).  To my point, if that technique is to be used generically hosts and routers need to know when to use it over classic RS/RA with unsolicited RAs.

Thanks.

---

From: Ole Troan <[email-masked]>
Date: Thu, 11 Jan 2018 18:49:38 +0100

David,

> So then we either need to use the technique described in RFC8273 or we need a protocol change to allow the unicast of unsolicited RAs, which was my earlier point. I suppose you could eliminate the…

The initial premise for PIO-X is that you are on a point to point link. Or something that is made to look like one.

Cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Jan 2018 17:55:05 +0000

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: Thursday, January 11, 2018 9:50 AM
> To: David Farmer <[email-masked]>
> Cc: 6man <[email-masked]>
> > So then we either need to use the technique described in RFC8273 or we need a protocol change to allow the unicast of unsolicited
> RAs, which was my earlier point. I suppose you could eliminate the unsolicited RAs all together, having the host solicit the RA again and
> again, but that's a protocol change too.
> 

Or, on an NBMA link like ISATAP or AERO.
Or, on any link type for which an IP-over-foo document can be written.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Jan 2018 08:10:23 +1300

> This document does not need to say a single thing about prefix length. Only describe protocol mechanism.

Exactly. The design of a hammer does not specify the length of the nail.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 11 Jan 2018 17:24:28 -0300

> Sigh. We have to be able to separate what's protocol what is policy.

s/protocol/mechanism/  (potocol == (mechanism && policy))

> This document does not need to say a single thing about prefix length. Only describe protocol mechanism.

Agreed. But prefix length is not a policy but a parameter. If you
specify a mechanism, you do need to talk about policy (e,g,, if you
spacidy TCP's ACK number, you need to say quite a lot about it:
semantics, when to ack, etc.)

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 11 Jan 2018 22:35:40 +0000

> describe protocol mechanism.

I somewhat disagree. As I read this thread, I'm becoming convinced that it would be useful to explicitly state that the host MUST support any length prefix, as there are no constraints on the sent prefix length.
I do agree there should be no constraints on prefix length. But this discussion leads me to believe there is a strong likelihood of bad (i.e., constrained) host implementations if nothing is said at all.
Barbara

---

From: David Farmer <[email-masked]>
Date: Thu, 11 Jan 2018 16:39:06 -0600

On Thu, Jan 11, 2018 at 11:49 AM, Ole Troan <[email-masked]> wrote:

> my earlier point. I suppose you could eliminate the unsolicited RAs all

I don't see anything in the document explicitly limiting the scope of the
document to point-to-point links. In fact to the contrary, I think it it
intends to be compatible with all RFC4861 compliment implementation
including all RFC2464 implementations.

Last paragraph of Section1;

   Use of the X flag is backward compatible with existing IPv6 standards
   compliant implementations.  [RFC4861]-compliant nodes that do not
   understand the X flag are not negatively impacted.  They must ignore
   it, and can process the PIO under existing standards, making use of
   the information exactly as if the X flag were not set.

 Am I reading it wrong?

Based on that I don't think in section 5.3 you can simply say the sender
"SHOULD unicast the the PIO-X RA."  As I said that is an over
simplification, I think more details are needed.  Adding, or referring to,
the text from RFC8273 would be fine with me.

Thanks.

---

From: David Farmer <[email-masked]>
Date: Thu, 11 Jan 2018 17:02:31 -0600

On Thu, Jan 11, 2018 at 4:35 PM, STARK, BARBARA H <[email-masked]> wrote:

> > This document does not need to say a single thing about prefix length.
> Only
> > describe protocol mechanism.
>
> I somewhat disagree. As I read this thread, I'm becoming convinced that it
> would be useful to explicitly state that the host MUST support any length
> prefix, as there are no constraints on the sent prefix length.
> I do agree there should be no constraints on prefix length. But this
> discussion leads me to believe there is a strong likelihood of bad (i.e.,
> constrained) host implementations if nothing is said at all.
> Barbara
>

The combination of RFC4862 (SLAAC), RFC2464(IPv6-over-ethernet), and
RFC4291 (IPv6 Addressing Architecture) currently only supports /64
prefixes. Personally, I doubt there is consensus to change that at this
time.  However, if you think there is then we should revisit the RFC4291bis
discussion.

This mechanism should not restrict the prefix length, but that doesn't mean
a host will know what to do with prefix length other than /64.  At this
time there is no mechanism for a host to auto generate an addresses with a
prefix of a length other than /64, this is not the discussion to change
that, revisiting the RFC4291bis discussion is the right way to change that.
But, again I doubt there is consensus for that.

Thanks.

---

From: DY Kim <[email-masked]>
Date: Fri, 12 Jan 2018 08:08:48 +0900

+1

---
DY

> On 11 Jan 2018, at 22:58, Alexandre Petrescu <[email-masked]> wrote:
> 
> I want the proposals that I support to succeed.

---

From: DY Kim <[email-masked]>
Date: Fri, 12 Jan 2018 08:12:31 +0900

Yeah…

https://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy

---
DY

> On 11 Jan 2018, at 23:19, Ole Troan <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Fri, 12 Jan 2018 08:19:11 +0900

The intention of the comment was only to find a way to get the draft moving on.

What condition do you (or those opposing this draft) think will be able to let go of this draft?

Or do you (with those opposing) fundamentally oppose to this draft whatsoever?

---
DY

> On 11 Jan 2018, at 23:46, Peter Hessler <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Fri, 12 Jan 2018 08:31:04 +0900

I don’t get this. Do you mean it’s not relevant anymore?

---
DY

> On 12 Jan 2018, at 00:35, Lorenzo Colitti <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Fri, 12 Jan 2018 08:33:43 +0900

We could do both; unsolicited PIO-X and solicited PIO-X.

---
DY

> On 12 Jan 2018, at 01:17, Templin, Fred L <[email-masked]> wrote:
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Jan 2018 23:56:46 +0000

In the words of draft-templin-v6ops-pdhost:

   “IPv6 Prefix Delegation (PD) entails 1) the communication of a prefix

   from a server to a requesting router, 2) a representation of the

   prefix in the network's Routing Information Base (RIB) and the first-

   hop router's forwarding information base (FIB), and 3) a control

   messaging service to maintain prefix lifetimes.”

What is currently lacking in PIO-X is “a control messaging service to

maintain prefix lifetimes”. This can and probably should be based on

unicast RS/RA in the same spirit as in RFC5214, but a complete control

messaging service would end up looking a lot like DHCPv6 where we

have mature standards and implementations. So, why not just use

RS/RA messaging with embedded DHCPv6 options?

I am asking this as an author of a proposal that is currently assumes

DHCPv6 but could very easily be migrated to PIO-X.

Thanks - Fred

---

From: DY Kim <[email-masked]>
Date: Fri, 12 Jan 2018 09:16:51 +0900

These seem to be mechanism.

---
DY

> On 12 Jan 2018, at 05:24, Fernando Gont <[email-masked]> wrote:
> 
> semantics, when to ack

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 12 Jan 2018 08:53:02 +0100 (CET)

> a protocol change to allow the unicast of unsolicited RAs, which was my

The PIO-X draft is not intended to go into detail about deployment 
scenarios and why the router sets the PIO-X bit, on what link types etc.

It's about the router/administrator knowing that the PIO-X bit is 
appropriate to set (for instance because this is an P2P link) for the 
deployment scenario, and that this scenario means the RA is going to be 
received by a single host.

If some deployment scenarios mean we need to change the IPv6 
standardisation documents on when to send unsolicited unicast RAs etc, 
then I'd rather handle that in another document. There are other cases 
where this is not needed, such as for instance a P2P link where the only 
two devices on the link is the router and the host (where the "host" in 
this case can be a RFC7084 router for instance, sitting on an ethernet 
access link to the ISP upstream router).

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 12 Jan 2018 09:57:51 +0100 (CET)

(changing topic because I believe we changed topic now, PIO-X is not 
prefix delegation)

On Thu, 11 Jan 2018, Templin, Fred L wrote:

> messaging service would end up looking a lot like DHCPv6 where we have 
> mature standards and implementations. So, why not just use RS/RA 
> messaging with embedded DHCPv6 options?
>

I think it's a bad idea to start "tunneling" DHCPv6 as-is, and not change 
anything else. I also would like to avoid bringing in all the DHCPv6 
machinery both as server and client, because I don't think it's 
fundamentally needed for at least some deployment scenarios.

The major drawback with DHCPv6 and ND/RA being completely separated 
(fundamentally) is that information sent in RA won't affect anything that 
has to do with DHCPv6. Sending zero lifetime RA doesn't invalidate DHCPv6 
based resources, even if it's from the same router. PD is kind of a 
"bastard", and it doesn't even have a standardised mechanism for 
installing the delegated prefix on the delegating router RIB. Same with 
IA_NA/TA if it's outside of the already configured prefix of the router.

So I could live with saying "this RA option contains DHCPv6 stateless 
options" so DHCPv6 stateless information could be announced in RA (so we 
don't have to standardise options both in DHCPv6 and RA, it'd be the same 
option space). I do not want to "tunnel" DHCPv6 IA_NA, IA_TA or IA_PD 
handling in RA (and not change anything else), in that case I'd like to 
make sure we figure out and solve the drawbacks of DHCPv6 stateful 
handling and solve it in a better way so it all fits together, without 
having to bring in all of DHCPv6.

People have modeled their org charts and work split after how DHCPv4 
worked. Just because people don't want to change their org charts isn't a 
good reason to bring with us all DHCPv4 downsides into IPv6.

---

From: [email-masked]
Date: Fri, 12 Jan 2018 11:02:03 +0100 (CET)

> good reason to bring with us all DHCPv4 downsides into IPv6.

There's a fine balance here - the more difficult you make it for people
to continue working in a similar way (as they did for IPv4), the more
they are going to resist IPv6.

Steinar Haug, AS2116

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 12 Jan 2018 11:47:01 +0100

Le 12/01/2018 à 09:57, Mikael Abrahamsson a écrit :
> I think it's a bad idea to start "tunneling" DHCPv6 as-is, and not 
> change anything else.

I think it is a good idea to start tunneling DHCPv6 as-is.  Other 
successful proposal was the use of LCP protocol (typically for PPP) in 
IP messages, in order to make a VPN tunnel.  I think it's called L2TP, 
or something like that.  It is widely deployed.

But I also think that if we go that way, we would need to change 
something in the RS/RA semantics, like adding some fields in RA telling 
the payload is DHCP.  (so it is not 'not change anything else').

> I also would like to avoid bringing in all the 
> DHCPv6 machinery both as server and client, because I don't think it's 

But, as time goes by, RS/RA looks more and more like a machinery.  An 
radvd.conf now has much  more options than before, and there are more 
and more RFCs about RS/RA.

Who would have thought before that a DNS Resolver would be present in 
RA, and yet there it is, widely used.

> (fundamentally) is that information sent in RA won't affect anything 
> that has to do with DHCPv6. Sending zero lifetime RA doesn't invalidate 
> DHCPv6 based resources, even if it's from the same router. 

A zero lifetime RA only affects the default route.  It does not affect 
the MTU either, so it will not affect DHCP or the DNS server.

> PD is kind of 
> a "bastard", 

Ah no, dont call it that way please :-)  I keep pushing for it to some 
manufacturer and when they come telling me that the 'design of IPv6 is 
without DHCP', then I suppose they read that at IETF somewhere.

> and it doesn't even have a standardised mechanism for 
> installing the delegated prefix on the delegating router RIB.

I can agree.  I think BBF did standardize it, but IETF did not.  But 
there is an Internet Draft of this problem at Relay
draft-petrescu-relay-route-pd-problem-00.txt

> Same with 

I can agree.  Would you like to write this problem in one phrase?  We 
can put it in that draft very quickly.

Alex
> don't have to standardise options both in DHCPv6 and RA, it'd be the 
> same option space). I do not want to "tunnel" DHCPv6 IA_NA, IA_TA or 
> IA_PD handling in RA (and not change anything else), in that case I'd 
> like to make sure we figure out and solve the drawbacks of DHCPv6 
> stateful handling and solve it in a better way so it all fits together, 
> without having to bring in all of DHCPv6.
> 
> worked. Just because people don't want to change their org charts isn't 
> a good reason to bring with us all DHCPv4 downsides into IPv6.
> 
> 
>

---

From: David Farmer <[email-masked]>
Date: Fri, 12 Jan 2018 08:54:02 -0600

> received by a single host.

I'm fine with that. But maybe add a little more emphasis to the fact that
that it is a single node receiving the PIO-X RA in the Abstract and
Introduction by adding the word "single" in the first sentence of each;

...that the *single* node receiving this RA...

> standardisation documents on when to send unsolicited unicast RAs etc, then
> I'd rather handle that in another document. There are other cases where
> this is not needed, such as for instance a P2P link where the only two
> devices on the link is the router and the host (where the "host" in this
> case can be a RFC7084 router for instance, sitting on an ethernet access
> link to the ISP upstream router).

I'm fine with a separate document dealing with the unicast of unsolicited
RAs.  However, I would view that other document as a blocking dependency
for publication of this document.

Also, I would like to see it clarified that both Rule #1 in section 3 and
and the recommendation to "unicast the PIO-X RA" in section 5.3 applies to both
Solicited RAs sent by a router in response to an RS and to Unsolicited RAs
sent periodically by a router.

Thanks.

---

From: Peter Hessler <[email-masked]>
Date: Fri, 12 Jan 2018 15:59:15 +0100

My concern is only with mandating a prefix size/range.  Other than that,
I have no opinions on the draft.

On 2018 Jan 12 (Fri) at 08:19:11 +0900 (+0900), DY Kim wrote:
:The intention of the comment was only to find a way to get the draft moving on.
:
:What condition do you (or those opposing this draft) think will be able to let go of this draft?
:
:Or do you (with those opposing) fundamentally oppose to this draft whatsoever?
:
:---
:DY
:
:> On 11 Jan 2018, at 23:46, Peter Hessler <[email-masked]> wrote:
:> 
:> Mandating a /64 as the only acceptable prefix size *in the protocol* is
:> utterly ridiculous.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 12 Jan 2018 16:07:14 +0000

Hi Alex,

I somehow did not get Mikael's note that you are quoting here - mailer problems?
Some kind of filter? Do I need to start watching the list archives?

To Mikael's points:

> anything else.

It is a fundamentally sound idea, and it is not "tunneling" nor is there a
need to change anything else. It is  a unification of IPv6 ND and DHCPv6;
one unified service for all autoconfiguration needs. It is backward
compatible, and incrementally deployable. Not all nodes need to
be modified to support the function at the same time.

> I also would like to avoid bringing in all the DHCPv6 

The primary function of DHCPv6 that is of interest (to me at least)
is prefix delegation. For that, the server needs some way to
uniquely identify the client, there needs to be a transaction ID so
the client can match its requests with replies, the server needs
to keep track of which prefixes it has given out to which clients,
and there needs to be a control message service for managing
prefix lifetimes, releasing prefixes, etc. All of that is needed for
any prefix delegation service - whether by DHCPv6 or something
else. And, fully-functional DHCPv6 client and server software is
freely available and widely deployed.

To Alex's points:

> From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Friday, January 12, 2018 2:47 AM
> To: [email-masked]
> Subject: Re: prefix delegation/stateful DHCPv6 (was RE: draft-pioxfolks-6man-pio-exclusive-bit-02.txt)
> 
> 
> 

Thanks.

> or something like that.  It is widely deployed.

Thanks for pointing out this precedence.

> the payload is DHCP.  (so it is not 'not change anything else').

The idea is to define a (single) new IPv6 ND option code to carry in
RS/RA messages. There are no other changes necessary in RS/RA.

> and more RFCs about RS/RA.

RA has become the swiss army knife of IPv6ND. There is a blade or
gizmo for every imaginable function. We are simply asking to add a
single new option.

> RA, and yet there it is, widely used.

Right - good example.

> without DHCP', then I suppose they read that at IETF somewhere.

As near as I can tell, PD is the saving grace of DHCPv6. It will
become more and more important as more and more hosts
realize that they can get an entire prefix instead of just one
or a couple of individual addresses.

> draft-petrescu-relay-route-pd-problem-00.txt

Installing the route is based on the delegated IA_PD  prefix in the
server's Reply message, but it is an implementation matter of how
to install it. In my linux code, I use "ip route add" and the prefix is
both installed in the FIB and propagated into the RIB by the routing
protocol. But, this is strictly an implementation matter and not
something to put in a standard.

> can put it in that draft very quickly.

I actually wouldn't mind if we just dropped IA_NA/IA_TA altogether and
focus only on IA_PD. As I said, I think IA_PD is the saving grace of DHCPv6.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Jan 2018 08:12:19 +1300

> they are going to resist IPv6.

Yes. To be frank, the RA/SLAAC mechanism is great for a "don't worry,
be happy" style of network management where you rely on things working
by default. That's good for a very wide variety of scenarios (ones
in which DHCPv4 is used without any human intervention). But networks
that don't just work by default aren't going to go away any time soon.

I'm hopeful that the way humans manage such networks will evolve over
time; that's why I'm in the ANIMA WG. But DHCPv6 is not going away.

    Brian

---

From: james woodyatt <[email-masked]>
Date: Fri, 12 Jan 2018 11:16:41 -0800

On Jan 11, 2018, at 23:53, Mikael Abrahamsson <[email-masked]> wrote:
> 
> […] It's about the router/administrator knowing that the PIO-X bit is appropriate to set (for instance because this is an P2P link) for the deployment scenario, and that this scenario means the RA is going to be received by a single host. […]

I mainly object to this draft *because* it depends on implicitly isolating the L2 link between the router and the host. If we want to extend ICMPv6 to provide an explicit signal to hosts that the link is a point-to-point link and no other nodes are directly reachable on the link by ND6, then we should define a fresh option to signal precisely that, and not do this thing where we insert a bit into the Prefix Information Option to signal it.

---

From: james woodyatt <[email-masked]>
Date: Fri, 12 Jan 2018 11:24:51 -0800

> or a couple of individual addresses.

I’m skeptical about this. This forecast depends on servers being routinely provisioned to grant IA_PD requests and not just IA_NA request, which I don’t see happening on the networks where most hosts are deployed. I see no evidence that leads me to believe this will happen. Hence, I’m in no particular hurry to make border routers that request prefixes. Easier to just use the model we all know and love with IPv4.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 12 Jan 2018 19:46:13 +0000

Hi James,

Understand your concerns from a general standpoint, but I am looking at specific
cases such as manned aircraft operating in the global air traffic management (ATM)
service, unmanned aircraft operating in the uncontrolled airspace (UTM) and
enterprise mobile device users moving freely between WiFi hotspots and cellular
while maintaining stable IPv6 services from their home enterprise. In all of these
cases, the killer app is mobility and the solution is a mobility service based on
DHCPv6 PD and IPv6 ND.

I think even looking beyond these uses, in the general case hosts will begin to
notice that getting an entire prefix gives more bang for the buck than getting
just one or a few addresses (for example, for multi-addressing or tethering
purposes). And, prefix delegation provides a suitable mechanism.

Thanks - Fred

From: james woodyatt [mailto:[email-masked]]
Sent: Friday, January 12, 2018 11:25 AM
To: [email-masked]
Cc: Templin, Fred L <[email-masked]>
Subject: Re: prefix delegation/stateful DHCPv6 (was RE: draft-pioxfolks-6man-pio-exclusive-bit-02.txt)

On Jan 12, 2018, at 08:07, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

---

From: james woodyatt <[email-masked]>
Date: Fri, 12 Jan 2018 11:55:04 -0800

On Jan 12, 2018, at 11:46, Templin, Fred L <[email-masked]> wrote:
> 
> And, prefix delegation provides a suitable mechanism.

Sure, but a mechanism with no policy of deploying it is not better than no mechanism at all. Meanwhile, we have a mechanism available that requires no additional policy be adopted to deploy it: network address translation.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 12 Jan 2018 20:23:01 +0000

Hi James,

>Meanwhile, we have a mechanism available that requires no additional policy be
>adopted to deploy it: network address translation.

You didn't specify an IP protocol version, so I assume you mean both? This could
be a hard reality check, but if you mean to include IPv6 NAT aren't we up the creek
before we even get started?

For my applications, I want an IPv6 prefix that travels with the mobile device
wherever it goes without having to do NAT at every network point of attachment.
I also want to support session survivability so that I don't have to stop and
restart all of my sessions every time my network attachment point changes.
So, my devices do need to get a prefix delegation that they can run with. And
I'm sure that sort of arrangement would be appreciated for other applications.

Thanks - Fred

From: james woodyatt [mailto:[email-masked]]
Sent: Friday, January 12, 2018 11:55 AM
To: Templin, Fred L <[email-masked]>
Cc: [email-masked]
Subject: Re: prefix delegation/stateful DHCPv6 (was RE: draft-pioxfolks-6man-pio-exclusive-bit-02.txt)

On Jan 12, 2018, at 11:46, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 12 Jan 2018 22:02:34 +0100 (CET)

On Fri, 12 Jan 2018, james woodyatt wrote:

> I mainly object to this draft *because* it depends on implicitly 
> isolating the L2 link between the router and the host. If we want to 
> extend ICMPv6 to provide an explicit signal to hosts that the link is a 
> point-to-point link and no other nodes are directly reachable on the 
> link by ND6, then we should define a fresh option to signal precisely 
> that, and not do this thing where we insert a bit into the Prefix 
> Information Option to signal it.

There are some deployment scenarios where what you write makes sense, but 
there are some others were it does not.

Do RFC8273 style deployments count?

What should the device do if this flag is 1 and it receives an ICMPv6 
redirect indicating that the device it's sending traffic to, is actually 
reachable on-link?

So while I sympathise with your desire to keep this clean, deployment 
scenarios are not necessarily that clean.

---

From: james woodyatt <[email-masked]>
Date: Fri, 12 Jan 2018 13:17:40 -0800

On Jan 12, 2018, at 12:23, Templin, Fred L <[email-masked]> wrote:
> 
> You didn’t specify an IP protocol version, so I assume you mean both? This could
> be a hard reality check, but if you mean to include IPv6 NAT aren’t we up the creek

That’s pretty much what I’m saying. As a developer of IPv6-only hosts and small-scale consumer routers, I have a hard time selling any plan to rely on the provisioning of DHCPv6 servers to grant prefix delegations in most networks where general purpose hosts are expected to be deployed. Only path forward I see working at this point is to use a cone NAT66.

I’ve been warning against this potential future for over a decade. It’s not the future anymore.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 12 Jan 2018 22:07:55 +0000

Hi James,

DHCPv6 should be part of a unified autoconfiguration service at least in
managed networks – maybe you are talking about unmanaged ones?
But, even in unmanaged networks, the host has to trust the first hop
router to give “good” autoconfiguration information in its RAs. So, it
should be able to supply IA_PDs in addition to PIOs.

Thanks - Fred

From: james woodyatt [mailto:[email-masked]]
Sent: Friday, January 12, 2018 1:18 PM
To: Templin, Fred L <[email-masked]>
Cc: [email-masked]
Subject: Re: prefix delegation/stateful DHCPv6 (was RE: draft-pioxfolks-6man-pio-exclusive-bit-02.txt)

On Jan 12, 2018, at 12:23, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Mark Smith <[email-masked]>
Date: Sat, 13 Jan 2018 13:20:07 +1100

Similarity (Compatibility) is a factor in adoption, however it is only one
of 5 - Relative Advantage, Compatibility, Complexity, Trialability and
Observability ("Diffusion of Innovations")*.

I think the Relative Advantage factor is more significant - what is the
relative advantage of IPv6 over IPv4 to solve a particular problem?

For many enterprises, IPv6 doesn't yet solve (and possibly may never solve)
a problem better than IPv4. They're not running out of IPv4 addresses,
because they use RFC1918s. They don't care about end-to-end or globally
unique addressing, because they want the majority of their hosts to only be
clients, and they push all the client traffic through Internet access
policy enforcement web proxies.

For a while I thought deploying IPv6 as insurance against some future day
that an IPv6 only website that enterprise staff have to access would be a
reason to deploy it. However, I've since realised those organisations will
probably just IPv6 enable the outside interface of their Internet access
policy enforcement web proxy. Overnight they have "IPv6 Internet access".

If we want IPv6 to be adopted, we need to make it easier, cheaper and
better to use to solve problems than IPv4 is. If the goal is to make IPv6
the same cost use and operate as IPv4, then there may never be a relative
advantage to IPv6 for many organisations.

Regards,
Mark.

Steinar Haug, AS2116

---

From: Ole Troan <[email-masked]>
Date: Mon, 15 Jan 2018 09:48:46 +0100

James,

> I mainly object to this draft *because* it depends on implicitly isolating the L2 link between the router and the host. If we want to extend ICMPv6 to provide an explicit signal to hosts that the l…

I do also have some sympathy with that view point.
Point to point is a property of the data-link layer. Unfortunately we are were we are, and punting to IEEE might not give us a practical solution.

Cheers,
Ole

---

From: Erik Kline <[email-masked]>
Date: Mon, 15 Jan 2018 17:56:24 +0900

> Point to point is a property of the data-link layer. Unfortunately we are were we are, and punting to IEEE might not give us a practical solution.

We could claim a bit in the Extended Flags Option for this.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 15 Jan 2018 17:18:18 +0100 (CET)

On Mon, 15 Jan 2018, Ole Troan wrote:

> Point to point is a property of the data-link layer. Unfortunately we 
> are were we are, and punting to IEEE might not give us a practical 
> solution.

Signalling to the host "you're the only one who can use these resources, 
go ahead" and telling the host "you're on a point to point link", these 
two things are not the same thing.

We might want to limit the deployment scenarios and what can be done, but 
then we're making an intentional decision to do so.

---

From: james woodyatt <[email-masked]>
Date: Tue, 16 Jan 2018 12:19:24 -0800

On Jan 15, 2018, at 08:18, Mikael Abrahamsson <[email-masked]> wrote:
> Signalling to the host "you're the only one who can use these resources, go ahead" and telling the host "you're on a point to point link", these two things are not the same thing.

Yes, and the last time we had a discussion about this draft (and the closely related document that was published by V6OPS as Unique IPv6 Prefix per Host [RFC 8273]), I was scolded for not recognizing that none of this stuff works unless you have L2 isolation, i.e., "you’re on a point-to-point link.” (Questions that Fred Templin and I raised about how this stuff works when there isn’t L2 isolation, i.e., when “you’re the only one [authorized] to use these resources, go ahead [until we somehow tell you about exceptions],” were dismissed as off-topic.)

The text of RFC 8273 was eventually clarified to make it very clear that L2 isolation is required for the operational practice it describes to work. This draft, by comparison, comprises a change to the ICMPv6 protocol to provide an explicit signal that L2 isolation required for RFC 8273 is applied to your link, and it seems to me, it’s the wrong way to convey that signal.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 20 Jan 2018 11:09:12 +0100 (CET)

On Tue, 16 Jan 2018, james woodyatt wrote:

> Yes, and the last time we had a discussion about this draft (and the 
> closely related document that was published by V6OPS as Unique IPv6 
> Prefix per Host [RFC 8273]), I was scolded for not recognizing that none 
> of this stuff works unless you have L2 isolation, i.e., "you’re on a 
> point-to-point link.” (Questions that Fred Templin and I raised about

Well, someone might scold you about that, but I don't agree with them.

> The text of RFC 8273 was eventually clarified to make it very clear that 
> L2 isolation is required for the operational practice it describes to 
> work. This draft, by comparison, comprises a change to the ICMPv6 
> protocol to provide an explicit signal that L2 isolation required for 
> RFC 8273 is applied to your link, and it seems to me, it’s the wrong way 
> to convey that signal.

I am open to having the discussion, the important thing is that we agree 
that "you have sole use of this resource" is a different thing than saying 
"you're the only one on this link apart from the router". Because the 
second thing implies that if there is an ICMP redirect saying someone is 
on-link, this signal must be ignored for things to be consistent (at least 
in my opinion). So that opens another can of worms, potentially.

---

From: james woodyatt <[email-masked]>
Date: Mon, 22 Jan 2018 10:24:57 -0800

On Jan 20, 2018, at 02:09, Mikael Abrahamsson <[email-masked]> wrote:
> 
> […] I am open to having the discussion, the important thing is that we agree that "you have sole use of this resource" is a different thing than saying "you're the only one on this link apart from the router". Because the second thing implies that if there is an ICMP redirect saying someone is on-link, this signal must be ignored for things to be consistent (at least in my opinion). So that opens another can of worms, potentially.

I completely agree. However, the former is much more difficult to specify cleanly than the latter.

In a protocol as fundamental to IPv6 as Neighbor Discovery, I would say that anything so underspecified is functionally broken. I can’t help but notice that a deficiency of the expired PIO-X draft is that it doesn’t actually say what is the conforming behavior when a host receives a PIO-X for prefix P (from router R1) and later receives ND Redirect (from router R2, cases where R1 = R2 and R1 ≠ R2) for an address with prefix P.

Ignore? Process? Nasal demons (c.f. http://www.catb.org/jargon/html/N/nasal-demons.html <http://www.catb.org/jargon/html/N/nasal-demons.html>)?

If we don’t want to open that can of worms— and, as far as I can tell, the working group as a whole mostly does not— then we have to be very clean about what we’re talking about: stuff like RFC 8273 only works with L2 isolation. In which case, this whole draft is a problem, and what it should really be is a draft that explicitly signals that L2 isolation is in effect, and what that means a host is permitted/obligated to do differently, e.g., the question about ND Redirect you reference above, among others.

RFC 8273 doesn’t currently allow a host to recognize its exclusive allocation of resources expressed in RA messages. This draft is a major departure from that. It seems you are asserting that “you have exclusive use of this [prefix information] resource” makes this draft *less* difficult to specify cleanly than “you and me are the only nodes on this L2 network,” and that seems like a mistake to me.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jan 2018 11:09:12 +1300

On 23/01/2018 07:24, james woodyatt wrote:
> If we don’t want to open that can of worms— and, as far as I can tell, the working group as a whole mostly does not— 

I suspect we can't put this off for ever. Once upon a time, the
Internet was built entirely out of either point-to-point links or
broadcast LANs. As time goes on that becomes less and less true,
and beyond a certain moment it won't be possible to hack our way
round it.

> then we have to be very clean about what we’re talking about: stuff like RFC 8273 only works with L2 isolation. In which case, this whole draft is a problem, and what it should really be is a draft that explicitly signals that L2 isolation is in effect, and what that means a host is permitted/obligated to do differently, e.g., the question about ND Redirect you reference above, among others.

But "L2 isolation is in effect" and "you are the only host in this
prefix" are orthogonal; one, both or neither could be true. So
two bits are needed.

Clearly if a host receives both "L2 isolation is in effect" and
an ND redirect, something is broken. If it receives both "you are
the only host in this prefix" and an ND redirect *for an address
in the same prefix* something else is broken. (If it's talking
to itself, that should be handled as a loopback.)

> RFC 8273 doesn’t currently allow a host to recognize its exclusive allocation of resources expressed in RA messages. This draft is a major departure from that. It seems you are asserting that “you…

Since they are orthogonal signals, the mistake would be to
conflate them.

   Brian

---

From: james woodyatt <[email-masked]>
Date: Mon, 22 Jan 2018 14:58:27 -0800

> prefix" are orthogonal; one, both or neither could be true. So

They are not orthogonal. They are entangled because the latter is not easy to do unless the former is done as well.

Consider the specification complexity of each of the following three possible combinations.

* Shared link + Shared prefix: status quo, already specified.

* Isolated link + Shared prefix: very nearly status quo; host MAY safely ignore all ND Redirect, which is pretty much a trivial refinement of what hosts are already doing today. They still MUST perform DAD and address defense.

* Isolated link + Exclusive prefix: not too different from Isolated link + Shared prefix, above, except hosts could also dispense with DAD and address defense.

Unfortunately, the expired PIO-X draft presents the remaining combination:

* Shared link + Exclusive prefix: we need to define rules for how hosts behave in the face of conflicting X-bits on matching PIO advertisements from multiple routers; including how to behave when routers send ND redirects that conflict with other routers PIO-X advertisements, we need a better way to redirect whole prefixes and not just addresses, e.g., the also expired I-D.templin-6man-rio-redirect. This is a huge mess compared to the other combinations.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jan 2018 12:10:54 +1300

On 23/01/2018 11:58, james woodyatt wrote:
> They are not orthogonal. 

Well, that's a matter of definition. Neither one implies the state of the
other, which is what I meant by "orthogonal". 

> They are entangled because the latter is not easy to do unless the former is done as well.
> 

Exactly. There are four combinations, and each has to work. We agree on that.

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 23 Jan 2018 07:52:48 +0100 (CET)

On Mon, 22 Jan 2018, james woodyatt wrote:

> They are not orthogonal. They are entangled because the latter is not 
> easy to do unless the former is done as well.

Depending on the definition of "easy", this is true or not true. There is 
one camp that thinks SAVI is stupid, because why put more than two devices 
on a VLAN? For other deployments, SAVI makes perfect sense and it's been 
in wide use since early 2000:ds (DHCP snooping for instance). It's a layer 
violation, and thus people have strong feelings about it. I see PIO-X L2 
isolation as a similar issue.

PIO-X can be done without L2 isolation. There is also no reason to 
standardize the L2 isolation in the PIO-X document, the same way there is 
no reason to standardize the L2 in other L3 specifications. We might want 
to implement some sanity checks (possibly), but I'm not sure we actually 
need to.

> * Shared link + Exclusive prefix: we need to define rules for how hosts 
> behave in the face of conflicting X-bits on matching PIO advertisements 
> from multiple routers; including how to behave when routers send ND 
> redirects that conflict with other routers PIO-X advertisements, we need 
> a better way to redirect whole prefixes and not just addresses, e.g., 
> the also expired I-D.templin-6man-rio-redirect. This is a huge mess 
> compared to the other combinations.

Do we really need to define this? My intention was that this would be 
undefined behaviour because this setup is just broken.

If you can't make sure the resource (in this case PIO) is sent to one 
device and only one device, you've got a broken network and things are 
just undefined but most likely broken. I see no reason to untangle this 
mess with lots of rules and ifs/buts.

If someone can come up with an L2 implementation that makes sure just a 
single host gets the PIO-X, then fine, they can do that. If they fail, 
then they have failed and their network is now broken and not functioning 
properly.

I want to keep the protocol specification document as clean as possible, 
just stating what it means what the host should do about it. I'd rather 
keep the router and L2 part of the document out of the PIO-X document. 
v6ops can write one or several operational document as BCP or something, 
on how to implement this the best way in different scenarios.

About redirecting whole prefixes, that's fine by me but not part of the 
PIO-X document.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Jan 2018 17:37:56 +0900

On Tue, Jan 23, 2018 at 7:58 AM, james woodyatt <[email-masked]> wrote:

> redirects that conflict with other routers PIO-X advertisements, we need a
> better way to redirect whole prefixes and not just addresses, e.g., the
> also expired I-D.templin-6man-rio-redirect. This is a huge mess compared to
> the other combinations.
>

I agree that this is a huge mess, not just because of redirects, but for
RAs as well. FWIW, I don't think we should attempt to solve this last
problem at all. If we want to do PIO-X (and like I said, I don't know that
reaching consensus on it is feasible due to the /64 debate that it would
cause), then we should start by specifying it only for networks where L2
isolation is in use.

---

From: Ole Troan <[email-masked]>
Date: Thu, 25 Jan 2018 09:22:37 +0100

Brian,

> Exactly. There are four combinations, and each has to work. We agree on that.

I don't think we agree on "each has to work".
We could very well define an initial version of PIO-X that is restricted to P2P links (or something that is made to appear to look like one).

Cheers,
Ole

---

From: Bob Hinden <[email-masked]>
Date: Thu, 25 Jan 2018 07:51:53 -0800

Ole,

> On Jan 25, 2018, at 12:22 AM, Ole Troan <[email-masked]> wrote:
> 
> Brian,
> 

Right.  I think it makes sense to focus on the Isolated link cases.  As you noted, it’s easy to create isolated links on shared media.  As stated the “shared-link + exclusive prefix” gets complex very fast, and overlaps with other solutions such as using routing protocols.  IMHO, better to focus on things that we can make work.

Bob

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Jan 2018 16:20:44 +0000

Hi Bob,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
> Sent: Thursday, January 25, 2018 7:52 AM
> To: Ole Trøan <[email-masked]>
> Cc: james woodyatt <[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
> >>> * Isolated link + Shared prefix: very nearly status quo; host MAY safely ignore all ND Redirect, which is pretty much a trivial
> refinement of what hosts are already doing today. They still MUST perform DAD and address defense.
> >>>
> >>> * Shared link + Exclusive prefix: we need to define rules for how hosts behave in the face of conflicting X-bits on matching PIO
> advertisements from multiple routers; including how to behave when routers send ND redirects that conflict with other routers PIO-X
> advertisements, we need a better way to redirect whole prefixes and not just addresses, e.g., the also expired I-D.templin-6man-rio-
> redirect. This is a huge mess compared to the other combinations.
> >>
> Right.  I think it makes sense to focus on the Isolated link cases.

PIO-X currently defines an *unsolicited* mode of operation where the
router provides the host with an exclusive prefix that the host did not
ask for. There should also be a *solicited* mode where the host can
ask for an exclusive prefix, e.g., by including a PIO in its RS messages
to the router. In that case, it would begin to look like DHCPv6 PD.

> As you noted, it’s easy to create isolated links on shared media.  As
> stated the “shared-link + exclusive prefix” gets complex very fast, and overlaps with other solutions such as using routing protocols.

Very large shared links may not be candidates for using routing protocols.
Some NBMA links may connect thousands of nodes or more, for example.

> IMHO, better to focus on things that we can make work.

DHCPv6 PD falls under the scope of things that can work.

Thanks - Fred

---

From: David Farmer <[email-masked]>
Date: Thu, 25 Jan 2018 10:23:39 -0600

On Thu, Jan 25, 2018 at 9:51 AM, Bob Hinden <[email-masked]> wrote:

> >>> * Isolated link + Shared prefix: very nearly status quo; host MAY
> safely ignore all ND Redirect, which is pretty much a trivial refinement of
> what hosts are already doing today. They still MUST perform DAD and address
> defense.
> >>>
> >>> * Isolated link + Exclusive prefix: not too different from Isolated
> link + Shared prefix, above, except hosts could also dispense with DAD and
> address defense.
> >>>
> >>> * Shared link + Exclusive prefix: we need to define rules for how
> hosts behave in the face of conflicting X-bits on matching PIO
> advertisements from multiple routers; including how to behave when routers
> send ND redirects that conflict with other routers PIO-X advertisements, we
> need a better way to redirect whole prefixes and not just addresses, e.g.,
> > We could very well define an initial version of PIO-X that is restricted
> to P2P links (or something that is made to appear to look like one).
>
> Right.  I think it makes sense to .  As you noted, it’s easy to create
> isolated links on shared media.  As stated the “shared-link + exclusive
> prefix” gets complex very fast, and overlaps with other solutions such as
> using routing protocols.  IMHO, better to focus on things that we can make
> work.
>

Then are you saying, no shared media like Ethernet?  Yes, an Ethernet can,
and these days frequently does, have only two devices on it, but the two
devices have no way of knowing that they are the only two devices. You
could assume there are only two devices, but then what do you do if/when
that assumption proves false? The only safe assumption is they are not the
only two devices.

So as you say, I think we should focus on the isolated link cases, but for
robustness, we do need to think about what happens when the link isn't
isolated as designed.  I think this can be treated as error condition but
we don't want "nasal demons" flying around. :)

Thanks

---

From: james woodyatt <[email-masked]>
Date: Thu, 25 Jan 2018 09:58:38 -0800

On Jan 25, 2018, at 08:23, David Farmer <[email-masked]> wrote:
> 
> So as you say, I think we should focus on the isolated link cases, but for robustness, we do need to think about what happens when the link isn't isolated as designed.  I think this can be treated as error condition but we don't want "nasal demons" flying around. :) 

An outline of my thoughts on what might be worth considering: an update to RFC 4861 that defines a new Link Layer Address option code, with the same format as the existing SLLA and TLLA options, which I provisionally call the Exclusive Target Link Layer Address (ETLLA) option. These would be valid only in NA messages sent with R=1. Their effect would be to signal to hosts that A) all IPv6 packets received from other target link-layer addresses MUST be ignored, i.e. discarded before processing any IPv6 header material, and B) all further IPv6 packets MUST be sent to the ETLLA. This effect would persist until 1) a physical link layer “down” event is detected, 2) another valid NA message is received from a node sending from the ETLLA that has either R=0 or another ETLLA option containing a different address. (Another way of specifying the same thing would be to eat a reserved bit from the NA header to be used for this purpose in conjunction with the R=1 and TLLA option. Either way works.)

I have deep misgivings about the wisdom of this proposal. It does, however, have one virtue: it would make it easier to specify a PIO-X protocol that allows a host to know that it need not do DAD for self-assigned addresses in A=1 prefixes. You just write the spec so that the X-bit is only valid in RA messages sent by nodes that advertised a currently used ETLLA option. Again, I have deep misgivings about the wisdom of this idea. I merely describe it here to facilitate discussion of a possible compromise with people who insist that prefix delegation needs to be jammed into ND6 somehow without going all the way to the various extents that Fred Templin and I have proposed in recent drafts.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Jan 2018 18:11:25 +0000

I am Cc'ing the document authors so that this comment does not fall
through the cracks. Please consider this as a comment for the spec:

  PIO-X currently defines an *unsolicited* mode of operation where the
  router provides the host with an exclusive prefix that the host did not
  ask for. There should also be a *solicited* mode where the host can
  ask for an exclusive prefix, namely by including a PIO in its RS messages
  to the router. The PIO MUST have the X bit set, and the prefix may be
  either unspecified (all-0's) or a specific prefix that the host is requesting.
  If the prefix is unspecified, the router will return an RA with a PIO with
  the X bit set and with a prefix that it is providing to the host. Otherwise,
  if the host's requested prefix is acceptable, the router will return an RA
  with the same PIO with the X bit set; otherwise, the router will return
  an RA with a PIO with the prefix and with lifetimes set to 0.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Jan 2018 18:24:15 +0000

That would make sense in terms of a way to isolate the link, yes.

Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of james woodyatt
Sent: Thursday, January 25, 2018 9:59 AM
To: IPv6 List <[email-masked]>
Subject: Re: draft-pioxfolks-6man-pio-exclusive-bit-02.txt

On Jan 25, 2018, at 08:23, David Farmer <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Jan 2018 08:00:19 +1300

> Right.  I think it makes sense to focus on the Isolated link cases.  As you noted, it’s easy to create isolated links on shared media.  As stated the “shared-link + exclusive prefix” gets complex v…

Well, I'm not convinced that it's impossible to define rules for the 4th case that make it work without disaster; but if we prefer to say we won't do that and make it a NOT RECOMMENDED scenario, fine.

   Brian

---

From: Dae Young Kim <[email-masked]>
Date: Thu, 25 Jan 2018 21:06:24 -1000

+1.

——
DY

> On 25 Jan 2018, at 8:11 AM, Templin, Fred L <[email-masked]> wrote:
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 26 Jan 2018 13:50:37 +0000

-1
This proposal (add a solicited mode) adds far too much unnecessary complexity for what I see as the primary use cases. When the unsolicited prefix is provided, the host can choose to take it or leave it. Just like with SLAAC. A host isn't required to generate an address from an advertised SLAAC prefix. It can, if it wants. And the host isn't required to inform the router that it wants to do SLAAC.

This draft is marked Experimental. So let's keep the experiment simple. Only if simplicity can be proven not to work should we experiment with more complex solutions.
Barbara

> > router provides the host with an exclusive prefix that the host did
> > not  ask for. There should also be a *solicited* mode where the host
> > can  ask for an exclusive prefix, namely by including a PIO in its RS
> > messages  to the router. The PIO MUST have the X bit set, and the
> > prefix may be  either unspecified (all-0's) or a specific prefix that the host is
> requesting.
> >  If the prefix is unspecified, the router will return an RA with a PIO
> > with  the X bit set and with a prefix that it is providing to the
> > host. Otherwise,  if the host's requested prefix is acceptable, the
> > router will return an RA  with the same PIO with the X bit set;
> > otherwise, the router will return  an RA with a PIO with the prefix and with
> lifetimes set to 0.
> >
> > Thanks - Fred
> >
> >
> > Administrative Requests:
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> > man_listinfo_ipv6&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq
> > 4vrfog&m=a6DL7FfatW0VcqxTJwsDTP1HrxGUfAu8YyM6UvJ3V7o&s=o-
> dkO3YSzVlbyZY
> > 9W5KLdA6aJVPGkneQpLePSdldC80&e=
> Administrative Requests:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=a6DL7FfatW0VcqxTJwsDTP1HrxGUfAu8YyM6UvJ3V7o&
> s=o-dkO3YSzVlbyZY9W5KLdA6aJVPGkneQpLePSdldC80&e=

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 26 Jan 2018 22:54:47 +0900

On Fri, Jan 26, 2018 at 3:24 AM, Templin, Fred L <[email-masked]>
wrote:
>
> These would be valid only in NA messages sent with R=1. Their effect would
> be to signal to hosts that A) all IPv6 packets received from other target
> link-layer addresses MUST be ignored, i.e. discarded before processing any
> IPv6 header material, and B) all further IPv6 packets MUST be sent to the
> ETLLA.
>

That sounds like giant DOS/snooping vector. "Hey host, there's just you and
me on this link, honest. So just send everything to me. You can trust me
because I was able to send you an NA with R=1"

---

From: james woodyatt <[email-masked]>
Date: Fri, 26 Jan 2018 07:23:09 -0800

Yes, that’s only one of the many reasons I have misgivings about this proposal. But then, I’m uneasy about L=0 in the PIO, and I hate the whole of DHCP, so I’m obviously far out of step with rough consensus.

—sent from my phone

> On Jan 26, 2018, at 05:54, Lorenzo Colitti <[email-masked]> wrote:
> 
>> On Fri, Jan 26, 2018 at 3:24 AM, Templin, Fred L <[email-masked]> wrote:
>> These would be valid only in NA messages sent with R=1. Their effect would be to signal to hosts that A) all IPv6 packets received from other target link-layer addresses MUST be ignored, i.e. discarded before processing any IPv6 header material, and B) all further IPv6 packets MUST be sent to the ETLLA.
>> 
> 
> That sounds like giant DOS/snooping vector. "Hey host, there's just you and me on this link, honest. So just send everything to me. You can trust me because I was able to send you an NA with R=1"

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 26 Jan 2018 15:31:18 +0000

Just to be clear, I didn’t write what you are quoting below. Please don’t
mis-quote me like that.

Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Friday, January 26, 2018 5:55 AM
To: Templin, Fred L <[email-masked]>
Cc: james woodyatt <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: draft-pioxfolks-6man-pio-exclusive-bit-02.txt

On Fri, Jan 26, 2018 at 3:24 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
These would be valid only in NA messages sent with R=1. Their effect would be to signal to hosts that A) all IPv6 packets received from other target link-layer addresses MUST be ignored, i.e. discarded before processing any IPv6 header material, and B) all further IPv6 packets MUST be sent to the ETLLA.

---

From: Dae Young Kim <[email-masked]>
Date: Fri, 26 Jan 2018 05:59:45 -1000

The host also has the freedom whether to choose to use the ‘solicited mode’ or not. If not, it only has to wait for an unsolicited prefix announcement. It is not forced to confine itself to the use of the ‘solicited mode’.

I don’t see why it hurts the community to define this mode. This would only help the completeness of the draft to open a wider applicability of the technique, I’d think.
 
——
DY

> On 26 Jan 2018, at 3:50 AM, STARK, BARBARA H <[email-masked]> wrote:
> 
> When the unsolicited prefix is provided, the host can choose to take it or leave it.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 26 Jan 2018 18:18:51 +0000

> From: Dae Young Kim [mailto:[email-masked]]
> Sent: Friday, January 26, 2018 8:00 AM
> To: STARK, BARBARA H <[email-masked]>
> Cc: Templin, Fred L <[email-masked]>; IPv6 List <[email-masked]>
> The host also has the freedom whether to choose to use the ‘solicited mode’ or not. If not, it only has to wait for an unsolicited prefix
> announcement. It is not forced to confine itself to the use of the ‘solicited mode’.
> 
> I don’t see why it hurts the community to define this mode. This would only help the completeness of the draft to open a wider
> applicability of the technique, I’d think.
> 
> ——
> DY
> 

Hi, I wrote this up in Internet Draft format to discuss use of PIOX for (solicited)
prefix delegation:

In the proposal:

1) requesting nodes can include PIOX in the RS messages they send to routers
    as a means of soliciting a prefix delegation
2) pure RS/RA messaging can be used on the link between the requesting node
     and router, while DHCPv6 messaging can be used on the backhaul network
     between the router and the prefix delegation server.

This latter point allows for reuse of widely-deployed and mature implementations
and standards so the router does not need to re-invent the service. So, we still
end up with a unified IPv6ND/DHCPv6 service -it's just that requesting nodes
only ever see RS/RA and never see any DHCPv6 messaging.

Comments?

Fred

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, January 26, 2018 9:18 AM
To: [email-masked]
Subject: I-D Action: draft-templin-6man-dhcpv6-ndopt-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : IPv6 Neighbor Discovery Extensions for Prefix Delegation
        Author          : Fred L. Templin
	Filename        : draft-templin-6man-dhcpv6-ndopt-02.txt
	Pages           : 10
	Date            : 2018-01-26

Abstract:
   IPv6 Neighbor Discovery (IPv6ND) specifies a control message set for
   nodes to discover neighbors, routers, prefixes and other services on
   the link.  It also supports a manner of StateLess Address
   AutoConfiguration (SLAAC).  The Dynamic Host Configuration Protocol
   for IPv6 (DHCPv6) specifies a service for the stateful delegation of
   addresses and prefixes.  This document presents IPv6ND extensions for
   providing a single unified autoconfiguration service.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-templin-6man-dhcpv6-ndopt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-templin-6man-dhcpv6-ndopt-02
https://datatracker.ietf.org/doc/html/draft-templin-6man-dhcpv6-ndopt-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-templin-6man-dhcpv6-ndopt-02

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Jan 2018 08:28:43 +1300

James,
On 27/01/2018 04:23, james woodyatt wrote:
> Yes, that’s only one of the many reasons I have misgivings about this proposal. But then, I’m uneasy about L=0 in the PIO, 

Why? If you mean the usage advocated in https://tools.ietf.org/html/rfc8028#section-2.1,
it doesn't carry any more of a spoofing risk than a PIO with L=1, that I can see.

L=0 doesn't mean "this prefix is off-link". It means "I'm not saying that this prefix
is on-link".

   Brian

> and I hate the whole of DHCP, so I’m obviously far out of step with rough consensus.
> 
> —sent from my phone
>

---

From: james woodyatt <[email-masked]>
Date: Fri, 26 Jan 2018 11:41:42 -0800

On Jan 26, 2018, at 11:28, Brian E Carpenter <[email-masked]> wrote:
> is on-link”.

I think you’ve mischaracterized what L=0 means here. I would say it more accurately signals: “I’m not saying whether or not this prefix is on-link, but if you know what’s good for you, you’ll trust me to route it for you, at least until another router here expressly tells you that it’s on-link. But don’t hold your breath. Seriously, you can send all the neighbor solicits you want, but you’re really naïve if you think this network is going to deliver you any neighbor advertisements for it without giving you a PIO with L=1."

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Jan 2018 11:45:19 +1300

> I think you’ve mischaracterized what L=0 means here. I would say it more accurately signals: “I’m not saying whether or not this prefix is on-link, but if you know what’s good for you, you’ll trust…

Yes, on most networks. But I'm still not getting why there's any difference from the point of view of detecting routers that have no business existing. If a random person plugs a router into my network and sends PIOs, how do I know whether to trust them or not, regardless of the L bit?

Maybe that's a question for OPSEC?

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 27 Jan 2018 07:37:38 +0100 (CET)

> This draft is marked Experimental. So let's keep the experiment simple. Only if simplicity can be proven not to work should we experiment with more complex solutions.

Agreed. My thoughts on this is that I would like to keep PIO-X as simple 
as possible. I would like to leave out all the if:s and but:s about link 
types, whether the host is alone or not, how this affects redirect 
handling etc. That's up to the network implementor, ie "don't send PIO-X 
packets unless you can somehow assure that only a single host gets the 
packet".

If someone wants to write a solicited-PIOX draft to request a specific 
prefix from the router, then that can be a different draft. I am not 
opposed to it (actually, it's along the lines of what I have considered 
before), but I am opposed to lumping these together.

In RFC8273 style deployments it looks like L2 security is done through 
"forced forwarding" or similar mechanism, meaning it could be similar to 
"NBMA" style network, but on ethernet. That's not the same thing as saying 
"you're alone on this link", because at least from the router POV, you're 
not.

So I'd like to leave L2 out of these documents as much as possible at this 
time. I'd prefer if we created operational documents dealing with L2 
implications at a later date after we have experience from the PIO-X 
experiments.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Jan 2018 08:29:38 -0500

STARK, BARBARA H <[email-masked]> wrote:
    > -1
    > This proposal (add a solicited mode) adds far too much unnecessary
    > complexity for what I see as the primary use cases. When the
    > unsolicited prefix is provided, the host can choose to take it or leave
    > it. Just like with SLAAC. A host isn't required to generate an address
    > from an advertised SLAAC prefix. It can, if it wants. And the host
    > isn't required to inform the router that it wants to do SLAAC.

I agree that there should be one mode.
I wonder if perhaps that mode should be solicited mode?

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Jan 2018 08:37:35 -0500

Brian Carpenter wrote:
    bc> Why? If you mean the usage advocated in
    bc> https://tools.ietf.org/html/rfc8028#section-2.1,
    bc> it doesn't carry any more of a spoofing risk than a PIO with L=1,
    bc> that I can see.

    bc> L=0 doesn't mean "this prefix is off-link". It means "I'm not
    bc> saying that this prefix
    bc> is on-link”.

james woodyatt <[email-masked]> wrote:
    > I think you’ve mischaracterized what L=0 means here. I would say it
    > more accurately signals: “I’m not saying whether or not this prefix is
    > on-link, but if you know what’s good for you, you’ll trust me to route
    > it for you, at least until another router here expressly tells you
    > that it’s on-link. But don’t hold your breath. Seriously, you can send
    > all the neighbor solicits you want, but you’re really naïve if you
    > think this network is going to deliver you any neighbor advertisements
    > for it without giving you a PIO with L=1."

I'm with James here.
Except that he was nice and used "naive" rather than stronger language :-)
(Insert Rocket from Guardians of the Galaxy using the wrong eye to winK)

It seems to me that there are attacks where a malicious node sends RAs
with L=0 or L=1 and each has potential uses to attack a host.  None of these
are worse than the situation with IPv4 and ARP, except that it's properly at
layer-3 now.  I wish we could find an incremental lever to make SEND worth
deploying.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 29 Jan 2018 14:58:07 +0100 (CET)

On Mon, 29 Jan 2018, Michael Richardson wrote:

> with L=0 or L=1 and each has potential uses to attack a host.  None of 
> these are worse than the situation with IPv4 and ARP, except that it's 
> properly at layer-3 now.  I wish we could find an incremental lever to 
> make SEND worth deploying.

For me, SEND is useless. It solves such a small part of the problem space 
that it's of next to no use.

The only way to properly solve the problem is with SAVI style approach of 
forwarding devices enforcing what's going on. Encrypting/authorizing RAs 
just solves a minor part of the problem.

SEND is obviously not deployable, or we would have it by now. SAVI style 
enforcement has been deployed for 15+ years now, and is in wide use.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Jan 2018 09:40:06 -0500

>> It seems to me that there are attacks where a malicious node sends RAs with
    >> L=0 or L=1 and each has potential uses to attack a host.  None of these are
    >> worse than the situation with IPv4 and ARP, except that it's properly at

    > that it's of next to no use.

I agree with you.
I'm lamenting that we don't have a "SEND" that solved the bigger problem of
trust at the ND layer.

    > forwarding devices enforcing what's going on. Encrypting/authorizing
    > RAs just
    > solves a minor part of the problem.

It's the infrastructure behind the authorization that would be interesting.
How does SAVI prevent a malicious node on a truly broadcast media
(wifi without smart APs, or ethenret with unmanaged switches) from screwing
with another node?

If the answer is, "it doesn't", that's why we have smart APs and managed
ethernet, then that's okay.  But if that's the case, then I think that we
should accept that the "LAN" is actually no longer broadcast, and is a
star/hub-spoke, and we should architect on in that way.

I think that pio-exclusive is in many ways about that realization.

    > SEND is obviously not deployable, or we would have it by now.

I don't think that this follows.  SEND is deployable, it just doesn't bring
any incremental value to the first deployer.  The ROI was only at the end
of the fax effect.

    > SAVI style

SAVI has value to the node that deploys it, and it doesn't have to care about
anything else. It is therefore incrementally deployable.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 29 Jan 2018 15:52:50 +0100 (CET)

On Mon, 29 Jan 2018, Michael Richardson wrote:

> It's the infrastructure behind the authorization that would be 
> interesting. How does SAVI prevent a malicious node on a truly broadcast 
> media (wifi without smart APs, or ethenret with unmanaged switches) from 
> screwing with another node?

Well, that's not what SAVI is so it doesn't prevent that. SAVI is "RA 
guard" "DHCP inspection" etc, which implicitly means managed switches and 
smart APs.

> I don't think that this follows.  SEND is deployable, it just doesn't 
> bring any incremental value to the first deployer.  The ROI was only at 
> the end of the fax effect.

I looked into SEND 5+ years ago. Back then the cryptographic information 
distribution method as out of scope, and I couldn't find how to get that 
onto hosts. Has this changed?

> SAVI has value to the node that deploys it, and it doesn't have to care 
> about anything else. It is therefore incrementally deployable.

It has value to the network that deploys it. Nodes don't need to deploy 
anything, it requires no end system changes.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 29 Jan 2018 15:00:00 +0000

Mikael Abrahamsson wrote:
> Nodes don't need to deploy anything, it requires no end system changes.

just smart l2 / access edge kit, and increasingly smarter over time.

Nick

---

From: james woodyatt <[email-masked]>
Date: Mon, 29 Jan 2018 07:56:25 -0800

The network creates value for itself at the expense of destroying the opportunity for hosts to make their own decisions about the authenticity of network control plane messages.

This perception that it’s always better when hosts have no choice but to trust the network entirely with the keys to control literally everything, and if something goes wrongs, well that’s your fault for choosing the wrong network. It’s peculiar.

—sent from my phone

> On Jan 29, 2018, at 06:52, Mikael Abrahamsson <[email-masked]> wrote:
> 
> It has value to the network that deploys it. Nodes don't need to deploy anything, it requires no end system changes.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 29 Jan 2018 16:29:44 +0000

james woodyatt wrote:
> This perception that it’s always better when hosts have no choice but
> to trust the network entirely with the keys to control literally
> everything, and if something goes wrongs, well that’s your fault for
> choosing the wrong network. It’s peculiar.

no, it's reality and what's peculiar is falling into the trap of
assuming that the world's networking requirements are uniform, either
from the host or the network point of view.  There are plenty of
situations where laissez-faire networks of the type you describe are
appropriate, even useful.  There are plenty of others which need to have
rigid connectivity policies applied.  SAVI is mandatory in lots of these
situations.

Nick

---

From: Sander Steffann <[email-masked]>
Date: Mon, 29 Jan 2018 17:51:25 +0100

Hi,

> There are plenty of

Yep. Look at banks. Either they are in control and can audit everything, or it isn't allowed. The security department overrules the networking department any day. They deploy DHCPv6 with SAVI. I asked them about Android, and the answer was simple: if it doesn't play nice with our security and auditing infrastructure then we won't use/allow/etc it. No exceptions.

There are other decision factors besides what would be nice from the network's or device's point of view.

Cheers,
Sander

---

From: james woodyatt <[email-masked]>
Date: Mon, 29 Jan 2018 09:43:49 -0800

> rigid connectivity policies applied.  SAVI is mandatory in lots of these

I’m not arguing against SAVI mandates. I’m saying how it’s very peculiar to think that SEND has no utility where SAVI is mandated. It’s even more peculiar that I even have to explain that here.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jan 2018 08:12:28 +1300

On 30/01/2018 03:40, Michael Richardson wrote:

<big snip>
> ...then I think that we

To be future proof, you may have to stop using the phrase "LAN" at all,
and accept that the L2 topology may be a local mesh (of which hub & spoke
is a simple case). That means rethinking everything, not just details
like the L bit.

   Brian

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 29 Jan 2018 19:28:25 +0000

james woodyatt wrote:
> I’m not arguing against SAVI mandates. I’m saying how it’s very peculiar
> to think that SEND has no utility where SAVI is mandated. It’s even more
> peculiar that I even have to explain that here.

then I wasn't the only person who didn't understand your email :-)

The issue with SEND isn't that it's not useful - it probably would be if
it were widely deployed.  The problem relates the trust anchor: there is
only a limited set of situations where the network operator has
administrative control over the client devices to the point that they
can insert a specific trust anchor into the client device.  There are,
of course, situations where this is probably the case, e.g. large
enterprise, etc, but there is often a substantial discongruity between
administrative control over the network and the client device sets.

Even then, SEND is hard to argue.  If you can tie down a port with
802.1x and implement v4 / v6 source address validation (both of which
are already widely deployed), you've gone a long way towards ensuring
better security for ipv6 for most network types, while having saved
yourself the complication associated with managing a SEND
infrastructure.  Again, this isn't an argument that SEND has no utility,
just that it's not applicable to many cases and isn't an easy sell in
many of the rest.

Nick

---

From: Mark Smith <[email-masked]>
Date: Tue, 30 Jan 2018 06:54:00 +1100

+1

I think the fundamental problem is a single LAN has the property of
allowing any LAN attached node (i.e. Layer 2 node) to send unicast,
multicast or broadcast frames to any other node. That's the property
people are trying to suppress with L=1, Private VLANs, RA guard etc.

Broadband with PPPoE solves this properly by creating a logical "LAN"
per host. The drawback is that it requires the host to have and use a
PPPoE client. Another drawback is that the PPPoE "LAN" is truly
point-to-point, meaning that it isn't possible to have router
redundancy; it isn't possible to have a PPPoE link with 1 host and 2
routers, with the routers running e.g. VRRP.

The property a LAN we're trying to keep is the natural grouping of
hosts together within an aggregateable IPv6 address space i.e. a
subnet, and that the creation of the aggregation boundary occurs
automatically at the boundary of the LAN.

So I think what we want is:

- on demand creation of per-host LANs, providing proper layer 2 and
therefore proper layer 3 per-host isolation

- without the host requiring to have or enable any special client such
as a PPPoE client

- support for a host to have 2 or more routers available to it for redundancy

- automatically configured address aggregation that occurs on the edge
router, so the group of attached hosts can be immediately represented
in the routing domain via a single route announcement

It's possible to configure all of this with per-host VLANs and route
aggregation today, it's just not or not that automatic.

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 29 Jan 2018 20:20:21 +0000

> From: ipv6 [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
> Sent: Friday, January 26, 2018 10:38 PM
> Cc: IPv6 List <[email-masked]>
> Subject: RE: draft-pioxfolks-6man-pio-exclusive-bit-02.txt
> 
> prefix from the router,

Actually, it is not just about soliciting a *specific* prefix; it is also about
soliciting *any* prefix. The main point is that the node asks for a prefix,
and the router delivers.

That is different than the router delivering a prefix to a node that has not
asked for one (and may not be expecting to receive one). For example,
how does the node decline a prefix that is unwanted?

> then that can be a different draft. I am not

Here's the draft:

It now outlines three options for prefix solicitation:

1) DHCPv6 options in RS/RA messages
2) PIO-X options in RS messages
3) Out-of--band network login messaging

Option 1) is based on DHCPv6 messaging, and is an alternative to PIO-X.
Both options 2) and 3) expect PIO-X in returned RA messages, and so
they support the PIO-X proposal.

I think this can go as a separate draft, but if so it should be in parallel
with the main PIO-X spec.

Thanks - Fred
[email-masked]

---

From: Ole Troan <[email-masked]>
Date: Mon, 29 Jan 2018 21:24:21 +0100

> automatically at the boundary of the LAN.

If this is justifying bridges, I am not sure this is a property we particularly want to keep.
Why?

Ole

---

From: David Farmer <[email-masked]>
Date: Mon, 29 Jan 2018 15:12:27 -0600

> aggregation today, it's just not or not that automatic.

Not explicitly stated but I think implied by "without the host requiring to
have or enable any special client such as a PPPoE client" is support for
standard RFC 2464 hosts unchanged, at least hosts if not routers.

I want to make the implication explicit so I can challenge it.  What about
starting with a new link type using a new ethertype? Yes, that means new
code on everything both hosts and routers, but it also allows old
assumptions to be tossed out.

I'm not sure you can realistically rethink the LAN or L2 if we want to be
backward compatible with many of the very ideas we want to rethink.

Regards,

---

From: Mark Smith <[email-masked]>
Date: Tue, 30 Jan 2018 08:44:35 +1100

> automatically at the boundary of the LAN.

If this is justifying bridges,

It's not.

It's observing that LANs have created implicit IP address aggregation
boundaries right at the edge of the network. That is also how people are
used to and taught to plan and maintain their IP address space. People now
also use subnets to group hosts that are in the same security domain. The
"subnet model" of IP addressing is ingrained, and I expect it is one reason
why people are trying to have imperfect host isolation within the same IPv6
subnet.

I think this is about a fundamental security question:

When a new IPv6 host is attached to a link, that other IPv6 hosts may
already be attached to, can the new IPv6 host be trusted with the ability
unicast or multicast frames and therefore IPv6 packets to and directly to
all or any other IPv6 hosts on the link.

If the answer is yes, then the hosts can be part of the same layer 2 link
("LAN"), and can share the same /64.

If the answer is no, then the new host must be entirely isolated at layer 2
from all other IPv6 hosts. Reaching other hosts must be via a router. Each
isolated host has it's own /64, either on the link between it and its
routers, or the /64 is delegated to the host.

I used to think the middle ground of "Private VLANs", TR-101 N:1, Wifi
Station isolation etc. was OK, however I've realised that all the
workarounds and preventions to try to achieve host isolation, while sharing
the same IPv6 /64 subnet, are more trouble than they're worth. (
https://tools.ietf.org/id/draft-smith-6man-link-locals-off-link-00.txt).
Just layer 2 isolate hosts when that is your security requirement, and then
use the conventional IPv6 addressing model - subnet per (now host
dedicated) link. Unlike in IPv4, we have the address space to do that.

Regards,
Mark.

I am not sure this is a property we particularly want to keep.
Why?

Ole

---

From: DY Kim <[email-masked]>
Date: Tue, 30 Jan 2018 10:05:18 +0900

The subnet in mind here might be one which acts as

  1) an address-aggregation boundary AS WELL AS
  2) a routing boundary (bordered by a router)

I wonder how firmly item 1) is ingrained in IPv6. Although ‘subnet’ is defined in roc 4291, I wonder whether that is for just operational convenience/practice or for an absolute architectural requirement of IPv6.

Theoretically, ‘subnet’ can dispense with item 1) and only keep item 2. Is such a rethinking absolutely out of scope for IPv6?

To me, the notion of subnet with both properties of the above two items seems to be a result of less careful continuation of IPv6-like architectural convention.

---
DY

> On 30 Jan 2018, at 06:44, Mark Smith <[email-masked]> wrote:
> 
> The "subnet model" of IP addressing is ingrained (in IPv6).

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 30 Jan 2018 06:09:02 +0100 (CET)

> aggregation today, it's just not or not that automatic.

This is literally what "forced forwarding" and etc mechanisms have tried 
to do since early 2000:ds. It's in wide use in access networks today.

This was mitigated outside of the IETF 15 years ago. Still today when I 
bring up SAVI or similar techniques, people either fight back or yawn at 
me.

I keep bringing SAVI up once a year or something just to remind people 
that it exists, but people just don't care/want to hear about it. If 
things are changing, few people would be happier than I would.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 30 Jan 2018 06:27:57 +0100 (CET)

On Tue, 30 Jan 2018, Mark Smith wrote:

> Just layer 2 isolate hosts when that is your security requirement, and 
> then use the conventional IPv6 addressing model - subnet per (now host 

That's what RFC8273 is all about. It just implicitly states that all 
devices are untrusted and should be in their own /64 instead of having a 
mechanism determine if there is something to share.

Providing a new ethertype for this kind of "autoconfig L2 ethernet" isn't 
needed, this can already be done by the network equipment. There is no 
need to change all hosts. This is already a solved problem, it's just not 
solved in way that some IETFers are interested in.

I advocate unique /64 per port/device for enterprise networks. Most access 
equipment supports this already (fairly common that managed L2 access 
switches has ethertype-based vlans and can do L3 routing anyway). It's 
just that when I present this solution to people I interact with, then 
people go bananas. Unique /64 per port is just such a foreign concept to 
most people who are used to handling a single unique IPv4 address per 
device.

When I tell them their IPv6 solution can be different from their IPv4 
setup (again, ethertype based vlans), people just go GAAAAH. Even people 
who work at ISPs, not to even speak of enterprise peeps.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 30 Jan 2018 06:33:14 +0000

Hello Brian:

Introducing NBMA topologies implies routing.

RPL takes some of its origins in an effort to build ND for a general NBMA network(https://datatracker.ietf.org/doc/draft-thubert-nina/). Initially DIOs were RA-DIO, and DAO was an option of an NA. 6Lo ND and RPL were one.

The game of areas caused them to split and slightly diverge, till at some point ROLL decided for a separate ICMP. But we have a working solution for that problem.

All the best;

Pascal

Le 29 janv. 2018 à 20:12, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> a écrit :

<big snip>
...then I think that we

  Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Jan 2018 11:58:41 -0300

> just that it's not applicable to many cases and isn't an easy sell in

Besides, lack of support in client OSes means that you'd do much of such
work in vein, and you'd need something else that would actually work for
such client OSes. And if you have something that work with all such
client OSes, then that reduces the incentive of such client OSes from
supporting SeND.

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 30 Jan 2018 16:33:59 +0000

Hi, just having 802.1X only protects access at the link layer. Something like
SEND is necessary to protect access at the network layer. For example, even
if both Bob and Alice can access the link via 802.1X, without something like
SEND there is nothing to stop Bob from impersonating Alice at the network
layer and stealing Alice's services.

Thanks - Fred

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 30 Jan 2018 16:48:40 +0000

> layer and stealing Alice's services.

this is what SAVI does, depending on how it's implemented.

Nick

---

From: Mark Smith <[email-masked]>
Date: Wed, 31 Jan 2018 06:01:11 +1100

On 30 January 2018 at 16:09, Mikael Abrahamsson <[email-masked]> wrote:
> This is literally what "forced forwarding" and etc mechanisms have tried to
> do since early 2000:ds. It's in wide use in access networks today.

MAC forced forwarding is another layer 2 hack to try to isolate hosts,
without them each having their own dedicated IP subnet, and their own
individual and dedicated router interface (logical or physical) to
serve the per-host dedicated prefix.

> bring up SAVI or similar techniques, people either fight back or yawn at me.
>
> I keep bringing SAVI up once a year or something just to remind people that
> it exists, but people just don't care/want to hear about it. If things are
> changing, few people would be happier than I would.
>
> --

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Wed, 31 Jan 2018 06:41:36 +1100

On 30 January 2018 at 16:27, Mikael Abrahamsson <[email-masked]> wrote:
> That's what RFC8273 is all about. It just implicitly states that all devices
> are untrusted and should be in their own /64 instead of having a mechanism
> determine if there is something to share.

RFC8273 fails the proper layer 2 isolation/per-host link/LAN requirement too.

The hosts are all sharing the same Link-Local prefix, rather than each
host having its own instance of the Link-Local prefix. They're all
using the same router interface, rather than each host having its own
dedicated router interface. There is sharing of IP layer resources
between multiple hosts, so the hosts are not on separate links.

Per RFC4291, in the Addressing Model section,

"Currently, IPv6 continues the IPv4 model in that a subnet prefix is
   associated with one link."

multiple hosts that share just one common IPv6 subnet of possibly a
number on the link are members of the same one link.

The PPPoE model meets the per-host link requirement, with two drawbacks:

- requires a host to have and to run a PPPoE client, rather than just
emit vanilla IPv6 frames.

- doesn't support stateless router redundancy i.e. the logical link
that PPPoE creates is a point-to-point, so it isn't possible to have a
"3 ended" PPPoE link, with the host and 2 routers, with the routers
running e.g. VRRP.

> needed, this can already be done by the network equipment.

So when a host attaches to a port, the layer 2 device allocates a new
virtual link, dedicated to the host, and then signals the router,
which then allocates a new Link-Local prefix, new GUA and possibly ULA
prefix, and then creates a new router interface for that individual
host?

> There is no need
> to change all hosts. This is already a solved problem, it's just not solved
> in way that some IETFers are interested in.
>
> switches has ethertype-based vlans and can do L3 routing anyway). It's just
> that when I present this solution to people I interact with, then people go
> bananas. Unique /64 per port is just such a foreign concept to most people
> who are used to handling a single unique IPv4 address per device.
>
> When I tell them their IPv6 solution can be different from their IPv4 setup
> (again, ethertype based vlans), people just go GAAAAH. Even people who work
> at ISPs, not to even speak of enterprise peeps.
>

It's easy to forget that Private VLANs were created not for security
reasons, but to save IPv4 addresses. People want to continue with
these models because they're comfortable with them, and in the case of
Private VLANs/TR-101 N:1/Wifi station isolation, easy to setup and
don't impose any specific requirements (such as a special client like
a PPPoE client) on the attaching hosts.

What method or protocol exists to signal between a layer 2 edge device
and a router for the router to allocate new instances of
Link-Local/GUA/ULA prefixes for a new-host and to spin up a new
logical layer 3 router interface? I think that people may be more
willing to accept per-host IPv6 prefixes is the configuration is just
as easy to configure and operate as Private VLANs etc. with a single
IPv4 prefix is.

I don't have any experience or detailed knowledge of it , however I'm
reminded of Access Node Control Protocol - RFC6320. Perhaps a
generalised version of that for other types of layer 2 edge devices
might be an option.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Jan 2018 08:56:30 +1300

> Introducing NBMA topologies implies routing.

Yes, or at least routing-like behaviour. 

> RPL takes some of its origins in an effort to build ND for a general NBMA network(https://datatracker.ietf.org/doc/draft-thubert-nina/). Initially DIOs were RA-DIO, and DAO was an option of an NA.…

As you may know, we chose a prefix per node and RPL for the ANIMA autonomic control plane, which makes us rather independent of the underlying topology. But it challenges protocols based on the assumption that link-local multicast is a thing.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Wed, 31 Jan 2018 08:18:55 +1100

On 30 Jan. 2018 17:33, "Pascal Thubert (pthubert)" <[email-masked]>
wrote:

Hello Brian:

The trouble is this isn't an NBMA link layer, although it might seem like
it.

The limitation of NBMA is that they don't support multicasting to some or
all of the attached nodes. IPv6 support for NBMA goes to the effort of
restoring that capability by emulating it.

On the links described here, that multicast restriction is seen to be a
security advantage, and if it was restored via emulation, it is a security
policy violation.

NBMA links do not intentionally prevent attached nodes directly sending
packets sending to each other. That is a limitation of NBMA links that is
to be overcome by either hair pinning via the default router (via L=0), or
by setting up a direct virtual circuit or path of some sort between the
nodes and ICMP redirects.

In other words, on an NBMA link, these constraints are natural ones to work
around. On a Private VLAN, TR-101 etc. link, they're intentionally imposed
ones that must not be worked around because they exist for security
reasons, not because the link doesn't naturally support those capabilities.

Regards,
Mark.

RPL takes some of its origins in an effort to build ND for a general NBMA
network(https://datatracker.ietf.org/doc/draft-thubert-nina/). Initially
DIOs were RA-DIO, and DAO was an option of an NA. 6Lo ND and RPL were one.

The game of areas caused them to split and slightly diverge, till at some
point ROLL decided for a separate ICMP. But we have a working solution for
that problem.

All the best;

Pascal

Le 29 janv. 2018 à 20:12, Brian E Carpenter <[email-masked]> a
écrit :

<big snip>

...then I think that we

  Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 30 Jan 2018 22:04:53 +0000

Hi, I have been making statements about NBMA links for a long time now
both on the lists and in drafts. AERO is based on the NBMA link model:

https://datatracker.ietf.org/doc/draft-templin-aerolink/

as was ISATAP [RFC5214]. But, please note well that AERO *is not*
the offspring of ISATAP, although they are distant cousins.

Thanks - Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Tuesday, January 30, 2018 1:19 PM
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Michael Richardson <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: L=0 [was draft-pioxfolks-6man-pio-exclusive-bit-02.txt]

On 30 Jan. 2018 17:33, "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>> wrote:

Hello Brian:

The trouble is this isn't an NBMA link layer, although it might seem like it.

The limitation of NBMA is that they don't support multicasting to some or all of the attached nodes. IPv6 support for NBMA goes to the effort of restoring that capability by emulating it.

On the links described here, that multicast restriction is seen to be a security advantage, and if it was restored via emulation, it is a security policy violation.

NBMA links do not intentionally prevent attached nodes directly sending packets sending to each other. That is a limitation of NBMA links that is to be overcome by either hair pinning via the default router (via L=0), or by setting up a direct virtual circuit or path of some sort between the nodes and ICMP redirects.

In other words, on an NBMA link, these constraints are natural ones to work around. On a Private VLAN, TR-101 etc. link, they're intentionally imposed ones that must not be worked around because they exist for security reasons, not because the link doesn't naturally support those capabilities.

Regards,
Mark.

Pascal

<big snip>

...then I think that we

  Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 31 Jan 2018 10:49:11 +0100 (CET)

> RFC8273 fails the proper layer 2 isolation/per-host link/LAN requirement 

No, it doesn't. It just doesn't specify how this is to be achieved. I am 
of the opinion that it doesn't need to, and it shouldn't. Yes, someone 
implementing this should make sure that L2 assures that customers can't 
spoof each other, that source validation etc is in place, but I am of the 
opinion that RFC8273 doesn't need to specify how that should be done.

> host having its own instance of the Link-Local prefix. They're all using 
> the same router interface, rather than each host having its own 

Sure.

> number on the link are members of the same one link.

But the GUA prefix isn't the same, just the LLA.

> virtual link, dedicated to the host, and then signals the router, which 
> then allocates a new Link-Local prefix, new GUA and possibly ULA prefix, 
> and then creates a new router interface for that individual host?

No. Those are your requirements, it's you who are saying all of those are 
needed. Not me.

> generalised version of that for other types of layer 2 edge devices 

PPPoE doesn't solve the mac address duplication problem, either. Only 
separate L2 per user solves that.

So what I have been proposing for lots of years is to keep the 1:N model 
for IPv4 (because that's what a lot of people do), but create 
one-vlan-per-user for IPv6, using ethertype based vlans. This requires no 
host changes.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 31 Jan 2018 11:38:16 +0100 (CET)

On Wed, 31 Jan 2018, Mikael Abrahamsson wrote:

> So what I have been proposing for lots of years is to keep the 1:N model for 
> IPv4 (because that's what a lot of people do), but create one-vlan-per-user 
> for IPv6, using ethertype based vlans. This requires no host changes.

Struck me that this might be confusing.

We both want L2 separation, it's just that I prefer to have it done by the 
network access equipment and not change the hosts, whereas you seem to 
propose a new mechanism to be implemented in the hosts.

This new mechanism would have the same issues as SEND and 802.1x, in that 
it needs authentication, cryptographic information distributed, who to 
trust, certificate chains and other things that we (humanity as a whole) 
seem to be really bad at.

WPA3 which was announced recenently seems to have what I have asked about 
for years, which is an encrypted mode that is "trust on first use". So you 
don't put in a password when connecting to the wifi, it just blindly 
trusts the cryptographic information, because it's better than nothing.

So if devices would support SEND the same way, then we'd have a 
significantly increased security layer, where for instance the router can 
indicate that "if you trust the information I send you, please only talk 
to my mac address, don't talk to anyone else, oh btw, here is your /64 
that is yours only, you can start using it immediately". This doesn't 
solve any L2 issues, but at least sets up some kind of trust between the 
router and the device.

Perhaps the WIFI/WPA layer for wifi could indicate cryptographic 
information to trust to bootstrap that as well, for instance "if you 
choose to connect to this network, here is the bootstrap information you 
need to have in order to understand SEND on this network". Then the device 
can choose what to do based on its own security credentials store or 
perhaps verify things via some other means it has.

So I am not opposed to SEND, my problem with it is that it hasn't been 
deployed and I haven't read up on it in the past 5+ years because I didn't 
see it as deployable (back then). If we want it to be generally deployed 
then perhaps we should go to wifi alliance and have SEND be part of what 
they're doing to bootstrap the whole thing?

---

From: Ole Troan <[email-masked]>
Date: Wed, 31 Jan 2018 11:47:58 +0100

Mikael,

>> So what I have been proposing for lots of years is to keep the 1:N model for IPv4 (because that's what a lot of people do), but create one-vlan-per-user for IPv6, using ethertype based vlans. This requires no host changes.
> 
> We both want L2 separation, it's just that I prefer to have it done by the network access equipment and not change the hosts, whereas you seem to propose a new mechanism to be implemented in the hosts.

Almost all networks have this separation already.
The physical network is a hub and spoke, and the thick yellow cable BMA network is emulated by Ethernet bridges.
Just replace wherever there is bridge with a router in the topology and you have L2 isolation.

That conceptual model should suffice in the draft and would be a good starting point for defining the mechanism.

As has been clear from this thread, 1:N VLANs, SEND, Anima... albeit enjoyable rat-holes... continuing down those paths will not progress this work.

Ole

> 
> This new mechanism would have the same issues as SEND and 802.1x, in that it needs authentication, cryptographic information distributed, who to trust, certificate chains and other things that we (humanity as a whole) seem to be really bad at.
> 
> WPA3 which was announced recenently seems to have what I have asked about for years, which is an encrypted mode that is "trust on first use". So you don't put in a password when connecting to the wifi, it just blindly trusts the cryptographic information, because it's better than nothing.
> 
> So if devices would support SEND the same way, then we'd have a significantly increased security layer, where for instance the router can indicate that "if you trust the information I send you, please only talk to my mac address, don't talk to anyone else, oh btw, here is your /64 that is yours only, you can start using it immediately". This doesn't solve any L2 issues, but at least sets up some kind of trust between the router and the device.
> 
> Perhaps the WIFI/WPA layer for wifi could indicate cryptographic information to trust to bootstrap that as well, for instance "if you choose to connect to this network, here is the bootstrap information you need to have in order to understand SEND on this network". Then the device can choose what to do based on its own security credentials store or perhaps verify things via some other means it has.
> 
> So I am not opposed to SEND, my problem with it is that it hasn't been deployed and I haven't read up on it in the past 5+ years because I didn't see it as deployable (back then). If we want it to be generally deployed then perhaps we should go to wifi alliance and have SEND be part of what they're doing to bootstrap the whole thing?
> 
> --

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 31 Jan 2018 19:59:38 +0900

> Just replace wherever there is bridge with a router in the topology and

Sure. But in a large class of networks (e.g., home networks) it is a
feature, not a bug, that devices can talk to each other and broadcast to
each other. Examples of things that require this to work are MDNS,
Chromecasting, and in general all sorts of peer-to-peer discovery
protocols, of which each app appears to build its own.

---

From: Ole Troan <[email-masked]>
Date: Wed, 31 Jan 2018 12:01:12 +0100

Lorenzo,

> Sure. But in a large class of networks (e.g., home networks) it is a feature, not a bug, that devices can talk to each other and broadcast to each other. Examples of things that require this to work are MDNS, Chromecasting, and in general all sorts of peer-to-peer discovery protocols, of which each app appears to build its own.

yes, and it is equally a feature to prohibit that from happening.

Cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 31 Jan 2018 20:05:51 +0900

> yes, and it is equally a feature to prohibit that from happening.

Agreed that other (misguided ;-)) people might see this as a feature. My
point is that we can't just throw out the shared subnet model and replace
it with prefix-per-host, because we'll break the use cases where multicast
is necessary.

---

From: Ole Troan <[email-masked]>
Date: Wed, 31 Jan 2018 12:08:52 +0100

> Agreed that other (misguided ;-)) people might see this as a feature. My point is that we can't just throw out the shared subnet model and replace it with prefix-per-host, because we'll break the use cases where multicast is necessary.

Multicast works perfectly well in this model. ;-)
Homenet has "solved" this problem though.

Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 31 Jan 2018 13:30:24 +0100 (CET)

On Wed, 31 Jan 2018, Lorenzo Colitti wrote:

> point is that we can't just throw out the shared subnet model and 
> replace it with prefix-per-host, because we'll break the use cases where 
> multicast is necessary.

Prefix-per-host still works if they retain shared LLA space and can talk 
L2 to each other (perhaps via the router that does proxying).

This is why I don't want to conflate prefix-per-host with L2 separation. 
It's just not the same thing. There are modes of operation already 
deployed where things are done in the grey zone between "everybody shares 
L2 and can do what they could on 10BASE-2" and "strict L2 separation".

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 31 Jan 2018 21:44:25 +0900

> L2 to each other (perhaps via the router that does proxying).

If they can talk at L2 to each other then they can mount any of the variety
of attacks, either against each other or against the infrastructure, that
prefix-per-host allows the network to prevent. For example, they can deny
each other the ability to form IPv6 addresses by faking DAD collisions. I
don't think you can fix this without allowing the hosts to mount state
exhaustion attacks on the router in fe80::/64 space.

> It's just not the same thing. There are modes of operation already deployed
> where things are done in the grey zone between "everybody shares L2 and can
> do what they could on 10BASE-2" and "strict L2 separation".

You might want to try writing down how this would work. I think you'll find
it's harder than it would appear at first sight.

---

From: Ole Troan <[email-masked]>
Date: Wed, 31 Jan 2018 13:47:38 +0100

Mikael,

> Prefix-per-host still works if they retain shared LLA space and can talk L2 to each other (perhaps via the router that does proxying).
> 
> This is why I don't want to conflate prefix-per-host with L2 separation. It's just not the same thing. There are modes of operation already deployed where things are done in the grey zone between "everybody shares L2 and can do what they could on 10BASE-2" and "strict L2 separation".

You can make this separate new work that would extend the simple model that pio-x assumes.
(Describing how to securely emulate a p2p link on top of a BMA link, that emulates BMA mode on top of a set of p2p links, doesn't seem like something that should go in the base document.)

Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 31 Jan 2018 14:09:02 +0100 (CET)

On Wed, 31 Jan 2018, Lorenzo Colitti wrote:

> If they can talk at L2 to each other then they can mount any of the 
> variety of attacks, either against each other or against the 
> infrastructure, that prefix-per-host allows the network to prevent.

Not if the network implements SAVI.

> You might want to try writing down how this would work. I think you'll 
> find it's harder than it would appear at first sight.

https://tools.ietf.org/html/rfc6620

For the SEND enthusiasts, there is even a SEND related SAVI RFC:

https://tools.ietf.org/html/rfc7219

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 31 Jan 2018 14:11:31 +0100 (CET)

On Wed, 31 Jan 2018, Ole Troan wrote:

> You can make this separate new work that would extend the simple model 
> that pio-x assumes. (Describing how to securely emulate a p2p link on 
> top of a BMA link, that emulates BMA mode on top of a set of p2p links, 
> doesn't seem like something that should go in the base document.)

I'd say most of it is already described in standards track RFCs by the 
SAVI WG.

I just don't think the knowledge about what has been done is very 
wide-spread in this WG.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 31 Jan 2018 22:21:18 +0900

> Not if the network implements SAVI.

But if it does, that allows the hosts to mount a state exhaustion attack on
the network by creating new IP addresses. Remember, one of the biggest
advantages of the prefix-per-host model is that it has none of the
scalability issues inherent in individually tracking IP addresses.

> https://tools.ietf.org/html/rfc6620

Sure. Now write down how it will scale without limiting the number of IP
addresses that each host can use.

---

From: Mark Smith <[email-masked]>
Date: Thu, 1 Feb 2018 03:44:17 +1100

On 31 Jan 2018 20:49, "Mikael Abrahamsson" <[email-masked]> wrote:

RFC8273 fails the proper layer 2 isolation/per-host link/LAN requirement
> too.

No, it doesn't. It just doesn't specify how this is to be achieved. I am of
the opinion that it doesn't need to, and it shouldn't. Yes, someone
implementing this should make sure that L2 assures that customers can't
spoof each other, that source validation etc is in place, but I am of the
opinion that RFC8273 doesn't need to specify how that should be done.

The hosts are all sharing the same Link-Local prefix, rather than each host
> having its own instance of the Link-Local prefix. They're all using the
> same router interface, rather than each host having its own dedicated
> router interface. There is sharing of IP layer resources between multiple
> hosts, so the hosts are not on separate links.
>

Sure.

You're saying hosts that have a common LL prefix *aren't* on the same link?

> reminded of Access Node Control Protocol - RFC6320. Perhaps a generalised
> version of that for other types of layer 2 edge devices might be an option.
>