In message <[EMAIL PROTECTED]>, Margaret Wasserm
an writes:
>
>I sent the attached message to the routing area discussion list. I thought th
>at people on
>the IPv6 list might be interested in this discussion, so I will forward a mess
>age containing
>the responses after this one. I suppose I just should have cc:ed the IPv6 gro
>up in the
>first place...
>
My strong preference would be to drop site-local addresses completely.
I think they're an administrative and technical nightmare.
Margaret has pointed out that our routing protocols don't support
site-local addresses. The only alternative suggestion I've seen thus
far is to run multiple instances of, say, OSPF on all routers within a
site. But how are these distinguished from each other? OSPF runs with
an IP protocol number, not a port number, so we can't have multiple
instances that way. And RFC 2740's specification of the necessary
multicast addresses notes that they're all link-local. Still, there's
apparently running code; I look forward to seeing the details.
I'm very concerned about DNS entries. When should a DNS server -- or a
caching resolver -- return a site-local address? (If the DNS never
returns such things, they're useless.) One suggestion I've heard is
two-faced DNS servers -- only return site-local information if the
querier is within the same site. Apart from the fact that I have no
idea how that determination can be made -- surely no one will suggest
putting site-local addresses into NS records -- RFC 2182 (aka BCP 0016)
specifically warns against putting all secondary servers for a zone
within a site:
Consequently, placing all servers at the local site, while easy to
arrange, and easy to manage, is not a good policy. Should a single
link fail, or there be a site, or perhaps even building, or room,
power failure, such a configuration can lead to all servers being
disconnected from the Internet.
Secondary servers must be placed at both topologically and
geographically dispersed locations on the Internet, to minimise the
likelihood of a single failure disabling all of them.
Etc.
There will also be a lot of unnecessary pain in DNS maintenance as
"sites" are split or merged. v6 is designed to support easy renumbering
of global addresses, but those are designed to reflect topology.
Site-local addresses do not, which increases the probability of
address space collision during a merger.
Philosophically, I think that the problem is that a "site" is a new
(and deliberately poorly defined) concept. The DNS is designed to work
with administrative boundaries, while routing and addressing reflect
topology. We now have a new concept that is neither administrative nor
topological, but one that must be supported by administrative and
topological mechanisms.
Finally -- and perhaps least important -- I'm not sure what problem
they solve. I can understand site-local multicast, since (most)
inter-site traffic traverses links that are not inherently
multicast-capable. There is thus considerable extra expense. But why
do I need site-local unicast addresses?
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com ("Firewalls" book)
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
