Multi homing & NLAs.

[Brian E Carpenter]

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.

    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