> The problematic bit is, I think, 's' in babel_handle_update can be NULL
> because nothing ensures the babel_source for a particular neighbour
> actually exists here:
s will be passed to babel_is_feasible, which returns true if s is null.
Later on, s is only used if feasible is false, in which
> The problematic bit is, I think, 's' in babel_handle_update can be NULL
> because nothing ensures the babel_source for a particular neighbour
> actually exists here:
s will be passed to babel_is_feasible, which returns true if s is null.
Later on, s is only used if feasible is false, in which
>> The issue has been described in draft-ietf-babel-mac-relaxed, which is
>> currently pending RFC publication. That also describes two mitigation
>> mechanisms: Keeping separate PC counters for unicast and multicast, and
>> using a reorder window for PC values. This patch implements the former as
As Toke said, OSPFv3 is a fine protocol. OSPFv2 was already pretty good,
and the designers of OSPFv3 fixed the two significant flaws in OSPFv2.
But of course I'd be delighted if you could experiment with Babel.
>> routes). I'm simplifying wildly here, and I'm sure Juliusz will jump in
>> and
> But this filter applies in the antenna that advertise the route.
> 10.20.2.2 and 10.20.2.36 advertise 10.0.0.0/8
>
> 10.20.2.162 and 10.20.3.1 links with 10.20.2.2 and i want that 10.20.2.162
> uses
> 10.20.2.36 (not direct link) for 10.0.0.0/8 not 10.20.2.2 and 10.20.3.1 uses
> 10.20.2.2
For
> We have a series of wireless antennas deployed in mesh with the babel
> protocol using bird.
>Two of those antennas advertise the route 10.0.0.0/8.
>The rest of the antennas choose one of the two outputs depending on the
> babel protocol.
>How can I force it to go out through one
> I find enormously few examples on the internet. Furthermore, I do not
> understand the difference between the filter in, out and redistribute.
Daniel summarised it quite well. In my inimitable artistic style:
in out
--> babeld -->
| ^
| |
> from my perspective the time to prolong the IPv4 usage is over.
I agree.
But that's not what this debate is about. It's about whether it is the
role of the authors and maintainers to enforce the desired behaviour
(which is what Maria is arguing for), or whether the maintainers should
merely
> By stdlib, you presumably mean the x/net/websocket package,
Careful with this library, it's not quite correct. Websocket is
a frame-oriented protocol, while x/net/websocket implements a simplistic
API that does not always preserve frame boundaries.
Correct implementations include:
> The RFC says "ordinary IPv4 announcements are preferred to v4-via-v6
> announcements when the outgoing interface has an assigned IPv4 address",
> but there is also the third option - using an IPv4 address from another
> interface as a next hop.
The ways in which routing may fail are different.
> * the neighbour, if any, on behalf of which we are forwarding this request;
[...]
> But it is true that since forwarded requests are not resent, i also do not
> see the need for this information.
Agreed on both counts.
> I think that the text of section 3.2.7 (The Table of Pending Seqno
>
> Right, so after going after this a couple of times, I think I see the
> discrepancy here: in Bird we're currently doing retransmission at every
> hop;
Yep, that's the intent of RFC 8966 Section 3.8.1 (I agree it's not
perfectly clear):
A single request MUST NOT be duplicated: it MUST NOT be
> Tying the seqno request entry to the destination had the problem that when
> that destination neighbour entry was removed, we'd remove the entire
> request, and thus no longer retransmit it. Tying the entry to the neighbour
> on whose behalf we are forwarding the entry instead means that we can
https://bugs.kde.org/show_bug.cgi?id=394496
Juliusz Chroboczek changed:
What|Removed |Added
Status|NEEDSINFO |REPORTED
Resolution
I'm writing a simple UDP server, and I'm trying to use the new net/netip
data types. My main loop starts as follows:
for {
n, a, err := sock.ReadFrom(buf)
if err != nil {
log.Printf("ReadFrom: %v", err)
time.Sleep(100 * time.Millisecond)
> Juliusz, please go read RFC2026. You are completely out of order.
> Proposed standards do not need *ANY* interoperable implementations.
Usually, neither implementation nor operational experience is
required for the designation of a specification as a Proposed
Standard. However, such
Removing the IESG from CC.
> I propose you start mentioning what you believe are unspecified gaps
> that could lead to interoperability issues.
With all due respect, Daniel, I'm a little surprised by this development.
In this WG, we did spend a lot of effort ensuring that all of our
> I wish I had a fancy pony with:
That's not a pony. That's a whole herd.
> Routing based on diffserv.
That was originally supported by OSPFv2, but was removed from later
versions of the specification, to be replaced by multi-topology routing
(RFC 4915). It's a little costly if you only have
> Ultimately though, these are just shortest hop path builders and need some
> other kit on top of them to do any sort of traffic engineering or load
> balancing. ECMP doesn't work for me, and doesn't work for a lot of wisps
Perhaps one of you could explain what kind of traffic engineering and
> OSPF is where it is now because it's "good enough (for now)"
It is very good.
> Sure, an implementation that spits out bad LSAs is going to break
> everything - you're going to get some pretty nasty results from sending
> out broken destination-distance-vector data, too.
I claim that in DV
> our toasts to the builders of Notre-Dame.
...which then burnt down :-/
> Dijkstra's algorithm remains a very natural approach to mapping a
> graph
I'm not sure what that means. Dijkstra's is a shortest path algorithm,
it's not in the business of mapping. I guess the author meant that
> What I think we're missing is the integration of network attributes and class
> of service. For instance, user to 'internet' has 3 potential paths with each
> having these end-to-end latency, upload throughput, download throughput, and
> say 'quality' or packet loss. Then having your QoS
> found babel, corresponded with (and frankly thoroughly annoyed) the
> author,
Being said author, I can confirm that you did thoroughly annoy me. But
then, you also made me think.
> Babel is so simple that toke wrote a near complete implementation from
> the spec, in python, during a string of
Hi Linus!
> Regarding [0] does anyone have an overview of which Linux kernel
> patches might need backporting when trying this v4-via-v6 feature
> of Babel on OpenWrt 22.03's Linux 5.10 kernel?
Toke will correct me if I'm wrong, but as far as I'm aware, it's just this:
>> this document tries to describe would see adoption, it's become very
>> clear that dynamic DNS services as described in Section 4 have won out
>> here. These services are far from perfect, but at least some of the
>> limitations in Section 4 have been addressed, and others are arguably a
>>
> A quick skimming of RFC 7298 suggests the PC is indeed intended to be
> per-interface without taking the {mult,un}icast bit into account. Is this
> an oversight in the spec?
Hi Daniel,
I've just given a talk about this issue, and while reviewing our
correspondence while preparing the talk,
> Juliusz, see the Twitter thread I linked to, it explains precisely the
> jamming scenarios they could be facing, and how they are possible.
I saw it after I wrote my question, and it does explain a lot. Thanks.
Do you have an idea how difficult it is to actually do in practice? Is it
a
Thanks for the discussion, David, I'm sure I'm not the only one who found
it enlightening.
-- Juliusz
___
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
> In essence, once you give something away for free, not even setting the
> expectation that it’s a “freemium” model, it’s very hard to get out of it. If
> you then claim your costs are way higher than what analysis work out, eyebrows
> raise way above the hairline.
Uh. Hmm.
> SpaceX was too generous early on and set expectations, and now seems to
> be moving to the other side of the spectrum in terms of their costs,
> with figures that seem, on the surface, unrealistic.
Could you please explain this last point?
-- Juliusz
> you need to provide the rest of the information, namely that Russia is
> actively jamming communications.
Interesting, I wasn't aware that they have the capability to do that in
areas that they do not control. Do you have any further information?
-- Juliusz
As some of you recall, Elon Musk recently posted a tweet in which he
recommends that Ukraine should capitulate to Russia. Andrij Melnyk, the
Ukrainian Ambassador to Germany, replied in two words.
https://twitter.com/melnykandrij/status/1576977000178208768
A few days later, Musk announced
> Very interesting article came out recently.
> https://www.infoq.com/articles/java-virtual-threads/
Interesting article, thanks for the pointer.
> it has implications for the Go context discussion and the author makes
> a very good case as to why using the thread local to hold the
> context -
> I've got a pet theory that the burstiness of internet traffic is an artifact
> of
> the fact that academics and marketing departments, in a weird kind of unholy
> alliance, keep focusing on peak throughput.
Hmm.
Packet pacing is counterintuitive and tricky to get right. It's highly
> > https://www.battlemesh.org/BattleMeshV14
>
> Hi Dave, I plan to be there.
I'm teaching in September, but I'm awfully tempted. (Unfortunately, we're
terribly short on lecture theatres, so it's almost impossible to move
a lecture.)
-- Juliusz
___
>
> While this is not fatal for the reordering fix per-se your RTT patch also
> breaks because of this AFAICT. Since the IHU tstamps only ever arrive via
> unicast. At least with my `unicast true` babeld config.
More exactly, with "unicast true" babeld will send a IHUs over unicast,
which will in
> I've set `rtt cost` and can see the metrics being adjusted based on the
> latency, and have also confirmed ipv4 via ipv6 next hops is working as
> I'd expect.
That's excellent news. It means that BIRD now has all of the useful
features of babeld.
-- Juliusz
>> Sounds like you could be hitting the same issue as described in this
>> thread?
>> https://alioth-lists.debian.net/pipermail/babel-users/2022-February/003884.htm
> That does indeed look like the same issue,
You guys are giving me extra homework ;-)
I've got a private branch that fixes the
Dear all,
I have just removed support for draft-chroboczek-babel-diversity-routing,
also known as Babel-Z, from babeld. The sub-TLV numbers remain allocated,
but the code is gone.
The extension was based on an idea by Benjamin Henrion (Zoobab to his
friends), and aimed to choose routes that
Hi,
I'm about to remove the diversity code from babeld. This will not break
on-the-wire compatibility, but it will require you to tweak your config
files:
- the "-z" option will no longer exist;
- the following interface options will no longer parse:
- diversity-factor
- channel
> What do you think how well would a dynamic routed environment with
> babeld scale?
The Babel protocol has been designed to scale up to hundreds of thousands
of nodes. The current implementations (babeld and BIRD) have not been
tested with more than a a thousand nodes or so.
Don't let this
.
* Schedule an interface check just after adding an interface.
Thanks to Andrew Hoff.
-- Juliusz Chroboczek
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
> I've managed to reproduce the problem locally, and I've confirmed that the
> split-PC approach fixes the issue. I'm seeing failed PC validations, but
> not enough to cause association failure.
Just to be clear -- I'm seeing failed PC validations with stock 1.12. I'm
not seeing any unexpected
Daniel,
I've managed to reproduce the problem locally, and I've confirmed that the
split-PC approach fixes the issue. I'm seeing failed PC validations, but
not enough to cause association failure.
I've merged the fix into master. Right now, I'm not planning to implement
the window-based
Thanks a lot, Daniel.
> I'm having some trouble establishing a baseline using babeld. Using
> babeld-1.11 as both the sending and receiving side I'm not observing any
> errors
You need to run babeld with the "-d2" flag to see MAC and PC validation errors.
> and the session seems to come up
> You'll find a patch for babeld in the branch "hmac-unicast-pc"
>
> git clone -b hmac-unicast-pc https://github.com/jech/babeld
>
> The patch is here:
>
>
> https://github.com/jech/babeld/commit/7e5d18791f5b5f2d5ad660fad85769f75f47f705
Daniel, could you please confirm that whether
> I have a conference this week,
That's not an excuse -- I've seen you write the BIRD implementation of
Babel during a conference, in just five days.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
Hi Toke, hello list,
I've just written a first draft of an ID that describes the changes that
you and I have made to our respective implementations of Babel-MAC. See
the directory "draft-chroboczek-babel-mac-relaxed" under
https://github.com/jech/babel-drafts/
I've put readable HTML here:
> Right, okay. I updated the Bird patch to implement both the separate
> ucast/mcast values and the window (patch below). Daniel, could you
> please test this in your environment?
You'll find a patch for babeld in the branch "hmac-unicast-pc"
git clone -b hmac-unicast-pc
> Ah, I see! Okay, that makes sense. Also, it occurred to me that the
> window-based approach likely isn't enough when there are multiple
> neighbours and you do unicast updates, as then another neighbour can eat
> up a whole chunk of PC number space that you never see.
Exactly. The sender
> Hmm, I certainly see where you're coming from; having separate sequence
> numbers for unicast/multicast would neatly sidestep this particular
> problem. However, one problem with this is that it's not straight-forwardly
> backward compatible.
No, no sender changes. Just receiver changes.
The
CC-ing babel@ietf. List, Daniel has reported that multicast packets are
delayed in his network by up to 200ms, which breaks Babel-MAC's PC check.
Toke has determined that the issue is with WiFi powersave, which is
unfortunately not something we can control. Toke has proposed a patch
against his
> The protocol is described in RFC 9229, which has not been published yet;
It's just been published:
https://www.rfc-editor.org/rfc/rfc9229.html
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> Nevertheless, the feature is still very useful for radios up to 802.11g.
Remember, Benjamin, we've never been able to prove that (you were there).
We've proved that the feature works well in an idle network, but as soon
as you add traffic, the interferences cause enough packet loss for ETX to
Package: babeld
Vesion: 1.9.1-1+b1
The version of babeld in Debian is almost three years old, and has
a number of bugs that have been fixed in more recent versions. Please
upgrade to a more recent version.
Dear all,
Babeld 1.12 is available from
https://www.irif.fr/~jch/software/files/babeld-1.12.tar.gz
https://www.irif.fr/~jch/software/files/babeld-1.12.tar.gz.asc
For more information about the Babel routing protocol, please see
https://www.irif.fr/~jch/software/babel/
This version
Hi,
I've done some testing with current master, and it looks good to me. I'm
planning to release it over the weekend as 1.12, with v4-via-v6 enabled by
default on recent Linux kernels (5.13 and later). If you disagree, please
speak up now.
After 1.12 is out, I plan to remove the diversity
> > 1. Are you running with the "unicast" option set in your config file?
>
> Aaah turns out I was, because I had it set in `default` for my wireguard
> links.
>
> Adding `interface enpxx unicast false` magically fixes this. According to
> the docs this skips sending a duplicate hello to
> I'm attaching a filtered down pcap from the receiving side showing the
> problem. Wireshark filter: (babel && ipv6.src == fe80::1) || icmpv6. The
> sending side is running babeld the receiving side bird2 if that matters.
Interesting, thanks.
1. Are you running with the "unicast" option set in
> Enable extended acknowledgements for netlink messages
Thanks Toke. I've applied your patch to master, just replacing the
failure when the setsockopt fails with a friendly warning.
> Use per-table dumps on kernels where this is available
This one looks more risky, I'll wait until after
> I'm seeing babel mac authentication failures related to the packet counter
> on a wireless link. I've tracked this down to being because of packet
> reordering.
Babel-MAC does not deal with packet reordering: we assume that packets
don't get reordered on the local link. It would be fairly
A route across three IPv6-only nodes:
$ ip route show 10.0.0.2
10.0.0.2 via inet6 fe80::216:3eff:fe00:1 dev lxcbr0 proto babel onlink
Here's how it's logged by babeld:
10.0.0.2/32 from 0.0.0.0/0 metric 384 (384) refmetric 288 id
02:16:3e:ff:fe:9a:5e:22 seqno 36425 chan (255) age 15
>> Yes, it would make sense. The reason why we calculate an exponential
>> average is that it is cheaper to compute, and works quite well in
>> practice. The goal here is not to compute an accurate metric, it is to
>> reliably choose the best route: the metric only needs to be accurate
>> enough
> That seems like an interesting idea, especially for things like
> automatically switching between multiple Wireguard tunnel concentrators.
That's exactly the application that it was designed for. For some
background, please see
https://arxiv.org/pdf/1403.3488.pdf
(I never managed to
> Enable extended acknowledgements for netlink messages
This looks safe to me, so I'm tempted to apply it straight away.
> Use per-table dumps on kernels where this is available
This one looks a little bit more risky, so I'm tempted to wait until after
babeld-1.12.
Opinions?
-- Juliusz
> AFAICT the babeld code will require quite a bit of surgery to change
> this behaviour; to the point where I think it may be simpler to
> implement the RTT extension in Bird (but I'm obviously biased here)... :)
Please?
Your BIRD code is much better than what's in babeld, which has been hacked
>> I think for my use-case the loop avoidance point is moot though since I'm
>> mainly interested in using this on endpoints, not routers. So perhaps
>> calling this ECMP is not the right nomenclature?
> Not sure; what are you trying to do, exactly?
I'm interested too. Could you please explain?
> As for why you're seeing this in particular when Babel is running, now
> that we know the route dump is the culprit, it's quite obvious: While
> Babel listens for new route notifications from the kernel, it doesn't
> actually use those notifications directly; instead, it just sets a flag
> (see
Dear all,
I've just merged support for v4-via-v6 routing into babeld master.
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
Dear all,
Babeld 1.11 is available from
https://www.irif.fr/~jch/software/files/babeld-1.11.tar.gz
https://www.irif.fr/~jch/software/files/babeld-1.11.tar.gz.asc
For more information about the Babel routing protocol, please see
https://www.irif.fr/~jch/software/babel/
The main news in
> POISED was the result.
Could somebody please explain?
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
> The setup is made using Raspberry Pi with USB Wi-Fi dongle. The Wi-Fidevices
> are placed into ad-hoc mode with the following commands:
> sudo ip link set wlan1 down
> sudo iwconfig wlan1 mode ad-hoc channel 11 essid "mesh"
> sudo ip link set up dev wlan1
Did the link layers
> Probably because babeld subscribes to netlink notifications for all new
> routes, and only filters them on the table name fairly late,
> specifically here:
>
> https://github.com/jech/babeld/blob/master/kernel_netlink.c#L1175
Do you see how it can be done better?
> I run Bird in a similar
> Is there more to be done than just writing the equivalent to the
> add_interface function [0]?
It should be enough.
Please be aware that this code has seen little testing. In particular,
the flush_interface function is too subtle for comfort: it puts the
interface down (the call to
> The mystery is partly solved. Most importantly, ipv6 and babeld are both
> now working!
Good.
> The source of the problem lies in ipv6's DAD (duplicate address
> detection). If I understand correctly, when an ipv6 address is assigned,
> dad is supposed to check the network to see if the newly
> Thanks! Can I also remove an interface via that way?
If you put the interface down (ip link down), babeld will stop routing
through it, but the data structure will remain in memory. There's
currently no way to delete an interface altogether.
-- Juliusz
> It would be nice to have something similar with babeld.
You can do it by connecting to the local management interface (-G) and saying
interface whatever
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> These same steps are repeated on Pi number 2, but with an ipv4 address of
> 10.0.2.1. At this point both of them can ping each other at their ipv4 address
> via the wlan1 interface.
>
> Attempting to run babeld on wlan1 will result in an error regarding a lack of
> link-local address. The
>> Chromium crashes immediately when attempting VP9 simulcast. To reproduce, go
>> to
>>
>> https://janus-legacy.conf.meetecho.com/echotest.html?simulcast2=true=vp9
> I just tried this on sid and bullseye with v97 and it didn't crash.
I couldn't reproduce the issue with 97.0.4692.71-0.1.
Your comments reordered.
> Very much appreciate the help! This personal project was designed to teach
> me a little about routing and it has definitely served that purpose
> well :) But perhaps learning a little about routing isn't the same as
> being very good at routing!
Distributed
> Do I want to install TWO default routes with my script, one to be used and
> one to be propagated?
Yes, I think you need to do that. A route in Babel is either
redistributed (in which case it triggers duplicate suppression) or ignored
(in which case it's not redistributed). If you need one
> I have a hack which pings from each site to see if its own internet
> connection is up. If it is, it installs a default route.
How do the pings reach the Internet before a default route has been
installed?
> Babel will not put its own proto route into the table, if there is
> a static route
>> https://blog.cloudflare.com/october-2021-facebook-outage/
> Thanks, Benjamin, that's exactly what I was looking for.
Actually, it's a little disappointing.
Does anyone have a technical explanation of the Facebook f*ck up? It
seems difficult to believe that setting an incorrect BGP filter
> The nodes run OpenWrt 21.02 with babeld 1.10-2. Virtualization is made with
> Proxmox
I'm not familiar with Proxmox, I'll have a look.
> The problem is that distributed routes come and go. What I observed was a node
> to have 18 routes tops. Sometimes they fluctuate between 9 and 13.
> The
>> the Babel RFC makes it clear that 0 is a valid value that must not be
>> confused with NULL.
This is true for both seqnos and metrics. A route with metric 0 is
perfectly valid, and in fact the value 0 is the default for a directly
connected prefix.
-- Juliusz
I haven't been following Ted's work on stub networks, and I've only just
taken some time to read through the latest draft. Sorry if I repeat
things that have already been said, I haven't caught up yet with my
Homenet mail.
A few quick comments while I think it over.
1. There's a lack of
> I want to be able to terminate each worker independently of others
> (i.e. close on worker, wait for it to finish its tasks, but allow
> other workers to run if they haven't been signalled to stop).
The solution I use is to have each worker take two parameters:
- a channel that will be
> FWIW, I think there's further work after stub networks for HomeNet to do. We
> now have Babel and Source-Specific routing, but I suspect that setting it up
> will involve some innovation, and that ought to be documented.
That would be RFC 9080. It's fully implemented in both hnetd and shncpd.
Hi Mikael,
> If it's not hw accelerated, it sucks.
Fortunately, that hasn't been true in a long time. Two data points.
The WND3700v2/WNDR3800, which is now over ten years old, can easily
forward 400Mbit/s NATed IPv4 (max-sized packets) in software. To be fair,
it can saturate 1Gbit/s with
Package: firefox
Version: 88.0.1-1
Run the following code:
voices = window.speechSynthesis.getVoices();
voices[0].lang;
This returns something like:
"sk-STEPH3"
which is not a correct language code, and breaks language matching against
e.g. navigator.languages.
I've relicenced sroamd under the MIT licence, and moved it to github.
https://github.com/jech/sroamd
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
> Okay, I found this design description that is very helpful. :)
> https://www.mail-archive.com/babel-users@alioth-lists.debian.net/msg00662.html
Some more details. Sroamd consists of five pieces:
1. a distributed (replicated) database (flood.c);
2. a table that maps IP addresses to MAC
> Am I allowed to put sraomd to openwrt/routing feed?
I'd need to change the licence first.
> I think a lot of persons will try using it and give feedback to us.
Yeah, it might be a good idea. I'll think it over and get back to you.
-- Juliusz
___
> Nice, but why is 5.10 missing?
I have no idea, perhaps I missed it. I just did a web search for the
title of the patch, and reported what I found.
Here's the patch, in case you're better at searching than I am:
https://lore.kernel.org/netdev/20210618110436.91700-1-t...@redhat.com
--
It looks like Toke's patch that implements Section 3 of draft-ietf-babel-v4viav6
is going to get into kernels 5.13, 5.4.128, and 4.14.238.
:-)
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
This is in reply to https://github.com/openwrt-routing/packages/issues/678 :
> I'm very interested in MAC authentication for the Babel routing
> protocol. However, I'm unsure if I can apply some of the parts to
> a decentralized network like freifunk, where everyone can
> participate. The basic
>> https://mailarchive.ietf.org/arch/msg/homenet/7JmkTCBSSMs5nnH3VWPj6JAL0cA/
> I didn't find any clear definition of how DDNS works in that email.
[...]
> What's the Performance Specification that describes this process? Yes,
> I know where the vendor specific documentation is.
As far as I'm
Dear all,
A quick tutorial on protecting your Babel network with cryptographic
signatures using the Babel-MAC protocol extension.
0. What does MAC security do?
=
It protects your Babel infrastructure by preventing an attacker from
impersonating a Babel router by
Hi Michael,
>> Stephen and Juliusz expressed that they're still not convinced that
>> DDNS isn't a good enough solution for the use case.
> Well, I'd be happy to discuss with this them again, but they'd have to
> actually tell us what "DDNS" really is for them.
Hi,
I'm in the process of merging v4-via-v6 into mainline babeld, and I need
some advice about the default configuration.
V4-via-v6, is described here:
https://datatracker.ietf.org/doc/html/draft-ietf-babel-v4viav6
It's a technique that allows an IPv6-only router to forward IPv4 packets,
101 - 200 of 3650 matches
Mail list logo
