Hi Michael, I wrote this up and presented it at mboned some number of meetings ago: http://tools.ietf.org/html/draft-jabley-multicast-ptr-00 I didn't hear any dramatic objections to the approach described in there at the time, although the document could surely benefit from more review. I The draft is in pretty reasonable shape, I think, and it would likely not take too much work to polish it off. If you have spare cycles and enthusiasm to work on it, I'd happily add you as a co-author and collaborate on making some progress. Joe On 10 July 2014 at 16:12:45, Michael Richardson (mcr+ietf@xxxxxxxxxxxx) wrote: > > I'm not really sure where to address this question. > I am debugging some DHCPv6 code, and I asked my system for multicast > membership, and "netstat -g" told me that I was a member of all-systems.mcast.net. > Adding -n told me the IPv4 values, but I then noticed that the V6 addresses > did not have a reverse. > > icann.org seems to maintain the reverse for 224.in-addr.arpa, so naturally > 224.0.0.1 gets mapped that way. > Doing a dig on reverse for ff02::1 gets me: > ip6.arpa. 3587 IN SOA > b.ip6-servers.arpa. hostmaster.icann.org. 2014061793 1800 900 604800 3600 > > and asking about ip6-servers.arpa tells me that iab@xxxxxxx is the admin contact, > and iana@xxxxxxxx is the technical contact. > > I guess it's IANA's job to populate the reverse for ff::/8 with something? > I'm wondering when this might occur... what will it point to? > > mcast.net is a Verisign property. The contact address is very generic, so I > am skeptical that an email to that address will return something useful, > but I've tried anyway. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > >