in this issue:
On naming in non-routed ad-hoc networks
On use of LL in non-routed ad-hoc networks
On the Poll
On the text in draft-ietf-ipv6-deprecate-site-local-00.txt
----------------------------------------------------------------------
On naming in non-routed ad-hoc networks:
Erik is correct to point out the issues associated with naming in
non-routed ad-hoc networks if any of the hosts have multiple interfaces.
This is similar to a problem that exists in v4LL if any of the hosts
have multiple interfaces - multiple hosts can choose the same v4LL
address and be reachable by the same host, and a host with multiple
interfaces can be forced to choose a new address (thus breaking open
connections) if there is a conflict on any of those interfaces. Unlike
v4LL, in v6 we generally expect most LL addresses to be globally
unique (modulo bugs in the hardware) so address collisions "shouldn't
happen".
What this probably means is that it's a bad idea to try to make lookup
of local names in an ad hoc network look too much like DNS - the ad hoc
network has additional failure modes (e.g. name collisions) that the DNS
design (and the design of apps using DNS) never anticipated. What you
really need is a way to do searches where the client's actual location
in the net can be an implicit part of the query. For instance, find
the nearby printers, projectors, etc. Of course, you need a separate
API for this, and you can't expect apps that are only aware of DNS to
make good use of this facility.
However that doesn't mean you can't implement lookup of DNS names on
an ad hoc network. But the names have to be (a) globally unique and
(b) assigned to the host, meaning the host has to be _authoritative_ for
its DNS records - i.e. the owner of the parent zone has delegated
authority to that host to maintain records for its name. (this isn't a
matter of network protocol, it's a matter of deciding who is going to
maintain what part of the DNS name tree).
If the host is sometimes attached to a "managed" network with real
DNS, and its name is advertised via DNS, it's also necessary that
the host update the network-accessible servers for its domain (if there
are any), whenever it has the chance, to keep them consistent with the
RRs it is providing via local lookup. This could employ dynamic update,
or zone transfer, whatever.
This is mostly useful for supporting name lookup for local hosts when
the local net is partitioned from the DNS, and for hosts that migrate
(e.g. laptops) to be able to keep their DNS names as they move from one
location to another. I don't offhand see how it's useful to appliances.
So you need two distinct lookup services on ad hoc networks:
- lookup/search of "local" devices
- lookup of DNS names on disconnected networks or networks with
local scope
and offhand I don't think you can reasonably implement either service
in terms of the other one.
----------------------------------------------------------------------
On use of LL in non-routed ad-hoc networks:
(continuing from the last topic...)
However I still take issue with this statement by Erik:
> For a single ad-hoc link I can see LLMNR work as a naming protocol
> (and link-locals or any other IP address can be used - doesn't matter
> since all IP addresses must either be local to the link or be
> unreachable).
That's not a valid assumption for several reasons:
One is that some apps will need to filter link locals in order to
operate correctly under normal conditions, but this behavior won't work
for the single ad-hoc link Erik describes - so the app is required
to have an option that says "use link locals", which is a pain.
Another is that a single-link network might suddenly change to
a routed network - these things *are* ad hoc, after all - in which
cases the LL address suddenly become very dysfunctional and the
link needs to renumber. It is better to avoid that case entirely.
Finally, any apps that involve a host with multiple interfaces and
attached to multiple networks may be exposed to addresses without
being able to know which network the address belongs on. Yes, if
the app gets the address via doing LLMNR queries on each link then it
can determine which interface to use based on which link the answer
came from. But this doesn't help if the app does address referrals,
and because scopes don't have names, the app can't include the name
of the scope in the referral.
It makes far more sense for each link in an ad hoc network to elect
its own randomly-generated, probably-unique, prefix. That solves
the whole problem of needing to keep up with scope ids in a much
more general fashion.
----------------------------------------------------------------------
On the Poll:
Have you ever taken one of those multiple choice tests where a
lot of the questions have no correct answers (and there is no
"none of the above" choice)? A lot of the questions put to
this group feel like that, including this one.
I don't think the results of the poll can be meaningful because
questions B and C are meaningless. If Site-Local doesn't solve
"a" problem, and if the problems that Site-Local is supposed
to address aren't either well-defined or agreed to, how can there
be "an" alternative solution? How will we ever know if these
criteria are met and it's okay to deprecate site-locals?
I don't see consensus that site-locals solve any real problems.
This is a recipe for stalling indefinitely when we need to be
making forward progress.
It would make far more sense to ask "what things do we need to
agree on before we can announce that we're deprecating site-locals?"
(IMHO: we need to agree to define GUPIs and PUPIs, and that's it)
----------------------------------------------------------------------
On the text in draft-ietf-ipv6-deprecate-site-local-00.txt
here's (in essence) what I think the relevant section should say:
IETF has determined that site-locals are, overall, a highly undesirable
feature which are likely to cause harm if widely deployed. Therefore
use of IPv6 site-local addresses is formally deprecated existing and
future protocols. In particular:
- All existing IETF protocols that make special use of site-locals
(e.g. address selection) will be revised to discourage or eschew
use of site-locals.
- Future IETF protocols will not make special use of site-local
addresses; such protocols may specifically discourage or eschew
use of site-local addresses.
- No future IETF protocols will support the routing or provisioning
of site-local addresses within networks.
- All existing IETF protocols that support routing or provisioning of
site-local addresses will be revised to remove such support.
Such protocols may be revised to specifically discourage or eschew
use of site-local addresses on networks.
- Application vendors and protocol authors SHOULD NOT attempt to make
special use of site-local addresses in new products, and they SHOULD
NOT make any assumptions about the properties (security or otherwise)
of site-local addresses if they are encountered in operation. Such
applications MAY discourage or eschew use of site-locals.
- Existing applications which make special use of site-local addresses
SHOULD be modified to not do so. In order to ease transitions
for sites and applications that are already using site-local
addresses, the revised versions of such applications MAY have a
compatibility mode which causes the application to treat site-local
addresses as in earlier versions. However, it MUST be possible to
disable this mode, and the default setting SHOULD be to not treat
site-locals specially.
- Routers, firewalls, proxies, and other intermediaries SHOULD NOT
support special treatment of site-local addresses. Such devices MAY
discourage or eschew use of site-local addresses.
- Existing router, firewall, proxy and other intermediary products
which treat site-locals specially SHOULD be modified to not do so.
Such devices, after modification, MAY have a compatibility mode which
enables the deprecated behavior. It MUST be possible to disable
this compatibility mode, and the default behavior SHOULD be to disable
it.
- The addressing architecture [RFC3513] will be revised to classify the
FEC0::/10 prefix as "reserved - do not use". This prefix will be
available for reassignment by a future IETF standards action.
- The specific changes to protocols and specifications to deprecate
site-local will be worked out by the groups maintaining the relevant
documents as those documents are revised, subject to the following
criteria:
- the intent is to discontinue protocol support for site-local
- site-local use may be discouraged or prevented if operationally
necessary
- applications and networks using site-local will be
encouraged to transition away from site-local
- pre-existing use of site-local by applications and within networks
may still be permitted for a time in order to avoid imposing abrupt
transitions on those users
---
That was a lot of text, and I'm not happy with the wording yet, but
I don't have time to work it all out right now. The main ideas are:
- state broad _intent_ to deprecate site-locals and what this means in
general terms for several classes of things (how we intend to change
existing ietf protocols, intentions for future IETF protocols, what
existing networks and existing apps should do)
- don't try to write blanket text that covers exactly what this
means in every case - leave the specifics for when the relevant
documents are revised
- upper-case keywords (MUST,etc) apply to implementations and
deployments, not to future IETF standards actions.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
