PTR records for IPv6

[Dan Wing]

On Sep 5, 2013, at 7:03 AM, David Magda <dmagda at ee.ryerson.ca> wrote:

> On Wed, September 4, 2013 22:47, Dan Wing wrote:
> 
>> Yes, disabling IPv6 privacy addresses makes tons of things easier --
>> including traffic analysis.  One of the primary purposes of IPv6 privacy
>> addresses was to antagonize traffic analysis and discourage one of the
>> justifications to create a NAPT66 device (as one of the justifications for
>> NAPT is to antagonize traffic analysis).
>> http://tools.ietf.org/html/rfc4941#section-2 has lots of good details.
>> (And I know privacy information is leaked at upper layers; there are
>> constant attempts at those layers to reduce their privacy leakage and it
>> doesn't excuse exposing privacy at layer 3).
> 
> Sadly there doesn't seem to be an easy way to do pre-prefix privacy
> options. If one is using SLAAC and RAs, there's no option to tell IPv6
> systems to use the privacy extensions on prefix A but not on B.

I have seen that idea floating around and agree it would avoid the problem of privacy addresses within, say, an enterprise but use privacy addresses when communicating towards the Internet. That would resolve the most typical threat (that traffic analysis is being performed by attackers outside of the enterprise network).  However, I haven't yet seen that written up as an Internet-Draft, which would help encourage discussion and would help gain attention of OS X/iOS/Windows, which are the primary OSs deployed on the enterprise networks where privacy addresses are the biggest problem to network administrators.  But such a feature implies the network manager is confident their local network is free of attackers doing traffic analysis of internal traffic.  But it would ease the memory requirements of IPv6 switches because RA guard (and similar technologies) would need to remember fewer host IPv6 addresses!

> Similarly I asked a while ago and DHCPv6 implementations don't have a way
> to do it either.
> 
> So if one's network (say) uses ULA for internal traffic, and public
> addresses for external traffic, then it's either all or nothing for
> privacy. It'd be nice to have random addresses to prevent external
> tracking, but MAC-based addresses for internal auditing. If that isn't
> available via RA options, then hopefully it will become possible via
> DHCPv6 at some point.

The best solution is improving tools to understand multiple IPv6 addresses.  Consider an abuse report (from the Internet) reported to the enterprise will see the IPv6 privacy address, and the enterprise needs to determine which host was using that address.  Thus the tooling needs to be capable auditing for multiple IPv6 addresses assigned to a host.  If the tooling can handle multiple IPv6 addresses assigned to a host for Internet-destined traffic, the tooling should be capable of handling multiple IPv6 addresses for enterprise-internal traffic, too?

-d