Re: PTR for IPv6 clients (Re: IPv6 NAT?)

[Rémi Després <remi.despres@xxxxxxx>]

This is a retransmission with a source address accepted on this discussion list.
Apologies to those who received it already.
If you respond, please use preferably this copy.
RD

Harald Alvestrand wrote:

Mark Andrews skrev:
  

You also don't want to do it as you would also need massive churn in
the DNS.

Microsoft gets this wrong as they don't register the privacy addresses
in the DNS which in turn causes services to be blocked because there
is no address in the DNS.
    

perhaps the advent of IPv6 will result in people finally (*finally*)
giving up on this sorry excuse for a security blanket? (calling it a
"mechanism" is too kind)

Or perhaps it'll just make people register wildcard records at the /64
level in ip6.arpa :-(

  

One approach to achieve it could be ias follows:
-  An IPv6 link  where some privacy source addresses may be used would have in the DNS a record for a "generic privacy address".
-  This address would  be the /64 of the  link followed by an agreed "joker IID" (0:0:0:0 or some other to be agreed on, e.g. FFFF:0:0:0).
-  Resolvers, if they recognize a privacy remote address, would query the reverse DNS with this "generic privacy address"  of the remote link.
-  They could also do this type of queries after failures of full address queries.

Problem:
Privacy addresses, as specified today, cannot be distinguished with 100% certainety from addresses obtained with stateful DHCPv6.
A proposal would be an addition to the privacy extension spec (rfc 4941).
- A variant of privacy addresses would be defined for "dsitinguishable privacy addresses".
- These addresses would, for example, have  FF00::/8 at the beginning of their IID  (no currently specified IPv6 IID begins that way; randomness on 58 bits is good enough).
- Then resolvers could recognize such privacy addresses for sure, and could query the reverse DNS with the  generic privacy address only when this is appropriate.

IMHO, this is a feasible step to reconcile: (1) privacy requirements of individuals; (2)  desire to know which site is at the other end where and when such a desire exists.

RD

_______________________________________________
IETF mailing list
IETF@xxxxxxxx
http://www.ietf.org/mailman/listinfo/ietf