Re: IPv6 automatic configuration architecture (?)

Simon Hobson <linux@thehobsons.co.uk> Tue, 23 October 2018 20:09 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 5B531126CC7 for <ipv6@ietfa.amsl.com>; Tue, 23 Oct 2018 13:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=unavailable 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 rXr_qEJ-sfKX for <ipv6@ietfa.amsl.com>; Tue, 23 Oct 2018 13:09:31 -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 B220512426A for <6man@ietf.org>; Tue, 23 Oct 2018 13:02:47 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from simons-macbookpro.thehobsons.co.uk (Simons-MacBookPro.thehobsons.co.uk [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 840001BC37 for <6man@ietf.org>; Tue, 23 Oct 2018 20:02:43 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: IPv6 automatic configuration architecture (?)
From: Simon Hobson <linux@thehobsons.co.uk>
In-Reply-To: <8d8886fc-fc63-1d31-5b72-37da85415ea4@si6networks.com>
Date: Tue, 23 Oct 2018 21:02:42 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A4C9E364-8201-4101-BED4-17110768EEBF@thehobsons.co.uk>
References: <8d8886fc-fc63-1d31-5b72-37da85415ea4@si6networks.com>
To: "6man@ietf.org" <6man@ietf.org>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1lID5PMvSVvEPV2PUKb1UPLKsJY>
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, 23 Oct 2018 20:09:32 -0000

Fernando Gont <fgont@si6networks.com> wrote:

> Whenever there has been a proposal or discussion about a DHCPv6 option
> to advertise a default route, the argument has been, IIRC/AFAICT, that
> the DHCPv6 server is not in a position to tell where packets should be
> sent to.

ISTM that the main reasons coming up from time to time are :

1) DHCP isn't conducive to rapid reconfiguration of networks - eg for a mobile device which gets a new address as it moves around and gets a new connection. For this reason, one large vendor of a mobile OS has decreed that "though shalt not do DHCPv6".
I can understand why not use DHCP for such setups, but many of us have highly stable landline connections and this issue isn't a problem for us - but it seems that we shouldn't be allowed to configure our networks with DHCP because of the mobile issue.

2) Servers and Networks are frequently different departments, and it seems to be argued that these two departments don't talk to each other, and hence it makes no sense to allow any network configuration by the servers team. But given that both teams **must** talk to each other (server addresses, DNS entries, and network configuration have to match for things to work) - I think this is a bit of a red herring. So no, I don't think it is logically valid to say that the DHCP server can't know where packets must be sent to - and conversely using RAs means that even on a stable network, means that hosts have a dynamic environment where routes are dependent on "broadcasts" which do not have guaranteed delivery.

3) DHCP implies central management and that goes against the idea of privacy. Hosts should be allowed to pick their own addresses and change them regularly - but that's not automatically incompatible with using DHCP.


> Specifically, why e.g. an IPv6 router could speak for the whole subnet about IPv4 connectivity, but OTOH a DHCPv6 server cannot e.g. advice where packets should be directed to.

Apart from the issue already mentioned that **all** IPv6 routers must set the flag for it to have effect, you are correct to question it since IMO a DHCP server can speak for the whole network segment - barring misconfiguration, a DHCP server **is** authoritative for a network whether locally connected or remote.