Re: [v6ops] ULA draft revision #2 Regarding isolated networks

[Tore Anderson <[e-mail]>]

* Owen DeLong

> On May 28, 2014, at 2:21 AM, Tore Anderson <[e-mail]> wrote:
> 
>> We have a few customers in the same situation. So we obtained a PI
>> prefix for them, which costs next to nothing in the RIPE region at
>> least, and advertise the prefix on their behalf (and in the cases 
>> where there's a second upstream, the second upstream does the 
>> same). Works perfectly well, and is much less complex than
>> anything solution involving ULA, NAT, multiple prefixes on the
>> hosts, or whatever. The customer just gets a bunch of addresses he
>> can use in perpetuity.
> 
> Exactly, but it does have the drawback of black holing traffic in 
> certain failure modes.

If the upstream starts blackholing in his core network somewhere and the
customer is singlehoming, he's toast no matter how he's connected to the
upstream. If he's multihoming, however, he can just physically pull the
plug or shut the interface and traffic converges on the remaining good
upstream, in pretty much in the same way it would if he used BGP.

Of course, if the problematic upstream provider doesn't withdraw the BGP
announcement when the customer shuts his interface then there's still
going to be a problem, but that's equally true both for connections with
or without BGP between the provider and the customer.

Blackholing of traffic during failure modes is something you can get
with any form of deployment. The way I see it, the use of BGP or non-use
of BGP doesn't really change the risks of this happening either for the
worse or the better. So I don't quite see why you call this a «drawback».

> If you really want to avoid an ASN (not sure why), it is possible to
> do this using a private ASN that is stripped off by the upstream
> provider(s), but using a real ASN is much simpler.

It's not I who want to avoid it, it's the end user. He doesn't
necessarily know how internet routing works, how to set up or operate
BGP, have equipment that can do so [without extra licences], and so
forth. Even if he does, he might not want the extra bother. So the point
isn't to avoid an ASN - if the customer is going to use BGP it's simpler
with an ASN than without - but to avoid requiring BGP.

Where the end user simply wants plain no bells-and-whistles internet
service, but require addresses that work with >1 upstream provider
simultaneously or which may be kept should he decide to switch providers
in the future, using a PI prefix that his upstream(s) originate into the
DFZ on his behalf is a really simple solution that actually works today
both for IPv6 *and* IPv4 (if you have them, that is). It's much less
complex than any solution I've seen that involves ULAs, NPT/NAT, BGP,
multi-prefixes, or anything else, which makes it my preferred way of
catering to the customers in question - for now.

Tore