[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DVB: [TM-GBS] DVB-S2 GSE and IPv6 DAD
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: strauf@ifn.ing.tu-bs.de
Schleinitzstraße 22
D-38106 Braunschweig