Subject: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41)

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 15 Dec 2014 19:38:05 +0000

Hi Gert,

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Gert Doering
> Sent: Monday, December 15, 2014 10:01 AM
> To: Tariq Saraj
> Cc: [email-masked]
> Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41
> 
> Hi,
> 
> On Sun, Dec 14, 2014 at 12:18:00AM +0500, Tariq Saraj wrote:
> > There are some issues with 6rd as well, IPv6 with all its powerful features
> > is still under critical objections in academia just because of the urgency
> > shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 clearly
> > mentioned that it cannot support multicast at layer-3, on the other end 6rd
> > claimed that multicast can be provided, my question is that while
> > standardizing 6rd which at that time was just supporting unicast traffic
> > traversing across IPv4 network and its still not matured enough to provide
> > multicast support yet in its functionality other than using some proxy
> > support for multicast traffic. why It was standardized ?
> 
> There is no wide-area multicast anyway.

I don't know about that, but it does not hurt to be prepared to accommodate such.

> So why bother if a closed user
> group decides to deploy a stopgap technology to enable IPv6 access.

Link- and site-scoped multicast might still be very beneficial, e.g., an operator
sending a bulletin to all customers, etc. So, the ability to support IPv6 multicast
within the operator network may be useful.

> And, when speaking about academia: do they have a "how to not write e-mail"
> class there?  Like, "take a full digest with lots of unrelated mail in it,
> and write a top posting on top of it"?

Please be gentle in providing guidance.

Thanks - Fred
[email-masked]

> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
> 
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Bill Owens <[email-masked]>
Date: Mon, 15 Dec 2014 15:01:21 -0500

> I don't know about that, but it does not hurt to be prepared to accommodate such.

As of this afternoon, we see 20655 v6 unicast networks and 66 multicast, with paths that include a total of 50 ASes. We have both commercial and R&E v6 paths, but there are just thirteen peers that carry multicast; all of them are R&E networks. So there is *some* wide-area IPv6 multicast, but not *much*. Certainly not enough to be worth using except in extremely limited circumstances. We continue to support it simply because of inertia; it would be more work to remove it from our configurations than to keep it in.

Bill.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 15 Dec 2014 21:10:17 +0000

Hi Bill,

> From: Bill Owens [mailto:[email-masked]]
> Sent: Monday, December 15, 2014 12:01 PM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41)
> 
> As of this afternoon, we see 20655 v6 unicast networks and 66 multicast, with paths that include a total of 50 ASes. We have both
> commercial and R&E v6 paths, but there are just thirteen peers that carry multicast; all of them are R&E networks. So there is *some*
> wide-area IPv6 multicast, but not *much*. Certainly not enough to be worth using except in extremely limited circumstances. We
> continue to support it simply because of inertia; it would be more work to remove it from our configurations than to keep it in.

That is great data, but is a bigger picture concern for IPv6 in general and
not for the use of tunnels inside of IPv6 sites right?

Inside of the site, there may be a need for IPv6 link- and site-scoped
multicasts, e.g., for service discovery, public bulletins, media simulcasts,
etc. In that case, it might be good if the tunnels handled multicast.

Thanks - Fred
[email-masked]

---

From: Bill Owens <[email-masked]>
Date: Mon, 15 Dec 2014 16:54:04 -0500

> etc. In that case, it might be good if the tunnels handled multicast.

I suppose it might be useful to have site-scoped multicast, though if tunnels were needed to accomplish that I think it would be more likely that they'd be hand-configured tunnels between routers, rather than some part of a transition mechanism. I honestly have never paid any attention to the prospect of using any of the transition schemes within a site; it always seemed to me that they would be between a site and its provider. And although I used to be a strong advocate of multicast both in the wide and local networks, its use cases have faded to the point where I no longer recommend that anyone make the effort of deploying it.

Bill.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 15 Dec 2014 22:43:09 +0000

Hi Bill,

> Sent: Monday, December 15, 2014 1:54 PM
> To: Templin, Fred L
> Cc: [email-masked]
> I suppose it might be useful to have site-scoped multicast,

Two that come to mind are LLMNR and mDNS. But really, any site-scoped or
link-scoped multicast application should work.

> though if tunnels were needed to accomplish that I think it would be more
> likely that they'd be hand-configured tunnels between routers,

Automatic tunnels without explicit configurations are also possible (see AERO).

> rather than some part of a transition mechanism.

Tunneling is about more than just transition. Also useful for mobility, routing
control, security, traffic engineering, etc. regardless of transition or not.

> I honestly have
> never paid any attention to the prospect of using any of the transition schemes within a site; it always seemed to me that they would
> be between a site and its provider.

Just to be clear, I am considering the entire ISP network as a "site" when
I talk about link- and site-scoped multicast. And the tunnel provides a
"link" that spans the site.

> And although I used to be a strong advocate of multicast both in the wide and local networks, its
> use cases have faded to the point where I no longer recommend that anyone make the effort of deploying it.

Well, there are already RFC4795, RFC6762, RFC6763, etc.

Thanks - Fred

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 15 Dec 2014 22:47:13 +0000

> Well, there are already RFC4795, RFC6762, RFC6763, etc.

Probably Bill is referring to routed multicast or worse still, interdomain
multicast (obligatory shudder).  LAN-local multicast is normally fine.

Nick

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 15 Dec 2014 22:53:54 +0000

Hi Nick,

> From: Nick Hilliard [mailto:[email-masked]]
> Sent: Monday, December 15, 2014 2:47 PM
> To: Templin, Fred L; [email-masked]
> Cc: [email-masked]

OK. In this case, however, the "LAN" is the entire ISP network since the tunnel
provides a virtual link over underlying ISP network. So really, LLMNR, mDNS, etc.
would be a link-scoped service over the tunnel but a site-scoped service within
the ISP network.

Thanks - Fred

---

From: Tim Chown <[email-masked]>
Date: Tue, 16 Dec 2014 09:56:56 +0000

> I don't know about that, but it does not hurt to be prepared to accommodate such.

Well, there is Embedded-RP, which is used inter-site. I believe it’s supported around much of the academic/NREN networks. 

Or of course SSM.

But yes, the usage levels are ‘light’.

All our multicast streams used Embedded-RP, even though most are intra-site.

> Please be gentle in providing guidance.

Well yes, top/tail is a personal preference. But let’s discuss multicast...

Tim

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Dec 2014 11:52:12 +0100

Hi,

> I don't know about that, but it does not hurt to be prepared to 

6rd etc. are short-term solutions that will go away as soon as the
infrastructure can support native, and people start turning off IPv4.

So "we need to support something that nobody is using on a migration
technology, just in case someone might want to use it a few years down
the road, when the migration technology is going away anyway" is just
not a convincing argument.

> within the operator network may be useful.

Uh, right.  I'd dearly love to see such an application out in the real
world - there is no application that can "send bulletins via multicast"
today, and if there were, it would not be installed on a customer's
machine by default.

We're not talking about niche markets where multicast is deployed today,
like "financial industry in a very controlled environment" but about
areas where 6rd is used - which is "out in the wild Internet".  Different
world.  No multicast there, no multicast capable applications, no use
case.

(TV streaming is a valid use case and uses multicast, but that's normally
done inside the Telco's network, so they will ensure that whatever 
technology they use to provide IPv6 will nicely live side by side with
whatever technology they use to provide their TV offerings)

> Please be gentle in providing guidance.

Would that work?

Gert Doering
        -- NetMaster

---

From: Bill Owens <[email-masked]>
Date: Tue, 16 Dec 2014 07:52:30 -0500

> Well, there is Embedded-RP, which is used inter-site. I believe it’s supported around much of the academic/NREN networks. 

"Supported" in the sense that the configuration is in place and if you want to use it nobody will stop you, yes. And "networks" being backbones for the most part, along with a very small list of end sites. But "supported" as in "considered a production grade service that is documented, monitored and actively tested, with technical staff able to assist with deployment and troubleshooting"? No, I don't think so. And this isn't a situation that makes me happy; I would rather see people using native multicast where it is appropriate, but I think it is clear that in the wide-area, interdomain case that will not happen.
 
Bill.

---

From: Bill Owens <[email-masked]>
Date: Tue, 16 Dec 2014 07:57:20 -0500

> would be a link-scoped service over the tunnel but a site-scoped service within

What's the use case for LLMNR or mDNS over an ISP network? You want to be able to do DNS lookups or service discovery for services that the ISP offers, but that they don't want to configure into conventional DNS? You want people to be able to see each others' LAN devices (probably not!) If the tunnel is spanning an ISP and linking two sites that belong to the same administrative domain, I could see a desire for it to carry multicast, but that's also a scenario in which I think it is very likely that the user would want a manually-configured and probably encrypted tunnel rather than an automatically generated one. What am I missing?

Bill.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Dec 2014 16:09:30 +0000

Hi Gert,

> From: Gert Doering [mailto:[email-masked]]
> Sent: Tuesday, December 16, 2014 2:52 AM
> To: Templin, Fred L
> Cc: Gert Doering; Tariq Saraj; [email-masked]
> Subject: Re: IPv6 multicast and tunnels (RE: [v6ops] v6ops Digest, Vol 52, Issue 41)
> 
> Hi,
> 

I am not talking about extending 6rd, but rather about a long-term solution
that addresses much more than just IPv6-over-IPv4 transition.

> not a convincing argument.

It is not only about migration.

> today, and if there were, it would not be installed on a customer's

Link- and/or site-scoped multicast are useful.

> world.  No multicast there, no multicast capable applications, no use

I thought 6rd was within an operator network, and not "out in the wild
Internet"? But again, I am not restricting to that one specific use case;
I want one tunneling solution that applies everywhere and for uses more
than just transition. And, multicast support is a part of that.

> whatever technology they use to provide their TV offerings)

Any link- or site-scoped multicast is a valid use case, keeping an open mind
about possibilities.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Dec 2014 16:22:36 +0000

Hi Bill,

> Sent: Tuesday, December 16, 2014 4:57 AM
> To: Templin, Fred L
> Cc: Nick Hilliard; [email-masked]
> What's the use case for LLMNR or mDNS over an ISP network?

The same as for any link.

> You want to be able to do DNS lookups or service discovery for services
> that the ISP offers, but that they don't want to configure into conventional DNS?

I am naming just two examples of link- and site-scoped multicast services.

> You want people to be able to see each others' LAN
> devices (probably not!)

I want people to receive link- and site-scoped multicast services provided
by the ISP, enterprise network or whatever other form of network that
provides a tunneled service.

> If the tunnel is spanning an ISP and linking two sites that belong to the same administrative domain, I could
> see a desire for it to carry multicast, but that's also a scenario in which I think it is very likely that the user would want a manually-
> configured and probably encrypted tunnel rather than an automatically generated one. What am I missing?

The peer-to-peer tunnel setup would be automatically generated based on
a common trust anchor in the provider network. So, if trust anchor A trusts
clients B and C, then B and C have the foundations for trusting one another.
In some environments, just verifying the peer's  source address may be all
that is needed. In other environments, there may be a need for a security
association and encryption. But again, the tunnel is established dynamically
and not manually configured.

Thanks - Fred

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Dec 2014 17:26:27 +0100

Hi,

> Any link- or site-scoped multicast is a valid use case, keeping an open mind

"valid use case" is nice and shiny, but if people don't actually *use* it,
I don't see the issue why one would need to complain that a certain
(temporary) technology doesn't support it.

Please stick to the general topic the thread started with: a complaint from
academia that certain migration technologies have been pushed out into
operations without taking care to support multicast.

Gert Doering
        -- NetMaster

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Dec 2014 16:35:53 +0000

Hi Gert,

> Sent: Tuesday, December 16, 2014 8:26 AM
> To: Templin, Fred L

There is a certain "if we build it, they will come" aspect to this. IPv6 links
should support multicast if possible. And, for tunnels, the underlying
network is the "link".
 
> operations without taking care to support multicast.

Huh? This is v6ops, and we are discussing IPv6 operational considerations.
That being multicast support for IPv6 tunnels in whatever context.

Thanks - Fred

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Dec 2014 17:44:42 +0100

Hi,

On Tue, Dec 16, 2014 at 04:35:53PM +0000, Templin, Fred L wrote:
> There is a certain "if we build it, they will come" aspect to this. 

Yeah, I used to believe that.  10+ years ago, and built a nice and shiny
IPv4 multicast network, with MBGP, MSDP, and you name it.  And got our
upstream providers to support it as well, etc.

Guess what?  It didn't.  Disabled all of it about 3 years ago, because it
was a nuisance to maintain, and the single user had long left.

> IPv6 links

This is a particular model for a tunnel - other tunnels are just plain
point to point.  They could support multicast, but link local multicast
doesn't go very far then ("to the other end") and routed multicast just
doesn't exist out there, except certain niche applications.

From an operational perspective, supporting routed multicast means "being
able to debug user problems", and *this* usually means "look at every single
router on the SPF tree if it doesn't work", and *that* means "it's just
not sustainable if it passes administrative boundaries".

Bang, dead.  Except for niches like stock market delivery (very well 
controlled closed environment) and TV streaming (local to the ISP, very
well controlled environment)...

> That being multicast support for IPv6 tunnels in whatever context.

Yes, totally so.  Just discuss anything in any thread, that really helps
people to follow a discussion.

Gert Doering
        -- NetMaster

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Dec 2014 16:56:14 +0000

Hi Gert,

> Sent: Tuesday, December 16, 2014 8:45 AM
> To: Templin, Fred L

Now you are needing to speak of specific use cases where multicast
is or is not present. And, I know of use cases where multicast traffic
is more prevalent than unicast (and routed multicast in particular).

> doesn't exist out there, except certain niche applications.

I am interested in all domains of applicability.

> well controlled environment)...

You are considering only a very limited class of uses then. I am looking
at the bigger picture - one solution that fits all uses. While at the same
time providing support for a service that can be turned on at a later
time if it is not currently being used.

> people to follow a discussion.

Right, so let's then say we are discussion multicast support for IPv6 tunnels
wherever they happen to be deployed. And, we have one solution that fits
all use cases.

Thanks - Fred

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 16 Dec 2014 16:58:35 +0000

> was a nuisance to maintain, and the single user had long left.

I just canned inter-domain multicast on INEX yesterday.  Good times.

Nick