[IPv6] efficient ND (was: Working Group Adoption call for <draft-thubert-6man-ipv6-over-wireless>)

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Eduard:

First we must agree on the architecture but I see you. And I agree that we wasted time. RFC 8505 was done at 6lo because 6MAN was frozen, and there we are now.

Historically speaking, RFC 8505 is the completion/correction of RFC 6775 (*). draft-chakrabarti-nordmark-6man-efficient-nd superseded draft-chakrabarti-nordmark-energy-aware-nd which was based on RFC 6775. Like I said a lot of work was done though outside the 6MAN ML. To your point, we do not want to go back to RFC 6775 because that would be 10 years of good work wasted. We have to start from RFC 8505.

IOW if something is missing in RFC 8505 that was in efficient ND and that we want now (**), then we need a new RFC that extends RFC 8505 and looks adds those efficient ND features. If you think there's stuff in RFC 8505 that we do not want, same thing.

(*) Some mechanisms in RFC 6775 were now updated, e.g., the TID, and which address is registered (the target as opposed to the source). Also the link abstraction is refined, some clarifications happened about how to register link local addresses, stuff like that. Then we built RFC 8928 (securing the registration) and RFC 8929 (ND proxy), a lot of stuff. 

(**) the consistency of the router state and the host state was not verified in RFC 8505. It is now done with https://datatracker.ietf.org/doc/html/draft-ietf-6lo-multicast-registration-12#name-consistent-uptime-option.

All the best,

Pascal


> -----Original Message-----
> From: Vasilenko Eduard <[e-mail]>
> Sent: mardi 24 janvier 2023 16:48
> To: Pascal Thubert (pthubert) <[e-mail]>; Mark Smith
> <[e-mail]>
> Cc: Michael Richardson <[e-mail]>; IPv6 List <[e-mail]>
> Subject: RE: [IPv6] Working Group Adoption call for <draft-thubert-6man-ipv6-
> over-wireless>
> 
> IMHO: it makes sense to return to draft-chakrabarti-nordmark-energy-aware-nd
> Then think about what additional features of WiND (RFC6775+RFC8505) to add in
> the basement.
> And what to put into the optional additional RFC (like MLSN).
> It may be that despite 10 years lost, draft-chakrabarti-nordmark-energy-
> aware-nd should be adopted as it is.
> Ed/
> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:[e-mail]]
> Sent: Tuesday, January 24, 2023 5:34 PM
> To: Mark Smith <[e-mail]>; Vasilenko Eduard
> <[e-mail]>
> Cc: Michael Richardson <[e-mail]>; IPv6 List <[e-mail]>
> Subject: RE: [IPv6] Working Group Adoption call for <draft-thubert-6man-ipv6-
> over-wireless>
> 
> <From someone who implemented frame relay on IBM boxes (3746-9x0), both FRTE
> and FRSE, in the mid-90s, with P2MP and NBMA for IPv4 capability based on
> OSPF.>
> 
> 1) RFC 2590 is disappointing because it requires a multicast emulation. So it
> does not solve the problem, it just moves it elsewhere.
> 2) Section 7 expect a full mesh which is not reasonable.
> 3) bottom line is everyone I'm aware of implements IPv6 as a collection of
> P2P, one per DLCIs.
> => RFC 2590 is a failure, sad when you think that the IPv4 version was quite
> reasonable.
> 
> RFC 3122 was a more reasonable starting point and indeed we tried that first
> (see https://www.ietf.org/archive/id/draft-thubert-3122bis-01.html) in the
> late 2000.
> 
> Then the work evolved to consider the need for the device to form any
> address, anytime. This dismissed refreshing RFC 3122, which is really IPv4
> thinking, one address per interface, in favor of the host announcing its
> addresses when it likes, and with guaranteed routability and ownership for
> the duration it wants, provided that the network can handle it (accepts the
> contract).
> 
> Rationale for the host-based model is that the host may be sleeping or
> disconnected at times, e.g., for energy conservation of because of transient
> connectivity issues, while we expect the router to be always on. This is how
> we came up with RFC 6775, and then RFC 8505 which is the corrected version.
> 
> (as opposed to RFC 2590 and quite like the P2MP model in the case of
> IPv4/OSPF) RFC 8505 is designed for not-onlink and allows the routers to
> reach NBMA destinations leveraging host routes between routers. This is
> exemplified with RPL and BGP in RFC 9010 and draft-thubert-bess-secure-evpn-
> mac-signaling, respectively. In an ESS model, the routers can also play
> classical ND on a common ethernet backbone and proxy ND for Wi-Fi STAs,
> that's RFC 8929.
> 
> Bottom line: there was a lot of brain power, trial-and-error, and real world
> deployment experience since we started looking seriously at NBMA. We now have
> a solid base for an NBMA architecture that works and makes sense for IPv6,
> based on 15 years of WG efforts and implementation experience.
> 
> Cheers,
> 
> Pascal
> 
> 
> > -----Original Message-----
> > From: ipv6 <[e-mail]> On Behalf Of Mark Smith
> > Sent: mardi 24 janvier 2023 13:57
> > To: Vasilenko Eduard <[e-mail]>
> > Cc: Michael Richardson <[e-mail]>; IPv6 List
> > <[e-mail]>
> > Subject: Re: [IPv6] Working Group Adoption call for
> > <draft-thubert-6man-ipv6-
> > over-wireless>
> >
> > On Tue, 24 Jan 2023, 22:07 Vasilenko Eduard,
> > <[e-mail]>
> > wrote:
> > >
> > > > See RFC2491 for IPv6 over NBMA, including ND operation. 24 years
> > > > old this
> > month.
> > >
> > > It forms the basis for subsidiary companion documents that
> > >
> > >    describe details for various specific NBMA technologies (such as
> > > ATM
> > >
> > >    or Frame Relay).
> > >
> > >
> > >
> > > Looks like not finished.
> >
> > RFC 2492
> > RFC 2590
> >
> > > It is not possible to apply it to WiFi.
> >
> > "Certain NBMA networks may provide a form of connectionless service
> >    (e.g. SMDS). In these cases, a "call" or "VC" shall be considered to
> >    implicitly exist if the sender has an NBMA destination address to
> >    which it can transmit packets whenever it desires."
> >
> > Wifi would be such an NBMA link if you don't use broadcasts or multicasts.
> >
> >
> >
> > > Eduard
> > >
> > > From: Mark Smith [mailto:[e-mail]]
> > > Sent: Tuesday, January 24, 2023 1:00 PM
> > > To: Vasilenko Eduard <[e-mail]>
> > > Cc: Lorenzo Colitti <[e-mail]>; Michael Richardson
> > > <[e-mail]>; IPv6 List <[e-mail]>
> > > Subject: Re: [IPv6] Working Group Adoption call for
> > > <draft-thubert-6man-ipv6-over-wireless>
> > >
> > >
> > >
> > >
> > >
> > > On Tue, 24 Jan 2023, 06:28 Vasilenko Eduard,
> > <vasilenko.eduard=[e-mail]> wrote:
> > >
> > > The problem that needs to be solve is the same for 25 years:
> > >
> > > ND should support NBMA or media that emulates multicast with the
> > > great
> > deficiency (like WiFi).
> > >
> > > See RFC2491 for IPv6 over NBMA, including ND operation. 24 years old
> > > this
> > month.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > It is exactly for 6man.
> > >
> > >
> > >
> > > Pascal’s document is not BCP – it is about the opposite “how should
> > > not
> > do”.
> > >
> > > I see Pascal’s document as “requirements”. Requirement is perfectly
> > > fine
> > for 6man.
> > >
> > >
> > >
> > > PS: NBMA support would probably resolve almost everything that
> > > Pascal is
> > trying to discuss.
> > >
> > > Ed/
> > >
> > > From: ipv6 [mailto:[e-mail]] On Behalf Of Lorenzo
> > > Colitti
> > > Sent: Monday, January 23, 2023 9:43 PM
> > > To: Michael Richardson <[e-mail]>
> > > Cc: IPv6 List <[e-mail]>
> > > Subject: Re: [IPv6] Working Group Adoption call for
> > > <draft-thubert-6man-ipv6-over-wireless>
> > >
> > >
> > >
> > > On Mon, Jan 23, 2023 at 8:29 AM Michael Richardson
> > > <[e-mail]>
> > wrote:
> > >
> > > We (the IETF), regularly write and publish documents of this type:
> > > they are BCPs.  They often require people to write code to deal with
> > > specific situations, and they often requirement consensus as to
> > > what/how some types of ND should be used.
> > >
> > >
> > >
> > > 6man is not the right group to publish operational guidance. That
> > > belongs
> > in v6ops.
> > >
> > >
> > >
> > > Fundamentally, I think that the continuing attempt to emulate 1980s
> > > ethernet,
> > > 40 years later, has been a disaster.  It's IPv4 think.  We can do
> > > much better, and I think that it's time that we sat down and wrote
> > > down the ways in which we can do better.
> > >
> > >
> > >
> > > Maybe so. But before we "sit down and rearchitect ND" think we need
> > > a clear
> > statement of the things we want to fix and why. That's not what we
> > have in this document, and in any case, I don't think 6man is the
> > right group to work on such a document.
> > >
> > >
> > >
> > > Please adopt.
> > >
> > >
> > >
> > > Adopt what? A document that explains the history of how ND was done
> > > on
> > certain types of low-power wifi links? A document that explains the
> > issues with ND on some types links? A document that changes the basic
> > architecture of ND to be registration-based rather than peer-to-peer?
> > This document sort of attempts to do all of them, and IMO the
> > inevitable consequence is that it cannot do any of them well.
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list [e-mail] Administrative
> > > Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------