Hi folks,
I am looking for some advice on how to place the peer/transit circuits on the edge
routers. Would like to find the best practice that would provide enough diversity
without having an operation nightmare. e.g. putting peer and transit circuits on
different routers will make the routing
William, they might be rejecting your post for SPAM. Take a look at the
link below:
http://groups.google.com/groups?q=dns1.elan.net&hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&sa=N&tab=wg
Michael Booth
The only effect this will have is to further alienate many skilled
engineers and promising students, who are already at a great disadvantage
due to language barriers.
http://listserv.utk.edu/cgi-bin/wa?A2=ind0310&L=jesse&D=1&O=D&P=4946
http://www.spectrum.ieee.org/WEBONLY/wonews/oct03/1003ofac.
Title: London, England Connectivity
I'm looking for colo services, point to point E1's, and PSTN connectivity in the London, England area. Would interested parties able to provide these services please get in touch with me off list.
Thanx.
Ray Burkholder
[EMAIL PROTECTED]
http://www.one
> Leave content filtering to the ES, and *force* ES to filter the content.
And just to make sure we know what content filter is, this is what I
received immedialy following my previous post to nanog.
Whoever you are, that did not see my post, please at least configure your
content filter to r
On Wed, 29 Oct 2003, Alex Yuriev wrote:
> > > application traffic", and we should not do that. It should not be the goal
> > > of IS to enforce the policy for the traffic that passes through it. That
> > > type of enforcement should be left to ES.
> >
> > Well, that is nice thery, but I'd like t
Jack Bates wrote:
>
> David Raistrick wrote:
>
> >
> > You seem to be arguing that NAT is the only way to prevent inbound access.
> > While it's true that most commercial IPv4 firewalls bundle NAT with packet
> > filtering, the NAT is not required..and less-so with IPv6.
> >
>
> I think the poi
> Recently, [EMAIL PROTECTED] (Alex Yuriev) wrote:
> > On Wed, 29 Oct 2003, Alex Yuriev wrote:
> > > As the network operators, we move bits and that is what we should stick to
> > > moving.
> > >
> > > We do not look into packets and see "oh look, this to me looks like an evil
> > > application
> Recently, [EMAIL PROTECTED] wrote:
> >* But customers of broadband ISP aren't going to want to pay more than
> $40 a
> >month for any such thing you add,
>
> You are right about the average customer. But this mythical beast is
> composed of some less than average customers who just want plain
> On Wed, 29 Oct 2003, Alex Yuriev wrote:
> > As the network operators, we move bits and that is what we should stick to
> > moving.
> >
> > We do not look into packets and see "oh look, this to me looks like an evil
> > application traffic", and we should not do that. It should not be the goal
On Wed, 29 Oct 2003, Alex Yuriev wrote:
> As the network operators, we move bits and that is what we should stick to
> moving.
>
> We do not look into packets and see "oh look, this to me looks like an evil
> application traffic", and we should not do that. It should not be the goal
> of IS to e
> I think the other point that may be escaping some people,
> is that as more and more connections take on this VPN-like
> quality, as network operators we lose any visibility into
> the validity of the traffic itself.
As the network operators, we move bits and that is what we should stick to
m
>
> In a message written on Wed, Oct 29, 2003 at 02:24:54PM -0600, Kuhtz, Chris=
> tian wrote:
> > Isn't that the whole point of running a VPN connection?
>
> Yes. What I'm saying is network operators are slowly forcing
> everyone to run _everything_ over a VPN like service. That's fine,
> but
Owen DeLong wrote:
>
> It's much the
> same problem as FTP. The reason FTP doesn't BORK is because most NAT
> gateways understand about the need to proxy FTP and because PASSIVE mode
> FTP doesn't have the same call-setup problems.
Passive mode has the same problems that PORT FTP does. It just
Hi Bill,
I'd be happy to review your paper.
Hope you're doing fine in the US, in these times of turmoil.
Best regards,
Wouter
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of William B. Norton
> Sent: Wednesday, October 29, 2003 7:35 PM
> To: [EMA
David Raistrick wrote:
You seem to be arguing that NAT is the only way to prevent inbound access.
While it's true that most commercial IPv4 firewalls bundle NAT with packet
filtering, the NAT is not required..and less-so with IPv6.
I think the point that was being made was that NAT allows the filt
> In a message written on Wed, Oct 29, 2003 at 02:24:54PM
> -0600, Kuhtz, Christian wrote:
> > Isn't that the whole point of running a VPN connection?
>
> Yes. What I'm saying is network operators are slowly forcing
> everyone to run _everything_ over a VPN like service. That's
> fine, but
On Wed, 29 Oct 2003, Scott McGrath wrote:
> Life would be much simpler without NAT howver there are non-computer
> devices which use the internet to get updates for their firmware that most
> of us would prefer not to be globally reachable due to the human error
> factor i.e. "Oops forgot a rule
In a message written on Wed, Oct 29, 2003 at 02:24:54PM -0600, Kuhtz, Christian wrote:
> Isn't that the whole point of running a VPN connection?
Yes. What I'm saying is network operators are slowly forcing
everyone to run _everything_ over a VPN like service. That's fine,
but it makes network op
Life would be much simpler without NAT howver there are non-computer
devices which use the internet to get updates for their firmware that most
of us would prefer not to be globally reachable due to the human error
factor i.e. "Oops forgot a rule to protect X".
The radar on your cruise ship use
> In article
> <[EMAIL PROTECTED]
> arvard.edu>,
> Scott McGrath <[EMAIL PROTECTED]> wrote:
> >And sometimes you use NAT because you really do not want the NAT'ed
> >device to be globally addressible but it needs to have a link to the
> >outside to download updates. Instrument controllers
> The end result is that in the near future it will be much
> harder, or impossible for network operators to collect
> statistics based on traffic type or to filter particular
> types of traffic without being able to dig into the payload
> itself and see what type of traffic is passing.
>
> S
In article <[EMAIL PROTECTED]>,
Scott McGrath <[EMAIL PROTECTED]> wrote:
>And sometimes you use NAT because you really do not want the NAT'ed device
>to be globally addressible but it needs to have a link to the outside to
>download updates. Instrument controllers et.al.
I don't understand. Wh
> Dave Howe wrote:
> IPSec, SIP/VoIP or almost anything that relies on UDP borks
> on NAT, doesn't it?
I have multiple IPSEC tunnels and also multiple H.323 and SIP phones
behind one IPv4 address. Never tried it, but I hear that some forms of
e2e IPSEC works over NAT now.
Michel.
Hi all -
I've been working on documenting some of the significant disruption from
and aftermath of the Telecom collapse of 1999/2000, focusing specifically
on the operations community and the Peering Ecosystem in particular. I
spent a lot of time speaking with Peering Coordinators to document t
If anyone on the list is connected to PAIX via the MetroPAIX product from 55
Market St. in San Jose, I'd like to hear about your experience. Please
contact me off-list.
Matthew Kaufman
[EMAIL PROTECTED]
[EMAIL PROTECTED]
And sometimes you use NAT because you really do not want the NAT'ed device
to be globally addressible but it needs to have a link to the outside to
download updates. Instrument controllers et.al.
The wisdom of the design decision to use the internet as the only method
to provide software updat
However, what is authenticated in the IPSEC datagrams is the addresses
of the IKE gateways (the routers). The fact that an entire netblock
exists within the tunnel is not especially relevant to the part
that suffers from NAT breakage.
Owen
--On Wednesday, October 29, 2003 3:14 AM -0800 Avleen Vig
Right... Forgot about the SNMP breakage. SIP doesn't depend on knowing
which host it's talking to from the source address, but, it does depend
on being able to assign RTP session parameters based on IP addresses
contained within the SIP payload. Thus, when the SIP payload goes through
a NAT box a
No. IPSEC and SIP break because their payloads include information that
is dependent on the IP address header. In the case of IPSEC, this is
to support end-to-end authentication and avoid certain kinds of man-in-
the-middle attacks. In the case of SIP, it's because SIP is a call setup
protocol w
In a message written on Wed, Oct 29, 2003 at 09:35:13AM -0600, Kuhtz, Christian wrote:
> Simply ignoring present reality isn't a globally wise solutions. Hence we
> have broken VPN products incapable of dealing with NAT. Some are capable of
> dealing with NAT just fine, and are readily available.
Kuhtz, Christian wrote:
>> Kuhtz, Christian wrote:
>>> Seems several commercial clients (such as Cisco's VPN client) offer
>>> workaround for that (tunneling IPSEC in a TCP session).
>> Works great.
>> Yup. there are various proprietary solutions that require us
>> to trash out an expensive and *w
> Kuhtz, Christian wrote:
> > Seems several commercial clients (such as Cisco's VPN client) offer
> > workaround for that (tunneling IPSEC in a TCP session).
> Works great.
> Yup. there are various proprietary solutions that require us
> to trash out an expensive and *working* VPN-1 solution,
On Wed, 29 Oct 2003 15:10:18 GMT, Dave Howe <[EMAIL PROTECTED]> said:
> but sucks if your cable or xDSL ISP decides NAT is the
> way to go. (usually followed by a "well, you shouldn't need two or more
> nodes there/want to run a server/care about SIP, a business should pay for
>
> The fact that something can be worked around with enough
> footwork really doesn't make okay.
Sure. Neither is it ok for VPN vendors to pretend as if NAT wasn't a part
of daily life and reality.
> Consider the congestion related behavior of TCP inside TCP.
> Consider the additional perpacke
On Wed, 29 Oct 2003, Kuhtz, Christian wrote:
> Seems several commercial clients (such as Cisco's VPN client) offer
> workaround for that (tunneling IPSEC in a TCP session). Works great.
I'm sure I could also setup a PPPoEmail shim that would bypass most of
these problems..
Who needs routers wi
Kuhtz, Christian wrote:
> Seems several commercial clients (such as Cisco's VPN client) offer
> workaround for that (tunneling IPSEC in a TCP session). Works great.
Yup. there are various proprietary solutions that require us to trash out
an expensive and *working* VPN-1 solution, buy an equally
Dave Howe wrote:
Indeed so yes - however... A large and increasing segment of my users are
VPN laptop users with ADSL at home. our accounts department looks a
certain amount of askance at IT when they get a large phone bill in
expenses for someone using a 33.6 modem right next to a nice shiny half
Seems several commercial clients (such as Cisco's VPN client) offer
workaround for that (tunneling IPSEC in a TCP session). Works great.
> -Original Message-
> From: Greg Maxwell [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 29, 2003 9:56 AM
> To: Avleen Vig
> Cc: Simon Lockhart
Kuhtz, Christian wrote:
> And there are workarounds for all those.
NAT-T for ipsec is really intended for endnodes only - which is fine if
you are doing the NAT yourself (typical medium/large company scenario -
internal users shouldn't be using IPSEC, that is done at the
gateway/firewall) but suck
On Wed, 29 Oct 2003, Avleen Vig wrote:
> Indeed, and IPSec tunnels are frequently done between routers on
> networks, rather than individual hosts on networks (at least in most
> multi-site enterprises i've seen).
The most common use of VPN links is the roadwarrior.
IPSEC in this context is brok
On Wed, 2003-10-29 at 05:28, Avleen Vig wrote:
> > imagine a network without NAT. I stopped counting applications
> > that are struggling/breaking with NAT...
> > But many people still believe rfc1918 and NAT are a cool thing
> > because they just got used to it...
>
> They're a cool thing for ot
Avleen Vig wrote:
> Indeed, and IPSec tunnels are frequently done between routers on
> networks, rather than individual hosts on networks (at least in most
> multi-site enterprises i've seen).
Indeed so yes - however... A large and increasing segment of my users are
VPN laptop users with ADSL at h
Simon Lockhart wrote:
> Anything that relies on knowing which host it is talking to by
> looking at the source address of packets breaks.
Indeed. Novell networking for example - or MS Exchange New Mail
notification. of course, you shouldn't be doing either on the internet,
but a common "small bra
On Wed, 29 Oct 2003 03:14:20 -0800 Avleen Vig <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 29, 2003 at 11:03:11AM +, Simon Lockhart wrote:
> > No.
> > Anything that relies on knowing which host it is talking to by looking at
> > the source address of packets breaks.
> > Plenty of UDP based apps wo
> Lance;
>
> Having been on both sides of the fence, I know that it is hard
> for router development engineers, especially at legacy vendors, to know
> what is really going on in the market. But for ISPs operators, the
> audience of this group, your question comes across as a "duh" moment.
On Tue, 28 Oct 2003 13:36:26 -0800 [EMAIL PROTECTED] wrote:
> To be more clear, I'm specifically referring to Gigabit Ethernet Converters and
> not
> SFPs for POS or SONET. So, to reprhase, where in your network topology, are yo
> u
> using Gigabit Ethernet, specifically GE interfaces using GBI
On Wed, Oct 29, 2003 at 11:03:11AM +, Simon Lockhart wrote:
> No.
> Anything that relies on knowing which host it is talking to by looking at
> the source address of packets breaks.
> Plenty of UDP based apps work over NAT.
Indeed, and IPSec tunnels are frequently done between routers on
netw
No.
Anything that relies on knowing which host it is talking to by looking at
the source address of packets breaks.
Plenty of UDP based apps work over NAT.
Simon
On Wed Oct 29, 2003 at 10:57:35AM -, Dave Howe wrote:
>
> Avleen Vig wrote:
> > If "more IP addresses" is the only motivation f
Avleen Vig wrote:
> If "more IP addresses" is the only motivation for using IPv6, it's
> really not enough. For environments where direct access to the
> internet isn't required, NAT serves perfectly well.
IPSec, SIP/VoIP or almost anything that relies on UDP borks on NAT,
doesn't it?
On Wed, Oct 29, 2003 at 10:06:37AM +0100, Stefan Mink wrote:
> > > Does anybody honestly think companies will commit the capex needed to
> > > implement IPv6?
> > Not without additional benefits. We need either applications that are
> > working a lot better at ipv6 or we may yet have to see ipv4 s
On Mon, Oct 27, 2003 at 01:17:26PM -0800, [EMAIL PROTECTED] wrote:
> > Does anybody honestly think companies will commit the capex needed to
> > implement IPv6?
> Not without additional benefits. We need either applications that are
> working a lot better at ipv6 or we may yet have to see ipv4 spac
52 matches
Mail list logo
