Tony Finch - le (m/j/a) 1/1/09 10:01 PM:
But what we need is an addressing architecture that allows us to tell the
difference between a hostname that has multiple addresses because they are
required for application addressing, or because the destination has
multiple points of connection. (I think IPv4 vs IPv6 is a special case of
the latter.) This is another way of looking at the id/loc split.
In my understanding, SCTP has a promising approach for this:
- The DNS provides as usual a set of locators that may be tried
successively to start an SCTP association, until one succeeds. They may
be those of different hosts (e.g. for load sharing on a per connection
basis).
- Once an SCTP association is established with an SCTP endpoint, both
ends may exchange their lists of alternative locators. These locators
being exclusive of endpoint physical hosts, this is adequate for
multihoming support.
Given multiple addresses for the same hostname, a client has no way
to make an informed decision about which is the best to connect to.
This is why hosts that support IPv6 do not work as well as IPv4-only
hosts.
I guess I don't follow. Indeed, IPv6 hosts that follow RFC [3484]
will defeat some attempts at load-balancing,
This isn't about load balancing. One example is that RFC 3484 prefers IPv6
to IPv4 even when IPv6 connectivity relies on sub-optimal tunnels. Another
is section 6 rule 1 says a client should "avoid unusable destinations"
without specifying any way for a client to find out which destinations are
usable.
SRV resource records do provide indications for weighted load
balancing, nicely distinct from normal vs backup.
IMO, their use could be extended for multihoming.
For this, alternative locators of a multihomed endpoint would be
compared to those obtained in SRV RRs that , in the DNS, are given
for the name of this endpoint.
For each address that matches an SRV RR, the weight it indicates can be
used for intelligent load balancing.
There is no support for multiple instances of the same application
per host (i.e. virtual hosting) unless the application has its own
addressing.
I'm not clear what Tony might see as such "support".
Ned's message had some examples. I suppose that SRV records go some way to
fixing the problems with well-known port numbers, so "no support" is an
exaggeration - but we've failed to back-port this fix to older protocols.
Same view.
In addition, if applications use Connect By Name, and resolvers make
SRV queries when names have the service-name format, then:
- applications need not to be concerned
- transport modules can get the right remote application ports.
RD
|
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf