Subject: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 02 Jul 2017 21:38:28 +0200

Hi John, Gunter,

While writing an article where I’ve included a reference to this work, I realized something that despite having read many times this document, I didn’t cached before.

The title of the document is “Unique IPv6 Prefix Per Host” but actually I think the overall idea of this work is more on the direction of “Unique IPv6 Prefix Per Link”.

I mean the document is talking always about “link”, whereas sometimes uses “host”, but I believe the intend is more on “host-links”, as everything is applicable to each link in case a host has several. Right? Or I’m missing anything?

I may require a very quick tidy-up of all the document (and I’m happy to review it or help, if you need that) to make sure that everything is consistent if you decide to change the title and make all the text coherent with that.

Regards,
Jordi

**********************************************
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 use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 3 Jul 2017 10:18:26 +0900

-1

I think "per host" is the best title. It clearly explains that the network
provides a unique prefix for every host. Of course, a host may be connected
to other networks at the same time, but that is true whether this draft is
in use or not.

"Per link" is not a good title, because a link almost always has a unique
prefix, even though in general there may be many hosts on it.

On Mon, Jul 3, 2017 at 4:38 AM, JORDI PALET MARTINEZ <
[email-masked]> wrote:

> Hi John, Gunter,
>
> While writing an article where I’ve included a reference to this work, I
> realized something that despite having read many times this document, I
> didn’t cached before.
>
> The title of the document is “Unique IPv6 Prefix Per Host” but actually I
> think the overall idea of this work is more on the direction of “Unique
> IPv6 Prefix Per Link”.
>
> I mean the document is talking always about “link”, whereas sometimes uses
> “host”, but I believe the intend is more on “host-links”, as everything is
> applicable to each link in case a host has several. Right? Or I’m missing
> anything?
>
> I may require a very quick tidy-up of all the document (and I’m happy to
> review it or help, if you need that) to make sure that everything is
> consistent if you decide to change the title and make all the text coherent
> with that.
>
> Regards,
> Jordi
>
>
>
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be aware
> that any disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
>
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 3 Jul 2017 09:23:23 +0200

> -1
> 
> I think "per host" is the best title. It clearly explains that the network provides a unique prefix for every host. Of course, a host may be connected to other networks at the same time, but that is true whether this draft is in use or not.
> 
> "Per link" is not a good title, because a link almost always has a unique prefix, even though in general there may be many hosts on it.

in my implementation I have a unique link per host.

Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Jul 2017 08:40:10 -0400

> in my implementation I have a unique link per host.

So you create vlans somehow...?

---

From: Ole Troan <[email-masked]>
Date: Mon, 3 Jul 2017 15:07:31 +0200

Ted,

> So you create vlans somehow...?

something that looks like a point to point interface on the router side.

e.g.:
interface Ethernet0.X point-to-point <remote-macaddress>

https://gerrit.fd.io/r/#/c/7224/

Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Jul 2017 09:16:16 -0400

> something that looks like a point to point interface on the router side.

So hosts on the link communicate through the router.   The reason I ask is that while this is certainly a valid way of doing it, it isn't clear to me that it's necessary.

---

From: Ole Troan <[email-masked]>
Date: Mon, 3 Jul 2017 21:54:23 +0200

> On 3 Jul 2017, at 15:16, Ted Lemon <[email-masked]> wrote:
> 

correct. almost all commonly used network topologies are point to point anyway.
just stop emulating a shared media with bridges and do routing at those points instead.
long time since anyone has seen a thick yellow cable.

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 4 Jul 2017 08:38:00 +1200

> long time since anyone has seen a thick yellow cable.

But, as the saying goes, "just say multicast".

    Brian

---

From: Ole Troan <[email-masked]>
Date: Mon, 3 Jul 2017 23:14:15 +0200

> But, as the saying goes, "just say multicast".

what about multicast?
no change in location of replication point, and the commonly used multicast scopes are of course much smaller.

Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Jul 2017 17:37:48 -0400

> no change in location of replication point, and the commonly used multicast scopes are of course much smaller.

This breaks service discovery.

---

From: Ole Troan <[email-masked]>
Date: Mon, 3 Jul 2017 23:41:39 +0200

> On 3 Jul 2017, at 23:37, Ted Lemon <[email-masked]> wrote:
> 

It breaks the assumption that everything you want discovered is within the same broadcast domain. Many think that assumption was broken anyway. 

Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Jul 2017 17:49:37 -0400

> It breaks the assumption that everything you want discovered is within the same broadcast domain. Many think that assumption was broken anyway. 

Given the document I'm presently working on, I wouldn't really argue with that, except to say that it's still the default assumption in most environments.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 4 Jul 2017 11:31:14 +1200

> Given the document I'm presently working on, I wouldn't really argue with that, except to say that it's still the default assumption in most environments.

Yes, and that has deeply impacted both a document I'm working on
(draft-ietf-anima-grasp) and a demo implementation thereof
(https://github.com/becarpenter/graspy/blob/master/grasp.py).

The cost of *not* having link-local multicast is considerable,
because it means that every node, however dumb, must replicate
and relay discovery in one way or another.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Jul 2017 20:24:59 -0400

Dnssd hybrid.proxy addresses this.

On Jul 3, 2017 7:31 PM, "Brian E Carpenter" <[email-masked]>
wrote:

> >> It breaks the assumption that everything you want discovered is within
> the same broadcast domain. Many think that assumption was broken anyway.
> >
> > Given the document I'm presently working on, I wouldn't really argue
> with that, except to say that it's still the default assumption in most
> environments.
>

---

From: Ole Troan <[email-masked]>
Date: Tue, 4 Jul 2017 08:59:44 +0200

Brian,

> and relay discovery in one way or another.

The solution I briefly described previously of course supports link-local multicast.

If your answer to the discovery problem is that we must put all nodes on the network in the same broadcast domain, we know that doesn't scale well. Apart from Taht showing that bridging links with very different properties doesn't work well either (wired and wireless). This was the premise for homenet.

For the current mDNS based discovery, that is already heavily filtered by the network in large L2 domains. It is just too noisy.

Since we have to solve the problem for multiple links anyway, does it then make a difference that logical topology follows physical topology and each host is on its own link?

Fingers crossed for hybrid dns-sd... the IETF glorious past in service discovery hasn't given me much confidence though. ;-)

Ole

---

From: Tim Chown <[email-masked]>
Date: Tue, 4 Jul 2017 11:17:38 +0000

> On 4 Jul 2017, at 07:59, Ole Troan <[email-masked]> wrote:
> 
> Brian,
> 

The hybrid proxy work was split at IETF97 into a discovery and an advertising proxy. The discovery proxy is about to be sent to the IESG (though it carries a reference to .home that needs fixing); see https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-06

The general approach is that unicast queries from a DNS-SD client for a specific subdomain allocated to a link, e.g. Building1.example.com, are forwarded until they reach the discovery proxy (as the delegated authoritative name server for that subdomain), and the unicast response is then synthesised from responses to a local multicast DNS query on the link. The new DNS Push work allows client hosts to subscribe to receive updates; DNS Push is also about to be sent to the IESG.

Tim

---

From: Noah <[email-masked]>
Date: Tue, 4 Jul 2017 18:42:40 +0300

> think the overall idea of this work is more on the direction of “Unique
How about  "Unique IPv6 Prefix Per /End System",   Since a host could have
different interfaces each with a unique Identifier address.

Cheers,
Noah

---

From: Ross Chandler <[email-masked]>
Date: Tue, 4 Jul 2017 18:09:47 +0100

> On 4 Jul 2017, at 16:42, Noah <[email-masked]> wrote:
> 
> 
> How about  “Unique IPv6 Prefix Per /End System",   Since a host could have different interfaces each with a unique Identifier address.

Sticking with the current per-host title is more understandable. I don’t think the draft seeks to preclude more than one unique prefix per end system anyway. 
E.g.  the host may have  multiple network interface types such as WiFi & 3GPP, each connecting to different upstream networks.  

Ross

---

From: Noah <[email-masked]>
Date: Tue, 4 Jul 2017 22:58:42 +0300

On 4 Jul 2017 8:11 p.m., "Ross Chandler" <[email-masked]> wrote:

> How about  “Unique IPv6 Prefix Per /End System",   Since a host could
have different interfaces each with a unique Identifier address.

Sticking with the current per-host title is more understandable. I don’t
think the draft seeks to preclude more than one unique prefix per end
system anyway.

Ok then

E.g.  the host may have  multiple network interface types such as WiFi &
3GPP, each connecting to different upstream networks.

Make sense.

Ross

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Jul 2017 08:17:32 +1200

On 04/07/2017 18:59, Ole Troan wrote:
> If your answer to the discovery problem is that we must put all nodes on the network in the same broadcast domain, we know that doesn't scale well. 

Of course not. I think both DNSSD and ANIMA have got beyond that point.

...
> Since we have to solve the problem for multiple links anyway, does it then make a difference that logical topology follows physical topology and each host is on its own link?

If the discovery traffic is a very small proportion of total traffic, it probably doesn't matter exactly which solution you adopt. But (as Tim implies for DNSSD), I think you should use link-local multicast when it's available. Are we disagreeing?

    Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 4 Jul 2017 22:35:56 +0200

Brian,

> If the discovery traffic is a very small proportion of total traffic, it probably doesn't matter exactly which solution you adopt. But (as Tim implies for DNSSD), I think you should use link-local…

Are you implying there are links where link-local multicast aren't available?
If course on the link type I describe there is ever only two nodes connected. 

If we can't do better than require every link to have a service discovery "helper" then sure link-local multicast is fine ( benefit is well known addresses).

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Jul 2017 08:46:30 +1200

> Are you implying there are links where link-local multicast aren't available?

I'm not aware of any, but do we actually have a standard that makes it mandatory?

> If course on the link type I describe there is ever only two nodes connected. 

Sure, I understood that.
 
> If we can't do better than require every link to have a service discovery "helper" then sure link-local multicast is fine ( benefit is well known addresses).

Yes. I think it's unavoidable. Certainly our intention in ANIMA is that discovery must work on any topology without prior configuration, and that requires every node that has more than one interface to automatically deploy a discovery relay between its interfaces. (And yes, that in turn requires loop prevention.)

  Brian