How is a typical v6 TCP client at a multihomed site, with address
prefixes from multiple upstream providers, supposed to choose
amongst it's local addresses when contacting a remote server?

One way might be for each host to keep a full routing table with
link-global nexthop addresses.  In which case the typical connect()
sequence would go something like this:

        Client app calls connect() on a new socket with local
        address unspecified.

        The kernel looks up the remote address in the local forwarding
        table (aka the routing table) and finds a local interface
        address.

        It set's the socket local address accordingly, and begins
        the 3 way handshake to establish the TCP session.

Unfortunately, creating a forwarding table with link-global nexthops
is a bit more problematic.  It's not practical to run an iBGP
session to every host on the network.

RIPng uses exclusively link-local nexthops (per RFC2080) which
makes it useless for conveying link-global nexthops.

I havent investigated using OSPF6 yet.

I also have some reservations about "redistributing" BGP routes
into an IGP at all.  Since many sites already redistribute IGP
routes (from ISIS, OSPF, or RIPng) into BGP, can redistributing
BGP routes back the other way cause problems?

If redistributing routes from BGP into an IGP is an unacceptable
risk then perhaps the best way to distribute the full routing table
to end systems is to use a RIPng like protocol on a different UDP
port and specify that it should use link-global addresses.

Would it be better to simply forgo the use of routing protocols
and use using Neighbor Discovery to find both the best nexthop and
link-global address prefix to use?  At least this method doesnt
require maintaining a full routing table.


brad
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------

Reply via email to