On 11 May 2016, at 15:01, Ray Hunter (v6ops) <[email protected]
<mailto:[email protected]>> wrote:
Tim Chown wrote:
On 25 Apr 2016, at 03:39, Ted Lemon <[email protected]
<mailto:[email protected]>> wrote:
On Sun, Apr 24, 2016 at 12:29 PM, Juliusz Chroboczek
<[email protected]
<mailto:[email protected]>> wrote:
> 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 DDNS?
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.
That to me seems to be putting pragmatism before requirements.
To an extent it is. The Bonjour protocols are much more widely
implemented and deployed than DNS Update.
Yes. I've seen a lot of printers shipping with it, and it works great at
that scale.
I've also seen enterprises working with fully integrated DNS, together
with managed Windows Domain Controllers, at monster scale.
Homenet is somewhere in the middle: we have more complexity, but no
"computer certificates" to fall back on.
I'm not entirely convinced by the dnssd work, and have said so on the
relevant WG.
Do you mean the need for it based on Bonjour, or the solution given
we’re building on that?
Both.
Bonjour is a great protocol for a flat L2 network.
Bonjour is not designed for L3 networks (no inherent hop count, nor loop
protection), nor support for multiple/overlapping name spaces.
The Homenet architecture calls for administrative zones.
I may have a guest LAN.
I may have a printer LAN (that is shared with guests)
I may have a media server (which is not shared with guests)
The Homenet architecture calls for multiple upstream providers.
I may have an electricity provider who allows me some special log on via
the power network to control home automation, or feed back from my solar
panels. They may publish (private) names for use by contracted customers
that are not available over the Internet. Yes, that could also be done
over Internet, but a specialised "walled garden" could be so much more
secure and less vulnerable to external disruption.
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 Appletalk NBP/ZIP resolution also prevents loops in routed networks.
Otherwise I struggle to map the Homenet requirements onto the solution.
[BTW for the record, I don't consider DNS "as-is today" a great
contender either. So I'm not just bashing Bonjour by any means]
Note that one requirement was that other SD protocols could be
integrated into the hybrid proxy model. That’s still possible, but no
one has expressed any interest as yet.
I don't like the hybrid proxy model either.
It promises the union of the problems and intersection of the functionality.
Proxying flies in the face of the trend of smart devices and dumb networks.
If you get any device that bypasses, or misunderstands, the proxy
topology, we could get very nasty name resolution loops [no inherent
loop protection in Bonjour].
But Ted has raised the question of DNS Update there, and we agreed
in BA that we’d accept a draft on issues around coexistence of mDNS
and DNS Update.
If "it" (multi-subnet mDNS) is going to cause more issues down the
line, is it sensible to pull this into Homenet now?
I think this is why Ted is doing what he is doing. Homenet is a
different environment - smaller and unmanaged, generally.
Is that the intended question to be answered by that draft?
The question is what happens in environments where both might mix.
Well, that’s one question. Ted offered to draft a -00 on that topic,
in one of his spare moments ;)
That seems like a worthwhile draft.
> 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 the same security
characteristics that mDNS has, we have to ensure that the update
actually originated on the local link, which requires a different
sort of listener than is present in a typical DNS server. And
existing DNS servers typically don't have any way to support
unauthenticated updates on a first-come, first-served basis, so if
you allow unauthenticated updates, you don't have any way to avoid
collisions. Otherwise you are correct. The answer is to write a
document that describes how to do that, and if you read the homenet
naming arch document, you can see that I actually sketched out a
solution there, which I expect to go in a different document,
likely in a different working group.
There are many worms in that can :)
I understand that this is potentially a huge can of worms, but if no
one opens it, it'll never get solved.
So my preference would be to write down what we want in Homenet (in
the naming architecture document, in a technology-agnostic way),
analyse the gaps against competing current technologies, and then see
what people propose to close those gaps.
That sounds like a good start.
If multi-subnet mDNS comes out a clear winner, then I'll shut up.
But I'm not even convinced that the gaps are understood/ documented
at this time.
No, and I agree there. But that doesn’t preclude delivering the hybrid
proxy model, which is certainly applicable in campus environments (and
was in response in part to an educause petition), and for which Markus
has presented a draft for how that model could work in homenets.
Tim
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
