>>> (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?

>
> Same issue as above.
>
>>> This will require changing the algorithm in Section 5.4 (since the
>>> neighbor graph is no longer necessarily connected).
>
>> That will result in state hanging around forever unless we introduce
>> some TTL scheme alongside it. Considering the main design goal of DNCP
>> is _not_ to have TTLs in the protocol,
>
> Ah.  Right.  I'm an idiot.
>
> Please make this rationale more explicit in the draft -- it's said in the
> introduction, please repeat it in Section 5.4.
>
> I'll think about it some more, but I think you've convinced me -- I don't
> see a good way to avoid the state explosion without giving up on the
> link-state nature of DNCP.  (Which I understand is not likely to happen.)

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...


-- 
Dave Täht
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to