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(_at_)sandelman(_dot_)ca) 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(_at_)iab(_dot_)org is the
admin contact,
and iana(_at_)iana(_dot_)org 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 =-