Re: Questions related to single-hop IP BFD over IPv6

Jeffrey Haas <jhaas@pfrc.org> Thu, 25 May 2017 14:56 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B279A129432 for <rtg-bfd@ietfa.amsl.com>; Thu, 25 May 2017 07:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.503
X-Spam-Level:
X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yIBdIyUqG8D for <rtg-bfd@ietfa.amsl.com>; Thu, 25 May 2017 07:56:46 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CF1481200FC for <rtg-bfd@ietf.org>; Thu, 25 May 2017 07:56:46 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 7A27C1E37B; Thu, 25 May 2017 11:04:54 -0400 (EDT)
Date: Thu, 25 May 2017 11:04:54 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: "dkatz@juniper.net" <dkatz@juniper.net>, David Ward <dward@cisco.com>, Shigang Wang <Shigang.Wang@ecitele.com>, Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>, Natalie Rogozovsky <Natalie.Rogozovsky@ecitele.com>, James Lian <James.Lian@ecitele.com>, BFD WG <rtg-bfd@ietf.org>, Alexander Ferdman <Alexander.Ferdman@ecitele.com>
Subject: Re: Questions related to single-hop IP BFD over IPv6
Message-ID: <20170525150454.GA19117@pfrc.org>
References: <AM4PR03MB17134BD800C0E072C4ECE6249DE40@AM4PR03MB1713.eurprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <AM4PR03MB17134BD800C0E072C4ECE6249DE40@AM4PR03MB1713.eurprd03.prod.outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/r99dxBVsWzOTvY-ti1G-clGUT5U>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 May 2017 14:56:49 -0000

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