Subject: MultiHoming with IPv6

From: Joe Abley <[email-masked]>
Date: Wed, 21 Jul 1999 21:13:57 +1200

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 <[email-masked]>
To: Craig Metz <[email-masked]>
Cc: Richard Draves <[email-masked]>, [email-masked]
Subject: Re: Bad routes update
X-Mailer: Mutt 0.95.4i
In-Reply-To: <[email-masked]>; 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 <[email-masked]>      Tel +64 9 912-4065, Fax +64 9 912-5008
Te Kaihoahoa Kawei, CLEAR Communications Ltd      http://www.clear.net.nz/
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Jul 1999 09:34:30 -0500

Joe,

The multihoming proposal presented last week in Oslo
(OK, a long way from NZ but I did spot one Kiwi there :)
specifically deals with operational backup, without
requiring TCP connections to survive prefix changes,
and without compromising aggregation. I think when you
see it written up in a draft it will address most of
your concerns, but your comments from an operational 
perspective will be highly valuable.

Your concerns about renumbering, a.k.a. prefix updates, are 
valid. There is more work to be done on the automation of
downstream prefix updates, but remember that a prefix
update is not a flag-day operation; the old and new
prefixes can co-exist for as long as needed operationally.
We do need A6 records for this to work properly.

  Brian Carpenter

---

From: "Ted Rohling" <[email-masked]>
Date: Wed, 21 Jul 1999 07:09:55 -0500

Has anyone taken the time to develop a list of things we can do in IPv4 and
determine exactly how they are going to be done in IPv6.  I know IPv6 has
lots of new stuff but what about the old stuff.  IE.

Assignment of DNS server address during autoconfiguration.
Forced selection of "gateway" router during autoconfiguration when there are
multiple routers attached to a segment.
Assignment of Node names and Domain names during autoconfiguration.
..... and the list goes on.

These may not be extremely interesting developmental issues but until the
ADMINISTRATIVE trivia is taken care of and people understand how things will
work, IPv6 remains a mystery and an interesting yet unnecessary opportunity
to avoid.  For those of you who are implementors or developers, remember
that the fruits of your labors have to be used by someone.  A simple "that
will be handled by individual implementations" is not a satisfactory answer
to those of us who will live with this in the real world.

Hope this doesn't generate a stream of protests but during the next IETF
meeting, why doesn't someone undertake this in a committee meeting and help
us in the user community understand why this is so useful.

Thanks for listening

---

From: Bill Axelrod <[email-masked]>
Date: Wed, 21 Jul 1999 13:38:46 -0400

I agree with Ted completely.

From a maintainer/end-user point of view, I'd want to
know that IPv6 has been fully functionality regression
tested and that any migration plans include methods to
overcome any ways where the functionality or the
implementation processes change.

Would the NGTRANS (Next Generation Transition) working group
be better suited to research this?

Bill

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Ted Rohling
Sent: Wednesday, July 21, 1999 8:10 AM
To: [email-masked]
Subject: Time for a Review

Thanks for listening

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Jul 1999 08:21:02 -0500

Indeed. There is a plan to commission such a review by the IESG,
since it is an IETF-wide issue. (Think of it as somewhat like
the Y2K review recently published.) Hopefully this will start pretty
soon. 

  Brian Carpenter

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM Internet Div
On assignment for IBM at http://www.iCAIR.org 
Non-IBM email: [email-masked]