Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements

"Ms. Li HUANG" <bleuoisou@gmail.com> Tue, 27 October 2020 08:03 UTC

Return-Path: <bleuoisou@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5683A12DE; Tue, 27 Oct 2020 01:03:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=gmail.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 TEETEEcngLpG; Tue, 27 Oct 2020 01:03:05 -0700 (PDT)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 F02813A12D6; Tue, 27 Oct 2020 01:03:04 -0700 (PDT)
Received: by mail-il1-x132.google.com with SMTP id q1so670627ilt.6; Tue, 27 Oct 2020 01:03:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e7L5njDw9bHL34WY32/WhQRZ+neauDVWAq7FZeiI7Qo=; b=VDZi62Z4zvhpXMuee7O6zbr/ZeRNXQa6zZY52XajuzTbGNmjRhe57M5jioPO5zLJp0 uulwquIQFjMdF0NjCNRZNp8O5zsTim0We1HEmMCo0ryFOOiVdAOV4XF9vUrqMWOsTMvX PkkC0uhjFhOizyF5mOr/lU8JbO7qydc06BAdH+m1KKd/fuCnwoVPhvnxlam938rcBJDC 7of2ckx/WPa5yFbow1FrS/B7wXqHvjWgWPwypKXBoIbjWA+u1Is3XgkkVffvaXMEI44B 2Fi6GuW68bWpZlZA2IMGuBSIUPyq7wO4amXyYf1uUd9DXb0ozjEs48DrAJVcDzgLqFzJ YyGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e7L5njDw9bHL34WY32/WhQRZ+neauDVWAq7FZeiI7Qo=; b=FiVevXCSbk8XFocxLl4MpG4hOWNxvxYagcadpLATUtcVzG64Khg37xFHq4xLv2IYhm eGafv16uxE6siiZWE9rTecEDd8TdAikwax0f1CwTm0AnPbjoJuvuZQLNixG7S4gBJ/px yUubo4yLMdEeFr03xKvLAAV/6gPwFrYKXOXVlOdAC0n+MLEYGXtzeI/UzlHQ6Dja+1bZ UzPekCS95qgqmHfwTUkHpsmwiIL0X5xzkKzoKY1BQFpbYw3n/CCzh3PBoZDyuc+PnSex EKNf38VOuBMuvQzy5qj9Yme7CQGoK7ZGp5ogYZrip9eagyfXvVO7rPI5SpxqXOEq9hOY heTg==
X-Gm-Message-State: AOAM531tgUXj+LGjcMeQPmopt9vzhHx8BZ+h9K69szE9lOUyg7BIdHwA V6wxSRXYDd75LEHvXmVZ9mrLdrNAyiu9TWM5mkk=
X-Google-Smtp-Source: ABdhPJzlyO0b5PfRDX31MEBqu+zOAoPUpQgGo6v1VLesS4dqAK7LTzbvfues5RP1iSbdLlhz76dj/ps4dxdkEAtaK6w=
X-Received: by 2002:a92:5e14:: with SMTP id s20mr758634ilb.16.1603785784232; Tue, 27 Oct 2020 01:03:04 -0700 (PDT)
MIME-Version: 1.0
References: <65f390e222244427bd3cbc1f58a3ec95@boeing.com> <533e7f91ae814feeb594bc42b7cd70c9@huawei.com> <c621dda1c2a348dfbe9ff86bd4170d4b@boeing.com> <F056E007-9302-4658-92E4-9A4F5F81BA79@employees.org> <618b9ee8ddec4957906bf715b04190a0@boeing.com>
In-Reply-To: <618b9ee8ddec4957906bf715b04190a0@boeing.com>
From: "Ms. Li HUANG" <bleuoisou@gmail.com>
Date: Tue, 27 Oct 2020 16:02:52 +0800
Message-ID: <CAGGiuEa+CTgCgjdGjBZbkbHTej_YB5Pr1okuwLyojgWpyTqkQg@mail.gmail.com>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
Cc: otroan@employees.org, Vasilenko Eduard <vasilenko.eduard@huawei.com>, v6ops list <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>, dhcwg <dhcwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f710fe05b2a279a6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/st04HrGkN6Z1eFkBGBcvipZlJHM>
Subject: Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Oct 2020 08:03:07 -0000

15:46.hk S8 Oct. 27 2020


Good Day group,




The own sg,  vlan routing to ISP dhcpv6 ?
        -  its ipv6 route told unable routed?
        -  stub insight sg or modem.isp?


The own rv ipv6 temp at ipconfig /all is AT wan, none PD possible to be set
up...
        - wan v6 would be able to package exchanging to isp dhcpv6?
        - stub on this rv?



The modem.isp only network to endpoint pc,
        -  stub on modem possible ?
        -   stub on vrrp v6 of isp ?
        -    stub at ISP behind of the client 's rv, or sg or modem ?


       none of is then, no stub package would once tried , no longer
possible to resent it as probably immediately dropped at the 1st
transformation failed right afterward ?



Sincerely
Li HUANG

On Sat, Oct 17, 2020, 04:49 Templin (US), Fred L <Fred.L.Templin@boeing.com>
wrote:

> Ole,
>
> > The CPE requirements document could have had a requirement that it
> should never forward a packet received on the WAN interface
> > back out the WAN interface.
>
> That is what I said before, but I qualified it by saying "should never
> forward a packet
> received on the WAN interface back out the WAN interface *via a default
> route*."
> It could be that there are more-specific routes that would cause a packet
> coming
> into the WAN interface to go back out the WAN interface and that is OK;
> but, not
> via a default route.
>
> However, the further discussion seems to suggest that the delegating
> router needs
> to be mindful of clients that maliciously or otherwise send ping-ponged
> self-directed
> packets. I was worried that the delegating router would not be able to
> distinguish
> CPE router A from CPE routers B, C, D in some cases. But, I am not worried
> about
> that anymore.
>
> Thanks - Fred
>
> > -----Original Message-----
> > From: otroan@employees.org [mailto:otroan@employees.org]
> > Sent: Friday, October 16, 2020 11:31 AM
> > To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> > Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com>om>; Michael Richardson <
> mcr+ietf@sandelman.ca>gt;; v6ops list <v6ops@ietf.org>rg>;
> > 6man WG <ipv6@ietf.org>rg>; dhcwg <dhcwg@ietf.org>
> > Subject: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay
> Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> > requirements
> >
> > This message was sent from outside of Boeing. Please do not click links
> or open attachments unless you recognize the sender and
> > know that the content is safe.
> >
> >
> > >
> > > We are talking past each other, and one of us does not have a clear
> understanding
> > > of the issue at the heart of the discussion which I see as a
> forwarding plane issue
> > > having nothing to do with the control plane.
> >
> > Well, the forwarding plane just does what it's told.
> > When you set up DHCP with static routes at both ends, which are
> maintained by snooping on a protocol. It's not inconceivable that
> > there are cases where you'd get a routing loop. Good thing we have the
> HLIM field. ;-)
> >
> > Markus' draft is still the most authorative document discussion the
> solution space:
> > https://tools.ietf.org/html/draft-stenberg-v6ops-pd-route-maintenance-00
> >
> > The CPE requirements document could have had a requirement that it
> should never forward a packet received on the WAN interface
> > back out the WAN interface.
> >
> > Cheers,
> > Ole=
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>