>>>>> On Tue, 15 Nov 2005 16:05:07 +1100,
>>>>> Mark Andrews <[EMAIL PROTECTED]> said:
>> 255.255.255.255.IN-ADDR.ARPA /* IPv4 BROADCAST */
>>
>> ==> should the whole 255.IN-ADDR.ARPA be covered? should 0.0.0.0 be
>> covered ? what about site-local v4/v6 multicast addresses?
> I was being conservative. I'll follow w.g. advice on this.
> As for general multicast the reverse space for IPv4 multicast is
> currently populated.
Mac OS X seems to try resolving 0.0.0.0.in-addr.arpa for some
applications (e.g., in the "w" command). So, covering 0.0.0.0 is
effective at least in practice. I personally also think it's
justified according to the sence of RFC3330, which reads:
0.0.0.0/8 - Addresses in this block refer to source hosts on "this"
network. Address 0.0.0.0/32 may be used as a source address for this
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
host on this network; other addresses within 0.0.0.0/8 may be used to
^^^^^^^^^^^^^^^^^^^^
refer to specified hosts on this network [RFC1700, page 4].
I think the semantics is effectively the same as that for 127.0.0.1 (or
127/8):
127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
This is ordinarily implemented using only 127.0.0.1/32 for loopback,
but no addresses within this block should ever appear on any network
anywhere [RFC1700, page 5].
and the full-service-resolvers draft already covers 127/8.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
