Antonio Querubin writes:
> After reading through the responses to this thread it's not clear to
me
> whether there's any consensus for change. I see several issues:
>
> 1. Is the current non-transparency of the API for handling multicast
> addresses sufficiently annoying to warrant fixing 'something'?
>
> 2. Even if they're not annoying enough, should the specs be at least
> clarified one way or another?
>
> 3. If the specs need to be modified to either clarify and/or fix
things
> then which ones and which parts? RFC-2373 section 2.5 covers only
unicast
> addresses so the description of IPv4-mapped IPv6 addresses in 2.5.4
> theoretically doesn't apply to multicast addresses at all. Since
fixing
> this problem (if we do want to fix it) seems to revolve around the
IPv6
> representation of an IPv4 multicast address we're highly dependant on
what
> RFC-2553 says. But section 3.7 of RFC-2553 makes no explicit
distinction
> between unicast and multicast addresses. The distinction is implicit
> based on the definition of an IPv4-mapped address which leads us back
to
> RFC-2373.
>
> For me the answers to #1 and #2 are YES for the same reasons already
> mentioned by others. For #3, I'm inclined to suggest a change to
RFC-2373
> where the format of IPv4-mapped multicast addresses be explicitly
defined
> and then perhaps RFC-2553 wouldn't require modification. So do we
want to
> explicitly 'define' what an IPv4-mapped multicast address should look
> like? Ie. should it look something like ff0e::ffff:224.5.6.7 to
> distinguish it from a real IPv6 multicast address or perhaps
> ::ffff:224.5.6.7 for similarity to IPv4-mapped unicast addresses? I'm
> inclined to go with the latter.
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.
-Dave
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
