| 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. -- Richard Cox

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

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

...

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

On Thu, 2004-06-24 at 06:49, Valdis.Kletnieks@vt.edu wrote:

On Wed, 23 Jun 2004 15:48:14 MDT, John Neiberger <John.Neiberger@efirstbank.com> said:

...

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.

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... :)

I think you meant IANA there, not ARIN ;) 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 ;) 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 :) Greets, Jeroen