Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses"

From: Erik Nordmark <[email-masked]>
Date: Wed, 22 Oct 2003 22:08:35 +0200 (CEST)

> A simple method would be to check the first 48 bits of the IP addresses 
> that are suspected of having "local" reachability. But this doesn't 
> allow for the merging of two sites, which was presented as a rather 
> prominent requirement during the site local wars (or at least the part 
> I got to witness).

Good point.

> I don't believe two-faced DNS is a solution, because then the DNS 
> server must know all the information the hosts are apparently unaware 
> of, and know the exact reachability details of each possible pair of 
> hosts to boot. I expect both internal information to leak out and 
> internal hosts to be presented with external information only in many 
> situations.
> 
> A solution could be giving hosts access to local routing information. 
> Is this something we want? Or do we drop the site merger without 
> renumbering thing and work on renumbering instead?

At least having a mechanism to provide hosts with a list of which local
prefixes are likely to be routable wouldn't be hard.
But how many such prefixes is it reasonable to assume that
the most basic nodes will support? (If I read between the lines
about the claimed security befits of local addresses in the hain/templin
draft it seems like it is the simple small devices that supposedly
benefit most from unique local addresses, but those might also not want
to store a hundered such prefixes.)
Things brings us to the semantics of the "local only" communication when
there are both site mergers (with two or more local prefixes denoting the same
site) as well as having private interconnection of sites; which prefixes
should be included in the "local only" type of filter in each host?

> Note that these problems don't disappear once we sprinkle them with 
> magic loc/id separation powder: it's still entirely possible for the 
> system to choose a locator that doesn't work. But at least this is a 
> problem that can be corrected somewhere lower (below the application) 
> in the stack and optimized there, rather than dump the problem on 
> applications and hope those will do the right thing after TCP times 
> out.

Agreed.
I haven't yet thought about the utility of locator locators with 
locatior/identifier separation. Perhaps they would be useful since
they can survive flash cutover renumbering (when DNS can't be updated in time)
but they might not provide benefits for controlled renumbering.

> So my question is: are unique local IPv6 unicast addresses unroutable 
> by design yes or no?

I'll let others answer that question.

What I see in the draft is language like:
      - Not possible to route Local IPv6 prefixes on the global Internet
        with current routing technology.  Consequentially, it is
        necessary to have the default behavior of site border routers to
        filter these addresses.
This sure reads like folks would like them to be globally routable
and that there are just some minor technical issues with the current
routing technology that prevents that (hah!). Sure looks like
a slippery slope to me.

   Erik

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 22 Oct 2003 22:34:15 +0200 (CEST)

Overall I support this document, but there are two things that have
me concerned.

1. The document talks about a replacement in section 2 and section 5.
While finding replacement for what folks perceived as being benefit
with site local addresses is useful (and perhaps even required),
the text in this draft seems to lock us down into replacement that
consist of defining some new address format.
I find this odd since the the WG has discussed partial replacement solutions
(for instance, draft-zill-ipv6wg-zone-prefixlen-00.txt) which do not involve
defining a new address format.

Does this document indeed intend to prevent the WG from working
on replacement solutions which do not define a new addressing format?
That would seem silly thus I suggest the text be reworked a bit to
make this more clear.

2. Section 2 talks of only two categories of issues but I
think there is a 3rd one: "moving the problem to the application space".

The text in section 2.1 talks of only one aspect of this (having to deal
with scope ids in the application).
draft-wasserman-ipv6-sl-impact-02.txt in section 3.7 has additional 
issues relating to:
         - Two-party client/server applications that exchange IP
            addresses at the application layer.
         - Multi-party applications that exchange IP addresses at the
            application layer.
Thus in particular the last two paragraphs in section 3.7 in 
draft-wasserman-ipv6-sl-impact-02.txt seems to be missing from this draft
and I think they need to be included to make sure important aspects of
the issues are not forgotten as we move forward.

   Erik