Subject: (ngtrans) 6to4 multicast comments

From: Pekka Savola <[email-masked]>
Date: Thu, 11 Jul 2002 12:02:52 +0300 (EEST)

Hello,

This is the first time I read 6to4 multicast draft, so beware.

The big picture:

 1) I think we need to identify which kind of IPv6 multicast we want to 
support over 6to4.  Does 6to4 have to be able receive multicast 
trasmissions?  Or send multicast transmissions too?  

If we could limit the applicability to the former, the required complexity
would be reduced.  6to4 _is_ only a transtionary mechanism after all, and
IPv4 multicast is not all that commonplace either.

 2) It needs to be much, much more plainly laid out (e.g. a new section)  
how this changes the 6to4 model of operation.  The changes are
significant, IMO.  For example, multicast traffic between two 6to4 nodes
is sent through a relay; and the multicast from IPv6-native does not go to
the closest relay to the IPv6-native, but across IPv6 infrastructure and
IPv6 multicast routing to the "home" relay (except if MLD tricks are 
used).

 3) One should list the requirements for this to work.  This includes IPv6
multicast support in all relays, in all the other IPv6 infrastrucure etc.,
I think.

 4) Would restricting to Source-Specific Multicast help any?  There is no
MSDP for IPv6 (and possibly never will), and it's unlikely that the whole
world is going to use only one RP.

 5) There needs to be a "walk-through" section for:

1) 6to4 site sends multicast, recipients in IPv6-native
2) 6to4 site sends multicast, recipients possibly also in 6to4
 b) under different relays
3) IPv6-native sends multicast, recipients (also) in 6to4
 b) under different relays
 
It's difficult to get the picture of what's really going on under all of 
these circumstances (there are more.. :-) without a short summary "big 
picture" section.

 6) (In conclusion, after writing this message): I think we should focus
on "only multicast recipients on 6to4 sites" -- that at least _seems_ to
be a much simpler case than the general solution and I think would satisfy
the vast majority of users' needs.

1.  Abstract

6to4 Tunneling allows isolated IPv6 domains or hosts, attached to
an IPv4 network which has no native IPv6 support, to communicate
with other such IPv6 domains or hosts with minimal manual
configuration.

==> s/other such IPv6 domains or hosts/other IPv6 nodes/ ?
[same with Introduction]

(The wording above, especially 'such', could be be read to imply only
6to4 <-> 6to4 traffic)

Unlike [6OVER4], 6to4 does not assume the general availability of
wide-area IPv4 multicast.   The 6to4 mechanism assumes only
unicast capability in its underlying IPv4 carrier network.

==> One should be careful with the word 'carrier' network.  Does this also
include the network between 6to4 relays?  If it simplified the techniques,
I think it might be OK to require that 6to4 relays are IPv4 multicast
-capable.

3.  Overview

We assume each 6to4 gateway points an IPv6 default route at a     
particular relay reachable across the IPv4 infrastructure.  Each  
relay, plus the set of all gateways (perhaps unknown to the relay)
using the relay, together can be thought of as being on a separate
NBMA link.

==> I think you're implicitly discarding one traditional 6to4 case (which
does not apply directly to this proposal) here: when native IPv6 nodes
send traffic to 6to4 nodes, they use a closest relay.

                                       This requires the 6to4 relay
to keep state for each gateway which has joined a particular
group.  

==> Not only that but all 6to4 relays be aware of all the states of all 
the other relays (6to4 <-> 6to4 traffic), unless I'm mistaken.  

          IPv6 multicast packets from the IPv6 native infrastructure
behind the relay will be sent to each gateway which has requested 
them. 

==> This implicitly requires that every 6to4 relay is capable of IPv6
multicast, and has IPv6 multicast "connection" to every 6to4 relay and
every native-IPv6 node which would transmit traffic (ie. all native IPv6
routers between them support IPv6 multicast and have IPv6 multicast
routing enabled).

These are huge assumptions, looking at the availability of IPv4 multicast 
today.

                                            Since a 6to4 gateway
may be a host, and hosts typically do not implement routing
protocols, gateways will use MLD as described in Section 4 below.

==> My worry is whether this kind of MLD proxying by _routers_ break 
assumptions made when specifying MLD.

 When a relay receives a multicast packet via 6to4 encapsulation,
it applies a Reverse-Path Forwarding check by dropping it unless
the source address is a 6to4 address.  If it is not dropped, the
packet is forwarded to all other 6to4 gateways which have
requested it, in addition to being forwarded out any native IPv6
interfaces according to the rules of the multicast routing
protocol(s) running on the relay.

==> The wording should be improved.  When ... If.. -- what should be done 
in the case that a relay receives a multicast packet not via 6to4 
encapsulation -- does the If sentence apply.  If so, 'all _other_ 6to4 
gateways' (underlining mine) does not match.

The IPv6 source address of MLD reports sent to a 6to4 relay MUST 
be a link-local address formed as specified in Section 3.7 of    

==> You're making an assumption that a link-local address, as specified 
with 'would be formed' in RFC3056 3.1, would actually be generated.  Many 
implementations don't generate link-local addresses for 6to4.

However, sending periodic MLD Reports to an anycast address can
cause duplicates.  Specifically, if routing changes such that a
different relay receives a periodic MLD Report, both the new and
old relays will encapsulate data to the 6to4 site until the old 
relay's state times out.  This is obviously undesirable.

==> This is undesirable, yes, but I'm not sure if that's really all that
big a deal.  If the routing changes so that one if preferred to another --
who cares?  The user just receives double trasmission for a while, and the
traffic soon switches to a "better" relay. However if the two paths become
equal-cost and there is load balancing, or there is route flapping, this
may be undesirable.

                                         The recommended procedure
is that a gateway having an anycast address of a relay should send
an ICMPv4 Echo Request to the anycast address, and that relays
should respond with an Echo Reply from their unicast address  
(since anycast addresses should not be used as source addresses).

==> There is no requirement that _IPv4_ anycast addresses should not be 
used as source addresses AFAIK.  The 6to4 anycast relay we maintain does 
not change it, and I have no inclination to change that, at least.

6.  Supporting Multiple Relays in the Presence of RPF

The 6to4 gateway must keep state per relay from which an MLD 
Report has been sent, and in addition to forwarding multicast
traffic from the site to its relay of choice, traffic is also
forwarded to all relays from which Reports have been received.

==> so if there are 100 relays, the traffic could be unicast-tunneled to 
100 different relays?

7.  Supporting Site-Site Multicast
[...]
We note that this can result in a significant amount of state at a
site gateway sourcing multicast to a large number of other 6to4   
sites.  However, it is expected that this is not unreasonable for 
two reasons.  First, the 6to4 most likely does not have native    
multicast connectivity (or else it could use 6over4 instead), [...]

==> assumption that if there is multicast, 6over4 would probably be used 
is invalid.

8.  Security Considerations

The same security considerations and solutions discussed in [6TO4]
apply to multicast traffic.

==> No, the solutions in [6TO4] are inadequate to address this.

6to4 + multicast requires that relays and gateways send and receive
different kinds of packets, including link-locals (like MLD).  These can
easily be forged.  There needs to be much more analysis on what kind of
traffic is generated and how to protect against abuse.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords