On 1 October 2010 06:55, Doug Barton wrote:
> In any case I didn't say that 6rd was not useful at all. What I tried to
> make the case for is that its utility is limited, both in the absolute sense
> and in the temporal sense; and that because of these limitations the
> benefits that adding the c
On 9/30/2010 11:36 PM, Dan Langille wrote:
On 9/30/2010 11:06 PM, Dan Langille wrote:
Hi folks,
I'm setting up IPv6 at home. On the gateway, I can ping6 just fine. But
not from within the LAN.
I have:
Routed /48: 2001:470:8a86::/48
Routed /64: 2001:470:1f07:b80::/64
On the gateway, I have th
On 9/30/2010 11:36 PM, Dan Langille wrote:
On 9/30/2010 11:06 PM, Dan Langille wrote:
Hi folks,
I'm setting up IPv6 at home. On the gateway, I can ping6 just fine. But
not from within the LAN.
I have:
Routed /48: 2001:470:8a86::/48
Routed /64: 2001:470:1f07:b80::/64
On the gateway, I have th
On 9/30/2010 11:06 PM, Dan Langille wrote:
Hi folks,
I'm setting up IPv6 at home. On the gateway, I can ping6 just fine. But
not from within the LAN.
I have:
Routed /48: 2001:470:8a86::/48
Routed /64: 2001:470:1f07:b80::/64
On the gateway, I have this:
# cat /etc/rtadvd.conf
fxp1:\
:addrs#1:
Hi folks,
I'm setting up IPv6 at home. On the gateway, I can ping6 just fine.
But not from within the LAN.
I have:
Routed /48: 2001:470:8a86::/48
Routed /64: 2001:470:1f07:b80::/64
On the gateway, I have this:
# cat /etc/rtadvd.conf
fxp1:\
:addrs#1:addr="2001:470:1f07:b80::":prefix
On Thu, 30 Sep 2010, Doug Barton wrote:
Hey,
In any case I didn't say that 6rd was not useful at all. What I tried to make
the case for is that its utility is limited, both in the absolute sense and
in the temporal sense; and that because of these limitations the benefits
that adding the code
On 9/30/2010 2:46 PM, Rui Paulo wrote:
I really don't feel like discussion this ad nauseum as your last IPv6
thread, but 6rd is useful and your argument about the timeline for
FreeBSD 9.0 doesn't make sense: we can have this on FreeBSD 8-STABLE
in a week after this is committed to HEAD.
Well I
On 9/30/10 10:49 AM, Ryan Stone wrote:
It's not a big thing but it would be nice to replace the m_next and
m_nextpkt fields with queue.h macros.
funny, I've never even thought of that..
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.o
On 30 Sep 2010, at 20:16, Doug Barton wrote:
> On 9/30/2010 12:13 PM, Rui Paulo wrote:
>> On 28 Sep 2010, at 23:27, Doug Barton wrote:
>>
>>> On 9/22/2010 1:32 PM, Hiroki Sato wrote:
>>> | Hello,
>>> |
>>> | Can anyone try a patch for adding 6rd (RFC 5569) support to stf(4)?
>>>
>>> Well I don
Hi,
The attached patch supports tablearg options to setfib.
With the patch, you can add rules like
ipfw add 100 setfib tablearg ip from 'table(1)' to any
It help in policy based routing as discussed in this thread.
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=124951+0+archive/2009/freebsd-net/2
On 9/30/2010 12:13 PM, Rui Paulo wrote:
On 28 Sep 2010, at 23:27, Doug Barton wrote:
On 9/22/2010 1:32 PM, Hiroki Sato wrote:
| Hello,
|
| Can anyone try a patch for adding 6rd (RFC 5569) support to stf(4)?
Well I don't want to be "Mr. Negativity," but I'd like to suggest that
adding this su
On 28 Sep 2010, at 23:27, Doug Barton wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 9/22/2010 1:32 PM, Hiroki Sato wrote:
> | Hello,
> |
> | Can anyone try a patch for adding 6rd (RFC 5569) support to stf(4)?
>
> Well I don't want to be "Mr. Negativity," but I'd like to sug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi, Jack,
On 2010/09/17 10:42, Jack Vogel wrote:
> Put DDB/KDB into the kernel and get me the stack trace when this
> problem happens. Tell me exactly what the hardware is (pciconf).
Just wanted to let you know that after putting DDB/KDB into the k
It's not a big thing but it would be nice to replace the m_next and
m_nextpkt fields with queue.h macros.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr
14 matches
Mail list logo
