Bad routes update

Magnus Ahltorp map@stacken.kth.se
20 Jul 1999 20:58:10 +0200


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

There is an internet-draft on how to use Mobile IP to solve this
issue.

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

There were presentations in Oslo that addressed these issues.

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

Do you really think that there are only 80000 sites that want to be
multi-homed?

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

And in what way is 16 addresses "many"? Compared to most IPv4 hosts,
it's a huge amount, but then, this isn't IPv4.
 
> >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 

The DNS issues are addressed by the A6 RR.

> and route filter updates, for example. There is going to be manual
> intervention required all along the track.

IP number dependency in route filters is just broken anyway. Normally,
filters are there to allow or disallow some pattern of
source/destination IP address prefixes and port numbers. I don't
really see the problem in making those IP address prefixes symbolic.
Once they are symbolic, I don't see why automatic updating and
multiple prefixes should be a problem.

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

Yes, the requirement to multi-home increases. It will continue to
increase. _That_ is the reason for not allowing IPv4 style
multi-homing. The routing tables would become enormous.

/Magnus