>Now could we achieve this in a multi-link Homenet without any
>elections?
The primary purpose of the election is to avoid having multiple different zones
and names for the same link. It's not so much an issue of running multiple mdns
proxies but mainly to avoid duplication.
That's why the fi
On 31.8.2015, at 13.16, Henning Rogge wrote:
> On Mon, Aug 31, 2015 at 11:42 AM, Steven Barth wrote:
>>> Now could we achieve this in a multi-link Homenet without any
>>> elections?
>>
>> The primary purpose of the election is to avoid having multiple different
>> zones and names for the same l
On Mon, Aug 31, 2015 at 12:34 PM, Markus Stenberg
wrote:
> On 31.8.2015, at 13.16, Henning Rogge wrote:
>> Typical configuration of a cheap router would be to run dnsmasq for
>> local DHCP and as a DNS cache. If each of these DNS caches could
>> forward DNS queries for *..homenet to the relevant
On 31.8.2015, at 13.37, Henning Rogge wrote:
> On Mon, Aug 31, 2015 at 12:34 PM, Markus Stenberg
> wrote:
>> On 31.8.2015, at 13.16, Henning Rogge wrote:
>>> Typical configuration of a cheap router would be to run dnsmasq for
>>> local DHCP and as a DNS cache. If each of these DNS caches could
>
Hi,
Jumping in here with the perpective of a «dumb user» who spent the
weekend playing with the Homenet implementation in OpenWrt 15.05...
(Note that I don't know whether my comments pertain to the Homenet
standards themselves or are specific to the OpenWrt implementation.)
* Markus Stenberg
>
On Mon, Aug 31, 2015 at 12:44 PM, Markus Stenberg
wrote:
> Let’s assume a shared link with 2 homenet routers (rid1, rid2) and 1 host
> (foo).
>
> Given no election, use of e.g. mDNS to determine hosts/services would result
> in the host showing under both rid1.home and rid2.home. That isn’t a pr
On 31.8.2015, at 14.12, Tore Anderson wrote:
> Jumping in here with the perpective of a «dumb user» who spent the
> weekend playing with the Homenet implementation in OpenWrt 15.05...
>
> (Note that I don't know whether my comments pertain to the Homenet
> standards themselves or are specific to
On 31.8.2015, at 14.17, Henning Rogge wrote:
> On Mon, Aug 31, 2015 at 12:44 PM, Markus Stenberg
> wrote:
>> Let’s assume a shared link with 2 homenet routers (rid1, rid2) and 1 host
>> (foo).
>>
>> Given no election, use of e.g. mDNS to determine hosts/services would result
>> in the host sho
On 31.8.2015, at 14.33, Markus Stenberg wrote:
> Sure, you can define link segment name election mechanism and use per-link
> names (they are even mentioned as an option in
> draft-ietf-homenet-stenberg-hybrid-proxy-zeroconf; see also why doing that
> zeroconf might be bad idea), but I am not s
* Markus Stenberg
> Instead, it sounds like potentially issue with IPv4 + dnsmasq (e.g.
> option that prevents RFC1918 replies from being forwarded), I hope
> you are not using legacy IP :)
I left everything at defaults, so my links were indeed numbered using
IPv4 (RFC1918, 10/8), as well as IPv
Erik Kline wrote:
On 26 August 2015 at 15:41, Juliusz Chroboczek
wrote:
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 paragr
On 31.8.2015, at 14.42, Ray Hunter (v6ops) wrote:
> Also DND SD (RFC 6763) states "Address-based Domain Enumeration queries are
> performed using names under the IPv6 reverse-mapping tree" which is under the
> direct control of the individual upstream ISPs.
>
> So, what are people expecting to
In general I think making unqualified names work is problematic. We'd need to
add one search path entry per link which doesn't scale. Plus duplicates are not
really handled deterministically.
Cheers,
Steven___
homenet mailing list
homenet@ietf.org
h
Hi,
On Mon, Aug 31, 2015 at 01:16:28PM +1200, Brian E Carpenter wrote:
> > And that's a well-known issue that the IETF needs to finally tackle:
> > source-address failover.
>
> We did - it's called shim6. The trouble is that we can't deploy it
> because of stupid firewalls blocking the necessary
Hi,
On Sun, Aug 30, 2015 at 10:03:47PM -0700, joel jaeggli wrote:
> >> And that's a well-known issue that the IETF needs to finally tackle:
> >> source-address failover.
>
> So long as you don't invoke the prospect of either extremely expnesive
> overlay networks, or globably route scalability g
On 08/31/2015 05:05 AM, Markus Stenberg wrote:
On 31.8.2015, at 14.42, Ray Hunter (v6ops) wrote:
upstream ISP (via DHCPv6), and forward delegation (glue records) are entered
via the domain registrar via http or something else?
I am not very fond of idea of having to push anything to ISP for
On 08/31/2015 04:42 AM, Ray Hunter (v6ops) wrote:
Juliusz (and others) have objected to
https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options
because it appears to be tied to the ISP. Yet for reverse resolution,
the ISP is an essential party, because they have been
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Home Networking Working Group of the IETF.
Title : Home Networking Control Protocol
Authors : Markus Stenberg
Steven Barth
Hi everyone,
this is HNCP revision 9. This version addresses the issues raised in the second
WGLC. Changes include final adaptions to the latest DNCP version (updated TLV
definitions, improved version handling), as well as clarifications to client
configuration and naming.
Cheers,
Steven
Am
On 01/09/2015 01:24, Gert Doering wrote:
> Hi,
>
> On Sun, Aug 30, 2015 at 10:03:47PM -0700, joel jaeggli wrote:
And that's a well-known issue that the IETF needs to finally tackle:
source-address failover.
>>
>> So long as you don't invoke the prospect of either extremely expnesive
>>
Why is topology being forced into the naming? DNS is independent
of topology. We have *a* home. I really don't care what link my
printer is connected too. It is not something I want to see in its
name unless I put it there.
Have ".home" be the default suffix with a low preference. Allow
any
21 matches
Mail list logo
