Re: The internet architecture

[Rémi Després]

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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf