From: Steven Barth <cyrus@openwrt.org>
To: "Ole Trøan" <otroan@employees.org>
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Current state of ipv6 in openwrt barrier breaker
Date: Tue, 11 Dec 2012 21:46:59 +0100 [thread overview]
Message-ID: <b2e6e3482f87119a1847afabee5802cb@midlink.org> (raw)
In-Reply-To: <8F973FF7-B39D-4E21-B889-14F6105A29F4@employees.org>
Hi Ole,
your feedback is appreciated, thanks.
Just to clarify a few things here because I think there might be
misunderstandings.
> or create state...
> NPT should not be on by default though
I agree and it won't be a default in plain OpenWrt.
> I think the the ULA prefix should be created as specified in RFC4193.
> otherwise you'll get into trouble merging networks, or building a
> mesh with your neighbour.
> (overlapping ULA space).
In the current implementation /dev/urandom is used to generate the /48
on the first boot of the device. fd00:: was just an example here.
I don't see any particular advantage in using the sha / ntp etc. thing
especially since there might not be a working RTC.
> shouldn't all interface have a /64?
I won't restrict users doing anything else but /64 is the default, yes.
> actually it should not be expected to have global reachability.
> doing ULA to global translation by default would break one of the
> ideas we have in the homenet WG,
> about allowing devices on the network not being prepared to be on the
> global Internet use ULAs. that way
> we can avoid firewalls on the network borders, and still protect the
> unprepared... ;-)
Yes the problem is that source address selection seems to be a trouble
on clients. I just had users / tester complain yesterday about devices
using ULA instead of the 200X: source addresses breaking connectivity
when both are announced so now I had to implement a hack that sets
the preferred time of the ULA to 0 when there are prefixes with global
reachability.
Similarly I see NPT only as a way to work around client issues
- especially when having multi-homing / redundant uplinks -
and not as a default way of doing things.
Cheers,
Steven
next prev parent reply other threads:[~2012-12-11 20:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-11 19:56 Ole Trøan
2012-12-11 20:25 ` Dave Taht
2012-12-11 21:31 ` Ole Trøan
2012-12-12 8:19 ` Dave Taht
2012-12-12 9:08 ` Ole Trøan
2012-12-12 9:19 ` Steven Barth
2012-12-12 9:28 ` Ole Trøan
2012-12-12 9:47 ` Steven Barth
2012-12-12 10:11 ` Dave Taht
2012-12-12 18:56 ` Michael Richardson
2012-12-12 9:05 ` Török Edwin
2012-12-11 20:46 ` Steven Barth [this message]
2012-12-11 21:02 ` Ole Trøan
2012-12-12 8:23 ` Steven Barth
2012-12-12 8:43 ` Ole Trøan
-- strict thread matches above, loose matches on Subject: below --
2012-12-10 8:41 Dave Taht
2012-12-10 9:15 ` Dave Taht
2012-12-10 11:27 ` Steven Barth
2012-12-10 11:40 ` Dave Taht
2012-12-10 11:53 ` Steven Barth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b2e6e3482f87119a1847afabee5802cb@midlink.org \
--to=cyrus@openwrt.org \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=otroan@employees.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox