> At 10:09 AM 12/2/99 -0800, Charles E. Perkins wrote:
> >
> >> With this in mind I hope that the same folks who complained about
> >> increased dependencies on DNS by NATs, would be equally vocal in
> >> complaining about increased reliance on the DNS by IPv6 (which claimed
> >> to be an improvement over NATs).
> >
> >DNS is supposed to be a way to resolve domain names into IP addresses.
> >How else would one get an IP(v6) address from a domain name other
> >than by using DNS? Am I missing something here?
>
> The IPv6 A6 record, which I helped design, map a host name to a tuple of
> (prefix length, prefix name, binary suffix). The prefix name is a DNS name.
> In order to actually get the address, one should go read the A6 record(s)
> of the prefix, then combine prefix(es) and suffix to obtain address(es).
> The idea is to facilitate renumbering by storing the prefix(es) in exactly
> one place.
>
> One could say that this structure implies an "increased reliance on the
> DNS", in the sense that one will need to access two records instead of one
> in order to obtain the address. In fact, we may need more than two
> transactions, if the prefix itself is built from another prefix. On the
> other hand, there are at least three ways to diminish this reliance:
>
> 1) DNS server can provide a copy of the prefix-name's A6 record in the
> "additional information" field of responses, so that the second transaction
> can be served from the cache,
>
> 2) In "Intranet" environments, a working set of prefixes will be present in
> the cache anyhow,
>
> 3) In really constrained environment, network managers may choose to
> arbitrage between ease of renumbering and reliance on the DNS, and set the
> prefix length to zero, thus falling back to IPv4 like operation.
>
> In short, this issue was discussed at length in the IPv6 working group, and
> the benefits of easy renumbering/reconfiguration were deemed to exceed the
> "extra reliance."
> -- Christian Huitema
I'm glad this idea of decoupling site prefix and internal site
address is finally getting some serious attention. I've always
felt this was critical to the success of being able to actually
renumber a site fairly painlessly. I'll have to check out the
details of the A6 DNS draft. I proposed something very similar
way back in March of 1995, but it wasn't given much attention
then. Now if we could only have an alternate stateful address
configuration method than the backwards one of DHCPv6, one that
generated an IPv6 address directly from the host's domain name
rather than from a layer 2 MAC address, we'd really be in business.
Maybe that too will come eventually. I've included my earlier
message to the ipng e-mail list as historical perspective (my
original original message is at the very end).
-Bill
>From bill Tue Dec 31 02:10:24 1996
Subject: Re: (IPng 2593) Re: 8+8 (further discussion)
To: [EMAIL PROTECTED] (Rob Pickering)
Date: Tue, 31 Dec 1996 02:10:24 -0500 (EST)
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
In-Reply-To: <[EMAIL PROTECTED]> from "Rob Pickering" at Dec 12,
96 09:41:58 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 9852
Status: OR
> > Mike's current draft is no good for protection against the piracy,
> > because it can't lookup DNS with ID part only.
>
> Mike's draft doesn't talk at all about reverse lookup (PTR) records
> which would in any case be necessary. If you
> arrange to provide PTR records for all RG:ESD pairs that a host has
> e.g.
>
> host.dom.ain AAAA <rg1>:<esd>
> host.dom.ain AAAA <rg2>:<esd>
This is similar to something I proposed to the IPng list in March of 1995.
I've included my original message at the bottom of this message, but I'll
adapt it here for the 8+8 discussion (and variants).
A multi-homed site might have something like the following DNS setup:
My_Site IN RG xxx-LSID-Provider1_ID-Site_ID_for_Provider1
My_Site IN RG xxx-LSID-Provider2_ID-Site_ID_for_Provider2
which would represent two different providers for My_Site (this particular
example assumes that both providers are in the same LSID).
Non-Internet-connected routing domains could use the Site Local Use
prefix.
Then a host at My_Site might have the following AAAA records:
host IN AAAA My_Site PTP1_ID-EID
host IN AAAA My_Site PTP2_ID-EID
host IN AAAA My_Site PTP3_ID-EID
which assumes that the host has 3 interfaces and one IPv6 address per
interface for this particular example. Each address would be 64 bits
long (128 - length of My_Site prefix which is 64 bits). These
site-specific addresses would be invariant with a change of provider.
Then, when someone queried the DNS for the host's AAAA entries, instead
of simply returning a set of 128-bit AAAA entries for the host, it would
return the set of 3 64-bit site-specific addresses for the host, i.e. the
PTP_ID + EID.
In an additional section, it would return the list of RG entries for
My_Site, in this case the 2 64-bit Site RG prefixes representing Provider1
and Provider2.
Upon receiving the DNS reply, the requesting host would simply combine
the AAAA and RG parts to form the various full 128-bit IPv6 addresses
for the host (which would have 6 possible addresses in this example), or
use the information in other meaningful ways, such as provider selection.
It also might be desirable to have a preference value on the RG record
to order the preference of Site Providers, similar to the preference
value on MX records.
This would not only significantly reduce the possible size of a DNS
reply (3*8 + 2*8 = 40 octets versus 2*3*16 = 96 octets for this simple
case), but should also be a great help in facilitating change of provider
or exchange, and in supporting multi-homed routing domains.
I didn't initially push that hard for inclusion of such an idea in the
IPv6 DNS spec, but the more I think about it, the more I believe such a
facility is really needed even in the early deployment stages of IPv6,
to decouple the site portion of an IPv6 address from the routing goop
portion of an IPv6 address.
> and
>
> <esd>.<rg1>.IP6.INT. PTR host.dom.ain.
> <esd>.<rg2>.IP6.INT. PTR host.dom.ain.
I didn't originally consider PTR records, but my inclination is that
it's probably not a good idea to include the RG (or PTP info) in the
inverse mapping, so this should probably be:
Reversed_EID.IP6.INT. PTR host.My.Domain.
If we really want to include the RG, then it should at least be via
indirection using some new syntax, perhaps something like:
[EMAIL PROTECTED] PTR host.My.Domain.
[EMAIL PROTECTED] PTR host.My.Domain.
[EMAIL PROTECTED] PTR host.My.Domain.
Since My_Site has 2 Providers and thus 2 RG entries, the above would
actually generate the equivalent of 6 PTR records, one for each of the
6 possible IPv6 addresses for host.My.Domain.
> and a packet exchange is going on with <rg1>:<host> as the remote address. The
> route via <rg1> dies and a host unreachable is received. The stack
> then does a DNS query for <esd>.<rg1>.IP6.INT and gets host.dom.ain,
> which then forward resolves to the two AAAA records. <rg1>:<esd> is
> ruled out because we know it is dead, so we substitute <rg2>:<esd>
> and continue the conversation.
I assume you meant the new RG unreachable ICMPv6 error rather than
just a host unreachable. It would also be nice to be able to revert
back to the "preferred" RG when it came back up, but I'm not sure
how you would implement this. Perhaps you could do like Path MTU
Discovery and periodically send out some type of ICMPv6 probe message
to see if the "preferred" RG had come back up.
> This has some security as it will only use full addresses which are
> in the list of AAAA records for the host.
>
> --
> Rob Pickering
Finally, I'm still weighing in my own mind the pros and cons of the
Mike O'Dell 8+8 proposal, which I think of as 8+2+6 (Public_RG+Private_RG+EID),
versus the Masataka Ohta 8+8 proposal, which I think of as 6+2+8
(Public_RG+Private_RG+EID). I do like the ability with Masataka's
proposal to do PTR lookups based solely on the EID. It seems intuitive
to me that such PTR lookups shouldn't have anything to do with any of
the routing goop (either public or private). Since Mike didn't address
PTR lookups in his 8+8 proposal, I can't really fairly assess what he
might have in mind for performing PTR lookups. However, the concepts
and ideas in his overall proposal I generally found favorable (including
the idea of dynamically inserting the source routing goop at the Site
Boundary Router), although the details still need to be hashed out
further. I can make the same general statement about Masataka's
8+8 proposal, noting that the two proposals have much in common.
In Mike's proposal, I'm not sure I like the idea of any hard boundaries
in the Public RG part, and don't see the necessity for it, although it
could be used initially as guidance for the initial allocation of LSIDs,
to initially limit the number of routes in the global Default Free Zone
to at most 2^13 (or 2^14), plus the intra-LSID routes of course. As
routers become more capable over time, I suspect that there may be
advantages to having finer routing granularity at the top level.
One of the disadvantages Masataka listed with Mike's 8+8 proposal had
to do with mobility. One possible simple kludge to deal with this would
be to reserve either PTP (subnet) 0 or PTP 0x7FFF for mobile hosts.
This would make all mobile hosts have a constant ESD regardless of
where they happened to roam. This would limit the number of mobile
host to 2^48 or over 281 trillion hosts, but I think it will be quite
a while before we bump into that limit. Having said that, as indicated
earlier, my current leaning is toward an 8 byte EID as espoused by
Masataka, although perhaps not the exact breakdown as in Masataka's
proposal (once again I don't like the idea of completely hard boundaries
plus 3 bytes for country NICs seems excessive).
As others have noted, there are a number of similarities between Mike's
and Masataka's proposals, and I feel it should be possible to synthesize
a merged proposal from the two. As the tradeoffs are discussed further,
hopefully consensus can be reached. I think one of the determining
factors is whether or not the EID is all that is needed to do a PTR
lookup. I'm currently leaning that way personally, but am still open
to other alternatives, depending on the costs involved.
-Bill
Original message to IPng list regarding IPv6 DNS issue:
--------------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Bill Fink)
Subject: Re: (IPng) New IPv6 DNS Draft
To: [EMAIL PROTECTED]
Date: Tue, 28 Mar 1995 00:00:59 -0500 (EST)
Was any thought given to decoupling the site portion of an IPv6 address
from the exchange or provider portion of an IPv6 address?
I am envisioning something like the following DNS setup:
My_Site IN PREFIX 010-Registry_ID-Provider1_ID-Site_ID_for_Provider1 64
My_Site IN PREFIX 010-Registry_ID-Provider2_ID-Site_ID_for_Provider2 64
which would represent two different providers for My_Site, where the length
of the Site Prefix for My_Site is 64 bits. Non-Internet-connected routing
domains could use the Site Local Use prefix.
Then a host foo at My_Site might have the following AAAA records:
foo IN AAAA My_Site:Subnet1_ID-Interface1_ID
foo IN AAAA My_Site:Subnet2_ID-Interface2_ID
foo IN AAAA My_Site:Subnet3_ID-Interface3_ID
which assumes that foo has 3 interfaces and one IPv6 address per interface
for this example. Each address would be 64 bits long (128 - length of
My_Site prefix which is 64 bits). These site-specific addresses would
be invariant with a change of provider.
Then, when someone queried the DNS for host foo's AAAA entries, instead
of simply returning a set of 128-bit AAAA entries for host foo, it would
return the set of 3 64-bit site-specific addresses for host foo, i.e. the
Subnet_ID + Interface_ID (right justified in the smallest number of octets
that will hold the address, in this case 8 octets).
In an additional section, it would return the list of Site Prefixes for
My_Site, in this case the 2 64-bit Site Prefixes representing Provider1
and Provider2 (left justified in the smallest number of octets that will
hold the address, in this case 8 octets).
Upon receiving the DNS reply, the requesting host would simply combine
the AAAA and PREFIX parts to form the various full 128-bit IPv6 addresses
for host foo (which would have 6 possible addresses in this example), or
use the information in other meaningful ways, such as provider selection.
This would not only significantly reduce the possible size of a DNS
reply (3*8 + 2*8 = 40 octets versus 2*3*16 = 96 octets for this simple
case), but should also be a great help in facilitating change of provider
or exchange, and in supporting multi-homed routing domains.
-Bill
