Section 5.6.1: Use of IPv6 DAD with UDLR <next rev of draft-ietf-ipdvb-ar-03.txt>

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

Following the issues you raised on the use of DAD for Ipv6 when using UDLR,
The authors propose adding the following amendment to the next rev of
draft-ietf-ipdvb-ar-03.txt.

Does this seem to capture the issues that you describe?
- Comments please to the ipdvb mailing list.
- Other comments welcome.

Best wishes,

Gorry Fairhurst.

----

* A new subsection will be added to the end of section 5.6:

5.6.1 Multicast/Broadcast addressing for UDLR

UDLR is a layer 2 solution, in which a Receiver may send multicast/broadcast
frames that are subsequently forwarded natively by a Feed Router (using the
topology in figure 2), and are finally received at the feed interface of the
originating Receiver.  This multicast forwarding does not include the normal
L3 Reverse Path Forwarding (RPF) check or L2 spanning tree checks, the
processing of the IP Time To Live (TTL) field, or the filtering of
administratively scoped multicast addresses. This raises a need to carefully
consider multicast support [. RFC3077 notes that a Receiver needs to be
configured to discard these received packets.

When the encapsulation includes an NPA/MAC source address, such packets may
be filtered at the link-layer using a filter that discards L2 addresses that
are local to the Receiver. In some circumstances, systems can send packets
with an unknown (all zero) MAC source address (e.g. IGMP Proxy Queriers
[RFC-IGMP-Proxy]), where the source at L2 can not be determined at the
Receiver, these packets need to be silently discarded, which may prevent
running the associated services on the Receiver.

Some encapsulations do not include an NPA/MAC source address (Table 2).
Multicast packets may therefore alternatively be discarded at the IP layer
if their IP source address matches a local IP address (or address range).
Systems can send packets with an all zero IP source address (e.g. BOOTP
[RFC951], DHCP [RFC2131] and ND [RFC2461]), where the source at L3 can not
be determined at the Receiver these packets need to be silently discarded.
This may prevent running the associated services at a Receiver, e.g.
participation in IPv6 Duplicate Address Detection, or running a DHCP server.


* Some other minor updates to other sections will also aim to make this
issue clearer.