On Mon, 7 May 2001, Dave Thaler wrote:
> I'd agree with Yes for #1 and #2.
>
> There's no really "good" answer to #3, and I think it partly comes down
> to what people expect the answers to these questions to be:
>
> 4. For a v4-mapped multicast address, should IN6_IS_ADDR_V4MAPPED be
> TRUE?
>
> 5. For a v4-mapped multicast address, should IN6_IS_ADDR_MULTICAST be
> TRUE?
>
> The best technical answer would be Yes to both #4 and #5. However,
> that would mean the definition of one or the other of the macros would
> have to change to include the v4-mapped multicast address range,
> and that may not be reasonable at this point. Another alternative
> would be to define an IN6_IS_ADDR_V4MAPPED_MULTICAST macro, and
> make callers of either IN6_IS_ADDR_V4MAPPED or IN6_IS_ADDR_MULTICAST
> (depending on which prefix we go with) call the new macro too to cover
> all cases.
While I would agree that the answer to #4 and #5 are both Yes I'm not as
sure that would require a change to the definition of the macros as
specified in the socket extension API. The definition of
IN6_IS_ADDR_V4MAPPED does not make a distinction between unicast and
multicast and so would be blind to a change in RFC-2373 that only extends
the definition of V4-mapped to now include multicast. For the definition
of IN6_IS_ADDR_MULTICAST - well when you think about it that's what we're
actually trying to clarify in the first place. Ie. what
IN6_IS_ADDR_MULTICAST covers is not clear however, is clarifying it at the
RFC-2553 level appropriate vs clarifying it in RFC-2373? However, I do
agree a revision of RFC-2373 would cause implementations that were once
compliant with RFC-2553 no longer are - but not because RFC-2553 changed.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
