Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT)

Fernando Gont <fernando@gont.com.ar> Wed, 22 January 2014 21:53 UTC

Return-Path: <fernando@gont.com.ar>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B571A04A0; Wed, 22 Jan 2014 13:53:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 v_ag3qjpLGOy; Wed, 22 Jan 2014 13:53:27 -0800 (PST)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2811A0455; Wed, 22 Jan 2014 13:53:27 -0800 (PST)
Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <fernando@gont.com.ar>) id 1W65jd-0002Wt-48; Wed, 22 Jan 2014 22:53:21 +0100
Message-ID: <52E03DCB.4060101@gont.com.ar>
Date: Wed, 22 Jan 2014 18:53:15 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Pete Resnick <presnick@qti.qualcomm.com>, Fernando Gont <fgont@si6networks.com>
Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT)
References: <20140122192018.8692.82071.idtracker@ietfa.amsl.com> <52E02C0C.7080901@si6networks.com> <52E0322C.1000301@qti.qualcomm.com>
In-Reply-To: <52E0322C.1000301@qti.qualcomm.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-6man-stable-privacy-addresses@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 22 Jan 2014 21:53:29 -0000

On 01/22/2014 06:03 PM, Pete Resnick wrote:
>>> This is an algorithm to generate stable, private, and mostly unique
>>> addresses. It does not affect interoperability at all if people choose a
>>> different method.
>>>      
>> The short answer to this is what Bob has already responding:
>>
>> We currently require nodes to embed their hardware address in the IID
>> when they do SLAAC. And every other specification to generate IIDs is
>> also Std track. So we are being consistent.
> 
> As you might have guessed, consistently doing the incorrect thing isn't
> terribly convincing to me.

If how you select an IID is not std track, prepare for lazy
implementations to set the IID to "1" and hence for collisions to become
common. At that point that becomes an interoperability problem.

And, a folk working on a v6 stack needs to implement *something*. When
he gets to the point of generating an IID, there's something he has to
follow. This document is one way to do it. With specific goals in mind.
And specific requirements if you mean to meet does goals.

That looks std track to me.



>> All the above said, there are many documents from different areas where
>> we have std track RFCs which "do not affect interoperability". e.g. TCP
>> congestion control, TCPs initial RTO, etc. which, from your pov, should
>> be informational?
> 
> I'm happy to extend "interoperability" to mean "an individual host won't
> screw up the net for everybody else, even if it's not directly
> communicating with it." 

That's not interoperability, but a different goal. At that point, you're
doing your own thing rather than the Section 6 of RFC2119 you're quoting.


> Perhaps 6410 has simply done away with the whole notion of what it is to
> standardize things. Maybe I'm in the rough. But I think local
> configuration options and ways to do things that are not about
> interoperably communicating across the Internet have no place in the
> standards track.

If the "local policy" results in a high number of collisions, which
subsequently result in a high number of retries, you might find that the
local policy now has interoperability implications.

It's entirely local policy if it the whole thing relies on your node.
But when it comes to IIDs, they are required to be unique. And that's
not "local" anymore (or not "local to the host", at least).

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1