Subject: Repost: DVB-S2 GSE and IPv6 DAD

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 07 Jun 2006 14:13:51 +0100

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: [email-masked]
 >
 > Schleinitzstraße 22
 > D-38106 Braunschweig
 >

---

From: Fausto Vieira <[email-masked]>
Date: Thu, 08 Jun 2006 11:43:00 +0200

Just a couple of thoughts on this issue...

DaD can be treated as a special case of multicast or a generic multicast 
solution should be able to support DaD.

The most compatible solution would be:
- having source and destination MAC addresses on the encapsulation 
protocol for multicast traffic.
- having source and destination IPv6 addresses on the  encapsulation 
protocol for multicast traffic.
- having a unique MAC address (at least from a upper layers point-of-view)
- having a multicast reflector proxy at the hub.

A more efficient solution would be:
- solving multicast and DaD independently
- having at the hub a proxy agent that would keep records of the DaD 
packets and would reply in the name of the terminals.
- having a module in the terminal that would match sent and received 
multicast packets and emulate the loopback by inserting the source IP 
address.

I don't know if this solves the problem completely.

best  regards

Fausto