Re: [IPFIX] ipNextHopIPv6Address reported address

Brian Trammell <ietf@trammell.ch> Thu, 04 June 2015 13:57 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43261B34D4 for <ipfix@ietfa.amsl.com>; Thu, 4 Jun 2015 06:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_SUBJ_BRKN_WORDNUMS=0.01] autolearn=ham
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 9klHG-QGPxSW for <ipfix@ietfa.amsl.com>; Thu, 4 Jun 2015 06:57:26 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDD21B34FB for <ipfix@ietf.org>; Thu, 4 Jun 2015 06:47:22 -0700 (PDT)
Received: from [IPv6:2001:67c:10ec:52c8:8000::e9e] (unknown [IPv6:2001:67c:10ec:52c8:8000::e9e]) by trammell.ch (Postfix) with ESMTPSA id 497201A0302; Thu, 4 Jun 2015 15:47:21 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed; boundary="Apple-Mail=_58534407-8080-4E58-8A79-2EC8DB3A6BA2"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5b6
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <1433416039.22978.70.camel@brocade.com>
Date: Thu, 04 Jun 2015 15:47:21 +0200
Message-Id: <F8E56235-E3CD-433F-859E-616EA7124C19@trammell.ch>
References: <1433416039.22978.70.camel@brocade.com>
To: Nick Brown <brownn@Brocade.com>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipfix/0E3vOEKyfVhn9izpHCTxlCRb560>
Cc: Luca Boccassi <lboccass@Brocade.com>, Doug Gordon <dgordon@Brocade.com>, Derek Fawcus <dfawcus@Brocade.com>, "ipfix@ietf.org" <ipfix@ietf.org>, Paul Atkins <patkins@Brocade.com>
Subject: Re: [IPFIX] ipNextHopIPv6Address reported address
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix/>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2015 13:57:29 -0000

> On 04 Jun 2015, at 13:07, Nick Brown <brownn@Brocade.com> wrote:
> 
> Hi All,
> 
> In a sentence, is it expected that ipNextHopIPv6Address should report
> the global ipv6 address of the next hop when it has one, or may the link
> local address be reported instead?
> http://tools.ietf.org/html/rfc5102#section-5.7.3

First, the proper reference for the definitions of IEs in the IPFIX information model is http://www.iana.org/assignments/ipfix/ipfix.xhtml; per 7012, 5102 is no longer considered authoritative for IE definitions.

(In this case, though, this is an admittedly pedantic distinction; the content is identical).

> There are obvious cases where the next hop may only have link local
> address, if example it's only configured that way. But in other cases
> where it may have both a link local and global address it's often the
> case that routing protocols may use local addresses to setup the
> forwarding plane where traffic is being observed. Thus at the point in
> the forwarding path that traffic is being observed this all that is
> available, and it's not apparent that a mapping from link local address
> to global address (where is exists) can be done.

The way I read this, if the address is not being changed as part of the packet handing (on which see the fifth point in section 2.3 of RFC 7012), the address to report is the address the packets are sent to in the context of the egress interface. If the connection between the device the MP is on and the next hop has link-local addresses only, then the link-local address is the correct one to export.

Cheers,

Brian