> On 15 May 2017, at 11:44, Jan Zorz - Go6 <[email protected]> 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 >>
