Re: [v6ops] Who implements the DHCP service?

Lorenzo Colitti <lorenzo@google.com> Mon, 20 November 2017 01:36 UTC

Return-Path: <lorenzo@google.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 6AA52126B6D for <v6ops@ietfa.amsl.com>; Sun, 19 Nov 2017 17:36:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 qnVZ7j0CgKo1 for <v6ops@ietfa.amsl.com>; Sun, 19 Nov 2017 17:36:51 -0800 (PST)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 A83C51250B8 for <v6ops@ietf.org>; Sun, 19 Nov 2017 17:36:51 -0800 (PST)
Received: by mail-it0-x235.google.com with SMTP id n134so10063442itg.3 for <v6ops@ietf.org>; Sun, 19 Nov 2017 17:36:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QjlWWDi81Y6CT81w/fySqbMvVfs2K1XU0ijliaPh7js=; b=JiR7FV+umhT55geDMuFYpkI2oxChxnuCp8FwF8MjYXdtmKWBUZGjBg4PkjtNLYrfSA Hwve3AXG2e+ikacYfVrpV8S17dLYvB0sUUMDTjxJib6ocAVBiEjHwWPs+GcfeiN7FoJo EB2wgNoKM+STx7s3Z+iUaNAjk66iM9d7x6O4Cky5sVJBTou3EyQRqDSx0WuMDST8T1U6 IoJZH0MQ2oXXaWy8yWScHWB4gKt5Zrcwl4dKzQtFm53AZ1PO4PYVhsNGsApmi2ojBhn8 1yJiosmPqmSVXCtfgB/awSBdNt8jg1IMCJs7+5AWgsxW4VPOoC3mAKM0m6jDqHbkG2PX nOZQ==
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=QjlWWDi81Y6CT81w/fySqbMvVfs2K1XU0ijliaPh7js=; b=MLNHh2anAMmsgxX+jNcEv5HAgjUZwcd/HjQC4e0ilD7JGVlrSYP/b0G/pJwZXTL0mo BQraLfTeYqfOSQJ1IzjagjSr/NiIkGPv0+NtPJLLD2ck1WI3NGrQmKFHFrYzQHPNpdpF RySKdIc++DUlxFZiYyEWCxHRoUcrMuMPkln/7FrXVnW3Rt9BrX8w7CKtK8civ0+ZQ60P s5TsIk8aI1TpOM2GashNSVz4UC3CGF6D3IDTWpQ0jzEMW+S0R0TbAWMTRFoZ+Esxgqml 32SLcdmzheF8FjVZINhjAur8Q42F+cpXV92DhYhL5ahkYarMjm+b/fOckO9RsznTKHmQ t/+A==
X-Gm-Message-State: AJaThX7cKWyUPFBJq+RFk6FFKPc4KVupMUA9r0QXYKhsAIZ4JtZ5kn8I eqDVbiUBK4jukqlNHzVo4LD/lOUwLDPJexsAUb4DrA==
X-Google-Smtp-Source: AGs4zMbSnwAy7mmOlTK3jiyuaDn37v9jGXwW8IcQdfG82/JD4FvLjoIVFNFqamJadeTBMicMaBpXruvilidbtWAs06c=
X-Received: by 10.36.81.21 with SMTP id s21mr16785639ita.144.1511141810504; Sun, 19 Nov 2017 17:36:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.16.155 with HTTP; Sun, 19 Nov 2017 17:36:29 -0800 (PST)
In-Reply-To: <9FDA6FE7-C03C-4AA9-BED4-F0D7ED63FBBF@gmail.com>
References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <AM5PR0701MB283634D35008FC7AAF934B88E02E0@AM5PR0701MB2836.eurprd07.prod.outlook.com> <fd860e6c2af84c4d9774ce67f4468720@XCH15-06-08.nw.nos.boeing.com> <43186ad6-dc2f-c9d8-2884-db4a097f142d@gmail.com> <655879d9e7274da88ee2cd33a0202dd7@XCH15-06-08.nw.nos.boeing.com> <9FDA6FE7-C03C-4AA9-BED4-F0D7ED63FBBF@gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Mon, 20 Nov 2017 10:36:29 +0900
Message-ID: <CAKD1Yr0SF+eZDhKYXpNZQ9ZwrWzwNx0TmxFbpcTSCBtUScuHLw@mail.gmail.com>
To: Fred Baker <fredbaker.ietf@gmail.com>
Cc: Fred Templin <Fred.L.Templin@boeing.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="001a113a7146d2b95c055e601e98"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/fgV8EvzokD_QVvDTJkGtaqzysdc>
Subject: Re: [v6ops] Who implements the DHCP service?
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: Mon, 20 Nov 2017 01:36:53 -0000

+1, in most scenarios the delegating node does not have an interface
connected to the requesting node.

On Mon, Nov 20, 2017 at 10:27 AM, Fred Baker <fredbaker.ietf@gmail.com>
wrote:

> One comment on the draft in question.
>
> Looking at figure 1 (applies to all of the figures, but let me be specific
> for the purposes of a comment) I don't see any reason to believe that the
> node marked "Delegating Router" is in fact a router or is connected
> directly to the "Upstream Interface". AFAIK, given the relay capability
> present in RFC 3315, the common practice is to have a more central server
> respond to IA_NA and IA_PD requests, and simply have a router connected on
> the ISP link. That might get complex to draw in a figure, but I'd worry
> about any implicit assumption in the WG version of the document that only
> routers implemented the PD service.
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>