Return-Path: 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 CF096C1519AD for ; Tue, 23 Jul 2024 20:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.405 X-Spam-Level: X-Spam-Status: No, score=-4.405 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_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=umn.edu 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 CSiUQv7e1M3V for ; Tue, 23 Jul 2024 20:53:09 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3BC6C1DA2EB for ; Tue, 23 Jul 2024 20:53:08 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 4WTKqS2K7dz9vhV0 for ; Wed, 24 Jul 2024 03:53:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7Nfa9mznSnR for ; Tue, 23 Jul 2024 22:53:08 -0500 (CDT) Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 4WTKqR5xsSz9vhTq for ; Tue, 23 Jul 2024 22:53:07 -0500 (CDT) DMARC-Filter: OpenDMARC Filter v1.3.2 mta-p8.oit.umn.edu 4WTKqR5xsSz9vhTq DKIM-Filter: OpenDKIM Filter v2.11.0 mta-p8.oit.umn.edu 4WTKqR5xsSz9vhTq Received: by mail-ed1-f72.google.com with SMTP id 4fb4d7f45d1cf-5a7c6a0f440so1766521a12.0 for ; Tue, 23 Jul 2024 20:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; t=1721793186; x=1722397986; 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=Q5fhhaG0X3olOLT9j4zJT3GGWOljr57VOrfqgWTYIGA=; b=BD/3hAmjwRP1a5y/K9m+zzWK8iW8lelQpG2AAuMs3+B/swLwulR3bKoiSAgyFkxgxt ZcPG5vfcMbgKRKxEvIAyplaWJIWrOH/AGMyNMf1IkOVpNamNqRq7ZMcS4Y6MfcsoliU4 9OXoDgzEny8JFViHqeIX64Q1jcXfnWIYeVM1b1NG05eNK54jfmNpfI3skcnBcKyPjWhs 9h39iEFuPGJ7r5k8sPfIkfPEk8fsKFcwXakf+kYeb/1Xz9K1bSyzu8Kg9IXk1zZGQ0au bu0W8RZP6x1e0MY3QqMoIjhsAy2f+oc75SEK9XSaP+m2QxzdxoTgNpibNxKQbOMw4uS7 gJ9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721793186; x=1722397986; 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=Q5fhhaG0X3olOLT9j4zJT3GGWOljr57VOrfqgWTYIGA=; b=G51juNb4k7uioUJCWtEpLNHzc91U2sX+EZ6DJTBmOymceXh71HR5Jn6qgrUCMU4s/Q 2Sz5LDdYye/7WadmqHT7EVeo9KKUd0k9jqVPcPHcWDpyHZifJ9MBEqveOzPO5jxCUZhS nb27UhaIiUHryU2vHXd7/S7dpWBNnqYGO4p/ZSmkJYhsfhsihl9p5tVuOd7B0Ig1YAi0 M77XyQ6EUZgQoVxa4GIIfjUAGFOWLtg3An99Flbvee7e+9INsOdaAZA1BW8okNRVbUYQ Z1UNaxmaO7oi5hBuviSq67loKUdIqqVxN52PBF8EWH4uJmIQAOCdh4WmygeQzqXTiuTa QVjg== X-Gm-Message-State: AOJu0Yy8cy6BWssk7N/99Yz2Z3NjuO8Ytdrzvm43KfXzFj1vs0bhvOLi 2gzlhw43zHuWe2dQH4Rn9EEJ2N9iAu4nySW338cZ5OKSxAfvpd4UsmrBgOLHgnlAJf4TDmpK2TD aM4qqigG0DN0qGtwRafxGJlKt92ZD1u4kANWdTR8Vmd3iFII+CX963JRYfJH2ivlmS0Ptp+Af/O v9c91FId9/QDxXqBrj4LPbKcXzzmcU08AT X-Received: by 2002:a17:907:6d13:b0:a72:69e8:f039 with SMTP id a640c23a62f3a-a7a87bf3f1dmr369062066b.12.1721793186025; Tue, 23 Jul 2024 20:53:06 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHsxBFDIomPvlW/l+zsd7XjPOWRl9Qn9EoqSAyBwG2qhxfRsysMhi3ZhkQoxXsonnKvejJbgg1IuDqFni4UHeI= X-Received: by 2002:a17:907:6d13:b0:a72:69e8:f039 with SMTP id a640c23a62f3a-a7a87bf3f1dmr369060966b.12.1721793185607; Tue, 23 Jul 2024 20:53:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Farmer Date: Tue, 23 Jul 2024 22:52:49 -0500 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary="0000000000003488eb061df63708" Message-ID-Hash: WJ7L2RVATMI5GM4PTYPZR7SLE3DWEHDQ X-Message-ID-Hash: WJ7L2RVATMI5GM4PTYPZR7SLE3DWEHDQ X-MailFrom: farmer@umn.edu 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 X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bv6ops=5D_Re=3A_DHCPv6_PD_in_a_multi-prefix_environment?= List-Id: v6ops discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000003488eb061df63708 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable from the Introduction of draft-ietf-snac-simple; The term "stub" refers to the way the network is seen by the link to which it is connected: there is reachability through a stub network router to devices on the stub network from the infrastructure link, but there is no reachability through the stub network to any link beyond that one. I was reading that as networks downstream of the SNAC router. Is this supposed also to mean upstream of the infrastructure link? I wanted the SNAC network to have ULA addresses to reduce the attack surface. But if the SNAC network cannot, by policy, communicate with the Internet through the infrastructure link, then providing the SNAC router with a ULA prefix is not advantageous. I'm fine proving the SNAC router with a GUA prefix. That may be how I misunderstood the scenario. Thanks On Tue, Jul 23, 2024 at 10:09=E2=80=AFPM David Farmer wrot= e: > 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=E2=80=AFPM Ted Lemon wrot= e: > >> 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=E2=80=AFPM David Farmer wr= ote: >> >>> 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=E2=80=AFPM Ted Lemon wr= ote: >>> >>>> 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=E2=80=AFPM David 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 pref= ix 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 approp= riate >>>>> 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 r= outer >>>>> choose one or more? How does the requesting router know which prefixe= s it >>>>> is appropriate to select in what circumstances? If the delegating rou= ter >>>>> 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 prefi= x 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 pref= ix >>>>> from the delegating router and not a GUA prefix, especially in the sc= enario >>>>> described in A.3. However, similar questions exist for downstream RFC= 7084 >>>>> or PD-per-device in a multi-prefix environment. >>>>> >>>>> Thanks. >>>>> -- >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> 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 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> _______________________________________________ >>>>> v6ops mailing list -- v6ops@ietf.org >>>>> To unsubscribe send an email to v6ops-leave@ietf.org >>>>> >>>> >>> >>> -- >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> 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 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >> > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --0000000000003488eb061df63708 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
from the Introduction of draft-ietf-snac-simple;

<= blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px">
The ter= m "stub" refers to the way the network is seen by the link to whi= ch it is connected: there is reachability through a stub network router to = devices on the stub network from the infrastructure link, but there is no r= eachability through the stub network to any link beyond that one.

I was reading that as networks downstream of t= he SNAC router. Is this supposed also to mean upstream of the infrastructur= e link?=C2=A0

I=C2=A0wanted the SNAC network to ha= ve ULA addresses to reduce the attack surface.=C2=A0But if the SNAC network= cannot, by policy, communicate with the Internet through the infrastructur= e link, then providing the SNAC router with a ULA prefix is not advantageou= s. I'm fine proving the SNAC router with a GUA prefix.

That may be how I misunderstood the scenario.

=
Thanks

On Tue, Jul 23, 2024 at 10:09=E2=80=AFPM David Farmer <<= a href=3D"mailto:farmer@umn.edu">farmer@umn.edu> wrote:
So, ar= e you saying the SNAC router should use a GUA prefix in all cases and expos= e the IOT devices to the Global Internet?

On Tue, Jul 23, 2024 at 9:55=E2=80= =AFPM Ted Lemon <m= ellon@fugue.com> wrote:
No, I mean can you describe a real-world sc= enario where this would happen. I get that you could configure a DHCP serve= r to do this. The question is, when would someone configure the DHCP server= that way?

On Tue, Jul 23, 2024 at 7:49=E2=80=AFPM David Farmer <farmer@umn.edu> wrote:<= br>
I already=C2=A0did=C2=A0scenario=C2=A0A.3 in draft-ietf-s= nac-simple. It is appropriate for the SNAC router to obtain a ULA prefix in= stead of a GUA prefix to reduce the=C2=A0attack surface of the IOT devices.=

= On Tue, Jul 23, 2024 at 9:33=E2=80=AFPM Ted Lemon <mellon@fugue.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Can you g= ive us an example of a situation where such a decision would need to be mad= e?

On Tue, Jul 23, 2024 at 6:48=E2=80=AFPM David Farmer <farmer=3D40umn.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 sing= le prefix to be delegated to a requesting router from the ISP. Meanwhile, m= any of the draft-ietf-v6ops-cpe-lan-pd use cases probably expect a=C2=A0sub= delegation from this ISP provided prefix.=C2=A0Nevertheless, 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 b= e prefixes from more than one ISP or additional prefixes while renumbering.=

Should the delegating router in draft-ietf-v6ops-cpe-la= n-pd advertise subdelegations from all prefixes it may have and let the req= uesting router choose one or more? How does the requesting router know whic= h prefixes it is appropriate to select in what circumstances? If the delega= ting router doesn't advertise subdelegations from all prefixes, how doe= s it know which prefixes to advertise to which requesting routers?

You can also ask the question=C2=A0from the opposite direc= tion: 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=C2=A0draft-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 i= n the=C2=A0scenario described in A.3. However, similar questions exist for = downstream RFC7084 or PD-per-device in a multi-prefix environment.

Thanks.
--
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking= & Telecommunication Services
Office of Information Technology
Un= iversity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 = =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0= Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
_______________________________________________
v6ops mailing list -- v= 6ops@ietf.org
To unsubscribe send an email to v6ops-leave@ietf.org


--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David= Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
= Networking & Telecommunication Services
Office of Information Techno= logy
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029= =C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D


--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David= Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
= Networking & Telecommunication Services
Office of Information Techno= logy
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029= =C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D


--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David= Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
= Networking & Telecommunication Services
Office of Information Techno= logy
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029= =C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
--0000000000003488eb061df63708--