Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability

"Fred Baker (fred)" <> Wed, 08 July 2015 18:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 49E861A700B for <>; Wed, 8 Jul 2015 11:39:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -114.511
X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UUQroD3HI7A6 for <>; Wed, 8 Jul 2015 11:39:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D31071A700A for <>; Wed, 8 Jul 2015 11:39:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3081; q=dns/txt; s=iport; t=1436380747; x=1437590347; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Q02jG2qXQK8UlaPdnNu1zZR2zZeybDwaMeUW3IWvcQw=; b=W8ak/MUtts6+7OlCzfiYuFV9gCA1lS36UWFBDSYaJGAOKfFbU1r6X4X0 RTqgXZ29fZuthNSeyoxFYIP8IKEElxkNN70j1pZRxW4PcJvZN4ziDqnYU 8OCO7x6gTRW+BeMID5kxiLW64FwLImdduJLMwWuH40kF3b5PJgEWAZzw7 4=;
X-Files: signature.asc : 833
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.15,433,1432598400"; d="asc'?scan'208";a="13738891"
Received: from ([]) by with ESMTP; 08 Jul 2015 18:39:06 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t68Id6o2019836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jul 2015 18:39:06 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 8 Jul 2015 13:39:06 -0500
From: "Fred Baker (fred)" <>
To: Erik Kline <>
Thread-Topic: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability
Thread-Index: AQHQua1ern+gb4bVAkKw0CKjGdvjkg==
Date: Wed, 8 Jul 2015 18:39:06 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_5C28523E-1C96-49B0-BB77-BC7AE21AC6A3"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Jul 2015 18:39:09 -0000

> On Jul 6, 2015, at 7:08 PM, Erik Kline <> wrote:
> Some of this could also serve as input to motivate a SAVI document
> defining a basic logging protocol.
> I still believe that if there where a trivially deployable logging
> methodology that captured
>    {IP address, timestamp, rfc7039#section-3.2 binding context}
> tuples, or even the full data structure entry described in
> rfc6620#section-3.1, then the auditing objectives could be well and
> truly met.
> I think this is still one large unmet need.  (not necessarily a v6ops
> matter, perhaps)

Operational requirements for such could be a v6ops project, and probably a quick one. You're correct that a protocol development probably belongs in a protocol WG. Calling out the binding anchor makes sense, but some of those (the port on an Ethernet switch to which a host attaches, the security association between a host and the base station on wireless links) don't have obvious portable names (if I say that a given security association is number 27 in the AP's table, that's meaningful to the AP, but I'm not sure it's meaningful to an operator coming in after the fact).

I find myself wondering whether this might get rolled up with some other logging operation, such as for stateful NATs. It begins to sound a lot like a record that associates a set of elements together (a 3-tuple or 5-tuple for a session with a MAC Address and a port number and a time stamp, logged only if the source IP address isn't mapped to the MAC address of interest, perhaps) that is emitted for a reason beyond "it was seen".

Would IPFIX, in some incarnation, address this?

I'll let you write that :-)