Re: [dhcwg] Adoption Call for draft-fkhp-dhc-dhcpv6-pd-relay-requirements - Respond by Jan 14, 2020

"Ms. Li HUANG" <bleuoisou@gmail.com> Fri, 22 May 2020 10:28 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 72F963A0AB0 for <dhcwg@ietfa.amsl.com>; Fri, 22 May 2020 03:28:35 -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 9OJrku9FTJPP for <dhcwg@ietfa.amsl.com>; Fri, 22 May 2020 03:28:31 -0700 (PDT)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 D64F23A0AAF for <dhcwg@ietf.org>; Fri, 22 May 2020 03:28:30 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id f4so10775301iov.11 for <dhcwg@ietf.org>; Fri, 22 May 2020 03:28:30 -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=vgSNu/IRIFvEcPwzlLl/GZn/4jfG/AY2Dr5InbXihBw=; b=Pt4tVtFEX0hmmjqWMbymFoNs0AWMZJ8+IGqHHYYSUJCwZM0IidZn4iYrBYzVhY+ADp 9bjC2siBKYVgV1PgCwHTfnD2yi5ZqdksvOfFQw7Q+T4ka4Rv2hDrA/kdPPW7+EMHJXGF FM41iehZHAZwUocviDD+JKp03R51epUj4MlMuA62NVmroZYI1w3LzsgNFFjC/Ugah7qM pqOeSB8ztK5iRO8vzadr0H2XiAqY89fe0OnLtHPxsKgh/dgZEWai7sli8KOkr1KWaaYe jSoR4b4p0eBR6lR7AibvUqR2pEE4BIvyecNLTYj9YIbYqYQ4Bkc1yVcEjwyL6S39PQCt Hr/A==
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=vgSNu/IRIFvEcPwzlLl/GZn/4jfG/AY2Dr5InbXihBw=; b=Qj8tGfmGD87RD5Pv9eyqAQVFX00vW9Vq3MbVbiO1r5RIQu5ZP9cmiqcAT9JbFSVkK/ mZP48sZl4v6y5LO7CnW/ZQDrn2ntXGgMVqQd4xxbCxSDpnRITosNPs9/MrqkBQ+QgwtF oA7oA0CCe3IOjgToGyfPWT9J/0sSch466ZAybYXLVwiKgY15NBITYMKe9x2by+4WAk4A DmJiNRAeXF2hsbxvI5R9WpTb10kOn2YEJ3M9pRIu4o0Aed233YdZXL8qOapszhiQILaf b81Iy8q+Rurgp0opKTiNew4pNpJ4jWODkZzOz3HkeZvpBrNDyxEuVz1/+E98RRKZAjCD QNyg==
X-Gm-Message-State: AOAM531Zu2XmHw138pXl+Rm4z7tCK0i2Y4+KoE2L5nnwNRhrHS80AXd2 5Fm2Z9DMO4llWQviYeg5psNcjIbaO3akAMyyGCg=
X-Google-Smtp-Source: ABdhPJxLFQqsH1Cnw2C/aKFKG7ZBGfvgAAxglhzHJGOx0Uv3pNwclzhSfzfxxvIJ19I1WgwhJILKSZGrjsSLbUlPm6Y=
X-Received: by 2002:a6b:1543:: with SMTP id 64mr2560841iov.123.1590143310022; Fri, 22 May 2020 03:28:30 -0700 (PDT)
MIME-Version: 1.0
References: <BYAPR11MB2888345B6D3728C02AE410EFCF240@BYAPR11MB2888.namprd11.prod.outlook.com> <CAMGpriX0F8FfbvjdEOG1rz10d8fsqS5YfQPaZhVv_Puwc24U-A@mail.gmail.com> <F345A7A1-9A7D-42EC-8979-1D1DD10E285A@gmx.com> <CAGGiuEbvPWqRPZT1T0d3+3CkE3rqp0SrOcGAezhzTExbdfAWfA@mail.gmail.com> <C2FDBFB4-9DFE-48DA-AAA0-1444A08D6970@gmx.com> <CAGGiuEaQ0H7Zd2ANMnwdQDAEm-J7sptG1qqnXkv_98hbwYjdMg@mail.gmail.com>
In-Reply-To: <CAGGiuEaQ0H7Zd2ANMnwdQDAEm-J7sptG1qqnXkv_98hbwYjdMg@mail.gmail.com>
From: "Ms. Li HUANG" <bleuoisou@gmail.com>
Date: Fri, 22 May 2020 18:28:18 +0800
Message-ID: <CAGGiuEZ61p-XQp7xBb5pZGDw5T=Eq12QxJEa8wK-LWTQjt45ng@mail.gmail.com>
To: ianfarrer@gmx.com
Cc: Erik Kline <ek.ietf@gmail.com>, dhcwg@ietf.org, "Bernie Volz (volz)" <volz@cisco.com>
Content-Type: multipart/alternative; boundary="00000000000022cd6905a63a1743"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/8-IYYHGayS8TR5Ojt98K0PR3YR8>
Subject: Re: [dhcwg] Adoption Call for draft-fkhp-dhc-dhcpv6-pd-relay-requirements - Respond by Jan 14, 2020
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: Fri, 22 May 2020 10:28:36 -0000

18:22.hk S8 may 22 2020


to relay those not initial mac as  changed board and duid modified , wifi
adapters int, even mobile double mac  int,   the basic octet, hex, decimal
rule converted lladd correctly or ipconfig /all after isp Whatever scheme
doing as the not corresponding mac.bit part of ipv6 with tempv6, to  be put
under RALAY would be right?


Sincerely
Li HUANG

On Fri, May 15, 2020, 16:20 Ms. Li HUANG <bleuoisou@gmail.com> wrote:

> Good Day Ian,
>
>
>
> To keep the rcf3315, rcf8417 the DUID at its initial,  the the 2nd mac int
> showing at local adapter one would be must create a prefix ull 128 ipv6
> with the same prefix of duid one's as well set delay it like 2nd sub.mac -
> parralled /sub.networking ?
>
>
>
> Since the ipconfgure /all not shown the 3rd mac int space built in,  the
> the same way as said above just put it to the 2nd relay.prefix according
> mac use same the wan prefix of duid one's and list all of mac int at relay
> prefix area would be fine?
>
>
>
> How about for the pc having wifi mac x 2 to 3 interfaces processed as also
> to the mobile 2x IMIE can be merged into the sg device configured somehow?
>
>
>
> Appreciated your returning in advance...
>
>
>
> Sincerely
> Li HUANG
>
> On Mon, May 11, 2020, 22:26 <ianfarrer@gmx.com> wrote:
>
>> Hi,
>>
>> Just to make sure I understand your question correctly, you are asking
>> what happens when a client network interface card is swapped out, meaning
>> that the MAC address changes, will the same prefix be delegated?
>>
>> According to RFC8415 11.2, in this case the client DUID MUST remain
>> unchanged, so it would be delegated the same prefix by the server assuming
>> that there is still an active lease for the client with the old network
>> interface, or the previously delegated lease is not leased to another
>> client (in the case that the previous lease has expired).
>>
>> Thanks,
>> Ian
>>
>>
>> On 8. May 2020, at 17:05, Ms. Li HUANG <bleuoisou@gmail.com> wrote:
>>
>> 22:59.hk S8  May 08 2020
>>
>>
>>
>> "This is to allow client devices with duplicate DUIDs to
>> function on separate broadcast domains. "
>>
>>
>> when the rcf3315 replaced board machine owning local and dh pv6duid two
>> of mac.eth both, how the duid being counted on which eth.mac int please?
>>
>> would such env, getting multiple nets v6 and mean timely recognizable
>> from a, multi dhcpv6 servers if in case ?
>>
>> To oem over 2 times changed motherboard pc even unable shown up one if
>> mac.ehe info time, as 2 limited in the ipconfig space, how to be recognized
>> please?
>>
>>
>> So on circumstances ...
>>
>>
>>
>> Sincerely
>> Li  HUANG
>>
>>
>>
>> On Tue, Apr 28, 2020, 22:33 <ianfarrer@gmx.com> wrote:
>>
>>> Hi Erik,
>>>
>>> I’m just going through the outstanding points on this draft and it seems
>>> your comment got overlooked. My apologies.
>>>
>>> There’s an change in the wording for G-5 (in response to a question from
>>> Bernie) that will be in the next update which might be relevant:
>>>
>>> If a device has multiple interfaces that implement
>>> a delegating relay function, the device SHOULD allow the same
>>> client identifier (DUID) to have active delegated prefix leases on
>>> more than one interface simultaneously, unless client DUID
>>> uniqueness is necessary for the functioning or security of the
>>> network.  This is to allow client devices with duplicate DUIDs to
>>> function on separate broadcast domains.
>>>
>>>
>>> To clear up your question, we could add the following new routing
>>> requirement:
>>>
>>> For devices with multiple interfaces implementing a delegating relay
>>> function:
>>> If a Relay-reply message is received containing an instance of
>>> OPTION_IAPREFIX with
>>> a prefix that already has an active lease /route on one interface, but
>>> with an
>>> interface identifier (e.g. the Link Address) that is for a different
>>> interface,
>>> then the relay should remove the existing lease / route and bind it to
>>> the
>>> new interface.
>>>
>>> Does that cover it for you?
>>>
>>> Thanks,
>>> Ian
>>>
>>> On 15. Jan 2020, at 02:03, Erik Kline <ek.ietf@gmail.com> wrote:
>>>
>>> I support adoption.
>>>
>>> I am confused about some things though.  Specifically related to 3.4 and
>>> 4.1 G-5.  Should the delegating relay support a client moving from one
>>> interface to another (presumably this just means honoring a request with
>>> previously allocated IA_PDs in it, updating the routes accordingly)?  I
>>> guess, what's the guidance for supporting a duplicate versus detecting a
>>> migration?
>>>
>>> [nits]
>>> S2.1: s/should be understand/should be understood/
>>>
>>> S2.1: s/specificcally/specifically/
>>>
>>> On Sun, Dec 29, 2019 at 8:03 AM Bernie Volz (volz) <volz@cisco.com>
>>> wrote:
>>>
>>>> Hello:
>>>>
>>>>
>>>>
>>>> As follow up from the IETF-106 DHC WG meeting, we are initiating the WG
>>>> call for adoption on
>>>> *https://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/*
>>>> <https://datatracker.ietf..org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/>
>>>> (DHCPv6 Prefix Delegating Relay). This document was presented at IETF-106 –
>>>> see
>>>> https://datatracker.ietf.org/meeting/106/materials/slides-106-dhc-dhcpv6-prefix-delegating-relay-00
>>>> .
>>>>
>>>>
>>>>
>>>> This starts the call for Adoption of this document. Please respond by
>>>> January 14, 2020.
>>>>
>>>>
>>>>
>>>> Thanks in advance for your consideration of whether the WG should or
>>>> should not adopt this document as a work item.
>>>>
>>>>
>>>>
>>>> And, Happy New Year!
>>>>
>>>>
>>>>
>>>>    - Tomek & Bernie
>>>>
>>>>
>>>> _______________________________________________
>>>> dhcwg mailing list
>>>> dhcwg@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>>>
>>>
>>> _______________________________________________
>>> dhcwg mailing list
>>> dhcwg@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>>
>>
>>