Subject: Re: DVB: [TM-GBS] DVB-S2 GSE and IPv6 DAD

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 08 Jun 2006 13:08:05 +0100

See comments in-line, and in particular it would be great to capture 
some of this within the AR draft.

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.
 >
OK, that seems reasonable.
> 
> 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, 
 >
Yes! - If UDLR had used L3 forwarding (as in PIM, etc) you'd normally 
expect a multicast RPF check at the feed and receiver;-)

I think this is the case where RFC3077 says:
    "Caution: a receiver which sends an encapsulated
     broadcast/multicast packet to a default feed will receive
     its own packet via the unidirectional link.  Correct
     filtering as described in [RFC1112] must be applied."

The reference to RFC1112 seems to be to section 7.2 which says:
   "An incoming
    datagram with an IP host group address in its source address field is
    quietly discarded."

> 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.
 >
Indeed (unless perhaps a Receiver understood the routing topology and 
hence the significance of the L3 source address as in RFC1112).

> 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, 
 >
If you're suggesting that the 6 byte MAC/NPA address could be 
non-unique, then this seems a configuration error that violates the L2 
architecture in general. If this is so, several things may break, not 
just the ND protocol.

> 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.
> 
Seems so.

> 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.
Yes.

> - 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.
> 
There is always an option to choose to use IEEE-assigned addresses and 
bridging mode.

> 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
 >
Yes, although we SHOULD document it in the AR document, perhaps we can 
work together on a few extra paragraphs.

>     - because we need GSE now!
> - When/If IPDVB develops a solution for ULE, it can be adopted for GSE
> as well.
 >
Yes :-)

> - The issue might be mentioned in an informational annex of the GSE spec.
> 
Or/and you could cite RFCxxxx on AR (when it is published).

> 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
>