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 7CCE0120655; Thu, 4 Jul 2019 05:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 7B4_CBYo4zXC; Thu, 4 Jul 2019 05:39:03 -0700 (PDT) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 157801205CF; Thu, 4 Jul 2019 05:39:03 -0700 (PDT) Received: by mail-oi1-x230.google.com with SMTP id 65so4790494oid.13; Thu, 04 Jul 2019 05:39:03 -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=+iDzL6OY+gCS133+hfm0hUgDEHBcnVcar3iHciLwlYA=; b=QDbamxiyHopDDXilwT0Rk3gobW6rqUvsoMXIlAqqYWVzLP8eRUFvfDQATYhfNLJiXZ iQYuk3cSanlNs0qX78VqaBXsiYSDZfyH5E4d526LNHGr3CqDbizqy4m14qvzcmfgQ6j8 Ruofv0aivexI46FMa/zZwffHQGZCcTHjkaqmZqgJVEQ6hdbSL+DslaLFx5/oQXFLKP6I 2uGPzOR4OkhSZ9UjoeQelD/P43D0kSk+Kg/VcGblYknBiWMOwOao/TLxYvq1p2v43bRz d9Uy+LZKBp9gYyX6sNfeHsx+lOTSv54WGqy8bkBh/JwNRkJc5SrPYhSCYBN0kf9VC4TY 96WQ== 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=+iDzL6OY+gCS133+hfm0hUgDEHBcnVcar3iHciLwlYA=; b=oLB15N05aeRkdAKg/T7Zil8uWLXLGCbR/BziU72jL4+9v7vG6reG643WDhOp/LPf/C 2/5utk2WmMyfjEtSC/RPb3hdt/AQeRYmh5DU29WliJ2Tfhg9uHr0mK0k0BhOBQcvMxf3 bqvJwkYz/aRBHlE2+b45kMWHH6iTslRBNponcmN2o6gss/vRRaXWVEhfcXtOB+Ebuzvf 6qz0FL12nWUDsoQNi4+CkZoIja2BRvp/hkUFAHMfy4IcLYSuJ+AvZri9+IFDOa7uckx2 WIAWVYYRHxy8tcCiD5qE7HPfFR/vND6YIGCM2Uo5UNffJI6tJ1plGASeVNMhhQ/bsnsP SUEw== X-Gm-Message-State: APjAAAVb+6SZcMKYt6m2xd2pvTgLE/intUacxk8WWgq487Cptt1bTDpO 34riK4Xpk2K29GQTkAMoVJcJu7fAFyJz09PS0Oc= X-Google-Smtp-Source: APXvYqyKkLqUjj9P7detPoef2jilRc06aGtEtSzh390uwxZuNGBskoQQ5YGRsgAAJpPN8inuLqCrvX4Bmw8cps09peA= X-Received: by 2002:aca:d511:: with SMTP id m17mr1749007oig.54.1562243942264; Thu, 04 Jul 2019 05:39:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mark Smith Date: Thu, 4 Jul 2019 22:38:50 +1000 Message-ID: To: "Pascal Thubert (pthubert)" Cc: Carsten Bormann , Michael Richardson , V6 Ops List , 6man <6man@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Content-Type: multipart/alternative; boundary="0000000000003b33ac058cda4333" Archived-At: Subject: Re: [v6ops] [6lo] Advocating a generalization of RFC8505 to non-6lo LANs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 12:39:06 -0000 --0000000000003b33ac058cda4333 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu., 4 Jul. 2019, 21:38 Pascal Thubert (pthubert), wrote: > This is all very right, Carsten. > > > > RFC 6775/8505 on a new (greenfield) foo (as in IP over foo) is pretty > much a > > no-brainer, if that foo has points where the 6LBR functionality is > naturally > > centralized. > > No brainer it is, but for Lorenzo's issues on state preservation or > reconstruction upon router reboot. > I think that can be overcome. I've been thinking for a while how to build something like this using existing protocols and host or router behaviour. Fundamentally two stages: - collect nodes' link local addresses - query nodes' for their other GUA or ULA addresses Collecting nodes LLAs can be done via collecting source addresses from node emitted RSess and/or MLDv2 reports. Once they've been collected, then nodes are unicast queried by routers for their other addresses via either ICMPv6 Node Information queries or Inverse ND. (There is currently a limitation with ICMPv6 NI that it doesn't report temporary addresses for security reasons. That could be lifted by e.g. saying that all addressed including temporaries are reported if the NI query source address is an LLA i.e. limited to a query from an on-link source, or both LLA source and that the LLA is that of a known default router.) A new node on the link effectively announces its LLA to existing routers via RS and MLDv2 joins for solicited node groups for its addresses (and other multicast groups it may join). If a node configures a new address, it joins the address's Solicited Node Multicast group. Routers use that as a signal to unicast query the node it for its updated address list to discover the new address. (DAD is another possible way for routers to collect new address information, however I think Ericsson have some IPR over that idea, and it also doesn't work for anycast addresses, because DADs aren't performed for them). Routers detect when an address disappears via standard ND NUD. A new router on a link can collect existing nodes' LLAs via a general MLD query, as it does anyway to collect the set of multicast groups on the link. Once the new router has that set of LLAs, it then unicast queries the nodes for their other addresses. Perhaps a bit of pedantry, however if nodes are "Neighbours", since we now have possibly multiple addresses per node/neighbour, ND isn't really discovering neighbours, it's actually discovering the presence of addresses, not "neighbours". Address Discovery or Address Presence Discovery would perhaps be a more accurate name for this function. Regards, Mark. > > Not so easy for brownfield, i.e., in networks where classic ND is > already used in > > some hosts and some routers. =E2=80=9CEfficient ND=E2=80=9D (which was= essentially RFC > 6775 > > for Ethernet and thus also traditional Wi-Fi) mostly didn=E2=80=99t tak= e off at > the time > > because we didn=E2=80=99t articulate a cohabitation (=E2=80=9Ctransitio= n=E2=80=9D) strategy. > I=E2=80=99m sure > > we can do that if we put a little more focus on it, leading to another > > specification that describes how to run in mixed classic/efficient ND > networks. > > For I started that at 6lo and there is text in > https://datatracker.ietf.org/doc/html/draft-ietf-6lo-backbone-router , > e.g., in section 3.2. The coexistence is also discussed in > https://tools.ietf.org/html/draft-thubert-6lo-unicast-lookup but at some > point it is not a 6lo problem anymore and that work should really move > somewhere else. > > Being non-maintenance, it seems too early for 6MAN. If so maybe we should > form a short-lived WG to sort out the issues raised by Lorenzo, yours > (coexistence) and mine (limit use of broadcast / interface with a fabric > mapping server and do unicast lookup when possible). > > All the best, > > Pascal > > > -----Original Message----- > > From: Carsten Bormann > > Sent: jeudi 4 juillet 2019 13:22 > > To: Pascal Thubert (pthubert) > > Cc: Michael Richardson ; 6lo@ietf.org; V6 Ops > List > > ; 6man <6man@ietf.org> > > Subject: Re: [6lo] Advocating a generalisation of RFC8505 to non-6lo LA= Ns > > > > RFC 6775/8505 on a new (greenfield) foo (as in IP over foo) is pretty > much a > > no-brainer, if that foo has points where the 6LBR functionality is > naturally > > centralized. > > > > Not so easy for brownfield, i.e., in networks where classic ND is > already used in > > some hosts and some routers. =E2=80=9CEfficient ND=E2=80=9D (which was= essentially RFC > 6775 > > for Ethernet and thus also traditional WiFi) mostly didn=E2=80=99t take= off at > the time > > because we didn=E2=80=99t articulate a cohabitation (=E2=80=9Ctransitio= n=E2=80=9D) strategy. > I=E2=80=99m sure > > we can do that if we put a little more focus on it, leading to another > > specification that describes how to run in mixed classic/efficient ND > networks. > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > On Jul 4, 2019, at 12:28, Pascal Thubert (pthubert) < > pthubert@cisco.com> > > wrote: > > > > > > Hello Brian: > > > > > > Yes, I'm willing to make the case. > > > > > > There are a number of reasons to enable a registration method on beyo= nd > > 6lo networks: > > > - It is useful in wireless in general because it addresses non-transi= t > > > multipoint links (see > > > https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireles= s > > > /) and NBMA ML-subnets > > > - it is useful in particular in Wi-Fi because it reduces the need for > broadcast > > quite dramatically. > > > - It is useful in a switched fabric to maintain an accurate state in > > > the overlay mapping server (see > > > https://datatracker.ietf.org/doc/draft-thubert-6lo-unicast-lookup/) > > > - It is useful in a situation of host mobility in general, (see the > > > discussion in > > > https://tools.ietf.org/html/draft-ietf-rift-rift-06#section-5.3.3 ) > > > - It is useful for routers with hardware assist forwarding to avoid > > > the punting dance and dropping of packets > > > - It provides SAVI properties with a workable Secure ND (see > > > https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/) > > > - It provides an abstract interface to the router to get routing > > > services (already used with RIFT, RPL, see > > > https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/, and > > > ND proxy, see > > > https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/) > > > - It solves a number of problems including Jen's, but also sleeping > devices on > > non-6lo networks, remote DOS against router and ND cache, and more. > > > > > > All in all I see it as a much needed modernization of ND to cope with > the > > evolutions of the network (IOT, Wi-Fi and overlays) and with the new > needs > > and behaviors (instant connectivity, fast roaming). > > > > > > All the best, > > > > > > Pascal > > > > > >> -----Original Message----- > > >> From: 6lo <6lo-bounces@ietf.org> On Behalf Of Michael Richardson > > >> Sent: jeudi 4 juillet 2019 02:58 > > >> To: 6lo@ietf.org; V6 Ops List ; 6man <6man@ietf.org> > > >> Subject: Re: [6lo] ND cache entries creation on first-hop routers > > >> > > >> > > >> Brian E Carpenter wrote: > > >>>> I=E2=80=99m interested to have a parallel discussion on where RFC = 8505 can > > >>>> not apply. In the products and use cases I=E2=80=99m aware of, it = could, > > >>>> since we are actually faking it by snooping ND and DHCP to achieve > > >>>> similar but less accurate results. > > >> > > >>> So if you are advocating a generalisation of RFC8505 to non-6lo > > >>> LANs, that's certainly a discussion we could have, IMHO. > > >> > > >> I think that it could be applied in situations of servers, such as > > >> data centers where there are multiple tenants. (Many VM > > >> infrastructures have shared front-end networks) > > >> > > >> I think that temporary addressess are not a feature in some of those > > >> deployments that everyone wants, and thus having a registration > > >> system is a feature. > > >> > > >> This does not solve the smartphone on new WIFI issue, which is a > > >> different situation completely. > > >> > > >> -- > > >> ] Never tell me the odds! | ipv6 mesh > networks [ > > >> ] Michael Richardson, Sandelman Software Works | IoT > architect [ > > >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > > > > _______________________________________________ > > > 6lo mailing list > > > 6lo@ietf.org > > > https://www.ietf.org/mailman/listinfo/6lo > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --0000000000003b33ac058cda4333 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu., 4 Jul. 2019, 21:38 Pascal Thubert (pthubert),= <pthubert@cisco.com> wrote:
This is all very right, Carsten.


> RFC 6775/8505 on a new (greenfield) foo (as in IP over foo) is pretty = much a
> no-brainer, if that foo has points where the 6LBR functionality is nat= urally
> centralized.

No brainer it is, but for Lorenzo's issues on state preservation or rec= onstruction upon router reboot.

I think that can be overcome.

I've been thinking for a while ho= w to build something like this using existing protocols and host or router = behaviour.

Fundamentally= two stages:

- collect n= odes' link local addresses

- query nodes' for their other GUA or ULA addresses

Collecting nodes LLAs can be done vi= a collecting source addresses from node emitted RSess and/or MLDv2 reports.=

Once they've been c= ollected, then nodes are unicast queried by routers for their other address= es via either ICMPv6 Node Information queries or Inverse ND.

(There is currently a limitation with= ICMPv6 NI that it doesn't report temporary addresses for security reas= ons. That could be lifted by e.g. saying that all addressed including tempo= raries are reported if the NI query source address is an LLA i.e. limited t= o a query from an on-link source, or both LLA source and that the LLA is th= at of a known default router.)

A new node on the link effectively announces its LLA to existing rou= ters via RS and MLDv2 joins for solicited node groups for its addresses (an= d other multicast groups it may join).

If a node configures a new address, it joins the address'= ;s Solicited Node Multicast group. Routers use that as a signal to unicast = query the node it for its updated address list to discover the new address.=

(DAD is another possibl= e way for routers to collect new address information, however I think Erics= son have some IPR over that idea, and it also doesn't work for anycast = addresses, because DADs aren't performed for them).

Routers detect when an address disappears v= ia standard ND NUD.

A ne= w router on a link can collect existing nodes' LLAs via a general MLD q= uery, as it does anyway to collect the set of multicast groups on the link.= Once the new router has that set of LLAs, it then unicast queries the node= s for their other addresses.


Perhaps a bit of pedantry, however if node= s are "Neighbours", since we now have possibly multiple addresses= per node/neighbour, ND isn't really discovering neighbours, it's a= ctually discovering the presence of addresses, not "neighbours". = Address Discovery or Address Presence Discovery would perhaps be a more acc= urate name for this function.

Regards,
Mark.


=

> Not so easy for brownfield, i.e., in networks where classic ND is alre= ady used in
> some hosts and some routers.=C2=A0 =E2=80=9CEfficient ND=E2=80=9D (whi= ch was essentially RFC 6775
> for Ethernet and thus also traditional Wi-Fi) mostly didn=E2=80=99t ta= ke off at the time
> because we didn=E2=80=99t articulate a cohabitation (=E2=80=9Ctransiti= on=E2=80=9D) strategy.=C2=A0 I=E2=80=99m sure
> we can do that if we put a little more focus on it, leading to another=
> specification that describes how to run in mixed classic/efficient ND = networks.

For I started that at 6lo and there is text in https://datatracker.ietf.org/doc/html/= draft-ietf-6lo-backbone-router , e.g., in section 3.2. The coexistence = is also discussed in https://tools.ietf.org/html/draft-thubert-6lo-unicast-lookup but at = some point it is not a 6lo problem anymore and that work should really move= somewhere else.

Being non-maintenance, it seems too early for 6MAN. If so maybe we should f= orm a short-lived WG to sort out the issues raised by Lorenzo,=C2=A0 yours = (coexistence) and mine (limit use of broadcast / interface with a fabric ma= pping server and do unicast lookup when possible).

All the best,

Pascal

> -----Original Message-----
> From: Carsten Bormann <cabo@tzi.org>
> Sent: jeudi 4 juillet 2019 13:22
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>= ;
> Cc: Michael Richardson <mcr+ietf@sandelman.ca&g= t;; 6lo@ietf.org; V6 Ops List
> <v6ops@ietf.org>; 6man <6man@ietf.org>= ;
> Subject: Re: [6lo] Advocating a generalisation of RFC8505 to non-6lo L= ANs
>
> RFC 6775/8505 on a new (greenfield) foo (as in IP over foo) is pretty = much a
> no-brainer, if that foo has points where the 6LBR functionality is nat= urally
> centralized.
>
> Not so easy for brownfield, i.e., in networks where classic ND is alre= ady used in
> some hosts and some routers.=C2=A0 =E2=80=9CEfficient ND=E2=80=9D (whi= ch was essentially RFC 6775
> for Ethernet and thus also traditional WiFi) mostly didn=E2=80=99t tak= e off at the time
> because we didn=E2=80=99t articulate a cohabitation (=E2=80=9Ctransiti= on=E2=80=9D) strategy.=C2=A0 I=E2=80=99m sure
> we can do that if we put a little more focus on it, leading to another=
> specification that describes how to run in mixed classic/efficient ND = networks.
>
> Gr=C3=BC=C3=9Fe, Carsten
>
>
> > On Jul 4, 2019, at 12:28, Pascal Thubert (pthubert) <pthubert@cisco.com>
> wrote:
> >
> > Hello Brian:
> >
> > Yes, I'm willing to make the case.
> >
> > There are a number of reasons to enable a registration method on = beyond
> 6lo networks:
> > - It is useful in wireless in general because it addresses non-tr= ansit
> > multipoint links (see
> > https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless
> > /) and NBMA ML-subnets
> > - it is useful in particular in Wi-Fi because it reduces the need= for broadcast
> quite dramatically.
> > - It is useful in a switched fabric to maintain an accurate state= in
> > the overlay mapping server (see
> > ht= tps://datatracker.ietf.org/doc/draft-thubert-6lo-unicast-lookup/)
> > - It is useful in a situation of host mobility in general, (see t= he
> > discussion in
> > htt= ps://tools.ietf.org/html/draft-ietf-rift-rift-06#section-5.3.3 )
> > - It is useful for routers with hardware assist forwarding to avo= id
> > the punting dance and dropping of packets
> > - It provides SAVI properties with a workable Secure ND (see
> > https://datatr= acker.ietf.org/doc/draft-ietf-6lo-ap-nd/)
> > - It provides an abstract interface to the router to get routing<= br> > > services (already used with RIFT, RPL, see
> > http= s://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/, and
> > ND proxy, see
> > http= s://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/)
> > - It solves a number of problems including Jen's, but also sl= eeping devices on
> non-6lo networks, remote DOS against router and ND cache, and more. > >
> > All in all I see it as a much needed modernization of ND to cope = with the
> evolutions of the network (IOT, Wi-Fi and overlays) and with the new n= eeds
> and behaviors (instant connectivity, fast roaming).
> >
> > All the best,
> >
> > Pascal
> >
> >> -----Original Message-----
> >> From: 6lo <6lo-bounces@ietf.org> On Be= half Of Michael Richardson
> >> Sent: jeudi 4 juillet 2019 02:58
> >> To: 6lo@ietf.org; V6 Ops List <v6ops@ietf.= org>; 6man <6man@ietf.org>
> >> Subject: Re: [6lo] ND cache entries creation on first-hop rou= ters
> >>
> >>
> >> Brian E Carpenter <brian.e.carpenter@g= mail.com> wrote:
> >>>> I=E2=80=99m interested to have a parallel discussion = on where RFC 8505 can
> >>>> not apply. In the products and use cases I=E2=80=99m = aware of, it could,
> >>>> since we are actually faking it by snooping ND and DH= CP to achieve
> >>>> similar but less accurate results.
> >>
> >>> So if you are advocating a generalisation of RFC8505 to n= on-6lo
> >>> LANs, that's certainly a discussion we could have, IM= HO.
> >>
> >> I think that it could be applied in situations of servers, su= ch as
> >> data centers where there are multiple tenants. (Many VM
> >> infrastructures have shared front-end networks)
> >>
> >> I think that temporary addressess are not a feature in some o= f those
> >> deployments that everyone wants, and thus having a registrati= on
> >> system is a feature.
> >>
> >> This does not solve the smartphone on new WIFI issue, which i= s a
> >> different situation completely.
> >>
> >> --
> >> ]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never= tell me the odds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| ipv6 mesh networks [
> >> ]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2= =A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 IoT architect=C2=A0 =C2=A0[
> >> ]=C2=A0 =C2=A0 =C2=A0mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [
> >
> > _______________________________________________
> > 6lo mailing list
> > 6lo@ietf.org
> > https://www.ietf.org/mailma= n/listinfo/6lo
> >
> >

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