Subject: Re: SLAAC on non-/64 networks

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 9 Apr 2018 16:41:01 +0200

Anybody works on this for linux now?

Alex

Le 18/03/2018 à 19:09, Peter Hessler a écrit :
> On 2018 Mar 18 (Sun) at 18:58:11 +0100 (+0100), Alexandre Petrescu wrote:
> :
> :
> :Le 18/03/2018 à 18:36, Peter Hessler a écrit :
> :> On 2018 Mar 18 (Sun) at 17:08:16 +0100 (+0100), Alexandre Petrescu wrote:
> :> :I wanted to ask you: does this removal mean that now the system no longer
> :> :complains when receiving an RA with plen 65?
> :> :
> :>
> :> Yes, exactly.  Example from a VM on my laptop:
> :>
> :>   inet6 2001:67c:12f4:2500:112::d322 prefixlen 112 autoconf
> :
> :Is d322 formed according to RFC7217?
> :
> :> :What else does this removal mean, in practice?
> :> :
> :>
> :> It also means a shorter prefix length will be completely filled with
> :> random data, instead of only the finaly 64-bits of the address.
> :>
> :>   inet6 2001:67c:12f4:5681:1273:8150:90bd:22ed prefixlen 56 autoconf
> :
> :Is f4:5681:1273:8150:90bd:22ed formed according to RFC7217?
> :
> 
> For both: yes.  The RID is generated, then the least-significant
> 128-bits are taken and folded into the prefix masked with the prefixlen.
> 
> These addresses are stable, and reproducable.
> 
> -peter
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Mark Smith <[email-masked]>
Date: Tue, 10 Apr 2018 06:59:45 +1000

On Sat., 24 Mar. 2018, 20:35 Lee Howard, <[email-masked]> wrote:

>
>
> On 03/24/2018 07:39 AM, DaeYoung KIM wrote:
>
> On 24 Mar 2018, at 16:03, Mikael Abrahamsson <[email-masked]> <[email-masked]> wrote:
>
> We're already telling them to hand out /56:es, but that seems to be working so-so. Right?
>
> Where’s the document to strongly recommend or mandate that they SHOULD or MUST hand out /56:es?
>
> With the one for /64, I mean a strong recommendation or mandating as SHOULD or MUST.
>
> If ISPs still don’t comply, it’d only mean that IETF has simply lost its authority as an SDO.
>
>
> The only authority the IETF has is in ensuring interoperability.
>
> The only appropriate use for MUST is "If you don't do this, your stuff
> won't work with others' stuff."
>
> RFC2119 "Key words for use in RFCs to Indicate Requirements Levels"
> Section 6 Guidance in the use of these Imperatives:
>
> Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions)  *For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.*
>
>
> (emphasis mine)
>
> I don't think the case has been successfully made that IPv6 (or higher
> protocols) fails to interoperate with the 64 bit boundary.
>

TL;DR. removing the /64 boundary, and making it arbitrary, contradicts
BCP188 - "Pervasive Monitoring Is an Attack".

Where the difference is between IPv4 and IPv6 is in terms of addressing
security and privacy.

In my experience, at a number of corporate and residential ISPs, privacy
and security properties of addresses have not been a consideration in IPv4
because they couldn't be - there just weren't enough address bits for it to
be possible. It has been all about providing customers with as many
addresses as they needed, while also considering the scarcity of IPv4
addresses.

We might not know how many bits are the minimum are required for addressing
privacy and security. However, I think we do know that more bits is always
going to be better.

Today, with the /64 boundary, ISPs still don't specifically need to think
of customer address privacy and security - it is inherent in the size of
/64. Remove that boundary, and it won't suddenly be considered, and I
expect will be lost. I think ISP would be likely to inadvertently sacrifice
customer addressing privacy and security to retain IPv4 addressing methods
and practices because of their much more than a decade of familiarity with
them.

So /64 might not be a "MUST" or even a "SHOULD" to give the ability to a
host to have its own globally unique address to send IPv6 packets with.
However, from an address security and privacy perspective, probably not a
MUST, but I would certainly say a strong SHOULD.

The IETF may not be able to dictate what operators do (and I agree with
that). However, the IETF is in a strong position to signal and emphasise
what's best to do (hence, BCPs). Default for parameters are the signals
that provide the properties that the IETF design to and for are those
signals.

Regards,
Mark.

---

From: DaeYoung KIM <[email-masked]>
Date: Tue, 10 Apr 2018 07:34:16 +0200

All your arguments, especially in regards to the ISP practices, do not make a case, I’m afraid, that a /64 SHOULD be in rfc 4291. It suffices to state in a separate document that ISPs SHOULD hand out prefixes of /64 or shorter to the customer nodes, which document being already in existence.

With the common knowledge that an architecture document should be written as generic as possible, and with companion documents on SLAAC and IGPs already written to work for any prefix boundaries as they should be, rfc 4291 should not be written to enforce hard-coding the prefix boundary.

And as far as the sufficient number of IID bits for privacy, 40 bits are cited in a document as I recall.

Sent from my iPhone

---

From: Tom Herbert <[email-masked]>
Date: Mon, 9 Apr 2018 23:07:03 -0700

On Mon, Apr 9, 2018 at 1:59 PM, Mark Smith <[email-masked]> wrote:
>> On 24 Mar 2018, at 16:03, Mikael Abrahamsson <[email-masked]> wrote:
>>
>>    potential for causing harm (e.g., limiting retransmisssions)  For
>>    interoperability.
> In my experience, at a number of corporate and residential ISPs, privacy and
> security properties of addresses have not been a consideration in IPv4
> Today, with the /64 boundary, ISPs still don't specifically need to think of
> customer address privacy and security - it is inherent in the size of /64.

Mark,

I disagree that privacy customer privacy is inherent in /64
assignment. In the very common case where /64s are being assigned to
individual devices, all addresses created by the device will share a
common unique prefix. The device is trackable based on the /64 prefix
alone. The IIDs used by the device can change constantly, but that
does nothing to prevent tracking of the device. This concern is
mentioned in passing in RFC4941 and we examine it in more detail in
draft-herbert-ipv6-prefix-address-privacy.

Tom

> Remove that boundary, and it won't suddenly be considered, and I expect will
> be lost. I think ISP would be likely to inadvertently sacrifice customer
> addressing privacy and security to retain IPv4 addressing methods and
> practices because of their much more than a decade of familiarity with them.
>
> what's best to do (hence, BCPs). Default for parameters are the signals that
> provide the properties that the IETF design to and for are those signals.
>
> Regards,
> Mark.
>

---

From: Mark Smith <[email-masked]>
Date: Thu, 12 Apr 2018 06:26:05 +1000

Hi Tom,

On 10 April 2018 at 16:07, Tom Herbert <[email-masked]> wrote:

> >> Where’s the document to strongly recommend or mandate that they SHOULD
> or
> >> MUST hand out /56:es?
> >>
> and
> assignment.

I don't think I said that. What I was saying is that ISPs aren't in the
habit of considering customers' privacy requirements during IPv4 address
assignment during assignment, both because there wasn't an evident need
(i.e. pre-Snowden), and there weren't enough IPv4 addressing bits to do so
anyway. (I've never done it, and as recently as within the last month or
so, I've split up a public IPv4 /24 into /29s for customer assignments for
the most recent of 5 ISPs I've worked for.)

Unless the ISP service or product specifically offers security and privacy
as a feature e.g. IPsec VPN product, in my experience ISPs consider
customer privacy and security to be the customers' responsibility.

> In the very common case where /64s are being assigned to

I think that is unrelated to the size of the IID itself, and is a privacy
issue related to and caused by the assignment of a single prefix to a
single device. As you've observed, the prefix becomes the host identifier.

Reducing the default size of the IID, or abandoning a default IID size,
isn't going to have any positive influence on host addressing privacy in
that prefix-per-host scenario. Reducing the IID size significantly would
help confirm to a remote attacker that the prefix-per-host assignment model
is being used, when e.g. despite their being a possible 2^64 IID values
within a conventional /64 prefix assignment (i.e. assignment to link or
host), all the IIDs come from within e.g. a /120 within an assumed /64
address space.

Regards,
Mark.

> that

---

From: Mark Smith <[email-masked]>
Date: Thu, 12 Apr 2018 06:34:03 +1000

On 10 April 2018 at 15:34, DaeYoung KIM <[email-masked]> wrote:

> All your arguments, especially in regards to the ISP practices, do not
> make a case,

How so?

I've been exposed to or involved in IPv4 addressing planning since 1991
(yes, I remember the Internet before NAT, and I want that simplicity back),
have worked for 5 ISPs since then, including working for one of the 4
largest in .au now, and as recently as within the last month or so split up
a public IPv4 /24 into /29s. Never seen or had customers addressing privacy
be an IPv4 addressing size allocation consideration. It's been all about
how many individual hosts do they want to address, and in the more recent
decades, how much public address space do they want and are they willing to
pay for.

> I’m afraid, that a /64 SHOULD be in rfc 4291. It suffices to state in a
> separate document that ISPs SHOULD hand out prefixes of /64 or shorter to
> the customer nodes, which document being already in existence.
>
> With the common knowledge that an architecture document should be written
> as generic as possible, and with companion documents on SLAAC and IGPs
> already written to work for any prefix boundaries as they should be, rfc
> 4291 should not be written to enforce hard-coding the prefix boundary.
>

It isn't hard coded. There is no hard boundary between the prefix and IID
portions. RFC6164 would not be possible to implement or deploy if it was,
and BCP198 would not be able to make statements such as if there was a hard
boundary.

"Hardware and software
   implementations of routing and forwarding should therefore impose no
   rules on prefix length, but implement longest-match-first on prefixes
   of any valid length."

> cited in a document as I recall.

I don't recall, so a citation would be useful.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Apr 2018 09:39:59 +1200

> On 10 April 2018 at 15:34, DaeYoung KIM <[email-masked]> wrote:
...
> I don't recall, so a citation would be useful.

https://tools.ietf.org/html/rfc7421#section-4.5

But it's absolutely non-normative.

    Brian

---

From: Tom Herbert <[email-masked]>
Date: Wed, 11 Apr 2018 15:31:33 -0700

On Wed, Apr 11, 2018 at 1:34 PM, Mark Smith <[email-masked]> wrote:
> be an IPv4 addressing size allocation consideration. It's been all about how
> many individual hosts do they want to address, and in the more recent
Mark,

Even if they didn't consider privacy their customers might be getting
it accidentally. If they are using IPv4 CGNAT with a sufficiently
large pool of users behind a NAT address they are getting pretty good
privacy already. NAT addresses are hard to track. I've yet to see a
substantive argument that IPv6 /64 assignment can achieve that same
level of privacy for customers. Besides that, law enforcement doesn't
want providers to stop using CGNAT and start using IPv6 because that
gives better privacy for users, it's the other way around-- they want
IPv6 because they think it's easier to track individuals on the
Internet!

Tom

---

From: DaeYoung KIM <[email-masked]>
Date: Thu, 12 Apr 2018 05:53:18 +0200

Sent from my iPhone

> On 11 Apr 2018, at 22:34, Mark Smith <[email-masked]> wrote:
> 
> It isn't hard coded. There is no hard boundary between the prefix and IID portions.

RFC4291 specifies that hard boundary at /64, by limiting the IID length to 64 bits.

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Apr 2018 06:25:31 +1000

Hi Tom,

On 12 April 2018 at 08:31, Tom Herbert <[email-masked]> wrote:

> how
This sounds like an argument for ISPs to only give out /128s to individual
customers, or worse, have customers use ULAs and run a 1:M IPv6 CGNAT.

What I think is happening here is mixing up the specific privacy threats
and their possible mitigations.

The privacy I'm considering is the pervasive surveillance one, where a
party not involved in the communications is observing addresses. That is
why I referenced BCP188.

I'm not considering privacy from parties that have been chosen to
communicate with. If a host has chosen to communicate with a remote entity,
then it accepts it has chosen not to remain private from that remote entity.

To bidirectionally communicate with an entity, you either have to expose
your own identity to that entity, or operate through a proxy, with the
proxy hiding your identity, acting as a trusted intermediary. This is the
NAT/CGNAT box you mention (although they're not really that effective at
protecting privacy, they're not stripping out usernames/passwords/cookies
etc.)

The drawback of the proxy model is that now the proxy has to be trusted to
properly protect your privacy (and you're not easily able to verify it is),
and the proxy also becomes a easier target to attack to violate privacy.
Breach a proxy and you've breached the privacy of everybody using it.

I think the only way you can have total privacy from an entity being
communicated with, and not use a trusted intermediary, is to only have
unidirectional communication and to use bogus source addresses. Not very
applicable or useful.

Regards,
Mark.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 17 Apr 2018 14:27:01 -0700

On Tue, Apr 17, 2018 at 1:25 PM, Mark Smith <[email-masked]> wrote:
> What I think is happening here is mixing up the specific privacy threats and
> their possible mitigations.
>
> The privacy I'm considering is the pervasive surveillance one, where a party
> not involved in the communications is observing addresses. That is why I
> referenced BCP188.
>
Mark,

That is the same privacy concern I am considering. If a third party
attacker has access to an Internet link they can monitor it and
observe addresses used in flows. If individual devices use persistent
addresses (or peristent device prefixes), then the attacker can
attribute otherwise unrelated communications that share the same
source address or device prefix as being sourced by the same device
(and hence user for a personal device). That alone does not divulge
identity, but that may not be so hard to get. All the attacker needs
to do is establish the user behind just _one_ of their communications.
For instance, they may have access to server logs for a common app
that ties identity to IP address (similar to what FB provided to ICE).
IMO, the way to prevent this attack is to remove the correlating
information in addresses used in different flows (this an the effect
of CGNAT).

Tom

> your own identity to that entity, or operate through a proxy, with the proxy
> hiding your identity, acting as a trusted intermediary. This is the
>> >> And as far as the sufficient number of IID bits for privacy, 40 bits
>> >> are
>> >> cited in a document as I recall.
>> >
>> >

---

From: joel jaeggli <[email-masked]>
Date: Tue, 17 Apr 2018 15:13:23 -0700

> information in addresses used in different flows (this an the effect
The fixed nature of v6 subnetting tends to mean you can frequently mask
off the rightmost 64 bits when attempting to use source addresses as
identifiers. this is no different really then cpe-gateways with a single
/32 v4 address and port address translation. yes there are or may be
multiple hosts in there, varying your source address within a proscribed
address range however is like massive port number expansion, and it
doesn't take long to look past it.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 Apr 2018 16:48:58 +0200

> Where the difference is between IPv4 and IPv6 is in terms of addressing

Removing it also means that, if you please, you can also use *more* bits
for the IID.

> and security properties of addresses have not been a consideration in
> IPv4 because they couldn't be - there just weren't enough address bits
> for it to be possible. It has been all about providing customers with as
> many addresses as they needed, while also considering the scarcity of
> IPv4 addresses.

Well, one might argue that NATs relieve you from the need to randomize
addresses, since no matter how many nodes you have, all look the same
from the external realm.

> We might not know how many bits are the minimum are required for
> addressing privacy and security. However, I think we do know that more
> bits is always going to be better.
> 
> Today, with the /64 boundary, ISPs still don't specifically need to
> think of customer address privacy and security - it is inherent in the
> size of /64. Remove that boundary, and it won't suddenly be considered,
> and I expect will be lost. I think ISP would be likely to inadvertently
> sacrifice customer addressing privacy and security to retain IPv4
> addressing methods and practices because of their much more than a
> decade of familiarity with them.
> 
> However, from an address security and privacy perspective, probably not
> a MUST, but I would certainly say a strong SHOULD.
> 

I think the folks that have argued in favor of relaxing the /64 boundary
(including myself) were certainly in favor of including a "SHOULD do /64
for SLAAC".

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Apr 2018 08:06:25 +1200

> (including myself) were certainly in favor of including a "SHOULD do /64

Yes. That's what draft-bourbaki-6man-classless-ipv6 says, for example,
although not in RFC2119-speak.

     Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 Apr 2018 18:10:35 +0200

On 04/17/2018 10:25 PM, Mark Smith wrote:
> Hi Tom,
> 
> On 12 April 2018 at 08:31, Tom Herbert <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     On Wed, Apr 11, 2018 at 1:34 PM, Mark Smith <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     >
>     > On 10 April 2018 at 15:34, DaeYoung KIM <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>
> This sounds like an argument for ISPs to only give out /128s to
> individual customers, or worse, have customers use ULAs and run a 1:M
> IPv6 CGNAT.
> 
> communicate with. If a host has chosen to communicate with a remote
> entity, then it accepts it has chosen not to remain private from that
> remote entity.
> 
> proxy hiding your identity, acting as a trusted intermediary. This is
> the NAT/CGNAT box you mention (although they're not really that
> effective at protecting privacy, they're not stripping out
> usernames/passwords/cookies etc.)

But you don't need to allow the other party to correlate unrelated
network activity.

IPv6 tries to tacle that by using multiple addresses (RFC4941). IPv4
does this by having all nodes use the same address. In a sense, one
might argue that, fot this specific thing, the IPv4 approach is better.

---

From: Tom Herbert <[email-masked]>
Date: Sat, 21 Apr 2018 08:46:03 -0700

> But you don't need to allow the other party to correlate unrelated
Fernando,

That's the problem that needs to be solved.

> might argue that, fot this specific thing, the IPv4 approach is better.
RFC4941 does not consider the prefix, only privacy IIDs (it even says
that).If the device prefix is trackable then all the effort to chnage
IID for privacy seems ineffective. We consider prefixes and privacy in
draft-herbert-ipv6-prefix-address-privacy.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Sat, 21 Apr 2018 11:20:51 -0500

>>> <mailto:[email-masked]>> wrote:
[....]
> draft-herbert-ipv6-prefix-address-privacy.

I will read you I-D (hopefully this weekend) and provide comments.

That said, the only part of an address that you can really play with is
that which is not really an address.

E.g., In an IPv6 address, the prefix is topologically dependent and the
IID is not. So you can play freely with the I-D. If you do play with the
prefix, then you made it become topologically-independent (meaning that
it's now kind of an IID) or you will make routing cumbersome -- because
you pretend to be in places of the topology where you are not.

Thanks,

---

From: Tom Herbert <[email-masked]>
Date: Sat, 21 Apr 2018 09:50:30 -0700

Fernando,

That assumes that the address must contain topology information to be
routed to the end host. That's not necessarily true. NATed addresses:
identifier/locator split addresses like ILA, VIPs, virtual addresses
in network virtualization are examples where addresses are used that
don't themselves contain sufficient topology information to route a
packet all the way to the end host.

Eliminating internal fine grained network topology information form
externally visible addresses could be a benefit. For instance, this
could prevent network topology information in addresses being used to
deduce physical location of devices and hence users. This could also
help the network infrastructure, for instance I wouldn't want to
expose my internal network topology to the outside world lest
attackers could attack the infrastructure (e.g. launching a DDOS
attack on a rack switch via destination addresses in the rack).

Tom

---

From: Fernando Gont <[email-masked]>
Date: Sat, 21 Apr 2018 12:19:05 -0500

On 04/21/2018 11:50 AM, Tom Herbert wrote:
> routed to the end host. That's not necessarily true. 

An address is, by definition, a topologically-dependent ID. If it isn't,
it's not an address.

> NATed addresses:

It need not, as long as the packet gets routed there. And from the pov
of topology, maybe the address indicates the target LAN or something.

> externally visible addresses could be a benefit.

Isn't that what address translation is about? (along with any other
fancy names)

>  For instance, this
> deduce physical location of devices and hence users. 

If that's what you want, pic addresses from a flat space, and do
host-specific routes (this is the "routing becomes cumbersome" that I
referred to before).

> This could also

You either do the above (and appropriate filtering as needed), or... you
do NAT. Yes, NATs buy you this.

---

From: Tom Herbert <[email-masked]>
Date: Sat, 21 Apr 2018 10:41:40 -0700

> host-specific routes (this is the "routing becomes cumbersome" that I
Yes, on the surface it would seem that "simple routing" and strong
privacy for users are conflicting goals. I am hopeful that something
like "hidden aggregation"  (proposed in
draft-herbert-ipv6-prefix-address-privacy) might satisfy both goals.

Tom

---

From: joel jaeggli <[email-masked]>
Date: Sat, 21 Apr 2018 11:39:13 -0700

> An address is, by definition, a topologically-dependent ID. If it isn't,
the identifier and locator functions are overloaded on the address. the
IP layer only cares about the locator form of that function for forwarding.
> of topology, maybe the address indicates the target LAN or something.
they do contain information necessary to deliver the packet to
destination specified by the locator. there just happens to be
middlebox  at that locator which has used some other function to
transform them, typically by rewriting the locator or through encapsulation
> Isn't that what address translation is about? (along with any other
eliding topology information doesn't require transforming the locator,
tunneling does that all the time, so does anycast.