Subject: RE: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt

From: "Richard Draves" <[email-masked]>
Date: Thu, 17 Oct 2002 11:12:09 -0700

> 	agreed.  you can't pass around scoped address across 
> nodes (in general)
> 	as the view of the scope differs between nodes.  i have 
> clearer idea
> 	on link-locals, but i have almost no solutions against 
> site-locals.
> 	there are security issues associated with it (attacking 
> other company's
> 	inside machine using routing header w/ site-local 
> address, and such...).

I've always liked draft-ietf-ipngwg-site-prefixes-05 (the basic idea is
that site-locals are put in the DNS and it specifies a way for a node to
filter out the site-locals when they shouldn't be used). It can be
extended to the situation of an application on one node sending
addresses to an application on another node. The simple idea is to just
send all your global & site-local addresses, then the receiving node
does the same filtering specified by draft-ietf-ipngwg-site-prefixes-05,
and uses draft-ietf-ipv6-default-addr-select-09 to figure out what order
to try the addresses.

Rich

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

---

From: Keith Moore <[email-masked]>
Date: Thu, 17 Oct 2002 15:19:59 -0400

> and uses draft-ietf-ipv6-default-addr-select-09 to figure out what order

I have a lot of problems with that document.

- it has a wide impact, because it potentially imposes requirements 
  on all IPv6 apps (not just hosts) and/or encourages hosts to 
  filter DNS results that might be meaningful to apps - one result of
  this is that each component in a distributed app effectively 
  has a different view of DNS. 

- like a lot of other proposals, it assumes that DNS TTL is somehow
  related to the binding between an IP address and the host, or the
  IP address and the application component.  It's not.  DNS TTL
  is related to the binding of a name to a resource record.  It says
  nothing about the lifetime of the binding between an address and
  a host or application component.

- like a lot of other proposals, it assumes that apps get their
  addresses exclusively from DNS, even if indirectly.  this is 
  not the case.

- it assumes that all AAAA records returned in an RRset refer to
  the same host.  they don't.  they're all bound to the same DNS
  name, which isn't the same thing.

- it assumes that an app should prefer site-local addresses over
  global addresses.  but this breaks for apps that (quite reasonably)
  use source addresses in referrals to other hosts.

- address selection is already broken.  by creating yet another 
  address for each host/interface that uses them, site locals make
  the problem even worse.

- it doesn't solve the problem with two-faced DNS - it just moves
  the problem and makes failures more difficult to diagnose.  in 
  both cases the party doing the filtering is not in a position 
  to know whether the addresses will be usable by the party that 
  eventually needs to use them.

- it artifically fragments the problem space for apps that use 
  long-running connections into "site-local" apps vs "non-site-local"
  apps.  we really need something that supports reasonably long-running 
  connections for both cases.  at the same time we should recognize that 
  no address has ever been permanently bound to either a host or an 
  application.  we should just establish reasonable expectations for
  the lifetime of those bindings.  apps that need to keep connections
  open for longer than that would need to define and implement mechanisms
  for recovery from address changes.  that way we could retain 
  location-independence for apps - i.e. they wouldn't need to care whether
  they were entirely site-local or not.

this is just from a brief scan.

we're trying to solve a number of problems by creating a separate 
name for each distinct situation.  I don't think it will work - it's 
just too hard to keep track of which name to use in which case.
this proposal makes a good try but actually just ends up illustrating
how difficult the problem really is.

Keith

---

From: Robert Elz <[email-masked]>
Date: Mon, 21 Oct 2002 18:02:00 +0700

Date:        Thu, 17 Oct 2002 11:12:09 -0700
    From:        "Richard Draves" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I've always liked draft-ietf-ipngwg-site-prefixes-05 (the basic idea is
  | that site-locals are put in the DNS and it specifies a way for a node to
  | filter out the site-locals when they shouldn't be used).

No, that's a hopeless idea, and I thought had already been discarded
(the draft expired almost a year ago and hasn't been replaced).

There are just too many failure modes for that one to have any chance at all.

Aside from as used in isolated sites, SL addresses have no place in the DNS
at all, ever.

There are better ways to work out when and how to use SL addresses (some of
which might even not engender Keith's wrath).

kre

---

From: Markku Savela <[email-masked]>
Date: Mon, 21 Oct 2002 14:28:26 +0300

> From: Robert Elz <[email-masked]>
> 

Unless we introduce a new model for name resolution, an extension of
the current one. I would call it "scoped name resolution". It would
have following properties

- each name service is associated with a scope level

- the service can be unicast or multilcast based

- nodes need to have policy, which tells in which order the services
  are looked (hostfile, highest scope first or some other order).

All current DNS servers are unicast based Global Scope (even if the
address were site or link local).

The proposed link local name resolution (LLNMR), is at link local
scope and uses multicast.

In such model, one can imagine setting up a name resolution at site
scope, either as unicast server or based on multicast (using almost
same logic as LLMNR). In theory, at each scope level, one could use
either unicast or multicast approach, but of course, at global level
multicast surely wont be feasible due to scaling problems...

The scope level of the unicast server must be configured somehow, as
it cannot be deduced from the address of the server (you can have
global name server on the link using link local address, or you could
have a linklocal scope unicast server -- alternative to LLMNR).

At least for IPv6, the scope of the name service for multicast based
resolutions can be deduced from the multicast address.