For me the bigger problem is how do I enable IPv6 on my assorted
CE-facing edges when management is still buying edge hardware that
can not and will not ever support IPv6.
Find out if Randy Bush's companies are still buying non-IPv6-capable
gear, and ask if you're a competitor to those
It's a 128 bit address. Routing is done on VLSM, but, generally for DNS
purposes, these
are expected to be at least on nibble boundaries.
There is an intent to support what is known as EUI-64, which means every
subnet should
be a /64, however, there are people who number smaller
Nathan Ward wrote:
Sort of - except it is only for IPv6 clients to connect to named IPv4
servers. NAT-PT allowed for the opposite direction, IPv4 clients
connecting to IPv6 servers - NAT64 does not.
Which is a serious mistake in my opinion. Corporate world will not or
can not shift out of
On Wed, Feb 18, 2009 at 3:51 PM, Bryant Valencia bvl...@gmail.com wrote:
Has anybody hired Cisco for their NOS (Network Optimization Services)? I
would like to hear about your experience (good or bad).
I'm particularly interested in their CNC box.
Either this is merely exquisite acronym
Mikael,
On Feb 17, 2009, at 9:18 PM, Mikael Abrahamsson wrote:
Suggestion: next time you buy equipment from competing vendors,
tell the sales folk from the losing vendors that one deciding
factor was (vendor or product) IPv6 support. That (and perhaps only
that) will get their attention...
We are seeing intermittent connectivity issues via ATT to McAfee's Update
service network (208.69.152.0/21).
Attempts to contact McAfee Support and ATT support have gotten standard
responses. If there is a McAfee Net Admin on list, maybe you can initiate a
ticket with ATT? We've got several
Calhoun, Matthew wrote:
9 212 ms 200 ms * 12.118.225.22 Problem occurring here.
Sometimes traffic gets through, sometimes it doesn't
10 29 ms26 ms26 ms 216.143.71.219
11 26 ms26 ms26 ms www.mcafeeasap.com [208.69.153.135]
Looks a lot like that hop is
We've also seen that busy routers are slower to respond to requests directed
at them as opposed to traffic routing thru them which can continue to work
without issue or performance loss.
-Original Message-
From: Kameron Gasso [mailto:kgasso-li...@visp.net]
Sent: Wednesday, February 18,
From: David Conrad d...@virtualized.org
Date: Wed, 18 Feb 2009 07:57:12 -1000
Mikael,
On Feb 17, 2009, at 9:18 PM, Mikael Abrahamsson wrote:
Suggestion: next time you buy equipment from competing vendors,
tell the sales folk from the losing vendors that one deciding
factor was
While I agree with all of your assessments, this traceroute was being provided
to illustrate where traffic *appears* to be stopping when we are seeing the
issue. It's intermittent, so some times we can reach the destination hosts (via
HTTP, HTTPS, etc.) and sometimes we can't.
When we can
Well, considering how very few vendors actually support IPv6, it's
hard to find proper competition.
You don't have to tell the truth to the losing sales folk... :
Or you could be truthful and say we decided to go with the XYZ product,
despite the fact that they don't support IPv6; if your
Kevin,
On Feb 18, 2009, at 8:19 AM, Kevin Oberman wrote:
You don't have to tell the truth to the losing sales folk... :-)
Yes, I saw the smiley, but
Sigh. Perhaps there needs to be an emoticon for really joking,
really. no, really..
Ethical issues aside, giving incorrect information to
David Conrad wrote:
Yeah. Rants about the IETF should probably be directed elsewhere.
Just how DO we get the message to the IETF that we need all the tools we
have in v4 (DHCP, VRRP, etc) to work with RA turned off?
- Kevin
On 18/02/2009 19:39, Kevin Loch wrote:
Just how DO we get the message to the IETF that we need all the tools we
have in v4 (DHCP, VRRP, etc) to work with RA turned off?
Easy. Disable all ipv4 at ietf meetings and change the address of the DNS
server on the LAN every couple of minutes.
Humor aside, the only practical answer is to show up at meetings and
and on mailing lists and express your technical reasons. There are
people there (in addition to me) who want the perspective of network
operators.
John
On 2009Feb18, at 2:45 PM, Nick Hilliard wrote:
On 18/02/2009
Kevin Loch wrote:
Just how DO we get the message to the IETF that we need all the tools we
have in v4 (DHCP, VRRP, etc) to work with RA turned off?
You don't, because there isn't really a technical reason for turning off
RA. RA is used as a starting point. It can push you to DHCPv6 or any
On 18/02/2009 19:39, Kevin Loch wrote:
Just how DO we get the message to the IETF that we need all the
tools we
have in v4 (DHCP, VRRP, etc) to work with RA turned off?
What operational reasons are there for working with RA turned off?
Aria Stewart
aredri...@nbtsc.org
smime.p7s
On Wed, Feb 18, 2009 at 12:55:19PM -0700, Aria Stewart wrote:
On 18/02/2009 19:39, Kevin Loch wrote:
Just how DO we get the message to the IETF that we need all the
tools we
have in v4 (DHCP, VRRP, etc) to work with RA turned off?
What operational reasons are there for working with RA
Just how DO we get the message to the IETF that we need all the tools we
have in v4 (DHCP, VRRP, etc) to work with RA turned off?
You don't, because there isn't really a technical reason for turning off
RA.
I'm glad to see that several of the big vendors seem to disagree with
you.
-
What operational reasons are there for working with RA turned off?
networks with visitors have shown a serious problem with rouge RAs
randy
On Wed, 18 Feb 2009 12:55:19 MST, Aria Stewart said:
What operational reasons are there for working with RA turned off?
If the intent is to feed the just-booted box all its network config via
DHCPv6, including the network/netmask/default router, the *last* thing you
want is a second box
On Wed, Feb 18, 2009, Jack Bates wrote:
Kevin Loch wrote:
Just how DO we get the message to the IETF that we need all the tools we
have in v4 (DHCP, VRRP, etc) to work with RA turned off?
You don't, because there isn't really a technical reason for turning off
RA. RA is used as a starting
On Feb 18, 2009, at 1:15 PM, Randy Bush wrote:
What operational reasons are there for working with RA turned off?
networks with visitors have shown a serious problem with rouge RAs
Does that get better with RAs from the good routers turned off?
Aria Stewart
aredri...@nbtsc.org
On Feb 18, 2009, at 11:53 AM, Jack Bates wrote:
Kevin Loch wrote:
Just how DO we get the message to the IETF that we need all the
tools we
have in v4 (DHCP, VRRP, etc) to work with RA turned off?
You don't, because there isn't really a technical reason for turning
off RA. RA is used as
On 19/02/2009, at 9:08 AM, Chuck Anderson wrote:
On Wed, Feb 18, 2009 at 12:55:19PM -0700, Aria Stewart wrote:
On 18/02/2009 19:39, Kevin Loch wrote:
Just how DO we get the message to the IETF that we need all the
tools we
have in v4 (DHCP, VRRP, etc) to work with RA turned off?
What
On 19/02/2009, at 9:17 AM, valdis.kletni...@vt.edu wrote:
2) Some end-node box with a IPv6 stack from Joe's Software Emporium
and
Bait-n-Tackle sees an RA packet, and concludes that since RA and
DHCPv6
are mutually exclusive, to ignore any DHCPv6 packets it sees, and
hilarity
ensues.
Hi!
networks with visitors have shown a serious problem with rouge RAs
Does that get better with RAs from the good routers turned off?
Aria Stewart
aredri...@nbtsc.org
Is there something like RA filtering on switches yet, so end users can be
filtered? Just like the dhcp stuff thats
In a message written on Wed, Feb 18, 2009 at 12:55:19PM -0700, Aria Stewart
wrote:
What operational reasons are there for working with RA turned off?
Not picking on the original poster, as I have no idea if they would
have any personal experience with this or not.
There was a kinder,
On 19/02/2009, at 9:15 AM, Randy Bush wrote:
What operational reasons are there for working with RA turned off?
networks with visitors have shown a serious problem with rouge RAs
Networks with visitors have shown a serious problem with rogue DHCP
servers.
Networks with visitors that use
Mikael Abrahamsson wrote:
On Tue, 17 Feb 2009, Justin Shore wrote:
different vendors, I asked each of them about their IPv6 support and
they all unanimously claimed that there was no demand for it from
their customers.
Well, this is just ignorance or a kind of a lie. There might be few
2) Some end-node box with a IPv6 stack from Joe's Software Emporium
and
Bait-n-Tackle sees an RA packet, and concludes that since RA and
DHCPv6
are mutually exclusive, to ignore any DHCPv6 packets it sees, and
hilarity
ensues.
They are not mutually exclusive, DHCPv6
On 19/02/2009, at 9:34 AM, Leo Bicknell wrote:
Allowing an UNAUTHENTICATED BROADCAST packet to determine where you
send
your traffic is insane. Rather than moving forward, this is a
giantantic step backwards for security and reliability.
I guess you don't use DHCP in IPv4 then.
It seems
On Thu, 19 Feb 2009, Nathan Ward wrote:
It seems there are lots of people who want auto configuration in IPv6
but who clearly do not do this in IPv4. That seems strange, to me.
Everybody uses DHCP in IPv4, it's just that there is functionality in
the equipment we use to make sure it can only
In a message written on Thu, Feb 19, 2009 at 09:44:38AM +1300, Nathan Ward
wrote:
I guess you don't use DHCP in IPv4 then.
No, you seem to think the failure mode is the same, and it is not.
Let's walk through this:
1) 400 people get on the NANOG wireless network.
2) Mr 31337 comes along and
On 19/02/2009, at 9:42 AM, sth...@nethelp.no wrote:
2) Some end-node box with a IPv6 stack from Joe's Software Emporium
and
Bait-n-Tackle sees an RA packet, and concludes that since RA and
DHCPv6
are mutually exclusive, to ignore any DHCPv6 packets it sees, and
hilarity
ensues.
They are not
networks with visitors have shown a serious problem with rogue RAs
Does that get better with RAs from the good routers turned off?
no, need to turn off listeners in this case
the problems in the discovery space are sufficient to be causing a
bit of effort to go into painting security on ex
On 19/02/2009, at 9:53 AM, Leo Bicknell wrote:
In a message written on Thu, Feb 19, 2009 at 09:44:38AM +1300,
Nathan Ward wrote:
I guess you don't use DHCP in IPv4 then.
No, you seem to think the failure mode is the same, and it is not.
Let's walk through this:
1) 400 people get on the
On Feb 18, 2009, at 3:00 PM, Nathan Ward wrote:
On 19/02/2009, at 9:53 AM, Leo Bicknell wrote:
Let me repeat, none of these solutions are secure. The IPv4/DHCP
model
is ROBUST, the RA/DHCPv6 model is NOT.
The point I am making is that the solution is still the same -
filtering in
In a message written on Thu, Feb 19, 2009 at 10:00:48AM +1300, Nathan Ward
wrote:
The point I am making is that the solution is still the same -
filtering in ethernet devices.
No.
I agree that in some enviornments DHCPv4/DHCPv6/RA filtering are
going to be a requirement. If I was running
Raymond Dijkxhoorn wrote:
Hi!
Hi,
networks with visitors have shown a serious problem with rouge RAs
Does that get better with RAs from the good routers turned off?
Aria Stewart
aredri...@nbtsc.org
Is there something like RA filtering on switches yet, so end users can
be filtered?
Leo Bicknell wrote:
It wouldn't be so bad if we could just turn it off. Indeed, in
part you can. On a static LAN there is no need for RA's. Static
IP the box, static default route, done and done.
VRRPv6 however is relevant to static environments and also needs to
(optionally) work with
Dale W. Carder wrote:
On Feb 18, 2009, at 3:00 PM, Nathan Ward wrote:
On 19/02/2009, at 9:53 AM, Leo Bicknell wrote:
Let me repeat, none of these solutions are secure. The IPv4/DHCP model
is ROBUST, the RA/DHCPv6 model is NOT.
The point I am making is that the solution is still the same
David Conrad wrote:
Tony,
On Feb 17, 2009, at 12:17 PM, Tony Hain wrote:
This being a list of network engineers, there is a strong bias
toward tools
that allow explicit management of the network. This is a fine
position, and
those tools need to exist. There are others that don't
In a message written on Wed, Feb 18, 2009 at 04:11:40PM -0500, Kevin Loch wrote:
Leo Bicknell wrote:
It wouldn't be so bad if we could just turn it off. Indeed, in
part you can. On a static LAN there is no need for RA's. Static
IP the box, static default route, done and done.
VRRPv6
Justin Shore wrote:
...
At this point I'm looking at doing 6to4 tunnels far into the future.
You can forget that, as CGN will break 6to4. Get used to teredo (miredo),
and if that is impeded don't be surprised when IPv6 over SOAP shows up.
Tony
Raymond Dijkxhoorn wrote:
Is there something like RA filtering on switches yet, so end users can
be filtered? Just like the dhcp stuff thats available on most switches
nowdays... ?
Its as annoying as fake DHCP servers...
Per customer VLAN isolation (common to solve DHCP server issues). You
Owen DeLong wrote:
...
If you want SLAAC or RA or whatever, more power to you. Some
installations
do not. They want DHCP equivalent functionality with the same
security model.
It is always amusing when people equate DHCP with security... Outside of
that, I do agree with you that the
Leo Bicknell wrote:
...
But, when DHCPv6 was developed the great minds of the world decided
less functionality was better. There /IS NO OPTION/ to send a default
route in DHCPv6, making DHCPv6 fully dependant on RA's being turned on!
So the IETF and other great minds have totally removed the
On Wed, Feb 18, 2009, Tony Hain wrote:
No, the decision was to not blindly import all the excess crap from IPv4. If
anyone has a reason to have a DHCPv6 option, all they need to do is specify
it. The fact that the *nog community stopped participating in the IETF has
resulted in the situation
Adrian Chadd wrote:
On Wed, Feb 18, 2009, Tony Hain wrote:
No, the decision was to not blindly import all the excess crap from IPv4. If
anyone has a reason to have a DHCPv6 option, all they need to do is specify
it. The fact that the *nog community stopped participating in the IETF has
On 19/02/2009, at 9:22 AM, Owen DeLong wrote:
There are also a number of security issues available in the Just
trust some
unsolicited broadcast about where to send all your network traffic.
approach
to host bootstrapping that bother some people.
So, those people don't use DHCP in IPv4 if
--- mcalh...@iodatacenters.com wrote:
From: Calhoun, Matthew mcalh...@iodatacenters.com
While I agree with all of your assessments, this traceroute was being provided
to illustrate where traffic *appears* to be stopping when we are seeing the
issue. It's intermittent, so some times we can
On 19/02/2009, at 10:07 AM, Leo Bicknell wrote:
In a message written on Thu, Feb 19, 2009 at 10:00:48AM +1300,
Nathan Ward wrote:
The point I am making is that the solution is still the same -
filtering in ethernet devices.
No.
I agree that in some enviornments DHCPv4/DHCPv6/RA filtering
In a message written on Wed, Feb 18, 2009 at 01:39:57PM -0800, Tony Hain wrote:
No, the decision was to not blindly import all the excess crap from IPv4. If
anyone has a reason to have a DHCPv6 option, all they need to do is specify
it. The fact that the *nog community stopped participating in
http://www.physorg.com/news154093231.html
Roderick S. Beck
Director of European Sales
Hibernia Atlantic
13-15, rue Sedaine, 75011 Paris
http://www.hiberniaatlantic.com
Tony Hain wrote:
Leo Bicknell wrote:
...
But, when DHCPv6 was developed the great minds of the world decided
less functionality was better. There /IS NO OPTION/ to send a default
route in DHCPv6, making DHCPv6 fully dependant on RA's being turned on!
So the IETF and other great minds have
On Thu, Feb 19, 2009, Nathan Ward wrote:
So, those people don't use DHCP in IPv4 if this is a concern, so I'm
guessing they are not hoping to use DHCPv6 either.
Static configuration of IP addressing information and other
configuration will work just fine for them.
I wonder, do they use
Daniel Senie wrote:
...
No, the decision was to not blindly import all the excess crap from
IPv4. If
anyone has a reason to have a DHCPv6 option, all they need to do is
specify
it. The fact that the *nog community stopped participating in the
IETF has
resulted in the situation where
Leo Bicknell wrote:
...
The last time I participated a working group chair told me operators
don't know what they are talking about and went on to say they should
be ignored.
So did you believe him and stop participating? Seriously, the -ONLY- way
the IETF can be effective is for the ops
On Wed, 18 Feb 2009 22:12:02 GMT, Rod Beck said:
http://www.physorg.com/news154093231.html
From the fine article:
In greedy routing, a node passes information to the neighboring node that is
closest to the final destination in an abstract space called hidden metric
space.
Sounds suspiciously
In a message written on Wed, Feb 18, 2009 at 02:32:24PM -0800, Tony Hain wrote:
So did you believe him and stop participating? Seriously, the -ONLY- way
the IETF can be effective is for the ops community to provide active
feedback. If you don't provide input, don't be surprised when the output
David Conrad wrote:
If a vendor sales person indicates they are getting no requests for
IPv6 support in their products (which would clearly be false since
presumably you are requesting IPv6 support),
It's hard to imagine a vendor that is getting _no_ requests for IPv6
support these days;
On Thu, Feb 19, 2009, Nathan Ward wrote:
Yep. You asked your vendors to support equivalent IPv6 things at the
time though, so when you roll out IPv6 the support is ready, right?
The point is that these deficiencies exist in IPv4, and I'm not sure
how you would solve them in IPv6
Leo Bicknell wrote:
I can't think of a single working
group chair/co-chair that's ever presented at NANOG and asked for
feedback.
Then were busy staring at your laptop and not watching the program.
If the IETF wants this to be a two way street actions would
speak louder than words.
In that
On Wed, 18 Feb 2009 17:40:02 -0500
Leo Bicknell bickn...@ufp.org wrote:
And let me ask you this question, why do the operators have to go to
the IETF? Many of us have, and tried. I can't think of a single
working group chair/co-chair that's ever presented at NANOG and asked
for feedback.
Maybe there's some critical insight in the paper that Physorg managed
to totally not mention, I dunno.
I saw it the same way...
As the researchers explain, some types of networks are not navigable. For
instance, if the probability that two nodes are linked doesn't depend on the
metric
On Wed, 2009-02-18 at 16:45 -0600, Stephen Sprunk wrote:
I bet the latter is why the US DoD gave up on their hard IPv6
requirements and now simply mandates that products be software
upgradeable to support IPv6...
I think you will agree that vendor support for IPv6 has come a long way
in the
On Feb 18, 2009, at 5:57 PM, Joel Jaeggli wrote:
Leo Bicknell wrote:
I can't think of a single working
group chair/co-chair that's ever presented at NANOG and asked for
feedback.
Then were busy staring at your laptop and not watching the program.
If the IETF wants this to be a two way
On 19/02/2009, at 9:20 AM, Adrian Chadd wrote:
Who says the IPv6 solutions need to be better than IPv4?
Actually, with IPv6 I'd like _a_ solution that at least is viable and
works - it's doesn't have to be the final one, it doesn't have to even
be as good as IPv4, it just has to be
I had to laugh when reading... This is how I think someone who doesn't get
how the Internet works may try to re-explain what a researcher explained to
them about how metrics influence the flow of traffic in BGP path selection.
Regards,
Jake Mertel
Nobis Technology Group, L.L.C.
Web:
Adrian Chadd wrote:
Who says the IPv6 solutions need to be better than IPv4?
I think that IPv6 solutions will automatically be better than IPv4 based
on the switch to multicast for handling things. That being said, I
haven't seen the normal IPv4 solutions migrated to IPv6 as of yet in the
On Feb 18, 2009, at 1:53 PM, Leo Bicknell wrote:
Try that with an IPv6 router. About 10 ms after you plug into the
wrong
port out goes an RA, the entire subnet ceases to function, and your
phone lights up like a christmas tree.
Let me repeat, none of these solutions are secure. The
If the IPv6 solutions are not going to be #39;better#39; than v4, how about
simply making sure that they are #39;as good as#39; ipv4?
Right now, I#39;d be hard pressed to think of a v6 function which is
#39;better#39; and I can think of a lot which are #39;not as good as.#39;
-David Barak
Mikael Abrahamsson wrote:
Well, considering how very few vendors actually support IPv6, it's hard
to find proper competition. Even the companies who do support IPv6 very
well in some products, not all their BUs do on their own products (you
know who you are :P ).
Even worse is when the BU
Why so many prepends from these folks?
Feb 18 20:02:35.649 CST: %BGP-6-ASPATH: Long AS path 1785 1273 9035 1267
41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827
41827 41827 41827 41827 41827 41827 41827 41827 41827 received from
209.253.101.9: More than configured
The fact that the *nog community stopped participating in the IETF has
resulted in the situation where functionality is missing, because nobody
stood up and did the work to make it happen.
the ops gave up on the ietf because it did no good to participate. so
the choice was spend the time
I can't think of a single working group chair/co-chair that's ever
presented at NANOG and asked for feedback.
i did a number of times. so have others.
otoh, all that gets pretty destroyed by a few self-inflated ietf
wannabes presenting org charts of the ietf and explaining what the
grown-ups
Opsec wg alsoabout 2 years ago Ross Callon went to most NOGs to
solicit input and I suppose now with Joel it'll be ongoing :)
- merike
On Feb 18, 2009, at 3:00 PM, Steven M. Bellovin wrote:
On Wed, 18 Feb 2009 17:40:02 -0500
Leo Bicknell bickn...@ufp.org wrote:
And let me ask you this
On Wed, 18 Feb 2009 22:12:02 GMT, Rod Beck said:
http://www.physorg.com/news154093231.html
From the fine article:
In greedy routing, a node passes information to the neighboring
node that is
closest to the final destination in an abstract space called hidden
metric
space.
Sounds
On 19/02/2009, at 12:27 PM, Nathan Ward wrote:
From other discussion with you, your main concern is vendor support
for a few things, right?
The issue is that the vendors aren't actually sure what to implement
because there's a distinct lack of standards as opposed to competing
drafts,
At 08:06 PM 18-02-09 -0600, neal rauhauser wrote:
Why so many prepends from these folks?
Cuz you set maxas=20? Just plain noise.
-Hank
Feb 18 20:02:35.649 CST: %BGP-6-ASPATH: Long AS path 1785 1273 9035 1267
41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827
41827
Hey guys any of you guys seeing some issues getting to msn on the west
coast here? I seem to be having issues via level3 abovenet and Comcast.
-carlos
82 matches
Mail list logo
