Re: [DNSOP] draft-tale-dnsop-edns-clientid

"Peter van Dijk" <> Fri, 31 March 2017 14:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B82981294CF for <>; Fri, 31 Mar 2017 07:14:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2NTRSh7_-ynl for <>; Fri, 31 Mar 2017 07:14:12 -0700 (PDT)
Received: from ( [IPv6:2a01:1b0:202:40::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B8A541294C4 for <>; Fri, 31 Mar 2017 07:14:12 -0700 (PDT)
Received: from [] (unknown [IPv6:2001:610:666:0:4835:5d5f:ecfb:87d3]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by (Postfix) with ESMTPSA id DCB74C1B96; Fri, 31 Mar 2017 16:14:10 +0200 (CEST)
From: Peter van Dijk <>
Date: Fri, 31 Mar 2017 16:14:10 +0200
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <>
Subject: Re: [DNSOP] draft-tale-dnsop-edns-clientid
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 Mar 2017 14:14:16 -0000

On 28 Mar 2017, at 21:56, Barry Raveendran Greene wrote:

>> On Mar 28, 2017, at 12:31 PM, Peter van Dijk 
>> <> wrote:
>> Please note that neither draft handles the use case of also passing 
>> the port number, which in a world of growing CGN deployment, may soon 
>> prove quite important.
> Can you elaborate?

Both drafts (xpf and clientid) allow the resolver to identify the client 
even if the IP header does not provide enough information for it. xpf 
does this for the case of a generic proxy, clientid does it for that 
case plus the case of a CPE that does NAT but can pass on the client’s 
MAC or another token, allowing the resolver to identify the individual 
device at the customer.

However, if the client to such a proxy is itself behind a CGN gateway, 
we may need both client IP + port number to identify the specific 
client. If the proxy only tells us the IP, we just know this might be 
any of a hundred different clients, because we do not have the port 
number that can help us distinguish these clients.

Kind regards,
Peter van Dijk