Subject: Re: [homenet] Fwd: [v6ops] default LAN routing protocol for IPv6 CE router

From: Fred Baker <[email-masked]>
Date: Tue, 2 Aug 2011 09:29:18 -0700

On Jul 28, 2011, at 9:00 AM, Joel Jaeggli wrote:

>> I think the third point on desirability of a path is key.  The routing
>> protocol should avoid constrained paths like 802.15.4 mesh networks in
>> favor of longer routes through technologies like Wi-Fi or Ethernet.  We
>> need to define appropriate routing metrics to make this happen.

Routing protocols will generally do that anyway, but I agree that we should make sure for normal cases.

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 2 Aug 2011 21:54:20 +0000

Agreed, however, it still not make it the best solution for the problem
space.

On 8/2/11 12:39 AM, "Shane Amante" <[email-masked]> wrote:

>
>On Aug 1, 2011, at 12:47 PM, Lorenzo Colitti wrote:
>
>
>On Mon, Aug 1, 2011 at 14:40, Philip Homburg <[email-masked]>
>wrote:
>
>It doesn't matter how do it. If it is done using an IGP, then can you bet
>that
>either some ISP happens to be using that IGP on WAN links, or that some
>script
>kiddies will try to see what happens if you try to send those packets to
>random CPEs.
>
>
>
>IGPs support authentication. As part of setting up your home network, you
>could associate CPEs with each other and use that to form a common auth
>key.
>
>
>
>
>And, likewise, any ISP worth their salt should be:
>a) using authentication *within* their access and Backbone network; and,
>b) using ACL's to protect their routing & signaling protocols
>... so there's absolutely no legitimate reason that a customer's network
>should ever "accidentally" be joined to the SP's IGP ...
>
>-shane
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 2 Aug 2011 23:08:49 +0000

On 8/2/11 3:47 AM, "Ray Hunter" <[email-masked]> wrote:

>As for only delegating a single /64 to home users
>i) I would hope ISP's are more sympathetic to home users who have genuine
>needs for a DMZ, guest LAN etc. now that NAT won't provide a solution for
>this requirement
[jjmb] I am sure shorter allocations will be available.  As I stated in an
earlier email the end user also needs to make sure their CPE supports the
same.

>ii) I would also hope that CIDR works beyond 64 bit prefix lengths (even
>if SLAAC doesn't yet)
[jjmb] assuming you are referring to longer than /64 this could work you
would have to leverage DHCPv6 for address assignment or static
configuration.  I imagine this may complicate renumbering.

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 2 Aug 2011 23:09:00 +0000

On 8/2/11 11:39 AM, "Nick Hilliard" <[email-masked]> wrote:

>On 02/08/2011 13:28, Keith Moore wrote:
>> A different idea is that the firewall always work in a very minimal mode
>> by default (e.g. it passes no traffic, or maybe only outgoing port 80
>> traffic, but its configuration interface is enabled for the internal
>> ports) so that the user must configure it in order to get it to do
>> anything useful.
>
>Each support call into a support centre costs money, and if you scale it
>up, any user that ends up calling support is basically losing money for
>the
>ISP.  Yes, margins are that thin.
[jjmb] +1
>
>Building a firewall that almost guarantees that an end-user will need to
>open a support call is both useless to the end-user and financially
>harmful
>to a service provider.  There is no point whatsoever in doing this - it
>adds pointless complexity with no measurable return.
[jjmb] conversely building a firewall that exposes the provider will also
cost in some way shape or form.
>
>If you want to build a router suitable for Keith Moore, then go out and
>customise a WRT54G, or hack a soekris into shape.  But don't assume that
>most end-users have either the interest or the capability to work out a
>good quality security policy for themselves because by-and-large, they
>don't.
[jjmb] advanced users should buy advance routers so they can do advanced
things.
>Nick