Multi homing & NLAs.

[Peter Tattam]

On Fri, 23 Apr 1999, Brian E Carpenter wrote:

> I don't think we should worry about the singly addressed
> version of multihoming. There's no reason to, since we can use
> multiple addresses.
> 
> I think that a PASTE-like mechanism resolves the failover
> problem that Perry was worrying about. And surely nobody writes
> serious apps that depend on long-term TCP sessions surviving?
> If you need that kind of assurance you build it into the app.
> 
> I take Jim's point that in some situations address selection
> can be pretty subtle and it should be/must be addressed in its
> own document.
> 
> But please let's not try and solve all this by tweaking the
> address allocation policy. We have running code proof that
> this is a broken solution.

I fully understand and would not realy want to alter it.  However to
sustain the policy,  we need to solve the source address problems.
Firstly selection of source address which appears to be manageable, and
secondly modifying the source address of long running tcp connections.

I stand by my firm opinion that it is not acceptable to insist on higher
layers having to reestablish a tcp connection in the case of a network
outage.   It will cause significant disruption to a wide array of existing
applications that rely on state information being bound to the tcp/ip
connection.

By solving one problem, we create a problem elsewhere in the IP framework. 
I don't believe this is progress, and if enough people perceive the issue
in the wrong way.... well, I'm not going to say any more as I will get
blasted again. 

Peter

> 
>     Brian
> 
> 
> Peter Tattam wrote:
> > 
> > I'm sorry if I've confused people about the multihoming issue.  The
> > discussion has helped me to resolve some issues but not others.
> > 
> > First some terminology issues for the discussion.
> > 
> > When I refer to "multi-homing",  I am using a broad definition of "being
> > connected to the internet at more than one place in the internet
> > topology".   This means that I could be connected at two or more points
> > anywhere in the internet, and not restricted to a region.
> > 
> > When I refer to "multi-addressing" I am referring to the ability for a
> > site to have more than one prefix which is accessible from the internet.
> > i.e.  the addresses are public. A site would be called "multiply
> > addressed" under this situation.  It may or may not be multiply homed.
> > 
> > If a site has only one prefix, I refer to it as being "singly addressed".
> > 
> > I think we can be agreed on those points - in this discussion anyway.
> > 
> > The way I see it, there are two ways to be multihomed, singly addressed
> > and multiply addressed.  The way the multi homing operates with each model
> > is distinctly different.
> > 
> > Now take the case of a multiply addressed site.  If we consider the IPv6
> > network as a tree structure which the current 6bone routing policies
> > encourage, then a site could be connected at two points on that tree.
> > Packets would follow different paths on the tree based on which address
> > were selected in the host by the source address selection policies of the
> > hosts in that site.  I concede that router updates may be the best way of
> > finding the "best" route if only *one* default route is advertised by the
> > immediate routers in the site local network.  It does not solve the
> > problem of long running connections though.  We cannot dictate to higher
> > level protocols regarding this issue.  TCP for example is supposed to
> > allow connections to remain active for an indefinite amount of time, even
> > over network outages.  Without the ability for IPv6 to renumber active
> > connections, then this will be a problem for multiply addressed sites,
> > even if a defined way of obtaining the best source address can be found.
> > 
> > Now take the case of a singly addressed site.  While we have solved the
> > long running TCP connection problem, I see there are other difficulties.
> > 
> > Can I explain by way of an example.
> > 
> > Say I have I am a site connected to two NLA's, each in themselves
> > connected to two independent TLA's respectively.  I hope this diagram can
> > do it justice.
> > 
> >       /--A----NLA1-----C----TLA1---E----\
> > Site /                                   \The 6bone.
> >      \                                   /
> >       \--B----NLA2-----D----TLA2---F----/
> > 
> > The links are named "A" through "F".
> > 
> > I will use my own addresses for the example..
> > 
> > NLA1 is connected to VBNS  prefix 3FFE:2800::/24,
> > NLA1 address is 3FFE:2804::/32
> > 
> > NLA2 is connected to Sprint prefix 3FFE:2900::/24
> > NLA2 address is 3FFE:2901::/32
> > 
> > Now my site address from the VBNS side  3FFE:2804:1::/48
> > and from the Sprint side                3FFE:2901:1::/48
> > 
> > If I only select only one address say 3FFE:2901:1::/48, then as long as I
> > have a route both ways through the Sprint network (TLA2) then I'll have
> > connectivity.  if link B, D or F goes down, I have a problem.  My
> > understanding of the 6bone routing policy is that no addresses with
> > prefixes longer than /24 are allowed to be advertised in the default free
> > zone.  This means that even if I could get to the internet via VBNS
> > (TLA1), routing policies preclude it.  If there was a peering arrangement
> > between TLA1 & TLA2 or between NLA1 & NLA2 , then if either E or F went
> > down I might still have connectivity as the two sites may exchange BGP
> > information.  If however link A, B, C or D went down (which is more likely
> > anyway), I have a problem unless NLA1 and NLA2 have a peering arrangement.
> > Considering a worst case scenario where there are no peering arrangements
> > whatsoever, a site multiply homed in this way would not work, mainly
> > because of the default free zone rules that are currently in place.
> > 
> > In my understanding this differs significantly from current practice in
> > the IPv4 world as a multiply homed site would have to have a routing entry
> > in the default free zone to work.
> > 
> > I stress that this is not an IPv6 problem per se, but rather our
> > application of current routing policy to IPv6.
> > 
> > My suggestion for this problem is to relax the default free zone rules in
> > a controlled manner.  Under the quiescent state (all links up), the normal
> > rules apply which would leave ethe default free zone small.  If however a
> > site is down, there may be a need for a site which is inaccessible from
> > one TLA to punch through to the DFZ via another TLA.  Is this planned
> > routing practice, or is it forbidden? (or does BGP just work that way)
> > 
> > So in summary, both methods of multihoming have their problems.  For a
> > multiply addressed site, there is the issue of selecting the best source
> > address, and also the issue of preserving long running connections.  For a
> > singly addressed site, there may be problems getting connectivity if
> > default free zone rules are adhered to.
> > 
> > There is a side issue about source addressing which seems to have been a
> > source of contention which I don't think has been particularly well
> > defined at this point in time.  For it to work properly, all hosts in the
> > site must participate in a controlled manner.  My opinion is that this is
> > not something we can fix later, as it is a fundamental IPv6 stack issue.
> > If we start deploying IPv6 stacks soon, we will have a problem as there
> > will need to be a whole heap of upgrades when we've figured out how best
> > it is to be done.  It's not an issue that can be sidelined by letting the
> > router working groups solve it later - it affects everybody.
> > 
> > [ For me personally, multi homing is bad enough under current Ipv4
> > practices.  We're a small ISP and we don't do it fully.  We have multiple
> > connections, but traffic flows out via static routes and quite
> > arbitrarily. We certainly don't use multi addressing because communicating
> > that to the hosts would be a nightmare.  I am told internal BGP could
> > solve our problem, but the routing table sizes make it prohibitive with
> > the limited sized routers which we run. ]
> > 
> > With larger ISP's I believe multi homing is essential to the quality of
> > their service so if they were to switch to IPv6, they would have a need to
> > do it and do it soon.
> > 
> > Once we've worked all this out, perhaps we need to put together a multi
> > homing how-to fact sheet so that this issue doesn't have to get thrashed
> > out yet again.
> > 
> > Does this explain things better?
> > 
> > --
> > Peter R. Tattam                            peter@trumpet.com
> > Managing Director,    Trumpet Software International Pty Ltd
> > Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210
> > 
> > ---------------------------------------------------------------------
> > The IPv6 Deployment Mailing List
> > Unsubscribe by sending "unsubscribe deployment" to majordomo@ipv6.org
> 
> 

--
Peter R. Tattam                            peter@trumpet.com
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210