On Mon, 16 May 2011, Todd Lyons wrote:
Double check the kernel version you have. IIRC kernels before 2.6.20
didn't have the ability to do RELATED,ESTABLISHED in ipv6. This hit
me on a CentOS box that I was using as a gateway. I am unaware if
there is a version of their 2.6.18 that has the pat
On Fri, May 13, 2011 at 2:32 PM, Jeroen van Aart wrote:
>
> Something like:
> -I FORWARD -j DROP
> -I FORWARD -s 2001:db8::/64 -j ACCEPT
> -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
Double check the kernel version you have. IIRC kernels before 2.6.20
didn't have the ability to do
On May 13, 2011, at 3:33 PM, Jeroen van Aart wrote:
> Owen DeLong wrote:
>> On May 13, 2011, at 2:32 PM, Jeroen van Aart wrote:
>
>>> -I FORWARD -j DROP
>>> -I FORWARD -s 2001:db8::/64 -j ACCEPT
>>> -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
>>>
>> I thought iptables processed ru
Owen DeLong wrote:
On May 13, 2011, at 2:32 PM, Jeroen van Aart wrote:
-I FORWARD -j DROP
-I FORWARD -s 2001:db8::/64 -j ACCEPT
-I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
I thought iptables processed rules in order until it found a match. In such a
case, wouldn't
you want th
On May 13, 2011, at 2:32 PM, Jeroen van Aart wrote:
> Jeroen van Aart wrote:
>> -I FORWARD -i eth0 -s 2001:db8::/64 -j ACCEPT
>> -I FORWARD -i eth1 -d 2001:db8::/64 -j ACCEPT
>
> Just in case if anyone'd be using it as an example. It's a good idea to make
> your rules more restrictive.
>
> Som
Jeroen van Aart wrote:
-I FORWARD -i eth0 -s 2001:db8::/64 -j ACCEPT
-I FORWARD -i eth1 -d 2001:db8::/64 -j ACCEPT
Just in case if anyone'd be using it as an example. It's a good idea to
make your rules more restrictive.
Something like:
-I FORWARD -j DROP
-I FORWARD -s 2001:db8::/64 -j ACCEP
Jeroen van Aart wrote:
Thanks all for the helpful suggestions.
Obviously I need to do a better job using documentation IPv6
consistently, so ignore any inconsistencies in that regard.
--
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html
Joe Loiacono wrote:
Jeroen Massar wrote on 05/12/2011 09:19:21 AM:
On 2011-May-12 15:14, Joe Loiacono wrote:
Anyone know roughly the current default-free routing table size for
IPv6?
http://www.sixxs.net/tools/grh/status/
Awesome web-site. The world of IPv6 routing on one page.
That is
Thanks all for the helpful suggestions.
It looks like I solved the problem by adjusting my forward chain. I have
a the local network on eth0 and the external network on eth1 and my
forward chain looked like:
-I FORWARD -i eth0 -o eth1 -s 2001:db8::/64 -j ACCEPT
-I FORWARD -i eth1 -o eth0 -d 2
On 13 mei 2011, at 18:42, Matthew Petach wrote:
>> The current RIR practice to reserve a /44 when a /44 is given out is a very
>> bad one. It assures unfilterability, because now you have random sizes from
>> /44 to /48 in the parts of the address space used for PI. And if say, 64k
>> /48s are
On Fri, May 13, 2011 at 12:56 AM, Iljitsch van Beijnum
wrote:
> On 13 mei 2011, at 2:39, Jimmy Hess wrote:
>
>> if the user starts obtaining
>> multiple non-aggregable /48s from different sources, or obtains an
>> additional PI allocation later, but
>> keeps using the original /48.
>
> Simple: m
On 13 mei 2011, at 2:39, Jimmy Hess wrote:
> if the user starts obtaining
> multiple non-aggregable /48s from different sources, or obtains an
> additional PI allocation later, but
> keeps using the original /48.
Simple: make a rule that you don't get more than one PI block, and if you want
a
Anthony Francis - Handy Networks LLC wrote:
I can confirm full IPV6 connectivity from HE.
I'm using the HE tunnel also and it works fine.
But I have a bit of difficulty getting the right ip6tables (and the
single iptables) rules to work so that my one server that tunnels ipv6
can serve as a
On Thu, May 12, 2011 at 8:39 PM, Jimmy Hess wrote:
> A very important distinction. The _immediate_ hit to the DFZ might be
> the same as obtaining PI V6 space,
> but the _long term_ hit to the DFZ might be much greater;
The real issue is that there are many /48 announcements today which
should b
On Thu, May 12, 2011 at 5:49 PM, George Bonser wrote:
> Possibly the hit might be the same, but possibly not. An organization
> that requires a second /48 from their upstream might get one that can't
> be aggregated with the previous one. It is my understanding that ARIN
A very important distin
On May 12, 2011, at 3:49 PM, George Bonser wrote:
>> In the RIPE region, being multihomed or planning to be it is not a
>> sufficient condition for getting a PI prefix. And even if it was, the
>> hit on DFZ is the same as from getting allocation from LIR. Even if
>> they get their own /32, the h
> In the RIPE region, being multihomed or planning to be it is not a
> sufficient condition for getting a PI prefix. And even if it was, the
> hit on DFZ is the same as from getting allocation from LIR. Even if
> they get their own /32, the hit would be the same (modulo individual
> FIB/RIB implem
George,
On Thu, May 12, 2011 at 11:41 AM, George Bonser wrote:
>> A lot. I see /48 breakouts from /32 PA blocks for instance, announced
>> by a
>> customer AS of the PA holder AS.
>>
>> --
>> Mikael Abrahamsson email: swm...@swm.pp.se
>
> Which is kinda sad.
It's reality.
> If those customer
Who sees the most AS's?
> A lot. I see /48 breakouts from /32 PA blocks for instance, announced
> by a
> customer AS of the PA holder AS.
>
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
Which is kinda sad. If those customer AS are multihomed or plan to be
multihomed, they can get their own allocation out of PI s
Jeroen Massar wrote on 05/12/2011 09:19:21 AM:
> On 2011-May-12 15:14, Joe Loiacono wrote:
> > Anyone know roughly the current default-free routing table size for
IPv6?
>
> http://www.sixxs.net/tools/grh/status/
Awesome web-site. The world of IPv6 routing on one page.
> 3668 good/required pr
On Thu, 12 May 2011, Jeroen Massar wrote:
As you can see, some folks seem to carry HALF of the table EXTRA than
they need let alone that poor ISP which is carrying almost 2/3s
more, I don't have time to check into it, but I wonder how much junk is
in there
A lot. I see /48 breakouts
Hi,
> Bernhard Schmidt wrote on 05/12/2011 06:27:38 AM:
>
>> Anthony Francis - Handy Networks LLC wrote:
>>
>> > I can confirm full IPV6 connectivity from HE.
>>
>> How can you confirm that when HE just admitted to be lacking IPv6 routes
>> from Cogent and a couple of other players?
>
> Anyone
On 2011-May-12 15:14, Joe Loiacono wrote:
> Bernhard Schmidt wrote on 05/12/2011 06:27:38 AM:
>
>> Anthony Francis - Handy Networks LLC wrote:
>>
>>> I can confirm full IPV6 connectivity from HE.
>>
>> How can you confirm that when HE just admitted to be lacking IPv6 routes
>> from Cogent and a
Bernhard Schmidt wrote on 05/12/2011 06:27:38 AM:
> Anthony Francis - Handy Networks LLC wrote:
>
> > I can confirm full IPV6 connectivity from HE.
>
> How can you confirm that when HE just admitted to be lacking IPv6 routes
> from Cogent and a couple of other players?
Anyone know roughly the
Anthony Francis - Handy Networks LLC wrote:
> I can confirm full IPV6 connectivity from HE.
How can you confirm that when HE just admitted to be lacking IPv6 routes
from Cogent and a couple of other players?
Bernhard
On 12 mei 2011, at 12:06, Owen DeLong wrote:
> IPv6 peering
> is somewhat different from IPv4.
How is it different?
I can confirm full IPV6 connectivity from HE.
-Original Message-
From: Owen DeLong [mailto:o...@delong.com]
Sent: Thursday, May 12, 2011 4:07 AM
To: m...@kenweb.org
Cc: nanog@nanog.org
Subject: Re: IPv6 foot-dragging
On May 11, 2011, at 8:14 PM, ML wrote:
> On 5/11/2011 11:03 AM,
On May 11, 2011, at 8:14 PM, ML wrote:
> On 5/11/2011 11:03 AM, ja...@jamesstewartsmith.com wrote:
>> I have had similar problems with our providers, and these are tier 1
>> companies that should have already been full deployed. These are also some
>> of the more expensive providers on a per M
On Thu, May 12, 2011 at 05:14, ML wrote:
> On 5/11/2011 11:03 AM, ja...@jamesstewartsmith.com wrote:
>>
>> I have had similar problems with our providers, and these are tier 1
>> companies that should have already been full deployed. These are also some
>> of the more expensive providers on a per
On 5/11/2011 11:03 AM, ja...@jamesstewartsmith.com wrote:
I have had similar problems with our providers, and these are tier 1 companies
that should have already been full deployed. These are also some of the more
expensive providers on a per Mb basis. The one provider that was full IPv6
rea
On 11 mei 2011, at 20:39, George Bonser wrote:
>> So what's the alternative? Never change anything?
> Of course not. But the best course forward is going to be different for
> different folks. What might work best for me might not (probably WILL
> not) work best for everyone else. One has to l
I agree that seconds sometimes matters, but the latency of a transaction
doesn't have a linear relationship with radio or battery usage on a
mobile device. Because of the timers involved in the state transitions
(eg CELL_FACH -> CELL_DCH), a few seconds of extra latency often is
inconsequent
On Wed, May 11, 2011 at 11:39 AM, George Bonser wrote:
> There are other things to take into account. If you
> increase the time it takes a mobile device to complete a transaction by
> only a couple of seconds, if you multiply those couple of seconds by
> all of the users in a large metro area,
> So what's the alternative? Never change anything?
Of course not. But the best course forward is going to be different for
different folks. What might work best for me might not (probably WILL
not) work best for everyone else. One has to look at their situation
and plan the best path for their
On 5/11/11 11:39 AM, George Bonser wrote:
> It depends. There are other things to take into account. If you
> increase the time it takes a mobile device to complete a transaction by
> only a couple of seconds, if you multiply those couple of seconds by
> all of the users in a large metro area,
On 05/11/2011 11:21, valdis.kletni...@vt.edu wrote:
Unless you have a captive audience for customers, you probably have a churn
rate higher than 0.1%*anyhow*.
This argument has already been refuted many times. Let's assume that
you're right about the churn rate. The issue is enterprises not wa
On Wed, 11 May 2011 10:32:54 PDT, George Bonser said:
> 0.1% of users is a HUGE number if you have 1,000,000 subscribers. Are
> you prepared to field 1,000 helpdesk calls or lose 1,000 customers? Now
> imagine 100,000,000 subscribers. Are you ready for 10,000 support calls
> or the loss of 10,0
On 11 mei 2011, at 19:32, George Bonser wrote:
>> If the results of world IPv6 day are as we expect and only 0.1 - 0.2 %
>> or less of all people have problems, I think the best way forward would
>> be to have a second world IPv6 day where we again enable IPv6 industry-
>> wide but this time we do
> Now you're counting DNS servers. Because the provisioning of IPv6 DNS
> addresses has been such a mess and still is problematic, many dual
> stack systems do this over IPv4. And the DNS servers they talk to may
> be IPv4-only, or IPv4-only users may talk to dual stack DNS servers.
Which is why I
* Iljitsch van Beijnum
> Firefox has for a long time done both A and lookups even if the
> system doesn't have IPv6.
They fixed that in version 4.0, by calling getaddrinfo() with the
AI_ADDRCONFIG flag (like most other browsers do).
https://bugzilla.mozilla.org/show_bug.cgi?id=614526
--
T
On May 11, 2011, at 1:12 PM, Iljitsch van Beijnum wrote:
> On 11 mei 2011, at 19:01, George Bonser wrote:
>
>> A couple of things you can do to check. First of all look for requests
>> to your DNS servers for records and note where those are coming
>> from.
>
> Firefox has for a long time
On 11 mei 2011, at 19:01, George Bonser wrote:
> A couple of things you can do to check. First of all look for requests
> to your DNS servers for records and note where those are coming
> from.
Firefox has for a long time done both A and lookups even if the system
doesn't have IPv6. I
>
> Apparently the need for IPv6 isn't yet high enough to consider adding
a
> transit provider. I've seen enough press releases from NTT and HE to
> know there's at least two that can do this out there.
>
I believe the major holdup at this point is lack of v6 eyeballs. End
user CPE, particularl
On 2011-05-11 09:10, Mike Tancsa wrote:
> On 5/11/2011 11:03 AM, ja...@jamesstewartsmith.com wrote:
>> I have had similar problems with our providers, and these are tier 1
>> companies that should have already been full deployed. These are also some
>> of the more expensive providers on a per Mb
On 5/11/2011 11:03 AM, ja...@jamesstewartsmith.com wrote:
> I have had similar problems with our providers, and these are tier 1
> companies that should have already been full deployed. These are also some
> of the more expensive providers on a per Mb basis. The one provider that was
> full IP
I have had similar problems with our providers, and these are tier 1 companies
that should have already been full deployed. These are also some of the more
expensive providers on a per Mb basis. The one provider that was full IPv6
ready was Cogent. HE is also IPv6 (although we don't use them
On 05/11/2011 09:50 AM, Iljitsch van Beijnum wrote:
On 11 mei 2011, at 16:39, William Astle wrote:
I think the above two points illustrate precisely why so many networks
in North America simply cannot deploy IPv6 whether they want to or not.
We simply cannot obtain IPv6 transit from our upstrea
On 2011-May-11 16:39, William Astle wrote:
[..]
> I think the above two points illustrate precisely why so many networks
> in North America simply cannot deploy IPv6 whether they want to or not.
> We simply cannot obtain IPv6 transit from our upstreams. It's just not
> available. And the old line a
On 11 mei 2011, at 16:39, William Astle wrote:
> I think the above two points illustrate precisely why so many networks
> in North America simply cannot deploy IPv6 whether they want to or not.
> We simply cannot obtain IPv6 transit from our upstreams. It's just not
> available. And the old line a
50 matches
Mail list logo
