Subject: DNS based Destination Selection

From: David Gethings <[email-masked]>
Date: 18 Jun 2003 17:08:20 +0100

Hi,

I understand that DNS based solutions to the IPv6 multihomed problem
have been suggested before. However I believe my suggestion is a
different variant to previous suggestions.

Below is an overview of my suggestion. I believe it has merit and would
like the groups view.

Purpose
The purpose of this idea is to use DNS as a means for a multihomed site
to influence an external source's destination decision making. In that
way the multihomed site can influence which of its ingress points
traffic for a particular host will come in on.

Summary
Import MX priority values into AAAA and A6 records

Assumptions
That a multihomed site has a prefix provided by each transit provider

Description of Operation
A source wishes to get to a multihomed destination. When performing the
DNS look up the source gets all the IP addresses that resolve to that
hostname. Each IP address has a priority value attached to it (like MX
records).

If the source is compatible then the source used the IP address of the
most preferred priority value. It then establishes a connection to that
IP address.

Where a host is not compatible then standard address selection is
performed. In this instance the multihomed site preferrence (or policy)
cannot be enforced.

Where the source is compatible and receives multiple destination
addresses with the same priority the source may determine (but some yet
to be defined means) which IP address is preferred. The source then
establishes a connection to that IP address.

Problems
Security wise this should introduce no new problems. It is no less
secure than MX records
The question is, is DNS the right place to do this? If not why not?
Load balancing maybe a problem as it depends on implementation.
Most of the expense is put on the multihomed site: it must manage
multiple prefixes; manage the priority setting for hosts.

Advantages
Ensures the hierarchical nature of IPv6 stays intact
Does not require any IP address rewriting, tunnelling or encapsulation
Multihomed sites have a method of enforcing internal policy without
using complicated routing policies
The multihomed site does not require BGP routing

Requirements
The the DNS wg accept this idea and impliment.
That hosts IPv6 stack be updated to take this into account

Cheers

Dg

---

From: Jay Ford <[email-masked]>
Date: Wed, 18 Jun 2003 11:58:01 -0500 (CDT)

> Below is an overview of my suggestion. I believe it has merit and would

My quick reactions:
   o  DNS is too high a level for (srcaddr,dstaddr) selection;
      not everything goes by name
   o  DNS changes are difficult->impossible to get deployed globally
   o  for some cases, relying on remotely-maintained DNS information is not
      sufficient or desirable
   o  you cover dstaddr selection; what about srcaddr selection?

________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: [email-masked], phone: 319-335-5555, fax: 319-335-2951

---

From: Cedric de Launois <[email-masked]>
Date: 19 Jun 2003 08:24:48 +0200

>       not everything goes by name

Indeed. We thought of this mechanism in the NAROS solution. We perfomed 
recently a quick evaluation of this solution (use of DNS to influence
an external source's destination decision making). First results
clearly show this is too high level : 70 to 90% of the traffic 
flows we analyzed were NOT preceeded by a DNS request ! (This
is only an approximation since it is hard to see which DNS request
is associated with which flow). This is due to the spread of p2p
applications : lots of flows without any DNS lookup.

---

From: David Gethings <[email-masked]>
Date: 19 Jun 2003 09:50:06 +0100

> applications : lots of flows without any DNS lookup.

I must admit I was initially surprised by this statement. I have no
reason to believe that this is untrue. However having given it a little
thought this result does not really surprise me. When downloading a
webpage there will only be a few DNS lookups required (usually only one
or two), however there will be a number of flows as the web browser
requests all the images and frames (if there are any) associated with
that page.

I do concede that there will be a number of applications that will never
do a DNS lookup. So this obviously puts a question on whether DNS is the
right place to do destination selection.

The point of my suggestion is that it is a simple method of influencing
which ingress path traffic could take for a multihomed site. It is
simple enough for most SOHO and SME's to use and does not require much
networking expertise - much less than using BGP.

Will it work in every situation: no. Does it offer enough functionality
that a reasonalbe proportion of multihomed sites will wish to use it: I
believe so. Is the cost of changing DNS and host stacks worth it: I
honestly do not know.

I honestly don't believe we will find just one multihoming solution that
will suit every multihomed site. I believe this method to a be good
starting point for people new to multihoming in IPv6.

Cheers

Dg

---

From: David Gethings <[email-masked]>
Date: 19 Jun 2003 10:01:29 +0100

>       not everything goes by name
See my response to Cedric

>    o  for some cases, relying on remotely-maintained DNS information is not
I agree that they are not easy, but this method is used for MX records.
I agree that by adding the priority value to the AAAA & A6 records
alters the purpose. But I do not see this as being a major sticking
point.

>    o  you cover dstaddr selection; what about srcaddr selection?
One thought I have just had (so I have no idea how good or bad this idea
is) is if a source is also multihomed it can perform PMTU discovery for
each of the IPv6 addresses it has in that scope. The source address to
use is determined by which ever returns the best PMTU and RTT.

This is a slight waste of bandwidth. But if the "best" possible path is
your ultimate goal there have to be trade offs.

Cheers

Dg

---

From: Cedric de Launois <[email-masked]>
Date: 19 Jun 2003 11:31:51 +0200

> starting point for people new to multihoming in IPv6.

My question is : what is the goal pursued with this mechanism ?
- If the goal is to perform inbound traffic engineering, then I'd say
  this mechanism is not sufficient. Not enough traffic is controlled via
  this way to get good load-balancing.
- If the goal is just to somewhat improve an external source's
  destination decision making, then what is the advantage of your
  suggestion compared to just carefully ordering the list of addresses
  returned in the DNS reply (solution which doesn't imply any change in
  the hosts) ?

---

From: Jay Ford <[email-masked]>
Date: Thu, 19 Jun 2003 08:45:16 -0500 (CDT)

> applications : lots of flows without any DNS lookup.

Wow.  I wouldn't have expected the no-preceding-DNS percentage to be that
high.  I guess I was more right than I knew.  ;^)

---

From: Jay Ford <[email-masked]>
Date: Thu, 19 Jun 2003 09:00:19 -0500 (CDT)

> right place to do destination selection.

Right.  I think it has to be lower down than the DNS.

> networking expertise - much less than using BGP.

Is it likely that small (home...) sites will be multihomed?  I'd pretty much
written them off as not pertinent.

> starting point for people new to multihoming in IPv6.

We probably will end up with multiple multihome options for IPv6, just like
we have with IPv4.  I just don't see that a DNS-based solution puts the
control at the right end or catches enough flows.

---

From: Jay Ford <[email-masked]>
Date: Thu, 19 Jun 2003 09:07:51 -0500 (CDT)

> alters the purpose. But I do not see this as being a major sticking

I think changing AAAA and/or A6 RRs at this point would be tough, but it
might be possible.

The second of my two above points was that the remote end (which owns the
DNS) would be specifying the preferences of the sender of a packet.  I'd
rather decide the preferences at my end for traffic I send.  Most net
interactions are bidirectional, so this is admittedly not a single-ended
problem, & the issue of who (sender or receiver) gets to decide path
selection for a packet borders on religious, so getting consensus on this
won't be easy.  (By the way, we have the same issues with IPv4, but based on
AS-path info... instead of addresses.)

> your ultimate goal there have to be trade offs.

The definition of "best" is tricky.  It isn't always just bandwidth & RTT.

---

From: Jay Ford <[email-masked]>
Date: Thu, 19 Jun 2003 09:12:13 -0500 (CDT)

>   this way to get good load-balancing.

Agreed.  Further, if the choice of source address preempts the path
selection, then the TE intended by the DNS preferences don't work.

>   returned in the DNS reply (solution which doesn't imply any change in

DNS replies often don't go directly from DNS server to DNS client when they
are in different administrative domains.  Recursive queries, caching,
secondary service... all introduce places where the RRs can get reordered.

---

From: Cedric de Launois <[email-masked]>
Date: 19 Jun 2003 16:20:11 +0200

> high.  I guess I was more right than I knew.  ;^)

I was also surprised. However, these values are rough approximations.
Factors that can explain these high percentages are :
- the trace contains lots of p2p traffic, that generates lots
  of flows without using DNS.
- attacks from the Internet : port scans etc. The trace should be
  cleaned up...
- caching on host applications
- associating a DNS request to a flow is a non-trivial task. The
  evaluation method used is far from perfect.

However, the values show that we can't rely on DNS to perform 
(srcaddr,dstaddr) selection.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Jun 2003 17:59:52 +0200

A couple of comments

1. Forget A6 records. They are deprecated and pretty much dead and buried.

2. I agree with the comments suggesting that DNS cannot be the primary
mechanism for address selection. However, that doesn't exclude a DNS
based solution for address mapping. Applications that don't use DNS
to initiate a transaction might just have to use DNS if they want to
benefit from a mapping style of multihoming.

  Brian

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 19 Jun 2003 15:41:03 +0200

On torsdag, jun 19, 2003, at 10:50 Europe/Stockholm, David Gethings 

> believe so. Is the cost of changing DNS and host stacks worth it: I

The problem with DNS for this purpose is as Brian pointed out some 
weeks (months?) ago - you create circular dependencies.

Best regards,

- - kurtis -

---

From: Joe Abley <[email-masked]>
Date: Thu, 19 Jun 2003 13:34:49 -0400

On Thursday, Jun 19, 2003, at 09:41 Canada/Eastern, Kurt Erik Lindqvist 

> weeks (months?) ago - you create circular dependencies.

But as we discussed in the thread which followed that observation, 
circular dependencies can be managed (e.g. by way of a bootstrap 
procedure). So the fact that a circular dependency might exist does not 
necessarily indicate a dead end.

Joe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 20 Jun 2003 00:21:21 +0200

On donderdag, jun 19, 2003, at 16:07 Europe/Amsterdam, Jay Ford wrote:

> won't be easy.

This assumes that given the choice between two addresses for the other 
end, choosing address #1 will make the packet flow over ISP A and 
choosing address #2 will make the packet flow over ISP B. I see no 
reason why this assumption would hold true in the majority of cases 
today, and it certainly doesn't _necessarily_ hold true.

>> use is determined by which ever returns the best PMTU and RTT.

With hop-by-hop routing you don't get to pick a source address: you 
must use one compatible with the ISP that is the next hop for the 
destination address in the packet.

You get to do this with source address dependent routing, though. (This 
will fix the above problem as well.)

> The definition of "best" is tricky.  It isn't always just bandwidth & 

Either the preference can be expressed in a policy so ask a policy 
server, or it can be expressed as "optimize this set of variables" in 
which case you try the permutations, perform measurements and 
ultimately decide.

Or make TCP multipath-aware with window and RTT processing per path. 
Then you get the performance of the combined paths regardless of the 
features of any particular path.

---

From: marcelo bagnulo <[email-masked]>
Date: 20 Jun 2003 10:11:14 +0200

Hi Iljitsch,

> today, and it certainly doesn't _necessarily_ hold true.

If PA addressing is used, the selection of the dest address implies the
selection of the provider used to reach that destination address (at
least in steady state i.e. no failures). right?
If this is so, what case are you considering where the selection of the
dest addr does not implies the selection of the isp used to reach the
multi-homed site?

Regards, marcelo