> 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 ex
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
specification
>> 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
>> feat
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 definit
> 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.
>> 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 a
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.
https://mailarchive.ietf.org/arch/
> #5 The arguments why this is better than DDNS don't convince
> me, except for the last one (new RR types). Given that DDNS is
> deployed, what's the chances that this would also get traction?
I think that's an important point. I actually asked the very same
question back in 2014:
https://ma
> I thought that we wrote somewhere in RFC7368 that the Homenet router should
> collect as many ports as possible together into a single L2 zone.
Section 3.3.2?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
> AFAICS there's certainly enough room for me to experiment with patches to
> i) reduce MTU to avoid problems arising from L2 MTU mismatches and
> ii) to reduce the amount of fragments (at the expense of more UDP packets)
> without any tweaking of the standards.
In case you're interested, here's t
>>> 1) DNCP allows an option of whether a network state TLV contains optional
>>> nested payload (HNCP) TLV's or not.
>> I'm pretty sure that's not the case. RFC 7787 Section 7.2.2.
> A OK so you're saying this is already covered in (Section 4.4 of) 7787
[...]
> state hash. The Node Sta
> 1) DNCP allows an option of whether a network state TLV contains optional
> nested payload (HNCP) TLV's or not.
I'm pretty sure that's not the case. RFC 7787 Section 7.2.2.
The Network-State TLV only contains the network state hash, short
Node-State TLVs are separate top-level TLVs. An implem
> The reason for the 64k limit is clear (due to the design choice of relying on
> UDP fragmentation).
> What's still unclear to me is why the packet contains all the nodes' TLV's.
Because HNCP allows aggregating multiple TLVs in a single packet, to the
implementation's discretion. Section 4.2 of
>> HNCP is a standards track protocol, and there's nobody left who's
>> willing and competent to work on a new revision.
> Yes, of course. We can never change a standards track protocol. That
> would be wrong. :)
My wording was perhaps badly chosen. Sorry for that.
I meant to say that I don't c
> I notice in the current Openwrt code that the max UDP packet size is set at
> 9000 octets with the comment:
> /* Very arbitrary. On some implementations, I have seen some issues
> * with 10+kb frames so we use this for now. It MUST be significantly
> * more than 4k, due to how code is written
> This still doesn’t address the problem that the HNCP packet needs to be
> fragmented. Fragmented Multicast doesn’t scale well.
HNCP doesn't fragment multicast, it only uses fragmentation for (link-local)
unicast. This is way less severe than what you incorrectly claim.
At any rate, the right
> If you have a discontinuous L2 MTU, you do not need fragmented packets
> to see packets disappear.
Ah, I see.
> No fragmentation of any sort involved, just incorrectly set up L2 segments.
Right. It's an incorrect network setup.
To fix that, it should be enough to point the tunnel directly at
> The problem is, how’d the packet get so big that it was fragmented?
HNCP relies on network-layer fragmentation: it uses UDP and has no
application-layer mechanism for fragmenting large TLVs. See Section 4.2
and Appendix B.2 of RFC 7787.
(I seem to recall that an earlier version of DNCP include
> The L2TPv3 tunnel has a lower MTU than the local LAN, and does not report ICMP
> PTB, so HNCP packets in one direction get through, but replies get dropped.
Is that not a bug?
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org
> Question: do PCP messages always go to the default route?
Yes, at least according to 6887.
> I re-read 6887 and that was unclear.
Section 8.1:
the default router list (for IPv4 and IPv6) is used as the list of
PCP server(s).
[...]
For the purposes of this document, only a s
> Hmm, so do you think it's possible that HOMENET could land in the "uses
> secure link layers" bucket?
No opinion on the above. I'll only state that HNCP supports running over
DTLS (this is implemented in hnetd, the reference implementation of HNCP).
Section 8.3 of RFC 7787 describes a distribut
> Interesting stuff - wireguard, fq_codel/sch_cake, babel with new
> metric that allows for cryptocurrency traffic billing.
Justin, could you please document the private TLVs that you're using and
register them with IANA? (I'm currently under pressure to make the TLV
allocation more onerous, and
> No, we are assuming that there are one or more homenet routers that either
> come with a delegated domain from the manufacturer (probably a very ugly
> one), or which that CPE's ISP will delegate via DHCPv6. (or both)
I see. (I still disagree with the technical choices, especially that of
bindi
>> Your turn now. Could you please describe the UI that you envision?
> The list of names (from the internal mDNS/DNS-SD, as well as DHCP hostnames)
> is presented to the house owner, they click on the ones that the want to
> be publically visible.
Are you assuming here there's a central Homenet
> It would seem your objection can be summarized as "we don't need this".
> Correct me if I'm wrong.
No, my objection is that I cannot see how that can work in a decentralised
manner -- with no central Homenet controller.
> To me is like saying we don't need a new routing protocol like BABEL, be
> Actually, it's fatal, because you can't get a certificate for "boombox.local"
> so you can't secure it that way. So you always have to use the FQDN.
That sucks, of course, but the problem is completely unrelated to being
published in the global DNS -- the very same problem applies to names that
Dear Michael,
>> Please see my unanswered e-mail of 21 November 2018.
>> https://mailarchive.ietf.org/arch/msg/homenet/vz1kdCJISN6UPNZpj9ZD4e8EdwQ
Thank you for your detailed reply. I'm glad we're finally having
a discussion about my objections to Daniel's proposal.
> We strongly believe that
> The front end naming architecture uses a primary and a secondary dns server to
> synchronize a zone.
People will recall that the need for a hidden primary hasn't been
established yet. Please see my unanswered e-mail of 21 November 2018.
https://mailarchive.ietf.org/arch/msg/homenet/vz1kdCJIS
>> If there is a more complex HNCP network, then we could probably simulate
>> the L2 scenario with VXLAN, configured by HNCP.
> If memory serves, VXLAN requires support for multicast, which HNCP+Babel
> doesn't provide. There's a set of IBM (?) extensions to VXLAN that avoid
> the use of multica
> If there is a more complex HNCP network, then we could probably simulate
> the L2 scenario with VXLAN, configured by HNCP.
If memory serves, VXLAN requires support for multicast, which HNCP+Babel
doesn't provide. There's a set of IBM (?) extensions to VXLAN that avoid
the use of multicast, I'm
> prplMesh solves the wifi broadcast domain issue.
>https://prplfoundation.org/working-groups/prplmesh/
>From their website: « prplMesh is an open-source, carrier-grade and
certifiable implementation of the WiFi Alliance’s Multi-AP specification. »
That's a purely layer 2 solution that relies
> PIE [...] lends itself better for implementation in existing hardware,
> or hardware with small modification.
Could one of you please explain why?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
>> I think that this work should be stalled until we have an implementation
>> to play with and make some in vivo experiments.
> I'm not sure if by "stalled" you mean sticking with the plan above, or
> something else
I'm concerned about two things:
- if you're not implementing yourself, every
Hi Stephen,
Sorry if I'm repeating myself -- I've already expressed the opinions
below, both at the mike and on the list.
> (a) work on simple naming
I think that this work should be stalled until we have an implementation
to play with and make some in vivo experiments. (Experience shows that
t
> Both HNCP and Babel carry their control traffic over link-local IPv6, but
> they support both IPv4 and IPv6 with almost equal functionality.
> (The only significant difference is the treatment of border routers, which
> are assumed to be doing NAT in IPv4 and stateless routing in
> I do remember that talk. CS grad students are not our target market.
First year undergrad, Ted. Eighteen year-old lass with no previous
networking experience.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo
>> It should be an easy fix, feel free to go ahead.
> The point of soliciting participation at hackathon is for us to gain
> collective experience on the easy or difficulty of deploying homenet in
> practice.
Oh, that's different, and not at all the motivation you give in your
previous mail. Exp
>> Both HNCP and Babel carry their control traffic over link-local IPv6, but
>> they support both IPv4 and IPv6 with almost equal functionality.
>>
>> (The only significant difference is the treatment of border routers, which
>> are assumed to be doing NAT in IPv4 and stateless routing in IPv6.)
> Both HNCP and Babel carry their control traffic over link-local IPv6, but
> they support both IPv4 and IPv6 with almost equal functionality.
> in fact while what you are saying is technically true, in practice IPv4
> _is_ treated like a second-class citizen in the sense that if your
> IS
> What I meant is that homenet router protocols are v6 only.
No, they're not.
Both HNCP and Babel carry their control traffic over link-local IPv6, but
they support both IPv4 and IPv6 with almost equal functionality.
(The only significant difference is the treatment of border routers, which
are
Thanks for your reply, Daniel.
> If I understand correctly the question is why do we have a Homenet Naming
> Authority responsible to outsource the Homenet Zone to the Public
> Authoritative
> Servers ( Front End architecture) instead of having each device updating their
> data directly to the Pu
Dear Daniel,
> I am planning to update the front end naming delegation draft [1] in the next
> weeks. Before revisiting the draft, I am collecting comments that need to be
> addressed.
After your talk at IETF-102, I asked what is the purpose of this rather
complex protocol, and why it is prefera
> Markus, I tried to be really clear about what I was communicating on the
> slide about implementations, but probably failed.
Indeed.
A number of your comments about Markus' code were entirely unnecessary.
-- Juliusz
___
homenet mailing list
homenet@
> Anyway, getting back to topic of Ted's passionate speech about bad HNCP
> implementations, I'd love to see him (or someone else) provide better one :-)
Ted is busy working on his implementation of Simple Naming. Please leave
him in peace, it's important that he convince us that Simple Naming is
>> From a user perspective, there are a few problems:
> When an interface goes down and then up again, it's renumbered. This
> includes reboots.
That shouldn't happen as long as there remains at least one Homenet router
to maintain the prefix (see Section 4.1 point 3 of RFC 7695).
I believe that
> Juliusz is saying that he wants a nearly stateless homenet;
No, I'm not.
> for him, putting the public/primary functional block in the cloud makes
> sense
No, it doesn't.
Ted, please don't put words into my mouth. It's unpleasant, and it's
disrespectful.
-- Juliusz
> if the homenet loses its memory, it can simply refresh it from the cloud.
What?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
>> neither SIP, nor Skype, nor BitTorrent, nor syncthing, nor anything
>> else that normal people run in their home relies on the DNS for
>> locating remote peers.
> If publishing things into global DNS worked reliably and automatically,
> and we had IPv6 everywhere, such designs would not be need
> Why? What is wrong with the owner of the network selecting which devices
> / services he/she wants globally reachable
I don't think this is about global reachability (which is hopefully managed
by PCP), it's about exporting names into the global DNS. We ought to
distinguish the two -- you can b
> Apparently my comment was clear as mud. I meant this:
> https://tools.ietf.org/html/draft-ietf-opsawg-mud-25
Quote, "YANG-based JSON that describes a Thing", unquote. 61 pages.
Revision 25, and still a draft. I wish you a lot of fun implementing that.
> Having a public/private zone pair where
> By using DynDns are you proposing to remove the requirement of having
> a naming resolution mechanism internally in the homenet ?
No. Naming *internal* to the Homenet needs another mechanism, perhaps
what Ted is designing (and implementing), perhaps something else.
Exporting names from the Hom
> One way to automate this would be using mud.
A bright light shines from the heavens, bathing you in its warm glow. An
enormous, white temple stands to the north, taking most of your view.
In order to enter the Temple of Homenet Naming, you must travel up the
large staircase that stands in fron
> On the other hand same thing using nsupdate (using TSIG and dynamic
> dns) is one command line + input file for nsupdate:
Cool.
Whichever end-to-end (host to DNS provider with no intermediate proxying)
encrypted and authentified protocol you pick, I'm with you.
-- Juliusz
>> And it's literally four lines of shell:
> vs
> while true; do
> (omitted for brevity)
You're doing end-to-end dynamic update over DNS, which is fine with me.
The exact transport we end up using doesn't matter that much.
You're not doing the proxying through a hidden master mandated by Daniel
> I am not speaking about discovery within the Homenet. I am speaking about
> exporting names into the global DNS, which is what Daniel's draft is
> about.
> Yes, but the problem is that you are treating this as if these are two
> separate problems, but they are not.
These are two com
> I think the local ULA should be used for all intra-ULA connections. We had a
> debate about this about four years ago, and apparently the text in the HNCP
> spec reflects the outcome of that discussion, but I think we understand the
> problem better now and we should fix this.
Agreed.
_
I've re-read Section 6.5 of 7788, and it looks like I was wrong. Sorry,
I should not be writing technical mails in the middle of the night.
As far as I can tell from the wording of 6.5:
- creating ULA is SHOULD if there's no global IPv6, MUST NOT otherwise;
- creating private IPv4 is MAY if
> In order for services to be discoverable on the homenet, they have to
> publish their contact info on the homenet. The protocol that everyone
> uses for this is DNSSD. This is how you find your printer when you want
> to print to it. Nobody uses the ad-hoc DynDNS protocol for this.
I am not spea
>> But if we want homenet to be widely adopted, I do not think this is the
>> correct default behavior: it violates the principle of least surprise.
> There's no surprise, it just works. RFC 6724, Section 6, Rule 8.
Er, no. ULAs have global scope. My bad.
-- Juliusz
_
> In order for IPv6 to be useful, you need naming to work.
No argument here.
> But if we want homenet to be widely adopted, I do not think this is the
> correct default behavior: it violates the principle of least surprise.
There's no surprise, it just works. RFC 6724, Section 6, Rule 8.
-- Ju
> All of this can be done in the DNS without resorting to any other protocol.
Excellent.
So what technical reasons are there to prefer the complexity of
draft...front-end-naming-delegation over a trivial update protocol,
whether encapsulated in HTTPS or DNS?
-- Juliusz
_
During his talk, Ted claimed that he lost all connectivity when his uplink
went down. This should not happen -- HNCP normally maintains an IPv6 ULA
that remains stable no matter what happens to DHCPv6 prefix delegations or
DHCPv4 leases. This is described in Section 6.5 of RFC 7788, and it is
the
Dear all,
Since the 1990s, people have been putting their dynamically allocated IPv4
addresses into global DNS by using a family of gratuitiously incompatible
trivial protocols. The technique doesn't have an official name (let alone
a specification), and is usually referred to as DDNS, DynDNS or
For people who have missed the Babel meeting, both David and I have done
our best to write self-contained slides. They're here:
https://datatracker.ietf.org/meeting/102/materials/slides-102-babel-hmac-in-babel-00
https://datatracker.ietf.org/meeting/102/materials/slides-102-babel-dtls-i
>REQ5: a Homenet implementation of Babel MUST use metrics that are of
>a similar magnitude to the values suggested in Appendix A of
>RFC 6126bis.
> "MUST" and "similar magnitude" are not a great pairing.
Fixed. This is now "must", the exact values are still SHOULD.
> I agree with th
> §2.1, REQ5: I agree with Benjamin Kaduk that " MUST use metrics that are of
>a similar magnitude" is a bit vague to be used with a MUST.
This is now "must". Exact values are still SHOULD.
> §1.1: Please consider using the 8174 boilerplate. There is at least one
> instance of a lower case k
> I do have some non-blocking comments:
Thank you very much, Alvaro.
> (1) I think that this document walks a fine line when Normatively
> referring to Appendix A in rfc6126bis given that it is an informative
> appendix.
Fixed to use non-normative language, as you suggested.
> (2) This reminds
> - draft-ietf-homenet-babel-profile-06 waiting on Juliusz for updated draft
My current draft of -07 is here:
https://raw.githubusercontent.com/jech/babel-drafts/master/draft-ietf-homenet-babel-profile/draft-ietf-homenet-babel-profile.xml
It addresses all of Tim Chown's Opsdir review, almost
Hi, and sorry for the massive cross-posting. I suggest followups should
go to babel@ietf.
The mails that I'm receiving indicate that we (Babel@IETF) have confused
some people with our crypto plans. Thanks to all for your questions, and
let me please try to clarify things publicly.
Considering s
> My biggest problem is that I don't have a very clear idea of how this all fits
> together.
Same here.
As I mentioned at the microphone in London, there's a lot of moving pieces
here, and everybody would feel much more comfortable if
1. we could have a look at Ted's implementation; and
2. s
>> The draft lives here:
>>
>> https://github.com/jech/babel-drafts/tree/master/draft-decimo-babel-dtls
> As far as the commit history goes, the file was first added to the
> repository above on 25 June 2018 (four days ago), then it was updated
> three times on 27 June 2018 and two times on 29
Dear Denis,
Thank you very much for your kind mail.
Unfortunately, I think there might be some confusion:
- DTLS is Stenberg-style security;
- HMAC is Ovsienko-style security,
- it has four variants (7298, 7298bis, DKC, Stenberg)
- two of which have fatal flaws (7298 and 7298
> Well, let me invent something. I throw together my network and it
> names the printers as printer1 and printer2. Being a stickler,
> I decide to rename them as Printer 1 and Printer 2. I mess around
> and find a config file somewhere and manually edit it.
Let me rephrase it:
« F
> Perhaps he refers to the RFC8174 update to the boilerplate:
Ah, thanks. Will do.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
> you should refer to 8174.
Perhaps you could kindly justify your advice? Non-capitalised "must" is
used just once in this document, and I don't see any opportunity for
ambiguity.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf
After much thought, I have settled on the following:
Rationale: support for wireless transit links is a distinguishing
feature of Homenet, and one that is requested by our users. In
the absence of dynamically computed metrics, the routing protocol
attempts to minimise the
> we are writing a standards document, not a 19th century romance novel
It is a truth generally acknowledged that a single man in possession of
a good fortune must be in want of a home network.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.
>> This is not the notion that I tried to express, probably badly. It's not
>> necessarily the important feature, it's the one that will make people
>> implement and deploy the protocol stack in the first place.
> Suggestion for '"killer feature" of Homenet': driver for using Homenet
That's good
> I too think the rationale is important but the phrasing may be confusing.
> Being
> a native speaker of U.S. English (and almost fluent in Southern Californiaese
> ;-) I found the colloquialisms confusing.
Being myself a native speaker of an Eastern-European dialect with way too
many postalveol
> I am the assigned Gen-ART reviewer for this draft.
Thanks for your comments, Stewart.
> if implementations use conflicting route selection policies,
> persistent oscillations might occur.
SB> Is this consistent with the statement earlier in the para that
SB> " Distinct
SB> implement
> the AmazonEcho/GoogleHome/Mycroft/etc. devices seem like ideal platforms
> to be the root of a secure network.
Huh?
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
> I do agree we'd need to know e.g. whether Babel implementations would
> plan to support what flavours of DTLS (e.g. pre-shared keys vs. bare
> public keys vs. certs if they do plan to use DTLS),
I'm not worried about Babel. I am worried about HNCP, since I fear
there's nobody who's both able a
> Filename: draft-ietf-homenet-babel-profile-04.txt
Barbara has pointed out that I had some minor changes in my git repository
that I hadn't submitted yet. Barbara also requested that I upgrade this
draft to Standards Track before I quit.
I couldn't possibly bring myself to refuse
Dear Barbara, dear Stephen,
After re-reading the comments I have received on the mailing list, and
re-reading my slides from 2017-03-27, I have decided that this has taken
way too long.
I hereby quit as editor of draft-ietf-homenet-babel-profile. Should you
be able to find a new editor, I expect
>> Should we really only suggest that the router dynamically probe the
>> quality of wireless links? Or would it make sense to suggest dynamic
>> probing of all links, because assuming the entire path between 2
>> routers uses a single physical layer technology may not be a good
>> assumption?
> I
>REQ6: a Homenet implementation of Babel SHOULD distinguish between
>wired and wireless links ; if it is unable to determine whether a link
>is wired or wireless, it SHOULD make the worst-case hypothesis that
>the link is wireless. It SHOULD dynamically probe the quality of
>wi
> Currently the draft has intended status of "Experimental".
That's what Mark told me to do.
> Given the intended status of 6126bis is Standards Track (and HNCP (RFC
> 7788) is also Standards Track), would it make sense to make
> homenet-babel-profile Standards Track as well?
Yes, I think so.
>
>> draft-chouasne-babel-tos-specific-00 may also cause issues, even though
>> it is just informational. You may want to consider removing the
>> reference so it doesn't create issues.
> Ok.
Does the same apply to [BABEL-Z]?
___
homenet mailing list
hom
Thanks, Barbara.
> The first 4 references to the "Babel routing protocol" spec are to
> [RFC6126bis]. All subsequent mentions are to RFC 6126.
Changed to 6126bis throughout. Since Homenet depends on source-specific,
and source-specific depends on mandatory bits, Homenet cannot be
implemented wit
> I re-read babel-profile-03 and have a few comments (below)
> offered as a WG participant (i.e. chair hat off) as part of
> WGLC.
Thanks, this is appreciated.
> - Req5: Is "MUST be... of a similar magnitude..." clear enough?
Yes. Minor tweaks to metrics don't cause suboptimal routing -- if one
Cross-posting between Babel and Homenet.
At this morning's Babel meeting, Barbara asked whether the work going on
in Babel on security means that homenet-babel-profile should be delayed.
I said no. Please, no. I beg you, Barbara, no.
I started working on this document in early autumn of 2016.
>> I think you're underestimating normal people, James.
> Bear with me please.
With you -- always.
> It's worth noting that in the vast majority of cases like you describe,
> the CE router provided by the ISP is only serviceable by the provider, or
> if it *is* serviceable by the subscriber, the
> The protocols we are developing here in HOMENET are for the tiny minority
> of people who prefer to build their own home networks instead of just
> plumbing their ISP directly up to every device in their home.
I think you're underestimating normal people, James.
I do not remember the last time
> I find the model of "there is a CPE, and behind that CPE, I connect
> another router to get homenet functionality" a bit unsatisfactory.
I think there are two possible deployment models.
1. The « My Friendly ISP » model
Every ISP-provided CPE participates in HNCP. Each ISP has access to all
t
> That makes perfect sense to me. I don't think the DTLS implementation would be
> that hard—is there any chance that anyone would be interested in working on
> this during the hackathon in Singapore?
A student of mine (Antonin, whom you might remember from Berlin) has been
working on that. Unfor
[Added babel@ietf to CC.]
Thanks, Ted.
> https://datatracker.ietf.org/doc/draft-lemon-homenet-babel-security-latest/
I'm not a security specialist, so just a few comments:
1. You're using a TLV, which means that the TLV parser runs before auth.
Is this good practice? What about using the pack
> Please, please, please take the time to read the Security Considerations
> and tell me if there's anything I need to change.
> https://tools.ietf.org/html/draft-ietf-homenet-babel-profile-02#section-4
This is now
https://tools.ietf.org/html/draft-ietf-homenet-babel-profile-03#section-4
Dear all,
This is just to remind you that I'm going to request Last Call for
draft-ietf-homenet-babel-profile. I'll be submitting a very slightly
amended (editorial changes only) version in the next days.
Please, please, please take the time to read the Security Considerations
and tell me if the
Confirmed, this is consistent with both known implementations of HNCP, as
well as with the tcpdump parser. This was also confirmed by Markus Stenberg
in a mail dated 9 June 2016 to myself and the former Homenet chairs.
Message-Id: <0aacde36-6a89-471e-8eea-b6a90197b...@iki.fi>
-- Juliusz
_
>> If the fast connection's DNS server replies after a delay or not at all,
>> and the slow connection's DNS server replies in a timely manner, using
>> a smart resolver across all the available DNS servers will improve latenc
> Yes, but if your fast connection is lossy, it's not fast. Lossy looks
1 - 100 of 652 matches
Mail list logo
