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

[Owen DeLong <[e-mail]>]

On May 28, 2014, at 2:52 PM, Tore Anderson <[e-mail]> wrote:

> * 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.

If I’m advertising to the upstreams via BGP, then when I drop the routes to
them, they stop advertising them to the world and thus there’s no black hole.

OTOH, when you’re advertising my routes on a static basis without peering with
me, then if I drop my connection to you, your routers don’t know/don’t care and
still keep advertising my routes.

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

Sure, but it’s much more common in the scenario you described than in the
scenario where the customer is sending you BGP announcements and you don’t
know about the customer’s prefix other than when you hear it from the customer
via BGP.

> 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».

Then you are living in an imaginary world where magic happens without a routing
protocol to prevent continued advertisement of a prefix that no longer has a
feasible successor. In the real world, this usually doesn’t happen without a routing
protocol.

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

Since I can run sufficient BGP for an end site on a Raspberry PI with a
second ethernet, using free software, I have trouble buying that argument.

As to the “how to configure” problem, that’s 2 hours (max) of some consultants
time (any smart ISP offers this as a professional services value add) and
can be pretty much fire and forget for the scenario in question.

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

It’s really not less complex than BGP where the customer advertises his
prefix and receives default. Nor does it require particularly expensive
hardware. Admittedly, the R-PI is probably a little too low-brow for
most situations, but a Juniper SRX-100, <$200 Mikrotik, or a variety of
other solutions can be made to work for ≤$600 total hardware and software.
Most of them can even take a full IPv6 table, while you get into real money
if you want a full IPv4 table.

Owen