Re: IPv6 Privacy Considerations

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Erik Nordmark writes:
> On 3/14/14 9:32 AM, Mark Andrews wrote:
> > If one is really worried ISP's could give out both stable and
> > unstable prefixes.  We just need a way to identify which is which.
> >
> > If you are running servers you put them on the stable prefixes.
> > You assign temporary addresses out of the unstable prefixes.
> >
> > IA_NA, IA_PD and SLAAC all need to be supported.
> Mark,
> 
> I don't know how important it is to solve this, but *if* we want to 
> solve it we might have a way do to it using existing protocol mechanism 
> (the lifetimes) in DHCP and in SLAAC.

It needs to be explicit.  As for the importance this may be forced
on us.

Personally I've used the same prefix at home for 10 years and it
doesn't bother me.  The IPv4 address I have is dynamic but only
changes when my ISP needs to split nodes.  I'm not particularly
worried as there are lots of ways to track a machine.  But for those
that are worried it would be nice to have this sort of functionality.

> For example, if a host doing SLAAC receives two prefixes (with A=1) in 
> RAs: one having a lifetime of 30 days and one having a lifetime of 1 day 
> (or 1 hour), then the host implementation of temporary address can pick 
> those from the short lifetime prefix, while picking the stable-privacy 
> address from the long-lived prefix. No on the wire change needed.
> 
> Likewise, a DHCP server in a home gateway might receive two (or more) 
> prefixes from the ISP using IA_PD, with very different lifetimes. When 
> such a DHCP servers handles a IA_NA it could pick from the long-lived 
> prefix(es), while IA_TA is picked from the short-lived prefix(es).
> 
> But the first question is whether we want to work on this problem area.
> 
>     Erik
> 
> >
> > As for dynamic updates, they do work provided there is a service
> > which continues to attempt to do the update when the name servers
> > for the zones are unreachable.
> >
> > It also requires dynamic DNS providers to support UPDATE + TSIG
> > and/or SIG(0) for all their customers.  SIG(0) is better from a
> > compromised server perspective as the provider is just storing a
> > public key usually in the zone being updated.
> >
> > Registrars also need to support UPDATE + TSIG and/or SIG(0) to
> > update glue records for those that want to host their own zones.
> > draft-andrews-dnsop-update-parent-zones-04 provides a outline of
> > how to do this.  This works for any parent zone not just RRR managed
> > zones.
> >
> > It is possible to make slave name servers use the source address
> > of NOTIFY + TSIG and/or SIG(0) messages to determine where to
> > transfer the zone content from.  This is just a exercise in coding
> > as all the protocol elements already exist to do this.  Normally
> > you would store the KEY record in the zone at the apex if you were
> > doing SIG(0).
> >
> > Mark
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]