RE: Can a customer take IP's with them?

Mailman List Mirror (Read Only)
1

Let me try to give you a hypothetical to show you why ARIN is

irrelevent.

Suppose I am a member of the Longshoreman's assocation and you have a
contract to buy shrimp for $8/pound provided you only resell it to

members

of the LA. You then enter into a contract with me to sell me shrimp

for

$10/pound. But then I leave the LA. Ooops, now you can no longer

resell me

the shrimp. So you break our contract and I sue you. Does your

contract with

your shrimp provider matter? If you continue to sell me shrimp even

though

I'm not in the LA, who does your shrimp supplier sue? You or me?

Is this analogy really accurate? In your analogy, the person who
initially purchases the shrimp actually *owns* the shrimp at that point.
With IP address space, the ISP does not own the space that it allocates.
It's really just sub-letting the space already allocated to it.

IANAL, but it appears that from a contractual perspective it is clear
that ARIN retains all 'ownership' rights to the address space. They
subdivide it to those who are willing to contractually agree to their
conditions, but the ownership is never transferred. I would think that
that is an important distinction to make.

Perhaps not.

John

2

Is this analogy really accurate? In your analogy, the person who
initially purchases the shrimp actually *owns* the shrimp at that point.
With IP address space, the ISP does not own the space that it allocates.
It's really just sub-letting the space already allocated to it.

  Doesn't matter. This issue has nothing to do with ownership. It just has to
do with the ISP continuing to allow their customer to use the IPs. The ISP
certainly has the ability and authority to do that.

IANAL, but it appears that from a contractual perspective it is clear
that ARIN retains all 'ownership' rights to the address space. They
subdivide it to those who are willing to contractually agree to their
conditions, but the ownership is never transferred. I would think that
that is an important distinction to make.

  Why? Nobody cares who owns the IPs, just whether or not the ISP allows the
customer to continue using them, which the ISP certainly has the ability to
do.

  DS

3

Why? Nobody cares who owns the IPs, just whether or not the ISP allows
the customer to continue using them, which the ISP certainly has the
ability to do.

Not necessarily. Use of the IPs is effectively licensed to the ISP by
the RIR, and sublicensed by the ISP to the user. If either breaches any
conditions under which the IPs are licensed, then the ISP should expect
to LOSE the right to sublicense them.

4

although the IP address block becomes damaged goods, as there
are more than a few ISPs that will ignore any announcement that's
broken out of an aggregate. if your /24 is broken out of TWD space,
sure, people will listen, but if you've got a /21 that was given to you
by NAC, and you're not a NAC customer any more, then i somehow
suspect you'll have trouble reaching verio space, just to name one.

additionally, how is the ISP to account to ARIN for this block should
they go back for more space?

there is a widely accepted understanding of how this is all supposed
to work, and if the ex-NAC customer succeeds in gaining this TRO,
and it becomes a pattern across the industry, then everybody's
connectivity, router tables, and support budget will likely suffer.

richard

5

additionally, how is the ISP to account to ARIN for this block should
they go back for more space?

  They show ARIN a copy of the TRO. Really.

there is a widely accepted understanding of how this is all supposed
to work, and if the ex-NAC customer succeeds in gaining this TRO,
and it becomes a pattern across the industry, then everybody's
connectivity, router tables, and support budget will likely suffer.

  Unfortunately, courts are generally not impressed by the "if everybody did
it" argument. In each case, they'll look at the actual incrementlay harm the
TRO will do in that particular case. I do agree, however, that it's very
important that if these cases do come to court, the ISPs win as many of them
as possible. Each loss makes the next loss easier.

  The reason I'm pointing out which strategies are unlikely to work is not
because I hope they won't work but because I want him to make sure to
emphasize the strongest possible arguments. IMO, these are:

  1) The emergency is of the customer's own creation. He had plenty of time
to renumber and didn't.

  2) There is no significant harm in renumbering immediately. Techniques such
as 1-to-1 NAT exist for exactly this purpose.

  3) DNS creates a portable namespace, so there's no legitimate portability
issue here. This is not like bringing your phone number with you when you
change providers but like bringing your phone *line* with you when you move
across the country.

  I would not try to argue that it harms you significantly to allow them to
continue using the IP space. I just don't see any honest way to show that
there's real harm. Perhaps in your specific situation there's such a way.
But defending abstract principles about router table sizes isn't likely to
work. The court will weigh the harm of the one advertisement.

  Don't forget, though, the customer can't get the TRO, regardless of the
balance of the hardships, unless they're likely to be entitled to it. So
look into the details of how the contract got terminated, and if it's
because of the customer's own actions, they're not likely to be entitled to
the relief the TRO seeks to get anyway.

  DS

6

you omit argument 4:

a TRO against nacs.net has no effect on the behavior of providers
such as verio who won't honor the advertisement of the subnet
in BGP. the customer would have to, one-by-one i think, go after
everybody with the relatively common policy of ignoring such
advertisements (isn't sprint one of these? that'd be a pretty big
hunk of internet to be disconnected from. sprint having no
contractual relationship with the idiot, er, customer in question,
it'd be hard for the customer to get anywhere there.)

in other words, by itself the requested TRO incompletely solves
the problem, making it fairly pointless.

richard

7

a TRO against nacs.net has no effect on the behavior of providers
such as verio who won't honor the advertisement of the subnet
in BGP. the customer would have to, one-by-one i think, go after
everybody with the relatively common policy of ignoring such
advertisements (isn't sprint one of these? that'd be a pretty big
hunk of internet to be disconnected from. sprint having no
contractual relationship with the idiot, er, customer in question,
it'd be hard for the customer to get anywhere there.)

in other words, by itself the requested TRO incompletely solves
the problem, making it fairly pointless.

  We don't know enough about the specifics to know if this argument works or
not. There are two obvious cases where it doesn't:

  1) The block in question is large enough (or located in legacy space) such
that most/all providers will listen to it anyway.

  2) The customer's new provider meets with their old provider directly and
the new block is inside a larger block the original provider will continue
to advertise. (This is a very common case if both providers are large.)

  It's worth pointing out, however, that if case 2 applies and case 1
doesn't, then the ISP will still be providing a level of actual packet
carrying service to the customer. It is grossly unfair to expect a provider
to do this for free, assuming they didn't do something equally unfair to the
customer. Which is why it will really come down to the merits of the actual
dispute between the customer and the ISP.

  The TRO is an interesting sideshow, but really in the scheme of things not
a particulary big deal. Remember, to get a TRO you must show that you
(likely) deserve it equitably, otherwise the hardship issue doesn't come
into play. It is, however, a good warning for ISPs. Make sure your contracts
with your customers stipulate that IP assignments are to follow ARIN's
published policies and that they may be revoked by you or ARIN for
non-compliance with standard practices. Also clearly state what your
renumbering policies and advertisement by other provider policies are.
What's obvious to you may not be obvious to your customers and you can't
expect to be assured of being able to enforce your contracts with ARIN on
your customers.

  DS

8

> a TRO against nacs.net has no effect on the behavior of providers
> such as verio who won't honor the advertisement of the subnet
> in BGP. the customer would have to, one-by-one i think, go after
> everybody with the relatively common policy of ignoring such
> advertisements (isn't sprint one of these? that'd be a pretty big
> hunk of internet to be disconnected from. sprint having no
> contractual relationship with the idiot, er, customer in question,
> it'd be hard for the customer to get anywhere there.)
>
> in other words, by itself the requested TRO incompletely solves
> the problem, making it fairly pointless.

  We don't know enough about the specifics to know if this argument works or
not. There are two obvious cases where it doesn't:

  1) The block in question is large enough (or located in legacy space) such
that most/all providers will listen to it anyway.

maybe. many filtering policies against legacy space are pretty severe
(e.g., filter at /16 for legacy B space.) you'd have to have a block of /20
or larger for modern allocations.

  2) The customer's new provider meets with their old provider directly and
the new block is inside a larger block the original provider will continue
to advertise. (This is a very common case if both providers are large.)

  It's worth pointing out, however, that if case 2 applies and case 1
doesn't, then the ISP will still be providing a level of actual packet
carrying service to the customer.

bzzzzt. if the ISPs have sensible policy implementations at the border,
nobody will be be providing free transit because of accidents of
adjacency.

richard

9

IANAL either, but I believe that ARIN doesn't claim to own 32-bit integers.
What they're providing is a *registry service* to keep track of what entities
are using what ranges of 32-bit integers, to prevent duplication. There's no
*requirement* that you use any particular address range, except that by
community agreement, nobody wants to deal with non-registered addresses.

If ARIN actually *owned* the address space, we'd not have the perennial
flame-war regarding 1918-space source addresses on the global net - everybody
would do a really fast and good job of implementing ingress/egress filtering
because ARIN could sue you for using their addresses... :slight_smile:

10

> It's worth pointing out, however, that if case 2 applies and case 1
> doesn't, then the ISP will still be providing a level of actual packet
> carrying service to the customer.

bzzzzt. if the ISPs have sensible policy implementations at the border,
nobody will be be providing free transit because of accidents of
adjacency.

  I wasn't talking about accidents. The draft TRO could easily be read as
requiring them to hear the announcement and carry the traffic.

"NAC shall permit CUSTOMER to continue utilization through any
carrier or carriers of CUSTOMER's choice of any IP addresses that were
utilized by, through or on behalf of CUSTOMER under the current agreement
during the term thereof (the "Prior CUSTOMER Addresses") and shall not
interfere in any way with the use of the Prior CUSTOMER Addresses,"

"(iii) by directly or indirectly causing reduced prioritization of access to
and/or from the Prior CUSTOMER Addresses."

  It's a good point though that this requires you to effectively continue to
provide the customer with service.

  DS

11

I think you meant IANA there, not ARIN :wink: Indeed nobody will complain if
you setup your own RIR and start handing out addresses, it is a registry
and those work as long as common believe is that they are the central
sources of authority. The same goes for DNS and basically everything
else.

On another, related note:

RFC2544 (C.2.2):
8<--------------------------
   The network addresses 192.18.0.0 through 198.19.255.255 are have been
   assigned to the BMWG by the IANA for this purpose. This assignment
   was made to minimize the chance of conflict in case a testing device
   were to be accidentally connected to part of the Internet. The
   specific use of the addresses is detailed below.
-------------------------->8
Thus 192.18.0.0/15 is IANA ?reserved? for the BMWG (btw note also
the "are have been" ;), but in whois.arin.net:

8<--------------------------
OrgName: Sun Microsystems, Inc
OrgID: SUN
Address: 4150 Network Circle
City: Santa Clara
StateProv: CA
PostalCode: 95054
Country: US

NetRange: 192.18.0.0 - 192.18.194.255
CIDR: 192.18.0.0/17, 192.18.128.0/18, 192.18.192.0/23,
192.18.194.0/24
NetName: SUN1
NetHandle: NET-192-18-0-0-1
Parent: NET-192-0-0-0-0
NetType: Direct Allocation
NameServer: NS1.SUN.COM
NameServer: NS2.SUN.COM
NameServer: NS7.SUN.COM
NameServer: NS8.SUN.COM
Comment:
RegDate: 1985-09-09
Updated: 2003-10-10
------------------------->8

The RFC is from 1999, according to the above Sun owns and is using that
block a lot longer.... what is correct?
RFC1944 (from 1996) also notes that block.
RFC1062 (from 1988) then again mentions SUN there :wink:

Anyone who has some thoughts about this?
Because a /15 is a very nice testrange if you don't want to break
connectivity to existing rfc1918 addresses and of course not to forget
SUN if you like watching pictures of highend servers to name an example
:slight_smile:

Greets,
Jeroen