Re: V4 via V6 and IGP routing protocols
Mark Tinka wrote: MPLS with nested labels, which is claimed to scale because nesting represents route hierarchy, just does not scale because source hosts are required to provide nested labels, which means the source hosts have the current most routing table at destinations, which requires flat routing without hierarchy or on demand, that is, flow driven, look up of detailed routing tables of destinations at a distance. This detail is limited to PE devices (ingress/egress). As it requires >> flat routing without hierarchy or on >> demand, that is, flow driven, look up of detailed routing tables >> of destinations at a distance. MPLS is just broken. You don't need to carry a BGP table in the P devices (core), as only label swapping is required. So? Fair point, it is a little heavy for an edge box, Requiring >> flat routing without hierarchy means it is fatally heavy for intermediate boxes. >> or on >> demand, that is, flow driven, look up of detailed routing tables >> of destinations at a distance. means it is fatally heavy for edge boxes. > In the end, having a flat L2 domain was just simpler. That's totally against the CATENET model. Why, do you think, NHRP was abandoned? > we've never ran into an issue carrying > thousands of IS-IS IPv4/IPv6 routes this way. Thousands of? Today with so powerful CPUs, that is a small network. So? Masataka Ohta
Re: V4 via V6 and IGP routing protocols
On 4/4/22 15:45, Masataka Ohta wrote: MPLS with nested labels, which is claimed to scale because nesting represents route hierarchy, just does not scale because source hosts are required to provide nested labels, which means the source hosts have the current most routing table at destinations, which requires flat routing without hierarchy or on demand, that is, flow driven, look up of detailed routing tables of destinations at a distance. This detail is limited to PE devices (ingress/egress). You don't need to carry a BGP table in the P devices (core), as only label swapping is required. Fair point, it is a little heavy for an edge box, but I imagine nearly any feature of consequence is going to be high-touch, high-impact, for the edge. Those who have solved this problem with SR can comment, as we don't run it. We did experiment with IS-IS hierarchy (L1 within the data centre and L2 between them), but Route Leaking (copying L2 routes into L1) was a requirement in order to facilitate FEC creation (/32 for IPv4, /128 for IPv6). In the end, having a flat L2 domain was just simpler. It's been years, and on today's hardware, we've never ran into an issue carrying thousands of IS-IS IPv4/IPv6 routes this way. Mark.
Re: V4 via V6 and IGP routing protocols
The other question for this list I'd basically had was this: > https://datatracker.ietf.org/doc/html/draft-ietf-babel-v4viav6 > Please let me know if you feel that it should be possible to > completely disable v4-via-v6 even on newer kernels, and whether you > feel that v4-via-v6 should be disabled by default. (The "Security > Considerations" section of the draft cited above might be > interesting.)"
Re: V4 via V6 and IGP routing protocols
Dave Taht wrote: Are MPLS or SR too heavy a bat? MPLS was not an option at the time. It might become one. MPLS with nested labels, which is claimed to scale because nesting represents route hierarchy, just does not scale because source hosts are required to provide nested labels, which means the source hosts have the current most routing table at destinations, which requires flat routing without hierarchy or on demand, that is, flow driven, look up of detailed routing tables of destinations at a distance. Masataka Ohta
Re: V4 via V6 and IGP routing protocols
On Mon, Apr 4, 2022 at 5:16 AM Mark Tinka wrote: > > > > On 4/4/22 03:06, Dave Taht wrote: > > > I'm actually not here to start a debate... happy to learn that the v4 > > over v6 feature I'm > > playing with actually exists in another protocol, mainly. I'm > > critically dependent on > > source specific routing, also, so I am hoping there's an isis or ospf > > that can do > > what I need, or now that I have more routers with enough memory, switch back > > to an ibgp. > > Are MPLS or SR too heavy a bat? MPLS was not an option at the time. It might become one. Don't know diddly about the current state of SR. What happened in the mesh wifi market circa 2015 is that eero perfected a superset of (layer 2) 802.11s that scaled well enough (3 hops max) to create a market. the eero 5 was great, the 6 a step backwards, I'm rather impressed by their new 6E product... on paper. It was bridging ethernet multicast to wifi multicast that was a real killer to performance then. Various solutions have appeared to lighten that load, arp proxying (don't know about ND), and a version of mdns that can upgrade to unicast, and fq_codel for wifi is out there on a lot of products now, like the ath9k, ath10k, pretty much all of intel and mediateks chips, iOS and OSX. Trying to revisit a few assumptions as to where the real problems are now. > > > > yes, and for smaller networks that are interconnecting, bgp can be > > too heavyweight also. > > I know tons of small networks using Mikrotik to run their BGP backbone. > Seems to work :-). BGP may end up what I switch to, but I note I have other requirements than just a robust routing protocol. middlebox fq_codel solutions like preseem's are now pretty common in that market, but the rightest answer was to move good queue management to every fast->slow transition as close to the hw as possible (rfc7567). Mikrotik only recently added fq_codel and cake support. There's some marvelous pictures of how well that's working if you login here: https://forum.mikrotik.com/viewtopic.php?t=179307#p885613 Regrettably their IPv6 support was broken entirely when I last checked a month or two back, I don't think they have the fq_codel native for wifi code operational either. Now that ISP rates are so much better than before, WiFi has become the bloated bottleneck for many. There's a real cliff for range, I was recently at a large apartment building where the usable range was under 8 feet due to all the APs competing. Sells more APs though... One of my holy grails from a working combination of fq_codel for wifi/ethernet meshes and a good routing protocol was a workable RTT, as opposed to loss based, metric. I was kind of agnostic as to the underlying routing protocol, but I really wanted it to fit in memory and scale well past 3 hops. Since then I mostly gave up on homenet's ideas, am revisiting older ones (like ospf and RPL) to see what progress was made there. It's a little OT for nanog, aside from a goal being better e2e connectivity and simplicity. I'll take another look at the current state of ospfv3, isis, and mpls. > Mark. -- I tried to build a better future, a few times: https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org Dave Täht CEO, TekLibre, LLC
Re: V4 via V6 and IGP routing protocols
Pascal Thubert (pthubert) wrote: Hello Ohta-san Hi, it is hopeless. If you look at it, LS - as OSPF and ISIS use it - My team developed our own. Hierarchical QoS Link Information Protocol (HQLIP) https://datatracker.ietf.org/doc/draft-ohta-ric-hqlip/ which support 256 levels of hierarchy with hierarchical thinning of link information, including available QoS. depends on the fact that all nodes get the same information and react the same way. Isn't that hopeless too? If you insist on OSPF or ISIS, yes. Clearly, the above limits LS applicability to stable links and topologies, and powered devices. This is discussed at length in https://datatracker.ietf.org/doc/html/draft-ietf-roll-protocols-survey. OLSRv2 pushes the model to its limit, don't drive it any faster. You don't have to say "low power" to notice OSPF not so good. With just a quick look at OSPF, I noticed OSPF effectively using link local reliable multicast hopeless (as a basis to construct hierarchical QoS routing system). Worse, minimum hello interval of OSPF is too long for quick recovery (low power is not required, for example, at backbone), which is why additional complication to have an optical layer were considered useful. RIFT (https://datatracker.ietf.org/doc/draft-ietf-rift-rift/) shows that evolution outside that box is possible. OK. RIFT is "for Clos and fat-tree network topologies" of data centers. > RIFT develops > anisotropic routing concepts (arguably from RPL) and couples DV and > LS to get the best of both worlds. It usually results in the worst of both, I'm afraid. But none of the above allow an source router to decide once and for all what it will get. As there are not so many alternative routes with Clos and fat-tree network topologies of data centers, pure source routing combined with some transport protocol to simultaneously try multiple routes should be the best solution, IMO, because avoiding link saturation is an important goal. When you drive and the street is blocked, you can U-turn around the block and rapidly restore the shortest path. The protocols above will not do that; this is why technologies such as LFA were needed on top. But then the redundancy is an add-on as opposed to a native feature of the protocol. What if network is not very large and minimum hello interval of OSPF is 1ms? Thinking outside that box would then mean: - To your end-to-end principle point, let the source decide the packet treatment (including path) based on packet needs To apply the E2E argument for LS routing, all the routers are *dumb* intermediate systems to quickly flood LS. At the same time, all the routers are ends to initiate flooding of local LS, to receive flooded LS and to compute the best route to destinations in a way consistent with other routers because they share same flooded LS except during short transition periods. Masataka Ohta
Re: V4 via V6 and IGP routing protocols
On 4/4/22 03:06, Dave Taht wrote: I'm actually not here to start a debate... happy to learn that the v4 over v6 feature I'm playing with actually exists in another protocol, mainly. I'm critically dependent on source specific routing, also, so I am hoping there's an isis or ospf that can do what I need, or now that I have more routers with enough memory, switch back to an ibgp. Are MPLS or SR too heavy a bat? yes, and for smaller networks that are interconnecting, bgp can be too heavyweight also. I know tons of small networks using Mikrotik to run their BGP backbone. Seems to work :-). Mark.
Re: V4 via V6 and IGP routing protocols
On 4/4/22 02:55, Dave Taht wrote: it was how hard adding source specific routing to isis turned out to be that turned me. At the time I needed simple means to get ipv6 working on multiple consumer uplinks. I suppose the presence of MPLS (and SR) for many operators is probably why this use-case was not pushed hard by that community in the IGP. I'm sad to hear that those two still have to co-exist. I'd given up on how static both routing protocols had become in light of my wireless requirements way back then, also memory requirements. Babel had turned out to be the only way to get teeny routers to route a few thousand ipv6 routes as well as ipv4 over wifi mesh networks. Given a good number of boxes are now based on x86 platforms, control plane management of the "classic" IGP's is not a major drama for a few thousand entries. One is more likely to run into FIB issues (as we have done). It's possible that at least one operator is using OSPFv3 for both IPv4 and IPv6, but they haven't come out publicly to announce this :-). We (and many others) have been running IS-IS for both IP protocols, without major issue over the years. I figured it had made zero penetration outside of that world despite our efforts to get it into frr, bird, etc. You're certainly right about that one... Mark.
RE: V4 via V6 and IGP routing protocols
Hello Ohta-san > it is hopeless. If you look at it, LS - as OSPF and ISIS use it - depends on the fact that all nodes get the same information and react the same way. Isn't that hopeless too? Clearly, the above limits LS applicability to stable links and topologies, and powered devices. This is discussed at length in https://datatracker.ietf.org/doc/html/draft-ietf-roll-protocols-survey. OLSRv2 pushes the model to its limit, don't drive it any faster. We have a panel of protocols and it's probably a question of selecting the best fit for a use case. And yes, probably for most people in this list, learning a stable topology with a link state protocol is the best choice available. To the point of this thread, BABEL thinks inside the same box as its DV predecessors, so I expect that the reasons for selecting LS inside your network would still apply. RIFT (https://datatracker.ietf.org/doc/draft-ietf-rift-rift/) shows that evolution outside that box is possible. RIFT develops anisotropic routing concepts (arguably from RPL) and couples DV and LS to get the best of both worlds. So it's not definitely either/or LS/DV after all. But none of the above allow an source router to decide once and for all what it will get. Because the routing decision is made again at each hop in a fashion that may contradict one of the previous hops. From there, it's either micro-loops or freezing, and in both cases, transient interruption of service. Isn't that hopeless too? The real issues of that thinking inside the ususal box are 1) that packets should "follow the arrows" along a path which certainly leads to loss when one link or node is broken along the arrows, and 2) greediness. All the protocols above are greedy, meaning that every hop that a packet made has to be progress towards the destination, and this dramatically reduces the opportunity to forward packets to destination. When you drive and the street is blocked, you can U-turn around the block and rapidly restore the shortest path. The protocols above will not do that; this is why technologies such as LFA were needed on top. But then the redundancy is an add-on as opposed to a native feature of the protocol. Thinking outside that box would then mean: - To your end-to-end principle point, let the source decide the packet treatment (including path) based on packet needs - congruence with shortest path when there is no breakage - neither micro-loop nor freeze when there's a breakage, - something like LFA-inside to survive one breakage, and possibly multiple ones, along the way While DV is capable to form Non-ECMP DAGs while inside-the-box LS is not, I will agree with you that DV is quite hopeless to achieve the goals above. This is why my personal favorite can be classified as an LS protocol done differently. What it does is: - use the LSDB as is - reverse SPF so the destination computes the tree "towards self" as opposed to "towards everybody else" - this just means use the incoming metric - tweak SPF to stitch selected branches in the tree to build "LFA-like" alternates, forming arcs that end in other arcs till destination, as opposed to arrows to be followed - add a step where the destination injects the path towards self along that path but reversed, using source routing in the control plane and tweaked to transport a serialized graph. Yet another sleeping beauty on the other side of the PM wall, waiting for the kiss of a sizable market. Hint, it's not the ill-fated U-Turn protocol, that one had its own issues. Keep safe; Pascal > -Original Message- > From: NANOG On Behalf Of > Masataka Ohta > Sent: dimanche 3 avril 2022 15:46 > To: nanog@nanog.org > Subject: Re: V4 via V6 and IGP routing protocols > > Dave Taht wrote: > > > Periodically I still do some work on routing protocols. 12? years ago > > I had kind of given up on ospf and isis, and picked the babel protocol > > as an IGP for meshy networks because I felt link-state had gone as far > > as it could and somehow unifying BGP DV with an IGP that was also DV > > (distance vector) seemed like a path forward. > > As DV depends other routers to choose the best path from several > candidates updated asynchronously, which means it is against the E2E > principle and decisions by other routers are delayed a lot to wait all the > candidates are updated, it is hopeless. > > OTOH, LS only allows routers distribute the current most link states > instantaneously and let end systems of individual routers compute the best > path, LS converges quickly. > > BGP is DV because there is no way to describe policies of various domains > and, even if it were possible, most, if not all, domains do not want to > publish their policies in full detail. > > > My question for this list is basically, has anyone noticed or fiddled > > with babel? > > No. > > Masataka Ohta
RE: V4 via V6 and IGP routing protocols
Hello Dave: There's RFC 8950 in the context of BGP. That's a refresher of RFC 5589 which is the one we typically refer to internally. I glanced at homenet too early, and then too late. Too early, it seemed that the protocol would be OSPFv3; no discussion. So I left till too late, when the choice was between ISIS and BABEL, and the group would not even consider arguments. RPL seemed to do the trick without the need to define anything new, in my book. It supports multihoming by defining as many topologies, no need for source/destination, radios, IoT, mobility, things you'll find at home. But hey, those of us who understand RPL were not there at the right time and there we get yet another fragmentation. Not the IETF at its best. Nothing against BABEL, it's neat. Well written specs, much better than we did with RPL. A modernized DV, addressing the same space as RIP or EIGRP - though I really like the DUAL piece in EIGRP. More of a core technology than of an edge/mobile like RPL, they could be complementary. And then BABEL has a nice dynamic community including openWRT developers, that's a huge strength. Not sure you'll find it in your usual vendor hardware though. Keep safe; Pascal > -Original Message- > From: NANOG On Behalf Of Dave > Taht > Sent: lundi 4 avril 2022 2:56 > To: Mark Tinka > Cc: NANOG > Subject: Re: V4 via V6 and IGP routing protocols > > On Sun, Apr 3, 2022 at 12:04 PM Mark Tinka wrote: > > > > > > > > On 4/3/22 13:55, Dave Taht wrote: > > > > > Periodically I still do some work on routing protocols. 12? years > > > ago I had kind of given up on ospf and isis, and picked the babel > > > protocol as an IGP for meshy networks because I felt link-state had > > > gone as far as it could and somehow unifying BGP DV with an IGP that > > > was also DV (distance vector) seemed like a path forward. > > > > To scale the IGP, we only carry Loopbacks and interfaces (backbone > > infrastructure) in the IGP. Many operators have been doing this, for > > some time now, as a best pratice. > > > > Customer routes as well as the DFZ is carried in iBGP. > > > > The only issue we have hit with this design is hardware that ships > > with limited FIB (you're talking 4,000 slots or less). While this can > > be mitigated with things like 6PE and RFC 3107, there are, now, tons > > of hardware shipping without this physical restriction. For me, the > > simpler, the better. > > > > > > > My question for this list is basically, has anyone noticed or > > > fiddled with babel? It's supported in FRR, bird, and a very small > > > standalone daemon. > > > > Never heard of it as an IGP until now :-). > > We'd somewhat foolishly made it a requirement in ietf homenet. > > it was how hard adding source specific routing to isis turned out to be > that turned me. > At the time I needed simple means to get ipv6 working on multiple consumer > uplinks. > > That later spawned a now mostly dead attempt to unify ipv4 and ipv6 > address distribution called hnet. > > I'm fiddling with the new ipv4 over ipv6 stuff now in trying to > interconnect several ipv4 networks over multiple p2p links. > > > > > Googl'ing: > > > > https://en.wikipedia.org/wiki/Babel_(protocol) > > > > > > > To recap that: > > > > > > "V4-via-v6 routing is a routing technique that allows routers with > > > only IPv6 addresses (including link-locals) to forward IPv4 packets. > > > It doesn't involve encapsulation (tunnelling), it doesn't involve > > > translation (NAT), it just works. For details, please see > > > > Since around Junos 9 (2007), OSPFv3 shipped with the ability to carry > > IPv4 NLRI over an IPv6-only network. We never did implement that, as > > IS-IS integrated both protocols already. But it's been there for a > > while for OSPFv3. > > > > I don't know when (or if) other vendors implemented the same thing for > > OSPFv3. > > > > That said, nearly any OSPF house I'm aware of still runs both OSPFv2 > > and > > OSPFv3 side-by-side. I guess folk are probably unprepared to use > > OSPFv3 for IPv4 NLRI. > > I'm sad to hear that those two still have to co-exist. I'd given up on how > static both routing protocols had become in light of my wireless > requirements way back then, also memory requirements. Babel had turned out > to be the only way to get teeny routers to route a few thousand ipv6 > routes as well as ipv4 over wifi mesh networks. > > I figured it had made zero penetration outside of that world despite our > efforts to get it into frr, bird, etc. > > > > > Mark. > > > > -- > I tried to build a better future, a few times: > https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org > > Dave Täht CEO, TekLibre, LLC
Re: V4 via V6 and IGP routing protocols
I'm actually not here to start a debate... happy to learn that the v4 over v6 feature I'm playing with actually exists in another protocol, mainly. I'm critically dependent on source specific routing, also, so I am hoping there's an isis or ospf that can do what I need, or now that I have more routers with enough memory, switch back to an ibgp. Is there a lightweight bgp client worth fiddling with? gobgp looked interesting. Presently I run bird in some places On Sun, Apr 3, 2022 at 6:49 AM Masataka Ohta wrote: > > Dave Taht wrote: > > > Periodically I still do some work on routing protocols. 12? years ago I had > > kind > > of given up on ospf and isis, and picked the babel protocol as an IGP > > for meshy networks because I felt link-state had gone as far as it > > could and somehow unifying BGP DV with an IGP that was also DV > > (distance vector) seemed like a path forward. > > As DV depends other routers to choose the best path from > several candidates updated asynchronously, which means > it is against the E2E principle and decisions by other > routers are delayed a lot to wait all the candidates > are updated, it is hopeless. I like to think babel solved most of the problems that RIP had, and while an optimal state is slow to arrive in babel, a working state is immediate, it's loop free, and it had a rtt metric. > > OTOH, LS only allows routers distribute the current most link > states instantaneously and let end systems of individual > routers compute the best path, LS converges quickly. Ages ago, I'd written a tool to stress out various igps in a scenario where lots of routes were coming and going, called rtod. It pretty much broke all the daemons and protocols I'd had available to me at fairly low levels of churn. https://github.com/dtaht/rtod > BGP is DV because there is no way to describe policies of > various domains and, even if it were possible, most, if > not all, domains do not want to publish their policies > in full detail. yes, and for smaller networks that are interconnecting, bgp can be too heavyweight also. > > > My question for this list is basically, has anyone noticed or fiddled > > with babel? > > No. > > Masataka Ohta -- I tried to build a better future, a few times: https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org Dave Täht CEO, TekLibre, LLC
Re: V4 via V6 and IGP routing protocols
On Sun, Apr 3, 2022 at 12:04 PM Mark Tinka wrote: > > > > On 4/3/22 13:55, Dave Taht wrote: > > > Periodically I still do some work on routing protocols. 12? years ago I had > > kind > > of given up on ospf and isis, and picked the babel protocol as an IGP > > for meshy networks because I felt link-state had gone as far as it > > could and somehow unifying BGP DV with an IGP that was also DV > > (distance vector) seemed like a path forward. > > To scale the IGP, we only carry Loopbacks and interfaces (backbone > infrastructure) in the IGP. Many operators have been doing this, for > some time now, as a best pratice. > > Customer routes as well as the DFZ is carried in iBGP. > > The only issue we have hit with this design is hardware that ships with > limited FIB (you're talking 4,000 slots or less). While this can be > mitigated with things like 6PE and RFC 3107, there are, now, tons of > hardware shipping without this physical restriction. For me, the > simpler, the better. > > > > My question for this list is basically, has anyone noticed or fiddled > > with babel? It's supported > > in FRR, bird, and a very small standalone daemon. > > Never heard of it as an IGP until now :-). We'd somewhat foolishly made it a requirement in ietf homenet. it was how hard adding source specific routing to isis turned out to be that turned me. At the time I needed simple means to get ipv6 working on multiple consumer uplinks. That later spawned a now mostly dead attempt to unify ipv4 and ipv6 address distribution called hnet. I'm fiddling with the new ipv4 over ipv6 stuff now in trying to interconnect several ipv4 networks over multiple p2p links. > > Googl'ing: > > https://en.wikipedia.org/wiki/Babel_(protocol) > > > > To recap that: > > > > "V4-via-v6 routing is a routing technique that allows routers with > > only IPv6 addresses (including link-locals) to forward IPv4 packets. > > It doesn't involve encapsulation (tunnelling), it doesn't involve > > translation (NAT), it just works. For details, please see > > Since around Junos 9 (2007), OSPFv3 shipped with the ability to carry > IPv4 NLRI over an IPv6-only network. We never did implement that, as > IS-IS integrated both protocols already. But it's been there for a while > for OSPFv3. > > I don't know when (or if) other vendors implemented the same thing for > OSPFv3. > > That said, nearly any OSPF house I'm aware of still runs both OSPFv2 and > OSPFv3 side-by-side. I guess folk are probably unprepared to use OSPFv3 > for IPv4 NLRI. I'm sad to hear that those two still have to co-exist. I'd given up on how static both routing protocols had become in light of my wireless requirements way back then, also memory requirements. Babel had turned out to be the only way to get teeny routers to route a few thousand ipv6 routes as well as ipv4 over wifi mesh networks. I figured it had made zero penetration outside of that world despite our efforts to get it into frr, bird, etc. > > Mark. -- I tried to build a better future, a few times: https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org Dave Täht CEO, TekLibre, LLC
Re: V4 via V6 and IGP routing protocols
On 4/3/22 13:55, Dave Taht wrote: Periodically I still do some work on routing protocols. 12? years ago I had kind of given up on ospf and isis, and picked the babel protocol as an IGP for meshy networks because I felt link-state had gone as far as it could and somehow unifying BGP DV with an IGP that was also DV (distance vector) seemed like a path forward. To scale the IGP, we only carry Loopbacks and interfaces (backbone infrastructure) in the IGP. Many operators have been doing this, for some time now, as a best pratice. Customer routes as well as the DFZ is carried in iBGP. The only issue we have hit with this design is hardware that ships with limited FIB (you're talking 4,000 slots or less). While this can be mitigated with things like 6PE and RFC 3107, there are, now, tons of hardware shipping without this physical restriction. For me, the simpler, the better. My question for this list is basically, has anyone noticed or fiddled with babel? It's supported in FRR, bird, and a very small standalone daemon. Never heard of it as an IGP until now :-). Googl'ing: https://en.wikipedia.org/wiki/Babel_(protocol) To recap that: "V4-via-v6 routing is a routing technique that allows routers with only IPv6 addresses (including link-locals) to forward IPv4 packets. It doesn't involve encapsulation (tunnelling), it doesn't involve translation (NAT), it just works. For details, please see Since around Junos 9 (2007), OSPFv3 shipped with the ability to carry IPv4 NLRI over an IPv6-only network. We never did implement that, as IS-IS integrated both protocols already. But it's been there for a while for OSPFv3. I don't know when (or if) other vendors implemented the same thing for OSPFv3. That said, nearly any OSPF house I'm aware of still runs both OSPFv2 and OSPFv3 side-by-side. I guess folk are probably unprepared to use OSPFv3 for IPv4 NLRI. Mark.
Re: V4 via V6 and IGP routing protocols
Dave Taht wrote: Periodically I still do some work on routing protocols. 12? years ago I had kind of given up on ospf and isis, and picked the babel protocol as an IGP for meshy networks because I felt link-state had gone as far as it could and somehow unifying BGP DV with an IGP that was also DV (distance vector) seemed like a path forward. As DV depends other routers to choose the best path from several candidates updated asynchronously, which means it is against the E2E principle and decisions by other routers are delayed a lot to wait all the candidates are updated, it is hopeless. OTOH, LS only allows routers distribute the current most link states instantaneously and let end systems of individual routers compute the best path, LS converges quickly. BGP is DV because there is no way to describe policies of various domains and, even if it were possible, most, if not all, domains do not want to publish their policies in full detail. My question for this list is basically, has anyone noticed or fiddled with babel? No. Masataka Ohta
V4 via V6 and IGP routing protocols
Periodically I still do some work on routing protocols. 12? years ago I had kind of given up on ospf and isis, and picked the babel protocol as an IGP for meshy networks because I felt link-state had gone as far as it could and somehow unifying BGP DV with an IGP that was also DV (distance vector) seemed like a path forward. My question for this list is basically, has anyone noticed or fiddled with babel? It's supported in FRR, bird, and a very small standalone daemon. Anyway, after babel hit the ietf, development slowed down a lot, but along the way some useful innovations were made, notably a RTT metric, "source specific routing" for ipv6, HMAC authentication, and most recently, Juliusz's announcement of V4-via-v6 hit the git babeld codebase. To recap that: "V4-via-v6 routing is a routing technique that allows routers with only IPv6 addresses (including link-locals) to forward IPv4 packets. It doesn't involve encapsulation (tunnelling), it doesn't involve translation (NAT), it just works. For details, please see https://datatracker.ietf.org/doc/html/draft-ietf-babel-v4viav6 Short story: v4viav6 is enabled by default if your linux kernel is recent enough. Just upgrade babeld to current master, and you should see your v6-only routers forward IPv4 packets. In order to disable announcing of v4-via-v6 routes, add the following to your configuration file: default v4-via-v6 false Long story. There are two pieces to v4-via-v6: installing IPv4 routes with an IPv6 next hop, and announcing such routes. By default, babeld will: - install v4-via-v6 routes on Linux 5.2 and later; - announce v4-via-v6 routes on Linux 5.13 and later. (backports are available for various stable versions) The former behaviour cannot be overridden -- we always install v4-via-v6 routes if the kernel supports them, and (obviously) never do otherwise. The latter behaviour can be overridden by the interface option 'v4-via-v6'. Feel free to experiment, but be aware that enabling v4-via-v6 on an older kernel might create ICMP blackholes. Please let me know if you feel that it should be possible to completely disable v4-via-v6 even on newer kernels, and whether you feel that v4-via-v6 should be disabled by default. (The "Security Considerations" section of the draft cited above might be interesting.)" Enjoy, -- Juliusz Juliusz Chroboczek via alioth-lists.debian.net Thu, Mar 31, 3:30 PM (3 days ago) to babel-users, Théophile On Fri, Apr 1, 2022 at 2:17 AM Pascal Thubert (pthubert) via NANOG wrote: > > A very long thread. > > Face it: everyone is right, and even technically correct. There's no good and > evil. We'd know, after 20 years. > > I live in France and my country has a famous 100-years war in its long > history with England. Do we want to beat this here? > > The plain truth: > > - IPv4 is here to stay. Some v4-only nodes and functionalities are here to > stay. Plenty of reasons for that in this thread. > - IPv6 is unavoidable. New devices like phones and IOT need it, many IPv6 > only in that space, numbers only growing > > > The things everyone agrees upon: > - Dual stack everywhere and forever is the worst of both worlds as it doubles > every cost, and that will remain long as the war rages > - Stateful NATs the size of the Internet not doable, which in my book says > that isolation not only unavoidable but already there. > > An the illusions: > > - any-to-any is required. In particular, any IPv4-only to any-IPv6 only. I'm > not talking security but plain functionality. And yes, exceptions if they are > few can be handled by expensive stateful NATs when the cost is justified > - the Internet is a big homogenous thing. The more it expands, the more we > see domains forming where specific capabilities are deployed, and because we > fail to handle that at L3, we mask the functionalities above UDP. > > If we agree on the above then a compromise is possible. Ideally, the > compromise would: > - maintain the current state of v4 affairs for those who want that > - scale v4 addresses for those who want that > - provide v4 to v6 stateless NATs for this who want that, and > - allow networks to be either of the 2 versions for those who want that. > > SciFi? There's a proposed starting point for that compromise in the yada-yatt > draft published at IETF v6ops. The key is to use baby steps between locations > (in the transition plan) where people can be at ease and stay as long as they > want to, as opposed to enforcing a giant zero-to-hero illusionary step. > > Are you ready for that, or should we wait another 80 years with dual stack > and gigantic stateful NATs? > > Pascal > > > > > -- I tried to build a better future, a few times: https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org Dave Täht CEO, TekLibre, LLC
