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

[Richard Welty <rwelty () averillpark net>]

On Wed, 23 Jun 2004 18:40:06 -0700 David Schwartz <davids () webmaster com> wrote:



> > 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
-- 
Richard Welty                                         rwelty () averillpark net
Averill Park Networking                                         518-573-7592
    Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security