Subject: RE: multicast IPv4-mapped IPv6 addresses/sockets

From: "Dave Thaler" <[email-masked]>
Date: Mon, 7 May 2001 18:42:31 -0700

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-masked]
--------------------------------------------------------------------

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 8 May 2001 05:42:27 -1000 (HST)

> (depending on which prefix we go with) call the new macro too to cover

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.