Hello,
grey area (deliberately). The main problem seems to be that you don't have a
valid IP(v6) address. This is on many implementations not different for IPv4:
1 or N micro BFD sessions must be Up before the LAG is declared Up in layer-2
and only then layer-3 and the IP address is activated.
This is why the destination MAC is defined, it allows to accept the BFD
packets while ignoring (at this stage) the IP address.
Relying on the defined destination MAC may also solve your DAD problem.
> 2a) Can destination IPv6 address be set to loopback ::1/128 ?
RFC 4291 ("IP Version 6 Addressing Architecture") states:
2.5.3. The Loopback Address
The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
It may be used by a node to send an IPv6 packet to itself. It must
not be assigned to any physical interface. It is treated as having
Link-Local scope, and may be thought of as the Link-Local unicast
address of a virtual interface (typically called the "loopback
interface") to an imaginary link that goes nowhere.
The loopback address must not be used as the source address in IPv6
packets that are sent outside of a single node. An IPv6 packet with
a destination address of loopback must never be sent outside of a
single node and must never be forwarded by an IPv6 router. A packet
received on an interface with a destination address of loopback must
be dropped.
Unless you find another RFC stating the opposite (quite possible ;-) you
cannot send a packet with ::1 as destination address onto a wire.
> 2b) Should destination address mandatorily be a global unicast address
> configured on peer interface?
The RFC 7130 says:
Control packets use a destination IP address that is configured on
the peer system and can be reached via the LAG interface.
Implementations may range from explicitly configuring IP addresses
for the BFD sessions to out-of-band methods for learning the
destination IP address. The details are outside the scope of this
document.
The "on peer interface" in your "2b" question is a bit too strict; an
unnumbered LAG "borrowing" from a loopback interface should be supported
too. But the "[...] address configured" comes close to the intention from
authors/implementors/users.
So practically the assumption is one side knows the IP address of the other
side upfront and uses it. Remember, this is before an IGP can even detect the
other side. I would not rule out link-local addresses assigned by a central
controller but again the micro BFD sessions would learn the IP of the peer
upfront, from the controller.
Regards, Marc
On Wed, 3 May 2017 16:30:42 +0530, arch 25 wrote:
> Hello WG,
>
> Problem Statement:
> ===============
> IPv6 DAD detection prevents bringing up of BFD-over-LAG session.
>
> Description:
> ========
> If BFD-over-LAG feature with IPv6 address family is provisioned on LAG
> interface before the aggregated member link is active, BFD session fails to
> come UP, since IPv6 global unicast address remains invalid as DAD detection
> is not triggered on LAG interface.
>
> I have few clarifications on RFC7130 to address this issue.
>
> 1) Can the BFD packet sent to UDP port 6784 with a source IPv6 address set
> to 0::0 ?
> 2a) Can destination IPv6 address be set to loopback ::1/128 ?
> 2b) Should destination address mandatorily be a global unicast address
> configured on peer interface?
>
>
> Thanks & Regards
>
>
