Subject: RE: Multihoming Issues

From: "Michel Py" <[email-masked]>
Date: Tue, 3 Sep 2002 14:33:18 -0700

Caitlin,

> Caitlin Bestler wrote:
> The relationship is that DNS is acting as an
> index service for IPv6 addresses. In doing so
> it treats them as simple hierarchical  addresses,
> i.e. like fat IPv4 addresses.
> The question as to whether that is the correct
> handling of IPv6 addresses is a valid one.

We have drafts dating six years back explaining how parts of the IID
could be used for multihoming purposes. Their shortcomings have been
extensively documented. It appears to me that you are trying to invent a
wheel that lots of people here have been unsuccessful in making it turn.

> This thread started with exactly such a question
> being raised, but the rationale on how DNS *could*
> be optimized for IPV6 was not spelled out.

If you can't relate to a specific protocol, there is little point
spelling out how DNS could be optimized in the abstract.

And, if think you have a multihoming protocol that uses DNS, it might be
a good idea to look at the temporary Requirements for IPv6
Site-Multihoming Architectures: (does not apply to host-based
multihoming, though).

Is there a link you can refer us to?

> [draft-ietf-multi6-multihoming-requirements-03]
> 3.1.7 Impact on DNS
> Multi-homing solutions either MUST be compatible with
> the observed dynamics of the current DNS system, or the
> solutions MUST have demonstrate that the modified name
> resolution system required to support them are readily
> deployable.

> Caitlin Bestler wrote:
> If, at some future date, we discover that name
> servers are cluttered with redundant information
> about multi-homed IPv6 hosts we could consider
> optimizing based upon the structure of the IPv6
> address.

If, at some future date, a multihoming protocol that uses DNS makes it
to a permanent blip on the radar screen, we will then discuss the way
that hypothetical protocol addresses 3.1.7.

Michel.

---

From: "Jim Fleming" <[email-masked]>
Date: Tue, 3 Sep 2002 18:37:29 -0500

----- Original Message ----- 
From: "Michel Py" <[email-masked]>
> spelling out how DNS could be optimized in the abstract.

It might be easier if you start with an Architecture.
128-bit DNS is useful in extending the ability to set more
bits in the 160-bit IPv4 header (plus the UDP or TCP headers).
The current 2002 "version" of 128-bit DNS is rather simple.
People start on the left with 2002:[IPv4]:* where IPv4 is one of
their site-ids. That allows an IPv4 header to be constructed with
that as the Destination Site-ID. For multi-homing, a node has to
be able to determine a Source Site-ID so that packets can find
their way back. Historically, the trivial 32-bit DNS has simply
been a name to A record mapping service, with only the destination
address in the 32-bits of the A record. The source knows its
address, or is supposed to.

One could imagine designing next year's version (2003) to be
2003:[IPv4src]:[IPv4dst]:*. That would allow the DNS to store binary
information on site-to-site prefixes as a name. It is not clear people
would want to have a lot of names to describe the *relationships* between
nodes, as opposed to just the location of the nodes. Also, that would take
80 bits (16+32+32) of the 128-bit DNS AAAA record, leaving 48 bits
for a persistent address. That makes it hard to also include a 16-bit Port
Number (for UDP | TCP) and have more than 32-bits left for the IPv4++
extended address bits. If one only cared about the legacy IPv4 transport
then they could use the 48-bits for one more persistent IPv4 address and
16-bits for the Port Number.

This would be....2003:[IPv4src]:[IPv4dst]:[IPv4]:[Port]...filling the 128-bits.
IPv4src of 0 in the 128-bit DNS could mean "any" or the default site-id.
This 2003 version could be designed for people who want to take an
Intranet and expose it to the global transport. Adding modules to do this with
the new stack on Linux is rather easy. Many more of the 160-bits in the classic
IPv4 header are now coming into play for routing, and the 128-bit DNS can
be used to set those bits.
http://www.netfilter.org

In 2004, someone may have a different version to suggest...

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...
http://ipv8.dyndns.tv
http://ipv8.yi.org
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.org
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt