Hi, Thanks for your comments. > > > "peer" is also a nit - if you > > want an unknown someone to be able to contact you, you need to make > > yourself findable, whether the protocol design is p2p or not. > > Otherwise you don't. > > I also object to the notion that every host or application should be identified by > name and not by address. In a peer to peer network, the peers can certainly > have the other peers' IP addresses known to them. You don't need a DNS at all, > in situations like this. > > Matter of fact, I would suggest that the Client Identifier Option of DHCP is > precisely for such scenarios. Where the unconfigured peer needs to be given a > specific IP address, because that's the only way the other peers can find it. >
DHCPv6 is another approach to generate an IID. So, the choice of using DNS name is out of scope of ra-privacy document. In ra-privacy draft, we explained that having a DNS names (not local names)/ public names would have a negative effect on user's privacy. This is why, the node "should" not have public addresses(that has public DNS names) if it cares about privacy. But also we explained that if a node wants to have public addresses, it "must" not generate it based on MAC..[..]. Our reason: you usually don't have public DNS names for your clients and you usually use it for your host. Some says that you should not separate the type of nodes (clients or servers...) and so you should not use "should" for this case. So, I agreed that I can use "recommended" or "might" and then explain the circumstances of having public DNS names. Thanks, Hosnieh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
