Re: Data Center Wiring Standards

[Frank Coluccio]

I would add to the recommendations already stated by Mark and John the
folllowing: Depending on the dimensions of the colo in question and the length 
of
the cabling runs you plan to install, take note of the distance limitations of
STP for DS1 signals and the in-house coaxial connections for DS3 signals and
higher, which are (were) governed by ANSI/Bellcore, the last time I looked.
Fiber, likewise, must be coordinated with network element interfaces (GBICs, ST,
etc.) and here again distance is a major consideration. The latter may become an
issue in large structures, or in the event that you plan to run media between
buildings, or if you plan to interconnect with service providers at the f-o 
level
(Layer1).

For your optical media and connection hardware (patch panels, raceways, etc.),
have a long hard talk with at least two reputable fiber optic cable suppliers
(e.g., Corning, CommScope, Sumitomo, etc.) and develop an understanding about 
the
limitations and advantages of the various s-m and m-m options you have available
to you, per the types of solutions you need to implement and the distances they
dictate. Incoming fiber from the street (dark fiber providers, included) will be
single-mode, primarily, but the preponderance of your in-house cabling between
switches, routers and servers, if fiber distances are indicated, will be
multi-mode, requiring a different patch bay selection. 

Where distances permit (<100 meter channels) UTP should suffice for Ethernet
speeds up to 10Gb/sec now, with 10Gb/sec (10GBASE-T) ratified only recently (I'm
quite certain), but I suggest reading the following article from Cabling
Installation & Maintenance Magazine, just the same. 

http://tinyurl.com/mrack

Note, Cat5e and vanilla Cat6 will not suffice (perhaps a Cat6A will, not sure at
this stage, but do your homework before purchasing anyone's Cat7)  for 10GbE (it
may work, but your hardware vendors will not honor warranties when problems
arise), so be prepared to make some long range planning decisions in coming to
terms with a cabling plant that's going to last you a while. HTH.

Frank A. Coluccio
DTI Consulting Inc.
212-587-8150 Office
347-526-6788 Mobile

On Fri Sep  8 23:31 , John L Lee  sent:

>
>
>
>  
>  
>
>
>Rick,
>
>
>
>The organization and standards you are looking for are:
>
>
>
>BICSI  -  http://www.bicsi.org/ and TIA/EIA 568 et al for structured
>cabling design for low voltage distribution.
>
>
>
>The BICSI organization has training and certification for RCDD
>Registered Communications Distribution Designer
>
>
>
>A BICSI article that is on there web site about data center design is
>http://www.bicsi.org/Content/Files/PDF/link2006/Kacperski.pdf.
>
>
>
>TIA/EIA 568(ab) how ever many they are up to discuss structured cabling
>design for UTP/STP/fiber/coax including patch cables single and multi
>pair UTP/STP/fiber  patch panels,  HVAC control, fire system control
>and security systems.
>
>
>
>John (ISDN) Lee 
>
>
>
>
>
>
>
>Rick Kunkel wrote:
>
>
>  Heya folks,
>
>I hope this is on-topic.  I read the charter, and it falls somewhere along
>the fuzzy border I think...
>
>Can anyone tell me the standard way to deal with patch panels, racks, and
>switches in a data center used for colocation?  I've a sneaking suspicion
>that we're doing it in a fairly non-scalable way.  (I am not responsible
>for the current method, and I think I'm glad to say that.)  Strangely
>enough, I can find like NO resources on this.  I've spent the better part
>of two hours looking.
>
>Right now, we have a rack filled with nothing but patch panels.  We have
>some switches in another rack, and colocation customers scattered around
>other racks.  When a new customer comes in, we run a long wire from their
>computer(s) and/or other device(s) to the patch panel.  Then, from the
>appropriate block connectors on the back of the panel, we run another wire
>that terminates in a RJ-45 to plug into the switch.
>
>Sounds bonkers I think, doesn't it?
>
>My thoughts go like this:  We put a patch panel in each rack.  Each of
>these patch panels is permanently (more or less) wired to a patch panel in
>our main patch cabinet.  So, essentially what you've got is a main patch
>cabinet with a patch panel that corresponds to a patch panel in each other
>cabinet.  Making connection is cinchy and only requires 3-6 foot
>off-the-shelf cables.
>
>Does that sound more correct?
>
>I talked to someone else in the office here, and they believe that they've
>seen it done with a switch in each cabinet, although they couldn't
>remember is there was a patch panel as well.  If you're running 802.1q
>trunks between a bunch of switches (no patch-panels needed), I can see
>that working too, I suppose.
>
>Any standards?  Best practices?  Suggestions?  Resources, in the form of
>books, web pages, RFCs, or white papers?
>
>Thanks!
>
>Rick Kunkel
>
>
>
>  
>
>
>

Re: Data Center Wiring Standards

[John L Lee]

Rick,

The organization and standards you are looking for are:

BICSI  -  http://www.bicsi.org/ and TIA/EIA 568 et al for structured
cabling design for low voltage distribution.

The BICSI organization has training and certification for RCDD
Registered Communications Distribution Designer

A BICSI article that is on there web site about data center design is
http://www.bicsi.org/Content/Files/PDF/link2006/Kacperski.pdf.

TIA/EIA 568(ab) how ever many they are up to discuss structured cabling
design for UTP/STP/fiber/coax including patch cables single and multi
pair UTP/STP/fiber  patch panels,  HVAC control, fire system control
and security systems.

John (ISDN) Lee 



Rick Kunkel wrote:

  Heya folks,

I hope this is on-topic.  I read the charter, and it falls somewhere along
the fuzzy border I think...

Can anyone tell me the standard way to deal with patch panels, racks, and
switches in a data center used for colocation?  I've a sneaking suspicion
that we're doing it in a fairly non-scalable way.  (I am not responsible
for the current method, and I think I'm glad to say that.)  Strangely
enough, I can find like NO resources on this.  I've spent the better part
of two hours looking.

Right now, we have a rack filled with nothing but patch panels.  We have
some switches in another rack, and colocation customers scattered around
other racks.  When a new customer comes in, we run a long wire from their
computer(s) and/or other device(s) to the patch panel.  Then, from the
appropriate block connectors on the back of the panel, we run another wire
that terminates in a RJ-45 to plug into the switch.

Sounds bonkers I think, doesn't it?

My thoughts go like this:  We put a patch panel in each rack.  Each of
these patch panels is permanently (more or less) wired to a patch panel in
our main patch cabinet.  So, essentially what you've got is a main patch
cabinet with a patch panel that corresponds to a patch panel in each other
cabinet.  Making connection is cinchy and only requires 3-6 foot
off-the-shelf cables.

Does that sound more correct?

I talked to someone else in the office here, and they believe that they've
seen it done with a switch in each cabinet, although they couldn't
remember is there was a patch panel as well.  If you're running 802.1q
trunks between a bunch of switches (no patch-panels needed), I can see
that working too, I suppose.

Any standards?  Best practices?  Suggestions?  Resources, in the form of
books, web pages, RFCs, or white papers?

Thanks!

Rick Kunkel



  

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[John L Lee]

Chris,

The first item they need is a Network Engineer.

You do not have actual IP addresses for servers you have DNS entries.
In my non legal opinion the individual filling suit is out money
because of there lack of understanding of  DNS entries versus IP
addresses. You can resolve thousands of web sites to one IP address if
you want to or get another block of IP addresses from ARIN and resolve
the other addresses to the newly assigned addresses. It appears from
the filing that they do not understand how DNS works since with an
appropriately designed zone structure there would be no issues.

This lawsuit is about the stupidity of the plaintiff and not about IP
address management. If any organization owns the IP addresses it is the
registries and they only lease them out to organizations for a nominal
fee to provide order and security for the Internet. ICANN for other
issues and ARIN for addresses bend over backwards to have large ISPs
and multinationals go through the same short process as any other
requester of IP addresses and have only one policy. And if you have
ever attended an ARIN meeting point out of the 100 to several hundred
high opinionated individuals who attend which ones control it for their
own economic benefit.

Send this legal team a copy of Comer's books on TCP/IP and Cricket
Liu's book on DNS and BIND. I take the Comer books back they would not
understand them so give them Uyless Black's books they are more
clueless friendly.

John (ISDN) Lee



Chris Jester wrote:

  

I am looking for anyone who has input on possibly the largest case
regarding internet numbering ever. This lawsuit may change the way
IP's are governed and adminstered. Comments on or off list please.
Anyone have experiences like are said in the lawsuit? I would love
to know if this is true or not.  Anyone with negative ARIN experiences
that relate to the lawsuit, please let me know, thanks!

For thos interested, you may read this lawsuit here:
http://72.14.209.104/search?q=cache:44uxmnEmJVkJ:www.internetgovernance.org/pdf/kremen.pdf+Kremen+Vs+ARIN&hl=en&gl=us&ct=clnk&cd=1

Or google for Kremen VS Arin

Chris Jester
Suavemente, INC.
SplitInfinity Networks
619-227-8845

AIM: NJesterIII
ICQ: 64791506




Chris Jester
Suavemente, INC.
SplitInfinity Networks
619-227-8845

AIM: NJesterIII
ICQ: 64791506

NOTICE - This e-mail and any files transmitted with it are confidential and
are only for the use of the person to whom they are addressed. If you are
not the intended recipient you have received this e-mail in error. Any use,
dissemination, forwarding, printing, copying or dealing in any way
whatsoever with this e-mail is strictly prohibited. If you have received
this e-mail in error, please reply immediately by way of advice to us. It is
the addressee/recipient duty to virus scan and otherwise test the
information provided before loading onto any computer system. Suavemente,
INC.
does not warrant that the information is free of a virus or any other defect
or error. Any views expressed in this message are those of the
individual sender, except where the sender specifically states them to be
the views of Suavemente, INC.


  

Re: Data Center Wiring Standards

[Bill Sehmel]

Rick Kunkel wrote:

Heya folks,

I hope this is on-topic.  I read the charter, and it falls somewhere along
the fuzzy border I think...

Can anyone tell me the standard way to deal with patch panels, racks, and
switches in a data center used for colocation?  I've a sneaking suspicion
that we're doing it in a fairly non-scalable way.  (I am not responsible
for the current method, and I think I'm glad to say that.)  Strangely
enough, I can find like NO resources on this.  I've spent the better part
of two hours looking.

Right now, we have a rack filled with nothing but patch panels.  We have
some switches in another rack, and colocation customers scattered around
other racks.  When a new customer comes in, we run a long wire from their
computer(s) and/or other device(s) to the patch panel.  Then, from the
appropriate block connectors on the back of the panel, we run another wire
that terminates in a RJ-45 to plug into the switch.

Sounds bonkers I think, doesn't it?

My thoughts go like this:  We put a patch panel in each rack.  Each of
these patch panels is permanently (more or less) wired to a patch panel in
our main patch cabinet.  So, essentially what you've got is a main patch
cabinet with a patch panel that corresponds to a patch panel in each other
cabinet.  Making connection is cinchy and only requires 3-6 foot
off-the-shelf cables.

Does that sound more correct?

I talked to someone else in the office here, and they believe that they've
seen it done with a switch in each cabinet, although they couldn't
remember is there was a patch panel as well.  If you're running 802.1q
trunks between a bunch of switches (no patch-panels needed), I can see
that working too, I suppose.

Any standards?  Best practices?  Suggestions?  Resources, in the form of
books, web pages, RFCs, or white papers?

Thanks!

Rick Kunkel

  
Ideally from each core router would go to a two distribution-a switch 
(Cat 4900 or something similar), from both dist-a switch then go to two 
bigger distribution (dist-b) switches (cat 6500 etc) Then from each 6500 
go to there own patch panels. Then from the two patch panels run a 
cables to access level (2900's etc) switches in each rack / shelf. This 
way you have full redundancy in each shelf for your co-located / 
dedicated customers.




My .02 cents


-Bill Sehmel


--

Bill Sehmel   -   [EMAIL PROTECTED]   -- 1-703-288-3081
Systems Administrator,   HopOne Internet Corp.  DCA2 NOC
Bandwidth & full range of carrier/web host colo + networking
services: http://www.hopone.netASN 14361

Re: Data Center Wiring Standards

[Mark Foster]

My thoughts go like this:  We put a patch panel in each rack.  Each of
these patch panels is permanently (more or less) wired to a patch panel in
our main patch cabinet.  So, essentially what you've got is a main patch
cabinet with a patch panel that corresponds to a patch panel in each other
cabinet.  Making connection is cinchy and only requires 3-6 foot
off-the-shelf cables.

Does that sound more correct?

I talked to someone else in the office here, and they believe that they've
seen it done with a switch in each cabinet, although they couldn't
remember is there was a patch panel as well.  If you're running 802.1q
trunks between a bunch of switches (no patch-panels needed), I can see
that working too, I suppose.

Any standards?  Best practices?  Suggestions?  Resources, in the form of
books, web pages, RFCs, or white papers?


Theres a series of ISO Standard for data cabling but nothing is yet set in 
stone around datacentres.  I think the issue of Standards in datacentres 
was touched on here some time back?


Ok, a quick google later,

TIA-942 Telecommunications Infrastructure Standards for Data Centres 
covers off a lot of the details. Its pretty new and I don't know if its 
fully ratified yet?


I quote...

--8<--
Based on existing cabling standards, TIA-942 covers cabling distances, 
pathways and labeling requirements, but also touches upon site selection, 
demarcation points, building security and electrical considerations. As 
the first standard to specifically address data centres, TIA-942 is a 
valuable tool for the proper design, installation and management of data 
centre cabling.


The standard provides specifications for pathways, spaces and cabling 
media, recognizing copper cabling, multi-mode and single-mode fiber, and 
75-ohm coaxial cable. However, much of TIA-942 deals with facility 
specifications. For each space within a data centre, the standard defines 
equipment planning and placement based on a hierarchical star topology for 
backbone and horizontal cabling. The standard also includes specifications 
for arranging equipment and racks in an alternating pattern to create 
ìhotî and ìcoldî aisles, which helps airflow and cooling efficiency.


To assist in the design of a new data centre and to evaluate the 
reliability of an existing data centre, TIA-942 incorporates a tier 
classification, with each tier outlining guidelines for equipment, power, 
cooling and redundant components. These guide-lines are then tied to 
expectations for the data centre to maintain service without interruption.


--8<--

The source url for the above was 
http://www.networkcablingmag.ca/index.php?option=com_content&task=view&id=432&Itemid=2. 
You may like to see if you can track down a copy of the referenced 
standard.



From my personal POV -

You have a couple of options depending on your switching infrastructure 
and required cabling density - and bandwidth requirements.  One way would 
be to have a decent switch at the top of each cabinet along with a Fibre 
tie to your core patch / switching cabinet.  All devices in that rack feed 
into the local switch, which could be VLAN'd as required to cater for ILO 
or any other IP management requirements.  Uplink would be a trunk of 
1000SX, 1000LX, MultiLink Trunk combinations of same, or perhaps even 
10Gig Fibre.


The other option would be to preconfigure each rack with a coupla 
rackunits of fixed copper or fibre ties to a core cabinet and just patch 
things around as you need to.  Useful if you are in a situation where 
bringing as much as possible direct into your core switch is appropriate, 
and cheaper from a network hardware pov - if not from a structure cabling 
pov.


Good luck. I know what a prick it is to inhereit someone elses shoddy 
cable work - I find myself accumulating lots of after-hours overtime, 
involving essentially ripping out everything and putting it all back 
_tidily_ - and hoping that I don't overlook some un-documented 
'feature'...


Mark.

Re: Data Center Wiring Standards

[William Yardley]

[ Disclaimer - my experience is as someone who has setup lots of racks,
dealt with a number of colocation facilities and cabling contractors.
However, I haven't ever run a colo. ]

On Fri, Sep 08, 2006 at 05:36:09PM -0700, Rick Kunkel wrote:

> Can anyone tell me the standard way to deal with patch panels, racks,
> and switches in a data center used for colocation?
 
> Right now, we have a rack filled with nothing but patch panels.  We
> have some switches in another rack, and colocation customers scattered
> around other racks.  When a new customer comes in, we run a long wire
> from their computer(s) and/or other device(s) to the patch panel.
> Then, from the appropriate block connectors on the back of the panel,
> we run another wire that terminates in a RJ-45 to plug into the
> switch.

This way of doing things *can* be done neatly in some cases - it really
depends on how you have things setup, your size, and what your
customers' needs are.

For large carrier neutral places like Equinix, Switch and Data, etc.,
where each customer usually has a small number of links coming into
their cage, and things are pretty non-standard (i.e., customers have
stuff other than a few ethernet cables going to their equipment), that's
pretty much what they do - run a long cable through overhead cable
trough or fiber tray, and terminate it in a patch panel in the
customer's rack.

> My thoughts go like this:  We put a patch panel in each rack.  Each of
> these patch panels is permanently (more or less) wired to a patch
> panel in our main patch cabinet.  So, essentially what you've got is a
> main patch cabinet with a patch panel that corresponds to a patch
> panel in each other cabinet.  Making connection is cinchy and only
> requires 3-6 foot off-the-shelf cables.

This is a better way to do it IF your customers have pretty standard
needs. One facility I've worked at has 6 cables bundled together (not 25
pr cable, but similar - 6 cat5 or cat6 cables bundled within some sort
of jacket), going into a patch panel. 25 pair or bundled cabling will
make things neater, but usually costs more.

Obviously, be SUPER anal retentive about labelling, testing, running
cables, etc., or it's not worth doing at all. Come up with a scheme for
labelling (in our office, it's "a.b.c where a is the rack number, b is
the rack position, and c is the port number) and stick to it. Get a
labeller designed for cables if you don't already have one (a Brady,
industrial P-Touch, Panduit, or something similar). Make sure there is a
standard way for everything, and document / enforce the standard.
Someone has to be the cable n**i (does that count as a Godwin?) or
things will get messy fast.

If you're doing a standard setup to each rack, hire someone to do it for
you if you can afford it. It will be expensive, but probably worth it
unless you're really good (and fast) at terminating cable.

Either way, use (in the customer's rack) one of the patch panels that's
modular, so you can put a different kind of connector in each slot. That
gives you more flexibility later.

In terms of whether patch panels / switches should be mixed in the same
rack; opinions differ. It's of course difficult to deal with terminating
patch panels when there are also big fat switches in the same rack.

I've usually done a mix anyway, but for your application, it might be
better to alternate, running the connections sideways.

Invest in lots of cable management, the bigger, the better. I assume you
already have cable management on these racks? 

I like the Panduit horizontal ones, and either the Panduit vertical
ones, or the CPI "MCS" ones. If you're doing a new buildout, or can
start a new set of racks, put extra space between them and do 10" wide
cable management sections (or bigger).

I can give you some suggestions in terms of vendors and cabling outfits,
though most of the people I know of are in the Southern California area.

> I talked to someone else in the office here, and they believe that
> they've seen it done with a switch in each cabinet, although they
> couldn't remember is there was a patch panel as well.

Ok, so if most of your customers have a full rack or half rack, I would
suggest not putting a switch in each rack. In that case, you should
charge them a port fee for each uplink, which should encourage them to
use their own networking equipment.

Now if most of your customers are using < 1/2 rack, and aren't setting
up their own network equipment, and you're managing everything for them,
then you might want to put 1 48 port / 2 24 port switch in each
individual rack, with two uplinks from some central aggregation switches
to each.

I really don't think you want more than 4-6 cables going to any one
rack.

Maybe you can clarify your typical customer setup?

> Any standards?  Best practices?  Suggestions?  Resources, in the
> form of books, web pages, RFCs, or white papers?

I think the best thing is just to look around as much as possible, and
then see what wo

Re: Data Center Wiring Standards

[Ingo Flaschberger]

Hello Rick,


Does that sound more correct?

I talked to someone else in the office here, and they believe that they've
seen it done with a switch in each cabinet, although they couldn't
remember is there was a patch panel as well.  If you're running 802.1q
trunks between a bunch of switches (no patch-panels needed), I can see
that working too, I suppose.


Thats the best solution I think.
Less cables, less work for precabling.
Build 1gige or 2x1gige fiber uplinks.
Perhaps wheels on the racks (then you can play google).

You have check what switches you use in the racks and in the core.
Number of vlans supported is the main goal.
Perhaps some hp procurve in the racks and some real coreswitches in the 
backbone.


When you reach 4096 vlans you could use vlan in vlan or mpls to grow more.

Kind regards,
Ingo Flaschberger

Re: TCP receive window set to 0; DoS or not?

[Jim Shankland]

Travis Hassloch <[EMAIL PROTECTED]> writes:
> The part where it becomes a DoS is when they tie up all the listeners
> on a socket (e.g. apache), and nothing happens for several minutes until
> their connections time out.  Whether intentional or not, it does have
> a negative effect.

Ah, that makes sense.  I was assuming a deliberate attack, which is
not actually implicit in the term "DoS".  A deliberate denial of
service is not made easier by shrinking the window.  But an implementation
that advertises a 0 window in lieu of sending FIN or RST can certainly
deny service inadvertently by tying up resources that should have been
freed.

Jim Shankland

Data Center Wiring Standards

[Rick Kunkel]

Heya folks,

I hope this is on-topic.  I read the charter, and it falls somewhere along
the fuzzy border I think...

Can anyone tell me the standard way to deal with patch panels, racks, and
switches in a data center used for colocation?  I've a sneaking suspicion
that we're doing it in a fairly non-scalable way.  (I am not responsible
for the current method, and I think I'm glad to say that.)  Strangely
enough, I can find like NO resources on this.  I've spent the better part
of two hours looking.

Right now, we have a rack filled with nothing but patch panels.  We have
some switches in another rack, and colocation customers scattered around
other racks.  When a new customer comes in, we run a long wire from their
computer(s) and/or other device(s) to the patch panel.  Then, from the
appropriate block connectors on the back of the panel, we run another wire
that terminates in a RJ-45 to plug into the switch.

Sounds bonkers I think, doesn't it?

My thoughts go like this:  We put a patch panel in each rack.  Each of
these patch panels is permanently (more or less) wired to a patch panel in
our main patch cabinet.  So, essentially what you've got is a main patch
cabinet with a patch panel that corresponds to a patch panel in each other
cabinet.  Making connection is cinchy and only requires 3-6 foot
off-the-shelf cables.

Does that sound more correct?

I talked to someone else in the office here, and they believe that they've
seen it done with a switch in each cabinet, although they couldn't
remember is there was a patch panel as well.  If you're running 802.1q
trunks between a bunch of switches (no patch-panels needed), I can see
that working too, I suppose.

Any standards?  Best practices?  Suggestions?  Resources, in the form of
books, web pages, RFCs, or white papers?

Thanks!

Rick Kunkel

Re: TCP receive window set to 0; DoS or not?

[Travis Hassloch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Shankland wrote:
> To address the "DoS" question, I don't see how this protocol violation
> enables a DoS attack.  More likely, it's simply somebody's buggy
> TCP stack misbehaving.  That "somebody" is unlikely to be Windows, MacOS,
> FreeBSD, or Linux.  My money is on some flavor of $50 NAT/"home router"
> box.

The part where it becomes a DoS is when they tie up all the listeners
on a socket (e.g. apache), and nothing happens for several minutes until
their connections time out.  Whether intentional or not, it does have
a negative effect.

It's insidious in that it leaves no traces in the application logs;
in particular, apache never logs anything because they never
complete a transaction (it logs when they finish).
- --
The whole point of the Internet is that different kinds of computers
can interoperate.  Every time you see a web site that only supports
certain browsers or operating systems, they clearly don't get it.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFAeGPPlSPhv5tocwRAgSVAJ4qGEo/aR4CMaBcnsu+H6DyGpN7iACfcMAM
FGvZWaAY2GYVSDLf37YUwbw=
=RZ/F
-END PGP SIGNATURE-

Re: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?

[Jack Bates]

Niels Bakker wrote:
Address space policy has always been the result of a community 
consensus. Just because that consensus has shifted over the years does 
not mean that older entries in some database have suddenly developed 
into property. All it means is that the community is very friendly for 
not applying the new rules retroactively.




The worst part of the filing was the fact that it asserted that by allowing the 
previous owner to retain ownership of the netblock, they were able to allocate 
addresses to customers and stay in business (as if they couldn't ask ARIN for 
more IP addresses).


The purpose of the transfer, if I read the filing correctly, was to give Kremen 
the right to force all routing of the block to stop to the various people using 
it to extort money out of them (based on the wording in the filing, that 
apparently is money Kremen lost). Many of the suballocated users of the netblock 
would probably have been innocent bystanders that are using a cheap ISP.


Of course, in reality, even with the transfer of the netblock, new allocations 
would have been requested and granted for networks requiring them. However, how 
many people would have been requested to pay or forced to immediately renumber? 
I've had to renumber a /18 when C&W decided to drop customers here. If they had 
forced them unroutable (claiming ownership) while I was trying to renumber, we 
wouldn't be questioning the status of IP addresses as property.



-Jack

Re: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?

[Joseph S D Yao]

On Fri, Sep 08, 2006 at 12:18:59PM -0700, David Schwartz wrote:
...
>   Even if you assume that allocations made by ARIN are not property, it's
> hard to argue that pre-ARIN allocations are not. They're not subject to
> revocation and their grant wasn't conditioned on compliance with policies.
...


I don't understand how you can assert this.  Use of IP addresses follows
the current policies, whatever they are.  They have no grandfathered
rights.

Oops, here I am sounding like I know something about lawyering.  ;-)  I
think we all need to either wait for the results, or if so moved, send
in amicus curiae briefs.  Not a lot else we can do, since few if any of
us are lawyers, except pray that the judge is enlightened.


-- 
Joe Yao
---
   This message is not an official statement of OSIS Center policies.

Tragedy of the Commons; was Re: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?

[Travis Hassloch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Amazing how many people fail to trim quoted material,
but at least they aren't top-posting.

Sounds a lot like tragedy of the commons.  To wit, the benefits
of having the IP space is given to the "owner", whereas the
resources are finite, and the cost of a new allocation is
borne by all (roughly proportional to the number of routers
that need large routing tables).
http://en.wikipedia.org/wiki/Tragedy_of_the_commons

This is always a formula for disaster, but I'm surprised it
has taken this long to metastasize into anything obvious.

If search engine page rank was indifferent to number of netblocks,
I don't think it would be an issue.  And then maybe people would
go back to making sites that people want to link to, instead of
trying to game the engines for personal profit.

Note the similarity to phone numbers, and how the telcos are being
dragged kicking and screaming towards portable numbers by the FCC
(I think).

BTW: When I started using this Innernet thingy, you could buy /24's
and they were portable, IIRC.
- --
The whole point of the Internet is that different kinds of computers
can interoperate.  Every time you see a web site that only supports
certain browsers or operating systems, they clearly don't get it.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFAdasPlSPhv5tocwRAlrqAJ4+XgYyZixIHoGMGOFhXDb0WL2BOQCfYw09
BWq6GRVlUZfBZbMN0QhGR2g=
=Xn9r
-END PGP SIGNATURE-

Re: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?

[Niels Bakker]

* [EMAIL PROTECTED] (David Schwartz) [Fri 08 Sep 2006, 21:20 CEST]:
	Even if you assume that allocations made by ARIN are not 
property, it's hard to argue that pre-ARIN allocations are not. 
They're not subject to revocation and their grant wasn't conditioned 
on compliance with policies.


Some people here are on crack.  Comparing IP addresses to mining rights? 
They're just numbers, not actual physical property.  Do you also propose 
to take allocations away again when they're not announced on the Internet?


Address space policy has always been the result of a community consensus. 
Just because that consensus has shifted over the years does not mean that 
older entries in some database have suddenly developed into property. 
All it means is that the community is very friendly for not applying the 
new rules retroactively.



-- Niels.

Re: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?

[Mark Kent]

>> More to the point, how can ARIN refuse such an order?

I would guess ARIN's point is "It's not yours to give" and that the
original court overstepped their bounds and clearly misunderstood the
whole notion of IP address "ownership."

Also, I think your example is almost as flawed as mine, and the
bidding for spectrum establishes a marketplace for it, while there is
no such thing for IP space.

I think a closer example is an operation that has phone numbers,
or perhaps more specifically, a 555 number.   555 numbers are supposed
to be for "information services" and are assigned based on some guidelines.
Suppose I win a suit against some bozo who runs just such a service
and has a 555 number and I get awarded his assets.  So, I sell the 
"information services company" but keep the 555 number for myself 
(because it would be cool).

Should I be allowed to keep the 555 number, or should I have to establish
that my use will fit under the current guidelines, just like everyone else?

-mark

P.S.  I get NANOG in digest form, so I may not be completely
  up-to-date on this discussion.

Re: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?

[william(at)elan.net]

On Fri, 8 Sep 2006, Mark Kent wrote:


Joe McGuckin typed:

2) Why does ARIN believe that it can ignore a court order?


Maybe because ARIN wasn't a party to the original proceedings
that generated that order?

Let's say you're eating lunch one day, minding your own business,
and a sheriff comes up with an official looking document and
says "You need to hand your car over to Fred..." because,
unknown to you, Fred and Barney just finished court proceedings
where the judge ruled that Barney had to give Fred "his" car,
even though that car was owned by you and just loaned to Barney.

Not a great analogy, because of the whole pink slip thing,
but you get the point.


Actually that is pretty good analogy.

Unfortunately in this case, the block appears to be one of legacy /16s
that ARIN did not assign but IANA or Internic probably did. We're
actually lucky they decided to not sue IANA or NSI because then the
whole thing would have been ever messier and judge even more confused.

IANAL, but I doubt it this will quickly end with summary judgment
though (you need similar cases for judge to compare and see decisions 
there, otherwise detailed investigation of case will be required).

Don't worry about costs though, I think ARIN has enough extra and
do have a lawyer, so I hope they spend it what is necessary to
get good results which can also be cited in the future.

--
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?

[joe mcguckin]

 Mark,A more 'correct' analogy would be as follows:    Let's say you win a judgement against another party where the court essentially awards you all the assets of the     defendant. One of the assets is a paging company. So,  you hike down to the FCC and want the radio licenses for the business    re-registered in your name, you present a valid court order to show that the court has awarded you title to the assets. In fact,    you present a court order specifically ordering the FCC to re-register the licensed spectrum to you.How can the FCC refuse? Any court with proper jurisdiction certainly has the ability to assess damages and specify remedies for thosedamages. A station license or spectrum - even though is not actual ownership, but a lease or license - is an asset and routinely are soldfor millions, even billions of dollars.More to the point, how can ARIN refuse such an order?Joe McGuckinViaNet Communications[EMAIL PROTECTED]650-207-0372 cell650-213-1302 office650-969-2124 fax On Sep 8, 2006, at 11:57 AM, Mark Kent wrote:Joe McGuckin typed: 2) Why does ARIN believe that it can ignore a court order? Maybe because ARIN wasn't a party to the original proceedingsthat generated that order?Let's say you're eating lunch one day, minding your own business,and a sheriff comes up with an official looking document andsays "You need to hand your car over to Fred..." because,unknown to you, Fred and Barney just finished court proceedingswhere the judge ruled that Barney had to give Fred "his" car,even though that car was owned by you and just loaned to Barney.Not a great analogy, because of the whole pink slip thing,but you get the point.-mark 

RE: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?

[David Schwartz]

> Joe McGuckin typed:
> >> 2) Why does ARIN believe that it can ignore a court order?

> Maybe because ARIN wasn't a party to the original proceedings
> that generated that order?

> Let's say you're eating lunch one day, minding your own business,
> and a sheriff comes up with an official looking document and
> says "You need to hand your car over to Fred..." because,
> unknown to you, Fred and Barney just finished court proceedings
> where the judge ruled that Barney had to give Fred "his" car,
> even though that car was owned by you and just loaned to Barney.
>
> Not a great analogy, because of the whole pink slip thing,
> but you get the point.

You comply with the court order to the extent that it will not do
irreversible damage to you, and you contest the order in court. To the
extent that the court order will do irreversible damage, you stall
compliance until you can get a court to suspend the order until you have
time to fully contest it. What you don't do is flat out refuse to comply
with the court order with the beneficiary of the court order and make them
go to court to enforce it.

If you assume that all Kremen's accusations are true (and correct the
obvious errors) his case seems very strong. ARIN should not have refused to
comply with a court order or insisted on conditioning its reply.

Even if you assume that allocations made by ARIN are not property, it's
hard to argue that pre-ARIN allocations are not. They're not subject to
revocation and their grant wasn't conditioned on compliance with policies.

DS

Re: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?

[Mark Kent]

Joe McGuckin typed:
>> 2) Why does ARIN believe that it can ignore a court order?

Maybe because ARIN wasn't a party to the original proceedings
that generated that order?

Let's say you're eating lunch one day, minding your own business,
and a sheriff comes up with an official looking document and
says "You need to hand your car over to Fred..." because,
unknown to you, Fred and Barney just finished court proceedings
where the judge ruled that Barney had to give Fred "his" car,
even though that car was owned by you and just loaned to Barney.

Not a great analogy, because of the whole pink slip thing,
but you get the point.

-mark

RE: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Fergie]

Don't be so sure.

What probably _would_ police these willy-nilly announcements,
however, are prefix-length filters on the various ISP routers. :-)

And again, this could certainly lend itself to folks sic'ing their
lawyers on eacvh other in the name of anti-competitive lawsuits.

A mess ensues that I don't think any of us wishes to see happen.

- ferg


-- <[EMAIL PROTECTED]> wrote:

> Another somewhat important point is that we also need to conserve
routing entries.  If you make a market for addresses without regard to
routability, you risk  
> creating a situation where you flood the world with /32's.  No thanks. 
>
> Tony  
 
I would think that would tend to police itself.  Even now with things
as they are you're going to have serious reachability problems if you
try to announce anything smaller than a /24.  And if routing tables
suddenly explode, I'd expect that threshold to quickly move in reaction.


--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Owen DeLong]

On Sep 8, 2006, at 10:33 AM, Stephen Sprunk wrote:



Thus spake <[EMAIL PROTECTED]>

[ I said ]
The debate there will be around the preferential treatment that  
larger

ARIN members get (in terms of larger allocations, lower per address
fees, etc), which Kremen construes as being anticompetitive via
creating artificial barriers to entry.  That may end up being  
changed.


Your statement about preferential treatment is factually
incorrect. Larger ARIN members do not get larger allocations.
It is the larger network infrastructures that get the larger
allocations which is not directly tied to the size of the
company. Yes, larger companies often have larger infrastructures.


And that's the point: A company that is established gets  
preferential treatment over one that is not; that is called a  
barrier to entry by the anti-trust crowd.  You may feel that such a  
barrier is justified and fair, but those on the other side of it  
(or more importantly, their lawyers) are likely to disagree.



As for fees, there are no per-address fees and there
never have been. When we created ARIN, we paid special
attention to this point because we did not want to create
the erroneous impression that people were "buying" IP
addresses. The fees are related to the amount of effort
required to service an organization and that is not
directly connected to the number of addresses.


Of course it's directly connected; all you have to do is look at  
the current fee schedule and you'll see:


/24 = $4.88/IP
/23 = $2.44/IP
/22 = $1.22/IP
/21 = $0.61/IP
/20 = $0.55/IP
/19 = $0.27/IP
/18 = $0.27/IP
/17 = $0.137/IP
/16 = $0.069/IP
/15 = $0.069/IP
/14 = $0.034/IP

While the price points quoted may be accurate, they don't really  
reflect the pricing
tiers in use at ARIN and I notice you completely ignore the fact that  
no matter how
much more than a /14 you have, you pay $18,000 and additional  
allocations don't

really cost anything.

Further, the prices you suggest refer to registration fees for ISPs,  
but, the current
fee schedule if you are NOT an ISP is a bit different (end user  
subscriber):


/24 = $100/year
/23 = $100/year
/22 = $100/year
/21 = $100/year
...
/8 = $100/year
etc.


So, just between the two ends of the fee schedule, we have a  
difference of _two orders of magnitude_ in how much an registrant  
pays divided by how much address space they get.  Smaller folks may  
use this to say that larger ISPs, some of whose employees sit on  
the ARIN BOT/AC, are using ARIN to make it difficult for  
competitors to enter the market.


Since you are paying for registration services and not for the IPs  
themselves, that is perfectly reasonable.
End users registration needs are simple, thus, the $100/year flat  
fee.  ISPs do some volume of
sub-assignment registration and as a result, the larger the network,  
the more registration effort
involved.  However, the effort does not scale linearly with the  
address space and the fee

structure reflects this.
Since that argument appears to be true _on the surface_, ARIN will  
need to show how servicing smaller ISPs incurs higher costs per  
address and thus the lower fees for "large" allocations are simply  
passing along the savings from economy of scale.  Doable, but I  
wouldn't want to be responsible for coming up with that proof.


I don't even think it is all that difficult.  Especially given the  
end-user fees.


Besides the above, Kremen also points out that larger prefixes are  
more likely to be routed, therefore refusing to grant larger  
prefixes (which aren't justified, in ARIN's view) is another  
barrier to entry.  Again, since the folks deciding these policies  
are, by and large, folks who are already major players in the  
market, it's easy to put an anticometitive slant on that.


It is my experience that any prefix within ARIN policy is generally  
equally routable.  I would say that
in my experience, Kremen's assertion in this area is false.   
Additionally, the characterization of
the ARIN policy process is largely detached from reality.  While the  
BoT technically has final
and complete authority, I cannot recall a situation in which a policy  
with consensus was not
accepted by the board, nor can I recall a situation where the board  
adopted a policy without
consensus.  Since the public policy meetings and mailing lists where  
consensus is judged
are open to any interested party, it is very hard to view this as an  
anti-competitive act in my

opinion.

Owen



PGP.sig
Description: This is a digitally signed message part

RE: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[andrew2]

>>> 3) What's wrong with treating assignments 
like property and setting up a market to buy and sell them? There's plenty of 
precedent for this:  
>>> Mineral 
rights, mining claims, Oil and gas leases, radio spectrum.  
>>>  If a given commodity is truly scarce, 
nothing works as good as the free market in encouraging consumers to conserve 
and make the best use of it.  
>>>
>> I think you're 
dead-on there, but you forget who you're really trying to convince.  It'll 
happen eventually but in the meantime the greybeards who were  
>> largely responsible 
for the Internet as we know it (and who by and large still 
wield significant influence if not still stewardship) will be dragged there 
kicking  
>> and screaming from their 
academic/pseudo-Marxist ideals, some of whom seem to still resent the 
commercialization of the Internet.  It's also hard to see  
>> the faults in the system when you 
are insulated by your position as member of the 
politburo.  
>>
>> The flip side of 
the coin of course is that if you let the free market reign on IP's, you may 
price developing countries right off the Internet which I don't think  
>> anyone sees as a 
desirable outcome.  There's sure to be a happy middle ground that people 
smarter than I will figure out, and maybe it takes a silly lawsuit  
>> such as this to kick things 
off. 
>>
>> Andrew Cruse  
>
> Another somewhat 
important point is that we also need to conserve routing 
entries.  If you make a market for addresses without regard to routability, 
you risk  
> creating a situation where you flood 
the world with /32's.  No thanks. 
>
> Tony  
 
I would think that would 
tend to police itself.  Even now with things as they are you're going to 
have serious reachability problems if you try to announce anything smaller than 
a /24.  And if routing tables suddenly explode, I'd expect that threshold 
to quickly move in 
reaction.
 
Andrew 
Cruse

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Michael Nicks]

The real fundamental flaw with this free-market approach to handling IP 
assignments is the fact that it will further create an environment where 
smaller (start-ups, small businesses) entities trying to acquire PI 
space will face insurmountable challenges (eg, financial).


While I think the majority of people these days would agree that the 
free-market approach to economics is definitely the best, certain 
resources are not very applicable to be traded in a free-market 
environment. I myself do not like over-bureaucratic processes, and while 
all of us at one time or another have complained about ARIN's 
procedures, policies, and practices, the purpose they serve is a needed one.


Best Regards,
-Michael

--
Michael Nicks
Network Engineer
KanREN
e: [EMAIL PROTECTED]
o: +1-785-856-9800 x221
m: +1-913-378-6516



[EMAIL PROTECTED] wrote:


3) What's wrong with treating assignments like property and setting up a 
market to buy and sell them? There's plenty of precedent for this: 
 
 Mineral rights, mining claims, Oil and gas leases, radio spectrum.  
 
 If a given commodity is truly scarce, nothing works as good as the free 
market in encouraging consumers to conserve and make the best use of it. 
 
 
I think you're dead-on there, but you forget who you're really trying to 
convince.  It'll happen eventually but in the meantime the greybeards 
who were largely responsible for the Internet as we know it (and who by 
and large still wield significant influence if not still stewardship) 
will be dragged there kicking and screaming from their 
academic/pseudo-Marxist ideals, some of whom seem to still resent the 
commercialization of the Internet.  It's also hard to see the faults in 
the system when you are insulated by your position as member of the 
politburo. 
 
The flip side of the coin of course is that if you let the free market 
reign on IP's, you may price developing countries right off the Internet 
which I don't think anyone sees as a desirable outcome.  There's sure to 
be a happy middle ground that people smarter than I will figure out, and 
maybe it takes a silly lawsuit such as this to kick things off.
 
Andrew Cruse

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Stephen Sprunk]

Thus spake <[EMAIL PROTECTED]>

[ I said ]
The debate there will be around the preferential treatment that 
larger

ARIN members get (in terms of larger allocations, lower per address
fees, etc), which Kremen construes as being anticompetitive via
creating artificial barriers to entry.  That may end up being 
changed.


Your statement about preferential treatment is factually
incorrect. Larger ARIN members do not get larger allocations.
It is the larger network infrastructures that get the larger
allocations which is not directly tied to the size of the
company. Yes, larger companies often have larger infrastructures.


And that's the point: A company that is established gets preferential 
treatment over one that is not; that is called a barrier to entry by the 
anti-trust crowd.  You may feel that such a barrier is justified and 
fair, but those on the other side of it (or more importantly, their 
lawyers) are likely to disagree.



As for fees, there are no per-address fees and there
never have been. When we created ARIN, we paid special
attention to this point because we did not want to create
the erroneous impression that people were "buying" IP
addresses. The fees are related to the amount of effort
required to service an organization and that is not
directly connected to the number of addresses.


Of course it's directly connected; all you have to do is look at the 
current fee schedule and you'll see:


/24 = $4.88/IP
/23 = $2.44/IP
/22 = $1.22/IP
/21 = $0.61/IP
/20 = $0.55/IP
/19 = $0.27/IP
/18 = $0.27/IP
/17 = $0.137/IP
/16 = $0.069/IP
/15 = $0.069/IP
/14 = $0.034/IP

So, just between the two ends of the fee schedule, we have a difference 
of _two orders of magnitude_ in how much an registrant pays divided by 
how much address space they get.  Smaller folks may use this to say that 
larger ISPs, some of whose employees sit on the ARIN BOT/AC, are using 
ARIN to make it difficult for competitors to enter the market.


Since that argument appears to be true _on the surface_, ARIN will need 
to show how servicing smaller ISPs incurs higher costs per address and 
thus the lower fees for "large" allocations are simply passing along the 
savings from economy of scale.  Doable, but I wouldn't want to be 
responsible for coming up with that proof.


Besides the above, Kremen also points out that larger prefixes are more 
likely to be routed, therefore refusing to grant larger prefixes (which 
aren't justified, in ARIN's view) is another barrier to entry.  Again, 
since the folks deciding these policies are, by and large, folks who are 
already major players in the market, it's easy to put an anticometitive 
slant on that.


S

Stephen Sprunk "God does not play dice."  --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking 

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
Daily listings are sent to [EMAIL PROTECTED]

For historical data, please see http://thyme.apnic.net.

If you have any comments please contact Philip Smith <[EMAIL PROTECTED]>.

Routing Table Report   04:00 +10GMT Sat 09 Sep, 2006

Analysis Summary


BGP routing table entries examined:  197313
Prefixes after maximum aggregation:  107623
Unique aggregates announced to Internet:  95918
Total ASes present in the Internet Routing Table: 23078
Origin-only ASes present in the Internet Routing Table:   20103
Origin ASes announcing only one prefix:9652
Transit ASes present in the Internet Routing Table:2975
Transit-only ASes present in the Internet Routing Table: 64
Average AS path length visible in the Internet Routing Table:   3.6
Max AS path length visible:  29
Max AS path prepend of ASN (36728)   27
Prefixes from unregistered ASNs in the Routing Table: 2
Unregistered ASNs in the Routing Table:   2
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:  9
Number of addresses announced to Internet:   1580431436
Equivalent to 94 /8s, 51 /16s and 120 /24s
Percentage of available address space announced:   42.6
Percentage of allocated address space announced:   60.5
Percentage of available address space allocated:   70.5
Total number of prefixes smaller than registry allocations:   98476

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:43293
Total APNIC prefixes after maximum aggregation:   17399
Prefixes being announced from the APNIC address blocks:   40913
Unique aggregates announced from the APNIC address blocks:18468
APNIC Region origin ASes present in the Internet Routing Table:2696
APNIC Region origin ASes announcing only one prefix:764
APNIC Region transit ASes present in the Internet Routing Table:404
Average APNIC Region AS path length visible:3.5
Max APNIC Region AS path length visible: 24
Number of APNIC addresses announced to Internet:  262062176
Equivalent to 15 /8s, 158 /16s and 192 /24s
Percentage of available APNIC address space announced: 81.9

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911
APNIC Address Blocks   58/7, 60/7, 121/8, 122/7, 124/7, 126/8, 202/7
   210/7, 218/7, 220/7 and 222/8

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes: 99748
Total ARIN prefixes after maximum aggregation:58992
Prefixes being announced from the ARIN address blocks:73259
Unique aggregates announced from the ARIN address blocks: 27654
ARIN Region origin ASes present in the Internet Routing Table:10953
ARIN Region origin ASes announcing only one prefix:4147
ARIN Region transit ASes present in the Internet Routing Table:1011
Average ARIN Region AS path length visible: 3.3
Max ARIN Region AS path length visible:  29
Number of ARIN addresses announced to Internet:   296980224
Equivalent to 17 /8s, 179 /16s and 143 /24s
Percentage of available ARIN address space announced:  77.0

ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
   3354-4607, 4865-5119, 5632-6655, 6912-7466
   7723-8191, 10240-12287, 13312-15359, 16384-17407
   18432-20479, 21504-23551, 25600-26591,
   26624-27647, 29696-30719, 31744-33791
   35840-36863, 39936-40959
ARIN Address Blocks24/8, 63/8, 64/5, 72/6, 76/8, 199/8, 204/6,
   208/7 and 216/8

RIPE Region Analysis Summary


Prefixes being announced by RIPE Region ASes: 39668
Total RIPE prefixes after maximum aggregation:26501
Prefixes being announced from the RIPE address blocks:36571
Unique aggregates announced from the RIPE address blocks: 24728
RIPE Region origin ASes present in the Internet Routing Table: 8485
RIPE Region origin ASes announcing only one prefix:4455
RIPE Region transit ASes present in the 

RE: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Tony Li]

 

  3) 
  What's wrong with treating assignments like property and setting up a market 
  to buy and sell them? There's plenty of precedent for this: 
   
   Mineral 
  rights, mining claims, Oil and gas leases, radio spectrum.  
   
   If a given 
  commodity is truly scarce, nothing works as good as the free market in 
  encouraging consumers to conserve and make the best use of it. 
   
   
  I think you're dead-on there, but you forget who you're 
  really trying to convince.  It'll happen eventually but in the meantime 
  the greybeards who were largely responsible for the Internet as we know 
  it (and who by and large still wield significant influence if not still 
  stewardship) will be dragged there kicking and screaming from their 
  academic/pseudo-Marxist ideals, some of whom seem to still resent the 
  commercialization of the Internet.  It's also hard to see the faults in 
  the system when you are insulated by your position as member of the 
  politburo. 
   
  The flip side of the coin of course is that if you let 
  the free market reign on IP's, you may price developing countries right off 
  the Internet which I don't think anyone sees as a desirable outcome.  
  There's sure to be a happy middle ground that people smarter than I will 
  figure out, and maybe it takes a silly lawsuit such as this to kick things 
  off.
   
  Andrew Cruse 
   
   
 
Another somewhat 
important point is that we also need to conserve routing 
entries.  If you make a market for addresses without regard to routability, 
you risk creating a situation where you flood the world with /32's.  No 
thanks.
 
Tony
 

RE: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[andrew2]

3) What's wrong with 
treating assignments like property and setting up a market to buy and sell them? 
There's plenty of precedent for this: 
 
 Mineral 
rights, mining claims, Oil and gas leases, radio spectrum.  
 
 If a given 
commodity is truly scarce, nothing works as good as the free market in 
encouraging consumers to conserve and make the best use of it. 
 
 
I think you're dead-on there, but you forget who you're 
really trying to convince.  It'll happen eventually but in the meantime the 
greybeards who were largely responsible for the Internet as we know it (and 
who by and large still wield significant influence if not still 
stewardship) will be dragged there kicking and screaming from their 
academic/pseudo-Marxist ideals, some of whom seem to still resent the 
commercialization of the Internet.  It's also hard to see the faults in the 
system when you are insulated by your position as member of the 
politburo. 
 
The flip side of the coin of course is that if you let the 
free market reign on IP's, you may price developing countries right off the 
Internet which I don't think anyone sees as a desirable outcome.  There's 
sure to be a happy middle ground that people smarter than I will figure out, and 
maybe it takes a silly lawsuit such as this to kick things 
off.
 
Andrew 
Cruse

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[joe mcguckin]

I read the complaint. I don't like the fact that a lot of my friends are named in the suit, but I think there are somepoints worth discussing within the community:1) IP address blocks are not 'property'     "Domains are not  property. The assignee of a domain has no ownership interest"    Network Solutions made this same argument  years ago. That was their shield against lawsuits when negligence    (or worse) on NetSols part would cause a domain to be erroneously transferred. When mistakes were made,    Network Solutions was notoriously unwilling to reverse the transaction to correct the error.    Then they got sued for refusing to reverse a fradulent domain transfer, and they lost. The case had the side effect of setting     the precedent that domains *are* in fact tangible property. Now when a registrar or registry makes a mistake, they can be     legally held responsible. (What case was that? Kremen v. Network Solutions)    I would say that's an improvement.2) Why does ARIN believe that it can ignore a court order?3) What's wrong with treating assignments like property and setting up a market to buy and sell them? There's plenty of precedent for this:     Mineral rights, mining claims, Oil and gas leases, radio spectrum.      If a given commodity is truly scarce, nothing works as good as the free market in encouraging consumers to conserve and make the best      use of it.Joe McGuckinViaNet Communications[EMAIL PROTECTED]650-207-0372 cell650-213-1302 office650-969-2124 fax

Re: [routing-wg]BGP Update Report

[Joe Provo]

On Fri, Sep 08, 2006 at 05:57:10PM +0300, Hank Nussbacher wrote:
> 
> On Fri, 8 Sep 2006, [EMAIL PROTECTED] wrote:
> 
> Strike me as curious, but this seems as if Connexion by Boeing is handing 
> off a /24 from ASN to ASN as a certain plane moves over certain geographic 
> areas.  Or is there some other explanation?

Detailed at nanog 31 (among other meetings):
http://www.nanog.org/mtg-0405/abarbanel.html

2005 detail from a blogger:
http://bayosphere.com/node/879

2006 detail from another blogger:
http://www.renesys.com/blog/2006/04/tracking_plane_flight_on_inter.shtml

-- 
 RSUC / GweepNet / Spunk / FnB / Usenix / SAGE

Re: [routing-wg]BGP Update Report

[Fergie]

If I recall correctly, Todd Underwood over at Renesy did a pretty
interesting write-up on this a while back

[Later] Here it is:

 http://www.renesys.com/blog/2006/04/tracking_plane_flight_on_inter.shtml

- ferg

-- "Patrick W. Gilmore" <[EMAIL PROTECTED]> wrote:


On Sep 8, 2006, at 10:57 AM, Hank Nussbacher wrote:
> On Fri, 8 Sep 2006, [EMAIL PROTECTED] wrote:
>
> Strike me as curious, but this seems as if Connexion by Boeing is  
> handing off a /24 from ASN to ASN as a certain plane moves over  
> certain geographic areas.  Or is there some other explanation?

They presented at NANOG saying they would be re-announcing a /24 per  
plane as it crosses the ocean.  I can't recall if the originating (or  
transit) ASNs were going to change, but it doesn't seem wholly  
unreasonable.  IMHO, of course.

-- 
TTFN,
patrick


--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: Market Share of broadband provider in Scandidavia

[Saku Ytti]

On (2006-09-08 18:03 +0200), Mikael Abrahamsson wrote:

> >Could anyone point me to a market-share by-country overview of broadband 
> >provider in Scandinavia (Denmark, Sweden, Norway, Finland, Iceland). Any 
> >help would be appreciated.
> 
> For Sweden, you can go to www.pts.se, more exactly 
> .

For Finland, from ~same govertment body:
http://www.ficora.fi/englanti/tele/marketreview.htm

Or direct URL to the PDF itself:
http://www.ficora.fi/englanti/document/Markkinakatsaus_2_2006_EN.pdf

Page 9 should answer your question.
-- 
  ++ytti

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Fergie]

-- "Stephen Sprunk" <[EMAIL PROTECTED]> wrote:

>The entire suit is predicated on the concept that IP addresses can
>be owned and traded like other property.  The rest is a house of
>cards that will fall if ARIN can prove that to be incorrect -- and
>will probably stand if they can't.

[snip]

I like how Jack Bates framed it: The IP address space is a "community
asset" and as such, the allocation of it needs to be done in a way
which serves & benefits the Internet community at-large.

That said, we have had this discussion many times over the years,
especially within IEPG discussions, and punching holes in CIDR blocks,
for the sake of alighning address space w.r.t. special interests
(as opposed to some sanity in allocation policy which attempts to
preserve allocation to allow CIDR aggregation) is a Bad Thing.

It will be interesing to see how this plays out...

- ferg

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: [routing-wg]BGP Update Report

[Bill Woodcock]

  On Fri, 8 Sep 2006, Hank Nussbacher wrote:
> Strike me as curious, but this seems as if Connexion by Boeing is handing
> off a /24 from ASN to ASN as a certain plane moves over certain geographic
> areas.

Yes, that was their architecture, originally.  My understanding was that 
they'd subsequently moved to a more complicated system of NATing, but my 
understanding may be incorrect, or they may not have done so entirely.

-Bill

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Justin M. Streiner]

The complaint was, at best, an entertaining read.  IANAL.

As was mentioned earlier, it looks like Kremen's whole case is built on a 
number of false assumptions:


1. Netblocks are the property of the organization once their assignment 
request is approved by ARIN or other RIR.


Since this is false, the none of the parties involved in Kremen v. Cohen 
would have legal standing to make the transfer of Cohen's netblocks a

condition of satisfying the judgment in that case.

2. There is an open market for buying and selling IP addresses.

While ISPs can and sometimes do charge fees to their customers to use a 
block of PA space, they cannot do the same on an 'open' market.  The 
customer normally may use the PA space until their business relationship

with the ISP is terminated, i.e. the space is non-portable.

3. ARIN's policies discriminate against smaller providers by preventing 
them from getting larger netblocks.


Going back to 1997 from what I can find, ARIN's address assignment 
policies have always advocated a pay-as-you-go model.  If an organization 
gets close to using all of their assigned addresses, they can request 
another block once they've provided justification that the first 
assignment has been efficiently used.  The complaint acknowledges that IP 
addresses are finite resources and that macro-allocation of address 
ranges is handled by ICANN.


4. "Recently... Classless Inter-Domain Routing or CIDR..."

As others have mentioned, this is hilarious.  I guess I'll have to upgrade 
my routers to use that newfangled routing protocol, BGP4  CIDR had a 
huge impact in putting the brakes on wasteful IP address allocation.  The 
days of /16s being available pretty much for the asking are long gone.


5. Providing information to justify an assignment or transfer request will 
force the requestor to reveal information that is confidential and 
proprietary.


The way I see it, this helps maintain some degree of transparency of 
ARIN's policies, customer business names and addresses are items that are 
probably already matters of public record from domain name registrations 
and so forth.  Also, the information provided to ARIN when requesting more 
space is normally more detailed than what is required to be made public 
through SWIP or RWHOIS.  The information specifically submitted to ARIN 
for proving a request is justified is not released to the public.


jms

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Jack Bates]

Matt Ghali wrote:


Yes, at the least, wasting huge piles of ARIN's money on legal fees; 
which is likely Kremen's entire intent, to "teach them a lesson" for not 
handing over what he wanted.




Correction. Wasting huge piles of our money. I was hoping the money would go 
towards a new template, too!


-Jack

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Brandon Galbraith]

Hopefully ARIN can recover their legal fees, so cash from members can be spent on IP space management.-brandonOn 9/8/06, Matt Ghali <
[EMAIL PROTECTED]> wrote:On Fri, 8 Sep 2006, Gordon Cook wrote:> This is Gary  Kremen owner of SEX dot com.
>> cohen stole sex.com from kremen and kremen sued and got it back - it looks> like he is trying to force arin to give him cohen's IP assignments  sounds> like a grudge match - but it is a shame that he might do arin collateral
> damageYes, at the least, wasting huge piles of ARIN's money on legal fees;which is likely Kremen's entire intent, to "teach them a lesson" fornot handing over what he wanted.People who use the courts as a way to bleed their targets like this
are vermin. Not surprising at all that this is all about somedomain-squatting nonsense.I do hope that ARIN can convince the judge to issue a summaryjudgement to throw this entire case out.matto
[EMAIL PROTECTED]<   Moral indignation is a technique to endow the idiot with dignity. - Marshall McLuhan
-- Brandon GalbraithEmail: [EMAIL PROTECTED]AIM: brandong00Voice: 630.400.6992"A true pirate starts drinking before the sun hits the yard-arm. Ya. --thelost"

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Matt Ghali]

On Fri, 8 Sep 2006, Gordon Cook wrote:


This is Gary  Kremen owner of SEX dot com.

cohen stole sex.com from kremen and kremen sued and got it back - it looks 
like he is trying to force arin to give him cohen's IP assignments  sounds 
like a grudge match - but it is a shame that he might do arin collateral 
damage


Yes, at the least, wasting huge piles of ARIN's money on legal fees; 
which is likely Kremen's entire intent, to "teach them a lesson" for 
not handing over what he wanted.


People who use the courts as a way to bleed their targets like this 
are vermin. Not surprising at all that this is all about some 
domain-squatting nonsense.


I do hope that ARIN can convince the judge to issue a summary 
judgement to throw this entire case out.


matto

[EMAIL PROTECTED]<
  Moral indignation is a technique to endow the idiot with dignity.
- Marshall McLuhan

Re: Market Share of broadband provider in Scandidavia

[Mikael Abrahamsson]

On Fri, 8 Sep 2006, Fredy Kuenzler wrote:



Could anyone point me to a market-share by-country overview of broadband 
provider in Scandinavia (Denmark, Sweden, Norway, Finland, Iceland). Any help 
would be appreciated.


For Sweden, you can go to www.pts.se, more exactly 
.


They publish both in Sweden and English as far as I can discern.

PTS is the regulatory entity in Sweden for Telecommunications (and Post, 
but that's beside the point here :) ).


--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

Re: Market Share of broadband provider in Scandidavia

[Simon Waters]

On Friday 08 Sep 2006 15:21, you wrote:
>
> Could anyone point me to a market-share by-country overview of broadband
> provider in Scandinavia (Denmark, Sweden, Norway, Finland, Iceland). Any
> help would be appreciated.

Ovum use to do reports on European ISP market share, I think it covered 
Scandinavia (I don't think we worried too much given that the entire 
population of Scandinavia is about the same as greater London, we were 
focused on larger countries - by population - mostly).

Included best guess at future changes at the time as well.

The report wasn't cheap, but the people I was working with just bought large 
chunks of such intelligence in order to assess big investment decisions.

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Fergie]

-- [EMAIL PROTECTED] wrote:

>> I am looking for anyone who has input on possibly the largest case
>> regarding internet numbering ever. This lawsuit may change the way
>> IP's are governed and adminstered. Comments on or off list please.
>
>My personal opinion is that this is yet another
>example of ignorance leading to anger leading to
>a stupid waste of court time. [...]

On this, we agree. :-)

- ferg

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: [routing-wg]BGP Update Report

[Patrick W. Gilmore]

On Sep 8, 2006, at 10:57 AM, Hank Nussbacher wrote:

On Fri, 8 Sep 2006, [EMAIL PROTECTED] wrote:

Strike me as curious, but this seems as if Connexion by Boeing is  
handing off a /24 from ASN to ASN as a certain plane moves over  
certain geographic areas.  Or is there some other explanation?


They presented at NANOG saying they would be re-announcing a /24 per  
plane as it crosses the ocean.  I can't recall if the originating (or  
transit) ASNs were going to change, but it doesn't seem wholly  
unreasonable.  IMHO, of course.


--
TTFN,
patrick

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Michael Nicks]

[EMAIL PROTECTED] wrote:

But in the end, IP addresses are not property, therefore
they cannot be assets and cannot be transferred. They can
only be kept if they are in use on network assets which are
transferred and which continue to be operational. And even
then, most people have no choice as to which specific 
address block they use. They simply take what the ISP gives

them.


One could probably debate that statement for a long time. Saying they 
are "free" to me is technically inaccurate. If you are getting PI space, 
you have to pay registration fees, which incurs cost on behalf of the 
party. A growing number of ISPs are now charging "leasing" fees or 
similar fees for the usage of PA addresses.


As IP address scarcity goes up, I wouldn't be surprised if leasing fees 
become higher and/or if ARIN fees become more steep as an attempt to 
weed out people who are trying to horde address space.


While IP addresses certainly are not a tangible asset, and a defined 
intrinsic value can not be determined, there does seem to be a value to 
them, if only speculative at best.


Best Regards,
-Michael

--
Michael Nicks
Network Engineer
KanREN
e: [EMAIL PROTECTED]
o: +1-785-856-9800 x221
m: +1-913-378-6516

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Michael . Dillon]

>  The debate there will be around the 
> preferential treatment that larger ARIN members get (in terms of larger 
> allocations, lower per address fees, etc), which Kremen construes as 
> being anticompetitive via creating artificial barriers to entry.  That 
> may end up being changed.

Your statement about preferential treatment is factually
incorrect. Larger ARIN members do not get larger allocations.
It is the larger network infrastructures that get the larger
allocations which is not directly tied to the size of the
company. Yes, larger companies often have larger infrastructures.
However, ARIN gives the addresses based primarily on the 
number of hosts attached to the network infrastructure.
It has been argued in the past that ARIN's policies are
prejudiced AGAINST larger organizations because the rules
do not properly allow for the scaling overhead necessary
due to the complexity of larger networks.

As for fees, there are no per-address fees and there 
never have been. When we created ARIN, we paid special
attention to this point because we did not want to create
the erroneous impression that people were "buying" IP
addresses. The fees are related to the amount of effort
required to service an organization and that is not
directly connected to the number of addresses.

--Michael Dillon
(no longer in any official ARIN capacity. Just another member)

Re: [routing-wg]BGP Update Report

[Hank Nussbacher]

On Fri, 8 Sep 2006, [EMAIL PROTECTED] wrote:

Strike me as curious, but this seems as if Connexion by Boeing is handing 
off a /24 from ASN to ASN as a certain plane moves over certain geographic 
areas.  Or is there some other explanation?



TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
4 - 83.210.15.0/24 1843  0.1%   AS23918 -- CBB-BGP-IBARAKI Connexion By 
Boeing Ibaraki AS
AS29257 -- CBB-IE-AS Connexion by Boeing 
Ireland, Ltd.
AS30533 -- CONNEXION-BY-BOEING-LTN - 
Connexion by Boeing
AS31050 -- CBB-RU-ASN Connexion by Boeing 
Eastern Europe, Ltd.
AS33697 -- CONNEXION-BY-BOEING-VBC - 
Connexion by Boeing
17 - 60.253.32.0/24  822  0.1%   AS23918 -- CBB-BGP-IBARAKI Connexion By 
Boeing Ibaraki AS
AS30533 -- CONNEXION-BY-BOEING-LTN - 
Connexion by Boeing
AS31050 -- CBB-RU-ASN Connexion by Boeing 
Eastern Europe, Ltd.
AS33697 -- CONNEXION-BY-BOEING-VBC - 
Connexion by Boeing


Hank Nussbacher
http://www.interall.co.il

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Stephen Sprunk]

Thus spake Brandon Galbraith

Two questions regarding thisfor the list (slightly OT):

1) Has any sort of IP address ownership precedence been set in a US
court?


Not that I'm aware of, but I've never looked.  I'm sure ARIN's lawyers 
have.



2) Isn't ARIN considered a non-profit resource management/allocation
organization? To my knowledge, there is no "marketplace" for IPs.


The entire suit is predicated on the concept that IP addresses can be 
owned and traded like other property.  The rest is a house of cards that 
will fall if ARIN can prove that to be incorrect -- and will probably 
stand if they can't.


Also, any technical expert can rip about half of the house down without 
breaking a sweat because it's so flawed to the point of being 
entertaining.  It'd be fun to read the transcripts if this ever goes to 
trial, but my money says it'll be decided one way or the other before it 
actually makes it into a courtroom.


The wording of Kremen's argument made me understand why ARIN is so 
resistant to using the term "rent" for their activities, because that 
implies that there is property exchanging hands.  Courts have 
jurisdiction over property, though it's a minefield to try to dictate 
who someone must rent to.  Keeping the words in registry-speak allows 
them to differentiate the situation and insist that addresses are not 
property at all.


The anti-trust angle is interesting, but even if ARIN were found to be 
one, it's hard to convince people that a _non-profit_ monopoly acting in 
the public interest is a bad thing.  The debate there will be around the 
preferential treatment that larger ARIN members get (in terms of larger 
allocations, lower per address fees, etc), which Kremen construes as 
being anticompetitive via creating artificial barriers to entry.  That 
may end up being changed.


S

Stephen Sprunk "God does not play dice."  --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking 

Market Share of broadband provider in Scandidavia

[Fredy Kuenzler]

Could anyone point me to a market-share by-country overview of broadband 
provider in Scandinavia (Denmark, Sweden, Norway, Finland, Iceland). Any 
help would be appreciated.


Regards,
Fredy

Wiltel contact

[J. Oquendo]

Can someone at wcg.net contact me offlist to discuss a security incident.

--

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Jack Bates]

Jon Lewis wrote:


In small quantities, and which tie you to particular providers.  Shells 
of companies have been bought (or just claimed) for their large, 
especially pre-ARIN, PI-IP assignments.  To a young ISP, a /16 for 
example may seem like a lifetime supply of IP space, and save the 
company many thousands of dollars (ARIN registration fees) and paperwork 
hassles.




Actually, their issue is that ARIN would only transfer the netblock to 
them under the condition of them signing the contract (which effectively 
states that ARIN controls the netblocks). They would also be liable for 
the annual fees. They are trying to treat IP address space as property 
which they own, and refuse to agree to ARIN registration/fees to obtain 
what they feel is their property. Unfortunately, while ARIN is a steward 
and technically does not *own* the IP address space, neither does the 
ISP that uses the space. The defendant apparently misses the fact that 
IP space is a community asset and is thus handled by the community.


IANAL, but I doubt they can prove Antitrust in this case. If only we 
could handle other limited resources in the world as effectively; 
including BGP routing table bloat.



-Jack

Re: TCP receive window set to 0; DoS or not?

[Robert E . Seastrom]

[EMAIL PROTECTED] writes:

> On Thu, 7 Sep 2006, Joshua Brewer wrote:
>
>> What about when we're seeing this on port 25?
>
> Sand worms.
>
> In all seriousness, your guess is as good as mine, at that point. If 
> memory serves, the platforms we saw this on most, with web browsers, were 
> mobile devices. What kind of volume are you seeing this in? 

Since the error message is within a debug statement, it seems
appropriate to repeat the words of advice an old pilot friend of mine
once gave on making emergency landings at night in small aircraft:

"First, turn off your strobes and landing lights - you want to be able
to see well outside the aircraft.  Find a road.  Fly a normal
left-hand pattern, and as you turn base to final, turn your landing
lights back on.  If you don't like what you see, turn them back off
again."

---rob

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Gordon Cook]

This is Gary  Kremen owner of SEX dot com.cohen stole sex.com from kremen and kremen sued and got it back - it looks like he is trying to force arin to give him cohen's IP assignments  sounds like a grudge match - but it is a shame that he might do arin collateral damage =The COOK Report on Internet Protocol, 609 882-2572 (PSTN) 415 651-4147 (Lingo) Back Issues: http://www.cookreport.com/browse_past_free2.shtml   Cook's Collaborative Edge Blog http://gordoncook.net/wp/ Subscription info: http://cookreport.com/subscriptions.shtml= On Sep 8, 2006, at 5:36 AM, tony sarendal wrote: Interesting read. http://www.internetgovernance.org/pdf/kremen.pdf#search=%22kremen%20vs%20arin%22I found this little gem in the "The Internet, IP addresses and Domain Names" section:  --- Recently a new form of Internet addressing has emerged, called Classless Inter-Domain Routing (CIDR).  In this new  addressing protocol, a CIDR network address could look like this: 193.30.250.00/21. The prefix is the address of the network, or gateway, and the number after the slash indicates the size of the network. The higher the number, the more host space that is in the network(2). ... --- (2) later contradicts this statement.  Maybe I should sell them some /32's, or why not a few /128's. Or maybe I just have too much time on my hands.  /Tony  On 08/09/06, Chris Jester <[EMAIL PROTECTED] > wrote: I am looking for anyone who has input on possibly the largest caseregarding internet numbering ever. This lawsuit may change the wayIP's are governed and adminstered. Comments on or off list please. Anyone have experiences like are said in the lawsuit? I would loveto know if this is true or not.  Anyone with negative ARIN experiencesthat relate to the lawsuit, please let me know, thanks!For thos interested, you may read this lawsuit here:  http://72.14.209.104/search?q=cache:44uxmnEmJVkJ:www.internetgovernance.org/pdf/kremen.pdf+Kremen+Vs+ARIN&hl=en&gl=us&ct=clnk&cd=1 Or google for Kremen VS ArinChris JesterSuavemente, INC.SplitInfinity Networks619-227-8845AIM: NJesterCQ: 64791506Chris JesterSuavemente, INC.SplitInfinity Networks 619-227-8845AIM: NJesterCQ: 64791506NOTICE - This e-mail and any files transmitted with it are confidential andare only for the use of the person to whom they are addressed. If you are not the intended recipient you have received this e-mail in error. Any use, dissemination, forwarding, printing, copying or dealing in any waywhatsoever with this e-mail is strictly prohibited. If you have receivedthis e-mail in error, please reply immediately by way of advice to us. It is the addressee/recipient duty to virus scan and otherwise test theinformation provided before loading onto any computer system. Suavemente,INC.does not warrant that the information is free of a virus or any other defect or error. Any views expressed in this message are those of theindividual sender, except where the sender specifically states them to bethe views of Suavemente, INC. -- Tony Sarendal - [EMAIL PROTECTED]IP/Unix   -= The scorpion replied,   "I couldn't help it, it's my nature" =- 

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Jon Lewis]

On Fri, 8 Sep 2006 [EMAIL PROTECTED] wrote:


Since IP addresses are basically available free from
any ISP who sells Internet access services, this seems


In small quantities, and which tie you to particular providers.  Shells of 
companies have been bought (or just claimed) for their large, especially 
pre-ARIN, PI-IP assignments.  To a young ISP, a /16 for example may seem 
like a lifetime supply of IP space, and save the company many thousands of 
dollars (ARIN registration fees) and paperwork hassles.


News of this case has been sent here before (by [EMAIL PROTECTED] back in 
July).  Is anything really happening with the case?


--
 Jon Lewis   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

The Cidr Report

[cidr-report]

This report has been generated at Fri Sep  8 21:45:01 2006 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org/as4637 for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
01-09-06193923  126440
02-09-06194021  126509
03-09-06193976  126474
04-09-06194001  126621
05-09-06194218  126743
06-09-06194352  126801
07-09-06194163  127028
08-09-06194527  126877


AS Summary
 22992  Number of ASes in routing system
  9655  Number of ASes announcing only one prefix
  1471  Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - AT&T WorldNet Services
  91398144  Largest address span announced by an AS (/32s)
AS721  : DISA-ASNBLK - DoD Network Information Center


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 08Sep06 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 194400   1268546754634.7%   All ASes

AS4134  1272  269 100378.9%   CHINANET-BACKBONE
   No.31,Jin-rong Street
AS4755   978   69  90992.9%   VSNL-AS Videsh Sanchar Nigam
   Ltd. Autonomous System
AS18566  959  126  83386.9%   COVAD - Covad Communications
   Co.
AS4323   994  292  70270.6%   TWTC - Time Warner Telecom,
   Inc.
AS9498   849  155  69481.7%   BBIL-AP BHARTI BT INTERNET
   LTD.
AS721974  308  66668.4%   DISA-ASNBLK - DoD Network
   Information Center
AS22773  697   52  64592.5%   CCINET-2 - Cox Communications
   Inc.
AS6197  1028  487  54152.6%   BATI-ATL - BellSouth Network
   Solutions, Inc
AS7018  1471  953  51835.2%   ATT-INTERNET4 - AT&T WorldNet
   Services
AS19262  694  189  50572.8%   VZGNI-TRANSIT - Verizon
   Internet Services Inc.
AS17488  529   41  48892.2%   HATHWAY-NET-AP Hathway IP Over
   Cable Internet
AS19916  565   94  47183.4%   ASTRUM-0001 - OLM LLC
AS855553   86  46784.4%   CANET-ASN-4 - Aliant Telecom
AS11492  731  287  44460.7%   CABLEONE - CABLE ONE
AS17676  498   62  43687.6%   JPNIC-JP-ASN-BLOCK Japan
   Network Information Center
AS18101  447   23  42494.9%   RIL-IDC Reliance Infocom Ltd
   Internet Data Centre,
AS3602   511  104  40779.6%   AS3602-RTI - Rogers Telecom
   Inc.
AS4766   703  310  39355.9%   KIXS-AS-KR Korea Telecom
AS812416   30  38692.8%   ROGERS-CABLE - Rogers Cable
   Inc.
AS15270  460   77  38383.3%   AS-PAETEC-NET - PaeTec.net -a
   division of
   PaeTecCommunications, Inc.
AS22047  454   94  36079.3%   VTR BANDA ANCHA S.A.
AS4812   395   60  33584.8%   CHINANET-SH-AP China Telecom
   (Group)
AS6467   396   61  33584.6%   ESPIRECOMM - Xspedius
   Communications Co.
AS16852  366   53  31385.5%   FOCAL-CHICAGO - Focal Data
   Communications of Illinois
AS16814  329   47  28285.7%   NSS S.A.
AS19115  375   97  27874.1%   CHARTER-LEBANON - Charter
   Communications
AS9583   952  678  27428.8%   SIFY-AS-IN Sify Limited
AS14654  284   15  26994.7%   WAYPORT - Wayport
AS17849  423  157  26662.9%   GINAMHANVIT-AS-KR hanvit ginam
   broadcasting comm.
AS6167   369  106  26371.3%   CELLCO-PART - Cellco
   Partnership

Total 

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 25-Aug-06 -to- 07-Sep-06 (14 days)
Observation Point: BGP Peering with AS4637

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS413437938  2.8%  61.8 -- CHINANET-BACKBONE 
No.31,Jin-rong Street
 2 - AS17974   18693  1.4%  36.9 -- TELKOMNET-AS2-AP PT 
TELEKOMUNIKASI INDONESIA
 3 - AS868513836  1.0% 406.9 -- DORUKNET DorukNet Istanbul / 
Turkey
 4 - AS619711668  0.9%  11.3 -- BATI-ATL - BellSouth Network 
Solutions, Inc
 5 - AS912111449  0.8%  97.0 -- TTNET TTnet Autonomous System
 6 - AS15464   11391  0.8% 474.6 -- IHLASNET IHLASNET Autonomous 
System
 7 - AS838610412  0.8% 433.8 -- KOCNET KOCNET-AS
 8 - AS17557   10189  0.8%  28.4 -- PKTELECOM-AS-AP Pakistan Telecom
 9 - AS15611   10017  0.7%  88.6 -- Iranian Research Organisation
10 - AS855  9974  0.7%  17.7 -- CANET-ASN-4 - Aliant Telecom
11 - AS341049297  0.7% 464.9 -- TELETEK-AS TELETEK 
TELEKOMINIKASYON HIZMETLERI A.S
12 - AS124978715  0.6% 174.3 -- SANET-GE SANET NETWORK (AS)
13 - AS7011 8589  0.6%  12.8 -- FRONTIER-AND-CITIZENS - 
Frontier Communications, Inc.
14 - AS337838176  0.6%  76.4 -- EEPAD
15 - AS4621 8164  0.6%  60.9 -- UNSPECIFIED UNINET-TH
16 - AS4787 8063  0.6%  30.2 -- ASN-CBN ASN CBNnet
17 - AS9394 8062  0.6%  17.6 -- CRNET CHINA RAILWAY 
Internet(CRNET)
18 - AS9021 7775  0.6% 555.4 -- ISNET ISBANKASI Autonomous 
System
19 - AS6198 7755  0.6%  15.0 -- BATI-MIA - BellSouth Network 
Solutions, Inc
20 - AS346957252  0.5% 164.8 -- E4A-AS E4A Primary AS


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS3043 3039  0.2%3039.0 -- AMPHIB-AS - Amphibian Media 
Corporation
 2 - AS30298 988  0.1% 988.0 -- FIRST-AMERICAN-BANK-SSB - First 
American Bank
 3 - AS34378 900  0.1% 900.0 -- RUG-AS Razguliay-UKRROS Group
 4 - AS12922 842  0.1% 842.0 -- MULTITRADE-AS Bank Outsourcer
 5 - AS34984 794  0.1% 794.0 -- BITEL-AS BILISIM TELEKOM
 6 - AS35080 784  0.1% 784.0 -- OYAK-TELEKOM-AS Oyak Telekom 
Hizm. BGP AS
 7 - AS39298 762  0.1% 762.0 -- SERI Seri Bilgi Teknolojileri 
ve Destek Hizmetleri
 8 - AS4271 1493  0.1% 746.5 -- WORX - Networx
 9 - AS31526 745  0.1% 745.0 -- TEKOFAKS-AS TEKOFAKS
10 - AS29666 725  0.1% 725.0 -- TRHENKEL Turk Henkel Kimya 
Sanayi
11 - AS39080 721  0.1% 721.0 -- SIMETRI-AS SIMETRI YAZILIM
12 - AS313651432  0.1% 716.0 -- SGSTELEKOM SGS Telekom 
Autonomous System
13 - AS31085 711  0.1% 711.0 -- VIKINGNET-AS VIKING TUR
14 - AS29635 700  0.1% 700.0 -- BANVIT-AS Banvit A.S
15 - AS30734 682  0.1% 682.0 -- METISBILG-AS Metis Bilgi 
Sistemleri A.S
16 - AS31704 677  0.1% 677.0 -- ROBERTCOLLEGE-AS Robert College
17 - AS38920 676  0.1% 676.0 -- MNGBANK-TR Mng Turkiye
18 - AS39328 668  0.1% 668.0 -- BOTO-AS Borusan Oto
19 - AS31307 668  0.1% 668.0 -- YKYATIRIM YAPI KREDI YATIRIM
20 - AS295492646  0.2% 661.5 -- ZIRAATBANK-AS T.C. Ziraat 
Bankasi A.S.


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 202.125.147.0/24   3980  0.2%   AS17557 -- PKTELECOM-AS-AP Pakistan Telecom
 2 - 208.0.225.0/24 3068  0.2%   AS11139 -- CWRIN CW BARBADOS
 3 - 209.140.24.0/243039  0.2%   AS3043  -- AMPHIB-AS - Amphibian Media 
Corporation
 4 - 83.210.15.0/24 1843  0.1%   AS23918 -- CBB-BGP-IBARAKI Connexion By 
Boeing Ibaraki AS
 AS29257 -- CBB-IE-AS Connexion by Boeing 
Ireland, Ltd.
 AS30533 -- CONNEXION-BY-BOEING-LTN - 
Connexion by Boeing
 AS31050 -- CBB-RU-ASN Connexion by Boeing 
Eastern Europe, Ltd.
 AS33697 -- CONNEXION-BY-BOEING-VBC - 
Connexion by Boeing
 5 - 143.81.0.0/21  1618  0.1%   AS6034  -- DDN-ASNBLK - DoD Network 
Information Center
 6 - 205.98.32.0/20 1147  0.1%   AS5839  -- DDN-ASNBLK - DoD Network 
Information Center
 7 - 195.46.34.0/23 1013  0.1%   AS31200 -- NTK Novotelecom ltd.
 8 - 216.85.162.0/231001  0.1%   AS6467  -- ESPIRECOMM - Xspedius 
Communications Co.
 9 - 209.189.231.0/24988  0.1%   AS30298 -- FIRST-AMERICAN-BANK-SSB - First 
American Bank
10 - 205.97.69.0/24  933  0.1%   AS5839  -- DDN-ASNBLK - DoD Network 
Information Center
11 - 130.36.88.0/21  931  0.1%   AS2686  -- AT&T Global Network Services - 
EMEA
12 - 205.97.70.0/24  930  0.1%   AS5839  -- DDN-A

RE: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Jim McBurnett]

 If it gets to trial, I can see all kinds of stunts..
A jury trial on a highly technical issue?
We hope that ma and pa non-computer literate owners are not on the
jury

But I think Michael is right, too many technical errors and less than
accurate statements.
Someone does not understand what is going on and wrote an interesting
read of a case...

Later,
J
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, September 08, 2006 7:36 AM
To: [EMAIL PROTECTED]
Subject: Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have
feedback?]


> I am looking for anyone who has input on possibly the largest case 
> regarding internet numbering ever. This lawsuit may change the way 
> IP's are governed and adminstered. Comments on or off list please.

My personal opinion is that this is yet another example of ignorance
leading to anger leading to a stupid waste of court time. The case is
filled with incorrect statements of fact which ARIN can easily demolish.
But at the bottom line, these people are complaining because ARIN didn't
let them use some IP addresses that were assigned to a different
company.

Since IP addresses are basically available free from any ISP who sells
Internet access services, this seems like a severe error in judgement on
the part of the plaintiff. A smart businessperson would have used the
free IP addresses to keep their business online even if they did decide
to dispute ARIN's decision.

But in the end, IP addresses are not property, therefore they cannot be
assets and cannot be transferred. They can only be kept if they are in
use on network assets which are transferred and which continue to be
operational. And even then, most people have no choice as to which
specific address block they use. They simply take what the ISP gives
them.

I personally suspect that ARIN will have this thrown out of court in
fairly short order. Even if it did go much further, the parallels with
NANPA would see it fade away quite quickly. 

This discussion really belongs on http://www.groklaw.net/ where I note
it has not yet appeared. Perhaps another indication that this is a
tempest in a teapot.

--Michael Dillon

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Michael . Dillon]

> I am looking for anyone who has input on possibly the largest case
> regarding internet numbering ever. This lawsuit may change the way
> IP's are governed and adminstered. Comments on or off list please.

My personal opinion is that this is yet another
example of ignorance leading to anger leading to
a stupid waste of court time. The case is filled with
incorrect statements of fact which ARIN can easily
demolish. But at the bottom line, these people are
complaining because ARIN didn't let them use some
IP addresses that were assigned to a different company.

Since IP addresses are basically available free from
any ISP who sells Internet access services, this seems
like a severe error in judgement on the part of the
plaintiff. A smart businessperson would have used the
free IP addresses to keep their business online even if
they did decide to dispute ARIN's decision.

But in the end, IP addresses are not property, therefore
they cannot be assets and cannot be transferred. They can
only be kept if they are in use on network assets which are
transferred and which continue to be operational. And even
then, most people have no choice as to which specific 
address block they use. They simply take what the ISP gives
them.

I personally suspect that ARIN will have this thrown out 
of court in fairly short order. Even if it did go much
further, the parallels with NANPA would see it fade away
quite quickly. 

This discussion really belongs on http://www.groklaw.net/
where I note it has not yet appeared. Perhaps another 
indication that this is a tempest in a teapot.

--Michael Dillon

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[tony sarendal]

Interesting read.
http://www.internetgovernance.org/pdf/kremen.pdf#search=%22kremen%20vs%20arin%22



I found this little gem in the "The Internet, IP addresses and Domain Names" section:

---
Recently a new form of Internet addressing has emerged, called Classless
Inter-Domain Routing (CIDR).  In this new  addressing protocol, a CIDR network address
could look like this: 193.30.250.00/21. The prefix is the address of the network, or
gateway, and the number after the slash indicates the size of the network. The higher
the number, the more host space that is in the network(2).
...
---
(2) later contradicts this statement.

Maybe I should sell them some /32's, or why not a few /128's.

Or maybe I just have too much time on my hands.

/Tony

On 08/09/06, Chris Jester <[EMAIL PROTECTED]
> wrote:
I am looking for anyone who has input on possibly the largest caseregarding internet numbering ever. This lawsuit may change the wayIP's are governed and adminstered. Comments on or off list please.

Anyone have experiences like are said in the lawsuit? I would loveto know if this is true or not.  Anyone with negative ARIN experiencesthat relate to the lawsuit, please let me know, thanks!For thos interested, you may read this lawsuit here:

http://72.14.209.104/search?q=cache:44uxmnEmJVkJ:www.internetgovernance.org/pdf/kremen.pdf+Kremen+Vs+ARIN&hl=en&gl=us&ct=clnk&cd=1
Or google for Kremen VS ArinChris JesterSuavemente, INC.SplitInfinity Networks619-227-8845AIM: NJesterCQ: 64791506Chris JesterSuavemente, INC.SplitInfinity Networks
619-227-8845AIM: NJesterCQ: 64791506NOTICE - This e-mail and any files transmitted with it are confidential andare only for the use of the person to whom they are addressed. If you are
not the intended recipient you have received this e-mail in error. Any use,
dissemination, forwarding, printing, copying or dealing in any waywhatsoever with this e-mail is strictly prohibited. If you have receivedthis e-mail in error, please reply immediately by way of advice to us. It is
the addressee/recipient duty to virus scan and otherwise test theinformation provided before loading onto any computer system. Suavemente,INC.does not warrant that the information is free of a virus or any other defect
or error. Any views expressed in this message are those of theindividual sender, except where the sender specifically states them to bethe views of Suavemente, INC.

-- Tony Sarendal - [EMAIL PROTECTED]IP/Unix   -= The scorpion replied,   "I couldn't help it, it's my nature" =-

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Brandon Galbraith]

Two questions regarding thisfor the list (slightly OT):1) Has any sort of IP address ownership precedence been set in a US court?2) Isn't ARIN considered a non-profit resource management/allocation organization? To my knowledge, there is no "marketplace" for IPs.
Thanks!-brandonOn 9/8/06, Chris Jester <[EMAIL PROTECTED]> wrote:
I am looking for anyone who has input on possibly the largest caseregarding internet numbering ever. This lawsuit may change the wayIP's are governed and adminstered. Comments on or off list please.
Anyone have experiences like are said in the lawsuit? I would loveto know if this is true or not.  Anyone with negative ARIN experiencesthat relate to the lawsuit, please let me know, thanks!For thos interested, you may read this lawsuit here:
http://72.14.209.104/search?q=cache:44uxmnEmJVkJ:www.internetgovernance.org/pdf/kremen.pdf+Kremen+Vs+ARIN&hl=en&gl=us&ct=clnk&cd=1
Or google for Kremen VS ArinChris JesterSuavemente, INC.SplitInfinity Networks619-227-8845AIM: NJesterCQ: 64791506Chris JesterSuavemente, INC.SplitInfinity Networks
619-227-8845AIM: NJesterCQ: 64791506NOTICE - This e-mail and any files transmitted with it are confidential andare only for the use of the person to whom they are addressed. If you arenot the intended recipient you have received this e-mail in error. Any use,
dissemination, forwarding, printing, copying or dealing in any waywhatsoever with this e-mail is strictly prohibited. If you have receivedthis e-mail in error, please reply immediately by way of advice to us. It is
the addressee/recipient duty to virus scan and otherwise test theinformation provided before loading onto any computer system. Suavemente,INC.does not warrant that the information is free of a virus or any other defect
or error. Any views expressed in this message are those of theindividual sender, except where the sender specifically states them to bethe views of Suavemente, INC.
-- Brandon GalbraithEmail: [EMAIL PROTECTED]AIM: brandong00Voice: 630.400.6992"A true pirate starts drinking before the sun hits the yard-arm. Ya. --thelost"

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Jonathan Lassoff]

Chris Jester wrote:


I am looking for anyone who has input on possibly the largest case
regarding internet numbering ever. This lawsuit may change the way
IP's are governed and adminstered. Comments on or off list please.
Anyone have experiences like are said in the lawsuit? I would love
to know if this is true or not.  Anyone with negative ARIN experiences
that relate to the lawsuit, please let me know, thanks!

For thos interested, you may read this lawsuit here:
http://72.14.209.104/search?q=cache:44uxmnEmJVkJ:www.internetgovernance.org/pdf/kremen.pdf+Kremen+Vs+ARIN&hl=en&gl=us&ct=clnk&cd=1

Or google for Kremen VS Arin

Chris Jester
Suavemente, INC.
SplitInfinity Networks
619-227-8845

AIM: NJesterIII
ICQ: 64791506




Chris Jester
Suavemente, INC.
SplitInfinity Networks
619-227-8845

AIM: NJesterIII
ICQ: 64791506

NOTICE - This e-mail and any files transmitted with it are confidential and
are only for the use of the person to whom they are addressed. If you are
not the intended recipient you have received this e-mail in error. Any use,
dissemination, forwarding, printing, copying or dealing in any way
whatsoever with this e-mail is strictly prohibited. If you have received
this e-mail in error, please reply immediately by way of advice to us. It is
the addressee/recipient duty to virus scan and otherwise test the
information provided before loading onto any computer system. Suavemente,
INC.
does not warrant that the information is free of a virus or any other defect
or error. Any views expressed in this message are those of the
individual sender, except where the sender specifically states them to be
the views of Suavemente, INC.
  
This could be fairly interesting. One bit that did stick out is II. A. 
25 (I don't know what the proper notation for this should be), "Recently 
a new form of Internet addressing has emerged, called Classless 
Inter-Domain Routing (CIDR). In this new addressing protocol, a CIDR 
network address could look like this: 190.30.250.00/21. The prefix is 
the address of the network, or
gateway, and the number after the slash indicates the size of the 
network. The higher the number, the more host space that is in the network."


Well, last I checked, 1993 wasn't recent, and those last two sentences 
were quite a mistake.


Cheers,
jonathan

[Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Chris Jester]

I am looking for anyone who has input on possibly the largest case
regarding internet numbering ever. This lawsuit may change the way
IP's are governed and adminstered. Comments on or off list please.
Anyone have experiences like are said in the lawsuit? I would love
to know if this is true or not.  Anyone with negative ARIN experiences
that relate to the lawsuit, please let me know, thanks!

For thos interested, you may read this lawsuit here:
http://72.14.209.104/search?q=cache:44uxmnEmJVkJ:www.internetgovernance.org/pdf/kremen.pdf+Kremen+Vs+ARIN&hl=en&gl=us&ct=clnk&cd=1

Or google for Kremen VS Arin

Chris Jester
Suavemente, INC.
SplitInfinity Networks
619-227-8845

AIM: NJesterIII
ICQ: 64791506




Chris Jester
Suavemente, INC.
SplitInfinity Networks
619-227-8845

AIM: NJesterIII
ICQ: 64791506

NOTICE - This e-mail and any files transmitted with it are confidential and
are only for the use of the person to whom they are addressed. If you are
not the intended recipient you have received this e-mail in error. Any use,
dissemination, forwarding, printing, copying or dealing in any way
whatsoever with this e-mail is strictly prohibited. If you have received
this e-mail in error, please reply immediately by way of advice to us. It is
the addressee/recipient duty to virus scan and otherwise test the
information provided before loading onto any computer system. Suavemente,
INC.
does not warrant that the information is free of a virus or any other defect
or error. Any views expressed in this message are those of the
individual sender, except where the sender specifically states them to be
the views of Suavemente, INC.

Re: Multiple BGP Routes in FIB

[Sam Stickland]

Hi Glenn,

Glen Kent wrote:


Hi,

There is an interesting discussion going on in the IDR WG and i am
cross posting a mail on Nanog to hear from the operators, if what is
described below, a common practise followed by them:


>> I don't think its correct to advertise one while using both for
>> forwarding.
>> NOTE: I am assuming that the routes share the same path length but 
have

>> different AS Paths (as mentioned by you earlier in this mail)
>
> I think this is being done by many providers.

Consider two paths for nlri X

as_path 1 {x y z} next_hop n1
as_path 2 {m n z} next_hop n2

Are you suggesting that providers are installing ecmp routes for X with
next-hops n1 and n2, while advertising only one of the paths to their 
IBGP

peers?


Yes.


Do providers really do this? Would they install multiple BGP Paths
with different AS Paths (but same length) in their FIB, and yet
advertise only one?

Is the the right thing to do?


I believe the problem is with the BGP withdrawal mechanism. When BGP 
withdraws a route it only specifies the prefix being withdrawn and not 
the path. In this case, if the peer advertised both paths {x y z} and {m 
n z} for a single prefix it would be impossible to withdraw only one of 
the paths. I guess, even when using ECMP, BGP still really only 
considers there to be one best route. Everything else is local FIB 
manipulations based on local policy (in a similar vein to policy routing 
- the BGP advertisements don't always reflect which way the traffic will 
actually be routed).


Sam

FreeBSD Security Advisory FreeBSD-SA-06:20.bind (fwd)

[Gadi Evron]

-- Forwarded message --
Date: Wed, 6 Sep 2006 21:59:43 GMT
From: FreeBSD Security Advisories <[EMAIL PROTECTED]>
Reply-To: freebsd-security@freebsd.org
To: Bugtraq 
Subject: FreeBSD Security Advisory FreeBSD-SA-06:20.bind

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

=
FreeBSD-SA-06:20.bind   Security Advisory
  The FreeBSD Project

Topic:  Denial of Service in named(8)

Category:   contrib
Module: bind
Announced:  2006-09-06
Credits:The Measurement Factory
Affects:FreeBSD 5.3 and later.
Corrected:  2006-09-06 21:18:26 UTC (RELENG_6, 6.1-STABLE)
2006-09-06 21:19:21 UTC (RELENG_6_1, 6.1-RELEASE-p6)
2006-09-06 21:20:08 UTC (RELENG_6_0, 6.0-RELEASE-p11)
2006-09-06 21:20:54 UTC (RELENG_5, 5.5-STABLE)
2006-09-06 21:21:50 UTC (RELENG_5_5, 5.5-RELEASE-p4)
2006-09-06 21:22:39 UTC (RELENG_5_4, 5.4-RELEASE-p18)
2006-09-06 21:23:16 UTC (RELENG_5_3, 5.3-RELEASE-p33)
CVE Name:   CVE-2006-4095, CVE-2006-4096

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
http://security.freebsd.org/>.

I.   Background

BIND 9 is an implementation of the Domain Name System (DNS) protocols.
The named(8) daemon is an Internet domain name server.  DNS Security
Extensions (DNSSEC) are additional protocol options that add
authentication and integrity to the DNS protocols.

II.  Problem Description

For a recursive DNS server, a remote attacker sending enough recursive
queries for the replies to arrive after all the interested clients
have left the recursion queue will trigger an INSIST failure in the
named(8) daemon.  Also for a a recursive DNS server, an assertion
failure can occour when processing a query whose reply will contain
more than one SIG(covered) RRset.

For an authoritative DNS server serving a RFC 2535 DNSSEC zone which
is queried for the SIG records where there are multiple SIG(covered)
RRsets (e.g. a zone apex), named(8) will trigger an assertion failure
when it tries to construct the response.

III. Impact

An attacker who can perform recursive lookups on a DNS server and is able
to send a sufficiently large number of recursive queries, or is able to
get the DNS server to return more than one SIG(covered) RRsets can stop
the functionality of the DNS service.

An attacker querying an authoritative DNS server serving a RFC 2535
DNSSEC zone may be able to crash the DNS server.

All of the above issues will result in a Denial of Service situation.

IV.  Workaround

A possible workaround is to only allow trusted clients to perform recursive
queries.

V.   Solution

Perform one of the following:

1) Upgrade your vulnerable system to 5-STABLE, or 6-STABLE, or to the
RELENG_6_1, RELENG_6_0, RELENG_5_5, RELENG_5_4, or RELENG_5_3 security
branch dated after the correction date.

2) To patch your present system:

The following patches have been verified to apply to FreeBSD 5.3, 5.4,
5.5, 6.0, and 6.1 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

# fetch http://security.FreeBSD.org/patches/SA-06:20/bind.patch
# fetch http://security.FreeBSD.org/patches/SA-06:20/bind.patch.asc

b) Execute the following commands as root:

# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/lib/bind
# make obj && make depend && make && make install
# cd /usr/src/usr.sbin/named
# make obj && make depend && make && make install

c) Restart the named application:

# /etc/rc.d/named restart

VI.  Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

Branch   Revision
  Path
- -
RELENG_5
  src/contrib/bind9/bin/named/query.c 1.1.1.1.2.3
  src/contrib/bind9/lib/dns/resolver.c1.1.1.1.2.5
RELENG_5_5
  src/UPDATING 1.342.2.35.2.4
  src/sys/conf/newvers.sh   1.62.2.21.2.6
  src/contrib/bind9/bin/named/query.c 1.1.1.1.2.2.2.1
  src/contrib/bind9/lib/dns/resolver.c1.1.1.1.2.4.2.1
RELENG_5_4
  src/UPDATING1.342.2.24.2.27
  src/sys/conf/newvers.sh  1.62.2.18.2.23
  src/contrib/bind9/bin/named/query.c 1.1.1.1.2.1.4.1
  src/contrib/bind9/lib/dns/resolver.c1.1.1.1.2.2.2.1
RELENG_5_3
  src/UPDATING1.342.2.13.2.36
  src/sys/conf/newvers.sh