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
On Fri, May 13, 2011 at 2:32 PM, Jeroen van Aart jer...@mompl.net 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
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
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 given
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
Joe Loiacono wrote:
Jeroen Massar jer...@unfix.org 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
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
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
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.
Something
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
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 rules in order
On Thu, May 12, 2011 at 05:14, ML m...@kenweb.org 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 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 Mb
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, ja
On 12 mei 2011, at 12:06, Owen DeLong wrote:
IPv6 peering
is somewhat different from IPv4.
How is it different?
Anthony Francis - Handy Networks LLC anth...@handynetworks.com 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
Bernhard Schmidt be...@birkenwald.de wrote on 05/12/2011 06:27:38 AM:
Anthony Francis - Handy Networks LLC anth...@handynetworks.com 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
On 2011-May-12 15:14, Joe Loiacono wrote:
Bernhard Schmidt be...@birkenwald.de wrote on 05/12/2011 06:27:38 AM:
Anthony Francis - Handy Networks LLC anth...@handynetworks.com wrote:
I can confirm full IPV6 connectivity from HE.
How can you confirm that when HE just admitted to be lacking
Hi,
Bernhard Schmidt be...@birkenwald.de wrote on 05/12/2011 06:27:38 AM:
Anthony Francis - Handy Networks LLC anth...@handynetworks.com 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
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
Jeroen Massar jer...@unfix.org 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
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 space.
Who sees the most AS's?
George,
On Thu, May 12, 2011 at 11:41 AM, George Bonser gbon...@seven.com 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
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
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 hit
On Thu, May 12, 2011 at 5:49 PM, George Bonser gbon...@seven.com 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
On Thu, May 12, 2011 at 8:39 PM, Jimmy Hess mysi...@gmail.com 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
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 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
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
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
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 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
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
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, particularly
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
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 done
* 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
--
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
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 don't
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,000
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
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, you
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 Wed, May 11, 2011 at 11:39 AM, George Bonser gbon...@seven.com 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
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
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 look
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
49 matches
Mail list logo
