Sasha, On Thu, May 18, 2017 at 02:13:51PM +0000, Alexander Vainshtein wrote: > I have several questions dealing with single-hop IP BFD sessions over IPv6. > So far I have failed to find clear answers to these questions in RFC > 5881<https://tools.ietf.org/html/rfc5881>. > > > 1. Is it possible to use link-local source and destination IPv6 > addresses in encapsulation of single-hop IP BFD Control packets? For the > reference: > > a. Section 4 of RFC 5881 explicitly states that link-local addresses > SHOULD NOT be used in encapsulation of BFD Echo packets, but it does not say > anything about BFD Control packets
In the case of echo, there's no guarantee that the traffic will pass through exactly one end system. It's likely that you *could* do this using link locals with appropriate discipline, but Echo packet contents are out of scope for BFD. For async single-hop sessions, you can do this. The BFD implementation obviously needs to take great care to send and receive on the same interface. Some socket implementations made such things a bit tricky in years past. > > b. OSPFv3 for IPv6 always uses link-local IPv6 addresses as the Next Hop > addresses of the routes it computes (see RFC > 5340<https://tools.ietf.org/html/rfc5340>, Section 4.8.2). Therefore it looks > reasonable to me to use single-hop IPv6 BFD sessions with link-local > addresses at least for monitoring OSPFv3 adjacencies > > 2. Section 3 of RFC 5881 states that "there will be only a single BFD > session between two systems over a given interface (logical or physical) for > a particular protocol". I would like to understand how this requirement can > be addressed in the following scenario: > > a. Let us assume that the answer to the question 1 above is positive. > > b. Let's further assume that: > > i. Router > A and Router B are connected across a single IPv6 hop (an IPv6 link) > > ii. A > single-hop IPv6 BFD session using link-local addresses of the corresponding > interfaces has been successfully established > > iii. > Globally unique IPv6 addresses have been configured on the interfaces > terminating this link in Router A and Router B and have successfully passed > the DAD check, i.e., these addresses are assigned and preferred addresses in > the terminology of RFC 4862<https://tools.ietf.org/html/rfc4862> > > iv. The user > (or some application) now tries to set up a single-hop IPv6 BFD session bound > to the same interfaces but using globally unique IPv6 addresses assigned to > these interfaces FWIW, the implementations I'm familiar with utilize the IP endpoints for the session uniqueness requirements. This means the global addresses would be potentially on a different session than the link locals. > c. Should, under the assumptions above, the implementation prevent > formation of an additional single-hop IPv6 BFD session between A and B > running across the same link but using assigned globally unique IPv6 > addresses of the corresponding interfaces? If yes, how can this be achieved? The difficulty in achieving this is the reason for my comment. One could make a similar observation even in IPv4 when multiple addresses are configured on the same interface. > d. Similar to above, but: > > i. The > interfaces connecting Router A and Router B have been assigned with multiple > globally unique IPv6 addresses > > ii. A > single-hop IPv6 BFD session using one pair of assigned IP addresses of these > interfaces has been successfully established > > iii. Should > the implementation prevent formation of an additional single-hop IPv6 BFD > session between A and B running on the same link but using a different pair > of assigned globally unique IP addresses? If yes, how can this be achieved? Same as the IPv4. I wouldn't expect this. This arguably suggests the requirement in 5881 is excessively strict. -- Jeff
