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

Erik Kline <> Tue, 07 July 2015 12:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5F08C1A034F for <>; Tue, 7 Jul 2015 05:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tVj8qjpnlqJS for <>; Tue, 7 Jul 2015 05:58:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07C9F1A02F1 for <>; Tue, 7 Jul 2015 05:58:57 -0700 (PDT)
Received: by wgjx7 with SMTP id x7so167160178wgj.2 for <>; Tue, 07 Jul 2015 05:58:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cuMac06x+RZRc1nauDJXDKeUf+2ohMhOGIGAJ4iGYaA=; b=VuH/anHFaxWUM2ZjxhV2eXBNKElfXTTW/JxpYOtCAC443kwd77pvy5N2L+MZGNaEdc gK+d7gEUYwyurk1Qdx7EM6PlJGueRRlVIiOHReL0HgtRBI0Aei2OLklf8m0dRMdWN60V uKKN6Ccmmjju2OMDEA5ShisgS4POEBY5GO576QSGgWnTMqZbGiL7KuDGd15cLN9cqo7y 4DGSJaryXDuuDOPxUWnMuRc48i53NU/22+AL2xILZm3U7e4Y1WFLf8L/46hYRUA1Ax9F d4GyLaq/zYAoWAkPf1Es4pmzBKojUD8eSd5nIXr77ZAXeaL+Xp7OleapJDfwogPEILGK ws8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cuMac06x+RZRc1nauDJXDKeUf+2ohMhOGIGAJ4iGYaA=; b=dcGX/IRgWHbeeOx2hOifLoWsC4To2m3STW/a3uBL9RaD+zcls0milvM8Os9NSYM8F2 I2S7s9Xdm5/jf0AEuyiKx0qeiOfR/yTF7nD3F2p6BpZ5hhG13xcSCWRvpfxGdftzeRCu JqlP9znlVpl1fZ65mfc3oRUKo1acs63D+bgzoSugkSq42tENb/LxLptAeMQLwJVAOT3M DzWDjS32u32YLVTZjLCOT+t0OUysr1Hlpjhbxnl+OVlTZvmzzKFmaiTcTwEi94tvuSRG vihrr1TcQrG+RTwTUeTtFzFoN+zDOrDpwpxmRrQczjzkQQrf8uPzdlSoemZYf0loryEQ wiDg==
X-Gm-Message-State: ALoCoQnA1F9+EDX9t3SxqyfxFE/udPdL6R0D+z1RUyuFm+tMaYTea69iSxxVTrvRE7kOncsZN3VX
X-Received: by with SMTP id j2mr8024590wiz.11.1436273936559; Tue, 07 Jul 2015 05:58:56 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 7 Jul 2015 05:58:36 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Erik Kline <>
Date: Tue, 7 Jul 2015 21:58:36 +0900
Message-ID: <>
To: Ray Hunter <>
Content-Type: text/plain; charset=UTF-8
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: Tue, 07 Jul 2015 12:59:00 -0000

I think it's solvable with the logging I mentioned in an earlier post.

Certainly when Google built such a system internally it seems to have
kept the audit folks happy.

On 7 July 2015 at 21:49, Ray Hunter <> wrote:
> Lorenzo Colitti wrote:
> On Tue, Jul 7, 2015 at 9:02 AM, Fred Baker (fred) <> wrote:
>> The statement that I don't see in the document, which would help me
>> personally, is a problem statement. I would guess that the problem statement
>> is "we think some networks are limiting host interfaces to a single IPv6
>> address." I'd want a little more detail, but I'll bet that's the crux of it.
> Not necessarily "are limiting" today, but "will limit" in the future.
> Suppose that all operating systems of interest to a given network support
> DHCPv6 and it is thus possible to run a network without SLAAC and without
> IPv4 without denying service to substantial percentages of users.
> Let's consider what would happen in such a DHCPv6-only network. How many
> addresses would be available to each host? Because DHCPv6 requires an
> explicit request to the network before an address can be used, the answer
> is, by definition, "as many as the network administrators decide to make
> available".
> In some of these networks, the "as many as the network administrators
> decided to make available" may equate to just one. There could be lots of
> reasons for this: technical reasons such as "our IPAM and logging systems
> support only one address per host and it's tied into our legal intercept
> system so we can only give out one address per host", "we only have enough
> TCAM entries for one address per host", "one address per host is what we do
> in IPv4, and we want to be consistent with that".
> If that sounds unreasonable, now consider what would happen in a hotel
> network that charges $5 per device. How many addresses would be available to
> hosts on such a network? At best, one for every $5 paid. More likely, if the
> billing system does not support more than one IPv6 address (why would it?),
> the answer would become "one per MAC address".
> I hope we agree that such networks provide suboptimal service, and that
> there are a number of things that users would like to do that require either
> the availability of more than one IPv6 address.
> If we are able to agree on that, then it is a useful statement to make, for
> two reasons:
> 1. The network administrators might listen to the statement.
> 2. Client and server implementations can implement network configuration
> protocols such as DHCPv6 in a way that does not lead to this suboptimal
> scenario.
> Cheers,
> Lorenzo
> If I might add some comment to the "problem statement"
> I'd like apps and users to be able to enjoy privacy from the "bad guys", and
> also be shielded from general attack and casual scans.
> However, I'd also like the "good guys" to be able to track security
> relationships at some abstract level for audit and security purposes.
> IMVHO That's still very much an area of "work to be completed" and is also
> the main reason why network operators want to limit the addresses in use
> (rather than the $5 per address reason cited).
> As an example, inbound sessions can be clearly directed to a particular
> stable/well known destination address e.g. using DNS. And application
> daemons can generally be configured to listen only on particular addresses.
> But has anyone tried to force apps to use a particular source address as a
> source for related sessions, or "mirror at L7" outbound sessions to use the
> same source address as the destination address of the inbound message?
> In OSI speak that's the session layer, and we don't really have one.
> So the problem isn't just a matter of supporting multiple addresses at the
> network adapter layer; it's a matter of how those addresses are bound to
> apps, and how/when they are selected.
> As one example, I recently came across an app that bound quite happily to a
> particular address on a VM adapter for inbound sessions/messages, but
> defaulted to using the first address configured on the underlying VM for all
> outbound sessions (rendering any stateful firewall pretty much useless,
> because the 1st underlying address was at the mercy of the cloud operator,
> who could shift load around between physical machines at will).
> As another example, I've also come across plenty of firewalls or proxies
> that use NTLM or some other L7 protocol to identify a "user", but are then
> stuck to IP authentication for further follow up sessions, because NTLM or
> equivalent mechanism is either too slow, or not supported on that particular
> app.
> You also have the "https first" problem. In some cases/countries it is
> illegal to intercept/break https encryption (e.g. using fake certs). So if a
> user first connects to a proxy for a site that uses https, there's no way of
> authenticating them, and they are blocked until they use a standard http
> session (to another site).
> In short: Is there any intention to include a shim (containing some sort of
> nonce) to allow (legitimate) tracking and authentication (within an AS)?
> equivalent of http cookie at the network layer?
> That could even be stripped when leaving an AS/site boundary to alleviate
> privacy concerns.
> Or at least some more clarification on socket binding?
> I fear that this isn't as trivial a problem as the draft seems to suggest.
> regards,
> _______________________________________________
> v6ops mailing list