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
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,
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
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
[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
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 need this or
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
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 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
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
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,
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 NAT,
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
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 the size of
On Sat, Mar 25, 2006 at 04:21:31PM +0100, Brian E Carpenter wrote:
Ray,
I think our goal is to not lose essential participants from the IETF due
to clashes. In fact that's why we want to schedule several years out, so
as to make it easier for many other organizations to do their scheduling.
Mon, Mar 27, 2006 at 10:27:22AM -0500, Scott W Brim wrote:
On Mon, Mar 27, 2006 04:18:42PM +0100, Tim Chown allegedly wrote:
On Mon, Mar 27, 2006 at 10:38:03AM +0200, Brian E Carpenter wrote:
I don't think the analogy holds, for a number of reasons. (As a matter
of interest, there
On Thu, Mar 23, 2006 at 07:34:00PM -0800, Andy Bierman wrote:
Dave Crocker wrote:
Michael StJohns wrote:
What I think Jordi is saying is that he wants the US sponsors to
subsidize the cost of the overseas meetings. At least that's what it
works out to be
This view can be mapped to a
On Thu, Mar 23, 2006 at 09:58:25PM -0600, Harald Alvestrand wrote:
Just wanted to state what's obvious to all of us by now:
This time the wireless WORKED, and Just Went On Working.
That hasn't happened for a while. THANK YOU!
Harald
for novel interpretations
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 except at
From: Keith Moore moore@cs.utk.edu
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.
[EMAIL PROTECTED] wrote:
ah yes, the IETF as a FormulaOne race car.
I'll approach CocaCola Visa for branding rights
if that would help (esp for those folks denied a 770)
ah yes, the ad absurdem form of argumentation.
The reality in having a host is that we already
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 'no you
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 only
... warning, this thread involves geeks trying to understand the real
world ...
My impression (from inside the hotel in Dallas) was that enough people had
travel problems coming into Dallas, which included travel problems
returning from dinner in the West End to the hotel on Sunday, that even
Noel,
I think the street address analogy is not close
enough - anymore than longitude and latitude numbers or
any other description of physical location.
The problem with physical location portability is
that the location remains even if you're not in it. So
someone else might
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
applications,
We could also simply tell everyone please take one pastry in the first
half of the breakfast hour or one cookie in the first half of the
cookie time. I would hope (but maybe this is naive) that if people
realize that the food is not infinite they will leave some for their
peers. I think issueing
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
that are
On Tue, Mar 28, 2006 11:16:33AM -0500, Steve Silverman allegedly
wrote:
In Paris, we switched to a late dinner which was necessary in Paris
but we did this in Dallas. Was this a general decision that I
missed? I prefer dinner from 6 - 8 and a night session where the
local customs support
Fully agree ;-)
Regards,
Jordi
De: Scott W Brim sbrim@cisco.com
Responder a: [EMAIL PROTECTED]
Fecha: Tue, 28 Mar 2006 11:25:31 -0500
Para: Steve Silverman [EMAIL PROTECTED]
CC: ietf@ietf.org ietf@ietf.org
Asunto: Re: About cookies and refreshments cost and abuse
On Tue, Mar 28, 2006
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 continue
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 enable
In Paris, we switched to a late dinner which was necessary in Paris
but we did this in Dallas. Was this a general decision that I missed?
I prefer dinner from 6 - 8 and a night session where the local customs
support this. This might also cut down the need for afternoon sugar
consumption.
An alternative to coordinating meeting dates with a growing list of peer
entities is to simply say that the IETF will meet on the second week of
March, July, and November every year. Such a stance would help everyone
to schedule.
[Note: these weeks are suggestions only, select a permanent variant
If we are willing to accept arbitrarily long paths to get from point
A to point B, there are techniques which allow topologically
insensitive packet handling. The Home-Register (aka HLR lookup) is
one way. (The routing reserachers have described this topic as
stretch 1 routing. There are
Stewart Bryant wrote:
In Paris, we switched to a late dinner which was necessary in Paris
but we did this in Dallas. Was this a general decision that I missed?
I prefer dinner from 6 - 8 and a night session where the local customs
support this. This might also cut down the need for
From: Keith Moore moore@cs.utk.edu
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.
Noel,
Delivering IP packets _always_ involves a translation
service. Usually, more than one, but - assuming we start
with IP addresses - there is at least one MAC (or other L2)
lookup that must occur before the packets can be delivered.
We should be careful not to assert layer
On Tue, 28 Mar 2006, Fleischman, Eric wrote:
An alternative to coordinating meeting dates with a growing list of peer
entities is to simply say that the IETF will meet on the second week of
March, July, and November every year. Such a stance would help everyone
to schedule.
[Note: these weeks
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 you
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 able to
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
I think is clear that we need to fix the meeting dates, and that should be
done in advance so we avoid clashes with other events and we can negotiate
with hotels and sponsors ahead of time enough to make it cheaper.
While I don't agree is to take in consideration national holidays unless
they are
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 transparently without
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
From: Keith Moore moore@cs.utk.edu
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
Noel,
Please recall that IP addresses are currently serving two semantic
functions: Locator and Identity. I interpreted Keith's posting to be
speaking of the latter. (e.g., HIP)
--Eric
-Original Message-
From: Noel Chiappa [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 28, 2006 11:45
The other side of the coin is the fact that many devices will effectively
require no more than a /128 because of the way they connect up to the
network. For example cell phones will be serviced on plans where the
subscription fee is per device.
it's perfectly reasonable to connect a small
From: Hallam-Baker, Phillip [EMAIL PROTECTED]
The other side of the coin is the fact that many devices will effectively
require no more than a /128 because of the way they connect up to the
network. For example cell phones will be serviced on plans where the
subscription fee is per device.
From: Keith Moore moore@cs.utk.edu
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)
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
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 -0800, Michel Py
The other side of the coin is the fact that many devices will effectively
require no more than a /128 because of the way they connect up to the
network. For example cell phones will be serviced on plans where the
subscription fee is per device. Verizon, T-mobile, cingular need no more
than
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.
On Wed, 29 Mar 2006, Mark Andrews wrote:
The other side of the coin is the fact that many devices will effectively
require no more than a /128 because of the way they connect up to the
network. For example cell phones will be serviced on plans where the
subscription fee is per device.
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 to something that
pinch of salt
I think it interesting that the great minds of the IETF are discussing in
depth something that is probably just slightly more important than the
outcome of this week's American Idol contest. Oh well, here are my two
cents...
Cookies seem to be a scarce resource, so why not bring
Hallam-Baker, Phillip writes:
That is not a real problem.
I've lost count of the number of times I've heard _that_. Eight bits,
sixteen bits, thirty-two bits, sixty-four bits, and now 128 bits ...
they are all good for eternity for at least a few years, and then
suddenly they are out of space.
Hallam-Baker, Phillip writes:
My point was that even if we do run out of /64s at some point the
last few remaining /64s can be made to go one heck of a long way.
So the address space will ultimately be managed in crisis mode,
because it was so badly mismanaged to begin with. Why does that
Joel Jaeggli writes:
I find it interesting that our vision is frequently so short-sighted that
we can't even envision in the course of an arguement the applications that
are possible today let alone the ones that people will want in the future.
And one consequence of this is that we cannot
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 all
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
The IESG has approved the following document:
- 'Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP) '
draft-ietf-netconf-beep-10.txt as a Proposed Standard
This document is the product of the Network Configuration Working Group.
The IESG contact persons are Bert
The IESG has approved the following document:
- 'IP over InfiniBand: Connected Mode '
draft-ietf-ipoib-connected-mode-03.txt as a Proposed Standard
This document is the product of the IP over InfiniBand Working Group.
The IESG contact persons are Margaret Wasserman and Mark Townsley.
A URL
The IESG has approved the following document:
- 'DHCPv6 Relay Agent Remote ID Option '
draft-ietf-dhc-dhcpv6-remoteid-01.txt as a Proposed Standard
This document is the product of the Dynamic Host Configuration Working Group.
The IESG contact persons are Margaret Wasserman and Mark
The IESG has approved the following document:
- 'The Role of Wildcards in the Domain Name System '
draft-ietf-dnsext-wcard-clarify-11.txt as a Proposed Standard
This document is the product of the DNS Extensions Working Group.
The IESG contact persons are Margaret Wasserman and Mark
66 matches
Mail list logo
