Subject: v6-in-v4 configured tunneling over v4 multicast (vs 6over4)

From: Pekka Savola <[email-masked]>
Date: Sat, 8 May 2004 09:21:55 +0300 (EEST)

Hi,

When discussing draft-savola-v6ops-tunneling-01.txt with Dave Thaler, 
mainly about the necessity of 6over4 in the scenario where the IPv4 
network is multicast-enabled but the v6 network is not, I came up with 
an idea which I'm not sure if others have brought up in the past:

If you want to create point-to-multipoint tunnels over v4 multicast
infrastructure, wouldn't the obvious solution be simply using
configured tunneling?  That is, you configure the tunnel destination
v4 address to be a multicast address (this requires zero code
changes), and the decapsulators configure their "local end" to be the
multicast address (requires code change in the tunnel setup tool to
permanently join the specified multicast address)?

This would seem to act like a "statically mapped", simplified
alternative to 6over4 which would only require an
implementation-specific addition to join the multicast group.

This is in line with RFC2893 and draft-ietf-v6ops-mech-v2-02.txt, as 
long as you interpret section 3.6 loosely enough:

   When an IPv6/IPv4 host or a router receives an IPv4 datagram that is
   addressed to one of its own IPv4 addresses, [...]

(this wording could be tuned, obviously.)

Thoughts?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 09 May 2004 10:04:57 +0200

Maybe. But I was told by the people who implemented 6over4 a few
years ago that it was only one page of code anyway - so I am not
so sure about the simplification.

    Brian

---

From: Stig Venaas <[email-masked]>
Date: Sun, 9 May 2004 11:13:28 +0200

On Sat, May 08, 2004 at 09:21:55AM +0300, Pekka Savola wrote:
[...]
> implementation-specific addition to join the multicast group.

Are you saying that all hosts that are to share a virtual link, will
use the same tunnel? So that all communications between all these
hosts will be sent to one single multicast group that they all join?

I think 6over4 would do better, and it's not hard to implement either.

Stig

---

From: Pekka Savola <[email-masked]>
Date: Sun, 9 May 2004 13:01:03 +0300 (EEST)

> hosts will be sent to one single multicast group that they all join?

No.  Sorry -- I should have been clearer on the context of the idea.

The strongest argument for 6over4 is in scenarios where you implement
v4 multicast for specific applications, and you'd implement v6
multicast for the same apps if you could (but if support is not being
provided by the vendors..).  The argument against configured tunneling
is that it requires quite a large load on the servers if the number of
participants per group grow larger than about 5-10 (due to requiring
unicast packet per receiver, instead of about one multicast packet).

So, I was thinking that these "multicast tunnels" might be able to 
complement either (non-multicast) native IPv6 or tunneled (configured 
tunnel, ISATAP whatever -- anything except 6over4) IPv6.

In other words, such "multicast tunnels" would be only used for very
specific applications, one tunnel per (group of) applications, as a 
means to leverage existing v4 multicast infrastructure to obtain the 
benefit of no multicast->unicast conversion/duplication in the 
network.

---

From: Stig Venaas <[email-masked]>
Date: Mon, 10 May 2004 10:35:26 +0200

On Sun, May 09, 2004 at 01:01:03PM +0300, Pekka Savola wrote:
[...]
> benefit of no multicast->unicast conversion/duplication in the 

Ah, I see. Yes, that's an interesting idea (:

Stig

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 May 2004 10:37:34 -0700 (PDT)

> permanently join the specified multicast address)?

This implies that all IPv6 (unicast and multicast) packets will be sent
as IPv4 multicast, right?

While that might significantly increase the use of IPv4 multicast, it might
have negative implications on the performance of the network :-)

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 May 2004 23:10:34 +0300 (EEST)

> as IPv4 multicast, right?

Not necessarily -- sorry for failing to say that explicitly in the
first place (you guys couldn't read my mind yet?!?! :).  See the note
I wrote to Stig for clarification.
 
> have negative implications on the performance of the network :-)

Yes, it could be a problem -- a bit in the same way as 6over4 (in this
context) hass a problem.  But luckily enough, this would probably
apply only to v6 multicast of scope greater than link-local.

---

From: Fred Templin <[email-masked]>
Date: Tue, 11 May 2004 15:14:44 -0700

Pekka,

>permanently join the specified multicast address)?

As you know, the decapsulating end of a configured tunnel requires
a specific IPv4 source address for the "remote end" of the tunnel, so
the configured tunnels you describe would only be able to decapsulate
multicasts from a single specific encapsulator. I.e., you would need
one such configured tunnel for each potential encapsulator (which
could be a large number).

If you want a single tunnel interface that could decapsulate multicasts
from *any* decapsulator, you would need something like 6over4 (or,
ISATAP if the IPv6 multicast address is mapped to a unicast IPv4
link-layer address.) Your configured tunnels could still be used as
decapsulator-specific "overlays" (if needed), but it seems like
you would still need the 6over4/ISATAP for wildcard match
on a large set of potential encapsulators.

Fred
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Tue, 11 May 2004 15:37:18 -0700

Whoops; I see a couple of typos to correct (below):

Fred
[email-masked]

> from *any* decapsulator, you would need something like 6over4 (or, 

s/decapsulator/encapsulator

> decapsulator-specific "overlays" (if needed), but it seems like

s/decapsulator-specific/encapsulator-specific

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 May 2004 18:46:02 -0700 (PDT)

> I wrote to Stig for clarification.

I didn't understand that note.

> benefit of no multicast->unicast conversion/duplication in the 

For those "specific applications" (whatever that means) you'd end up with 
having everything that enters the tunnel interface on the sender being sent
to the "tunnel endpoint", which you stated is an IPv4 multicast address.

If you are thinking about only using the multicast to discovery a unicast
address of the tunnel endpoint on a per IPv6 nexthop basis,
then I think you are recreating something isomorphic to 6over4.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 May 2004 08:36:07 +0300 (EEST)

I'll reply here to both you and Fred.

To Fred: yes, precisely; this mode would only allow one sender per
tunnel.  I don't see that as a big problem, as most multicast apps
(videoconferencing and similar being the exception, but those only
have a limited number of participants, so unicast duplication should
not be a problem) are intrinsically more or less single-source.

> I didn't understand that note.

OK, let me try to describe it with an example.
 
> to the "tunnel endpoint", which you stated is an IPv4 multicast address.

Let's take an example.  An enterprise is has a multicast application
with IPv4, for example, video broadcast of CEO talking every morning
:-), delivering stock prices to the brokers' terminals, or whatever.
(Videoconferencing is out of scope.)  Those are mainly one-to-many 
multicast.

Now, that enterprise would wish to do the same with v6, but their v6 
routers don't support multicast (or they don't have many v6 routers in 
the first place).

The enterprise assigns the admin-scoped multicast address 239.1.1.1 
for stockticks, or 239.1.1.2 for CEO's morning address.

The host sending this feed would configure the multicast tunnel like:

src_v4: 192.168.1.1 (the IP address)
dst_v4: 239.1.1.1

(No IPv6 addresses would be needed on the tunnel, except the 
traditional link-locals.)

The receivers would configure a tunnel like:

src_v4: 192.168.1.1
dst_v4: 239.1.1.1

(This would require an addition to configured tunnel set-up to join 
the multicast address 239.1.1.1.)

The v6 packets would be sent with:

src_v6: 2001:db8:1:2::1 (the IPv6 address of the sender)
dst_v6: ff05::1234 (whatever admin-scoped v6 multicast address)

To recap, this would require the following:
 1) one tunnel per multicast application (unless you wish to dump 
    everything in one v4 group, deliver it to everyone, and let their 
    multicast subsystem filter it out.)
 2) only for one-to-many multicast apps
 3) v4 multicast infrastructure

On the other hand, the benefits are:
 1) no unicast->multicast packet duplication at the tunnel servers, 
    etc -- uses v4 multicast techniques
 2) no new protocols needed, i.e., if deploying/implementing 6over4 is 
    not seen feasible, this could provide a means to achieve some 
    benefits of 6over4 for v4 multicast application.

> then I think you are recreating something isomorphic to 6over4.

No, that wasn't the intent -- and yes, that would be like 6over4.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 May 2004 09:42:12 +0200

> apply only to v6 multicast of scope greater than link-local.

6over4 only uses v4 multicast when native IPv6 over Ethernet would use
Ethernet multicast, so I don't see this as a significant issue for
6over4. In fact, the only known issue with 6over4 is that most enterprises
don't run v4 multicast on their intranets. Any other solution relying
on v4 multicast has this issue.

    Brian

    Brian

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 May 2004 15:42:57 -0700 (PDT)

> (Videoconferencing is out of scope.)  Those are mainly one-to-many 

I think you mean "single sender" since all multicast is "one-to-many".
Are you explicitly excluding applications, such a streaming media,
which have a unicast feedback channel? (for quality reports etc)

> routers don't support multicast (or they don't have many v6 routers in 

Does "don't have many v6 routers" imply that there
might not be unicast connectivity between all the nodes for which you want
to establish single-sender multicast connectivity?

> traditional link-locals.)

I think that implies that it is impossible to have unicast feedback;
there isn't a tunnel configured on the multicast receivers which can be
used to send packets to the senders link-local IPv6 address, is there?

>     benefits of 6over4 for v4 multicast application.

But why not just run this application over IPv4 multicast?
I don't see what IPv6 multicast using only IPv6 link-local addresses
(and perhaps not a unicast return channel) would provide
over what IPv4 multicast can provide in this case.

   Erik

---

From: Fred Templin <[email-masked]>
Date: Wed, 12 May 2004 16:03:34 -0700

>which have a unicast feedback channel? (for quality reports etc)

I'm not sure that "single sender" would be correct in all cases either,
since the encapsulator could occur on an IPv6 router (or some other
middlebox) which might be many IPv6 routing hops down the line
from the original source(s) - of which there could be many.

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Fri, 14 May 2004 12:40:20 +0300 (EEST)

> which have a unicast feedback channel? (for quality reports etc)

Sorry for the terminology mess.  I'm referring to the distinction of 
SSM vs ASM, where you either have "one-to-many" sessions or 
"many-to-many" sessions (from the perspective of the network and the 
receivers).  From the sender's point of view, it's always obviously 
one-to-many.

Unicast feedback channels are not excluded; I'd just assume that the
unicast v6 reachability is obtained using a different mechanism
(natively, using another configured tunnel, a tunnels server,
whatever).

> to establish single-sender multicast connectivity?

It's possible that native v6 would not be available to everyone, in 
which case some tunneling (separate from the multicast tunnels) would 
be used.

> used to send packets to the senders link-local IPv6 address, is there?

Connectivity is obtained separately, natively or through a different 
set of tunnels.  So there would be a feedback channel, but the 
feedback would go through a different route than the multicast feed.

> But why not just run this application over IPv4 multicast?

Good question.  I suppose the idea is to transition the network to 
IPv6, and being able to do the same with v6.  I think the argument in 
the original scenario was that if there is no mechanism for v6, people 
could not transition their apps etc. to v6, or might delay the v6 
deployment for the lack of support.

If truth be told, and considering dual-stack deployments, this is not 
really convincing, because as it works with v4, and the only thing 
missing from v6 is the support in their equipment, a correct 
response could be continue using it w/ v4 and request implementing v6 
multicast support, or buy only products which support that.

But delaying v6 deployment due to this might not be a good idea 
either, which is why I thought a separate multicast tunnel could be an 
easy solution to this problem.

> over what IPv4 multicast can provide in this case.

You don't need to use IPv6 link-local addresses, you can use a wider
scope as well.  But a link-local would be the simplest, and unicast
return channel would be possible as well.

---

From: Stig Venaas <[email-masked]>
Date: Fri, 14 May 2004 11:57:39 +0200

On Wed, May 12, 2004 at 09:42:12AM +0200, Brian E Carpenter wrote:
[...]
> Ethernet multicast, so I don't see this as a significant issue for

Agree

> on v4 multicast has this issue.

Yes, but I think there are many enterprises (although not most) that do
have intradomain multicast. Also in the academic world where I live, most
universities and schools do have intradomain multicast. I still think
6over4 is a really good solution in these cases.

Stig

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 May 2004 09:47:46 -0700 (PDT)

> multicast support, or buy only products which support that.

It would seem odd to have an organization which uses IP(v4) multicast
try to transition to IPv6 while forgetting that they need IPv6 multicast
support to allow their multicast applications to transition.

Since this is an operational WG, have we received requests from folks operating
IPv6 that they are running into this particular problem? 

> easy solution to this problem.

Easy to specify in a short RFC, but do we know anything about the 
operational complexity (trouble-shooting etc) of the resulting
network? For all I know it might be a lot more complex than
just operating dual-stack (with multicast support for both v4 and v6).

  Erik

---

From: Tim Chown <[email-masked]>
Date: Mon, 17 May 2004 16:57:21 +0100

> IPv6 that they are running into this particular problem? 

We operate IPv4 and IPv6 multicast.   If we want bridging between the two
protocols we use Stig's gateway (which sadly wasn't adopted by the mboned
WG, despite evidence of its utility).

For SSM, we are only using IPv6.

> just operating dual-stack (with multicast support for both v4 and v6).

At present we do not operate an RP for either protocol, and our routing
off site is different per protocol (IPv4 via our campus and regional
network, IPv6 via a direct tunnel to the UK 6NET multicast router).   One 
might expect these to merge in time I agree.   

Tim