Re: [Cerowrt-devel] shaggy dog story on 3.8.8-4 experiences

[Michael Richardson <mcr@sandelman.ca>]

[-- Attachment #1: Type: text/plain, Size: 3620 bytes --]


>>>>> "Steven" == Steven Barth <cyrus@openwrt.org> writes:
    Steven> I was on holiday until yesterday so my reply is a bit late.

Thank you for the reply!

    >> which means that any subnet that isn't allocated anywhere does not
    >> result in a routing loop.  It also causes the 6relayd to assign prefixes
    >> to each interface.
    >> 
    >> I will see if I can hack on 6relayd, because I really like this.

    Steven> This is actually done by netifd, not 6relayd. 6relayd is the
    Steven> RA/DHCPv6-server 
    Steven> used in OpenWrt trunk (CeroWrt uses dnsmasq here I think) and provides most
    Steven> of the homenet functionality (RFC 6204 should be pretty much covered by
    Steven> OpenWrt with very few exceptions - I think only one)

okay, I see. I would have thought that since the prefix came down via
DHCPv6, that this was being done there too.  I will read through netifd.

    >> >> At least one prefix is behind another router, so this router can not
    >> >> see that prefix is already in use.  Suggestion: start at highest
    >> >> number available and work downwards.

    Dave> Two interior prefix allocation methods have been described by the
    Dave> homenet and hipnet rfcs. openwrt follows neither at present.

:-)

    >> sure, that's not the point.  The point is that the set of "prefixes in
    >> use" is not limited to just those on local interfaces, but also ones
    >> that might have a static route elsewhere.   Yes, I agree that routing
    >> protocols are important and useful... that's why I have 4x 3800 now for
    >> play and testing :-)
    >> 
    >> The incidence of conflict would be less if the auto-assigned numbers
    >> started from highest number.  At least for me, it would.

    Steven> That's imo not a good idea because it doesn't really solve the issue.

I understand... I wasn't suggesting it would solve the problem, just
make it less of a toe stumbing event.

    Steven> I could modify the assignment logic in netifd to scan through all ip6addrs
    Steven> configured before distributing any prefixes and exclude ip6addr assigned
    Steven> prefix parts from being reassigned again.

That's really what we need.

    Steven> Regarding the other cases: It is possible to set ip6assign to something <64
    Steven> so that a bigger prefix is assigned to a downstream-interface. With 6relayd
    Steven> as DHCPv6-server this automatically makes anything but the first /64
    Steven> available on the interface to downstream routers via
    Steven> DHCPv6-PD (the first /64 
    Steven> is announced using RAs on the interface).

wow, that's really cool.  I will actually use this then so that my main
router can then play ISP for my test router...

    Steven> The technically better solution would be a mechanism where programs could
    Steven> request a prefix via some RPC-mechanism from netifd. However
    Steven> this would need 
    Steven> synchronization and callback-mechanism to inform the routing daemon when a
    Steven> prefix is assigned / deassigned etc.

dare I suggest... dbus?
I know that network manager already sends out dbus messages about new
prefixes configured, and things like pidgin listen and reconnect when
they see a new prefix.

"everyone is doing it"  (even the Automotive people)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
	

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]