Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt

Jen Linkova <furry13@gmail.com> Thu, 20 July 2017 10:02 UTC

Return-Path: <furry13@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0278613157A for <v6ops@ietfa.amsl.com>; Thu, 20 Jul 2017 03:02:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 xek3Yh_vcQHi for <v6ops@ietfa.amsl.com>; Thu, 20 Jul 2017 03:02:12 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A6A127735 for <v6ops@ietf.org>; Thu, 20 Jul 2017 03:02:11 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id a62so13724910itd.1 for <v6ops@ietf.org>; Thu, 20 Jul 2017 03:02:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lEEjFDQ25YNdP0gt4OG4AVAfDhMFDryh142lbn3M0fg=; b=Q8A3BDwvGJbBHH0nuVqbN0/ksEXT71lqYWZGUiMdM8Vx8NpTv5HLfdF0LHYJOJw4Bb 4Xf6/CQNSaky8zc0/81eUTtMLbW8EmTgJJfq6Qi6zeHujt6thrFHd2Q4+uyvZ0NON4RN ylcdWp4rIWruesinITvIlD4w1tKqcxlSRzCWGpLPVJ4l+ITOfTuBvY2138xxTfshsh6t sn+5UGOfbrP+7PAVzgzziniBwHoK3efBTNNvcljyXcuX8p5o8pqyGa+Iifq2QHQpLnG/ zsjLede8KtCa/dyXgQaS97Wt6ttl9wb9FFbQfnxj3HqItTSS9tVG3h6PP0mmr6msSUZC HReA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lEEjFDQ25YNdP0gt4OG4AVAfDhMFDryh142lbn3M0fg=; b=BobzBsUCFPcfOM8M0mKuSdiYJCfCttckV3OZr3pGPl3A5/3wWo+RoUkql6EEaQmEtP CYOO1ywm/K/mFoAPnh+pmGOhvKgwsN4//BGM+uavivVuO1ul0U1Jyt1hGafF0ZoR4iDk c8IydPTqmOTShNYMxaOvfGk5/R7r8c7Up+9mQykTi//DkvIfepgpLnu5k8hmnhsbJIs8 t//Sxixuhl6ZW+O4kBAJC4CSbT0y2ZEnms1tEdB5vDsbNGEE7Dzw9plvQsg6d9CCBSKa bBD91iSD5ZisC+osLe/MmH0A6/hY+Xdxwpf6FHa8k+oyMqEVOF2LdzMqPg4i/g2RxA/m IIJA==
X-Gm-Message-State: AIVw110vswl0dr3ptd+7henK2h4sJXL1dJOzwF7Leont3l4ILx+0zgVA rMRvPNtIcbXjC7djspSkiGxGL3J64g==
X-Received: by 10.36.58.8 with SMTP id m8mr2527596itm.103.1500544931301; Thu, 20 Jul 2017 03:02:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.55.215 with HTTP; Thu, 20 Jul 2017 03:01:50 -0700 (PDT)
In-Reply-To: <7776E80F-EBBF-4E30-94A5-E6570AB8B84A@cisco.com>
References: <596CF817.8040900@foobar.org> <BC0BBAF5-B016-44B5-8D73-BC9382CB79A9@google.com> <20170719090835.GC45648@Space.Net> <CAKD1Yr29MmGJuX+uhXaroB6UMRBBWBscCZPaMjaVscL0q7a7pg@mail.gmail.com> <98208c2e-7524-7afa-b0c8-865f251cd66e@gmail.com> <20170720062751.GL45648@Space.Net> <CAKD1Yr1ihnqHAzjhPcA8HB7sBBRwht2t5epJqQA-B_YGnfoTQA@mail.gmail.com> <20170720083002.GT45648@Space.Net> <20170720105009.34003050@echo.ms.redpill-linpro.com> <CAKD1Yr3SZAEbAvjr4Czv_tHN+-UVYGfnZ+SyaiJ0BNkvNr-d2g@mail.gmail.com> <7776E80F-EBBF-4E30-94A5-E6570AB8B84A@cisco.com>
From: Jen Linkova <furry13@gmail.com>
Date: Thu, 20 Jul 2017 20:01:50 +1000
Message-ID: <CAFU7BAR-4WuHw9VVT-ZJOrCHOjNjBV2LPefvSysA937MR7-TnQ@mail.gmail.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Cc: Lorenzo Colitti <lorenzo@google.com>, james woodyatt <jhw@google.com>, IPv6 Operations <v6ops@ietf.org>, Tore Anderson <tore@fud.no>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/VizIrWBrxAALfEPkiu1RU9fPNdE>
Subject: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jul 2017 10:02:15 -0000

On Thu, Jul 20, 2017 at 7:23 PM, Bernie Volz (volz) <volz@cisco.com> wrote:
>>> What if the topology change was such that the global address of the
>>> DHCPv6 server is no longer valid due to renumbering?

> Also, 3315bis recommends that clients refresh information via dhcp when a
> network change occurs (such as new prefixes in an RA appear).

Sorry if I missed smth in that 100+ pages draft hut the only thing I found says:
'
The server MAY initiate a configuration exchange, by sending
   Reconfigure messages, to cause DHCP clients to obtain new addresses,
   prefixes and other configuration information.  For example, an
   administrator may use a server-initiated configuration exchange when
   links in the DHCP domain are to be renumbered or when other
   configuration options are updated, perhaps because servers are moved,
   added, or removed.
'

I'd rather avoid repeating the whole Section 4 of
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-01
but:
1) it's quite possible that in the event of some network failure the
client unicast address might be unreachable;
2) the delay caused by 'network change -> DHCPv6 server gets notified
(by what mechanism, btw?) -> the whole reconfiguration process happens
to ALL affected clients' seems to increase the recovery time.


> On Jul 20, 2017, at 11:10 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
>
> On Thu, Jul 20, 2017 at 10:50 AM, Tore Anderson <tore@fud.no> wrote:
>>
>> That said, for me having the additional DHCPv6-assigned address in
>> addition to the SLAAC one has been a net negative, since it doesn't
>> reconfigure along with the link prefix following a PD change (but
>> nevertheless tends to be preferred for outbound traffic). Maybe this
>> would have been better if it was a ULA rather than a GUA though, I
>> don't know.
>
>
> That's an excellent point.
>
> More in general I'd say that IA_NA is a net loss in *any* network where
> addressing can unexpectedly change, such as a tethering hotspot, a small
> enterprise, or even a medium enterprise using PA addresses. For exactly this
> reason. (In fact - I don't think we even know how to make that sort of thing
> at all without NAT.)
>
> I'm sure many will just say that I'm biased, but think about it - if you
> can't tell the hosts that something has changed, then how do you deal with
> routing and renumbering changes? Even if hosts were to support DHCPv6
> reconfigure, which they don't, how do you reconcile that with the assertion
> that the value proposition is that DHCPv6 provides centralized management?
> How do you do that at scale? Does the DHCPv6 server need to know about all
> topology changes so it can issue appropriate RECONFIGUREs? What if the
> topology change was such that the global address of the DHCPv6 server is no
> longer valid due to renumbering? And so on.
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>



-- 
SY, Jen Linkova aka Furry