IETF Logo Mail Archive

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

"Bernie Volz (volz)" <volz@cisco.com> Thu, 20 July 2017 09:23 UTC

Return-Path: <volz@cisco.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 AD97D131897 for <v6ops@ietfa.amsl.com>; Thu, 20 Jul 2017 02:23:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Occs1YNwECT0 for <v6ops@ietfa.amsl.com>; Thu, 20 Jul 2017 02:23:07 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE6B126B72 for <v6ops@ietf.org>; Thu, 20 Jul 2017 02:23:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5895; q=dns/txt; s=iport; t=1500542585; x=1501752185; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2RG6PqjAaiimliPLFpeCLpo3Xbx3gmMK0xoQIEWb9Bs=; b=e8TmcpJA4jj9E0lG3pNY0CWNVC2KuXATphGwtJbcgqNvnoPFmks5fDjt wJYy1ECiQAS+rXbIU+6vF4ic0B+M7TEPTzaQ7DD7RhsmWbx+yiZkbW2A6 tGZxB5WT5QQAYeyW5uvsZH8Rdp72AGWwuGKWtMpkfJxgipa9Sv0Dbb6Xk 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CaAADodHBZ/5ldJa1cGQEBAQEBAQEBAQEBBwEBAQEBg1pkgRSOC5FnkFmFLIEyA1whAQqFGwKDcj8YAQIBAQEBAQEBayiFGQEBAQIBAQFsAgcCEAIBCD8HJwsUEQIEDgWJS1wIELM1iyABAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMohS0sgnmEVINZgjEFnz4ClBiCDJAoiUiMFQEfOEw+dRVJEgGFABwZgU52iXoBAQE
X-IronPort-AV: E=Sophos;i="5.40,383,1496102400"; d="scan'208,217";a="272265221"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2017 09:23:04 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v6K9N43Y007301 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Jul 2017 09:23:04 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Jul 2017 04:23:03 -0500
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 20 Jul 2017 04:23:03 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Lorenzo Colitti <lorenzo@google.com>
CC: Tore Anderson <tore@fud.no>, james woodyatt <jhw@google.com>, IPv6 Operations <v6ops@ietf.org>
Thread-Topic: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt
Thread-Index: AQHS/5m/vXdeJwPr90aX1hLwXQdtQqJbMdGAgAACOoCAAReuAIAAS4SAgAAfoYCAAAKDAIAABZ+AgAAFfQD//6/jEQ==
Date: Thu, 20 Jul 2017 09:23:03 +0000
Message-ID: <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>
In-Reply-To: <CAKD1Yr3SZAEbAvjr4Czv_tHN+-UVYGfnZ+SyaiJ0BNkvNr-d2g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_7776E80FEBBF4E3094A5E6570AB8B84Aciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/4ZT9mm5vJm2gF2qR6KgdSQOCDPM>
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 09:23:10 -0000

>> What if the topology change was such that the global address of the DHCPv6 server is no longer valid due to renumbering?

Address of DHCPv6 server does not matter - it can change. Clients generally never directly address packets to its address. They multicast to fe02::1:2.


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

- Bernie (from iPhone)

On Jul 20, 2017, at 11:10 AM, Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>> wrote:

On Thu, Jul 20, 2017 at 10:50 AM, Tore Anderson <tore@fud.no<mailto: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<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email