On Fri, 4 May 2001, Tim Hartrick wrote:
> > So I'd argue for just sticking IPv4 multicast addresses in ::ffff:0:0/96
> > at the API and have the implementations which support mapped addresses
> > do the right thing to send/receive IPv4 multicast packets in that case.
> >
>
> I would agree. What we want is application transparency so allowing
> ::ffff:224.x.y.z to represent IPv4 multicast addresses or ::ffff:127.0.0.1
> to represent IPv4 loopback addresses seems like the right thing.
I suppose it should allow for whatever format gethostbyname() or
getipnodebyname() returns (with or without the ff0e:: prefix) and just 'do
the right thing' for transparency.
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.
So are these reasonable suggestions? And am I even asking in the right
forum? Should I just propose a wording change to the existing RFCs?
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
