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

Tom Taylor <> Wed, 08 July 2015 23:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 71E091A19F8 for <>; Wed, 8 Jul 2015 16:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t0etpVzQhDsB for <>; Wed, 8 Jul 2015 16:10:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B21C11A0046 for <>; Wed, 8 Jul 2015 16:10:45 -0700 (PDT)
Received: by iecuq6 with SMTP id uq6so165930866iec.2 for <>; Wed, 08 Jul 2015 16:10:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=4S1AvlU9Y4acmsZArj/TVbtzxrCshNnCpqlavnHAkxg=; b=e4zau30r3whIXuKh+3laBZxjBEKIZ/nimuIbAj3/wc6f1JglbeqKRAJ8NoMqATqj8b b3IqdU3oXgsIXQ7A1I0L/3D3bqYmU0Qa9gsRpCOyCaGCQuszm8F3aki7hIfYPL3jKgmi D5IOu+n64xc124AKVs40Ed344jgfn7Mw7QixAm8YraDcoLjvhokp0aOo68t9YVIUczwb YsaU/oE4aJ+qLfQ91NxyA19ekrRbHK93rUNLEHlnHA7GWCtMJ2rQvoWhbA7V/m8azdEW p2FLl8VbJ23CtgF5RQjFK9eU9+c7uy5YxgGqf1vB+FEExJaGFGuJRynz3Sf/sve1QM/o jOng==
X-Received: by with SMTP id n8mr8847881igd.21.1436397045118; Wed, 08 Jul 2015 16:10:45 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id 76sm2881006iom.12.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2015 16:10:44 -0700 (PDT)
To: "Fred Baker (fred)" <>, Erik Kline <>
References: <> <> <> <> <>
From: Tom Taylor <>
Message-ID: <>
Date: Wed, 8 Jul 2015 19:10:42 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
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 23:10:47 -0000

On 08/07/2015 2:39 PM, Fred Baker (fred) wrote:
>> 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 :-)

We have both SYSLOG and IPFIX drafts in progress for NATs. They've been 
held up waiting for the NAT MIB to be finished. (The latter is now in 
the RFCEd Q.) We could look at adding these logs if you want, subject to 
your requirements.

Tom Taylor
> _______________________________________________
> v6ops mailing list