> 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
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
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 so
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 spac
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 your own darn
co
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 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. Verizon,
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.
> 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
> th
>> 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
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 03:08:39PM -0500, Marshall Eubanks wrote:
> I strongly prefer the new dinner schedule, and I personally
> don't think the theft of cookies is a serious matter.
The whole discussion seems mildly droll to me... :-)
> My feeling is that the refreshments are for _us_, to use f
> From: Markku Savela [mailto:[EMAIL PROTECTED]
> > 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
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: "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
I strongly prefer the new dinner schedule, and I personally
don't think the theft of cookies is a serious matter.
My feeling is that the refreshments are for _us_, to use for _our_
refreshment,
and if people feel they need a sugar cookie mid-way through a
session, they should be allowed to ha
> 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: Anthony G. Atkielski [mailto:[EMAIL PROTECTED]
> 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.
That is not a real problem.
There are two concerns here. The first is running
> > > 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
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 AM
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
On Tue, 28 Mar 2006, JORDI PALET MARTINEZ wrote:
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
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
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
> 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
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 ar
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
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 d
On Fri, 24 Mar 2006, [EMAIL PROTECTED] wrote:
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!
> > 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
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 afternoon
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
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 o
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.
I
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
Fully agree ;-)
Regards,
Jordi
> De: Scott W Brim
> Responder a: <[EMAIL PROTECTED]>
> Fecha: Tue, 28 Mar 2006 11:25:31 -0500
> Para: Steve Silverman <[EMAIL PROTECTED]>
> CC: "ietf@ietf.org"
> Asunto: Re: About cookies and refreshments cost and abuse
>
> On Tue, Mar 28, 2006 11:16:33AM -05
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
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
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 issuein
> 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
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
... 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 e
> 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
[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 ex
> 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
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 interpreta
Hi JORDI,
--On March 23, 2006 5:32:29 PM -0600 JORDI PALET MARTINEZ
<[EMAIL PROTECTED]> wrote:
So my suggestion to be reasonable and fair to all, will be to provide
together with our registration pack, a given number of refreshment
tickets, enough to cover the average needs.
The problem wit
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 interes
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
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 scheduli
> 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
83 matches
Mail list logo
