Thanks Tina,
I'm forwarding this to the ipdvb list, although the context of your
email was DVB/S.2 (i.e. GSE) the issues you raise seem to be more
generic to the use of multicast with UDLR, and I think should be
discussed on this list and addressed in the chartered work on
address-resolution,
i.e. in a revision to:
draft-ietf-ipdvb-ar-03.txt
Thoughts?
Gorry
Tina Strauf wrote:
> Dear Gorry,
>
> I am very sorry, this took so long. But as promised in the following I
> will try to summarize the results on the problem of GSE and IPv6 DAD we
> discussed at DVB-GBS during the meeting we had on May 9th/10th.
>
> 1) Scenario:
>
> A DVB-S2 (terminal/set-top-box) receives regular (unicast) downstream
> IP traffic via DVB-S2. The return-channel is similarly unidirectional
> and configured in such a way, that downlink and return link "emulate"
> one bidirectional link with only one link-layer and respectively
> IP-layer interface on each side. This can be achieved i.e. by
> implementing RFC 3077.
>
> 2) Problem Statement:
>
> 2.1 General
>
> A terminal sending out multicast packets to a group it is itself a
> member of will also receive those packets (back) again, because on the
> link layer they travel to the router/switch/tunnel-endpoint, where both
> the forward and return link are "fused" together, and are then relayed
> down the DVB-S2 link (to possibly reach other receivers on the same
> emulated link). Without a unique link-layer or IP-Layer source address
> in the headers the terminal has then no way of knowing if the packets
> were sent by itself or some other node.
>
> 2.2 In particular with regard to IPv6 DAD
>
> When performing IPv6 Duplicate Address Detection, a node sends out a
> Neighbor Solicitation Message to the solicited node multicast address
> for the address it wishes to configure. At this point this node itself
> is also part of that multicast group and in our scenario receives its
> own Neighbor Solicitation back again without being able to tell that
the
> message was the one it itself sent out (the IPv6 source address is the
> unspecified address and a link-layer source address is not present in
> the GSE header, if the original link-layer packet is not bridged (How
> would the encapsulator know, when to bridge packets and when not?).
> Regardless, we might not even know yet that the link-layer address is
> unique (on the link) either, so the problem exists with or without
> link-layer source field in the GSE header.
> RFC 2462 actually mentions this problem and also offers the following
> "advice":
>
> Implementor's Note: many interfaces provide a way for upper
layers to
> selectively enable and disable the looping back of multicast
packets.
> The details of how such a facility is implemented may prevent
> Duplicate Address Detection from working correctly. See the
Appendix
> for further discussion. [not quoted here]
>
> The following tests identify conditions under which a tentative
> address is not unique:
>
> - If a Neighbor Solicitation for a tentative address is
> received prior to having sent one, the tentative address is a
> duplicate. This condition occurs when two nodes run Duplicate
> Address Detection simultaneously, but transmit initial
> solicitations at different times (e.g., by selecting different
> random delay values before transmitting an initial
> solicitation).
>
> - If the actual number of Neighbor Solicitations received exceeds
> the number expected based on the loopback semantics (e.g., the
> interface does not loopback packet, yet one or more
> solicitations was received), the tentative address is a
> duplicate. This condition occurs when two nodes run Duplicate
> Address Detection simultaneously and transmit solicitations at
> roughly the same time.
>
> So, if the receiver is implemented in such a way, that it counts sent
> and received solicitations, compares the number and concludes that the
> address is unique, if the same number was messages sent out as was
> received, there only is a problem in case a message was lost or if two
> receivers perform DAD for the same address at more or less the exact
> same time.
>
> 3. "Results of Discussion"
>
> - For GBS the problem is particular to this scenario for integration of
> DVB downlinks into an IPv6 network, meaning this particular
> implementation of the return link.
> - The problem is exactly the same with MPE and ULE.
> - The problem is actually neither specific to GSE nor ULE or MPE but in
> general exists in all cases in which looped back multicast packets
> cannot be prevented/recognized by a network node. (Develop "IPv6 over
> ***" for such a case?).
> - A mandatory GSE link-layer source address field would only help, if
> the link-layer ID was 100% sure to be unique on the link. In that case
> it would not only solve the DAD problem but the general problem of
> recognizing looped back MC packets.
>
> 4. Conclusion
>
> - No change to GSE will be made
> - because the problem isn't really solved just with the address
> field present, if we can't be absolutely sure that the ll-ID is unique
> (link-layer dependent operational issue).
> - because the problem is the same with ULE/MPE
> - because we need GSE now!
> - When/If IPDVB develops a solution for ULE, it can be adopted for GSE
> as well.
> - The issue might be mentioned in an informational annex of the GSE
spec.
>
> Please feel free to forward this e-mail to IPDVB on behalf of DVB
> TM-GBS. Comments are of course welcome.
>
> Best Regards,
>
> Tina Strauf (on behalf of DVB TM-GBS)
>
>
> --
> Tina Strauf
> Institut für Nachrichtentechnik
> Technische Universität Braunschweig
> (Institute for Communications Technology
> Braunschweig Technical University)
>
> Fon: +49 531 391 2417
> Fax: +49 531 391 5192
> E-Mail: strauf@ifn.ing.tu-bs.de
>
> Schleinitzstraße 22
> D-38106 Braunschweig
>