(ngtrans) Re: Multicast in 6to4?

[Brian E Carpenter <[e-mail]>]

Erik,

I would like someone wiser than me to suggest a response to your
multicast issues.

Re "pseudo-interface", we added the "pseudo" because some
implementors didn't like plain "interface". Personally I agree
with you.

  Brian

Erik Nordmark wrote:
> 
> 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

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM Internet Div
On assignment for IBM at http://www.iCAIR.org 
Non-IBM email: [e-mail]