Summary:
- I do not think it is appropriate to publish this document as Proposed
Standard at this time.
- I believe the structure of these addresses and means of assigning
prefixes are basically sound. However, I have several problems with
sections 7 on.
- I would support publication of this document as Experimental if it
were revised to include only the sections on address structure and
assignment of prefixes, and omit the sections describing how the
authors expect these addresses to be *used* either in DNS or by
applications.
----------------------------------------------------------------------
> 7.0 DNS Issues
>
> AAAA records for Local IPv6 addresses SHOULD NOT be installed in
> the global DNS.
Trying to impose scope on DNS is not technically sound. Applications,
(including but not limited to DNS) are not aware of scope boundaries
and will leak addresses (including DNS query results) across those
scope boundaries. Applications operating across scope boundaries need a
consistent view of DNS in order to function properly.
> If Local IPv6 address are configured in the global DNS, no harm is
> done because they are unique and will not create any confusion.
> They may not be reachable, but this is a property that is common to
> all types of global IPv6 unicast addresses.
>
> For future study names with Local IPv6 addresses may be resolved
> inside of the site using dynamic naming systems such as Multicast
> DNS.
Multicast DNS is a very dubious concept which should not be endorsed
by this document. In particular, it suffers from the same severe
technical flaw (among others) that this section does - that it
is acceptable for DNS (or a combined system consisting of DNS and mDNS)
to present different views of an RRset or zone to different portions of
the network, when applications quite reasonably expect DNS to be
consistent (modulo skew between different versions of a zone at
different servers).
> 8.0 Application and Higher Level Protocol Issues
>
> Application and other higher level protocols can treat Local IPv6
> addresses in the same manner as other types of global unicast
> addresses. No special handling is required.
I do not believe this to be the case; or at the very least, this is a
gross oversimplification for the case of apps that do referrals
(for instance, any app that uses DNS). Some apps will need to choose
an address that functions across all peers; use of local addresses
would fail more often than globals. Some apps are intended for local
use only and are less tolerant of prefix changes; these apps will want
to use local addresses in preference to globals.
But even this is an oversimplification.
> This type of addresses
> may not be reachable, but that is no different from other types of
> IPv6 global unicast addresses.
Yes it is different, because the reasons for lack of reachability are
different. When an app cannot reach peer using a global address, it's
reasonable to assume that this is either due to administrative
prohibition or a temporary routing or link failure. (Administrative
prohibitions should be signalled with ICMP messages so that the app can
distinguish between these two cases; the fact that router/firewall
configurations often botch this doesn't justify propagation of that
error.)
> Applications need to be able to
> handle multiple addresses that may or may not be reachable any
> point in time.
This is also an oversimplification. It's certainly not a reasonable
statement as written, because there are too many cases where expecting
an application to cope with multiple addresses is either onerous
(as in expecting every application to implement its own route
advertisement, routing, and message forwarding) or infeasable (as in
expecting apps to route messages between pairs of hosts that
may not have any signal path between them).
A more realistic statement is that applications need to be able to
distinguish between cases where the application can reasonably do the
job (because the network provides adequate connectivity) and cases
where the application cannot reasonably do the job (because, for
whatever reason, the network fails to provide adequate connectivity).
And if the connectivity isn't adequate, this needs to be described as a
consequence of network configuration - not a failure of the application.
> In most cases this complexity should be hidden in APIs.
It is naive to assume that this complexity can be hidden in APIs, at
least given facilities currently in the network, because the decision
of which kind of address to use requires information that is not
available to the hosts. The apps can supply hints as to their
preferences, but reasonable decisions require knowledge of both
network topology (e.g. which addresses are reachable from which parts of
the network) and the topology of the application (where are the current
and future peers that are part of the application located?)
> From a host's perspective this difference shows up as different
> reachability than global unicast and could be handled by default
> that way. In some cases it is better for nodes and applications to
> treat them differently from global unicast addresses. A starting
> point might be to give them preference over global unicast, but
> fall back to global unicast if a particular destination is found to
> be unreachable.
This is not a reasonable strategy for many, perhaps most, applications.
It makes assumptions about application behavior that aren't generally
true, and may be even less valid in the future.
> Much of this behavior can be controlled by how they are
> allocated to nodes and put into the DNS.
It is not reasonable to make assumptions about applications' use of DNS;
in particular, it's not reasonable to assume that the scope in which a
DNS query was made is the same scope in which the results will be used.
> Note that the address selection mechanisms of [ADDSEL], and in
> particular the policy override mechanism replacing default address
> selection, are expected to be used on a site where Local IPv6
> addresses are configured.
Address selection by itself is woefully inadequate, and it cannot be
made adequate given either the existing APIs or the information that
is currently available to hosts about either the app or the network.
----------------------------------------------------------------------
The bottom line is this:
>>> we don't understand how to make this work yet. <<<
where "this" is having hosts advertise multiple addresses with varying
reachability. The potential for "this" has always been there in IPv4,
and it's been tried from time to time, but in general, it never has
worked well. The difference is that whereas in IPv4 we could generally
give each host a single address and make it reachable from all points
of interest (modulo administrative prohibition), in IPv6 we're trying to
insist that multiple addressing be used as a matter of course and to
solve a variety of problems. In other words, we're insisting that
something that has been tried many times and has never worked before,
be made to work (presumably by pretending that the problem doesn't
exist, or that it's somebody else's - the application writer's -
problem).
Basically this fails the "no known technical limitations" test.
A document that defines formats for GUPIs and PUPIs is a good next
step, but it is not sufficient. What we need to do is to set aside
this document (i.e. assume that it's fine as is, though it might need
tweaking later once we understand how to solve the real problems)
and start actually trying to define a model that works.
The model should consist of:
- rules for assignment of addresses to hosts (i.e. when to assign
locals, when to assign globals, or both)
- mechanisms to propagate information about which addresses are usable
that actually do follow scope (e.g. via ND/RA)
- rules for selection of addresses (not merely address selection
as it's currently thought of, but also considering things like
substituting a locally-known alternative for a global address
that is advertised in DNS or other referral mechanism)
- rules for address referrals (including but not limited to DNS)
As for what it means for the model to "work" I suggest the following:
- it should be possible to associate a token (or a short list of
tokens) with a host, so that the tokens can be used to unambiguously
identify and reach that host, reliably and efficiently, from any
location in the network, provided the host is reachable
- an application in possession of such tokens should be able to
quickly and reliably determine if failure to reach a host is due to
administrative prohibition or lack of a routing arrangement
(as opposed to a temporary condition such as a host or link failure)
- this token or list of tokens should be suitable for advertising in DNS
(probably but not necessarily AAAA records) or via other referral
mechanisms
- the binding between these tokens and their hosts should have
sufficient lifetime to allow them to be cached and to rid hosts
and most apps of the burden of dealing with changing bindings
- the efficient and reliable use of those tokens or list of tokens
to communicate with current and potential peers should rely only on
information that is easily available to hosts and apps using them.
- there should be a clear separation of function between application
responsibility, host responsibility, and network responsibility.
----------------------------------------------------------------------
> In order for hosts to autoconfigure Local IPv6 addresses, routers
> have to be configured to advertise Local IPv6 /64 prefixes in
> router advertisements. Likewise, a DHCPv6 server must have been
> configured to assign them.
since when? none of my v6 boxes require DHCPv6, and that's a Good
Thing.
> In order for a node to learn the Local IPv6 address
> of another node, the Local IPv6 address must have been installed in
> the DNS.
false. not all apps use DNS as a means of learning peers' addresses,
nor do apps that do use DNS always use it exclusively. nor would it be
desirable to impose that constraint.
> For these reasons, it is straight forward to control their
> usage in a site.
this does not follow because it's based on a false premise.
In general, I object to section 9 because it assumes (nay, imposes)
split DNS, which is highly undesirable and also nonstandard.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
