Subject: RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))

From: "Michel Py" <[email-masked]>
Date: Fri, 28 Mar 2003 18:09:13 -0800

John,

> John C Klensin wrote:
> We, or more specifically, the upstream ISP or an RIR, can
> tell the ISP that things will go badly for them if they
> permit un-routable addresses to leak into the public
> Internet. The only difference I can see between what I
> think is your SL address preference and my "unique, but
> un-routable" one is that you would bind that advice/threat
> to a particular prefix while I would bind it to other
> indicators of "un-routable address". The reserved prefix
> approach is less likely to get mucked up by a clueless
> ISP, but I am unconvinced that we should make special
> architectural provisions to make it easier to be in the
> ISP business while being clueless.

I also think that policy alone can not enforce un-routability of
addresses. The only way to make sure that addresses are not routable on
the public Internet is to suppress the demand for routing them.

Example that works: RFC1918. Although we occasionally see these on the
public Internet, it's due to misconfiguration. No customer is going to
see their upstream and offer them money to leak or route RFC1918
addresses, because it achieves nothing (because RFC1918 addresses are
ambiguous). No demand, no routing.

Example that would not work: Allocate a block of regular addresses
(let's say, 2003::/16) to the purpose of globally unique non-routable
addresses. Whether you bind the advice/threat to that prefix to other
indicators of "un-routable address" you will create the demand from
end-sites to go to their providers and indeed ask them to route them to
be used as PI, with the result of routing table bloat.

What is required in order to get globally unique non-routable are three
things:
- Policy (the advice/threat).
- Some normative language mandating implementations (vs. policy)
  to disallow the practice (default blackholing).
- Some kind of architectural limitation such as site-local.

The combination of all three is required. The policy alone is not enough
because some ISPs will take the customer's money at the risk of being
labeled as bad boys. The normative language alone is not enough as we
have no way to force implementers to code it. The architectural
limitation alone is not enough as one will likely come up with a dirty
hack to route SLs globally if need be. Any combination of two would not
be a powerful enough deterrent either.

In other words: the only way to guarantee the non-routability of
globally unique private addresses is to put so many hurdles on the way
that it won't happen. To this effect, the proposed deprecation of
site-locals is a serious blow as it suppresses the architectural
limitation and therefore creates demand for sites to pay their ISPs to
"forget" to filter their prefixes and transform a non-routable globally
unique prefix into a de-facto routable globally unique prefix also
called PI.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Mon, 31 Mar 2003 13:53:58 -0800

> Eliot Lear wrote:
> Right up till the point where two companies start communicating
> with one another directly with site-locals.

No, no, no. That's exactly what we don't want site-locals to do.
Site-locals are not to communicate outside their own site, period.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Mon, 31 Mar 2003 17:53:29 -0800

Margaret,

> Margaret Wasserman wrote:
> (2) Institutionalizing the need for split DNS. I understand
> that some network administrators choose to use split DNS
> today, but that doesn't meant that we want to build a
> requirement for split DNS it into the IPv6 architecture.

I don't think "Institutionalizing" is a good choice of words here. Split
DNS is not unique to site-local addresses, it's not even unique to
private addresses. I have seen several sites that have split DNS even
though they use public addresses only. Out of the 50 something distinct
sites that I administer, I think only one or two do not have split DNS.

> IMO, requiring the DNS infrastructure to be aware of and
> enforce topology boundaries is a poor architectural choice.

In theory, I agree but the fact of the matter is that it already is
aware of the topology and I don't see this changing any time soon. Don't
get me wrong: I do not like split DNS, but I have seen it on sites that
have a single public address per host. There also are multitudes of perl
scripts that parse custom zone files to make multiple different ones,
such as the very typical example below that will produce 2 set of zone
files:
(yes I know it does include NAT but keep in mind this is today's reality
too).

name inside_addr  outside_addr
www  192.168.1.2  209.233.126.65   # web server
ftp  192.168.1.3  209.233.126.65   # ftp server
sql  192.168.1.4  0.0.0.0
pop3 0.0.0.0      209.233.126.65

[parse with homebrew perl script]

zone file for inside DNS servers:
www  192.168.1.2  # web server
ftp  192.168.1.3  # ftp server
sql  192.168.1.4

zone file for outside DNS servers:
www  209.233.126.65   # web server
ftp  209.233.126.65   # ftp server
pop3 209.233.126.65

Again I'm not saying this is good but don't think it will be introduced
or institutionalized with site-local addresses; it's been around for a
long time.

Michel.