On 15 May 2017, at 11:44, Jan Zorz - Go6 <jan@go6.si> wrote:
On 15/05/2017 12:21, Tim Chown wrote:
But we should not do anything to preclude privacy-enhancing methods being applied at any layer.
Hi,
But how does changing the address prefix provide any possible privacy enhancement at all? It's usually L7 that provides/breaks nearly all of that…
Sure, much is at the application layer, but that is not a reason to address privacy issues at each layer. Hence, for example, with my IETF hat on, draft-ietf-dnssd-privacy-01 and draft-ietf-dnssd-pairing-01.
Nevertheless, for those people being completely lost with how technology works and to assure their warm&fuzzy feeling while dictating how others should build and run their networks - I would agree to add your proposed text below to the document. ;)
:) Well, I guess there is a potential user education topic here as well. It’s a trade-off. Tim
Cheers and thnx, Jan
I would argue that the BCOP text should say:
a) ISPs are encouraged to support both stable (persistent) and privacy-oriented (non-persistent) prefixes as options for customers;
b) stable/persistent prefixes are recommended as the default, in the absence of legal requirements to the contrary in any specific country.
I’d also note that the biggest UK IPv6 deployment is a “sticky” /56 to residences; it’s hard for an ISP to guarantee a lifetime stable prefix, but they can take steps to minimise the likelihood of a change being needed.
Tim