Subject: naming and LL in ad hoc networks, The Poll, draft-ietf-ipv6-deprecate-site-local-00 (digest)

From: Keith Moore <[email-masked]>
Date: Thu, 28 Aug 2003 21:26:52 -0400

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-masked]
--------------------------------------------------------------------