On Tue, 2004-04-20 at 00:21, Alexei Roudnev wrote:
> Hmnm, if you:
> -- are in Russia or other East Europe country
> - got Windows with a computer (so it is 90% pirated one)
> - have not credit card
geez, they are giving the CD away for free !
james
signature.asc
Description: This is a digital
On Mon, 19 Apr 2004, Alexei Roudnev wrote:
> Hmnm, if you:
> -- are in Russia or other East Europe country
> - got Windows with a computer (so it is 90% pirated one)
> - have not credit card
> how can you order this CD (of course, pirates will help -:))?
The US/English Windows Security Update CD
The question is too simplistic ... It is not (simply) a matter of small
vs. big or being on your own network from source-to-destination. Peering
is an enabler ... and gives all an opportunity to share content globally
... kinda' fundamental to the Internet consortium.
Is your question, 'Since fi
Title: RE: remote reboot power strips
We use Baytechs with much success. Not only does it allow remote reboots via the modem, it supports connectivity to the console ports via serial cables; ideal for troubleshooting or Xmodem-ing new code if necessary.
http://www.baytechdcd.com/
R
> >Think globally. Even though this forum has NA as its heading, we need to
> >think globally when suggesting solutions. You'll never get any sort of
> >licensing globally nor will you EVER get end users (globally) educated
> >enough to stop doing the things that they do which allow these events
On 4/20/04 1:34 AM, "Michel Py" <[EMAIL PROTECTED]> wrote:
>
>> Patrick W.Gilmore wrote:
>> Unless they have cheap access to a free NAP (TorIX, SIX, etc.),
>> transit, even at higher prices, is probably be the best /
>> cheapest way to reach the Internet.
>
> This is true, but there are plenty
On 4/20/04 8:45 AM, "Gary Hale" <[EMAIL PROTECTED]> wrote:
>
> The question is too simplistic ... It is not (simply) a matter of small
> vs. big or being on your own network from source-to-destination. Peering
> is an enabler ... and gives all an opportunity to share content globally
> ... kinda
On Tue, Apr 20, 2004 at 05:15:48AM +, Paul Vixie wrote:
>
> > > Peering? Who needs peering if transit can be
> > > had for $20 per megabit per second?
>
> anyone whose applications are too important to risk dependency on OPNs
> (other people's networks).
OPNs also carry some of the consum
On Tue, 20 Apr 2004 09:21:02 -0500 (CDT), Adi Linden wrote:
>> Since many gateway service providers will not prevent insufficiently
>> skilled users from connecting to the internet and injuring others, the
>> only remaining solution, as far as I can see, is cutting connectivity
>> with those enab
On Apr 20, 2004, at 10:32 AM, Daniel Golding wrote:
On 4/20/04 1:34 AM, "Michel Py" <[EMAIL PROTECTED]>
wrote:
Patrick W.Gilmore wrote:
Unless they have cheap access to a free NAP (TorIX, SIX, etc.),
transit, even at higher prices, is probably be the best /
cheapest way to reach the Internet.
Th
> As for the specifics of your comments, I could not disagree more, but it
> is a philosophy of life that distinguishes our views, not the analysis of
> the problem. I believe (like a lot of other New Englanders and even
> some from California) that people must assume responsibility for their
>
[snip]
:
: My argument is that a computer needs to be in a safe state by default. I
: firmly believe that if I buy a brand new box from any reputable vendor
: with a premium operating system of choice I should be able to connect this
: device to a local broadband connection indefinitely. It needs
Operating systems bundled with a retail computer _should_ be reasonably
secure out of the box.
OS X can be placed on a unprotected internet connection in a unpatched
state and it's default configuration allows it to be patched to current
levels without it being compromised.
On the other hand Wi
We're having a lot of deferrals with connection timeouts for mail destined
to hotmail.com, some of the IP's in question are accessable breifly from
other locations before they start timing out as well.
This is resulting in a lot of hotmail.com bound email backfilling in
our queues.
Is this some
http://www.uniras.gov.uk/vuls/2004/236929/index.htm
Mike Tancsa, tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994
Since no one's mentioned it yet, apparently there was a change in plans.
It was just released a day early.
http://story.news.yahoo.com/news?tmpl=story&cid=528&e=1&u=/ap/20040420/ap_on_hi_te/internet_threat
And the official one:
http://www.uniras.gov.uk/vuls/2004/236929
NISCC Vulnerability Advisory 236929Vulnerability Issues in TCPVersion Information Advisory Reference 236929 Release Date 20 April 2004 Last Revision 20 April 2004 Version Number 1.0 What is Affected?The vulnerability described in this advisory affects implementations of the Transmission Control Pr
ttp://story.news.yahoo.com/news?tmpl=story&cid=528&e=1&u=/ap/20040420/ap_on_
> hi_te/internet_threat
>
> And the official one:
>
> http://www.uniras.gov.uk/vuls/2004/236929/index.htm
>
> Grant
>
> --
> Grant A. Kirkwood - grant(at)tnarg.org
> Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED
On Tue, 20 Apr 2004, tad pedley wrote:
> Although denial of service using crafted TCP packets is a well known
> weakness of TCP, until recently it was believed that a successful
> denial of service attack was not achievable in practice. The reason
> for this is that the receiving TCP implementatio
On 20 Apr 2004, at 13:59, Aviva Garrett wrote:
In message <[EMAIL PROTECTED]>you
write:
Since no one's mentioned it yet, apparently there was a change in
plans.
It was just released a day early.
This is because of the story at http://www.washingtonpost.com/, in the
Technology section.
I sugges
On Tue, 20 Apr 2004, Patrick W.Gilmore wrote:
> In many, many cases, especially for smaller providers, this is a spare FE on a
> switch which already exists.
I assume Vijay meant the cost of a port for private peering, in which case if
you private with all your peers and you have a lot of smal
on Sun, Apr 18, 2004 at 04:33:18PM +, Paul Vixie wrote:
>
> > Maybe a stupid question... But if broadband providers aren't going to do
> > this, and considering there are way less legitimate SMTP senders than
> > broadband users, wouldn't it make more sense to whitelist known real SMTP
> > so
Daniel,
That is way too cynical ... and does not address the question of whether
building your own transport ever runs counter to the Internet as a
consortium.
There are business justifications that underpin peering relationships
... and they are based on understanding (or ... "philosophy") ...
now let me take a bite at this :P
i can see this 'attack' operational against a multihop bgp session that's
not md5'd.
now the question is... would this also affect single-hop bgp sessions?
my understanding would be no, as single-hops require ttl set to 1.
-J
On Tue, Apr 20, 2004 at 01:36:09P
How do you tell an adjacent TTL set to 1 from a TTL set to 5 four hops away?
Owen
--On Tuesday, April 20, 2004 14:54 -0400 James <[EMAIL PROTECTED]> wrote:
now let me take a bite at this :P
i can see this 'attack' operational against a multihop bgp session that's
not md5'd.
now the question is.
Hi,
For those not helped too much the MD5 Signature Option, this
i-d addresses the attacks in the Watson paper (it was meant to
come out just when the advisory came out, but they jumped the gun).
There are implementations in *xes and router OSes - more info
from those sources.
Allison
--
On Tue, 20 Apr 2004, Mike Tancsa wrote:
> http://www.uniras.gov.uk/vuls/2004/236929/index.htm
A huge round of applause for everyone not doing RPF and egress filtering
where it is trivial to do so. You make everyones job that little bit
harder.
You know who you are.
-Dan
On Apr 20, 2004, at 2:15 PM, Stephen J. Wilcox wrote:
On Tue, 20 Apr 2004, Patrick W.Gilmore wrote:
In many, many cases, especially for smaller providers, this is a
spare FE on a
switch which already exists.
I assume Vijay meant the cost of a port for private peering, in which
case if
you priva
On Tue, 20 Apr 2004, James wrote:
> i can see this 'attack' operational against a multihop bgp session that's
> not md5'd.
>
> now the question is... would this also affect single-hop bgp sessions?
> my understanding would be no, as single-hops require ttl set to 1.
you can engineer packets to
ah yes.. forgot about that :)
Thanks,
-J
On Tue, Apr 20, 2004 at 08:24:02PM +0100, Stephen J. Wilcox wrote:
> On Tue, 20 Apr 2004, James wrote:
>
> > i can see this 'attack' operational against a multihop bgp session that's
> > not md5'd.
> >
> > now the question is... would this also affect s
> The other is our new hot topic of security, not sure if
> anyone has thought of this yet (or how interesting it is) but
> the nature of the bgp attack means that if you can view a BGP
> session you can figure things about a peer that would
> otherwise be hidden from you in particular the po
On Apr 20, 2004, at 3:24 PM, Stephen J. Wilcox wrote:
On Tue, 20 Apr 2004, James wrote:
i can see this 'attack' operational against a multihop bgp session
that's
not md5'd.
now the question is... would this also affect single-hop bgp sessions?
my understanding would be no, as single-hops requir
On Apr 20, 2004, at 1:36 PM, Mike Tancsa wrote:
http://www.uniras.gov.uk/vuls/2004/236929/index.htm
What is a typical receive window on a router? I have been told (have
not confirmed) it was about 14 bits.
Assuming a well randomized starting sequence number (just give me this
one for the momen
On 04/20/04, Mark Jeftovic <[EMAIL PROTECTED]> wrote:
> We're having a lot of deferrals with connection timeouts for mail destined
> to hotmail.com, some of the IP's in question are accessable breifly from
> other locations before they start timing out as well.
Known issue. It should b
Cynical? Gee, I hope so. Anyone who reads that sort of fluff needs to be
cynical. Lack of appropriate cynicism led, in part, to the "recent
unpleasantness" in the telecommunications industry.
Words like "enabling", "leveraging", "mindshare", "b2b", "e-*", "i-*", et
al, are considered harmful to
John Fraizer author of MRLG one of the looking glass implementations
has updated his code to fix a flaw that provided too much information.
MRLG-4.3.0 is available at:
Available here:
ftp://ftp.enterzone.net/looking-glass/CURRENT/
Some route servers also provide too much info.
This audit was pe
Perhaps we are all making too much of this...
It appears that Winstar feels that there is no need for MD5
authentication of peering sessions. One of our customers has just had
the following response from Winstar following a request to implement MD5
on their OC3 connection to Winstar. My first sug
Patrick W.Gilmore wrote:
On Apr 20, 2004, at 3:24 PM, Stephen J. Wilcox wrote:
On Tue, 20 Apr 2004, James wrote:
i can see this 'attack' operational against a multihop bgp session
that's
not md5'd.
now the question is... would this also affect single-hop bgp sessions?
my understanding would be
On Tue, 20 Apr 2004 15:40:38 EDT, "Patrick W.Gilmore" said:
> Assuming a well randomized starting sequence number (just give me this
> one for the moment),
Nope. I won't give you that one, because that's a big chunk of the
problem:
http://lcamtuf.coredump.cx/newtcp/ (one year later)
http://raz
I disagree ... but sure do appreciate your tone ... :)
Regards,
Gary
-Original Message-
From: Daniel Golding [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 4:32 PM
To: Gary Hale; Michel Py; Gordon Cook; [EMAIL PROTECTED]
Subject: Re: Backbone IP network Economics - peering and
Well,
CERT thought it was
Jim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Technical Cyber Security Alert TA04-111A archive
Vulnerabilities in TCP
Original release date: April 20, 2004
Last revised: --
Source: US-CERT
Systems Affected
* Systems that rely on persistent TCP
On Tue, Apr 20, 2004 at 10:36:48AM -0700, Grant A. Kirkwood wrote:
>
> Since no one's mentioned it yet, apparently there was a change in plans.
> It was just released a day early.
>
> http://story.news.yahoo.com/news?tmpl=story&cid=528&e=1&u=/ap/20040420/ap_on_hi
On Tue, 20 Apr 2004, Crist Clark wrote:
> But it has limited effectiveness for multi-hop sessions. There is the
> appeal of a solution that does not depend of the physical layout of the
> BGP peers.
Does MD5 open the door to cpu DOS attacks on routers though? Eg can
someone craft a DOS attack to
On 20-apr-04, at 21:40, Patrick W.Gilmore wrote:
What is a typical receive window on a router? I have been told (have
not confirmed) it was about 14 bits.
Cisco routers have a command that will show you this number. It's
generally just under 16k. Unfortunately, some looking glasses allow
anyon
Seems Xspedius aka E.SPire aka ACSI doesn't feel that MD5 is
important on their BGP sessions either.
Based on the ticket we filed last week, Managment does not
feel its warranted to make these changes.
On the other hand, SPRINT was willing and able to take MD5
session info right away. WAY T
On Tue, Apr 20, 2004 at 02:11:02PM -0700, Dan Hollis wrote:
>
> On Tue, 20 Apr 2004, Crist Clark wrote:
> > But it has limited effectiveness for multi-hop sessions. There is the
> > appeal of a solution that does not depend of the physical layout of the
> > BGP peers.
>
> Does MD5 open the door
> I suggest an extensive late-night BOF in San Francisco in the bar to
> discuss the mechanics of adding MD5 keys to all your sessions in 48
> hours. Evidence of RSI and eyesight failure will be mandatory
for those who prefer to be keyboard monkeys all their lives instead
of building tools to c
vijay gill wrote:
>
>
> Yes it does. About 5 mbit of md5 should peg a juniper at 100% according
> to my friend alex. I have not verified this in the lab. I suggest
> you try it out.
>
> Also, this is why the GTSM (ttl hack) was written up ;)
So then you're suggesting that the GTSM is the c
On Tue, Apr 20, 2004 at 02:42:07PM -0700, Rodney Joffe wrote:
>
>
> vijay gill wrote:
> >
> >
> > Yes it does. About 5 mbit of md5 should peg a juniper at 100% according
> > to my friend alex. I have not verified this in the lab. I suggest
> > you try it out.
> >
> > Also, this is why the G
On Tue, 20 Apr 2004, Richard A Steenbergen wrote:
> Anyone who seriously wanted to protect against this attack could easily
> deploy RST rate limits against their management interfaces, rather than
> run around trying to set up MD5 with every peer. As a long term
> improvement, a random ephemeral
On Tue, 20 Apr 2004, John Brown (CV) wrote:
>
> Seems Xspedius aka E.SPire aka ACSI doesn't feel that MD5 is
> important on their BGP sessions either.
>
> Based on the ticket we filed last week, Managment does not
> feel its warranted to make these changes.
I dunno...to me, this falls on the
On Tue, Apr 20, 2004 at 09:45:01PM +, vijay gill wrote:
> infrastructure today - a large amount of PPS at the _router_ (with or
> without md5 or tcpsecure) will blow it out of the water. A 10mbits/s
> of packets at the juniper without md5 will also destroy it.
To be clear, I was just using j
repeatedly to produce a Denial of Service (DoS).
This advisory is available at:
http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml
Affected Products
=
This vulnerability was introduced by a code change for CSCeb22276. This
change was committed to the following
On Tue, Apr 20, 2004 at 03:30:30PM -0600, John Brown (CV) wrote:
>
> Seems Xspedius aka E.SPire aka ACSI doesn't feel that MD5 is
> important on their BGP sessions either.
>
> Based on the ticket we filed last week, Managment does not
> feel its warranted to make these changes.
>
> On the ot
On 20 Apr 2004, at 17:37, Randy Bush wrote:
I suggest an extensive late-night BOF in San Francisco in the bar to
discuss the mechanics of adding MD5 keys to all your sessions in 48
hours. Evidence of RSI and eyesight failure will be mandatory
for those who prefer to be keyboard monkeys all their
Dan Hollis wrote:
On Tue, 20 Apr 2004, Crist Clark wrote:
But it has limited effectiveness for multi-hop sessions. There is the
appeal of a solution that does not depend of the physical layout of the
BGP peers.
Does MD5 open the door to cpu DOS attacks on routers though? Eg can
someone craft a
On Tue, 20 Apr 2004, Sean Donelan wrote:
> I do not know if Microsoft plans to refresh the CD, or make it available
> through other channels.
Bittorrent? :-)
Does anyone have a BT iso of these CDs btw? I cant imagine microsoft
objecting to its distribution...
-Dan
> > I suggest an extensive late-night BOF in San Francisco in the bar to
> > discuss the mechanics of adding MD5 keys to all your sessions in 48
> > hours. Evidence of RSI and eyesight failure will be mandatory
>
> for those who prefer to be keyboard monkeys all their lives instead
> of buildin
> A huge round of applause for everyone not doing RPF and egress filtering
> where it is trivial to do so. You make everyones job that little bit
> harder.
>
> You know who you are.
well, no, actually, they mostly don't (know).
--
Paul Vixie
On 20-apr-04, at 23:45, vijay gill wrote:
the correct workaround is the
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt
draft. MD5 is also the correct workaround. However, neither of the
two protect against what is the most vulnerable thing in the internet
infrastructure today
On Tue, 20 Apr 2004, Joe Abley wrote:
> I suggest an extensive late-night BOF in San Francisco in the bar to
> discuss the mechanics of adding MD5 keys to all your sessions in 48
> hours.
Zeitgeist at 7pm or the Toronado at 9pm?
On Apr 20, 2004, at 4:49 PM, [EMAIL PROTECTED] wrote:
On Tue, 20 Apr 2004 15:40:38 EDT, "Patrick W.Gilmore" said:
Assuming a well randomized starting sequence number (just give me this
one for the moment),
Nope. I won't give you that one, because that's a big chunk of the
problem:
http://lcamt
Hello There,
maybe Offtopic, but i thought this could be interesting for some of you.
Nmap 3.51-TEST3 is released with some nice new features for local networks.
Nmap now uses the system interface table (as shown by ifconfig) to
determine whether a system is on the same network. A database deri
At 05:09 PM 20/04/2004, Richard A Steenbergen wrote:
party to know which side won the collision handling. Therefore you need
262144 packets * 3976 ephemeral ports (assuming both sides are jnpr, again
worst case) * 2 (to figure out who was the connecter and who was the
accepter) = 2084569088 packet
On Apr 20, 2004, at 9:23 PM, Mike Tancsa wrote:
At 05:09 PM 20/04/2004, Richard A Steenbergen wrote:
party to know which side won the collision handling. Therefore you
need
262144 packets * 3976 ephemeral ports (assuming both sides are jnpr,
again
worst case) * 2 (to figure out who was the conn
I've left your entire message below so that one can see I've removed
nothing. Winstar has made NONE of the statements you are interpreting from
their response. They have simply stated that they don't support it at this
moment in time. I'll grant you that they could have answered "when" or
"why"
> You missed the "(assuming the attacker can accurately guess both
> ports)" part.
>
> This is BY NO MEANS a given. In fact, it is pretty much guaranteed to
> not be a given on any router which has not recently been rebooted. (Or
> at least that the attacker doesn't know has been recently reboo
Please forgive me if I'm naive and/or ask a stupid question, but is
there any reason (besides your platform not supporting it) _not_ to MD5
your BGP sessions? Geez, on my _home_ router all my v4 BGP sessions are
MD5ed (v6 not there yet).
Michel.
-Original Message-
From: [EMAIL PROTECTED
> Stephen J. Wilcox wrote:
> I assume Vijay meant the cost of a port for private
> peering, in which case if you private with all your
> peers and you have a lot of small peers thats going
> to be a lot of cost for a few kbps of traffic
I'm having trouble parsing this. You connect your FE or GE p
On Apr 20, 2004, at 11:29 PM, Michel Py wrote:
Please forgive me if I'm naive and/or ask a stupid question, but is
there any reason (besides your platform not supporting it) _not_ to MD5
your BGP sessions? Geez, on my _home_ router all my v4 BGP sessions are
MD5ed (v6 not there yet).
There is seri
On Apr 20, 2004, at 11:09 PM, David Luyer wrote:
You missed the "(assuming the attacker can accurately guess both
ports)" part.
This is BY NO MEANS a given. In fact, it is pretty much guaranteed to
not be a given on any router which has not recently been rebooted.
(Or
at least that the attacker
Hi, NANOGers.
] Actual data: Over the past three plus years an organization with on the
] order of a dozen MD5-ized BGP sessions has has multiple down sessions
] due to, for instance, a peer doing standard (for them) password
] rotation and forgetting to inform the organization.
Yep, that's a pr
Hi, Patrick.
] Really? I certainly hope an attacker tries those three ports on a
] router I know about. Looking at a random cisco router at a random NAP
] with a significant number of peers, there are a total of zero session
] on those ports.
The ephemeral ports are used for active opens, not
On 20 Apr 2004, at 23:40, Patrick W.Gilmore wrote:
And how do you track a thousand passwords? Okay, maybe that is not
too hard.
Right :-)
But how do you guarantee a thousand peers will never screw up and
forget, lose, fat-finger, etc. a single one of them? This one I would
really like to k
> Rob Thomas wrote:
> We manage well over 150 peering sessions with MD5 passwords
> in place. This includes bogon peering, route-server peering,
> and production traffic peering. This has grown over the past
> three years. The total number of MD5-related outages: zero.
I have to complain about
On Tue, 20 Apr 2004, Michel Py wrote:
>
> Please forgive me if I'm naive and/or ask a stupid question, but is
> there any reason (besides your platform not supporting it) _not_ to MD5
> your BGP sessions? Geez, on my _home_ router all my v4 BGP sessions are
> MD5ed (v6 not there yet).
>
> Michel
Patrick / Christopher,
>> Michel Py wrote:
>> Please forgive me if I'm naive and/or ask a stupid question,
>> but is there any reason (besides your platform not supporting
>> it) _not_ to MD5 your BGP sessions? Geez, on my _home_ router
>> all my v4 BGP sessions are MD5ed (v6 not there yet).
> P
PWG> Date: Tue, 20 Apr 2004 19:24:37 -0400
PWG> From: Patrick W. Gilmore
PWG> Speaking of good randomization, does anyone have a good
PWG> algorithm to randomize ephemeral ports? Obviously "pick
PWG> random number, see if port is open, if it is, repeat" is not
PWG> a good idea, especially on a
That isn't the point of my post. Whether or not you think X is a good
idea, having someone technical say "we don't support X currently" does not
mean a host of other things like "we think X is a bad idea" or any other
nonsense like that.
On Tue, Apr 20, 2004 at 08:29:34PM -0700, Michel Py wrote:
On Apr 21, 2004, at 12:11 AM, Rob Thomas wrote:
] Actual data: Over the past three plus years an organization with on
the
] order of a dozen MD5-ized BGP sessions has has multiple down sessions
] due to, for instance, a peer doing standard (for them) password
] rotation and forgetting to inform t
Joe,
Joe Rhett wrote:
>
> I've left your entire message below so that one can see I've removed
> nothing. Winstar has made NONE of the statements you are interpreting from
> their response. They have simply stated that they don't support it at this
> moment in time. I'll grant you that they c
On Tue, 20 Apr 2004, Michel Py wrote:
> Now, the dumb question:
> Given:
> 1) The context above especially item b
> 2) Christopher Morrow's comments below
> Explain me what having or not having the MD5 password changes. Either
> you're small and/or stupid and do it manually, or you have an autom
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2004-04-20, at 23.09, Richard A Steenbergen wrote:
> but the massive amount of confusion,
> rumor, and worry which the major router vendors (Cisco and Juniper)
> created by essentially rediscovering the god damn spec and then telling
> only thei
On Apr 21, 2004, at 12:51 AM, Michel Py wrote:
b) A specific-to-the-peer route-map to filter the routes I receive from
the peer to the peer's blocks, as agreed in the beer drinking meeting
^H^H^H^H BLPA. This route map is not entirely specific, as I also put
in
stuff such as deny RFC1918 routes ;
Hmm... Well as Randy pointed out... I did not have the correct tools when
I configured this on all of Sprintlink in 1996, and I completed it in one
nights maintenance window. All it takes is normal planning. It is not a
pain in the ass... all of the problems you may have faced were corrected
my M
> > A significant number of BGP sessions will be with a source
> > port of 11000, 11001 or 11002; BGP sessions are generally
> > quite stable and Cisco routers start the source port at
> > 11000. So attackers could cause enough disruption just
> > targeting these three source ports. The other th
On Tue, 20 Apr 2004, Rodney Joffe wrote:
> However, perhaps someone from Winstar would care to help us all
> understand what the alternative solution is to securing the session via
> MD5? I would *love* an alternative to the 5 days of work we've just gone
> through.
1) Deploy correct ingress/egre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2004-04-18, at 04.48, Paul Jakma wrote:
> Well, let's be honest, name one good reason why you'd want IPv6
> (given you have 4)?
That's quite an assumption there.
- - kurtis -
-BEGIN PGP SIGNATURE-
Version: PGP 8.0.3
iQA/AwUBQIJbC6arNK
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2004-04-18, at 01.10, Paul Jakma wrote:
> Hmmm, or rather, there just wont be any demand for IPv6 deployment,
> at least from the edges (consumers, small/medium networks). Why
> bother changing if, despite the (almost indefinitely) availability o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As co-chair of the multi6 WG :
On 2004-04-19, at 02.29, william(at)elan.net wrote:
> Perhaps ipv6 has some dark spots that may have made upgrading not
> attractive
> at this time, but stopping work on it and continuing ipv4 for next 100
> years
>
Christopher / Patrick,
> Christopher L. Morrow wrote:
> I wasn't clear and for that I'm sorry. Except in the later
> code trains, or until the recent past (1 year or so) changing
> the BGP MD5 auth bits required the session to be reset.
Then I'm the one sorry because I never got it to work (I ha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> Perhaps ipv6 has some dark spots that may have made upgrading not
>> attractive
>> at this time, but stopping work on it and continuing ipv4 for next 100
>> years
>> is not an option in my view - we just need to put more effort on
>> things
>> lik
E.B. Dreger wrote:
> I don't think we're even that far along. If I'm reading FreeBSD
> 4.9 and NetBSD 1.6.2 source correctly,
>
> /usr/src/sys/netinet/in_pcb.c
Should have stretched as far as OpenBSD then. Same file.
> tells all.
> AFAIK, sequential search is about it. Try a port number, veri
On Tue, 20 Apr 2004, Michel Py wrote:
> Christopher / Patrick,
>
> > Christopher L. Morrow wrote:
> > I wasn't clear and for that I'm sorry. Except in the later
> > code trains, or until the recent past (1 year or so) changing
> > the BGP MD5 auth bits required the session to be reset.
>
> Then
94 matches
Mail list logo
