[v6ops] Re: DHCPv6 PD in a multi-prefix environment

Daryll Swer <contact@daryllswer.com> Wed, 24 July 2024 13:53 UTC

Return-Path: <contact@daryllswer.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 2894BC14F738 for <v6ops@ietfa.amsl.com>; Wed, 24 Jul 2024 06:53:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=daryllswer.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygeuKhkcTFYY for <v6ops@ietfa.amsl.com>; Wed, 24 Jul 2024 06:53:14 -0700 (PDT)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D63C14F6E4 for <v6ops@ietf.org>; Wed, 24 Jul 2024 06:53:14 -0700 (PDT)
Received: by mail-pl1-x629.google.com with SMTP id d9443c01a7336-1fc49c1f3e5so9373305ad.1 for <v6ops@ietf.org>; Wed, 24 Jul 2024 06:53:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daryllswer.com; s=google; t=1721829194; x=1722433994; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=TLHwYGxdMub2ttNXzsOfVQUnc+HXZghMrJXyDiK+m8g=; b=TGpMS/5lTOeJONO15veztbgfyY2EhCZ7cdkl06fFgJaRxieM1oK4Ta6pNmqBpOcwZt ZHcvaRjvE61uE9rN+zYJv1a+cGSqzWqp34pT9kFOsrZnwevUQ+eB1sb84aYlff7KAb/N huIEAXOrqEi7Hr0htYGmnlzTLeJT0AlTQxax9/e85RDVaBzvcB0TqRlY0G+KBpoS1xx2 53Po0LjCO9E3UBjggz0xA61pq+Tav5D7vrzNLyXNIZ3/nBwyMNy6l1xyZAqP2z896B5s cLpSdPchGQNYGGz3kGq0X6+Sl7ki08Eih+xnMh8VwbwoKMl+HfrRo/bWdHs4dadnQfeG eKfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721829194; x=1722433994; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TLHwYGxdMub2ttNXzsOfVQUnc+HXZghMrJXyDiK+m8g=; b=h+k9MJLhf3Tcbn+ERT5N7KIlZ7ouQ9Bk203i4RWeWUXtc2KLdoSGPXv9zIT4q0tB+S ClR8epIeG/CPtIxtS4A49Sat7/QcNswWAfuazFHgEJvjLSbBwr3OjKhbihMo+wMgIwhU C4KJiAWdaXJe8dnXfJB9yL4ORgdA5kVK9xQ28/H5mOKqYebSyURQF+VvaSK3n9tkHuYv Zp8BUjk7gYPeAimCXmpudZsKSkF+WhH2ee6EHASh4s0tmi2SzfbIKh5Z+hn6tR+JMvlo kN/s5lLCftkCrkYjxT2Wumz+YrXcSltw2EaFGReNFOSCM7IjnwPpvflUCChb7fr1bUU1 zZyA==
X-Forwarded-Encrypted: i=1; AJvYcCWuglTmgjeELx5TbSyrrbPsocddqBOzF6ttqyrf3vWCpwhz1/Oqlwmgdq/s0dJJV6zC7UbzeJ0Iocqb0MsWRA==
X-Gm-Message-State: AOJu0YzbOSAzVljLC7fkhg/1RTud/tefPr2gmndA3BTee60rBXcZ/Y1t i6QlQUtNIoJ7jxpUCWyl+CaenUwdtG4foasviiBy8eBmh/aSlVEy2Bhc/DH1hVOnDH7ZTnxYGA9 h1/c=
X-Google-Smtp-Source: AGHT+IF4f8Gk+mT7MwhpsNQIup7F2ccu5VeLiec7w9K56X1MfjfjQhkP6JW6I80cME3bqD8FZAS/sA==
X-Received: by 2002:a17:902:e546:b0:1fd:ae10:7246 with SMTP id d9443c01a7336-1fdae107492mr81682585ad.5.1721829193361; Wed, 24 Jul 2024 06:53:13 -0700 (PDT)
Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com. [209.85.214.176]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1fd6f317ed7sm94243585ad.138.2024.07.24.06.53.13 for <v6ops@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jul 2024 06:53:13 -0700 (PDT)
Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-1fc49c1f3e5so9372925ad.1 for <v6ops@ietf.org>; Wed, 24 Jul 2024 06:53:13 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCXp3SrubjLmu8U9TlSTGPCMNEKFft/qfxUvA5N7J7kKdr8vCbqyc8WQwevROxyZcqD3zGebM+P0rYaEo3fnjw==
X-Received: by 2002:a17:90a:d911:b0:2c8:6eea:7ad8 with SMTP id 98e67ed59e1d1-2cd161af494mr10545084a91.26.1721829192505; Wed, 24 Jul 2024 06:53:12 -0700 (PDT)
MIME-Version: 1.0
References: <CAN-Dau1tRp02p58O8RKcCAVeXKqnkJt_b14KM5iCcDTm4JmnGQ@mail.gmail.com> <CAPt1N1ntZmL47HH-zkryVey6NmzEenKfBzZ90hcUQaduZV3sLw@mail.gmail.com> <CAN-Dau1udnxJTWWknwwTjzTa7cQejoE0qcVk94u5ijd3RaBXrw@mail.gmail.com> <CAPt1N1mEPLo6BN6=xLd7r+WJ7PiNhjW3GtUboZtTBZeU6dy-0Q@mail.gmail.com> <CAN-Dau0icgiM5+9_KYhEiaKwfRD2tUcA9qSpC=R5sVgSecRcGQ@mail.gmail.com>
In-Reply-To: <CAN-Dau0icgiM5+9_KYhEiaKwfRD2tUcA9qSpC=R5sVgSecRcGQ@mail.gmail.com>
From: Daryll Swer <contact@daryllswer.com>
Date: Wed, 24 Jul 2024 19:22:32 +0530
X-Gmail-Original-Message-ID: <CACyFTPFeE6EVFsxBbnwM+v8Ga8vEXSMd0KBMR1reiO=YrKgJdg@mail.gmail.com>
Message-ID: <CACyFTPFeE6EVFsxBbnwM+v8Ga8vEXSMd0KBMR1reiO=YrKgJdg@mail.gmail.com>
To: David Farmer <farmer=40umn.edu@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000062280a061dfe99bf"
Message-ID-Hash: ULKKBYWWXWR3UI2K2HLX6ECWCLYWUS5K
X-Message-ID-Hash: ULKKBYWWXWR3UI2K2HLX6ECWCLYWUS5K
X-MailFrom: contact@daryllswer.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-v6ops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: V6 Ops List <v6ops@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] Re: DHCPv6 PD in a multi-prefix environment
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/VnkF2LydbeTP-XIi9sGV64AzOpE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Owner: <mailto:v6ops-owner@ietf.org>
List-Post: <mailto:v6ops@ietf.org>
List-Subscribe: <mailto:v6ops-join@ietf.org>
List-Unsubscribe: <mailto:v6ops-leave@ietf.org>

> So, are you saying the SNAC router should use a GUA prefix in all cases
and expose the IOT devices to the Global Internet?

What do you mean precisely by this? Yes, I'd give *native* *GUA* for
*everything,
*including my thermometer. But how did you conclude it'll be exposed to the
global internet? The CE for average home users is stateful
firewalled-default enabled for IPv6 with devices like TP-Link, Asus etc, in
fact, most of these off-the-shelf CPEs don't even support IPv6 firewall
disable-mode nor manual port allow on their firewall implementation
(usually legacy iptables in the backend). And for any enterprise or
professional users, they'd know how to set up their own stateful firewall,
either on the CE or on a middle-box below it.

I see zero reasons for ULA (other than the re-numbering possibility). What
I'd do (if we are discussing enterprise/business use cases) is getting my
own prefix from a RIR (or cheaper LIR? Whatever works), and:

   1. Get the ISP to advertise it for me and route it to me, OR
   2. Use my own GUA prefix internally (remember this is not globally
   advertised in this example) and then NPTv6 it back to the upstream's ISP(s)
   prefix delegation for a pure stateless, transport-agnostic translation.
   That solves your numbering problem permanently, even if you changed ISPs
   daily (assuming each ISP complies with BCOP-690 and gives you a /56 or
   larger GUA), OR
   3. If own-GUA is no go, I opt for *200::/7* space (reasoning being to
   avoid ULA-related operational issues, but perhaps even the new
   documentation prefix would suffice and might be a “cleaner” approach) and
   use it internally to avoid renumbering, and then combine it with NPTv6.

As someone who works professionally in this line of work, who also happens
to be a major advocate for native P2P networking without hacks (TURN) —
This is what I do to balance between stateful firewalling and P2P — I'm
sure there are many other professionals who do something similar as well:

   1. *Stateless* filters on the CE or middle-box (In Linux world that
   means, iptables prerouting chain, nftables -400 or -450 priority hook,
   IIRC) to drop bogons and for example, port 25 (with ACLs), basic ACLs to
   protect localhost daemons (BGP, OSPF etc).
   2. On-Host firewall and application security configuration/hardening —
   For example, my Windows machines all have default stateful firewall enabled
   which blocks all unsolicited ingress by default, my Linux hosts are
   configured via templates to do the same thing, and for additional security,
   let's assume nginx is running and exposed to WAN, I implement recommended
   practices to harden nginx on layer 7. Of course, we should implement
   OS-hardening as well, per industry norms.
   3. And if these are enterprise work-stations, the IT/System teams should
   ideally deploy policy control and management on their employee's
   company-owned devices to additionally block installation of unauthorised
   software, modifications etc.
   4. IoT devices (thermometer, cameras etc) are on IoT-dedicated VLANs —
   Said VLANs are always, permanently behind stateful firewall rules. However,
   I do not block ICMPv6 and always permit global ICMPv6 reachability — I only
   drop deprecated ICMPv6 subtypes
   <https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-4>,
   directly on the edge. That being said, most devices' kernel comes with a
   default ICMPv4/v6 rate-limit as well, so that helps a bit.

tl;dr
No need for ULAs, NAT66 hacks, renumbering — To
achieve security/firewalling and “mobility” (probably poor choice of word
here) across ISP-numbering.

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://mailtrack.io/l/6a46e2daa868111b9f7696db0b6127dd572ecadc?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=62149b81261996e4>


On Wed, 24 Jul 2024 at 08:39, David Farmer <farmer=40umn.edu@dmarc.ietf.org>
wrote:

> So, are you saying the SNAC router should use a GUA prefix in all cases
> and expose the IOT devices to the Global Internet?
>
> On Tue, Jul 23, 2024 at 9:55 PM Ted Lemon <mellon@fugue.com> wrote:
>
>> No, I mean can you describe a real-world scenario where this would
>> happen. I get that you could configure a DHCP server to do this. The
>> question is, when would someone configure the DHCP server that way?
>>
>> On Tue, Jul 23, 2024 at 7:49 PM David Farmer <farmer@umn.edu> wrote:
>>
>>> I already did scenario A.3 in draft-ietf-snac-simple. It is appropriate
>>> for the SNAC router to obtain a ULA prefix instead of a GUA prefix to
>>> reduce the attack surface of the IOT devices.
>>>
>>> On Tue, Jul 23, 2024 at 9:33 PM Ted Lemon <mellon@fugue.com> wrote:
>>>
>>>> Can you give us an example of a situation where such a decision would
>>>> need to be made?
>>>>
>>>> On Tue, Jul 23, 2024 at 6:48 PM David Farmer <farmer=
>>>> 40umn.edu@dmarc.ietf.org> wrote:
>>>>
>>>>> The classic ISP use case for DHCPv6 PD, as envisioned initially by
>>>>> RFC3633 and integrated into RFC8415, typically expected a single prefix to
>>>>> be delegated to a requesting router from the ISP. Meanwhile, many of the
>>>>> draft-ietf-v6ops-cpe-lan-pd use cases probably expect a subdelegation from
>>>>> this ISP provided prefix. Nevertheless, an RFC7084 CE Router may also have
>>>>> a ULA prefix to subdelegate from, and a ULA prefix may be more appropriate
>>>>> for some of the use cases. Not to mention, there may be prefixes from more
>>>>> than one ISP or additional prefixes while renumbering.
>>>>>
>>>>> Should the delegating router in draft-ietf-v6ops-cpe-lan-pd advertise
>>>>> subdelegations from all prefixes it may have and let the requesting router
>>>>> choose one or more? How does the requesting router know which prefixes it
>>>>> is appropriate to select in what circumstances? If the delegating router
>>>>> doesn't advertise subdelegations from all prefixes, how does it know which
>>>>> prefixes to advertise to which requesting routers?
>>>>>
>>>>> You can also ask the question from the opposite direction: How does
>>>>> the requesting router solicit for a ULA prefix instead of a GUA prefix if
>>>>> that is more appropriate for its use case?
>>>>>
>>>>> These questions came to mind while reading draft-ietf-snac-simple, as
>>>>> it would seem reasonable to want the SCAC router to obtain a ULA prefix
>>>>> from the delegating router and not a GUA prefix, especially in the scenario
>>>>> described in A.3. However, similar questions exist for downstream RFC7084
>>>>> or PD-per-device in a multi-prefix environment.
>>>>>
>>>>> Thanks.
>>>>> --
>>>>> ===============================================
>>>>> David Farmer               Email:farmer@umn.edu
>>>>> Networking & Telecommunication Services
>>>>> Office of Information Technology
>>>>> University of Minnesota
>>>>> 2218 University Ave SE        Phone: 612-626-0815
>>>>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>>>>> ===============================================
>>>>> _______________________________________________
>>>>> v6ops mailing list -- v6ops@ietf.org
>>>>> To unsubscribe send an email to v6ops-leave@ietf.org
>>>>>
>>>>
>>>
>>> --
>>> ===============================================
>>> David Farmer               Email:farmer@umn.edu
>>> Networking & Telecommunication Services
>>> Office of Information Technology
>>> University of Minnesota
>>> 2218 University Ave SE        Phone: 612-626-0815
>>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>>> ===============================================
>>>
>>
>
> --
> ===============================================
> David Farmer               Email:farmer@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> _______________________________________________
> v6ops mailing list -- v6ops@ietf.org
> To unsubscribe send an email to v6ops-leave@ietf.org
>