(ngtrans) Multicast in 6to4?

Erik Nordmark <Erik.Nordmark@eng.sun.com> Wed, 13 October 1999 22:34 UTC

Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05464 for <ngtrans-archive@odin.ietf.org>; Wed, 13 Oct 1999 18:34:42 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA25133; Wed, 13 Oct 1999 15:31:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA14263; Wed, 13 Oct 1999 15:29:45 -0700 (PDT)
Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d9DMRNg17949 for ngtrans-dist; Wed, 13 Oct 1999 15:27:23 -0700 (PDT)
Received: from sunmail1.Sun.COM (sunmail1.Corp.Sun.COM [129.145.1.2]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d9DMR1R17920 for <ngtrans@sunroof.eng.sun.com>; Wed, 13 Oct 1999 15:27:02 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL, v1.6.1-sunmail1) with ESMTP id AAA07210 for <ngtrans@sunroof.eng.sun.com>; Wed, 13 Oct 1999 00:02:11 -0700 (PDT)
Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA188190; Tue, 12 Oct 1999 22:09:47 -0700 (PDT)
Date: Tue, 12 Oct 1999 22:07:20 -0700
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: (ngtrans) Multicast in 6to4?
To: Brian E Carpenter <brian@hursley.ibm.com>, Keith Moore <moore@cs.utk.edu>
Cc: ngtrans@sunroof.eng.sun.com
Message-ID: <Roam.SIMC.2.0.6.939791240.31032.nordmark@jurassic>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET="US-ASCII"
Sender: owner-ngtrans@sunroof.eng.sun.com
Precedence: bulk
Reply-To: Erik Nordmark <Erik.Nordmark@eng.sun.com>

I'm trying to understand how multicast will work in 6to4 in practise i.e.
how much manual configuration is needed and how scalable things will be.

Take multicast in the simple example in section 5.1.
If a node in site A sends a packet to ff0e:Y with a source of 2002:c001:0203:X
how will A's 6to4 router know where to forward the packet?
In general this seems to imply that PIM(v6) on that router have a router
adjacency with all 6to4 routers on the planet. This appears to be true
for PIM dense mode, since it needs to do flood and prune to
all multicast router neighbors over the IPv4 link layer.
(I'm not sure about PIM sparse mode; please consult with some PIM experts on 
how to run PIM over the large cloud IPv4 link layer.)
Section 6 doesn't say whether PIM is restricted to just sparse mode, dense
mode, or both. Is the intent to restrict it?

Another issue is reception of multicast in a site with multiple 6to4 routers.
As pointed out in section 6 the 6to4 routers need to inject a route for 
2002::/16 for the RPF check to work. This is true - it is a necessary
condition. But is it not sufficient. When there are multiple 6to4 routers
injecting the 2002::/16 prefix the RPF check requires that the packets arrive
from the closest 6to4 router i.e. all 6to4 routers have to transmit all
multicast packets into the site (or there has to be some way to elect one 6to4
router as the only one to forward multicast packets into the site.)
I think draft-thaler-multicast-interop-03.txt outlines some of
the issues in gluing together multiple multicast routing domains.

Finally, a non-multicast terminology nit.
The document uses the undefined term "pseudo-interface" but the term
"interface" defined in RFC 2460 seems to have the intended meaning:
   link        - a communication facility or medium over which nodes can
                 communicate at the link layer, i.e., the layer
                 immediately below IPv6.  Examples are Ethernets (simple
                 or bridged); PPP links; X.25, Frame Relay, or ATM
                 networks; and internet (or higher) layer "tunnels",
                 such as tunnels over IPv4 or IPv6 itself.

   interface   - a node's attachment to a link.

I'd suggest either defining "pseudo-interface" or referencing RFC 2460 for
terminology.

   Erik