> I have talked to operator colleagues and found several who use .0 and .255
> IPv4 adresses handed out to customers for Internet communication without
> ill effects.
The customers are probably behind NAT, so I'm not sure how much that says
about the compatibility of client devices.
> So while th
> Yes - these are reserved IDs. You need to avoid any IPv6 address that
> would be the result of using these values as the ID portion.
I see, thanks to both of you.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listi
> https://tools.ietf.org/html/rfc5453
> provides an answer w.r.t. IPv6.
Do I need to avoid these addresses when assigning a /128 or a /127?
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
>> I just received a bug report for shncpd from somebody who noted that
>> shncpd's DHCPv4 server will happily assign addresses a.b.c.0 and a.b.c.255
>> to clients. That's obviously broken.
> Not since 1993 and RFC 1519, depending on the subnet mask.
Right. I was thinking of a /24, sorry for no
Hi,
I just received a bug report for shncpd from somebody who noted that
shncpd's DHCPv4 server will happily assign addresses a.b.c.0 and a.b.c.255
to clients. That's obviously broken.
Which addresses must be avoided, for both v4 and v6? I'm already setting
the g and u bits in modified EUI-64 t
I've just updated shncpd to follow the changes made between the draft
I had used and RFC 7788. The consequence is that shncpd no longer
interoperates with the version of hnetd in current OpenWRT head :-/
You can work around that by using the flags
-p 8808 -m ff02::8808
on shcnpd's command lin
> What happens if that new router has been booted stand-alone (so it creates
> its own ULA), and then joins the Homenet by being plugged in, and has
> a higher node identifier?
Each partition has at most one ULA. When the partition heals, a single
ULA is retained.
> Shouldn't this be a voting me
If I'm reading you correctly, Ray, you're promoting unstable naming. If
I have two routers called trurl and pirx in my network, then my printer
will becalled diablo630.pirx.home whe pirx is up, diablo630.trurl.home
when trurl is up, and either I reconfigure all of my hosts every time
I swap a rout
> So the naming protocol has to work with renumbering; ideally though
> intra-homenet communications would use the homenet's ULA,
That's not the point I'm making. I mean that numbers are not user-visible,
while names obviously are. That would seem to imply that naming is at
a higher level than e
>>> So perhaps you think of DNS data as being higher-layer than routing data
>>> and numbering data?
>> Do you not?
> No. Why are names different than numbers?
I should be able to renumber without telling my users.
-- Juliusz
___
homenet mailing list
>> No (HNCP manages quite a bit of hard state, unfortunately). I think
>> I meant "able to interpret higher-layer data", but I'm no longer sure ;-)
> So perhaps you think of DNS data as being higher-layer than routing data
> and numbering data?
Do you not?
-- Juliusz
___
> I tend to think of routing protocols and election protocols as "intelligent",
> but perhaps you meant something different... :)
> E.g., did you mean "stateful?"
No (HNCP manages quite a bit of hard state, unfortunately). I think
I meant "able to interpret higher-layer data", but I'm no longer
>>> Proxying flies in the face of the trend of smart devices and dumb
>>> networks.
> Be that as it may, Homenet in general flies in the face of that trend.
Not sure. If you look at HNCP, the only intelligence there is a bunch of
election algorithms (prefix assignment is just election with non-l
> Bonjour is (roughly) based on Appletalk AFAIK. I've got nothing against
> Appletalk Phase II, so if Bonjour was extended to provide an equivalent
> function to Appletalk Phase II Zone Information Protocol = ZIP then I'd be
> happier. That would cover concerns on non-overlapping name spaces. And
>
>> We can and should. The problem is that we won't see that code ship in
>> new devices anytime soon, so we still have to make mDNS work.
> And this is why the dnssd WG is focused on making mDNS work on
> multi-subnet networks.
Is there something I can read on this particular subject?
-- Julius
> So my next question is ‘what is External and what is Internal?’
- External: connected to the ISP's (non-Homenet) router.
- Internal: interior link within your Homenet, connected to other
Homenet routers and to (unmodified) hosts.
Here's a possible topology, where interfaces are marked
>>> Just 2136 isn't enfough, because there's no authentication scheme,
>> I don't understand this argument. How is non-secured DDNS any less secure
>> than mDNS? What am I missing?
> This is an implementation issue, not a security issue--sorry for not making
> that clear. In order to preserve
> Now you get me curious. How do you do efficient site-local multicast
> when you have multiple wifi and ethernet links?
Assuming you've got only transitive links, then any multicast routing
protocol should work fine at the scale we envision for Homenet as long as
it is able to avoid wireless link
> Juliusz, the problem is that existing home network devices that do
> DNS-based service discovery do not support DNS update. They could, but
> they don't, because we didn't define an easy way for them to do it.
I'd be grateful if you could expand on that. Why can't we define a way
for clients to
>> Do you mean, (1) how is a DNS resolver advertised to clients, or
>> (2) how clients are registered in DNS ?
>>
>> (1) is done by using the -N flag on the router advertising an external
>> connection (-E). This flag can be repeated multiple times.
> hnetd grabs this automatically from wan-faci
> I’m starting by running shncpd on a boundary router and tried a trivial
> installation.
Excellent, thanks.
> I don’t see how dns gets updated. Are such updates out of scope of
> shncpd?
Do you mean, (1) how is a DNS resolver advertised to clients, or
(2) how clients are registered in DNS ?
(1
> It’s the IPv6 stuff that I’m most interested in - IoT with ipv4 (NAT) is
> too expensive to support at scale. At least for the retail market. My
> sense was that the api to the openwrt tools was a likely stumbling
> block.
Tim, please try shncpd and let me know how it goes. I'm quite willing to
> So I tried to spin hnetd up on a fedora vm, and found it fighting the
> distro set-up. Maybe the implementation isn’t supposed to co-exist with
> other network controlling software on the same computer. What’s my best
> approach to getting the homenet protocols running as a proof of concept?
Hne
Hi,
Is it legal for multiple HNCP routers to announce the same delegated
(IPv6) prefix?
I assume it is legal, and that nodes should assign a single prefix per
delegated prefix to attached links (the spec says "set of delegated
prefixes", not "multiset"), but I'd like to be sure I'm not overlookin
> If you're announcing an external connection into the HNCP domain, shncpd
> will install a proto 43 source-specific default route. See route_externals
> in prefix.c.
In case that wasn't clear -- shncpd doesn't act as a DHCPv6-PD or DHCPv4
client, it expects you (the human operator or the startup
>> Shncpd has closer binding to the routing protocol, it marks its routes
>> as "proto 43" and expects the routing protocol to redistribute just
>> that; shncpd also occasionally inserts dummy "proto 43" routes into the
>> kernel, just so that they get redistributed into the routing protocol.
> Ju
> Is there room in the protocol for a router to announce what link type it
> is on?
This could be carried by a sub-TLV of Hello (or a sub-TLV of IHU if you
want to make it per-host).
> I.e., a router on wifi announces wifi and when a router that is on wired
> receives an announcement from a route
> here is some attempt to formalize a simple WiFi roaming approach
> using host routes and a stateless proxy for DAD NDP messages.
http://www.cisco.com/en/US/products/ps9390/products_white_paper09186a00800a3ca5.shtml
(See also RFC 1925 Section 2.11.)
-- Juliusz
_
> hnetd does address configuration on interfaces, the routing protocol picks
> this up because that's how it's configured...? Hnetd doesn't communicate
> directly with the routing protocol at all, right? It just sets up the
> landscape so the routing protocol can come and survey it and communicate
Added Mikael and the Homenet list to CC.
Homenet, the issue we're dealing with is that babeld performs badly when
there is a transparent wireless bridge connected to a wired interface: the
interface is treated as a lossless wired interface, and if it suffers
packet loss, there is repeated link fla
>> I'm probably missing something -- but where in the HNCP document does it
>> say that applied prefixes must be announced over the routing protocol?
>> I don't see it in Section 6.3.3.
> I'd say the role of HNCP and the routing protocol and what does what, is
> not really specified anywhere.
HNC
I'm probably missing something -- but where in the HNCP document does it
say that applied prefixes must be announced over the routing protocol?
I don't see it in Section 6.3.3.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/ma
> The IESG has approved the following document:
> - 'Home Networking Control Protocol'
> (draft-ietf-homenet-hncp-10.txt) as Proposed Standard
Yay!
(Congratulations to Markus, Stephen and Pierre, and also to Mark and
everyone else who sweated water and bl
-- Juliusz
>>> Hmm. I've also setup many small PKIs and don't agree. I do think someone
>>> could easily make all that quite usable within the home.
>> Have you ever walked a non-specialist through the process?
> I have not.
I see.
-- Juliusz
___
homenet mailin
> Hmm. I've also setup many small PKIs and don't agree. I do think someone
> could easily make all that quite usable within the home.
Have you ever walked a non-specialist through the process?
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https:
>> I'll be giving a talk about it early next year.
> When you do, if you have English slides please consider sending them to
> this list as well.
Good idea, and a good excuse to write my slides in English.
-- Juliusz
___
homenet mailing list
homenet@i
> A new Request for Comments is now available in online RFC libraries.
>
>
> RFC 7695
Congratulations, Pierre ! It's a nice algorithm, I'll be giving a talk
about it early next year.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.iet
>> While src-dest routing is certainly a solution - and an interesting
>> one - it doesn't seem at all appropriate for an HNCP spec to assert
>> that it is necessary.
> True. However, we were asked to describe the applicability, and
> I consider e.g. tunneling solution inferior so I would rather n
> It MUST be set to 0 if the router is not capable of doing FOO,
> otherwise it SHOULD be set to 4 but MAY be set to any value from 1 to
> 7 to indicate a non-default priority. The values 8-15 are reserved
> for future use.
Steven, shouldn't it say explicitly what a node does when it receives
a ca
> I am not fine with SHOULD for IPv4 as it will essentially break it;
Agreed, but I don't feel strongly about it.
> I can live with MUST for IPv6 but consider it unneccessary.
Agreed, announcing your IPv6 address, if it's chosen randomly, just wastes
24 bytes * prefixes * nodes * interfaces. Th
>> That's very well put, and exactly what I'm trying to explain to the
>> community. Please help me do that rather than adding to the perception
>> that HNCP contains dozens of random, arbitrary requirements.
> That's what I thought I was doing by writing that message! I am not
> sure it's helpf
> There is a reason why IETF standards are harder than ad hoc protocols: we
> specify what's needed to solve the problem generally and interoperably,
A lot of the MUST in HNCP are not about interoperability, they are about
mandating the features that we want Homenet routers that we have. In
other
>> HNCP is an amazingly flexible protocol, and one that will hopefully be
>> used well beyond it's original area of application. Many of the possible
>> applications of HNCP don't require DTLS, either because the network is
>> secured at a lower layer, or because they use a different application
>
Dear Kathleen,
> 2. Can you explain why DTLS is a SHOULD and not a MUST? The bullet in
> section 3 reads as if this is for use, not implementation. Is there a
> MUST for implementation (I didn't see one, but maybe I missed that)?
I am not one of the authors of the draft, but I'm the author of
> Of course, the coolest thing to be able to do would be to have an SSID
> that is a homenet backbone network, with a single (or multiple) homenet
> edge routers, and then attach to that using additional homenet routers,
> which would join that homenet. This would allow us to see a _lot_ of
> devi
> So what is the scope of the request and what needs to be simulated?
There are two distinct requests here:
1. have the IETF DHCPv6 servers delegate a /60 (at least) to any client
that requests it;
2. have the hnetd software automatically deal with the situation in which
no DHCPv6 serv
> I think the base view is, "we'll spec things for IPv6; if IPv4 gets the
> benefit, so much better".
Very well put, but not exactly what happens with HNCP, which specifies
things fairly precisely for IPv4. (A good thing, IMHO.)
> In this case... what's do we get from doing src/dest routing for
> could not nicely build out Homenet connection to the Internet because my
> internet provider of choice (IETF ;-) did not offer IPv6 prefix
> delegation on its network.
I know that's not what you're asking about, but still...
The Homenet party line, er, consensus, is that we expect the ISP to al
Dear all,
I've written up the discussion about a Homenet profile of Babel we've had
(both on-list and off-list) in the form of a draft of an Internet-Draft:
http://www.pps.univ-paris-diderot.fr/~jch/software/babel/draft-chroboczek-homenet-babel-profile.txt
http://www.pps.univ-paris-diderot.
> No, that is not true. The applicability section also mentions e.g.:
[...]
> I'm not sure what other points could be added,
Since every change in the set of neighbours of a node causes reflooding,
DNCP is not suitable in environments where high levels of node mobility
are expected?
-- Juliusz
> Are all your AP on the same frequency? Did you enable diversity-sensitive
> routing for babel? If not, you should add in /etc/config/babeld:
>
> config general
> option diversity true
I disagree, Gabriel -- since IS-IS doesn't do diversity routing, the
comparison is more interesting if babeld d
Thanks a lot for doing that, Mikael. Dynamically computed metrics are an
essential aspect of zero-configuration routing, sadly overlooked by the
IS-IS community in the past.
> I'd say both protocols/implementations are doing a decent job.
Interesting. I didn't expect SNR to be such a good predi
>> (2) SHOULD RFC 6126, IPv4 subset;
> Why not MUST? [...] I don't think the prodding should be done by causing
> unnecessary pain for average consumers.
Fully agreed, but I'm not sure what is the WG's thinking about IPv4. RFC
7368 (Homenet arch) is conveniently vague about IPv4. My reading i
Dear all,
As Ray mentioned in his mail, there's a need to define the minimum Babel
profile for Homenet. Pro memoria, Babel is defined as follows:
- the body of RFC 6126 defines the basic protocol, and leaves link
quality sensing and route selection to the implementation.
- Appendix A of
> Notwithstanding the valiant efforts of the Design Team, the Chairs
> believe that there is WG consensus that a single “mandatory to
> implement” routing protocol must be chosen. We also believe that further
> delaying the direction here has long passed the point of diminishing
> returns.
>
> Bas
>>> SHNCPD is good for a few first tests, but it only contains a subset of
>>> the useful HomeNet features.
>> Huh? What useful features are missing?
> What is about the interaction of SHNCPD with (M)DNS?
Right, SD and NAT-PMP proxying are not implemented by shncpd.
> Can I add the hybrid-prox
> SHNCPD is good for a few first tests, but it only contains a subset of
> the useful HomeNet features.
Huh? What useful features are missing?
(Yes, I've got your patches, just too busy right now.)
-- Juliusz
___
homenet mailing list
homenet@ietf.org
>>> a valid test of the metric setting features would be to have two wifi
>>> networks, one 2.4GHz, one 5Ghz, two different L2s, different IP
>>> networks, and then walk around with two clients connected together with
>>> a network cable, and check if the routing would change from the 5GHz
>>> netw
> a valid test of the metric setting features would be to have two wifi
> networks, one 2.4GHz, one 5Ghz, two different L2s, different IP
> networks, and then walk around with two clients connected together with
> a network cable, and check if the routing would change from the 5GHz
> network to the
> E.g. what if someone wants to share a DVD image to upgrade their routers
> using the protocol? DNCP is _not_ the way. URL + hash of content, or
> magnet link, perhaps, but not the image.
I think that's an enlightening example. Perhaps it could be mentioned in
the document somewhere?
-- Juliusz
> Are you referring to
n> http://www.pps.univ-paris-diderot.fr/~jch/software/babel/ ? I find
> 4 papers, two have broken links, one is for ad hoc networks, and another
> one is multi-hop mesh protocols.
Yes, all of them are in mesh networks. Since IS-IS doesn't do meshes,
you'll need to design a
This is interesting. Could you please share your experimental data?
>>> I would also be interested in this...
>> I haven't seen a reply to that. Are you doing experimental testing
> Could you please link to experimental testing you have done
I already have, repeatedly.
Please check the
>>> - Dynamic IS-IS Route Metric updating based on WiFi QualityInfo
>> This is interesting. Could you please share your experimental data?
> I would also be interested in this...
I haven't seen a reply to that. Are you doing experimental testing, or
are you implementing random features so you
>> Are you assuming that there are no dumb layer 2 APs in the network?
> Yes, that is a tradeoff.
Could the chairs please clarify whether restricting ourselves to
a particular class of topologies is acceptable for Homenet?
-- Juliusz
___
homenet maili
> * When responding to a multicast request over a multi-access medium,
> why is the randomization of the transmit time only a SHOULD?
> I would think that needs to be a MUST.
> Therefore I consider it a SHOULD; certainly, _for some link layer_, you
> may want it a MUST, but in general,
> - Transport: both L2 & IPv6 (Link-Local)
Which is suggested for Homenet? The two don't interoperate, right?
> - Point-to-Multi-Point or Broadcast over L2 or IPv6
Which is suggested for Homenet? Or do the two interoperate?
> These are standard IS-IS wide metrics, although it makes use of the
> - Dynamic IS-IS Route Metric updating based on WiFi QualityInfo
This is interesting. Could you please share your experimental data?
Getting dynamic metrics right in link-state is tricky, and using them in
a reliably flooded link-state routing protocol has never been done before
to my knowledge
> What I am starting to suspect is that OpenWrt's «IPv6 ULA-Prefix»
> setting is orthogonal to the Homenet handling of the interfaces,
Yes, that's my understanding too.
> I have to wait for a +3.3V UART to be delivered before I can get OpenWrt
> installed on it.
Then there's the bit when you try
> BTW - this reminded me that I also noticed that after rebooting a
> router, another ULA prefix (*not* the one configured in OpenWrt on
> either router) also showed up and links were numbered using it, but it
> vanished again after a while. No idea where it came from. To be
> investigated! :-)
Se
> This and broken WiFi roaming were the only two things that made me want
> to go back to my old non-Homenet setup
I agree, these are the two remaining issues with the current Homenet stack.
If you still have some energy left for experimenting, and a spare router
lying around, I'd be curious to k
> I am not very fond of idea of having to push anything to ISP for my
> _home_ network to work _within home_.
Please, let's listen to this man.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
> That's exactly the point. If my PC can discover my printer, media device
> etc. today if it is on the same link and we are introducing home
> networks with multiple links, I want this discovery to seamlessly work
> across links without needing to update my PC's operating system.
You're absolutel
>> While I would have expressed it in somewhat milder terms, I tend to agree
>> with Michael. If HNCP gets massively deployed together with a naming
>> protocol that is easy to implement, the host implementations will come in
>> due time.
> I'm not sure what problem you and Michael are claiming n
> If you don't like the idea using the NODE NAME TLV to announce DNS
> information of the local hosts, how would you do it without a central
> server configured by a network admin?
* mDNS plus mDNS proxying; or
* mDNS over ff05::fb; or
* announce a bunch of dynamic DNS servers (inside or outs
>> Requires host changes. Out of scope.
> This is *complete* bs.
While I would have expressed it in somewhat milder terms, I tend to agree
with Michael. If HNCP gets massively deployed together with a naming
protocol that is easy to implement, the host implementations will come in
due time.
--
> - publish a DNS Delegated Zone TLV that points to a (local or remote)
> DNS server that responds for that zone.
Markus,
Let's please not put per-host state into HNCP, it's not dealing very well
with churn (remember Jin Kaiwen's results?). Let's use HNCP for
bootstrapping the routers, let's l
Thanks for the explanation, Markus.
What does that mean for shncpd? I do nothing, and wait for the pixie dust
to settle?
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
I've changed the subject, since we're drifting away from the initial
concern, which was how to get a name within the Homenet for unmodified
hosts that got their address over SLAAC. Exporting these names to the Big
Bad Internet is a laudable endeavour, but it's condemned to failure if we
cannot eve
> how DNS can be bootstrapped and parent domains delegated to a Homenet
> Border Router.
I think we're speaking about different things. You're speaking about
exporting the naming of the Homenet into the ISP (the single ISP, sigh)
and from there into the global DNS, while we're speaking about havi
> Can we just go with whichever recommendations come out of dnssd?
>
> https://datatracker.ietf.org/wg/dnssd/charter/
> https://datatracker.ietf.org/wg/dnssd/documents/
Could you perhaps point me at a specific paragraph of a specific draft and
tell me "Do implement this, we're betting the
> - DHCPv6 (ha ha! but at least it is simple in this case)
I've received a few queries about this by private mail, some of which
indicate there is some confusion, so please let me clarify.
DHCPv6 has two modes of operation. Stateless DHCPv6 is a fine protocol
for propagating static configuration
>> Short-term reachability indications are sent to hosts in a reactive manner,
>> using ICMP unreachables. If any applications are unable to do the right
>> thing with ICMP unreachables, we should fix the applications.
> How do you propose the application to react? Most applications leave
> the
> I guess we might as well simply recommend MDNS
Fair enough, assuming there is mDNS proxying in the Homenet. (Or should
we be speaking on ff05::fb and counting on Pierre to do some magic?)
> DHCPv6 [...] relevant usecases [...]
And here I thought you were a friend.
-- Juliusz
___
>> How does a host announce its name and address to the Homenet? Just mDNS?
>> Or are we planning a protocol to store the mapping within DNS?
> Since we mainly have to live with what is there today (and in the IETF), the
> obvious solutions are MDNS
Ok.
> and stateful DHCPv6.
Over my dead body
>> So if a route is flapping, hosts get or don't get an IP depending on the
>> exact time when they send a DHCPREQUEST or NS? Is that better than always
>> assigning an IP to hosts, and expecting ICMP to signal route flapping in
>> real time?
> Are you talking about a route that is created and va
Hi,
How does a host announce its name and address to the Homenet? Just mDNS?
Or are we planning a protocol to store the mapping within DNS?
(I'm assuming no stateful DHCPv6, of course.)
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www
>> out what links interfere? Is this something that would need
>> a centralized view of the home network?
>
> There is also the quite common powerline to ethernet bridges.
Yeah. They look just like Ethernet to the host, so short of speaking the
HomePlug AV management protocol, I don't see how t
> Yes. If DHCP server and radvd wait until the route to the prefix is
> available in the routing table, we keep the decision about
> "reachability" to the routing protocol without having a hard dependency
> on it.
So if a route is flapping, hosts get or don't get an IP depending on the
exact time
> If I understand HNCP right then the "uplink" will announce a prefix
> which should be used by all routers for the attached hosts.
Er... no. The "uplink", or delegating router in Homenet parlance, only
announces a source-specific route. It's the routers performing the
assignment that announce a
> It is not uncommon for wireless links to use some kind of hysteresis
> on a routing protocol. The problem/feature of D/HNCP is that it is
> independent of the routing protocol... so it does not know.
I'm not sure I'm following you.
All that shncpd does is to announce attached prefixes over the
> [...] each router connected to said [Common] link:
> MUST forward traffic destined to said prefix to the respective link.
Here's the mechanism in the shncpd implementation, Steven will hopefully
tell me if that's what's intended:
- for each locally delegated prefix P, we install:
- a sou
> So my previous opinion stands, I think the homenet routing protocol should
> support ECMP on wired links that are between two directly connected
> devices with identical link speeds.
No problem with that -- but if it does ECMP, it must be smart enough to
avoid pessimising the traffic in the redu
> Ted, I asked a question about a feature that is considered critical in
> every routing environment that I am familiar with.
I think that we all have different pictures of what a homenet will look
like. Some of us appear to believe that homenets will predominantly
consist of wired links with a f
>A node MUST be able to detect whether two of its local internal
>interfaces are connected, e.g., by detecting an identical remote
>interface being part of the Common Links of both local interfaces.
>
> What should the node do if it detects that two interfaces are on the same
> link?
> IGP based multicast protocol is suggested, pls refer to
> http://tools.ietf.org/html/draft-yong-isis-ext-4-distribution-tree-02.
That's similar to MOSPF, but done in IS-IS, right?
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.
>> Why are HNCP codepoints specified as "standards action"? It's a 16-bit
>> space, wouldn't "documentation required" be good enough? Or even FCFS?
> With my RFC6709 hat on, I would advocate a fairly strict policy for
> extending something that walks and quacks like a routing protocol.
It's not
> Over the last couple of weeks, I've amused myself with doing a
> clean-slate implementation of the Babel protocol in the Bird routing
> daemon
Excellent news, Toke. I've had a first read over your code, and it looks
almost correct (I have some minor nits). I'll read it again, and do
a detailed
Why are HNCP codepoints specified as "standards action"? It's a 16-bit
space, wouldn't "documentation required" be good enough? Or even FCFS?
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
> The assumption is that the user will want to receive traffic from the
> ISP. To do so, it needs to subscribe first (e.g. using MLD) on one of
> the WANs. One problem is that you don’t know which WAN. The solution
> used here is to subscribe on all WANs.
Sorry if I'm being dense -- but does th
>> Could you please explain what problem you're solving with the SSMBIDIR
>> extension?
> SSBIDIR is not very different than BIDIR. It still uses one single
> forwarding tree,
Thanks for the explanation.
So what happens when there are multiple default routes?
>> What problem does the proxying b
201 - 300 of 652 matches
Mail list logo
