Joining to SSM sources that are IPv6 mobile nodes

["Dave Thaler" <dthaler@windows.microsoft.com>]

Sorry for the cross-post, but this issue really does concern 
interactions between drafts in three different WGs:
MobileIP: draft-ietf-mobileip-ipv6-14.txt, section 10.19
MAGMA: draft-vida-mld-v2-01.txt
SSM: draft-ietf-ssm-overview-01.txt
(Please trim the recipients when responding, if appropriate.)

Starting from the Mobile IPv6 spec:
> A mobile node that wishes to send packets to a multicast group
> also has two options:  (1) send directly on the foreign link being
> visited; or (2) send via a tunnel to its home agent.  Because
> multicast routing in general depends upon the Source Address used in
> the IPv6 header of the multicast packet, a mobile node that tunnels a
> multicast packet to its home agent MUST use its home address as the
> IPv6 Source Address of the inner multicast packet.

The issue is how to continue getting data to receivers after a mobile
node moves.
Method (2) works fine for SSM, but has the obvious inefficiency.
Method (1) does not work as is for SSM.

I'll assume the sender has advertised (HA,G) in whatever method (e.g. a
web page) he uses to announce the session, just like the session would
advertise HA in any method used to get unicast clients to connect to
him.  (The sender could just as well use (COA,G) but the same issues
arise if it subsequently moves, from my understanding.)

In the SSM model, when receivers join (HA,G) via MLDv2, join state is
constructed along the path to HA (i.e. hitting the home agent).  Any
data sent directly on the foreign link being visited will go nowhere,
since there is no join state there.

A bad answer would be "do nothing, we don't care if sourcing SSM is
broken".

A simple answer would be "an SSM source MUST use option (2), i.e.
tunnel packets to the home agent".  In this case, either option (1)
would never be used for any multicast traffic, or else the host would
have to know whether a receiver might want to use an include-mode list
with MLDv2 and tunnel to the home agent if so.  Personally, I don't
like this answer, but if this is what the consensus turns out to be,
then it should be documented in the Mobile IPv6 spec (no effect on the
SSM or MAGMA WGs), and apis to inform the mobile node stack that it
MUST tunnel to the home agent may be required.

Another answer, which would require adding rules to both the Mobile
IPv6 and MLDv2 specs (and probably mentioning it in the SSM overview
doc), would be to make method (1) work for SSM sources.  A potential
solution here is twofold: 

1) If an MLDv2 host is sending an include-mode report for a source X,
and a binding cache entry exists for X with a care-of-address COA, then
put both X and COA in the membership report.  (This means that if you
can somehow get a Binding Update to all the group members, then they'll
be able to receive packets sourced from COA, since routers will
construct join state back to the foreign link.)  It needs to join to
both addresses so that if the node moves again, it won't be stuck
waiting for data from the old COA.

2) A mobile node sourcing traffic when away from home needs to get a
Binding Update to all the group members.  I believe this can be done by
tunneling a packet via the home agent (and hence must have a source
address of its home address) which contains a Binding Update with
an Alternate Care-of Address of its current COA.  This would need to be
done periodically, so that new receivers get it.

Comments?  Am I missing anything?

-Dave Thaler