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

From: Erik Nordmark <[email-masked]>
Date: Mon, 28 Oct 2002 17:35:29 +0100 (CET)

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

That long expired draft explicitly stated the assumption that all IPv6
nodes had to be modified to filter out site-local addresses from
RRsets that contain both globals and site-locals.
That was not an outlandish idea when the draft was first written,
but today there is enough implementations of IPv6 with deployment starting
to happen that that assumption would be a non-starter.

One could of course suggest a mechanism where the DNS clients explicitly
need to request something different to let the server know that they are
capable of filtering site-locals that are in a different site.
But personally I feel that adding such things to the DNS (whether it be
a new address RRtype or something else) adds far to much complexity
and has performance implications, that it makes no sense given the 
relatively limited benefit of using site-local addresses when global addresses
are available. So the approach of putting site-local addresses in the global 
DNS doesn't seem worth-while.

My 2 cents,
  Erik

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