On Fri, 2003-09-12 at 12:48 +0300, Pekka Savola wrote:
> A year or two down the path, there may be another "local addressing"
> approach.. there is already a proposal:
>
> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-00.txt
>
> .. but whether thats *the* way, or a way at all, remains to be seen.
So the advocated FC00::/8 locally-assigned addresses would be a bit like
site-scope addresses, but with a higher probability of actually being
globally-unique, although that is entirely pointless, and without all
the useful semantics w.r.t. address selection. Great.
> You might also want to check out the document which is documenting the
> deprecation (note, it's still a draft version, and likely to evolve a
> lot), to learn about some of the problems of the site-locals:
>
> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-site-local-00.txt
It's interesting to see the arguments therein. I thought there might
have been some valid ones I wasn't previously aware of, since I'm fairly
new to IPv6. That doesn't really seem to be the case -- all the
arguments could apply just as well to RFC1918 too.
Â2.1 -- people might use _internal_ addresses of one site when they've
moved to another. Just like trying to talk to RFC1918 internal addresses
when you've moved. Yes it's a vague possibility -- compounded if people
are playing schizodns tricks so that internal addresses actually have
public-looking names -- but in practice it's a failure mode for RFC1918
already, and hence is known and avoided. Site addresses don't work
off-site. Film at 11.
Â2.2 -- internal addresses 'leak'. Not if you apply even a modicum of
clue. Same as RFC1918 in IPv4. You don't let packets with private source
addresses outside your borders, and you don't put them in public DNS.
Â2.3 -- routing is hard. Let's go shopping. You have a global internal
network routed over crypto tunnels between multiple sites. And you can't
handle setting up the routing? Yeah, right.
Â2.4 -- site is an illdefined concept. Yes, that's sort of the point.
Its scope is _allowed_ to vary, because it's user-defined. At long as it
doesn't leak, which it doesn't, you don't care whether I happen to use
'site' to mean a single physical location, or my global intranet.
Â3 -- development of a better alternative. That would be nice. Nothing
we've discussed so far really seems 'better' though.
</RANT>
> One possible, conceptually maybe easier way, would be to deploy a single,
> internal ISATAP domain (so you'd have only _one_ internal IPv6 subnet,
> which would really be just automatic tunnel between all v6 hosts in your
> enterprise), but that would require getting ISATAP in all the kernels and
> iputils you use first, and IMHO it wouldn't be the same as deployingi real
> IPv6... :-)
Some 6-in-4 method which gives at least a /64 to each IPv4 address is
nicer, since then you get the choice of making each host play for itself
to get optimal routing, or letting them route via a single
tunnel-capable router on each network segment. And it's an orthogonal
issue to the _real_ problem, which is getting optimal IPv6 routing to
the outside world by multi-homing, without the useful 'scope' concept
forcing you to pick the right addresses all the time.
--
dwmw2
|