Subject: Mixing up threats, expecting a single perfect mitigation to all of them

From: Mark Smith <[email-masked]>
Date: Thu, 22 Jun 2017 10:28:19 +1000

You're doing the same thing Tom did. Changing, mixing up and adding
threats, evaluating one specific measure against that set and
declaring it useless because it didn't mitigate all of them.

Again, this is a specific mitigation against a specific technique that
has been used very successfully against IPv4, including by recent
malware that was so successful at propagation and infection that it
made the world wide main stream press ("WannaCry"), and impacted car
factories, hospitals and other significant organisations.

If large IPv6 IID with random values is "security snake oil", it might
be the first "snake oil" ever that is effective against the threat it
is intended to mitigate.

"You can -j REJECT but you can not hide: Global scanning of the IPv6 Internet"
https://lab.dsst.io/slides/33c3/8061.html

"If we cannot scan it, can we observe it?"
https://lab.dsst.io/slides/33c3/slides/8061/10.jpg

*** Just worked to prevent unsolicited packet scanning ***

Another example. Shodan.io have made a business out of selling the
ability to scan the IPv4 address space to discover devices. Did they
try that approach with IPv6? No, they instead collected IPv6 addresses
to probe by adding rogue NTP servers into the pool.ntp.org pools.

https://arstechnica.com/security/2016/02/using-ipv6-with-linux-youve-likely-been-visited-by-shodan-and-other-scanners/

*** Just worked to prevent unsolicited packet scanning ***

Note what I said in my original response,

"So, in this context, if you're relying on not being discovered by
packet probing, it's a single point of failure. However, if you have
other measures in place, such as host based firewalls, authentication
at the IP or higher layers, meaning transport or application layers,
then obscurity adds another level of defence."

I'm not and have never claimed that this is the only measure you need
or that it is perfect at mitigating all threats, so please don't
assert that I am.

Bruce Schneier in his Beyond Fear book describes a number of security
measure categories and principles:

- defence in depth
- compartmentalisation
- prevention
- detection and response
- choke points

Large random IIDs adds a level of depth to defence and is a prevention
mechanism.

He also points out that security is a weakest link problem.

Scanning IPv4 addresses is a weak link that can be very successfully
exploited, as demonstrated by the many have. Large random IIDs in IPv6
strengthens that specific weak link such that people have to go
looking for others - the weak link has been moved, and the new weakest
link is stronger than the previous one.

As a security attack is a return on investment equation, when the ROI
has been reduced by increasing the investment needed, it discourages
the attacker from making the attack attempt.

On 21 June 2017 at 23:54, Nick Hilliard <[email-masked]> wrote:
> Mark Smith wrote:
>> So what I think you're doing here is adding and mixing up threats, and
>> then using those to evaluate the security measure. Once you do that,
>> the measure may be completely ineffective and entirely inappropriate.
>>
>> The specific threat where large IIDs and random addresses is an
>> effective mitigation is device discovery via brute force unsolicited
>> packet probing.
>
> While you quote specific examples of how easy it is to scan the entire
> ipv4 address space, you also omit to mention that scan + connect worm
> behaviour is not how the lion's share of vulnerabilities are spread
> these days, and also you don't mention that a single compromised device
> on an ipv6 network is enough to be able to spread to all other devices
> on the network due to being able to get other local addresses via ipv6
> LL traffic, ND and all that.  There are multiple references to this on
> the web which I'm not going to going to go to the effort of looking up
> right now, but they exist and the problem is real.
>
> You also don't acknowledge that many hosts are dual-stacked and
> compromise via ipv4 is just the same as compromise via ipv6, nor that
> there are plenty of other mechanisms which provide name to address
> mapping (dynamic dns, etc) or address lists (existing neighbor caches).
>
> So when you have:
>
> - single stack, ipv6 only
> - scan + connect worm threat only
> - no host level or network level firewalling
> - all addresses fully randomised on network
> - no other way of guessing addresses
> - no way of trapping LL traffic
>
> ... it is true that large address spaces with truly random addressing
> selection schemes can provide a modicum of security through obscurity.
>
> In pretty much all other situations, long mask lengths with random
> addresses have no impact whatever on security.
>
> Nick

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 22 Jun 2017 01:26:59 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Mark Smith

> Again, this is a specific mitigation against a specific technique
> that has been used very successfully against IPv4, including by
> recent malware that was so successful at propagation and infection
> that it made the world wide main stream press ("WannaCry"), and
> impacted car factories, hospitals and other significant
> organisations.

Yes, and other vulnerabilities would have been and are exploited, if that one didn't exist.

I see the discussion swaying one way, and then the other, and then back again, because there's no document that "tells it like it is." By which I mean, gives both sides of all of the points - for and against a hard 64-bit boundary. Perhaps the current Carpenter et al. draft might be a good vehicle for that, via a hopefully brief additional section.

For example, explain that there are security arguments which favor maintaining an extremely sparsely populated IID in IPv6 networks. Explain how the old criterion of 64-bit IIDs, populated with EUI-64, from RFC 2464, has *morphed into this new criterion* of sparse usage of the lower 64 bits. Explain too that this is useful for SLAAC, when SLAAC uses random IIDs vs EUI-64. Presumably, with EUI-64 IIDs, collisions would be even less likely than they might be with randomly selected IIDs.

Then, mention how this now impacts the supposed vastness of IPv6 address space, reducing it, in essence, from 2^128 to 2^64.

Explain that while there's no technical reason why SLAAC must use 64-bit IIDs, having deprecated EUI-64 as IID, the 64-bit IID requirement for SLAAC remains primarily to mitigate a "race to the bottom." Since SLAAC is seen as perhaps the most popular of plug and play address assignment technique in IPv6, limiting its capability also limits the likelihood of other than /64 subnets existing at all. In other words, educate the reader as to why such SLAAC limitations are retained. Otherwise, the reader might wonder why not allow 48-bit IIDs, or 40-bit IIDs? However, manual techniques can be used, to create networks with longer than /64 prefixes.

Mention how proponents of having /48s assigned to each device believe there is no problem, but then mention how /48s are not common practice currently. And how the vast address space would reduce even more, to something closer to 2^48. Mention how 2^48 could be still be considered vast if applied to people, but perhaps not so vast if applied to "things." (There are many more "things" than people, after all.)

Explain how the current practice of assigning individual /64s, when combined with the desire in some quarters to mandating 64-bit IIDs for all but very few exceptions, makes it difficult to expand networks at the edges. For example, a flat address space becomes mandatory, in any user-friendly expansion at the edges, unless more /64s can be obtained.

In short, tell all. I don't think it takes all that much room, and it would at least explain to the reader why these decisions were made.

Bert

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 Jun 2017 12:37:50 +1000

In message <[email-masked]>, "M
> Yes, and other vulnerabilities would have been and are exploited, if that

Ones that are less effective at discovering vulnerable hosts.
 
> I see the discussion swaying one way, and then the other, and then back
> again, because there's no document that "tells it like it is." By which I
> mean, gives both sides of all of the points - for and against a hard
> 64-bit boundary. Perhaps the current Carpenter et al. draft might be a
> good vehicle for that, via a hopefully brief additional section.
>
> For example, explain that there are security arguments which favor
> maintaining an extremely sparsely populated IID in IPv6 networks. Explain
> how the old criterion of 64-bit IIDs, populated with EUI-64, from RFC
> 2464, has *morphed into this new criterion* of sparse usage of the lower
> 64 bits. Explain too that this is useful for SLAAC, when SLAAC uses
> random IIDs vs EUI-64. Presumably, with EUI-64 IIDs, collisions would be
> even less likely than they might be with randomly selected IIDs.

Only if you intend to re-write history.  From the very beginning
you could take advantage of the sparseness of the /64.  It was a
known property.  EUI-64 was only ever ONE WAY of selecting addresses
and the limitation of that method against pure random addresses
were discussed at the time.

> Then, mention how this now impacts the supposed vastness of IPv6 address
> space, reducing it, in essence, from 2^128 to 2^64.

IPv6 has ALWAYS been 2^128 nodes in 2^64 subnets in 2^48 sites.
There is no reducing going on.  Only continued misunderstandings
on your part.

In IPv4 you have ~2^32 public addresses and a site count that is
asymptoting to that value as more sites reduce down to single
addresses with NAT.

> Explain that while there's no technical reason why SLAAC must use 64-bit
> IIDs, having deprecated EUI-64 as IID, the 64-bit IID requirement for
> SLAAC remains primarily to mitigate a "race to the bottom." Since SLAAC
> is seen as perhaps the most popular of plug and play address assignment
> technique in IPv6, limiting its capability also limits the likelihood of
> other than /64 subnets existing at all. In other words, educate the
> reader as to why such SLAAC limitations are retained. Otherwise, the
> reader might wonder why not allow 48-bit IIDs, or 40-bit IIDs? However,
> manual techniques can be used, to create networks with longer than /64
> prefixes.

There is a technical reason for choosing a single value.  Hosts
need to choose addresses in the absence of RAs.  /64 was choosen
after evaluating a number of different factors.  Even with RAs which
could in theory advertise a different value there are still reasons
to not do this.

> Mention how proponents of having /48s assigned to each device believe
> there is no problem, but then mention how /48s are not common practice
> currently. And how the vast address space would reduce even more, to
> something closer to 2^48. Mention how 2^48 could be still be considered
> vast if applied to people, but perhaps not so vast if applied to
> "things." (There are many more "things" than people, after all.)

No.  It's assign each *site* (or potential site) a /48.  The cell
phones in a site border router.  /48's *are* common practice other
than for cell phones which haven't moved past the stop gap mechanism
of giving each device a /64.

> Explain how the current practice of assigning individual /64s, when
> combined with the desire in some quarters to mandating 64-bit IIDs for
> all but very few exceptions, makes it difficult to expand networks at the
> edges. For example, a flat address space becomes mandatory, in any
> user-friendly expansion at the edges, unless more /64s can be obtained.

Explain how continuing to use stop gap mechanisms (every /64 to a
site has been put in place as stop gap mechanism, this includes
3GPP) is preventing IPv6 from being used as it was designed to be
used.

> In short, tell all. I don't think it takes all that much room, and it
> would at least explain to the reader why these decisions were made.
>
> Bert
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 22 Jun 2017 03:24:00 +0000

-----Original Message-----
From: Mark Andrews [mailto:[email-masked]] 

> From the very beginning you could take advantage of the
> sparseness of the /64.

Well, if the IID is made up of a MAC address and a fixed 16 bits, then that's what you have to use. The sparseness of that IID space is not quite so usable?

> IPv6 has ALWAYS been 2^128 nodes

Can't have it both ways. If the bottom 64 bit space has to be extremely sparsely used, then you have to quit the 2^128 node propaganda. You simply can't say both things at the same time. In effect, you have 2^64 maximum "nodes," with possibly a few more if you use schemes like RFC 7278 or manual configuration.

> In IPv4 you have ~2^32 public addresses and a site count
> that is asymptoting to that value as more sites reduce down
> to single addresses with NAT.

Yes, and IPv6 could do likewise. But perhaps we should also mention, we don't want to use NAT with IPv6. Or sure, we could have a truly gargantuan address space, with /128s and an extra 16 bits with NAT. So I agree. Make sure to include a goal of avoiding NAT, to fix the problem of inadequate flexibility for expansion at the edges.

> There is a technical reason for choosing a single value.
> Hosts need to choose addresses in the absence of RAs.

Can't use SLAAC in the absence of RAs. Can only do link local, in the absence of RAs. Link local is not what I was saying. I'm saying, most readers would wonder why an RFC would claim that fixed 64-bit IIDs are needed for SLAAC, when it's not at all difficult to devise a more flexible SLAAC. So, explain that while SLAAC with 48-bit IIDs, or what the heck even fewer, would still work, we're using this limitation for *ulterior motives*. Nothing wrong with that. Just be up front. By mandating SLAAC with 64-bit IIDs only, user-friendly address configuration will only work for /64s. That's the ulterior motive.

> No.  It's assign each *site* (or potential site) a /48.  The
> cell phones in a site border router.

Not sure what you're saying. My cell phone will get a /48, if I'm on the go? My home router gets a /48? As many have indicated, that's not happening. Not even /56s. So yes, the problem will go away if these things get /48s. But that amounts to assuming the problem away.

> Explain how continuing to use stop gap mechanisms (every /64 to
> a site has been put in place as stop gap mechanism, this
> includes 3GPP) is preventing IPv6 from being used as it was
> designed to be used.

Okay, I'll bite. Let's see a draft that claims that /64 assignments are a "stop gap measure," and then provides a credible mechanism to mandate anything different.

I see people making different unstated assumptions, and then coming to different conclusions based on those unstated assumptions. So, let's get those unsated assumptions stated, clearly, and that will show why different people say different things. As things are now, I keep seeing contradictory statements made.

Bert

---

From: Fred Baker <[email-masked]>
Date: Wed, 21 Jun 2017 22:58:09 -0700

> On Jun 21, 2017, at 8:24 PM, Manfredi, Albert E <[email-masked]> wrote:
> 

BTW, if we know it is a MAC address, and if we know anything about an enterprise network, we can probably guess a small set of OUIs to think about. It changes from probing 2^64 IIDs to probing N*2^24, where N is the number of OUIs found in the network.

Of course, one could pick a random 64 bit number. *could*.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 22 Jun 2017 15:34:02 +0900

On Thu, Jun 22, 2017 at 2:58 PM, Fred Baker <[email-masked]>
wrote:

> > Well, if the IID is made up of a MAC address and a fixed 16 bits, then
> that's what you have to use. The sparseness of that IID space is not quite
> so usable?
>
> BTW, if we know it is a MAC address, and if we know anything about an
> enterprise network, we can probably guess a small set of OUIs to think
> about. It changes from probing 2^64 IIDs to probing N*2^24, where N is the
> number of OUIs found in the network.
>

Which is precisely why addressing schemes that embed stable MAC addresses
are explicitly not recommended in current standards.

---

From: Ole Troan <[email-masked]>
Date: Thu, 22 Jun 2017 12:25:32 +0200

Bert,

> In short, tell all. I don't think it takes all that much room, and it would at least explain to the reader why these decisions were made.

I also think writing up the sets of considerations and pros and cons in a neutral language would be good.
How far would that be from rfc7421 though?

Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 22 Jun 2017 12:35:25 +0200

Please see the scan6 tool from <
https://www.si6networks.com/tools/ipv6toolkit>

It implements an automatic/smary scanner.

Thanks,
Fernando

---

From: Tom Herbert <[email-masked]>
Date: Thu, 22 Jun 2017 08:48:15 -0700

> factories, hospitals and other significant organisations.
WannaCry keeps coming up as the example why address randomization is
needed, so I'll ask the obvious question. If the world was all IPv6
and all IIDs were randomized, what would the effect had been? Would
the attackers have just given up when they saw that scanning wasn't
practical? Would they had just implemented an alternate method of
discovery (maybe just snoop the network for addresses one they
infected one machine)? Would this have completely avoided the attack,
slowed propagation by some X%, or have had no material impact on
success of the attack?

> to probe by adding rogue NTP servers into the pool.ntp.org pools.
So in other words, the attackers didn't give up because scanning was
too hard, they just found a different way to perform discovery.

Tom

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 22 Jun 2017 18:22:43 +0200

> IPv6 has ALWAYS been 2^128 nodes in 2^64 subnets in 2^48 sites.

No.  That's classes again.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 22 Jun 2017 18:48:03 +0200

Le 22/06/2017 à 12:25, Ole Troan a écrit :
> Bert,
> 
>>> Again, this is a specific mitigation against a specific
>>> technique that has been used very successfully against IPv4,
>>> including by recent malware that was so successful at propagation
>>> and infection that it made the world wide main stream press
>>> ("WannaCry"), and impacted car factories, hospitals and other
>>> significant organisations.
>> 
>> I see the discussion swaying one way, and then the other, and then
>> back again, because there's no document that "tells it like it is."
>> By which I mean, gives both sides of all of the points - for and
>> against a hard 64-bit boundary. Perhaps the current Carpenter et
>> al. draft might be a good vehicle for that, via a hopefully brief
>> additional section.
>> 
>> maintaining an extremely sparsely populated IID in IPv6 networks.
>> Explain how the old criterion of 64-bit IIDs, populated with
>> EUI-64, from RFC 2464, has *morphed into this new criterion* of
>> sparse usage of the lower 64 bits. Explain too that this is useful
>> for SLAAC, when SLAAC uses random IIDs vs EUI-64. Presumably, with
>> EUI-64 IIDs, collisions would be even less likely than they might
>> be with randomly selected IIDs.
>> 
>> Then, mention how this now impacts the supposed vastness of IPv6
>> address space, reducing it, in essence, from 2^128 to 2^64.
>> 
>> Explain that while there's no technical reason why SLAAC must use
>> 64-bit IIDs, having deprecated EUI-64 as IID, the 64-bit IID
>> requirement for SLAAC remains primarily to mitigate a "race to the
>> bottom." Since SLAAC is seen as perhaps the most popular of plug
>> and play address assignment technique in IPv6, limiting its
>> capability also limits the likelihood of other than /64 subnets
>> existing at all. In other words, educate the reader as to why such
>> SLAAC limitations are retained. Otherwise, the reader might wonder
>> why not allow 48-bit IIDs, or 40-bit IIDs? However, manual
>> techniques can be used, to create networks with longer than /64
>> prefixes.
>> 
>> Mention how proponents of having /48s assigned to each device
>> believe there is no problem, but then mention how /48s are not
>> common practice currently. And how the vast address space would
>> reduce even more, to something closer to 2^48. Mention how 2^48
>> could be still be considered vast if applied to people, but perhaps
>> not so vast if applied to "things." (There are many more "things"
>> than people, after all.)
>> 
>> combined with the desire in some quarters to mandating 64-bit IIDs
>> for all but very few exceptions, makes it difficult to expand
>> networks at the edges. For example, a flat address space becomes
>> mandatory, in any user-friendly expansion at the edges, unless more
>> /64s can be obtained.
>> 
>> In short, tell all. I don't think it takes all that much room, and
>> it would at least explain to the reader why these decisions were
>> made.
> 
> I also think writing up the sets of considerations and pros and cons
> in a neutral language would be good. How far would that be from
> rfc7421 though?

I think rfc7421 "why64" does not describe this problem of growth at the
edges in the presence of mandatory /64 and SLAAC, whereas it should.

I think rfc7421 does not describe that on-link prefixes are practically
the same thing as subnet prefixes (otherwise addresses are unreachable,
or resolution conflicts may arise).  One wouldnt appreciate a /63 prefix
for onlink determination and a different /64 to form addresses there.

While it talks about shorter IIDs  it does not analyze how good it would
be it the IIDlen were like 72 or so (more entropy; or good with /56
given by DHCPv6-PD rather than Prefix Exclude option, etc).

An analysis of the analysis, performed by an expert neutral, concludes
on the necessity of /64; I completely disagree - I myself didnt mean
that when participating in that effort.  So it would need to be
clarified so that analysis analyzers read as intended by the writers.

The why64 RFC does not tell that RFC4291 has an issue in fe80::/10 vs
fe80::/64.

So yes, I think there could be many things to be clarified along the
lines of rfc7421.

Alex

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

---

From: Simon Hobson <[email-masked]>
Date: Thu, 22 Jun 2017 20:32:14 +0100

> for onlink determination and a different /64 to form addresses there.

Isn't that mostly wrong - and such "imprecise" use of words part of the problem ?
As mentioned earlier, what is a "subnet prefix" ? Is it some imprecise combination of IPv4 terminology and thinking with IPv6 ?

Yes, it took me a long time to get my head around the concept of "on-link" being more or less unrelated to "in the same prefix prefix" (unlike the close coupling between address and subnet in IPv4).
In the example you've given, it is actually quite feasible that the /64 prefix given for forming addresses is not a collection of on-link addresses - while some different /63 prefix does comprise on-link addresses. It would be quite a contrived setup and I'm not sure what technology might arrive at that, but it would be a valid setup from the IPv6 PoV - perhaps some sort of wireless setup where direct client-client communications is not possible/permitted, but direct (on-link) communications between those clients and (say) some backend stuff is permitted.

---

From: "t.petch" <[email-masked]>
Date: Fri, 23 Jun 2017 11:00:11 +0100

----- Original Message -----
From: "Tom Herbert" <[email-masked]>
Sent: Thursday, June 22, 2017 4:48 PM

> > Again, this is a specific mitigation against a specific technique
that
> too hard, they just found a different way to perform discovery.

That is my surmise.  I don't know what the attackers are doing and,
while attackers may well track lists such as these, I doubt that anyone
will post a reply based on sound engineering.

What I do know is of a parallel field, that of bank robberies, where the
history is well understood and it is clear how bank robbers have changed
their approach over time as counter measures were developped.

So that remains my surmise.

Tom Petch

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Jun 2017 17:23:07 +0200

Le 22/06/2017 à 21:32, Simon Hobson a écrit :
>> I think rfc7421 does not describe that on-link prefixes are 
>> practically the same thing as subnet prefixes (otherwise addresses 
>> are unreachable, or resolution conflicts may arise).  One wouldnt 
>> appreciate a /63 prefix for onlink determination and a different 
>> /64 to form addresses there.
> 
> Isn't that mostly wrong - and such "imprecise" use of words part of 
> the problem ? As mentioned earlier, what is a "subnet prefix" ? Is
> it some imprecise combination of IPv4 terminology and thinking with
> IPv6 ?

Agreed, imprecise enough.

This stems from the fact that we dont have a definition of prefixes that
dont involve the word 'subnet'.  The definition that is closest for our
discussion is in draft-jinmei-6man-prefix-clarify-00.  That uses
"on-link prefix" and "SLAAC subnet prefix".

With these terms at hand, all I can say that the on-link prefix has the
same value as the SLAAC subnet prefix, otherwise SLAAC addresses may be
unreachable, or ND resolution conflicts may arise.

> Yes, it took me a long time to get my head around the concept of 
> "on-link" being more or less unrelated to "in the same prefix
> prefix" (unlike the close coupling between address and subnet in
> IPv4). In the example you've given, it is actually quite feasible
> that the /64 prefix given for forming addresses is not a collection
> of on-link addresses - while some different /63 prefix does comprise
> on-link addresses. It would be quite a contrived setup and I'm not
> sure what technology might arrive at that,

I hope no technology arrives at that.

To see why, I would like to propose to think in terms of on-link prefix,
SLAAC subnet prefix, _and_ in terms of form of prefix present in the
routing table; without this 3rd parameter it's hard to ensure
reachability and unique localisation (each address be bidirectionally
reachable, and be present at only one place).  It's also this 3rd
parameter that makes for magic like '64share', connected routes, ND, and
others.

This 3rd parameter is independent of IP version number; it is a
fundamental characteristic.

If we take this 3rd parameter into account then we can see that on-link
prefix and SLAAC subnet prefix can only be the same.

If not, not.  Without considering that 3rd parameter we could build
networks that dont ensure bidirectional reachability and that allow for
ND to break some times.

> but it would be a valid setup from the IPv6 PoV

It's not a valid setup.  It's an error.

It may be something useful in small networks like old IPX or
other-proprietary that are great inside themselves but hard to connect
to Internet.

> - perhaps some sort of wireless setup where direct client-client 
> communications is not possible/permitted, but direct (on-link) 
> communications between those clients and (say) some backend stuff is
>  permitted.

The details of it are not straightforward to me.  But we can discuss and
see what would be the on-link prefix, the SLAAC subnet prefix, and the
form of the prefixes present in the routing tables.

Alex

---

From: Simon Hobson <[email-masked]>
Date: Fri, 23 Jun 2017 18:02:08 +0100

Alexandre Petrescu <[email-masked]> wrote:

>> Isn't that mostly wrong - and such "imprecise" use of words part of the problem ? As mentioned earlier, what is a "subnet prefix" ? Is

>> Yes, it took me a long time to get my head around the concept of "on-link" being more or less unrelated to "in the same prefix
>> - perhaps some sort of wireless setup where direct client-client communications is not possible/permitted, but direct (on-link) communications between those clients and (say) some backend stuff is
>> permitted.
> 

OK, lets suppose that we have some form of yet to be determined network, where client-client direct communication is not possible (or not allowed). That's not uncommon in many public wireless networks where the APs and/or controller can go to some lengths to block such traffic - for the security of users.
But we could have some devices in the network that we do allow the clients to communicate with. OK, it's contrived and could (possibly) be built better with routed segments & prefixes - but lets continue.
So the router advertises a /64 for clients to use for SLAAC but does NOT mark this as on-link. The router also advertises a separate prefix as on-link - the actual prefix length doesn't matter, it could be a /63, but it is a different prefix.

The router itself has a routing table entry for both prefixes directing traffic out of the appropriate interface (same interface for both prefixes).
Client A tries to send a packet to Client B, sees that Client B is not "on-link" and so simply sends the packet to the router - which filters it according to applied policies before either dropping it or forwarding it back out the same interface to reach Client B. When Client B replies, packets again pass via the router.
Client wants to send packet to (say) Printer. It sees that Printer is in a prefix marked as on-link so simply sends the packet and it arrives. Packets from Printer to Client are simply injected into the network and delivered.
This is all predicated on the network hardware filtering traffic between clients. So lets say it's done by the AP - it applies rules which are simply : "If source and destination ports (as determined by reference to the MAC forwarding table) are both radio then drop the packet, else forward according to the table". Similar rules would also need to work back up into the network so as to block traffic between clients on different APs.

Now, lets see what might not work here.

ND. What won't work ? Clients can discover Router. Router can discover Clients. Printer can discover Clients, Clients can discover Printer. Client A can't discover Client B - but then it doesn't need to and (I assume) won't even try as it knows that Client B is not in an on-link prefix.

SLAAC. Now, if we go back to addresses based on MAC address then there's no problem. Each client will form an address in the prefix it's been given and it will be unique (assuming unique MACs, and it's interesting when they aren't).

So the problem now comes down to duplicate address detection when devices use random addresses and the prefix isn't on-link. Has there been any discussion of how this would work when devices are not in an on-link prefix ? Is there a process for the router to do some sort of proxy for DAD - eg when Client A does DAD for it's random address, Router will reply if it knows that the address is in use by Client B ?

Taking this last point, it now occurs to me that if there is no such mechanism, then "public" WiFi has a problem.
It either doesn't do client security - so any client can see all other clients; or it has to run some sort of proxy to make DAD work. At present, I believe (but haven't personally verified) that one make of AP that I work with simply blocks IPv6 altogether with bridge rules to avoid the problem if the admin selects inter-client security.

Now, where's the critical bit I've missed that makes the whole argument fall over !

---

From: Philip Homburg <[email-masked]>
Date: Fri, 23 Jun 2017 19:41:50 +0200

> With these terms at hand, all I can say that the on-link prefix
> has the same value as the SLAAC subnet prefix, otherwise SLAAC
> addresses may be unreachable, or ND resolution conflicts may arise.

You are ignoring the role of the router here.

In the extreme case where the route announces no onlink prefix, all traffic
(initially) goes through the router. So no problem from a routing point
of view. 

For SLAAC you still need DAD. In this case if multiple hosts share a prefix
(which is not a given) the router would have to do some kind of proxy-ND
just for DAD.

---

From: Fred Baker <[email-masked]>
Date: Fri, 23 Jun 2017 13:05:55 -0700

> unreachable, or ND resolution conflicts may arise.

I'd suggest you not ignore routing, or RFC 7608. RFC 7608 says that an IPv6 prefix is a CIDR prefix, which is to say that it has a length, and aggregates of them are stacked like Russian Dolls - one prefix contains another. So when an RIR is given a prefix by the IANA, it is (IIRC), 16 bits long, and from that the RIR delegates prefixes to ISPs of various lengths up to 32, which in turn delegate prefixes to their customers, who in turn deploy them in their networks. BGP, OSPFv3, IS-IS, RIP-II, and other protocols carry CIDR IPv6 prefixes. They have to be considered to be IPv6 prefixes if you're defining the term.

The only use of the term "subnet" in RFC 7608 refers to a prefix applied to a LAN, and is not part of the definition. In RFC 5340 (OSPF for IPv6), section 2.1 is entitled "Protocol Processing Per-Link, Not Per-Subnet", and guess what it says. In RFC 5308 (IS-IS for IPv6), the word subnet does not occur. And for BGP, RFC 2545 only refers to cases in which two routers are interconnected and share a prefix, using language common in 1999 - they "share a subnet". And in RFC 2080, the only usage is in the paragraph

   The distinction between network, subnet and host routes does not need
   to be made for RIPng because an IPv6 address prefix is unambiguous.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 23 Jun 2017 20:41:36 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Fred Baker

> I'd suggest you not ignore routing, or RFC 7608. RFC 7608 says
> that an IPv6 prefix is a CIDR prefix, which is to say that it
> has a length, and aggregates of them are stacked like Russian
> Dolls - one prefix contains another. So when an RIR is given a
> prefix by the IANA, it is (IIRC), 16 bits long, and from that
> the RIR delegates prefixes to ISPs of various lengths up to 32,
> which in turn delegate prefixes to their customers, who in turn
> deploy them in their networks. BGP, OSPFv3, IS-IS, RIP-II, and
> other protocols carry CIDR IPv6 prefixes. They have to be
> considered to be IPv6 prefixes if you're defining the term.

Exactly. And really no different from what we do with IPv4, leaving aside the length in bits, of course. When a customer is allocated a Class C, for instance, he/she may well proceed to create longer prefixes, for "subnets." And hosts might conceivably take that even further. With fewer bits to work with, fewer options than you have with IPv6, perhaps. But same mechanism.

> The only use of the term "subnet" in RFC 7608 refers to a prefix
> applied to a LAN, and is not part of the definition. In RFC 5340
> (OSPF for IPv6), section 2.1 is entitled "Protocol Processing
> Per-Link, Not Per-Subnet", and guess what it says. In RFC 5308
> (IS-IS for IPv6), the word subnet does not occur.

"Subnet," in IPv4, seems to me, has always been sloppily applied. I think the term "on link" could work just as well in IPv4.

I'm either continuing to miss some nuance, or there's really nothing new here, other than an unwillingness to continue to use sloppy terms?

Bert

---

From: Simon Hobson <[email-masked]>
Date: Sat, 24 Jun 2017 11:24:13 +0100

> I'm either continuing to miss some nuance, or there's really nothing new here, other than an unwillingness to continue to use sloppy terms?

I have a feeling that we have become so used to "one 'network' = one subnet (aka prefix)", together with the close binding between "in the same subnet = on-link" with IPv4 - that it's hard to consistently "unlearn" those associations when dealing with IPv6. It's not as if we can just forget about IPv4 as (I assume) most (all ?) of us are still dealing with IPv4 on a daily basis which keeps those associations fresh in our minds.

Thus it needs conscious effort to "think IPv6" - at least it does for me.

---

From: Ole Troan <[email-masked]>
Date: Mon, 26 Jun 2017 12:51:44 +0200

> On 23 Jun 2017, at 19:02, Simon Hobson <[email-masked]> wrote:
> 

DAD as specified in RFC4862 requires that all nodes are on the same shared media and in the same link-local multicast domain.

That is independent of on-link-ness being indicated in the PIO option or not. Two neighbours at the IP level can discover they are on-link in several different ways: (from RFC4861):

on-link     - an address that is assigned to an interface on a
                 specified link.  A node considers an address to be on-
                 link if:

                    - it is covered by one of the link's prefixes (e.g.,
                      as indicated by the on-link flag in the Prefix
                      Information option), or

                    - a neighboring router specifies the address as the
                      target of a Redirect message, or

                    - a Neighbor Advertisement message is received for
                      the (target) address, or

                    - any Neighbor Discovery message is received from
                      the address.

Much of this is designed for link-types that have gone out of fashion. See RFC1620.
Some of the same problems crop up when people try to emulate isolation at L3 on shared L2 domains. See also RFC6957.

Ole

---

From: Mark Smith <[email-masked]>
Date: Mon, 26 Jun 2017 21:28:36 +1000

>                     - any Neighbor Discovery message is received from

I also haven't seen RFC5942, "IPv6 Subnet Model: The Relationship
between Links and Subnet Prefixes" mentioned in these "on-link"
discussions. That RFC may explain what people think is missing.

https://www.rfc-editor.org/rfc/rfc5942.txt

---

From: Dae Young Kim <[email-masked]>
Date: Tue, 27 Jun 2017 10:01:40 +0900

Haven’t been the last two bullets deprecated by RFC 5942?

——
DY

> On 26 Jun 2017, at 7:51 PM, Ole Troan <[email-masked]> wrote:
>

---

From: Ole Troan <[email-masked]>
Date: Tue, 27 Jun 2017 09:23:08 +0200

Dae,

> Haven’t been the last two bullets deprecated by RFC 5942?

Yes, absolutely. Thanks for correcting me!

Ole

---

From: Dae Young Kim <[email-masked]>
Date: Tue, 27 Jun 2017 16:24:25 +0900

Relax.. I’m not wrong…

——
DY

> On 27 Jun 2017, at 4:23 PM, Ole Troan <[email-masked]> wrote:
> 
> Dae,
>