On Thu, Jan 30, 2014 at 5:18 AM, Mikael Abrahamsson <[email protected]> wrote:
> On Thu, 30 Jan 2014, Ole Troan wrote:
>
>> We need to decide, if we want prefix assignment and distribution of other
>> configuration information integrated in a routing protocol. Depending on
don't want it in the routing protocol.
>> that decision we either need to design a separate protocol to do that, or we
>> need to add support for that in a routing protocol.
>> Prefix assignment is
>> simpler with a link-state protocol,
I don't have any love for link-state personally.
> so that's why I have limited the choice
>> of routing protocols for that branch. I have assumed there is agreement to
>> have a single routing protocol in the home, and not support multiple.
I'm interested only in a routing protocol that works well with wired, wireless,
and the internet of things.
I don't think anyone will ever agree to a single routing protocol decision
unless the protocol meets those requirements well, and is battle tested
to meet those requirements well. And none do.
> I agree with the decision chart.
>
> While I initially was very enthusiastic about integrating prefix assignment
> into a routing protocol, I am now more sceptic to this approach.
I was unenthusiastic, (as are the maintainers of every routing daemon
I know of) and wanted to leverage ahcpd's methods (if not
necessarily the existing version of the protocol) of propagating info,
pre-routing information.
> So question if we don't use the routing protocol for prefix assignment, what
> should go in there? Should we have a new protocol for service discovery?
It is my hope that hybrid-proxy-mdns solves this. Certainly mdns is pretty
good about picking up dynamically changed
> Topology discovery? Anything else? Anyhow, the src/dst enhancements for the
> IGP has to be done, I don't see much alternative to that.
src/dst support landed in openwrt Barrier Breaker and cerowrt a week
or two back.
(it's still kind of rough). I also finally got up on comcast ipv6 personally.
In addition to src/dst semi-solving a raft of problems (bcp38 for ipv6
anyone?), it exposed others
like
-1) Getting a swarm of RA's from upstream triggered a firewall reload
every few seconds,
which took a few seconds to reload, leading to an unusable ipv6
implementation.
(if you are running cerowrt or openwrt on comcast DO upgrade. Ghu help you if
you are merely on an "ipv6 certified" router)
0) comcast is only distributing a /60.
It still seems that being able to distribute and route between /128s is needed,
and nd proxying for folk that are only doing a /64 and have subnets.
1) in the multi-homing case you want requests from a local dns server
to be sourced
from the right network to the right ISP-provided forwarder. (think
I have a fix for
that but it involves abandoning resolv.conf for specific dnsmasq
configuration.
2) most vpn technologies are not aware of src/dst routing decisions and routing
protocols can route around them, mistakenly. (tried strongswan so far)
3) Boy do we need to be able to forcibly retract ips and routes after
a reboot and
acquisition of a new subnet and loss of an old.
The only way I can see clear to doing this is to support some form
of authentication.
"I got this subnet from this source, and now it's telling me to
retract it in favor of
this subnet"
4) the vast increase in ipv6 related multicast led me to finally
violate the 802.11 standard and
fix wireless multicast rates to 9mbits. So far that hasn't broken anything.
> Anyhow, I don't think DHCPv6-PD is a good method to assign prefixes to
> interfaces.
Well, it works on the edge gateway, not so much on interior.
> --
> Mikael Abrahamsson email: [email protected]
>
> _______________________________________________
> homenet mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/homenet
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
