Spam Control Considered Harmful

Mailman List Mirror (Read Only)
1

Sure...and when I apply to ARIN for more space and show I've assigned a
/21 worth of space to static IP dialup users, I'm sure they won't laugh
while stamping DENIED on my application :slight_smile:

How does Demon get away with that sort of waste?

I is *not* a waste. It is a very good use of IP address space. We
have usage density of about 99% of our allocated blocks. Meanwhile
the customers love it bcause they can do things that not having an
IP address would stop. Their own domain name for a start -
"snark.demon.co.uk" for my dial-up. Security based on IP address.
We have many many busines users who use the fact that they know
what IP address a dial-up user will have to authenticate access to
their corporate networks.

We made a business case, and it is the correct one. We very rarely
have much more address space than required, and whether or not the
customers know what an IP address is, they come to us (as the
largest provider in the UK) because of the feature set and quality
of the service. They want an infinite number of mailboxes, they
like to be able to reconnect a dialup that drops half way through
a telnet of ftp session and continue from where they left off, they
like the "instant" intranet they get. Adn so on.

I reiterate. It is not a waste. What is a waste is people like
Interop having an entire class A, like PSInet having a class A,
like MIT ... fill in the blanks. They just got their first, but I
cannot see anyone rushing to return them.

Please do not judge other people's products and services because
you believe that it shouldn't work.

Peter

2

We originally used static addresses for dialup customers. We requested
more address space, and as part of the justification procedure I was told
by Kim Hubbard that we had to use dynamic address assignments for anyone
that was not connected 24/7. I used the same arguments, including that
you can't get any more efficient that assigning a single /32 to a single
host, but was told that in the days of address scarcity we couldn't afford
such a use of address space. We changed everything to dynamic, and after
now having 12x the number of customers, we are still using less space than
we were.

Until IPv6 is widely used and address space is not so critical, we have to
conserve address space and using it wisely.

Perhaps in the UK there are different requirements for allocation of address
space than InterNIC/ARIN.

John Tamplin Traveller Information Services
jat@Traveller.COM 2104 West Ferry Way
205/883-4233x7007 Huntsville, AL 35801

3

Peter Galbavy <peter@wonderland.org> writes:

While I agree that a good technical goal is to have
a pair like (wonderland.demon.co.uk, www) map to the http
daemon on Peter's box, and continuously push to make that
a reality, the appropriate way of doing this is to
consider the pair to be an endpoint address which maps to
different numbers that change relative to time and
topology.

That is, with some enhancements to the DNS and deployment
of evolving NAT technology, how Demon allocates addresses
locally will be Demon's business, and what those addresses
look like here likely will be different. (Ignoring the
fact that it could be redirected to a cache --:slight_smile: )
MOreover, if Peter changes his location in the Internet
the numbers will be different again, but the pair above
will continue to map to his http daemon.

Security based on IP address.

Here I disagree, not only for the obvious reason that
forgery is easy, but also because basing anything on IP
address that does not involve looking back up through the
DNS (which is also not yet safe) is incompatible with NAT.

Addresses change over time and over space.

I reiterate. It is not a waste. What is a waste is people like
Interop having an entire class A, like PSInet having a class A,
like MIT ... fill in the blanks. They just got their first, but I
cannot see anyone rushing to return them.

Right. I want to NAT them. Anything bounded by NATs can
use whatever address allocation scheme it likes, even to
the extent of using the same IP addresses in use elsewhere
in the concatenated Internet.

  Sean.

4

> Security based on IP address.

Here I disagree, not only for the obvious reason that
forgery is easy, but also because basing anything on IP
address that does not involve looking back up through the
DNS (which is also not yet safe) is incompatible with NAT.

...which brings me to think if it isn't so that Secure DNS (at
least as currently specified) and widespread deployment of NAT
boxes which fiddle with the contents of DNS reply/request packets
isn't exactly a properly working combination. As I understand it
you can have NAT or Secure DNS with e.g. signed A records but you
can't (easily?) have both.

(Which brings us even further afield from the original subject... :wink:

Regards,

- H�vard

5

Hi,

Of course, static IP address assignment is wasteful -- as demonstrated by
your case (and justifying ones actions by pointing to others doing worse is
seldom very effective), however a couple of questions/points:

Until IPv6 is widely used

Are any ISPs seriously considering deploying IPv6 in the forseeable future
(e.g., what level of demand are ISPs in the US seeing for IPv6)?

and address space is not so critical, we have to
conserve address space and using it wisely.

Address space will (presumably) always be critical -- after all, it
is a bit hard to connect to the Internet without it. As such, using
it wisely would seem a good idea. Of course, whether one needs to
"conserve" address space and whether conservation implies wise use
would depend on the answer to the question above and what one thinks
will happen when the free address pool approaches exhaustion.

Perhaps in the UK there are different requirements for allocation of address
space than InterNIC/ARIN.

Of course there are (look at why there are different regional registries
in the first place). For example, what happens when a new ISP with no
previous allocation history starts up in the US as compared to what
happens when it starts up in Europe or the AP region. Other examples
exist (the static IP address assignment issue isn't one of them -- all
the registries have a similar policy now).

These differences, however, are something the registries try to minimize
and work to resolve internally. Too bad there can't be a public forum in
which such stuff is worked on without the raving lunatics coming out of
the woodwork and turning the forum into meaningless repetitive dribble.

In response to the original statement that started this thread, I'd be
interested to know how one would go about putting technological djinn back
into their respective bottles. Blackhole feeds, et al, exist because
they serve a purpose. Like any tool, they can be misused. I'm sort
of suprised that some governments haven't already required ISPs in their
countries to accept "official" black hole feeds, but I suspect it'll happen
within the next year or so.

Of course, many people wish nuclear weapons weren't invented too...

Regards,
-drc

6

[playing devil's advocate here]

Of course, there is a rather large contingent of the
Internet community that is of the opinion that IPv6 is
a solution in search of a problem.

- paul

7

Is that why Cisco is one of the few networking companies that participate
in the 6bone? :slight_smile:

Joe Shaw - jshaw@insync.net
NetAdmin - Insync Internet Services

8

Participation in 6bone != belief that IPv6 is the solution to the problems
of today.

After all, some of us like hallucinogenic hobbies.

-dorian

9

phil@charon.milepost.com (Phil Howard) writes:

The transition to IPv6 is clearly going to have some difficulties. We are
waiting on:

1. Network equipment, with translation

2. End user software

3. Address space assignment

nice list.

IPv6-only space is of less value than IPv4-private space until IPv6
becomes at least fully routeable over the Internet. So the backbone
networks are going to have to take the lead to make it happen. Even
when it is routeable, it has to work on all the ends, which will thus
have to have translations to make their IPv4 space appear as IPv6sub4
space.

The best workable scenario I can see so far is one where IOS and other
routing software includes translation between IPv4 and IPv6

IOS IPv6 prototype does include that facility. It translates to and from
an arbitrary v4 network and an arbitrary v6 network.

Something is thus needed to encourage customers to move into IPv6 even
when it is fully routeable.

That is really the key issue... because even with IPv6 NAT (protocol
translation) working, IPv6 is as actractive as using IPv4 NAT, unless
it brings some value added to the end customers... The potential
advantage i see is autoconfiguration support. But DHCP can actually
do the same job reasonably well.

But just having IOS translating IPv4 <-> IPv6s4 is not enough.

Agreed.

We will need to manage the new IPv6 network. All the various tools we
use will need to understanding IPv6 and how it it configured on the
network. Routing will have to work right even during the transition
to this, which means BGP4v6 has to be there capable of understanding
IPv6 space at some point in time.

BGP4 + Multiprotocol Extensions is able to do the job. And it is working
resonably well...

Routing issues will become different in IPv6.

How ?

If IPv6 allocations will have varying sizes like CIDR, then we might
continue to have issues of size based route filtering. OTOH, with the
right methods of allocating IPv6 space, no one should ever have to come
back to get more space. Eventually that should mean fewer routes as
IPv4/IPv6s4 closes down. Route filtering should be encouraged on IPv4
space and prohibited on IPv6 space, at that point, IMHO.

I don't think i really understand your point here....

The only "difference" when it comes to routing information i can think off
is that in IPv6 there isn't suppose to be address ownership (which creates
holes into CIDR blocks)... but it seems to me that the same policy is
being adopted for IPv4.

  Pedro.

10

Bad model. I said this years ago.

IPng needs to have enough *prefix* length that every autonomous system
currently in existance or which will come into existance during its lifetime
can have a *unique*, *single* prefix.

Then the whole address ownership issue becomes moot - each ASN becomes a
prefix (heh, now that's novel - why not just use the ASN - duh!) and the
remaining space (define it as 32 bits for backward compatibility reasons
with IPv4) is private to the ASN.

If you change ASNs as a customer, it is between you and the new provider
whether you need to renumber - the rest of the world *DOES NOT CARE*.

What this leads to is a registry system (one or more) for the 32-bit
suffixes in which you form "colloquial" memberships, ensuring uniqueness
among competing ASNs *as long as both ASNs subscribe to the same registry*.

But membership is VOLUNTARY; you give up nothing except possibly the ability
to allow people to join your ASN without renumbering if you don't belong.

Right now membership in these registries is MANDATORY; the network breaks if
you choose random 32-bit integers and masks and announce them. We can fix
this if we think for more than 2 nanoseconds before doing something stupid
(again).

If you want to connect to an ASN which is *NOT* part of your colloquial
group, that's fine too -- but you might need to renumber in that case (or
perhaps not - 32 bits is still quite large).

With each ASN having 32 bits of *private* address space, the IP space becomes
effectively infinite, and the route table size is fixed at one entry per ASN.

The best of both worlds.

This is also, by the way, trivially backward compatible (heh, what a concept);
bitwise masking provides all you need to translate between local and global
address formats (these operations are extremely fast, and typically
single-instruction-cycle in duration on modern processors). Hardware
bit-slice assist on interface boards make it cheap and feasible even at
wire rates to translate at the boundaries of an ASN both inbound and
outbound.

This kind of logical design, of course, cannot be allowed to happen within
the realm of the Internet, which is why we'll never see it in our lifetime.

It never ceases to amaze me how people will ignore the obvious solutions to
problems like this.

11

Karl Denninger <karl@Mcs.Net> writes:

IPng needs to have enough *prefix* length that every autonomous system
currently in existance or which will come into existance during its lifetime
can have a *unique*, *single* prefix.

This has the advantage of maximizing site aggregation,
however it has the disadvantage of scaling badly with
respect to the number of sites.

Then the whole address ownership issue becomes moot - each ASN becomes a
prefix (heh, now that's novel - why not just use the ASN
- duh!)

Sure, but the problem is not now who deserves a /19 but
who deserves an ASN. Moreover, there is no plan in place
for a hierarchical distribution of AS numbers, and ASes
are not laid out very hierarchically (or in any kind of
useful order) right now.

If a very strict limit were placed on the number of ASes
in this type of Internet, then distributing connectivity
maps likely would be tractable; this leads into
discussions about a global link-state routing protocol,
some of which happen from time to time for other reasons.

However, if you are not prepared to refuse to give out AS
numbers to anyone who wants one, you will run into the
same political problems as refusing to give out
provider-independent addresses to anyone who wants some.

Alternatively, if you provide a mechanism for aggregation
of ASes (and don't go mad in the process), thus implying
hierarchical routing, then your idea is workable, except
that suddenly there is no difference between the semantics
of your ASN+IPADDR and the IPv6 provider-based addressing
scheme. The big difference would be in the requirement
that only a fixed-size field be routed upon, which is very
much like imposing prefix-length filtering on IPv6
addresses.

The only known means for any IP-like protocol to scale to
complex topologies is hierarchical routing. This imposes
constraints on address assignment. There is no way around
these constraints other than abandoning topological
complexity or routing efficiency.

I believe that the functionality you are trying to achieve
is having a system in which renumbering is unnecessary
when a change is made in the physical topology, or where
address uniqueness is not guaranteed. NAT is currently the
appropriate technology to be used in both cases, and has
the advantage that no NAT-friendly deployed software needs
to be changed to talk a new protocol.

This kind of logical design, of course, cannot be allowed to happen within
the realm of the Internet, which is why we'll never see it in our lifetime.

Why not? NATs delineate two addressing scopes, and
protocol translating NATs are an extension of this. Pablo
Bevilacqua has already pointed out an existing
implementation from OFRV.

There is no reason why a series of NATs which each border
on different IPv4 addressing scopes cannot share a common
protocol and addressing region on the "outside" of each of
these IPv4 addressing scopes. That is, among a group of
NATs there is no strict need to run IPv4, so long as
straightforward translations into and out of the local
IPv4 addressing scopes are possible. Consequently, there
is no reason why some part of the Internet cannot test or
even deploy your hypothetical protocol.

Personally I encourage you to go for it; there is alot we
need to learn about what ought to be "in the middle" to
keep the Internet permanently scalable, and the concept of
protocol translating NATs needs some thorough deployment
experience.

  Sean.

12

Karl Denninger <karl@Mcs.Net> writes:

> IPng needs to have enough *prefix* length that every autonomous system
> currently in existance or which will come into existance during its lifetime
> can have a *unique*, *single* prefix.

This has the advantage of maximizing site aggregation,
however it has the disadvantage of scaling badly with
respect to the number of sites.

Not if you define "site" as "one network owned by an entity or related set
of entities".

Of course, then what happens is that you have to revoke the multiple ASNs
that some providers have - which IMHO should NOT have been issued.

"Administrative convenience" isn't a valid reason to be issuing ASNs all
over the place. There is no *need* to do so - there may be a *want* to do
so, primarily because people don't want to carry their own customer's
traffic for the majority of the trip in even one direction (which IMHO is
baloney, but heh, that's just my point of view).

> Then the whole address ownership issue becomes moot - each ASN becomes a
> prefix (heh, now that's novel - why not just use the ASN
> - duh!)

Sure, but the problem is not now who deserves a /19 but
who deserves an ASN.

Anyone who connects to and exchanges routes with two or more other ASN
holders. If you're part of the mesh, then you need an identification
number to *BE* part of the mesh.

Moreover, there is no plan in place
for a hierarchical distribution of AS numbers, and ASes
are not laid out very hierarchically (or in any kind of
useful order) right now.

Not very relavent, really. Think about it - right now BGP4 uses the path
length as the first-order determinant. If you had one route entry for each
ASN, and only one, then By Golly, we'd have something like 5,000 prefixes in
the table right now.

Heh, anyone like the idea of being able to run on AGS+ platforms again and
other things with limited RAM and CPU power? Sure would be nice, wouldn't
it?

maps likely would be tractable; this leads into
discussions about a global link-state routing protocol,
some of which happen from time to time for other reasons.

Yep.

However, if you are not prepared to refuse to give out AS
numbers to anyone who wants one, you will run into the
same political problems as refusing to give out
provider-independent addresses to anyone who wants some.

Well, no. You give out AS numbers to anyone who is a member of the mesh.
By *definition* to be a mesh member you must exchange information with more
than one other party.

If you do, then you're a mesh member.

If you do not, then you are not.

Alternatively, if you provide a mechanism for aggregation
of ASes (and don't go mad in the process), thus implying
hierarchical routing, then your idea is workable, except
that suddenly there is no difference between the semantics
of your ASN+IPADDR and the IPv6 provider-based addressing
scheme.

Aggregation of ASNs is interesting, but I believe both unnecessary and
politically dangerous (for the same reason that I believe that aggregation
of IPv4 addresses now can be dangerous in that it can be used to restrain
trade).

The big difference would be in the requirement
that only a fixed-size field be routed upon, which is very
much like imposing prefix-length filtering on IPv6
addresses.

Yep. In fact it is *exactly* that; the fact that the high order bits are
defined as the ASN is an administrative convenience.

The only known means for any IP-like protocol to scale to
complex topologies is hierarchical routing.

One multiply-connected entity, one hierarchy. The requirement of multiple
connections is a natural limit to an explosion of hierarchies. Also,
with address space being effectively unlimited, there is no longer a reason
for people to persue this for any reason other than route exchange - it buys
you NOTHING.

See my other posting regarding low-order-bit confederation agreements to
allow full portability at the *customer* level without people needing to
have their own ASN. This instantly removes the argument for and desire to
obtain ASNs for what some people now call "vanity" purposes (and what I
call a survival requirement).

This imposes
constraints on address assignment. There is no way around
these constraints other than abandoning topological
complexity or routing efficiency.

The point is that constraints on an unlimited resource which *STILL* looks
unlimited after the constraint is applied are null operations as far as the
external impact goes. This is why the split that I've described works and
doesn't really inconvenience (or screw) anyone.

I believe that the functionality you are trying to achieve
is having a system in which renumbering is unnecessary
when a change is made in the physical topology, or where
address uniqueness is not guaranteed.

Correct. I am trying to achieve a level playing field.

NAT is currently the
appropriate technology to be used in both cases, and has
the advantage that no NAT-friendly deployed software needs
to be changed to talk a new protocol.

NAT is *not* currently the appropriate technology because people have
designed brain-dead protocols which encode endpoint addresses INSIDE THE
PAYLOAD REGION of datagrams. This requires all kinds of special-casing.

That the IETF has *approved* such protocols, and continues to do so, is a
huge problem. In fact it is THE problem which makes NAT unworkable in the
general sense.

Unfortunately, one of those protocols is one of the earliest - FTP.

But its not the only abuser by any stretch of the imagination.

There is no reason why a series of NATs which each border
on different IPv4 addressing scopes cannot share a common
protocol and addressing region on the "outside" of each of
these IPv4 addressing scopes. That is, among a group of
NATs there is no strict need to run IPv4, so long as
straightforward translations into and out of the local
IPv4 addressing scopes are possible. Consequently, there
is no reason why some part of the Internet cannot test or
even deploy your hypothetical protocol.

Personally I encourage you to go for it; there is alot we
need to learn about what ought to be "in the middle" to
keep the Internet permanently scalable, and the concept of
protocol translating NATs needs some thorough deployment
experience.

  Sean.

We need to fix the broken protocol problem too Sean... Fix that and
translation at boundaries becomes VERY workable. In fact, if we fix
that I will agree that such a reference implementation is worth my
effort and will see what I can code up for precisely this purpose.

13

The legitimate reason for multiple ASs is when separate parts of the
network have very different routing. For example, let's say a big
company on a single continent has one prefix for their whole network.
They then expand to another continent. If they use address space under
that same prefix, they wind up either having the transcontinental link
large enough to support all of the transcontinental traffic for that
prefix, or they wind up routing traffic across a transcontinental link
and back when it didn't have to. Now, if they get a different prefix for
the new continent, traffic will take the optimal path.

This is no different than inefficiencies caused by the current
implementation. Generally, traffic gets to the destination AS as quickly
as possible and then finds its way to the destination host from there.
However, there may be a shorter path involving a different entry point
into the destination AS.

With the larger address space of IPv6, there is the capacity for an arbitrary
number of levels in the hierarchy. Obviously, making use of those levels
to improve on the inefficiency noted above will require more routes to be
propagated, so there is a tradeoff. I don't think we want either a routing
table contaning one route per AS nor do we want one containing every subnet
with each AS. Ideally, we would choose some level of detail between those
extremes, using multiple routes per AS only where they actually improve
routing.

John Tamplin Traveller Information Services
jat@Traveller.COM 2104 West Ferry Way
205/883-4233x7007 Huntsville, AL 35801

14

This I agree with.

We could, for example, define a "country code" set of bits in the high-order
field of the "provider" area. For example, from the LEFT side of the
IPv6 address (128 bits wide):

Bits
0 - 8 - Reserved for when interplanetary travel and subspace
    communication become functional (to define "Galaxies" -
    this appeases Jim Fleming and Star Trek types :slight_smile: :slight_smile:

9 - 17 - Country code (1024 countries; there's only so much land
    on the planet, and we're well under that now I believe :slight_smile:

18 - 47 - Reserved for future use

48 - 63 - Provider's AS Number

======================== Boundary of externally-visible address space
        from a provider (ie: you route to a /64 level)
        Everything below this point "belongs" to the
        provider.

64 - 95 - Reserved for internal assignment once IPv4 direct backward
    mapping is no longer relavent (or desired).

96 - 127 - Existing IPv4 mapping, 32 bits, provider dependant and
    internal.

Now, think what this does:

1) Any address for a level beyond where you are only needs to seek
  the closest exit point (ie: if you're in "galaxy" 0, and you get
  a packet for "galaxy 1", you don't need to look at or care about
  the rest - find the closest "galaxy 1 exit".

2) Routing at the *country interconnect level* only requires a lookup
  of 1024 possible destinations - easily done with a direct index
  table (which is a *ONE INSTRUCTION* decision in core routers).
  Multinational providers use bits 9 - 63 to make routing decisions
  while single-nation providers only use bits 48-63 and have a
  1024-entry "forward to the best exit table" for bits 9-17. This
  also permits implementation of TOS and QOS restrictions based on
  destination or source country, which is something we're going to
  have to face sooner or later.

3) Routing between ASNs is a 16-bit issue (ie: 65,536 ASNs within a
  country, which is the MAXIMUM number of entities in one country -
  and if this isn't enough, encroach on the "reserved" areas). The
  initialization sequence for the Son-of-BGP4 communicates the size
  of this field so that as it grows its seamless to implement.

4) IPv4 space maps *directly* onto this at a low level, preserving
  the option of FULL backward compatibility.

5) Once we don't *CARE* about backward IPv4 mapping every doorbell,
  toaster, car, and wristwatch within a PROVIDER can be accomodated
  in 64 bits!

This solves all of the allocation problems, GREATLY simplifies routing to
the point that a $2,000 router now can effectively be a multi-homed device
(since the "thinking" part just got incredibly simple) and makes convergence
a non-issue.

A gateway device to map between this layout as a backbone level transport
and existing IPv4 is trivial.

Confederations of providers can decide to cooperate on the bit 96 - 127
address range; if they DO cooperate then you have inter-provider portability.
If not, then you still *might* have it, depending on whether the numbers you
were using have been assigned to someone else on the new provider you're
moving to or not.

15

Yo Karl!

16

Karl Denninger wrote:

We could, for example, define a "country code" set of bits in the high-order
field of the "provider" area. For example, from the LEFT side of the
IPv6 address (128 bits wide):

Have little experience in international networking, ain't we?

Take Russian Internet for example: five largest ISPs all
have separate dedicated links to _different_ European and
North American backbones.

This seems to be a typical picture all around the world.
European connectivity is particularly convoluted.

--vadim

17

Take Russian Internet for example: five largest ISPs all
have separate dedicated links to _different_ European and
North American backbones.

This seems to be a typical picture all around the world.
European connectivity is particularly convoluted.

For years, Thailand had for separate competing connections to AlterNet. I
loved it, as it demonstrated a minimum market price of ego.

Of course, there are no analogs to this in North American locales. Right.

randy

18

This illustrates my earlier comments about why
geographically-based allocation schemes are not
ideal.

- paul

19

"John A. Tamplin" <jat@traveller.com> writes:

With the larger address space of IPv6, there is the capacity for an arbitrary
number of levels in the hierarchy.

"Arbitrary" is overstating it, considering that the
addresses are fixed-length fields.

Obviously, making use of those levels to improve on the
inefficiency noted above will require more routes to be
propagated, so there is a tradeoff.

Kleinrock and Kamoun ("Stochastic Performance Evaluation
of Hierarchical Routing for Large Networks") demonstrated
that the optimal number of levels in a hierarchically
addressed Internetwork with k routers is ln k, and so e ln
k routing entries are needed per router to provide routing
with acceptable amounts of non-optimality. Consequently,
a scheme which can provide for this optimal number of
levels also neatly bounds the amount of routing
information necessary for nearly optimal routing.

A fixed address length clearly can be a scaling constraint
on the number of levels that can be encoded into the
address itself, and one that is too short, therefore,
naturally requires an Internet to carry larger numbers of
routes. (One that is too long is merely wasteful of
resources).

Note, however, that the important thing is that such a
scalable Internetwork is _hierarchically addressed_; this
constraint is necessary to make any Internetwork scale,
independent of the routing protocol(s) used.

I don't think we want either a routing table contaning
one route per AS

ASes are an EGPism, and the deaths of EGP and its
cosmetically improved descendents are long overdue.

Despite all the problems with BGP, at least with respect to
addressing the problem is not in the protocol, but in the
need for hierarchical routing.

  Sean.

20

Vadim Antonov <avg@pluris.com> writes:

European connectivity is particularly convoluted.

You have no idea...

  Sean. (eyeopening experiences galore)