IETF Logo Mail Archive

RE: on-link and off-link

Vasilenko Eduard <vasilenko.eduard@huawei.com> Tue, 13 July 2021 07:37 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7E53A1BA9 for <ipv6@ietfa.amsl.com>; Tue, 13 Jul 2021 00:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ZeiZMBPZv9tJ for <ipv6@ietfa.amsl.com>; Tue, 13 Jul 2021 00:37:26 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D233A1BA5 for <ipv6@ietf.org>; Tue, 13 Jul 2021 00:37:26 -0700 (PDT)
Received: from fraeml713-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GPC1H5XCSz6J67N; Tue, 13 Jul 2021 15:28:51 +0800 (CST)
Received: from msceml704-chm.china.huawei.com (10.219.141.143) by fraeml713-chm.china.huawei.com (10.206.15.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 13 Jul 2021 09:37:17 +0200
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml704-chm.china.huawei.com (10.219.141.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 13 Jul 2021 10:37:17 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.2176.012; Tue, 13 Jul 2021 10:37:17 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "Wes Beebee (wbeebee)" <wbeebee@cisco.com>, Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>, "ipv6@ietf.org" <ipv6@ietf.org>
CC: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Subject: RE: on-link and off-link
Thread-Topic: on-link and off-link
Thread-Index: AQHXdyb7YXMuWgk+gkikqI5k+gcOz6s/dH1SgAADpuCAABDEgIAA+dIg
Date: Tue, 13 Jul 2021 07:37:17 +0000
Message-ID: <321397e61bf142c69853bff15515c3f8@huawei.com>
References: <162512790860.6559.14490468072475126698@ietfa.amsl.com> <CAFU7BAT0O9nsuhs5FyNjvPfRKY+EM1fLYKaMYTwaPg2QjZAEpA@mail.gmail.com> <61e14cd7-ff37-5380-e547-8a9b6d3993da@gmail.com> <CAFU7BASF-vas+PP2dVNXuqScQArC+joB-fwRGzG3UZnsqq1QJg@mail.gmail.com> <6A22DCF6-5132-44D3-AB45-E9C151376D2C@cisco.com> <6f6ab3f9-daa8-a468-1abc-f32a22497af2@gmail.com> <m1m2xiY-0000FNC@stereo.hq.phicoh.net> <3652d4977d7540469730c35c83e20d60@huawei.com> <ADD19F44-5234-458A-8E3D-8E9775AABF38@cisco.com>
In-Reply-To: <ADD19F44-5234-458A-8E3D-8E9775AABF38@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.197.11]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/UT-Wx9KXkPSdENGM5AFv1pSyH2A>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Jul 2021 07:37:31 -0000

TR-177 in general and annex B in detail elaborates DAD proxy for BNG. Some sort of filtering is mandatory for broadband telco services because of LI, billing - traffic should go through BNG.
I have not seen equivalent discussion in IETF.

IPv4 has additionally NHRP that was not extended to IPv6. NHRP was more popular then proxy for IPv4.
RFC 2333: "NHRP can be used in host-host, host-router and router-host  communications."
Eduard
-----Original Message-----
From: Wes Beebee (wbeebee) [mailto:wbeebee@cisco.com] 
Sent: Monday, July 12, 2021 10:33 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>; ipv6@ietf.org
Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Subject: Re: on-link and off-link 

I agree that NS(DAD) for LLA has to be handled with care - and that's what we did with our NBMA link that's been working fine for tens of millions (probably hundreds of millions by now) of people for the past decade, which supports IPv6 fine by the way.  And yes, we implemented IPv6 multicast on that link too - everything has to be controlled by the hub site (think really big specialized hardware router) on an NBMA link, which is true for IPv4 as well.

- Wes

On 7/12/21, 11:41 AM, "ipv6 on behalf of Vasilenko Eduard" <ipv6-bounces@ietf.org on behalf of vasilenko.eduard@huawei.com> wrote:

    NBMA or P2MP are not supported by IPv6 anyway because it is not possible to check LLA uniqueness - multicast does not work.
    LLA proxy is needed on the hub site.
    Ed/
    -----Original Message-----
    From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Philip Homburg
    Sent: Monday, July 12, 2021 6:20 PM
    To: ipv6@ietf.org
    Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>
    Subject: Re: on-link and off-link 

    > I think one question
    > might be: do we agree that each IP address is assigned on an 
    > interface, and thus is on-link on a particular link?

    This is not correct. On a NBMA link it is possible that all GUA addresses are not on-link.

    The conceptual model of on-link is that a host can use neighbor discovery to find an onlink neighbor. If the neighbor is not on-link then traffic has to go (at least initially) through a default router.

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

v2.14.0 | Report a Bug | By Email