Re: [dhcwg] [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function

Lorenzo Colitti <> Wed, 22 November 2017 07:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57E0912EB4D for <>; Tue, 21 Nov 2017 23:33:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.035
X-Spam-Status: No, score=0.035 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, LONGWORDS=2.035, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FZ_3Pwm8TtER for <>; Tue, 21 Nov 2017 23:33:29 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D22AC12EB2D for <>; Tue, 21 Nov 2017 23:33:28 -0800 (PST)
Received: by with SMTP id x72so5529494ybg.11 for <>; Tue, 21 Nov 2017 23:33:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G4xKUa6+HAprE45vV0YEbcl72O5FS1IYmIKDP3tZnEE=; b=P22BOuSY4wQ4Ao4F0kXBRR+MZJ1OhoYZSBIVw90CtBPMyWOOdh8x1vLgigWQiXqwfg N2ZyXaEyPA582qarRXuUdxqDPD7eJMN/U2A31Y+l5Tt1MCD59ykDg3umwlv4qULcW1UY NMcdb3k7C/B2AKdGZRaT1+Itzr4xrKN5B3MbtiiRso4OIKOAnCOCrzLxy/CZ/16pJk9V dwpq/ALXxYYkyijkyOvlALLsXm0w5g2o1qt/mwZTILMMJprXDSSSUc2g5nTd+Nmy4QR0 Nwwh9CL3kyyuprR1X5m5U2NVOTxYyKsWJAXudbmXyj1ubdDrJjdiJ+LczkhgNG/YHFUy 4/3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G4xKUa6+HAprE45vV0YEbcl72O5FS1IYmIKDP3tZnEE=; b=H5zusJsfld+Qlp0ErigK2Z6pyx43LP0XfrIr//b4bh8LshtczY8lh0crUig4s1YAuK GvbQj28TLdz7QbhMRnGx8MJ4ZTrSiP6A0djUyFBFRlj2eaTLAcpaFNW8sldFbluw6fEa uqAomNYORRmynZm0jBu7WSng99fE1b38wwDU3OtRKZWOTqSETItHq9e3P3zmMzK4BuBV YEQ/dG6feo3ugt7o+nk7BUgzeFZeOV/Ex0WCxT0PWW0UK5+YjH1Cqj08VZcQxH03ykQR ZKDdJT4btBsFkvTQ/2mJ4hxGmEpXhLFQQ22ossawPHB5u8GbDiqnUWyGhReS1fTVWuvJ XsWw==
X-Gm-Message-State: AJaThX6binuc8+nOeDV4dUDIah1IYy7SKwNg1WPYHEVwuWh/Foc0opr5 6TUNfd0KDnn390c0uid85rDSjKp4NTZ7VJT3cERG5Q==
X-Google-Smtp-Source: AGs4zMbDUyjFKEDafZ8EvUydtVHDJ+R+PHpw06BpeOkILp6GEsmt3jJqZZRi6zQDIN6AaB154cy0aYdpETA1E0/5MhM=
X-Received: by with SMTP id p72mr13086674yba.63.1511336007721; Tue, 21 Nov 2017 23:33:27 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 21 Nov 2017 23:33:07 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Lorenzo Colitti <>
Date: Wed, 22 Nov 2017 16:33:07 +0900
Message-ID: <>
Subject: Re: [dhcwg] [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
To: Mark Smith <>
Cc: Sander Steffann <>,, "" <>, "" <>
Content-Type: multipart/alternative; boundary="001a11c04b04e0ee4f055e8d55ee"
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Nov 2017 07:33:30 -0000

On Wed, Nov 22, 2017 at 4:19 PM, Mark Smith <> wrote:

> Pushing layer 4+ configuration options into ND creates a dependency on
> router firmware for application deployment that doesn't exist today in
> either ND or DHCPV6.
> Another example of this trap. Remember that NTP amplification DoS from 3
> or 4 years ago? One place I'm aware of were using their PE routers to also
> provide customers with NTP time, and the router implementation was
> vulnerable. From memory, the vendor took around a week to release a fix.
> Then the next 6 to 8 weeks were spent organising high impact change
> controls because router firmware upgrades either required reboots or there
> was a hazard of one. The number of PE routers was in the 10s, imagine time
> and effort, and vulnerability exposure time if there were 100s or 1000s of
> PE routers providing NTP time to customers.
> Compare that to if the NTP service/application was not "in" the network,
> not "in" the routers' control planes, and as service reachable over the
> network. Only patches to the NTP servers would have been necessary, and
> there would have been far fewer of those.

These are all good reasons for ND being limited to only those options that
are strictly necessary for connectivity. There are those who argue that
even DHCPv6 is too low-level for that sort of thing and that
application-level configuration should be moved to another protocol.