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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Owen DeLong write
s:
>
> On May 28, 2014, at 2:21 AM, Tore Anderson <[e-mail]> wrote:
>
> > * Doug Barton
> >
> >> We have a substantial number of medium-sized enterprises which share
> the
> >> following characteristics:
> >>
> >> 1. They are large enough to have some internal resources that need
> >> addressing (printers, file servers, maybe a web site or two)
> >>
> >> 2. They are small enough that PI space and their own ASN are not
> practical
> >
> > You don't need an ASN to use PI space.
>
> Except possibly in the APNIC region due to previously discussed very high
> fees,
> I'm not sure why you think PI space is not practical for small
> organizations. I've
> set up multi homed connections for a number of small businesses,
> including even
> some one-man operations with gross revenues under US $250,000 annually.

Because it is actually more error prone than ULA when you are not
able to use the prefix for routing as there is no automatic built
in support.  Also running two GUA in parallel (PA + non-routeable
PI) will be harder to debug.  I realise that your PI is being routed.
You are the exception here.

This will actually encourage more NATPT or traditional NAT than ULA
will as the defaults are right for ULA + PA.

You are trading off P(collision) of epsilion when merging two ULA
domains with a continual debugging and configuration issues.  Every
time you add a router you need to remember to filter this prefix
to get ICMP unreachable returned.  If you have multiple sites then
you have lots of per site configuration.

With ULA I can see fd..... and identify that it is a ULA address
so I can easily see when a node is choosing the wrong address when
debugging.

Remember also homenet is doing SADR.  It so there will be even more
pressure to not announce yet another prefix as support for that
gets added to the very low end CPE devices.  If they can do it all
the more professional devices will need to support it so there will
be no escaping it.

If you get to the stage where you can get a PI routed, then sure use
that, but until you are at that stage non-routed PI is actually worse.

> >> 3. Some of them want to have multiple service providers, either for
> >> failover or traffic shaping
> >>
>
> Which makes an ASN and a PI prefix the easiest tactic possible.
> (Even easier than NAT, really.)
>
> >> 4. They don't want to have to renumber all of their internal resources
> >> when they change providers
> >>
> >> What's your solution for them?
> >
> > 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 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.
>
> Owen
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]