MultiHoming with IPv6

[Joe Abley]

Hi,

I've been cluttering the 6bone list with some concerns about multi-
homing from an operational perspective, and the subject has been deemed
off-topic for now.

Rob Rockell of Sprint suggested this was a better place to raise some
of the issues in the post that follows, so here we go. Apologies for
not lurking for longer than two minutes before barging in :)

6bone folk: apologies for the rude bcc'ing; just letting people know
where at least one branch of this thread has been taken.

I have been surprised by some of the vehement opposition to the idea of
compromising the pure backbone aggregation model, given the amount of
complexity that seems to be involved in the alternatives.

Is it not more reasonable to expect to have to make compromises in
this area, in the interests of a realistic transition to IPv6? Isn't
it _unreasonable_ to effectively change the semantics of TCP, such that
a distant network event could disrupt an active session (by making
one or both endpoint addresses unreachable), rather than allowing it to
recover and continue?

Earlier 6bone post is attached, to provide some context.


Joe

---

Date: Tue, 20 Jul 1999 21:33:34 +1200
>From: Joe Abley <jabley@clear.co.nz>
To: Craig Metz <cmetz@inner.net>
Cc: Richard Draves <richdr@microsoft.com>, 6bone@ISI.EDU
Subject: Re: Bad routes update
X-Mailer: Mutt 0.95.4i
In-Reply-To: <199907200655.GAA26375@inner.net>; from Craig Metz on Tue, Jul 20,
1999 at 02:55:44AM -0400
Precedence: bulk

Hi,

On Tue, Jul 20, 1999 at 02:55:44AM -0400, Craig Metz wrote:
> In message <4D0A23B3F74DD111ACCD00805F31D810145155E7@RED-MSG-50>, you write:
> >> >3FFE:F00:2::0/48          11261
> >>
> >>   This is not a bogus route per se. I told them to set it up
> >> this way. I have
> >> been recommending that non-pTLA multi-homed sites use a /48,
> >> which happens to
> >> mesh nicely with the way I've been managing tunnel address
> >> space at NRL.
> >
> >This is bogus - the backbone should only see /24s.
>
>   First off, you're going to have a very hard time arguing that the new /28s
> shouldn't be seen. Second, there *must* be some provision for sites to
> multi-home without being a full pTLA, or pTLA allocations will explode as will
> the allocations of pTLAs to people who shouldn't have them.
 
I was going to keep quiet about this until I had done a lot more reading,
but it seems that perhaps things aren't as cut and dried as I had imagined,
and perhaps there is some benefit in raising this on the 6bone list.
 
I asked questions about multi-homing a long time ago, and the prevelant
answer at the time (which I am hearing from Richard again, so I guess it
hasn't changed) was:
 
 o  if you connect to multiple pTLAs, you will get multple allocations
    of address space, since aggregation in the backbone is important and
    must not be compromised.

 o  if you connect to an NLA which is multi-homed, you will be provided
    with multiple addresses for every host.

I raised some issues regarding resilience of individual TCP sessions
in the event of a pTLA-NLA event upstream, and the answers were (and are):

 o  stability of individual sessions is not important in the event of
    a routing change upstream;

 o  having _new_ sessions connect correctly (i.e. handling the change
    of TCP session endpoint address) is more important; this will be done by

 o  an algorithm for choosing suitable source and destination addresses
    for TCP virtual circuit endpoints that will become clear with
    operational experience.

I am not convinced by the first point, and the second and third ideas
look very clumsy to me. Much more clumsy than having long-prefix routes
injected into the backbone, leading to routers with 80,000 routes in them,
to be honest. Personal opinion, and a little diversionary.

My real concern is the operational impact of managing IP addresses of
end users, or of the administrators just before the end-users. Suppose
we, as a large (by NZ terms; tiny in global terms) operator decide to
multi-home to four backbone providers. We will not be alone; other
providers in NZ will do similar things. This happens now with IPv4
in one way or another.

Today we have smaller ISPs who dual-attach to two or more of the major
carriers.

And below them we have customers who dual-home between ISPs.

All this dual-homing is done for a reason, and that's diversity -- the
way we build fault tolerance into our IP networks is to provision multiple,
diverse and independent paths, and to advertise our networks in every
direction. This takes care and skill to manage correctly, but if done
well can be very effective.

With IPv6, this means that the poor customer will need to number each
address on their equipment with as many as 16 different addresses
(their upstreams will each have to deal with 8).

>From an operational perspective, we deal with dual-homed customers today
who do not have technical staff in-house -- they hire it in, by the
hour, and pay through the nose for it. A change in a customer
relationship for one of the NLAs (who have no direct relationship with
the end customer in question) now has the knock-on effect of requiring
all downstream users to change addresses on their interfaces.

I believe the IPv6 autoconfiguration story, but only as far as it
goes -- I don't believe in effective automatic DNS and route filter
updates, for example. There is going to be manual intervention required
all along the track.

The number of end-users just in our customer base that have a business
requirement to multi-home increases every month.

This sounds a little bit like a nightmare. Is this for real? This
sounds a little less like IP, and a little more like E.164 number
portability in the switched voice network, complete with business
cards that need re-printing every two months (cue Psycho violins,
trembling shower curtain, shadow of hand c/w bloody knife).

For pTLA above, also read TLA in the real network -- I am presuming
that the original aims of the 6bone hold true, and that operational
procedures developed here will migrate their way to the Real Network.

I still presume that I am under some basic misconception that, once
cleared, will leave me happy and relaxed. The sooner someone can
point it out to me, the sooner I can get some sleep :)


Joe

--
Joe Abley <jabley@clear.co.nz>      Tel +64 9 912-4065, Fax +64 9 912-5008
Te Kaihoahoa Kawei, CLEAR Communications Ltd      http://www.clear.net.nz/