[IPFIX] ipNextHopIPv6Address reported address

Nick Brown <brownn@Brocade.com> Thu, 04 June 2015 11:07 UTC

Return-Path: <brownn@Brocade.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8230A1A0117 for <ipfix@ietfa.amsl.com>; Thu, 4 Jun 2015 04:07:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tks1p23wUsQJ for <ipfix@ietfa.amsl.com>; Thu, 4 Jun 2015 04:07:38 -0700 (PDT)
Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7123B1A010E for <ipfix@ietf.org>; Thu, 4 Jun 2015 04:07:38 -0700 (PDT)
Received: from pps.filterd (m0000700.ppops.net []) by mx0b-000f0801.pphosted.com (8.14.7/8.14.7) with SMTP id t54AUwjL006547 for <ipfix@ietf.org>; Thu, 4 Jun 2015 04:07:37 -0700
Received: from brmwp-exchub02.corp.brocade.com ([]) by mx0b-000f0801.pphosted.com with ESMTP id 1ute3h8q3t-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <ipfix@ietf.org>; Thu, 04 Jun 2015 04:07:37 -0700
Received: from BRMWP-EXMB12.corp.brocade.com ( by BRMWP-EXCHUB02.corp.brocade.com ( with Microsoft SMTP Server (TLS) id; Thu, 4 Jun 2015 05:07:21 -0600
Received: from BRMWP-EXMB11.corp.brocade.com ( by BRMWP-EXMB12.corp.brocade.com ( with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 4 Jun 2015 05:07:20 -0600
Received: from BRMWP-EXMB11.corp.brocade.com ([fe80::39a0:e6f2:6a5c:18a9]) by BRMWP-EXMB11.corp.brocade.com ([fe80::39a0:e6f2:6a5c:18a9%23]) with mapi id 15.00.1044.021; Thu, 4 Jun 2015 05:07:20 -0600
From: Nick Brown <brownn@Brocade.com>
To: "ipfix@ietf.org" <ipfix@ietf.org>
Thread-Topic: ipNextHopIPv6Address reported address
Thread-Index: AQHQnrafPB/7xd762E2gLPa3+qr4pQ==
Date: Thu, 4 Jun 2015 11:07:19 +0000
Message-ID: <1433416039.22978.70.camel@brocade.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <173A576CF63CE14CB7A8B9A9A94B172D@brocade.local>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-04_05:2015-06-03,2015-06-04,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1506040135
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipfix/SBYzmpsJI3KjWJ3hl4flx9BqQR0>
X-Mailman-Approved-At: Thu, 04 Jun 2015 05:37:14 -0700
Cc: Luca Boccassi <lboccass@Brocade.com>, Derek Fawcus <dfawcus@Brocade.com>, Paul Atkins <patkins@Brocade.com>, Doug Gordon <dgordon@Brocade.com>
Subject: [IPFIX] ipNextHopIPv6Address reported address
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Nick Brown <brownn@Brocade.com>
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 11:09:24 -0000

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?

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.