Subject: Re: [v6ops] [6lo] Advocating a generalization of RFC8505 to non-6lo LANs

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Jul 2019 11:37:38 +0000

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.

> Not so easy for brownfield, i.e., in networks where classic ND is already used in
> some hosts and some routers.  “Efficient ND” (which was essentially RFC 6775
> for Ethernet and thus also traditional Wi-Fi) mostly didn’t take off at the time
> because we didn’t articulate a cohabitation (“transition”) strategy.  I’m 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 <[email-masked]>
> Sent: jeudi 4 juillet 2019 13:22
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Michael Richardson <[email-masked]>; [email-masked]; V6 Ops List
> <[email-masked]>; 6man <[email-masked]>
> Subject: Re: [6lo] Advocating a generalisation of RFC8505 to non-6lo LANs
> 
> 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.  “Efficient ND” (which was essentially RFC 6775
> for Ethernet and thus also traditional WiFi) mostly didn’t take off at the time
> because we didn’t articulate a cohabitation (“transition”) strategy.  I’m 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üße, Carsten
> 
> 
> > On Jul 4, 2019, at 12:28, Pascal Thubert (pthubert) <[email-masked]>
> 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-transit
> > 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
> > 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 <[email-masked]> On Behalf Of Michael Richardson
> >> Sent: jeudi 4 juillet 2019 02:58
> >> To: [email-masked]; V6 Ops List <[email-masked]>; 6man <[email-masked]>
> >> Subject: Re: [6lo] ND cache entries creation on first-hop routers
> >>
> >>
> >> Brian E Carpenter <[email-masked]> wrote:
> >>>> I’m interested to have a parallel discussion on where RFC 8505 can
> >>>> not apply. In the products and use cases I’m 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   [
> >> ]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [
> >
> > _______________________________________________
> > 6lo mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/6lo
> >
> >

---

From: Mark Smith <[email-masked]>
Date: Thu, 4 Jul 2019 22:38:50 +1000

> 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.

> 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
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Jul 2019 13:09:42 +0000

Hello Mark:

There are a number of things  that the router would like to know in the process:

  *   A sense of lifetime; how long should the router/L3AP expect that the address will be used; at time out, the router can clean up the state.
  *   A sense of order; if a wireless node moves rapidly from a L3AP to the next, or a VM moves rapidly from a server to the next, which is the most recent point of attachment
  *   A sense of ownership; if the router maintains a state about the address for a requested lifetime, then a proof of ownership can be attached, so only the owner of the address can modify the state (SAVI)
  *   A sense of service; what should the router do with that address? Examples that come to mind are inject in a routing protocol, play sleeping proxy or ND proxy.

It does not take new messages but a new option is needed to provide all that information.

All the best,

Pascal

From: Mark Smith <[email-masked]>
Sent: jeudi 4 juillet 2019 14:39
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Carsten Bormann <[email-masked]>; Michael Richardson <[email-masked]>; V6 Ops List <[email-masked]>; 6man <[email-masked]>; [email-masked]
Subject: Re: [6lo] Advocating a generalization of RFC8505 to non-6lo LANs

On Thu., 4 Jul. 2019, 21:38 Pascal Thubert (pthubert), <[email-masked]<mailto:[email-masked]>> wrote:
This is all very right, Carsten.

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

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).

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.

All the best,

Pascal

> From: Carsten Bormann <[email-masked]<mailto:[email-masked]>>
> To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
> Cc: Michael Richardson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; V6 Ops List
> <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
> > On Jul 4, 2019, at 12:28, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
> wrote:
> >
> > Hello Brian:
> >
> >> From: 6lo <[email-masked]<mailto:[email-masked]>> On Behalf Of Michael Richardson
> >> To: [email-masked]<mailto:[email-masked]>; V6 Ops List <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
> >> Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
> >> ]     [email-masked]<mailto:[email-masked]>  http://www.sandelman.ca/        |   ruby on rails    [
> >
> > [email-masked]<mailto:[email-masked]>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Sat, 6 Jul 2019 12:18:48 +1000

Hi Pascal,

On Thu, 4 Jul 2019 at 23:24, Pascal Thubert (pthubert)
<[email-masked]> wrote:
> A sense of lifetime; how long should the router/L3AP expect that the address will be used; at time out, the router can clean up the state.

Already being performed by NUD right now.

NUD avoids the possibility of the router's view of when an address
expires getting out of sync with when the address does or has expired
on a host.

> A sense of order; if a wireless node moves rapidly from a L3AP to the next, or a VM moves rapidly from a server to the next, which is the most recent point of attachment

What sort of device is a "L3AP"? In RFC 8200 we don't have that sort
of device defined, we just have links, hosts, routers and nodes (IPv6
host or router).

I'm guessing it is a combined layer 2/layer 3 device with tight
integration between layer 2 and layer 3 processing? If it is, we
wouldn't want to create a requirement that all layer 2 devices are
also layer 3 routers for all IPv6 networks.

> A sense of ownership; if the router maintains a state about the address for a requested lifetime, then a proof of ownership can be attached, so only the owner of the address can modify the state (SAVI)

I think that can be achieved using using the state that NUD maintains
and is already occurring. For example, an unsolicited NA can be sent
to update remote devices' neighbor cache entry for the address with a
new link-layer address, however the update only occurs if the remove
device already has an existing neighbor cache entry for the address.

> A sense of service; what should the router do with that address? Examples that come to mind are inject in a routing protocol, play sleeping proxy or ND proxy.
>

These requirements seem to be more specific to 6lo environments,
rather than a more general and common cases. For example, hosts'
addresses aren't injected into a routing protocol in most networks.

However, once a router has knowledge of the existence of an address,
then I think what the router uses that address knowledge for, in
addition to forwarding, is out of scope for an address discovery or
registration protocol.

Regards,
Mark.

> On Thu., 4 Jul. 2019, 21:38 Pascal Thubert (pthubert), <[email-masked]> wrote:
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Jul 2019 12:41:04 +0000

Hello Mark:

> > A sense of lifetime; how long should the router/L3AP expect that the
> address will be used; at time out, the router can clean up the state.
> 
> NUD avoids the possibility of the router's view of when an address expires
> getting out of sync with when the address does or has expired on a host.

NUD is still important in RFC 6775/8505. The lifetime of a registration has additional value. It is a negotiated contract that the router will maintain and possibly defend / re-advertise the state during that period. It can be very short for short-lived address (e.g., one wake time of your tablet) and very long for an exit sign. NUD defaults show limits there.

> 
> > A sense of order; if a wireless node moves rapidly from a L3AP to the
> > next, or a VM moves rapidly from a server to the next, which is the
> > most recent point of attachment
> 
> What sort of device is a "L3AP"? In RFC 8200 we don't have that sort of device
> defined, we just have links, hosts, routers and nodes (IPv6 host or router).

Like a L3-switch but wireless. An AP is a bridge that is proactively programmed on the wireless side with the association process, as opposed to a learning (transparent) bridge that requires the broadcast. RFC 6775 / 8505 is the same thing at L3. If you add L3 features like an SVI to the AP, and L3 functions in there like RFC8505, routing, and/or ND proxy, then you have an L3-AP.

> I'm guessing it is a combined layer 2/layer 3 device with tight integration
> between layer 2 and layer 3 processing? If it is, we wouldn't want to create a
> requirement that all layer 2 devices are also layer 3 routers for all IPv6
> networks.

There should be one such thing on the path, we usually place it at the edge, device facing, aka Border Nodes. There are roles to be played at ingress, like the registration, ND snooping, and overlay encapsulation. Others at egress like multicast suppression.

> 
> > A sense of ownership; if the router maintains a state about the
> > address for a requested lifetime, then a proof of ownership can be
> > attached, so only the owner of the address can modify the state (SAVI)
> 
> I think that can be achieved using using the state that NUD maintains and is
> already occurring. For example, an unsolicited NA can be sent to update
> remote devices' neighbor cache entry for the address with a new link-layer
> address, however the update only occurs if the remove device already has an
> existing neighbor cache entry for the address.
> 

True, and we do that already. But a solid and local proof that it is the same guy is better, e.g. in fast mobility to avoid slowing down the roaming, or if the target is unreachable for a second, sleeping, rebooting, whatever, in which case the address is easy to steal. 
The companion draft for RFC 8505 is https://tools.ietf.org/html/draft-ietf-6lo-ap-nd. 

> > A sense of service; what should the router do with that address? Examples
> that come to mind are inject in a routing protocol, play sleeping proxy or ND
> proxy.
> >
> 
> These requirements seem to be more specific to 6lo environments, rather
> than a more general and common cases. For example, hosts'

Another example is the data center underlay, see https://tools.ietf.org/html/draft-ietf-rift-rift-06#section-5.3.3. 

Also 802.11OCB, see https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/.

As soon as your link is multiaccess yet non-transitive, or your subnet is multilink, you should consider L3 routing. Alt you let the L2 do it for you like in Switched Ethernet and Wi-Fi infrastructure mode, but then it comes at a cost that you may be willing to avoid, e.g.,  L3 broadcasts. 

The /64 per host is a valid approach to get there, but it throws ND with the water of the bath and seems wasteful at scale, e.g. , for IOT devices and VMs. 

I'm advocating for a modernization of ND that is not antagonistic to that but complementary with the /64 per host towards a same goal of more L3 / proactive, less broadcasts / reactive.

> However, once a router has knowledge of the existence of an address, then I
> think what the router uses that address knowledge for, in addition to
> forwarding, is out of scope for an address discovery or registration protocol.
> 

Agreed, the registration is abstract to the router operation. The point is that the router operation can be vastly improved by simple things like a sequence number or a lifetime.

All the best,

Pascal

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Jul 2019 14:51:04 +0200

Hi Pascal,

out there again confusing everyone with needlessly invented terminology? :-)

These things are called 6LRs in RFC 6775/8505, for people who want to look up what they do (or do you mean 6LBRs?).

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Jul 2019 14:31:27 +0000

Hello Carsten:

The 6LR, or 6LBR, are logical functions. A L3-switch is a box that has its differences with a router.

All the best,

Pascal

> Sent: lundi 8 juillet 2019 14:51
> Cc: Mark Smith <[email-masked]>; Michael Richardson
> <[email-masked]>; 6man <[email-masked]>; V6 Ops List
> <[email-masked]>; [email-masked]
> >> of device defined, we just have links, hosts, routers and nodes (IPv6 host or
> router).
> >
> > Like a L3-switch but wireless. An AP is a bridge that is proactively
> programmed on the wireless side with the association process, as opposed to
> a learning (transparent) bridge that requires the broadcast. RFC 6775 / 8505 is
> the same thing at L3. If you add L3 features like an SVI to the AP, and L3
> functions in there like RFC8505, routing, and/or ND proxy, then you have an
> L3-AP.
> 
> Hi Pascal,
>