Why would a service provider give up skimming the cream with that
(nearly free) extra cash that weirdos like us hand them for real IPv4
addresses?
Eliot
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Hi Andrew,
And people wonder why NATs proliferate... much of the world has no
option but to live with them. This is a direct result of policy
discouraging IPv4 address allocation.
sorry for asking, but what policy are you referring to?
RIR policy?
Can you point out any RIRs policy that
On 30-mrt-2006, at 10:29, marcelo bagnulo braun wrote:
And people wonder why NATs proliferate... much of the world has no
option but to live with them. This is a direct result of policy
discouraging IPv4 address allocation.
sorry for asking, but what policy are you referring to?
RIR
On 30-mrt-2006, at 6:26, Anthony G. Atkielski wrote:
We currently have 1/8th of the IPv6 address space set aside for
global unicast purposes ...
Do you know how many addresses that is? One eighth of 128 bits is a
125-bit address space, or
42,535,295,865,117,307,932,921,825,928,971,026,432
On 28 mar 2006, at 18.00, 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 more-or-less IP based but
On Thu, Mar 30, 2006 at 01:36:18PM +0200, Iljitsch van Beijnum wrote:
The thing that is good about IPv6 is that once you get yourself a /
64, you can subdivide it yourself and still have four billion times
the IPv4 address space. (But you'd be giving up the autoconfiguration
Steve Silverman writes:
The problem with allocating numbers sequentially is the impact on
routers and routing protocols.
The problem with not doing so is that a 128-bit address doesn't
provide anything even remotely close to 2^128 addresses.
You have to choose what you want.
I have heard
Keith Moore writes:
I find myself wondering, don't they get support calls from customers
having to deal with the problems caused by the NATs?
Sure, and the reply is I'm sorry, but we don't support multiple
computers on residential accounts.
___
Austin Schutz wrote:
On Wed, Mar 29, 2006 at 01:00:44AM +0200, Iljitsch van Beijnum wrote:
1996199719981999200020012002200320042005
2.7 1.2 1.6 1.2 2.1 2.4 1.9 2.4 3.4 4.5
(The numbers represent the number of addresses
--On Thursday, March 30, 2006 08:47 -0800 Peter Sherbin
[EMAIL PROTECTED] wrote:
If someone calls up for help with a
configuration problem, that may be six month's of
profits from that customer eaten up in the cost of
answering the call.
That is because the current Internet pricing has
I find myself wondering, don't they get support calls from
customers having to deal with the problems caused by the NATs?
Because they don't answer them. In the process of doing the
work that led to RFC 4084, I reviewed the terms and conditions
of service of a large number of ISPs in
On Thu, Mar 30, 2006 at 11:26:40PM +0200, Iljitsch van Beijnum wrote:
If that is indeed the case then the enhanced nat road for ipv6
begins to make much more sense, even in the nearer term.
I remember someone saying something about enhanced NAT here a few
days ago but I can't find it...
Thus spake Anthony G. Atkielski [EMAIL PROTECTED]
Iljitsch van Beijnum writes:
However, since that time I've learned to appreciate
stateless autoconfiguration and the potential usefulness of having
the lower 64 bits of the IPv6 address as a place to carry some
limited security information (see
Thus spake Anthony G. Atkielski [EMAIL PROTECTED]
Iljitsch van Beijnum writes:
So how big would you like addresses to be, then?
It's not how big they are, it's how they are allocated. And they are
allocated very poorly, even recklessly, which is why they run out so
quickly. It's true that
Thus spake Keith Moore moore@cs.utk.edu
Now of course this ISP does have a TC that prohibits running a server,
but server is a pretty vague term, and you don't have to be running
any kind of server to suffer from NAT brain-damage.
My ISP has ingeniously defined a server as any application that
Noel Chiappa wrote:
Needless to say, the real-time taken for this process to complete
- i.e. for routes to a particular destination to stabilize, after
a topology change which affects some subset of them - is dominated
by the speed-of-light transmission delays across the Internet
fabric. You
From: Michel Py [EMAIL PROTECTED]
Needless to say, the real-time taken for this process to complete
- i.e. for routes to a particular destination to stabilize, after a
topology change which affects some subset of them - is dominated by
the speed-of-light transmission
On Thu, 30 Mar 2006 20:43:14 -0600, Stephen Sprunk
[EMAIL PROTECTED] wrote:
That's why 85% of the address space is reserved. The /3 we are using (and
even then only a tiny fraction thereof) will last a long, long time even
with the most pessimistic projections. If it turns out we're
Noel Chiappa wrote:
If you think there aren't still stability issues, why don't
you try getting rid of all the BGP dampening stuff, then?
Have any major ISP's out there done that?
Dampening is part of the protocol and has nothing to do with the speed
of light. Removing it is akin to removing
On Fri, Mar 31, 2006 at 05:36:30AM +0200, Anthony G. Atkielski wrote:
More bogus math. Every time someone tries to compute capacity, he
looks at the address space in terms of powers of two. Every time
someone tries to allocate address space, he looks as the address space
in terms of a string
Dampening is part of the protocol and has nothing to do with the speed
of light.
Well, not really. Assume a simplistic model of the Internet with M
core routers (in the default free zone) and N leaf AS, i.e. networks
that have their own non-aggregated prefix. Now, assume that each of the
leaf
Stephen Sprunk writes:
An IPv4/6 address is both a routing locator and an interface identifier.
And so engineers should stop saying that n bits of addressing provides
2^n addresses, because that is never true if any information is
encoded into the address. In fact, as soon as any information
Theodore Ts'o writes:
You've been making the same point over and over (and over)
again.
To some, perhaps. I'm not so sure that it has yet been made even once
to others.
It's probably the case that people who will be convinced by your
arguments, will have accepted the force of your
On Thu, 30 Mar 2006, Stephen Sprunk wrote:
Thus spake Anthony G. Atkielski [EMAIL PROTECTED]
Why is this so difficult for people to understand?
..
Why is this so difficult for you to understand?
Feeding trolls is not very useful.. please at least keep him in Cc: so
I don't have to see the
The IESG has received a request from an individual submitter to consider the
following documents:
- 'TLS User Mapping Extension'
draft-santesson-tls-ume-04.txt as a Proposed Standard
- 'TLS Handshake Message for Supplemental Data'
draft-santesson-tls-supp-00.txt as a Proposed Standard
The
The IESG has reclassified draft-ietf-idwg-beep-idxp, currently in the
rfc-editor's queue as an experimental RFC. This document was
originally approved as a proposed standard. However it contains a
normative reference to draft-ietf-idwg-idmef-xml. That specification
has been approved as an
26 matches
Mail list logo
