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

From: Tim Hartrick <[email-masked]>
Date: Fri, 4 May 2001 12:01:40 -0700 (PDT)

> From [email-masked] Fri May  4 03:15:51 2001
> Received: from roll.mentat.com (roll [192.88.122.129])
> 	by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id DAA07760
> 	for <tim@leo>; Fri, 4 May 2001 03:15:51 -0700 (PDT)
> Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
> 	by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id DAA20140
> 	for <[email-masked]>; Fri, 4 May 2001 03:15:49 -0700 (PDT)
> Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
> 	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12084;
> 	Fri, 4 May 2001 03:13:26 -0700 (PDT)
> Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
> 	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA10911;
> 	Fri, 4 May 2001 03:13:16 -0700 (PDT)
> Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
> 	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44AC0IM008095
> 	for <[email-masked]>; Fri, 4 May 2001 03:12:01 -0700 (PDT)
> Received: (from majordomo@localhost)
> 	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44AC0gL008094
> 	for ipng-dist; Fri, 4 May 2001 03:12:00 -0700 (PDT)
> X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to [email-masked] using -f
> Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged))
> 	by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44ABnIM008087
> 	for <[email-masked]>; Fri, 4 May 2001 03:11:49 -0700 (PDT)
> Received: from buse (buse.France.Sun.COM [129.157.212.11])
> 	by jurassic.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with SMTP id f44ABVHD302120;
> 	Fri, 4 May 2001 03:11:32 -0700 (PDT)
> From: Erik Nordmark <[email-masked]>
> Reply-To: Erik Nordmark <[email-masked]>
> Subject: RE: multicast IPv4-mapped IPv6 addresses/sockets

> 
> 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.

tim
--------------------------------------------------------------------
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: Mon, 7 May 2001 13:25:46 -1000 (HST)

> 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?

---

From: Markku Savela <[email-masked]>
Date: Tue, 8 May 2001 11:15:08 +0300

> From: Antonio Querubin <[email-masked]>

> 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 definitely don't want to see "ff0e::ffff:224.5.6.7" (or if I see it,
it will be normal IPv6 multicast, the bits after "ff0e" are "opaque"
to me, I don't want to make any special IPv4 related things for such
address).

I would still have to check against "::ffff:224.5.6.7" (in my
implementation), and handle it as IPv4 where appropriate. Currently my
"multicast actions" are triggered with test

   IsMulticast() || (addr[12] == 224 && IsV4Mapped())

where IsMulticast() is testing the IPv6 multicast prefix