On 28.5.2015, at 19.20, Dave Taht <[email protected]> wrote:
>>>> (3) it is impossible to act as a dumb DNCP forwarder without publishing
>>>> a Node-State TLV and a full set of Neighbor sub-TLVs.
>>> This is not true. Given basic bridging of ‘remember one guy on end of
>>> each link’, you can do essentially bridging.
> so my use case (wanting routers without any ipv6 ips, just the fe80::,
> to be able to forward requests onward) is merely a limitation of the
> implementation?
Well, IPv6 IPs _are not forced_ by DNCP _or_ HNCP. Current implementation wants
to do the assignments now by default, but I think if you set ip6assign=0 (or
whatever the desired prefix length parameter was), you would get what you want
now too.
The light-weight bridging of DNCP described here (or some other scheme) is
something else. And for the record, I do not recommend it even if I _think_ I
made it possible when thinking of the current DNCP design originally.
> I had hoped for DNCP to be merely AHCP on a steroid, not the explosion
> of complexity that resulted.
>
> I have kind of been evolving something rather different.
>
> What I do right now leverages the source specific information in the
> routing protocol to assume that whatever is exporting a source
> specific default /60 or /56 route has a whatever::1 address in the
> first prefix of that, then self assigns itself a SLAAC/128 address
> out of the topmost /64, then uses curl over https to contact each for
> a potential prefix and other configuration information.
>
> Tis nothin but a bunch of itty bitty shell scripts like:
>
> getdefgws() {
> ip -6 route | grep '^default from' | grep / | while read d f addr via splat
> do
> mask=`echo $addr | cut -f2 -d/`
> a=`echo $addr | cut -f1 -d/`
> echo $a/$mask
> done
> }
>
> with stuff to measure the shortest and fastest paths (traceroute or ping)...
>
> and a bit of lua. distinct advantages are not having to upgrade any
> routers in the path with a new daemon,
> implicit security of the https, the state primarily lives on the
> source specific gw.
>
> disadvatages are tis hard to write it all in a shell script, and I
> imagine someone will object to someone treating somewhere::1 as a
> "special" indicator of an IP being available for configuration
> purposes, and no doubt more…
Well, sounds like you’re inventing god server for a subset of what HNCP does :)
I find it amusing that you consider https in and of itself a source of security
though. Do you actually validate your certs etc? Sounds relatively far from
zeroconf.
(And I wonder how one does e.g. OCSP without actually having network
configuration up.)
Couldn’t you just run DHCPv6 PD to the prefix::1 too? No need for magic, ready
encoding for lots of things, and support for PSK if you want it ’secure’
(arguably less painful to set up than your own cert hierarchy).
Cheers,
-Markus
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
