> Iljitsch van Beijnum wrote:
> ...including the RIR reserves which are at an
> all time high of nearly 400 million)
Also, keep in mind that the RIRs are not the only ones to have reserves.
The address space itself has reserves, class E for example. ISPs have
reserves, and customer have reserves t
Are you saying that ENUM is a dead end?
F.
--
[EMAIL PROTECTED]
819 692 1383
On Wed, 29 Mar 2006, Keith Moore wrote:
- DNS is often out of sync with reality
Dynamic DNS updates are your friend.
From an app developer's point-of-view, DDNS is worthless. DDNS is far
from universally implem
- DNS is often out of sync with reality
Dynamic DNS updates are your friend.
From an app developer's point-of-view, DDNS is worthless. DDNS is far
from universally implemented, and when it is implemented, it's often
implemented badly. DDNS can actually makes DNS a less reliable source
of in
Point made many times, and the proof is in the pudding: if they're using
it so widely it means it works for them.
Actually, no. The world is full of examples of practices and mechanisms
that are widely adopted and entrenched that work very poorly. You only
have to look at any day's newspaper
On 29-mrt-2006, at 18:34, Keith Moore wrote:
- DNS is often out of sync with reality
Dynamic DNS updates are your friend.
From an app developer's point-of-view, DDNS is worthless. DDNS is far
from universally implemented, and when it is implemented, it's often
implemented badly. DDNS can a
> Jeroen Massar wrote:
> I guess you missed out on:
> http://www.iana.org/assignments/ipv6-address-space
I declined to co-author it, as a matter of fact. It started as GUSL
(Globally Unique Site Locals), did you miss that season? Read the dark
side stuff I will post later...
> Austin Schutz wrot
it would be okay if the only apps you needed to run were
two-party apps. in other words, it's not just users and hosts
that need addresses to be the same from everywhere in the
network - apps need stable addressing so that a process on host
A can say to a process on host B, "contact this process
On 29-mrt-2006, at 16:43, Keith Moore wrote:
it would be okay if the only apps you needed to run were two-
party apps. in other words, it's not just users and hosts that
need addresses to be the same from everywhere in the network -
apps need stable addressing so that a process on host A ca
it would be okay if the only apps you needed to run were two-party
apps. in other words, it's not just users and hosts that need
addresses to be the same from everywhere in the network - apps need
stable addressing so that a process on host A can say to a process on
host B, "contact this proce
On 29-mrt-2006, at 16:17, Keith Moore wrote:
it would be okay if the only apps you needed to run were two-party
apps. in other words, it's not just users and hosts that need
addresses to be the same from everywhere in the network - apps need
stable addressing so that a process on host A ca
You didn't mean "locators are a lot easier to deal with if the name
has nothing to do with where the thing it names is", you meant
"locators are a lot easier to deal with if their meaning (i.e. the
thing they are bound to) is the same no matter where you are when
you evaluate them".
This is a pr
On Tue, Mar 28, 2006 04:12:24PM -0500, Noel Chiappa allegedly wrote:
> >>> locators are a lot easier to deal with if they're
> >>> location-independent
>
> >> Huh? Did you mean "identifiers are a lot easier to deal with
> >> if they're location-independent"?
>
> > I really was
Well, in the case of IPv6 we're currently playing in a sandbox 1/8 the
size of the available address space. So if what you say is true, and we
manage to use up an exponential resource in linear time, then we can
change our approach and try again with the second 1/8 of the space,
without having to
On 29-mrt-2006, at 2:17, Tony Hain wrote:
In the past 10 years, there have been several years where the growth
of the growth was less than the year before:
1996199719981999200020012002200320042005
2.7 1.2 1.6 1.2 2.1 2.4 1.9 2.4
> Mark Andrews writes:
>
> > Which was why IPv6 when to 128 bits rather than 64 bits.
>
> That won't help. It will add perhaps 25% to the lifetime of the
> address space, no more.
>
> > 64 bits of address space would have been fine to give
> > everyone all the addresses they would need. 128 b
Thomas Narten writes:
> This is FUD. Care to back up your assertions with real analysis?
Sure.
The consistent mistake engineers make in allocating addresses is that
they estimate capacity in terms of sequential and consecutive
assignment of addresses--but they _assign_ addresses in terms of bit
Mark Andrews writes:
> Which was why IPv6 when to 128 bits rather than 64 bits.
That won't help. It will add perhaps 25% to the lifetime of the
address space, no more.
> 64 bits of address space would have been fine to give
> everyone all the addresses they would need. 128 bits gives
> them al
Iljitsch van Beijnum wrote:
> On 27-mrt-2006, at 23:51, Austin Schutz wrote:
>
> >>> Your long term view is irrelevant if you are unable to meet short
> >>> term
> >>> challenges.
>
> >> very true. but at the same time, it's not enough to meet short term
> >> challenges without providing a path
"Anthony G. Atkielski" <[EMAIL PROTECTED]> writes:
> BTW, giving out /64s is one reason why the IPv6 address space will be
> exhausted in barely more time than was required to exhaust the IPv4
> address space.
This is FUD. Care to back up your assertions with real analysis?
You might want to rev
> Scott Leibrand writes:
>
> > They can charge for IPv4 addresses because they're perceived to be scarce.
> > With IPv6 they may be able to charge for allowing me a /48 instead of a
> > /56 or /64, but IMO they won't be able to assign me a /128 by default and
> > charge me if I want a /64.
>
> T
On 27-mrt-2006, at 23:51, Austin Schutz wrote:
Your long term view is irrelevant if you are unable to meet short
term
challenges.
very true. but at the same time, it's not enough to meet short term
challenges without providing a path to something that is
sustainable in
the long term.
>> And there's always IPv8...
Wasn't that IPv9 fun? ;)
-Thaddeus
-Original Message-
From: Tim Chown [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 28. März 2006 07:09
To: ietf@ietf.org
Subject: Re: Stupid NAT tricks and how to stop them.
On Tue, Mar 28, 2006 at 01:54:52AM
On 28-mrt-2006, at 11:54, Michel Py wrote:
Tim Chown wrote:
If you deploy IPv6 NAT, you may as well stay with IPv4.
You're the one who convinced me some three years ago that there
will be
IPv6 NAT no matter what, what's the message here?
I've travelled to this strange land where there is
> From: Keith Moore
> what I mean is that a locator that means the same thing (refers to the
> same destination) no matter where you are in the net, is a lot easier
> to deal with than a locator with a meaning that changes (refers to
> different destinations) depending on wher
> > a big wrinkle is when private networks are interconnected via
> > NATs - there's no "external" addresses that can be used there.
> >
> Currently (as I understand it) the solution involves static
> natting both sides. Again, this could probably benefit from automation. No
> question that
On Tue, Mar 28, 2006 at 09:48:24PM +0200, Anthony G. Atkielski wrote:
> > No, usually it's a lot less than 50%. More typical is like $5/mo extra
> > for additional IP(s).
>
> How much do the additional IPs cost the ISP?
>
This is dependent upon the location and size of the ISP. An
ISP /
On Tue, Mar 28, 2006 at 02:33:25PM -0500, Keith Moore wrote:
> > Precisely. Just what is this fetish about keeping the IP address the same as
> > the packet travels?
>
> it's called good engineering. eliminating needless complexity.
>
..and NAT isn't good engineering. But it may be good
> > > From: Keith Moore
> >
> > > even if IP had identifiers for hosts that were independent of
> > > locators, they wouldn' t be worth very much without a way to map them
> > > to locators. and locators are a lot easier to deal with if they're
> > > location-independent.
> >
> > From: Keith Moore
>
> > even if IP had identifiers for hosts that were independent of
> > locators, they wouldn' t be worth very much without a way to map them
> > to locators. and locators are a lot easier to deal with if they're
> > location-independent.
>
> Huh? Did yo
11:45 AM
To: ietf@ietf.org
Cc: [EMAIL PROTECTED]
Subject: Re: Stupid NAT tricks and how to stop them.
> From: Keith Moore
> even if IP had identifiers for hosts that were independent of
> locators, they wouldn' t be worth very much without a way to map
them
> to
Scott Leibrand writes:
> They could do so (when they implement IPv6) by running dual-stack routers.
Ah, so they aren't doing it _now_. They'll probably be doing it Real
Soon Now.
> My ISP doesn't yet provide IPv6 support. But at some point they (or
> another ISP) will.
I guess that's when you
> From: Keith Moore
> even if IP had identifiers for hosts that were independent of
> locators, they wouldn' t be worth very much without a way to map them
> to locators. and locators are a lot easier to deal with if they're
> location-independent.
Huh? Did you mean "identifi
> Precisely. Just what is this fetish about keeping the IP address the same as
> the packet travels?
it's called good engineering. eliminating needless complexity.
> If there is a way for the host to determine that it is behind a NAT and to
> request external registration of necessary ports the
Scott Leibrand writes:
> We definitely will have to see how it shapes up in the US. In Japan,
> where they actually have IPv6 deployed to end users, it looks like most
> ISPs are giving out /64's to home users, and /48's to business users:
Looks like IPv6 will be exhausted even sooner than I pre
On 03/28/06 at 9:00pm +0200, Anthony G. Atkielski <[EMAIL PROTECTED]> wrote:
> Scott Leibrand writes:
>
> > Um, have you heard of dual stack? My Windows XP does it quite
> > transparently (after I enable IPv6 at the command line), and presumably
> > Vista will do IPv4/IPv6 dual stack transparentl
> IP addresses currently serve two completely separate functions: they
> identify *who* you are talking to, and they identify *where* they are.
there's a tad more to it than that which is essential:
in a non-NATted network, IP addresses identify where a host is in a way
that is independent of the
On 03/28/06 at 8:54pm +0200, Anthony G. Atkielski <[EMAIL PROTECTED]> wrote:
> Scott Leibrand writes:
>
> > They can charge for IPv4 addresses because they're perceived to be scarce.
> > With IPv6 they may be able to charge for allowing me a /48 instead of a
> > /56 or /64, but IMO they won't be a
> In general, all of these (including extra addresses) have the attribute that
> "you plug this box in at the edge of the network, and don't have to change
> anything else".
which of course isn't true, even if it was claimed (or implied).
___
Ietf mail
Scott Leibrand writes:
> Um, have you heard of dual stack? My Windows XP does it quite
> transparently (after I enable IPv6 at the command line), and presumably
> Vista will do IPv4/IPv6 dual stack transparently without any command-line
> enabling.
How does your ISP handle this?
How much extra
Scott Leibrand writes:
> They can charge for IPv4 addresses because they're perceived to be scarce.
> With IPv6 they may be able to charge for allowing me a /48 instead of a
> /56 or /64, but IMO they won't be able to assign me a /128 by default and
> charge me if I want a /64.
They will charge y
Keith Moore writes:
> true. people do all kinds of evil things that break the net.
Yeah ... like charging for IP addresses that should be free.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
practice.
--
Eric
--> -Original Message-
--> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
--> Sent: Tuesday, March 28, 2006 1:17 PM
--> To: ietf@ietf.org
--> Cc: [EMAIL PROTECTED]
--> Subject: RE: Stupid NAT tricks and how to stop them.
-->
--> > From: &qu
> > From: Keith Moore
>
> > NATs do harm in several different ways
>
> It's not just NAT's that are a problem on the fronts you mention, though:
yes, there are other things that do harm besides NATs.
however, that's not a justification for NATs.
_
> From: "Gray, Eric" <[EMAIL PROTECTED]>
> I think the "street address" analogy is not close enough - anymore
> than longitude and latitude numbers or any other description of
> physical location.
No, it's a very good analogy, because the road network is a very good analog
to the
more (it once did). Your phone number is really more akin to an
identity. Phone you call someone, the system does a name lookup (ala
DNS) and then gets a routable location.
Yours,
Joel
At 10:48 AM 3/28/2006, Gray, Eric wrote:
To: [EMAIL PROTECTED], ietf@ietf.org
Subject: RE: Stupid NAT tric
On 03/28/06 at 7:00am +0200, Anthony G. Atkielski <[EMAIL PROTECTED]> wrote:
> Keith Moore writes:
>
> > don't think upgrade; think coexistence.
>
> How do IPv4 and IPv6 coexist? Like ASCII and EBCDIC, perhaps?
Um, have you heard of dual stack? My Windows XP does it quite
transparently (after I
On 03/28/06 at 6:11am +0200, Anthony G. Atkielski <[EMAIL PROTECTED]> wrote:
> Scott Leibrand writes:
>
> > NAT (plus CIDR) was the short-term solution, and is realistic as a
> > medium-term solution. In the long term, though, I don't think it will be
> > the only solution.
>
> It will be if ISPs
On Tue, 2006-03-28 at 08:00 -0800, Hallam-Baker, Phillip wrote:
> > From: Kurt Erik Lindqvist [mailto:[EMAIL PROTECTED]
>
> > > NAT is a dead end. If the Internet does not develop a way
> > to obsolete
> > > NAT, the Internet will die. It will gradually be replaced
> > by networks
> > > tha
> From: Kurt Erik Lindqvist [mailto:[EMAIL PROTECTED]
> > NAT is a dead end. If the Internet does not develop a way
> to obsolete
> > NAT, the Internet will die. It will gradually be replaced
> by networks
> > that are more-or-less IP based but which only run a small number of
> > applica
ECTED] [mailto:[EMAIL PROTECTED]
--> Sent: Tuesday, March 28, 2006 10:06 AM
--> To: ietf@ietf.org
--> Cc: [EMAIL PROTECTED]
--> Subject: RE: Stupid NAT tricks and how to stop them.
-->
--> > From: "Michel Py" <[EMAIL PROTECTED]>
-->
--> >> Tim Cho
> From: "Michel Py" <[EMAIL PROTECTED]>
>> Tim Chown wrote:
>> If you deploy IPv6 NAT, you may as well stay with IPv4.
> You're the one who convinced me some three years ago that there will
> be IPv6 NAT no matter what, what's the message here?
I think Tim's point is that the
> From: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]>
> I have never seen a coherent, rational argument as to why the network
> numbering on my internal network should be the same as the network
> numbering on the Internet. All I hear is a restatement of the original
> claim, the
> From: Keith Moore
> NATs do harm in several different ways
It's not just NAT's that are a problem on the fronts you mention, though:
> they block traffic in arbitrary directions
My ISP blocks incoming SMTP and HTTP connections. Has nothing to do with
NAT.
> these days they
> From: "Anthony G. Atkielski" <[EMAIL PROTECTED]>
> the solution is pretty simple: give out IP addresses for free, instead
> of charging an arm and a leg for anything other than a single address.
> As long as ISPs won't provide multiple addresses, or won't provide
> them excep
> From: Scott Leibrand <[EMAIL PROTECTED]>
> NAT (plus CIDR) was the short-term solution,
Do note that CIDR was intended as a solution to a number of problems, not
just consumption of address space - like this one:
> From: "Michel Py" <[EMAIL PROTECTED]>
> Especially now that th
On 28 mar 2006, at 13.46, Keith Moore wrote:
NAT is a dead end. If the Internet does not develop a way to
obsolete NAT, the Internet will die. It will gradually be
replaced by networks that are more-or-less IP based but which
only run a small number of applications, poorly, and expensive
On Tue, Mar 28, 2006 at 01:54:52AM -0800, Michel Py wrote:
> > Tim Chown wrote:
> > If you deploy IPv6 NAT, you may as well stay with IPv4.
>
> You're the one who convinced me some three years ago that there will be
> IPv6 NAT no matter what, what's the message here?
I think there will be IPv6 NA
Hello;
On Mar 27, 2006, at 11:13 PM, Anthony G. Atkielski wrote:
Keith Moore writes:
NAT is a dead end. If the Internet does not develop a way to
obsolete
NAT, the Internet will die.
I hardly think so, but in any case, the solution is pretty simple:
give out IP addresses for free, instea
NAT is a dead end. If the Internet does not develop a way to obsolete
NAT, the Internet will die. It will gradually be replaced by networks
that are more-or-less IP based but which only run a small number of
applications, poorly, and expensively.
...or you will see an overlay network build
On Mar 28, 2006, at 5:50 AM, Dave Cridland wrote:
On Tue Mar 28 11:33:27 2006, Austin Schutz wrote:
The limitations of NAT you mention make little difference to most
of the NAT users I am familiar with. These are typically end users or
small organizations. They generally don't know wha
If you can't provide the functionality that the customers want your protocol
purity comes down to 'you have to do it our way, oh and by the way we have
no interest in listening to you'.
which is why some of us wrote draft-ietf-v6ops-nap
Brian
_
On Tue Mar 28 11:33:27 2006, Austin Schutz wrote:
The limitations of NAT you mention make little difference to most
of the NAT users I am familiar with. These are typically end users
or
small organizations. They generally don't know what they are
missing, and NAT
works adequately well
On Mon, Mar 27, 2006 at 11:35:21PM -0500, Keith Moore wrote:
> >>now if what you're saying is that we need a standard NAT extension
> >>protocol that does that, I might agree. though IMHO the easiest way to
> >>do that is to make the NAT boxes speak IPv6.
> >>
> >
> > Yes, I am saying we nee
[cc trimmed]
On Tue, 2006-03-28 at 01:54 -0800, Michel Py wrote:
> > People will still want to do NAT on IPv6.
>
> Yes, and since site-locals have been deprecated they will also hijack an
> unallocated block of addresses to use as private, same what happened
> prior to RFC 1597 for the very same
> Tim Chown wrote:
> If you deploy IPv6 NAT, you may as well stay with IPv4.
Tim,
You're the one who convinced me some three years ago that there will be
IPv6 NAT no matter what, what's the message here?
> See also
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-02.txt
Remember: Users
On 28 mar 2006, at 00.11, Keith Moore wrote:
NAT is a done deal. It's well supported at network edges. It solves
the addressing issue, which was what the market wanted. It voted
for NAT with
dollars and time. It is the long term solution - not because it is
better, but
because it
Today, 90% of the phones in the world are still analog. Including
mine,
in the capital of California and my buddies' in the heart of Silicon
Valley.
the (static) statement that "90% of phones are analog" seems very
wrong to me.
according to newest ITU-D estimates, by the end of 2004, the
Interesting discussion.
Keith is hitting all the nails on the head. Phillip seems to suggest
that consumers buy NATs out of choice. They don't have any choice.
I surveyed my final years students last month. Just four have a static
IPv4 allocation for their home network, and only one has more
In this case the benefit to running NAT on my home network is that it saves
me $50 per month in ISP fees, means I have wireless service to the whole
house and means that guests can easily connect.
one immediate benefit to my running IPv6 on my home network is that I
can access any of my machine
> From: Keith Moore [mailto:[EMAIL PROTECTED]
> > I agree, but that opportunity may be to enhance NAT
> rather than throw
> > it away (you state something similar in your conclusion).
>
> As an engineer, the right thing to do is to transition away
> from NAT (along with IPv4), so that eve
Keith Moore writes:
> don't think upgrade; think coexistence.
How do IPv4 and IPv6 coexist? Like ASCII and EBCDIC, perhaps?
> As an engineer, the right thing to do is to transition away from NAT
> (along with IPv4), so that eventually it can be discarded.
I'm not aware of a smooth transition o
This is reasonable, but there is no realistic path to ipv6 that the
known world can reasonably be expected to follow.
That's because people keep thinking that there needs to be a path from
IPv4 to IPv6 that makes sense for all applications. No such path
exists, because applications vary
Keith Moore writes:
> and at some delta-T in the future, some things will be different. it
> might (or might not) be that lots more hosts run v6, it might (or might
> not) be that NATs are discredited, it might (or might not) be that the
> Internet mostly exists to connect walled gardens.
Probabl
Keith Moore writes:
> NAT is a dead end. If the Internet does not develop a way to obsolete
> NAT, the Internet will die.
I hardly think so, but in any case, the solution is pretty simple:
give out IP addresses for free, instead of charging an arm and a leg
for anything other than a single addre
Scott Leibrand writes:
> NAT (plus CIDR) was the short-term solution, and is realistic as a
> medium-term solution. In the long term, though, I don't think it will be
> the only solution.
It will be if ISPs continue to charge for extra IP addresses, as they
probably always will.
> And if someda
On Mon, Mar 27, 2006 at 05:11:18PM -0500, Keith Moore wrote:
> >>>Your long term view is irrelevant if you are unable to meet short term
> >>>challenges.
> >>very true. but at the same time, it's not enough to meet short term
> >>challenges without providing a path to something that is sustainabl
So the real question is: Given NAT, what are the best
solutions to the long term challenges?
A protocol that would be only v4 with more bits in the first place, with
routers / NAT boxes that would pad/unpad extra zeroes (also including
extra TBD fields). As this would be 100% compatible with v4
> Austin Schutz wrote
> the ipv6 vs. NAT battle is over in the marketplace.
Especially now that the size of the routing table is not a problem
anymore.
> So the real question is: Given NAT, what are the best
> solutions to the long term challenges?
A protocol that would be only v4 with more bit
On Mon Mar 27 22:51:35 2006, Austin Schutz wrote:
NAT is a done deal. It's well supported at network edges. It solves
the addressing issue, which was what the market wanted. It voted
for NAT with
dollars and time. It is the long term solution - not because it is
better, but
because it
Your long term view is irrelevant if you are unable to meet short term
challenges.
very true. but at the same time, it's not enough to meet short term
challenges without providing a path to something that is sustainable in
the long term.
This is reasonable, but there is no realistic
On 03/27/06 at 1:51pm -0800, Austin Schutz <[EMAIL PROTECTED]> wrote:
> This is reasonable, but there is no realistic path to ipv6 that the
> known world can reasonably be expected to follow.
I think a good number of exclusively-IPv4-using* realists (like myself)
will disagree with you here
On Mon, Mar 27, 2006 at 02:16:57PM -0500, Keith Moore wrote:
> > > maybe this is because "protocol purity zealots" take a long
> > > term view and want to preserve the flexibility of the net
> > > "market" to continue to grow and support new applications,
> > > whereas the NAT vendors are just e
> > > > maybe this is because "protocol purity zealots" take a long term
> > > > view and want to preserve the flexibility of the net "market" to
> > > > continue to grow and support new applications, whereas the NAT
> > > > vendors are just eating their seed corn.
> > >
> > > Your long term vi
specification had been allowed.
> -Original Message-
> From: Scott Leibrand [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 27, 2006 2:50 PM
> To: Hallam-Baker, Phillip
> Cc: ietf@ietf.org; iab@iab.org
> Subject: RE: Stupid NAT tricks and how to stop them.
>
> On 03/27/06
On 03/27/06 at 11:38am -0800, Hallam-Baker, Phillip <[EMAIL PROTECTED]> wrote:
>
> People can dispute opinions but not facts. The fact is that it has taken far
> too long to deploy DNSSEC.
Just a nit, as I can't really disagree with your assertion (nor can I
necessarily agree with it, as I haven't
> From: Keith Moore [mailto:[EMAIL PROTECTED]
> > > maybe this is because "protocol purity zealots" take a long term
> > > view and want to preserve the flexibility of the net "market" to
> > > continue to grow and support new applications, whereas the NAT
> > > vendors are just eating their
> > > the NAT vendors are just eating their seed corn.
> >
> > Your long term view is irrelevant if you are unable to meet short term
> > challenges.
>
> very true. but at the same time, it's not enough to meet short term
> challenges without providing a path to something that is sustain
> > maybe this is because "protocol purity zealots" take a long
> > term view and want to preserve the flexibility of the net
> > "market" to continue to grow and support new applications,
> > whereas the NAT vendors are just eating their seed corn.
>
> Your long term view is irrelevant if you
> From: Keith Moore [mailto:[EMAIL PROTECTED]
> > Unfortunately some protocol purity zealots still have to
> realize that
> > Linksys, Netgear, Belkin and consorts don't sell NAT boxes because
> > they think NAT is good, they sell NAT boxes because
> consumers want to
> > buy them.
>
> may
> Unfortunately some protocol purity zealots still have to realize that
> Linksys, Netgear, Belkin and consorts don't sell NAT boxes because they
> think NAT is good, they sell NAT boxes because consumers want to buy
> them.
maybe this is because "protocol purity zealots" take a long term view
and
> Hallam-Baker, Phillip wrote:
> The obvious way to deploy IPv6 is to leverage
> the NAT infrastructure.
Indeed.
> Evangelize to the major providers of NAT (Cisco,
> Netgear, Microsoft, Belkin...)
I will point out that we have had the beginning of a solution for ages
with 6to4. Unfortunately, t
> From: Henning Schulzrinne [mailto:[EMAIL PROTECTED]
> Trying to devise ever more elaborate NAT traversal mechanisms
> that include sending keep-alives every few seconds and
> various "let's try this and then that" algorithms clearly
> don't scale if we want to get to consumer-grade reliabil
101 - 192 of 192 matches
Mail list logo
