Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00)
Simon Hobson <linux@thehobsons.co.uk> Thu, 08 June 2017 16:31 UTC
Return-Path: <linux@thehobsons.co.uk>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CBD12943D for <ipv6@ietfa.amsl.com>; Thu, 8 Jun 2017 09:31:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5snrN3QTrTU9 for <ipv6@ietfa.amsl.com>; Thu, 8 Jun 2017 09:31:03 -0700 (PDT)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3BA71293F4 for <ipv6@ietf.org>; Thu, 8 Jun 2017 09:31:02 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6] (unknown [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 759BF1BC37 for <ipv6@ietf.org>; Thu, 8 Jun 2017 16:30:57 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00)
From: Simon Hobson <linux@thehobsons.co.uk>
In-Reply-To: <CAKD1Yr2x_EevJ37NnOg59Xk5+r3YYHmHEQKg_YCCSycuPpBzwA@mail.gmail.com>
Date: Thu, 08 Jun 2017 17:30:57 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <06B0C516-1F46-4279-8F43-A83F8540A8CF@thehobsons.co.uk>
References: <CAO42Z2ziUZnK+n2f9N_Xvb5TZBppApXgNSmDsRLxaT1_taLvFw@mail.gmail.com> <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> <CAKD1Yr2x_EevJ37NnOg59Xk5+r3YYHmHEQKg_YCCSycuPpBzwA@mail.gmail.com>
To: 6man WG <ipv6@ietf.org>
X-Mailer: Apple Mail (2.1510)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Ws9jGyC_ESHj4A-PqFkHbJMC6BI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jun 2017 16:31:05 -0000
Lorenzo Colitti <lorenzo@google.com> wrote: > As for "last byte" - using the last 32 bits of the address to store the IPv4 address seems pretty common too. Akamai has published data about this, I believe. That's an understandable approach to take - in a transitional environment (ie almost all of them these days) it's going to make it easier to remember and type addresses. On that, it's not unreasonable to assume that a lot of operators might be deliberately using "lots of zeroes" simply to make it easier for humans to work with stuff. Eg, it's a lot less typing to type (say) 2001:470:7f09:cbb::57 than 2001:470:7f09:cbb:756e:20d6:e7f6:a544 ! In environments where the DNS just isn't done right, which in my experience is the vast majority of small/medium business networks*, this is even more important. * Yes, this irritates me, but I've met few network admins below "big corporate" level who seem to care about DNS. It generally seems to come down to "the Windows AD controller does all that's needed" in making servers accessible to clients.
- Giving up security & privacy when manually config… Mark Smith
- Re: Giving up security & privacy when manually co… David Farmer
- Re: Giving up security & privacy when manually co… Fred Baker
- Re: Giving up security & privacy when manually co… Job Snijders
- Re: Giving up security & privacy when manually co… Christopher Morrow
- Re: Giving up security & privacy when manually co… Tom Herbert
- Re: Giving up security & privacy when manually co… sthaug
- Re: Giving up security & privacy when manually co… Erik Kline
- Re: Giving up security & privacy when manually co… sthaug
- Re: Giving up security & privacy when manually co… Fernando Gont
- Re: Giving up security & privacy when manually co… Fernando Gont
- Re: Giving up security & privacy when manually co… Mark Andrews
- Re: Giving up security & privacy when manually co… Nick Hilliard
- Re: Giving up security & privacy when manually co… Mark Smith
- Re: Giving up security & privacy when manually co… Philip Homburg
- Re: Giving up security & privacy when manually co… Lorenzo Colitti
- Re: Giving up security & privacy when manually co… Simon Hobson
- Re: Giving up security & privacy when manually co… Fernando Gont
- Re: Giving up security & privacy when manually co… Lorenzo Colitti
- Re: Giving up security & privacy when manually co… Fernando Gont
- Re: Giving up security & privacy when manually co… Mark Smith
- Re: Giving up security & privacy when manually co… Tom Herbert
- Re: Giving up security & privacy when manually co… Lorenzo Colitti
- Re: Giving up security & privacy when manually co… Fernando Gont
- Re: Giving up security & privacy when manually co… Alexandre Petrescu
- Re: Giving up security & privacy when manually co… Mark Smith
- Re: Giving up security & privacy when manually co… Simon Hobson
- Re: Giving up security & privacy when manually co… Tom Herbert
- Re: Giving up security & privacy when manually co… Fernando Gont
- Re: Giving up security & privacy when manually co… Fernando Gont