IETF Logo Mail Archive

Re: 64share v2

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 10 November 2020 12:29 UTC

Return-Path: <swmike@swm.pp.se>
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 EEB223A0A93 for <ipv6@ietfa.amsl.com>; Tue, 10 Nov 2020 04:29:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 AlRmh3frglqH for <ipv6@ietfa.amsl.com>; Tue, 10 Nov 2020 04:29:19 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687283A0A87 for <ipv6@ietf.org>; Tue, 10 Nov 2020 04:29:19 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 10A2FB1; Tue, 10 Nov 2020 13:29:17 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1605011357; bh=/s4neGChoqpuo1iqMYWX5TTC2Fr9/Kq7ownS2Ia8CG0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=3KyC6LmFpQp5Rhd+Bb9zvdTMqkNYSQRqAjEG4tvRXJRfHNzbrkLHoTNSsMGRtm3+4 zqgnKsGCZlQ9f62VOVIMmQOJ0Z8FgLe/wffFiVCnVhv5NTFX/IemG8IcsMapFeDZEh Ag5jszcFbSPNSeN3hCATzsc7ISS+RDu90BqXq4iA=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0DF8DB0; Tue, 10 Nov 2020 13:29:17 +0100 (CET)
Date: Tue, 10 Nov 2020 13:29:17 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: otroan@employees.org
cc: 6man WG <ipv6@ietf.org>
Subject: Re: 64share v2
In-Reply-To: <164BCB66-5B0F-4BBF-AB0B-417B95F4431F@employees.org>
Message-ID: <alpine.DEB.2.20.2011101324320.15604@uplift.swm.pp.se>
References: <CAD6AjGR-NE_sJ_jp7nAT6OvNkcdE9qoWuGEiiVW7r9YtsQvbbw@mail.gmail.com> <CAKD1Yr0G8PjzE+pULte_AaOi=RHMLyto-YUQerGjQ=iOYnz+iA@mail.gmail.com> <0986B112-2159-4045-87F9-876B58F1D896@employees.org> <CAKD1Yr0h9=7p+n=qnH1o1EHqtPrsaYebgvHciOJpP3=iXgNgKQ@mail.gmail.com> <0C739112-D8EA-42C3-BEFD-88C014D5BCD0@employees.org> <CAKD1Yr3Xr2t8yN40kmq6S+gSMPMDkm6cVXaVM+doW-xPo_BTrQ@mail.gmail.com> <55A3AF63-83FF-4D1B-8B18-AD2E7C35E441@employees.org> <alpine.DEB.2.20.2011101234290.15604@uplift.swm.pp.se> <164BCB66-5B0F-4BBF-AB0B-417B95F4431F@employees.org>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/aXEQkpqc-dI05KeDZZ8aKS1sIsU>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 10 Nov 2020 12:29:21 -0000

On Tue, 10 Nov 2020, otroan@employees.org wrote:

> But you see the difference right?
> RA configuration tied to link state. PD assignment not.
>
> Obviously both can be misconfigured. But as I think we have experienced. Getting the defaults correct, both in standards, implementations and understanding is important.

I've experienced internet connections where the PPPoE session was 
forcefully bounced by ISP once per 24 hours and you received a new DHCP 
based address when it came up again. True for both IPv4 and IPv6.

So it makes no difference to me. In real world, neither RA or DHCP based 
methods keep their promise (valid/lifetimes) and they can both be forced 
to be tied to a link state.

It's all up to what the receiver is configured to do about this 
information, and we're already trying to figure out how RA/DHCP should be 
tied together. If someone says "ships in the dark" again I don't know what 
to say, operationally they shouldn't be.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email