Subject: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Aug 2017 17:37:59 +0000

In section 2, the document says:

   " o  Two devices (subscriber/hosts), both attached to the same provider
      managed shared network should only be able to communicate through
      the provider managed First Hop Router"

Please change to say:

   "o  Two devices (subscriber/hosts), both attached to the same provider
      managed shared network should only be able to communicate through
      the provider managed First Hop Router unless the shared network
      explicitly permits peer-to-peer operations"

Thanks - Fred
[email-masked]

---

From: David Farmer <[email-masked]>
Date: Fri, 25 Aug 2017 09:53:13 -0500

I don't think you can just plop that in there without at least some
revisions to section 4 as well.

Thinking about this a bit, I think you are referring to redirects in
general and your draft 'draft-templin-6man-rio-redirect' more specifically.
In a current unmodified host only individual addresses and not whole
prefixes can be redirected, and therefore the router would have to track
individual addresses to redirect them, which again break the premise of
reducing ND.  Once redirects for whole prefixes are commonly available then
at the discretion of the router you could do as you suggest.

While I like the ideas in 'draft-templin-6man-rio-redirect' they are not
generally implement in the vast majority of hosts today, and therefore
networks implementing 'draft-ietf-v6ops-unique-ipv6-prefix-per-host' can't
reasonably expect the capability to be available, and can only reasonably
expect redirects for individual addresses, and implementing peer-to-peer
communication on that basis is not compatible with the fundamental
expectation in 'draft-ietf-v6ops-unique-ipv6-prefix-per-host'.

Once the capabilities described in 'draft-templin-6man-rio-redirect' are
generally available, I think it would be reasonable to add an option for
peer-to-peer communication to a future revision of
'draft-ietf-v6ops-unique-ipv6-prefix-per-host', but based on the
capabilities available today you can't implement peer-to-peer
communications without violating other fundamental expectations in
draft-ietf-v6ops-unique-ipv6-prefix-per-host'.

Thanks.

On Thu, Aug 24, 2017 at 12:37 PM, Templin, Fred L <[email-masked]
> wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

-- 
===============================================
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: "Templin, Fred L" <[email-masked]>
Date: Fri, 25 Aug 2017 15:19:41 +0000

Hi,

To further qualify this concern, and to bring it to the attention of the
chairs and ADs, this document seems to strongly discourage the use of
direct peer-to-peer communications. But, that would unnecessarily limit
the domain of applicability for links on which the use of Redirects provides
an operational advantage. The text in question and proposed resolutions
are as follows below. Thank you for your attention to this input.

Fred Templin

---

1) In section 2:

Please change to say:

2) In Section 4:

  " If the UE/subscriber
   desires to send anything external including other UE/subscriber
   devices (assuming device to device communications is enabled and
   supported), then, due to the L-bit set, it SHOULD send this traffic
   to the First Hop Provider Router."

Please change to:

    "If the UE/subscriber
   desires to send anything external including other UE/subscriber
   devices (assuming device to device communications is enabled and
   supported), then, due to the L-bit set, it SHOULD send this traffic
   to the First Hop Provider Router unless the shared network
   explicitly permits peer-to-peer operations."

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Thursday, August 24, 2017 10:38 AM
> To: [email-masked]
> Subject: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 25 Aug 2017 15:33:02 +0000

Hi David,

Seeing this now, it appears that your post arrived while I was in the process
of composing my own post. But, to respond to your points:

Ø  I don't think you can just plop that in there without at least some revisions to section 4 as well

You are right – section 4 also needs to say something (see my post).

Ø  Thinking about this a bit, I think you are referring to redirects in general and your draft 'draft-templin-6man-rio-redirect' more specifically.

I am referring to Redirects in general; my draft is based on standard Redirects but simply
asks them to carry a bit more information.

Ø  In a current unmodified host only individual addresses and not whole prefixes can be redirected

True.

Ø  and therefore the router would have to track individual addresses to redirect them, which again break the premise of reducing ND.

Redirects are issued at the discretion of the first-hop router. If Redirects are not appropriate
for the link, or if the first-hop router just plain doesn’t want to send them, then it need not
send them. But, there will be some links (e.g., NBMA) on which Redirects provide a strong
operational advantage.

Ø  Once redirects for whole prefixes are commonly available then at the discretion of the router you could do as you suggest

No, it is about Redirects in general and not just prefix Redirects.

Ø  While I like the ideas in 'draft-templin-6man-rio-redirect' they are not generally implement in the vast majority of hosts today, and therefore networks implementing 'draft-ietf-v6ops-unique-ipv6-prefix-per-host' can't reasonably expect the capability to be available, and can only reasonably expect redirects for individual addresses, and implementing peer-to-peer communication on that basis is not compatible with the fundamental expectation in 'draft-ietf-v6ops-unique-ipv6-prefix-per-host'.

On some links, Redirects for even individual addresses provide a useful optimization
and should not be disallowed. As far as I can tell, this is the only point on which
‘draft-ietf-v6ops-unique-ipv6-prefix-per-host’ unnecessarily limits the domain
of applicability.

Ø  Once the capabilities described in 'draft-templin-6man-rio-redirect' are generally available, I think it would be reasonable to add an option for peer-to-peer communication to a future revision of 'draft-ietf-v6ops-unique-ipv6-prefix-per-host', but based on the capabilities available today you can't implement peer-to-peer communications without violating other fundamental expectations in draft-ietf-v6ops-unique-ipv6-prefix-per-host'.

There is no need to wait for ‘draft-templin-6man-rio-redirect’ if we can get this
right on the first iteration of ‘draft-ietf-v6ops-unique-ipv6-prefix-per-host’. As
you know, BCPs are intended for the long-term and are not easy to update
once they are published.

Thanks - Fred

From: David Farmer [mailto:[email-masked]]
Sent: Friday, August 25, 2017 7:53 AM
To: Templin, Fred L <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'

I don't think you can just plop that in there without at least some revisions to section 4 as well.

Thinking about this a bit, I think you are referring to redirects in general and your draft 'draft-templin-6man-rio-redirect' more specifically. In a current unmodified host only individual addresses and not whole prefixes can be redirected, and therefore the router would have to track individual addresses to redirect them, which again break the premise of reducing ND.  Once redirects for whole prefixes are commonly available then at the discretion of the router you could do as you suggest.

While I like the ideas in 'draft-templin-6man-rio-redirect' they are not generally implement in the vast majority of hosts today, and therefore networks implementing 'draft-ietf-v6ops-unique-ipv6-prefix-per-host' can't reasonably expect the capability to be available, and can only reasonably expect redirects for individual addresses, and implementing peer-to-peer communication on that basis is not compatible with the fundamental expectation in 'draft-ietf-v6ops-unique-ipv6-prefix-per-host'.

Once the capabilities described in 'draft-templin-6man-rio-redirect' are generally available, I think it would be reasonable to add an option for peer-to-peer communication to a future revision of 'draft-ietf-v6ops-unique-ipv6-prefix-per-host', but based on the capabilities available today you can't implement peer-to-peer communications without violating other fundamental expectations in draft-ietf-v6ops-unique-ipv6-prefix-per-host'.

Thanks.

On Thu, Aug 24, 2017 at 12:37 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
In section 2, the document says:

Please change to say:

Thanks - Fred
[email-masked]<mailto:[email-masked]>

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

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

---

From: David Farmer <[email-masked]>
Date: Fri, 25 Aug 2017 15:09:28 -0500

Below;

On Fri, Aug 25, 2017 at 10:19 AM, Templin, Fred L <[email-masked]

>    explicitly permits peer-to-peer operations."

I think you need add a little bit about how peer-to-peer operations would
be explicitly permitted, thought the use of redirects, and that as a
consequence the addresses used buy each host would have to be tracked by
the router for it to send proper redirects to other hosts to enable
peer-to-peer operations
                                .  However, in some cases the trade-off
could be worth the performance increase for direct peer-to-peer
communications, and in others the trade-off will not be worth it.

-- 
===============================================
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: Fri, 25 Aug 2017 20:52:34 +0000

Hi David,

Thanks for your comments – I inserted follow-ups below.

Fred

From: David Farmer [mailto:[email-masked]]
Sent: Friday, August 25, 2017 1:09 PM
To: Templin, Fred L <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'

Below;

On Fri, Aug 25, 2017 at 10:19 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Fred Templin

---

1) In section 2:

Please change to say:

2) In Section 4:

  " If the UE/subscriber

Please change to:

    "If the UE/subscriber

I think you need add a little bit about how peer-to-peer operations would be explicitly permitted, thought the use of redirects, and that as a consequence the addresses used buy each host would have to be tracked by the router for it to send proper redirects to other hosts to enable peer-to-peer operations                                                                                     .  However, in some cases the trade-off could be worth the performance increase for direct peer-to-peer communications, and in others the trade-off will not be worth it.

Ø    Good points, but if anything more should be said I think it should be kept as terse

Ø    as possible. Can you suggest some text? An important thing to note is that the

Ø    Redirect itself does not really give permission – all it does is provides the source

Ø    node with the link-local and link-layer addresses of the target node. If the source

Ø    node has some other way of determining those addresses, it can go peer-to-peer

Ø    without even needing to receive a Redirect. In that case, the only way to prevent

Ø    peer-to-peer is via L2 mechanisms.

> From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Templin, Fred L
> To: [email-masked]<mailto:[email-masked]>

---

From: David Farmer <[email-masked]>
Date: Fri, 25 Aug 2017 22:28:01 -0500

> Ø    peer-to-peer is via L2 mechanisms.
Yes link-local addressing is available for peer-to-peer communication if
allow by the shared network, however redirects are the only mechanism
available for a node to determine the link-layer address associated with an
IPv6 address from within on of the Unique Prefixes as L=0, other than
malicious activity.  If L=0 you are not allowed to use ND to resolve the
link-layer address, and the only other way for a node to learn a link-layer
address associated with an IPv6 address from the Unique Prefix is by a
redirect from a router.

How about something like this;

If the UE/subscriber desires to send anything external including other
UE/subscriber devices (assuming device to device communications is enabled
and supported), then, due to the L-bit set, it SHOULD send this traffic to
the First Hop Provider Router, unless destine to a link-local address or
redirected by the router.

Note: If the shared network permits peer-to-peer operations, direct
UE/subscriber device to device communication will be possible using
link-local addressing across the shared network. Further, if the router
provides redirects, then direct UE/subscriber device to device
communications is also possible using the unique IPv6 prefixes across the
shared network.

I think this addition is important both if you want to enable or disable
direct device to device communications, if you want to enable it this tells
you what you have to do, and if you want to disable it, and the shared
network allows it, you are reminded to disable router redirects and that
you need to do something about link-local. It might be worth adding
something about this to the security considerations too.  For sure it be
worth noting in the security consideration that if the shared network
permits peer-to-peer operations, then malicious direct device to device
communications would be possible even without link-local addressing or
router redirects.

Thanks.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 27 Aug 2017 15:07:29 +0900

>       explicitly permits peer-to-peer operations"

No, *don't* do that. That's a fundamental change to the deployment model
that this document describes, and nullifies many of its advantages.

---

From: David Farmer <[email-masked]>
Date: Sun, 27 Aug 2017 11:39:31 -0500

On Sun, Aug 27, 2017 at 1:07 AM, Lorenzo Colitti <[email-masked]> wrote:

> On Fri, Aug 25, 2017 at 2:37 AM, Templin, Fred L <
> [email-masked]> wrote:
>
I agree, that this should not be changed, as it is an intentional part of
this deployment model.

However, based on this and related discussion, I think something should be
added to the security considerations along the lines of the following;

If the shared network permits peer-to-peer operations, a malicious device
could communicate with other UE/subscriber devices across the shared
network. Additionally, direct UE/subscriber device to device communication
will also be possible across the shared network, without first going
through the First Hop router, using link-local IPv6 addressing or using the
Unique IPv6 Prefixes, if the First Hop router provides redirects for the
Unique IPv6 Prefixes. This can be mitigated with access control lists
limiting link-local IPv6 traffic between UE/subscriber devices to only the
necessary Neighbor Discovery traffic and ensuring that the First Hop router
does not provide any redirects to the UE/subscriber devices. Further, Rogue
Router Advertisements SHOULD be mitigated as discussed in [RFC6104], to
prevent malicious or simply misconfigured devices from impersonating a
router on the shared network.

Thanks

---

From: Mark Smith <[email-masked]>
Date: Mon, 28 Aug 2017 08:34:46 +1000

On 28 August 2017 at 02:39, David Farmer <[email-masked]> wrote:
>> On Fri, Aug 25, 2017 at 2:37 AM, Templin, Fred L
>> <[email-masked]> wrote:
>>>

I'd add *directly*

> could communicate with other UE/subscriber devices *directly* across the shared
> will also be possible across the shared network, without first going through
> the First Hop router, using link-local IPv6 addressing or using the Unique
> IPv6 Prefixes, if the First Hop router provides redirects for the Unique
> IPv6 Prefixes. This can be mitigated with access control lists limiting
> link-local IPv6 traffic between UE/subscriber devices to only the necessary
> Neighbor Discovery traffic and ensuring that the First Hop router does not
> provide any redirects to the UE/subscriber devices. Further, Rogue Router
> Advertisements SHOULD be mitigated as discussed in [RFC6104], to prevent
> malicious or simply misconfigured devices from impersonating a router on the
> shared network.
>

Related, yet earlier,

"2.  Motivation and Scope of Applicability"

Two devices (subscriber/hosts), both attached to the same provider
      managed shared network should only be able to communicate through
      the provider managed First Hop Router"

I'd add a statement to explicitly say that the devices are not trusted
enough to be able to communicate directly between each other:

"Two devices (subscriber/hosts), both attached to the same provider
      managed shared network should only be able to communicate through
      the provider managed First Hop Router. In this scenario, the
subscriber/hosts are not trusted enough to be allowed to directly
communicate with each other over the link."

If hosts aren't trusted, then I wouldn't think Layer 3 ACLs are good
enough to prevent direct inter-host communication. I think it would be
worth stating in the Security Considerations section that direct
inter-host communication across the link should also be prevented at
layer 2, using mechanisms that may be available at layer 2, such as
Private VLANs, TR-101 N:1 VLANs or Wifi Station Isolation.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Aug 2017 11:01:55 +0900

On Mon, Aug 28, 2017 at 1:39 AM, David Farmer <[email-masked]> wrote:

> Unique IPv6 Prefixes.
If we want to say that, we should also add:

This creates a number of security issues such as the ability for hosts on
different prefixes to deny IPv6 service to each other by spoofing DAD
replies, target each other with ND cache exhaustion attacks,
man-in-the-middle traffic by spoofing redirects, and send rogue RAs.

---

From: David Farmer <[email-masked]>
Date: Sun, 27 Aug 2017 21:49:55 -0500

On Sun, Aug 27, 2017 at 9:01 PM, Lorenzo Colitti <[email-masked]> wrote:

>> However, based on this and related discussion, I think something should
>> be added to the security considerations along the lines of the following;
>>

Well, it doesn't explicitly say anything about the shared network
preventing peer-to-peer communications, it might be implied, but it is by
no means explicitly required. So, I think the draft either needs explicitly
require the shared network to prevent peer-to-peer communication, such as
by using Private VLANs, TR-101 N:1 VLANs or Wifi Station Isolation, or it
has to discuss the consequences of the shared network allowing peer-to-peer
communications.

Probably even better, would be to both explicitly recommend the shared
network prevent peer-to-peer communication, such as by using Private VLANs,
TR-101 N:1 VLANs or Wifi Station Isolation, and discuss the consequences of
the shared network allowing peer-to-peer communications, as well as the the
mitigations available short of using Private VLANs, TR-101 N:1 VLANs or
Wifi Station Isolation.

Thanks.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Aug 2017 12:20:32 +0900

On Mon, Aug 28, 2017 at 11:49 AM, David Farmer <[email-masked]> wrote:

> no means explicitly required.
>

At least *some* isolation is required because otherwise the periodic
multicast RAs sent to each host would go to all hosts, and all hosts would
have all the other hosts's prefixes. I agree that this should probably be
stated in the document.

---

From: Mark Smith <[email-masked]>
Date: Mon, 28 Aug 2017 13:53:31 +1000

On 28 Aug. 2017 13:21, "Lorenzo Colitti" <[email-masked]> wrote:

These constrained link-layers allow mcasts and bcasts from the routers to
go to all hosts, it is the host to other nodes direction that is
constrained to just reaching ports where routers are attached.

I would have thought all RAs in this scenario are unicast, including
periodic ones. The list of nodes to unicast to periodically could either be
sent using the neighbour cache or from a table built up using MLDv2 join LL
source addresses. Looking though the draft, there doesn't seem to be any
mention of what happens with periodic mutilcast RAs - are they switched off
(meaning periodic hosts' RSes and unicast RAs keep RA information current),
or unicast instead?

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Aug 2017 15:04:33 +0900

> (meaning periodic hosts' RSes and unicast RAs keep RA information current),

Periodic RAs are required, because a network without periodic RAs is a
network that only works for up to 65536 seconds. There is no standard that
requires hosts to send an RS if some subset of their configuration
information expires. There was opposition even to documenting that hosts
MAY do so.

My understanding is that this document is intended to work on links that
are fully isolated at layer 2 - per-host VLANs, if you will, and that it
uses periodic multicast RAs on each of these links. That is a much more
robust approach than tracking the host's address, because:

   1. The address might change
   2. It is legal to send an RS from the unspecified address
   3. NUD sends a lot of packets and keeps a lot of state. There's no need
   keep that state if you already have L2 isolation and a strong signal from
   L2 that tells you when a host has disconnected. 802.11 happens to be able
   to do both of these things.

I agree that these points are non-obvious to readers, though.

---

From: David Farmer <[email-masked]>
Date: Mon, 28 Aug 2017 01:05:06 -0500

> constrained to just reaching ports where routers are attached.

That's my understanding as well.

> (meaning periodic hosts' RSes and unicast RAs keep RA information current),

Yep that needs to be discussed too.

I'll note in at least most enterprise class WiFi systems it is a fairly
common to include ARP an ND proxies and consume those broadcasts and
multicasts within the AP and not forwarding them.  An answer is then
provided from the AP's cached information, it seems obvious to me to hack
the ND proxy in the AP to provide the desired ND isolation for this
deployment model.

Further, most enterprise class WiFi systems have some kind of proxy for
mDNS and sometimes other service discovery protocols too.  Once more
consuming those broadcasts and multicasts within the AP, providing a
customized answer scoped for the requesting device. Some of the really
fancy systems are even location aware, and scope the responses based on the
devices location.  Again, I can think of some really interesting hacks for
these capabilities to provide the desired isolation in this deployment
model.

Finally, other broadcast and multicast traffic, that is not proxied, is
either simply dropped or emulated by sending it as unicasts to each of the
interested endpoints. Which because multicast and broadcast traffic are
sent at the 802.11 base rate, which can be as low at 1Mb, it is frequently
more efficient to to replicate and send the multicast as multiple unicasts.
Again, I can think of some really interesting hacks for this capability to
provide the desired isolation in this deployment model.

Thanks

---

From: Mark Smith <[email-masked]>
Date: Mon, 28 Aug 2017 16:24:14 +1000

On 28 August 2017 at 16:04, Lorenzo Colitti <[email-masked]> wrote:
>> go to all hosts, it is the host to other nodes direction that is constrained
>> to just reaching ports where routers are attached.
>>
> information expires. There was opposition even to documenting that hosts MAY
> do so.
>

I couldn't remember one, just thought that hosts might issue an RS as
a "last resort" if an RA is going to expire, and that could have been
an alternative to periodic RAs.

Was the objection because RSes are multicast? It' seems there is a
little bit of room in RFC4861 that could allow RSes to be unicast to
an already known router, that would/could solicit a unicast RA
response.

"      Destination Address
                     Typically the all-routers multicast address."

> My understanding is that this document is intended to work on links that are
> fully isolated at layer 2 - per-host VLANs, if you will, and that it uses
> periodic multicast RAs on each of these links. That is a much more robust
> approach than tracking the host's address, because:
>
> The address might change
> It is legal to send an RS from the unspecified address
> NUD sends a lot of packets and keeps a lot of state. There's no need keep
> that state if you already have L2 isolation and a strong signal from L2 that
> tells you when a host has disconnected. 802.11 happens to be able to do both
> of these things.
>

Agree. My thought was the link between the hosts and router was a
single shared one with the "Private VLAN"/Wifi Isolated Station type
constraints we've been discussing in the other thread.

Regards,
Mark.

---

From: David Farmer <[email-masked]>
Date: Mon, 28 Aug 2017 02:05:42 -0500

> information expires. There was opposition even to documenting that hosts

In a WiFi environment that may not be much of an issue, 18 hours is a long
time for most WiFi environments.  Nodes usually go to sleep in a lot less
time then that, and frequently send a RS when they wake up.  And even if
they don't go to sleep there are frequently many other 802.11 layer events
that cause a node to send an RS to ensure to it's sill on the same network
after the event, roaming, forced re-associations, re-authentication timers,
etc...  I'd be seriously shocked to see a WiFi node make it 18 hours
without sending a RS of its own volition for one reason or another. Even if
it did, the WiFi system just has to force a re-associations on any node
attached for more than 18 hours. You must think WiFi is a whole lot more
stable than it really is.

>    3. NUD sends a lot of packets and keeps a lot of state. There's no
>    need keep that state if you already have L2 isolation and a strong signal
>    from L2 that tells you when a host has disconnected. 802.11 happens to be
>    able to do both of these things.
>

I'm not aware of that level of isolation in any of WiFi systems short of
separate VLANs and a host per-vlan, which would limit you to about 4000
hosts, or require multi layer 802.1q tagging and I'm not aware of any WiFi
system doing multiple Q tags. Also, I've never heard of any of the WiFi
system even getting to 4000 usable VLANs, they usually top out at a few
hundred VLANs.  I've talk to most of them about ideas like VLAN per user,
they thought I was NUTS! They pushed me toward Wifi Station Isolation,
which is not the level of isolation your talking about.

If that is truly the intent it needs a lot more discussion, and I don't see
how this could be BCP then, where is the running code?
-- 
===============================================
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: "Templin, Fred L" <[email-masked]>
Date: Mon, 28 Aug 2017 15:38:45 +0000

In thinking about this more, I think the document should say *less* than what
it is currently saying. In particular, in section 2, simply remove the bullet:

   “o  Two devices (subscriber/hosts), both attached to the same provider
      managed shared network should only be able to communicate through
      the provider managed First Hop Router”

and, in Section 4, simply remove the sentence:

   “If the UE/subscriber
   desires to send anything external including other UE/subscriber
   devices (assuming device to device communications is enabled and
   supported), then, due to the L-bit set, it SHOULD send this traffic
   to the First Hop Provider Router.”

The only thing that can prevent two subscriber devices from communicating
directly without going through the first hop router would be L2 mechanisms but
not all networks are going to want to prevent direct communications.

Therefore, leaving these two statements in would unnecessarily restrict the
domain of applicability.

Thanks - Fred

Sent: Friday, August 25, 2017 8:28 PM

On Fri, Aug 25, 2017 at 3:52 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi David,

Fred

>    Good points, but if anything more should be said I think it should be kept as terse

>    as possible. Can you suggest some text? An important thing to note is that the

>    Redirect itself does not really give permission – all it does is provides the source

>    node with the link-local and link-layer addresses of the target node. If the source

>    node has some other way of determining those addresses, it can go peer-to-peer

>    without even needing to receive a Redirect. In that case, the only way to prevent

>    peer-to-peer is via L2 mechanisms.
Yes link-local addressing is available for peer-to-peer communication if allow by the shared network, however redirects are the only mechanism available for a node to determine the link-layer address associated with an IPv6 address from within on of the Unique Prefixes as L=0, other than malicious activity.  If L=0 you are not allowed to use ND to resolve the link-layer address, and the only other way for a node to learn a link-layer address associated with an IPv6 address from the Unique Prefix is by a redirect from a router.

If the UE/subscriber desires to send anything external including other UE/subscriber devices (assuming device to device communications is enabled and supported), then, due to the L-bit set, it SHOULD send this traffic to the First Hop Provider Router, unless destine to a link-local address or redirected by the router.

Note: If the shared network permits peer-to-peer operations, direct UE/subscriber device to device communication will be possible using link-local addressing across the shared network. Further, if the router provides redirects, then direct UE/subscriber device to device communications is also possible using the unique IPv6 prefixes across the shared network.
I think this addition is important both if you want to enable or disable direct device to device communications, if you want to enable it this tells you what you have to do, and if you want to disable it, and the shared network allows it, you are reminded to disable router redirects and that you need to do something about link-local. It might be worth adding something about this to the security considerations too.  For sure it be worth noting in the security consideration that if the shared network permits peer-to-peer operations, then malicious direct device to device communications would be possible even without link-local addressing or router redirects.

Thanks.

---

From: David Farmer <[email-masked]>
Date: Mon, 28 Aug 2017 11:39:42 -0500

As Mark has been talking about in the other thread, if you use an L2
mechanism then you can't ensure you won't duplicated an IID without a ND
proxy along with the L2 mechanism.

So I have to disagree, we seem to have several different interpretations of
the current text, to me that usually means we are missing something
important in the text, and people are filling in with there own
imaginations, and coming to different conclusions.  I think there are
important details that need more discussion in the text, not less, or in
other word I can't support removing text, at least yet.

While I'm skeptical of Lorenzo's description, with more details of how you
put each host in its own VLAN, I could see how what he is talking about
could work.

So, I'd like to here what more about how the authors think this is suppose
to work.

Thanks

On Mon, Aug 28, 2017 at 10:38 AM, Templin, Fred L <[email-masked]

> In thinking about this more, I think the document should say **less**
> than what
>
> *From:* David Farmer [mailto:[email-masked]]
> *Sent:* Friday, August 25, 2017 8:28 PM
> *To:* Templin, Fred L <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-
> prefix-per-host-07'
>
>
>
>
>
>
>
> On Fri, Aug 25, 2017 at 3:52 PM, Templin, Fred L <

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 28 Aug 2017 16:40:17 +0000

Hi,

Ø  My understanding is that this document is intended to work on links that are fully isolated at layer 2 - per-host VLANs, if you will

I don’t see any prescriptions of VLANs and/or any other L2 mechanisms anywhere
in the document, and I think any such considerations are out of scope. These same
mechanisms should be useful on any shared media type (Ethernet, Wifi, NBMA, etc.).

That said, I would not be opposed to security considerations text that discuss the
threats. But, I would not support text that unnecessarily restricts the domain of
applicability.

Thanks - Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Sunday, August 27, 2017 11:05 PM
To: Mark Smith <[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'

On Mon, Aug 28, 2017 at 12:53 PM, Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:
At least *some* isolation is required because otherwise the periodic multicast RAs sent to each host would go to all hosts, and all hosts would have all the other hosts's prefixes. I agree that this should probably be stated in the document.

These constrained link-layers allow mcasts and bcasts from the routers to go to all hosts, it is the host to other nodes direction that is constrained to just reaching ports where routers are attached.

I would have thought all RAs in this scenario are unicast, including periodic ones. The list of nodes to unicast to periodically could either be sent using the neighbour cache or from a table built up using MLDv2 join LL source addresses. Looking though the draft, there doesn't seem to be any mention of what happens with periodic mutilcast RAs - are they switched off (meaning periodic hosts' RSes and unicast RAs keep RA information current), or unicast instead?

Periodic RAs are required, because a network without periodic RAs is a network that only works for up to 65536 seconds. There is no standard that requires hosts to send an RS if some subset of their configuration information expires. There was opposition even to documenting that hosts MAY do so.

My understanding is that this document is intended to work on links that are fully isolated at layer 2 - per-host VLANs, if you will, and that it uses periodic multicast RAs on each of these links. That is a much more robust approach than tracking the host's address, because:

  1.  The address might change
  2.  It is legal to send an RS from the unspecified address
  3.  NUD sends a lot of packets and keeps a lot of state. There's no need keep that state if you already have L2 isolation and a strong signal from L2 that tells you when a host has disconnected. 802.11 happens to be able to do both of these things.
I agree that these points are non-obvious to readers, though.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 28 Aug 2017 16:46:04 +0000

Hi David,

I flipped through the discussion that transpired over the weekend, but the trend
of that discussion seems to be implying more and more restrictions on the domain
of applicability. These mechanisms should be applicable on any link type, and not
just those that employ VLANs or other L2 mitigations. It is no different than
RFC4861 in that regard.

Again,  I would not be opposed to a more detailed discussion in the Security
Considerations section. But, I disagree with text that would unnecessarily
restrict the domain of applicability.

Thanks - Fred

Sent: Monday, August 28, 2017 9:40 AM

As Mark has been talking about in the other thread, if you use an L2 mechanism then you can't ensure you won't duplicated an IID without a ND proxy along with the L2 mechanism.

So I have to disagree, we seem to have several different interpretations of the current text, to me that usually means we are missing something important in the text, and people are filling in with there own imaginations, and coming to different conclusions.  I think there are important details that need more discussion in the text, not less, or in other word I can't support removing text, at least yet.

While I'm skeptical of Lorenzo's description, with more details of how you put each host in its own VLAN, I could see how what he is talking about could work.

So, I'd like to here what more about how the authors think this is suppose to work.

Thanks

On Mon, Aug 28, 2017 at 10:38 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
In thinking about this more, I think the document should say *less* than what
it is currently saying. In particular, in section 2, simply remove the bullet:

   “If the UE/subscriber

Thanks - Fred

From: David Farmer [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, August 25, 2017 8:28 PM
To: Templin, Fred L <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'

Fred

Thanks.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 28 Aug 2017 18:31:05 +0000

Hi, in general I wonder if we should stop and consider what it is we are doing here.
AFAICT, the BCP this document is seeking is to recommend a practice where routers
send unicast RAs with PIOs with A=1 and L=0 with each host receiving a unique PIO.
There are no BCP recommendations for hosts here, because hosts will do what they
have always done according to RFC4861 and RFC4862. For sure, the BCP does not
provide any way for hosts to know that the prefix being offered in the RA is a
unique prefix or a shared prefix. For that, we would need something very much
like the PIO-X draft.

So, I see this being a very simple document that wraps itself around RFC4861.
RFC4861 security considerations also apply (including RFC3756) and this doc
should not be in the business of unnecessarily restricting the domain of
applicability.

Thanks - Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Monday, August 28, 2017 9:46 AM
To: David Farmer <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'

Hi David,

Thanks - Fred

Thanks

   “If the UE/subscriber

Thanks - Fred

Fred

Thanks.

---

From: james woodyatt <[email-masked]>
Date: Tue, 29 Aug 2017 19:13:25 -0700

On Aug 28, 2017, at 09:39, David Farmer <[email-masked]> wrote:
> On Mon, Aug 28, 2017 at 10:38 AM, Templin, Fred L <[email-masked]> wrote:
>> 
>> In thinking about this more, I think the document should say *less* than what it is currently saying. […] The only thing that can prevent two subscriber devices from communicating directly without going through the first hop router would be L2 mechanisms but not all networks are going to want to prevent direct communications.
>> 
>> Therefore, leaving these two statements in would unnecessarily restrict the domain of applicability.
> 

If I-D.ietf-v6ops-unique-ipv6-prefix-per-host is meant as BCP for *only* those networks where layer-2 isolates hosts from direct communication with one another, then it really needs to say so more clearly, to expressly advise practitioners continue using shared prefixes, and *not* to use unique-prefix-per-host, on IPv6 networks where layer-2 does not isolate hosts from direct communication with one another. It doesn’t currently contain a MUST for that.

Until now, it was unclear to me that the authors intend for this BCP not to apply more widely than certain specific networks where this might be of private benefit, which leaves me scratching my head, and asking out loud: why is this an IETF document again?

On the other hand, if the intent is that unique-prefix-per-host MAY be applicable also on networks where layer-2 does not isolate hosts from direct communication with one another, then I think it should go into significantly more detail about how that should be made to work.

In either case, I don’t think the current draft is adequate.

--james woodyatt <[email-masked]>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 31 Aug 2017 00:07:53 +0900

> should not be in the business of unnecessarily restricting the domain of

I think you're entirely missing the goal of this document. It's written
clearly in the applicability statement section that the text applies to
situations where:

   o  Two devices (subscriber/hosts), both attached to the same provider
      managed shared network should only be able to communicate through
      the provider managed First Hop Router

This is an extremely desirable security property in any environment where
trust between devices is limited. In such environments, standard SLAAC on
shared links cannot be made reliable in the presence of buggy or malicious
hosts without brittle hacks that don't scale, and is thus a non-starter
from a an operational point of view unless the devices are tightly
controlled. Thus, there are very solid operational reasons to limit the
scope of applicability to such networks.

If you can convincingly argue that security or reliability would not be
lessened by allowing direct peer-to-peer communication, then sure, the
scope of applicability of this draft can be expanded. I don't think you'll
be able to convincingly argue that. Saying "it's no worse than standard
SLAAC" is not a convincing argument, because standard SLAAC has known
security and reliability issues in this sort of environment.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 31 Aug 2017 00:10:29 +0900

On Wed, Aug 30, 2017 at 11:13 AM, james woodyatt <[email-masked]> wrote:

> If I-D.ietf-v6ops-unique-ipv6-prefix-per-host is meant as BCP for *only*
> those networks where layer-2 isolates hosts from direct communication with
> one another, then it really needs to say so more clearly, to expressly
> advise practitioners continue using shared prefixes, and *not* to use
> unique-prefix-per-host, on IPv6 networks where layer-2 does not isolate
> hosts from direct communication with one another. It doesn’t currently
> contain a MUST for that.
>

Personally I think it says so pretty clearly. The applicability statement
contains the words:

Until now, it was unclear to me that the authors intend for this BCP not to
> apply more widely than certain specific networks where this might be of
> private benefit, which leaves me scratching my head, and asking out loud:
> why is this an IETF document again?
>

I think the scenarios above are actually very common. For example, this is
the only reasonable way I see to deploy a public wifi access point using
SLAAC without artificially limiting the number of addresses that each host
can use.

---

From: Tim Chown <[email-masked]>
Date: Wed, 30 Aug 2017 15:15:26 +0000

> On 30 Aug 2017, at 16:07, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Tue, Aug 29, 2017 at 3:31 AM, Templin, Fred L <[email-masked]> wrote:
> I think you're entirely missing the goal of this document. It's written clearly in the applicability statement section that the text applies to situations where:
> 
> This is an extremely desirable security property in any environment where trust between devices is limited. In such environments, standard SLAAC on shared links cannot be made reliable in the presence of buggy or malicious hosts without brittle hacks that don't scale, and is thus a non-starter from a an operational point of view unless the devices are tightly controlled. Thus, there are very solid operational reasons to limit the scope of applicability to such networks.
> 
> If you can convincingly argue that security or reliability would not be lessened by allowing direct peer-to-peer communication, then sure, the scope of applicability of this draft can be expanded. I don't think you'll be able to convincingly argue that. Saying "it's no worse than standard SLAAC" is not a convincing argument, because standard SLAAC has known security and reliability issues in this sort of environment.

Indeed; the isolation property is one of the key attractions of the draft.

Tim

---

From: David Farmer <[email-masked]>
Date: Wed, 30 Aug 2017 12:51:00 -0500

On Wed, Aug 30, 2017 at 10:15 AM, Tim Chown <[email-masked]> wrote:

> > This is an extremely desirable security property in any environment
> where trust between devices is limited. In such environments, standard
> SLAAC on shared links cannot be made reliable in the presence of buggy or
> malicious hosts without brittle hacks that don't scale, and is thus a
> non-starter from a an operational point of view unless the devices are
> tightly controlled. Thus, there are very solid operational reasons to limit
> the scope of applicability to such networks.
> >

Furthermore, it is this desirable and key security property that justifies
what would otherwise seem to be a wasteful use of number resources. With
the applicability limited to situation where if it was practical for
security reasons, you would have put each host on it own physical interface
and therefore it's subnet anyway, then the there is an argument to be made
that this practice isn't wasteful.  However, if there is no additional
security provided over that of the normal multiple host per subnet model,
then what justifies the use of a 1000 /64s for a 1000 hosts when one prefix
would have easily been sufficient?

Fred, you seem to want to make this generally applicable to almost any
situation. If that the case, then you have to answer the question of what
justifies that level of number resource utilization, if its not the
security advantage of separating hosts.

One of the reasons we justify /64 subnets in the first place, is to ensure
there is no practical limit, based on addressing, to how many hosts you put
in a subnet.  There is a limit, but it has nothing to do with the IPv6
addressing architecture. Security architecture is one of the limits on how
many and what hosts you put in any particular subnet.

So, I will repeat myself;  The subnet per host model is not a generalized
or universal replacement for the multiple host per subnet model.

And I will add to that; The subnet per host model is only justified by the
desirable and key security property of host separation provided in the
scope of applicability.

That said, the details of how this security property of host separation is
intended to be implemented needs a better description in the draft, and the
consequences of not or only partly implementing it needs to be discussed in
the security considerations.

Thanks.

---

From: james woodyatt <[email-masked]>
Date: Wed, 30 Aug 2017 13:57:04 -0700

On Aug 30, 2017, at 10:51, David Farmer <[email-masked]> wrote:
> 
> […] And I will add to that; The subnet per host model is only justified by the desirable and key security property of host separation provided in the scope of applicability. 
> 
> That said, the details of how this security property of host separation is intended to be implemented needs a better description in the draft, and the consequences of not or only partly implementing it needs to be discussed in the security considerations.

Then I’m in agreement. Please add appropriate language in section 5 to make clear that this draft documents a Best Current Practice for use ONLY in networks where individual UE/subscriber hosts are isolated at layer-2 and IPv6 Neighbor Discovery is blocked between them. Please also add further additional language in the Security Consideration section that details the risks and hazards of failing to do so.

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 30 Aug 2017 21:22:27 +0000

Hi, again this document is nothing more than an expression of what is already
in RFC4861, but then it adds constraints that don’t need to be there. If the
PIO has A=1, L=0 then by RFC4861 the host will autoconfigure one or more
addresses and send packets via the default router (since ‘L’ is 0) unless
there is a more-specific route.

But, the router may send a Redirect and therefore subsequent packets could
go from peer-to-peer without having to go through the router. This document
should not be in the business of disabling or disallowing the Redirect function,
which is a core element of IPv6 ND and necessary for some link types.

Thanks - Fred

From: v6ops [mailto:[email-masked]] On Behalf Of David Farmer
Sent: Wednesday, August 30, 2017 10:51 AM
To: Tim Chown <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'

On Wed, Aug 30, 2017 at 10:15 AM, Tim Chown <[email-masked]<mailto:[email-masked]>> wrote:
> On 30 Aug 2017, at 16:07, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
>
> On Tue, Aug 29, 2017 at 3:31 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Furthermore, it is this desirable and key security property that justifies what would otherwise seem to be a wasteful use of number resources. With the applicability limited to situation where if it was practical for security reasons, you would have put each host on it own physical interface and therefore it's subnet anyway, then the there is an argument to be made that this practice isn't wasteful.  However, if there is no additional security provided over that of the normal multiple host per subnet model, then what justifies the use of a 1000 /64s for a 1000 hosts when one prefix would have easily been sufficient?

Fred, you seem to want to make this generally applicable to almost any situation. If that the case, then you have to answer the question of what justifies that level of number resource utilization, if its not the security advantage of separating hosts.

One of the reasons we justify /64 subnets in the first place, is to ensure there is no practical limit, based on addressing, to how many hosts you put in a subnet.  There is a limit, but it has nothing to do with the IPv6 addressing architecture. Security architecture is one of the limits on how many and what hosts you put in any particular subnet.

So, I will repeat myself;  The subnet per host model is not a generalized or universal replacement for the multiple host per subnet model.

And I will add to that; The subnet per host model is only justified by the desirable and key security property of host separation provided in the scope of applicability.

Thanks.

---

From: David Farmer <[email-masked]>
Date: Wed, 30 Aug 2017 17:04:43 -0500

> which is a core element of IPv6 ND and necessary for some link types.

And you can do just that with one /64 subnet for how many every hosts you
want too on the same subnet.

However, if you have 1000 hosts all on the same link, and there is subnet
prefix per host, what prevents all 1000 hosts from forming SLAAC addresses
on each of the prefixes? Something has to prevent Host1 from knowing about
the prefixes for the other 999 hosts. Otherwise per RFC4861, Host1 would
form an address on those other 999 prefixes as well.  This implies some
kind of separation of the hosts is already required if a host is going to
use only it's prefix.

And if that separation is only applied to the RAs, and the hosts can
communicate directly with each other over the shared network then what is
the advantage of doing that over 1 subnet for the 1000 hosts? You are
making thinks more complicate without any seeming advantage. Now if the
hosts can't communicate with each other then there is an advantage provided
by segregating the RAs for the other 999 prefixes from Host1.

Therefore some level of host segregation is a fundamental property of this
whole technique, and it makes no sense to limit it per host advertisement
of RAs.

Thanks

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Aug 2017 11:16:20 +1200

On 31/08/2017 10:04, David Farmer wrote:
...
> on each of the prefixes?

If there are any multicast RA/PIOs for these prefixes, they should have
A=0; L=0 (cf RFC8028).

But I'm not sure why there would be any multicast RAs. They don't
seem to be needed. The draft talks about unicast RAs.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 31 Aug 2017 09:11:12 +0900

> seem to be needed. The draft talks about unicast RAs.

Unicast RAs would require the router to keep state on all its clients
regardless of its IP addresses and across IP address changes. That doesn't
scale. It's much better for the router to send a multicast RA on each
separate L2 link, knowing that it will go only to the host on that link
that has that prefix.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Aug 2017 13:15:17 +1200

> separate L2 link, knowing that it will go only to the host on that link

Yes, certainly, if there are genuinely separate L2 links. But what if there
is in reality a shared L2 link?

In any case the draft doen't even contain the word "multicast".

    Brian

---

From: David Farmer <[email-masked]>
Date: Thu, 31 Aug 2017 03:13:11 -0500

On Aug 30, 2017, at 19:11, Lorenzo Colitti <[email-masked]> wrote:

As I've said I'm not aware of any WiFi systems providing a full
bi-directional VLAN per host isolation, or in other words, each host get
its own VLAN interface on the router side. This seems to be what
Lorenzo is talking
about. However, I wouldn't be quite pleasantly surprised to be proven wrong
about that though.

The solutions I'm aware of provide isolation only on the host side, not the
router side, similar to private VLANs on Ethernet switches, or in other
words, all the hosts share a common VLAN interface on the router side, but
are isolated from each other.

https://en.m.wikipedia.org/wiki/Private_VLAN

In any case the router has to maintain an association of host MAC addresses
and unique prefixes for next-hop delivery of packets destine to each unique
prefix. When the router assigns a unique prefix to a host in response to
the host's initial RS, it will have to populate this.

RAs can also be formed from the information in this table. As Lorenzo said
the router should send RAs, with a PIO for the unique prefix of each host
with A=1, L=0, in response to an RS or for periodic RAs, destine to the
all-hosts multicast address in the IPv6 header, so it doesn't have to track
all the IIDs associated with each host. However, it should not use the
associated
multicast MAC address as the L2 destination but the unicast MAC address of
the host assigned the unique prefix. As I said the router has to maintain
RA isolation per host, this is fundamental to this technique. If this is
done then it doesn't matter if each host has it own VLAN interface on the
router side or if the hosts share a common VLAN interface on the router
side.

Whether the return traffic is isolated, or not, is not up to the router,
it's up to the WiFi system or Ethernet switch. But if it's not isolated the
router has gone to the effort of isolating the RA for little reason, other
than to waste a bunch of prefixes for no benefit that makes any sense to
me. If you want the hosts to talk to each other directly this is far more
efficiently done with the classic multi host per subnet model.

It might also be useful to advertise a PIO for the aggregate prefix the
router uses to assign the unique prefixes from, or even the providers
aggregate prefix, with A=0, L=0, to the all-hosts multicast address in the
IPv6 header and the MAC header, to ensure hosts compliment with RFC8028, that
may have other interfaces, would prefer routing of these prefixes to the
provider first hop router instead of out their other interface.

If the technique above is used and isolation is provided on the host side,
a host could form a duplicate Link-local address with another isolated
host, and it wouldn't cause an issue, as the router is not using or
tracking the link-local neighbors.  This also requires a modification of
the routers response to NS queries from hosts it must use the source IPv6
address and source MAC address from the NS as the destination IPv6 address
and destination MAC address of the NA without tracking them, as different
host could have the same source IPv6 address. The router needs to and
should be able to defend its link-local address against each of isolated
hosts so that the one of the hosts doesn't form a duplicate of the router's
link-local address, as this would cause issues. In this case I would
consider each host to be on a separate link, the router on each of these
links has the same link-local address.

If isolation at least on the host side is not provided by L2 then the
router and all the hosts are on a common link, link-local addresses will
work normally and malicious hosts could man-in-the-middle any traffic from
any of the hosts on the network.

If the Wifi system provides an ND proxy, fairly common at least in
enterprise class WiFi systems, or if a separate ND proxy is provided on a
separate promiscuous mode port like the router has, it sees and can send
traffic to all hosts, the ND proxy could defend each of host's link-local
address from the other isolated hosts preventing any possibility of a
duplicate link-local address among the hosts, and allowing the router to
track link-local addresses and utilize its standard NS and NA processes,
only requiring modification of the RA process.

There is a trade-off here though, if the router could track the hosts'
link-local addresses it could use it's normal and presumably well debugged
code paths for NS and NA and many of the normal tools on the router at
least those that utilize link-local addressing.  Or, it can use custom code
for NS and NA probably breaking all tools on the router, even those that
could use link-local addressing, for the advantage of not having to track
each of the hosts link-local addresses.  There are benefits and costs with
both options, in my opinion it's mostly a tie.  It probably boils down to
how many hosts does the environment really need to scale too, verses how
adaptable the staff that has to operate and troubleshoot the environment is.

Here at UMN, if we can eliminate the tracking of each hosts multiple GUA
addresses by the routers, that's probably a big enough win by itself that
I'd probably opt to keep the tracking of link-local addresses normal,
keeping as many tools on the router as normal as I could.

Thanks

---

From: Ole Troan <[email-masked]>
Date: Thu, 31 Aug 2017 11:46:49 +0200

> On 31 Aug 2017, at 10:13, David Farmer <[email-masked]> wrote:
> 
> 
>> On Thu, Aug 31, 2017 at 8:16 AM, Brian E Carpenter <[email-masked]> wrote:
>> Unicast RAs would require the router to keep state on all its clients regardless of its IP addresses and across IP address changes. That doesn't scale. It's much better for the router to send a multicast RA on each separate L2 link, knowing that it will go only to the host on that link that has that prefix.
> As I've said I'm not aware of any WiFi systems providing a full bi-directional VLAN per host isolation, or in other words, each host get its own VLAN interface on the router side. This seems to be what Lorenzo is talking about. However, I wouldn't be quite pleasantly surprised to be proven wrong about that though.
> 
> The solutions I'm aware of provide isolation only on the host side, not the router side, similar to private VLANs on Ethernet switches, or in other words, all the hosts share a common VLAN interface on the router side, but are isolated from each other.
> 
> In any case the router has to maintain an association of host MAC addresses and unique prefixes for next-hop delivery of packets destine to each unique prefix. When the router assigns a unique prefix to a host in response to the host's initial RS, it will have to populate this.
> 
> RAs can also be formed from the information in this table. As Lorenzo said the router should send RAs, with a PIO for the unique prefix of each host with A=1, L=0, in response to an RS or for periodic RAs, destine to the all-hosts multicast address in the IPv6 header, so it doesn't have to track all the IIDs associated with each host. However, it should not use the associated multicast MAC address as the L2 destination but the unicast MAC address of the host assigned the unique prefix. As I said the router has to maintain RA isolation per host, this is fundamental to this technique. If this is done then it doesn't matter if each host has it own VLAN interface on the router side or if the hosts share a common VLAN interface on the router side.
> 
> Whether the return traffic is isolated, or not, is not up to the router, it's up to the WiFi system or Ethernet switch. But if it's not isolated the router has gone to the effort of isolating the RA for little reason, other than to waste a bunch of prefixes for no benefit that makes any sense to me. If you want the hosts to talk to each other directly this is far more efficiently done with the classic multi host per subnet model.
> 
> It might also be useful to advertise a PIO for the aggregate prefix the router uses to assign the unique prefixes from, or even the providers aggregate prefix, with A=0, L=0, to the all-hosts multicast address in the IPv6 header and the MAC header, to ensure hosts compliment with RFC8028, that may have other interfaces, would prefer routing of these prefixes to the provider first hop router instead of out their other interface.
> 
> If the technique above is used and isolation is provided on the host side, a host could form a duplicate Link-local address with another isolated host, and it wouldn't cause an issue, as the router is not using or tracking the link-local neighbors.  This also requires a modification of the routers response to NS queries from hosts it must use the source IPv6 address and source MAC address from the NS as the destination IPv6 address and destination MAC address of the NA without tracking them, as different host could have the same source IPv6 address. The router needs to and should be able to defend its link-local address against each of isolated hosts so that the one of the hosts doesn't form a duplicate of the router's link-local address, as this would cause issues. In this case I would consider each host to be on a separate link, the router on each of these links has the same link-local address.
> 
> If isolation at least on the host side is not provided by L2 then the router and all the hosts are on a common link, link-local addresses will work normally and malicious hosts could man-in-the-middle any traffic from any of the hosts on the network.
> 
> If the Wifi system provides an ND proxy, fairly common at least in enterprise class WiFi systems, or if a separate ND proxy is provided on a separate promiscuous mode port like the router has, it sees and can send traffic to all hosts, the ND proxy could defend each of host's link-local address from the other isolated hosts preventing any possibility of a duplicate link-local address among the hosts, and allowing the router to track link-local addresses and utilize its standard NS and NA processes, only requiring modification of the RA process.
> 
> There is a trade-off here though, if the router could track the hosts' link-local addresses it could use it's normal and presumably well debugged code paths for NS and NA and many of the normal tools on the router at least those that utilize link-local addressing.  Or, it can use custom code for NS and NA probably breaking all tools on the router, even those that could use link-local addressing, for the advantage of not having to track each of the hosts link-local addresses.  There are benefits and costs with both options, in my opinion it's mostly a tie.  It probably boils down to how many hosts does the environment really need to scale too, verses how adaptable the staff that has to operate and troubleshoot the environment is.

This can be implemented without any changes to ND code.
We have done that as part of the VPP project: https://gerrit.fd.io/r/#/c/7224/
Since you no longer need to do address resolution and maintain the ND cache, this scales well and is much more resilient against attack than the ND cache. You only need to keep long lived "per subscriber" state in the router.

Ole

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 31 Aug 2017 12:34:12 +0000

https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-07

“This

   RA contains two important parameters for the EU/subscriber to

   consume: a Unique IPv6 prefix (currently a /64 prefix) and some

   flags.  The Unique IPv6 prefix can be derived from a locally managed

   pool or aggregate IPv6 block assigned to the First Hop Provider

   Router or from a centrally allocated pool.

 “
If the router is able to assign a unique prefix from a prefix pool, it should be able to assign a unique address from an address pool. There is no need for DAD with unique addresses. If there is no prefix assigned:

“   o  Two devices (subscriber/hosts), both attached to the same provider

      the provider managed First Hop Router“

The security control is achieved without assigning /64 subnet to a host.

Dusan

From: v6ops [mailto:[email-masked]] On Behalf Of David Farmer
Sent: Wednesday, August 30, 2017 1:51 PM
To: Tim Chown
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'

Thanks.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 31 Aug 2017 15:18:04 +0000

Hi,

The simple point in all of this is that Redirects are (and will remain) a
useful component of IPv6 ND, yet this document seems to deprecate
their use in all cases even for links where use of Redirects is essential.

The sending or not sending of Redirects is up to the router and, on
links where Redirects are not desired, the router simply refrains from
sending them. This is no different than what has been documented
in RFC4861 and its predecessors (RFC1970, RFC2461) since the earliest
days of IPv6.

Thanks - Fred

From: David Farmer [mailto:[email-masked]]
Sent: Wednesday, August 30, 2017 3:05 PM
To: Templin, Fred L <[email-masked]>
Cc: Tim Chown <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'

On Wed, Aug 30, 2017 at 4:22 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Thanks - Fred

And you can do just that with one /64 subnet for how many every hosts you want too on the same subnet.

However, if you have 1000 hosts all on the same link, and there is subnet prefix per host, what prevents all 1000 hosts from forming SLAAC addresses on each of the prefixes? Something has to prevent Host1 from knowing about the prefixes for the other 999 hosts. Otherwise per RFC4861, Host1 would form an address on those other 999 prefixes as well.  This implies some kind of separation of the hosts is already required if a host is going to use only it's prefix.

And if that separation is only applied to the RAs, and the hosts can communicate directly with each other over the shared network then what is the advantage of doing that over 1 subnet for the 1000 hosts? You are making thinks more complicate without any seeming advantage. Now if the hosts can't communicate with each other then there is an advantage provided by segregating the RAs for the other 999 prefixes from Host1.

Therefore some level of host segregation is a fundamental property of this whole technique, and it makes no sense to limit it per host advertisement of RAs.

Thanks

---

From: David Farmer <[email-masked]>
Date: Thu, 31 Aug 2017 11:49:47 -0500

You are talking about redirects as if they are a universal good, and yes
they are necessary in some situations, but they also have security
considerations. You claim the draft is ignoring the potential usefulness of
redirects in some environments and yes it is.  However, you are ignoring
the potential additional security that not having redirects has in other
environments.

Further, you have not discussed any advantages that the use of prefix per
host subnets model has over the classic multiple hosts per subnet model in
an insecure environment to justify the increased use of number resources by
prefix per host subnets model. Please explain some of the use cases you
think their are and why the prefix per host subnets model with redirects
has any kind of advantage over the classic multiple hosts per subnet model.

Thanks.

On Thu, Aug 31, 2017 at 10:18 AM, Templin, Fred L <[email-masked]

> *Sent:* Wednesday, August 30, 2017 3:05 PM
> *Cc:* Tim Chown <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> On Wed, Aug 30, 2017 at 4:22 PM, Templin, Fred L <

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 31 Aug 2017 17:18:19 +0000

Hi David – see below for follow-ups.

Thanks - Fred

Sent: Thursday, August 31, 2017 9:50 AM

You are talking about redirects as if they are a universal good, and yes they are necessary in some situations, but they also have security considerations. You claim the draft is ignoring the potential usefulness of redirects in some environments and yes it is.  However, you are ignoring the potential additional security that not having redirects has in other environments.

Ø    I never said Redirects are a universal good, as that would be far from the truth. I said

Ø    that on some links use of Redirects is “essential”, but what I meant to say is that

Ø    Redirects can provide a useful optimization. Routers don’t need to send Redirects

Ø    and hosts don’t need to listen to them, but on some link types (e.g., NBMA) their

Ø    use can improve performance for both the individual peers and the link as a whole.

Ø

Ø    About security, all of IPv6 ND has security considerations (RFC3756, RFC4861). So much

Ø    so that Secure Neighbor Discovery was standardized (RFC3971). True that RFC3971 is

Ø    not widely used/deployed, but the fact is that Neighbor Discovery Trust Models and

Ø    Threats need to be considered for each link type for all ND message types – not

Ø    just Redirects.

Further, you have not discussed any advantages that the use of prefix per host subnets model has over the classic multiple hosts per subnet model in an insecure environment to justify the increased use of number resources by prefix per host subnets model. Please explain some of the use cases you think their are and why the prefix per host subnets model with redirects has any kind of advantage over the classic multiple hosts per subnet model.

Ø    I have already said many times that Redirects are useful to allow peer-to-peer

Ø    communications instead of peer-to-router-to-peer. Call it a route optimization

Ø    or a neighbor discovery function – your choice. There may be benefits or

Ø    drawbacks to peer-to-peer depending on the use case – but there will be

Ø   use cases where there are benefits.

Thanks.

On Thu, Aug 31, 2017 at 10:18 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thanks - Fred

Cc: Tim Chown <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Thanks - Fred

Thanks

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Sep 2017 11:23:14 +1200

> separate L2 link, knowing that it will go only to the host on that link

Nevertheless,
(a) the draft says unicast.
(b) hypothetically there *is* no separate L2 link for multicast; there is just a
logical separation for unicast purposes. That seems to be what Ole described.

    Brian