Subject: [v6ops] Peer discovery for unique IPv6 prefixes per host

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 23 Aug 2017 22:00:14 +0000

With RFC7934, we already have BCP recommendations on host address availability
with benefits including privacy addressing, tethering, VM support, etc. Now, with
'draft-ietf-v6ops-unique-ipv6-prefix-per-host', we are seeing operational guidance
on delegating unique IPv6 prefixes to hosts.

With the advent of these recommendations and practices, we see an operational
advantage for hosts to discover the delegated prefixes of neighbors on the link so
that communications can go directly from peer to peer for better performance
and to reduce the load on routers. This becomes especially important when there
are many nodes on the link and/or when the performance in the direct path from
peer-to-peer is substantially better than the performance in the "dogleg" path
from peer-to-router-to-peer.

We would like to invite discussion in this forum as to the operational benefits
and implications of such a capability. This could provide guidance for solution
alternatives that may be taken up in other working groups. Thanks in advance
for your insights.

Fred and James

---

From: Erik Kline <[email-masked]>
Date: Wed, 23 Aug 2017 15:21:36 -0700

> alternatives that may be taken up in other working groups. Thanks in advance

I don't think it's going to prove wise to support a model where
neighbors share the same L2 broadcast domain but each receives
different RAs (to get their unique prefixes).

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 23 Aug 2017 22:45:39 +0000

Hi Erik,

> -----Original Message-----
> From: Erik Kline [mailto:[email-masked]]
> Sent: Wednesday, August 23, 2017 3:22 PM
> To: Templin, Fred L <[email-masked]>
> Cc: [email-masked]; james woodyatt <[email-masked]>
> Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host
> 

Trying to understand your comments. Are you referring to a mechanism
where prefix delegation to individual hosts is coordinated via RAs instead
of via something like DHCPv6 PD? Or, are you referring to unicast RAs
instead of multicast? Or, some combination of the two?

In any event, the operational capability we are referring to is completely
independent of the manner in which prefixes are delegated to hosts,
and works the same way regardless of the mechanisms.

Thanks - Fred

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 24 Aug 2017 09:01:26 +0900

On Thu, Aug 24, 2017 at 7:00 AM, Templin, Fred L <[email-masked]>
wrote:

> and to reduce the load on routers.

I'm not sure that would be generally useful, because:

   1. It only makes sense if router load is a problem. That is unlikely to
   happen in many scenarios, for example the common use case of a wifi network
   that hands out a /64 to every host. In such a deployment, the packets have
   to travel through the AP anyway, and cross-talk is likely to be extremely
   limited compared to Internet-bound traffic. Most network infrastructure is
   actually point-to-point these days.
   2. Allowing cross-talk between devices on the same link raises a number
   of security issues because malicious hosts can mount L2 attacks against
   other hosts on the network - for example, they can attempt to prevent other
   hosts from forming IPv6 addresses by replying to DAD probes, they can send
   rogue RAs, they can forge redirects, etc.

---

From: David Farmer <[email-masked]>
Date: Wed, 23 Aug 2017 20:02:40 -0500

> On Aug 23, 2017, at 19:01, Lorenzo Colitti <[email-masked]> wrote:
> 
>> On Thu, Aug 24, 2017 at 7:00 AM, Templin, Fred L <[email-masked]> wrote:
> It only makes sense if router load is a problem. That is unlikely to happen in many scenarios, for example the common use case of a wifi network that hands out a /64 to every host. In such a deployment, the packets have to travel through the AP anyway, and cross-talk is likely to be extremely limited compared to Internet-bound traffic. Most network infrastructure is actually point-to-point these days.
> Allowing cross-talk between devices on the same link raises a number of security issues because malicious hosts can mount L2 attacks against other hosts on the network - for example, they can attempt to prevent other hosts from forming IPv6 addresses by replying to DAD probes, they can send rogue RAs, they can forge redirects, etc.
Further, one of the primary motivations for this mechanism was to greatly reduced ND traffic on links with lots of hosts, frequently many thousands of hosts. It seems very unlikely you could facilitate this cross-talk communications without ND or a new protocol, supported by hosts, with more or less very similar traffic characteristics as ND, therefore defeating one of the primary purposes for the mechanism in the first place.

If you want hosts on the same link to communicate directly, we already know how to do that, use classic multiple host per prefix subnets. As I said before this mechanism isn't intended as a universal replacement for classic subnets.

David Farmer

---

From: Ole Troan <[email-masked]>
Date: Thu, 24 Aug 2017 10:13:14 +0200

>> 	• It only makes sense if router load is a problem. That is unlikely to happen in many scenarios, for example the common use case of a wifi network that hands out a /64 to every host. In such a deployment, the packets have to travel through the AP anyway, and cross-talk is likely to be extremely limited compared to Internet-bound traffic. Most network infrastructure is actually point-to-point these days.
>> 	• Allowing cross-talk between devices on the same link raises a number of security issues because malicious hosts can mount L2 attacks against other hosts on the network - for example, they can attempt to prevent other hosts from forming IPv6 addresses by replying to DAD probes, they can send rogue RAs, they can forge redirects, etc.

Indeed. The only difference is that host to host now happens at L3 instead of L2.
That hosts are on the same link is typically emulated at L2, we largely stopped building shared media links in the 80s. ;-)
This is just making the L3 topology reflect reality.

Ole

---

From: Simon Hobson <[email-masked]>
Date: Thu, 24 Aug 2017 13:12:37 +0100

> This is just making the L3 topology reflect reality.

You seem to be confusing shared media with broadcast domain. The fact that we now use L2 switching (ie no longer a shared media) doesn't affect the fact that the broadcast domain is now (excepting deliberate filtering) the same. Just switching from shared media (eg 10base2 and 10base5) to switched media (10/100/1000baseT) hasn't moved anything between L2 and L3 - again, absent adding features such as filtering to actively prevent the normal L2-L2 process.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Aug 2017 14:49:05 +0000

Hi Lorenzo,
Ø  1. It only makes sense if router load is a problem.
No, it also makes sense if the performance between peer-to-peer is significantly greater
than from peer-to-router-to-peer. For instance, the router could be located far away from
either peer on very large links.
Ø  That is unlikely to happen in many scenarios, for example the common use case of a wifi network that hands out a /64 to every host. In such a deployment, the packets have to travel through the AP anyway
On very large WiFi deployments, there may be many APs and the router function
may be located on a Wireless LAN controller far away from the APs.
Ø  and cross-talk is likely to be extremely limited compared to Internet-bound traffic. Most network infrastructure is actually point-to-point these days.
I think you are making a generalization based on a limited assumptions of the
types of use cases. Peer-to-peer is going to be useful for use cases such as
enterprise mobile device users, wireless LAN users, aeronautical communications
between aircraft and air traffic controllers, etc. This function is targeted to any
link that can run IPv6 ND, and there are many use cases for large shared links
with many nodes that need to communicate peer-to-peer.

Ø  2. Allowing cross-talk between devices on the same link raises a number of security issues
The security issues are the same as for standard IPv6 ND Redirect. This function is
useful when the Redirect applies to an entire prefix instead of a singleton address.

Ø  because malicious hosts can mount L2 attacks against other hosts on the network - for example, they can attempt to prevent other hosts from forming IPv6 addresses by replying to DAD probes, they can send rogue RAs, they can forge redirects, etc.
You are enumerating issues with IPv6 ND that have nothing to do with this
function. All of the securing concerns you are citing pertain to IPv6 ND on
any link type, and not just those that employ this function.

Thanks - Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Wednesday, August 23, 2017 5:01 PM
To: Templin, Fred L <[email-masked]>
Cc: [email-masked]; james woodyatt <[email-masked]>
Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host

On Thu, Aug 24, 2017 at 7:00 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

  1.  It only makes sense if router load is a problem. That is unlikely to happen in many scenarios, for example the common use case of a wifi network that hands out a /64 to every host. In such a deployment, the packets have to travel through the AP anyway, and cross-talk is likely to be extremely limited compared to Internet-bound traffic. Most network infrastructure is actually point-to-point these days.
  2.  Allowing cross-talk between devices on the same link raises a number of security issues because malicious hosts can mount L2 attacks against other hosts on the network - for example, they can attempt to prevent other hosts from forming IPv6 addresses by replying to DAD probes, they can send rogue RAs, they can forge redirects, etc.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 24 Aug 2017 23:53:35 +0900

On Thu, Aug 24, 2017 at 11:49 PM, Templin, Fred L <[email-masked]

> either peer on very large links.

I didn't say it was impossible, I just said it's unlikely.

> Ø  That is unlikely to happen in many scenarios, for example the common
> use case of a wifi network that hands out a /64 to every host. In such a
> deployment, the packets have to travel through the AP anyway
>

... which are very likely to be connected using fiber links that are much
faster and more reliable than the wifi link itself.

> Ø  because malicious hosts can mount L2 attacks against other hosts on
> the network - for example, they can attempt to prevent other hosts from
> forming IPv6 addresses by replying to DAD probes, they can send rogue RAs,
> they can forge redirects, etc.
>

Actually, they do have a lot to do with this function. One of the major
advantages of assigning a distinct prefix per host is *precisely* the
avoidance of these security issues. You're proposing bringing them back
again.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Aug 2017 14:57:28 +0000

Hi David,

Ø  Further, one of the primary motivations for this mechanism was to greatly reduced ND traffic on links with lots of hosts, frequently many thousands of hosts.

Yes, large links with many hosts – thousands or more. But, it also applies to any
link type and not just huge ones.

Ø  It seems very unlikely you could facilitate this cross-talk communications without ND or a new protocol, supported by hosts, with more or less very similar traffic characteristics as ND, therefore defeating one of the primary purposes for the mechanism in the first place.

Standard ND is assumed as the supporting function, with ND messages carrying prefix
information. It is incrementally-deployable, and adopters will see the benefits while
legacy hosts will continue to operate as they always have.

Ø  If you want hosts on the same link to communicate directly, we already know how to do that, use classic multiple host per prefix subnets. As I said before this mechanism isn't intended as a universal replacement for classic subnets.

RFC7934 and ‘draft-ietf-v6ops-unique-ipv6-prefix-per-host’ are establishing
operational guidelines for hosts to receive their own private prefixes for use
in whatever way they choose. We will want for these hosts to be able to
establish peer-to-peer communications without having to leverage a shared
subnet prefix.

Thanks - Fred

From: David Farmer [mailto:[email-masked]]
Sent: Wednesday, August 23, 2017 6:03 PM
To: Lorenzo Colitti <[email-masked]>
Cc: Templin, Fred L <[email-masked]>; james woodyatt <[email-masked]>; [email-masked]
Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host

On Aug 23, 2017, at 19:01, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

David Farmer

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Aug 2017 15:01:05 +0000

Hi Ole,

> That hosts are on the same link is typically emulated at L2, we largely stopped building shared media links in the 80s. ;-)

Shared media links have not gone away and continue to flourish. We see them
in large VPNs, enterprise networks, aeronautical communications, etc. Even
your 6rd proposal is an example of a large shared link (as is ISATAP, from which
6rd "borrowed" the link model).

Thanks - Fred

> From: v6ops [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: Thursday, August 24, 2017 1:13 AM
> To: David Farmer <[email-masked]>
> Cc: james woodyatt <[email-masked]>; [email-masked]
> >> 	• It only makes sense if router load is a problem. That is unlikely to happen in many scenarios, for example the common use
> case of a wifi network that hands out a /64 to every host. In such a deployment, the packets have to travel through the AP anyway,
> and cross-talk is likely to be extremely limited compared to Internet-bound traffic. Most network infrastructure is actually point-to-
> point these days.
> >> 	• Allowing cross-talk between devices on the same link raises a number of security issues because malicious hosts can mount
> L2 attacks against other hosts on the network - for example, they can attempt to prevent other hosts from forming IPv6 addresses by
> replying to DAD probes, they can send rogue RAs, they can forge redirects, etc.
> > Further, one of the primary motivations for this mechanism was to greatly reduced ND traffic on links with lots of hosts, frequently
> many thousands of hosts. It seems very unlikely you could facilitate this cross-talk communications without ND or a new protocol,
> supported by hosts, with more or less very similar traffic characteristics as ND, therefore defeating one of the primary purposes for
> the mechanism in the first place.
> >
> > If you want hosts on the same link to communicate directly, we already know how to do that, use classic multiple host per prefix
> subnets. As I said before this mechanism isn't intended as a universal replacement for classic subnets.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Aug 2017 15:30:06 +0000

Hi Lorenzo,

Ø  I didn't say it was impossible, I just said it's unlikely.

I think you are taking a too limited viewpoint of the applicable use cases. There
will be many use cases where peer-to-peer performance is much better than
peer-to-router-to-peer.

Ø   which are very likely to be connected using fiber links that are much faster and more reliable than the wifi link itself.

That is true, but it would still go as wifi-to-fiber-to-wifi without having to
go as wifi-to-fiber-to-router-to-fiber-to-wifi. So, it is still an improvement.

Ø  Actually, they do have a lot to do with this function. One of the major advantages of assigning a distinct prefix per host is *precisely* the avoidance of these security issues. You're proposing bringing them back again.

Disagree – this does not introduce new vulnerabilities beyond what is already
in IPv6 ND. And again, I think you may be taking too limited a view on the
types of use cases that this might apply to. This applies to any link type where
peer-to-peer communications are seen as an advantage. It does not have to
be used on links where peer-to-router-to-peer is preferred.

Think of this as an analog of the IPv6 ND Redirect function. It is true that
on many link types Redirects are turned off by default. But, on links where
Redirects are useful then this function will also be useful.

Thanks - Fred

Sent: Thursday, August 24, 2017 7:54 AM

On Thu, Aug 24, 2017 at 11:49 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
No, it also makes sense if the performance between peer-to-peer is significantly greater
than from peer-to-router-to-peer. For instance, the router could be located far away from
either peer on very large links.

>  That is unlikely to happen in many scenarios, for example the common use case of a wifi network that hands out a /64 to every host. In such a deployment, the packets have to travel through the AP anyway

... which are very likely to be connected using fiber links that are much faster and more reliable than the wifi link itself.

>  because malicious hosts can mount L2 attacks against other hosts on the network - for example, they can attempt to prevent other hosts from forming IPv6 addresses by replying to DAD probes, they can send rogue RAs, they can forge redirects, etc.

Actually, they do have a lot to do with this function. One of the major advantages of assigning a distinct prefix per host is *precisely* the avoidance of these security issues. You're proposing bringing them back again.

---

From: David Farmer <[email-masked]>
Date: Thu, 24 Aug 2017 10:49:53 -0500

On Thu, Aug 24, 2017 at 9:57 AM, Templin, Fred L <[email-masked]>
wrote:

> Hi David,
>
>  Ø  If you want hosts on the same link to communicate directly, we
> already know how to do that, use classic multiple host per prefix subnets.
> As I said before this mechanism isn't intended as a universal replacement
> for classic subnets.
>
>
>

RFC7934 simply points out one way to achieve its goals is to assign a
prefix to a host, it is also quite clear that SLAAC on classic subnets
equally meets it's goals, and even DHCPv6 IA_NA, while less preferred, can
meet it's goals in some situations.  Also, per host prefixes are clearly
brought up by RFC7934 in the context of reducing ND traffic.  RFC7934
expresses no preference for host per prefix over classic subnets with
SLAAC, only a preference for host per prefix over classic subnets with
DHCPv6 IA_NA.

Furthermore, the abstract of ‘draft-ietf-v6ops-unique-ipv6-prefix-per-host’
clearly limits the scope of it's applicability. Again prefix per host is
not a universal replacement for classic subnets, and neither RFC7934 or
‘draft-ietf-v6ops-unique-ipv6-prefix-per-host’ even attempts to make it so.

Thanks
-- 
===============================================
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: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Aug 2017 16:04:50 +0000

Hi David,

Ø  RFC7934 simply points out one way to achieve its goals is to assign a prefix to a host, it is also quite clear that SLAAC on classic subnets equally meets it's goals, and even DHCPv6 IA_NA, while less preferred, can meet it's goals in some situations.  Also, per host prefixes are clearly brought up by RFC7934 in the context of reducing ND traffic.  RFC7934 expresses no preference for host per prefix over classic subnets with SLAAC, only a preference for host per prefix over classic subnets with DHCPv6 IA_NA.

This approach does reduce ND messaging. Instead of one Redirect per each singleton IPv6
destination it is one Redirect per delegated prefix. There is no DAD on the link, either, as
the delegated prefixes are not assigned to the link over which they are delegated.

Ø  Furthermore, the abstract of ‘draft-ietf-v6ops-unique-ipv6-prefix-per-host’ clearly limits the scope of it's applicability. Again prefix per host is not a universal replacement for classic subnets, and neither RFC7934 or ‘draft-ietf-v6ops-unique-ipv6-prefix-per-host’ even attempts to make it so.

I read that abstract as applying to any link type. It says:

“Typically hosts (subscribers) on a shared network, either wired or wireless, such as Ethernet, WiFi, etc”

The “etc.” means that this can apply to any link type. There will be a very broad
domain of applicability, but in the end links are links and IPv6 ND applies.

Thanks - Fred

From: David Farmer [mailto:[email-masked]]
Sent: Thursday, August 24, 2017 8:50 AM
To: Templin, Fred L <[email-masked]>
Cc: Lorenzo Colitti <[email-masked]>; james woodyatt <[email-masked]>; [email-masked]
Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host

On Thu, Aug 24, 2017 at 9:57 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi David,

Thanks - Fred

RFC7934 simply points out one way to achieve its goals is to assign a prefix to a host, it is also quite clear that SLAAC on classic subnets equally meets it's goals, and even DHCPv6 IA_NA, while less preferred, can meet it's goals in some situations.  Also, per host prefixes are clearly brought up by RFC7934 in the context of reducing ND traffic.  RFC7934 expresses no preference for host per prefix over classic subnets with SLAAC, only a preference for host per prefix over classic subnets with DHCPv6 IA_NA.

Furthermore, the abstract of ‘draft-ietf-v6ops-unique-ipv6-prefix-per-host’ clearly limits the scope of it's applicability. Again prefix per host is not a universal replacement for classic subnets, and neither RFC7934 or ‘draft-ietf-v6ops-unique-ipv6-prefix-per-host’ even attempts to make it so.

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

---

From: Ole Troan <[email-masked]>
Date: Thu, 24 Aug 2017 21:44:53 +0200

Simon,

> You seem to be confusing shared media with broadcast domain. The fact that we now use L2 switching (ie no longer a shared media) doesn't affect the fact that the broadcast domain is now (excepting…

L2 bridging is just emulating a shared media out of a star topology.
In this model the L3 links follow the physical topology. I.e. routing all the way to the edge. And no need for bridges.

Ole

---

From: Simon Hobson <[email-masked]>
Date: Thu, 24 Aug 2017 21:15:32 +0100

> L2 bridging is just emulating a shared media out of a star topology.

Hmm, an interesting view on things. But in terms of "what can talk to what" there is no difference.

> In this model the L3 links follow the physical topology. I.e. routing all the way to the edge. And no need for bridges.

So are you saying that there is a separate router port per host ?

---

From: Gert Doering <[email-masked]>
Date: Thu, 24 Aug 2017 22:18:20 +0200

Hi,

> So are you saying that there is a separate router port per host ?

On modern switch/router gear, the difference between "a switch port"
and "a router port" is sometimes only a config flag.  No performance
difference, just looking at different parts of the header...

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Simon Hobson <[email-masked]>
Date: Fri, 25 Aug 2017 13:18:38 +0100

> difference, just looking at different parts of the header...

Hmm, I respectfully disagree there as well.
I suspect that some of the people here are mostly familiar with what (to some of us) is "high end" gear - it is clear that most of you work for larger organisations where networking kit is generally "not bargain basement". Down at the bottom end where some of us work (small IT services provider in my case), L3 capabilities are not something we're used to seeing in a switch*. That means there's a disconnect between what different people are talking about when they say "switch".

If you say "switch" to me (in the networking context, I also deal with electrical stuff just to confuse things further) then it means a L2 device - where all ports are in the same broadcast domain, and any device can talk directly to any other device.
Obviously, once get up from the very lowest spec then VLANs come into play, but that doesn't really semantically alter the meaning as long as you consider "all ports in the same VLAN == one logical switch".

But as you say, many switches have L3 functions. When you talk about L3 functions, I'd expect someone to say router - ie use the name of a device which deals with packets at L3.

So could I suggest that people be a little more precise in terminology. If you really mean a L3 device, then don't just use the term "switch" without qualification as that just leads to confusion - as we've seen here.

* To quantify that, right now, I don't think a single switch I am responsible for (either internally or on client sites) has L3 functions in it. I have managed L3 switches (or combined router/switches, or whatever) in the past, but we don't currently have any under management.

---

From: Gert Doering <[email-masked]>
Date: Fri, 25 Aug 2017 14:47:53 +0200

Hi,

> > difference, just looking at different parts of the header...
[..]
> 
> So could I suggest that people be a little more precise in terminology. 

That's exactly why I said "switch/router gear".  Most of these boxes
are not smart enough to be called a "real router", but have sufficient
L3 functionality to do, well, forwarding based on L3 information.

Of course there's pure L2 gear out there, but as soon as you have
routing functionality in the hardware, the distinction "is this a 
switch port or a router interface" is really just a config setting.

Gert Doering
        -- NetMaster