I've finally read draft-wasserman-ipv6-sl-impact-02.txt. (I admit I
should have done it much earlier...)
(Just to make my position clear)
First of all, I'm not a fun of site-local (SL) addresses, and agree on
limiting the use of SLs *to some extent*. So, I'm not intending to
criticize the draft.
General comments:
I respect the coverage of the draft, but at the same time, I have
several concerns:
- many issues described in the draft are specific to site-border
(multi-sited) nodes. Since we had a consensus of eliminating the
multi-sited case, it would be much simpler and clearer to
concentrate on single-site cases. The current draft seems to impose
too much negative impression on generic SL issues using issues
specific to multi-sited cases.
- the draft often uses the words "complex" and "complexity". Although
I agree that many of them are real issues, I'm afraid such wording
tends to cause subjective discussions. Also, some of the
"complexity" can be dealt with a generic approach applicable to both
link-local and site-local addresses, as I tried to describe below.
We should concentrate on complexities specific to SLs in the draft,
and should be careful if each "complexity" is the case and is a real
issue.
- I cannot still be convinced about the "Limited Use" proposal stated
in Appendix. It is true that all the issues described in the draft
can be solved by the "Limited Use". However, just saying "IPv6
site-local addresses should be reserved for use on isolated,
single-site networks" introduces another issues about intermittently
connected sites or sites migrating from isolated networks to
globally-connected ones. So the current "Limited Use" proposal is
just shifting one set of problems to another, at least to me. At
this moment, a reasonable compromise is to describe the issues and
to let administrators use SLs in a globally-connected site at their
own risk.
Detailed comments follow:
Abstract
Although there are several benefits attributed to site-local
addressing, some of those benefits can be more easily achieved
through less problematic mechanisms.
Hmm, what exactly are the "less problematic mechanisms"? The draft
often refers to provider independent global addresses, but they are
not available at this moment and have their own issues. So if the
"less problematic mechanisms" include provider independent global
addresses, it's not fair just to say " can be more easily achieved."
3.1.2.1 Problems for All Site-Border Nodes
Some people have commented that the same problems exist for link-
local addresses, but this is not entirely true. Link-local
addresses can use an existing identifier, the interface name or
number, as their qualifier, while site-local addresses require the
configuration of an artificial zone ID.
Technically, this is not really true since links are larger scope than
interfaces.
In general, link-local addresses will only be used for
specialized purposes or on single-link networks where they can be
treated exactly like global addresses.
I agree about the DNS issue.
But I, as an operator of IPv6 networks, often use ping or ssh on a router
(i.e., a multi-link nodes) with disambiguating an appropriate link.
Is such usage included in the "general" use?
3.1.2.2 Problems for Site-Border Routers
All IPv6 routers will need to check
all forwarded packets to determine if either the source or
destination is link-local. If so, the packet will be discarded and
an appropriate ICMP error message will be generated.
The procedure cannot be that simple. First, (again) since links are
larger than interfaces, it is possible for a router to forward a
packet with a link-local source or destination from an interface to
another one. Even in the default configuration where there is a
one-to-one mapping between links and interfaces, a router can receive
a packet with a link-local destination from an interface and forward
it back to the same interface.
While the draft says:
If the destination address is site-local, the router will look at
the interface on which the packet was received to determine the
site-local zone in which the packet originated, and will perform a
lookup in the correct site-local forwarding table and forward the
packet, as indicated.
However, this should also apply to link-local addresses as I said
above. And, in fact, our implementation adopts a generic forwarding
routine used for all type of scopes like this:
/* Source scope check. rt_ifp is the outgoing interface for dst */
in6_addr2zoneid(rt->rt_ifp, &ip6->ip6_src, &zone);
if (sa6_src.sin6_scope_id != zone) {
icmp6_error(mcopy, ICMP6_DST_UNREACH,
ICMP6_DST_UNREACH_BEYONDSCOPE, 0);
}
/* Destination scope check */
in6_addr2zoneid(rt->rt_ifp, &ip6->ip6_dst, &zone);
if (sa6_dst.sin6_scope_id != zone) {
m_freem(m);
return;
}
(I simplified the actual code for brevity. The full source can be
obtained from the KAME web site.)
3.3.1 DNS Server Issues
In summary, it seems to me that this section mixes site-local specific
issues and other DNS issues, though I admit SLs may introduce
additional complexity to the other issues.
The first part of this section apparently talks about generic issues
of split DNS. Though it would be true that the use of SLs inherently
requires (a kind of) split DNS, I also guess that enterprise operators
will still use split DNS even if they only have global addresses, in
order to hide host names of the intranet. If this is the case, the
issues introduced by split DNS are not so tightly related to SLs.
The second part of this section talks about the home or SO-HO network
case. In this case, we'll first solve an even harder issue; how to
register home or SO-HO host names to the name server in the ISP network.
If we really cannot solve this, the question about the SL implication
is also meaningless. If we can solve this, I also think SL related
issues can be addressed using per-office configuration in the ISP DNS
server.
3.3.2.1 DNS Resolver Issues for All IPv6 Nodes
The current address
selection rules prefer site-local destinations, so that site-local
addresses will be used, if available.
(This is just an editorial comment) More precisely, the address
selection rules prefer smaller-scope destinations.
The DNS resolver must also specify a zone ID for any site-local
addresses that are included in the address list returned to the
calling application. [....snip]
I'm a bit confused. Isn't this an issue only for site-border
resolvers? Why is this paragraph here, not in 3.3.2.2?
For example, this mechanism would not work properly when a local
caching resolver is used. In this common configuration, ...
What exactly do you mean by "a local caching resolver"? Do you mean,
e.g. a BIND DNS caching server running on the same node of the
resolver? If so, I don't think this is not a so common
configuration.
3.3.2.2 DNS Resolver Issues for Site-Border Nodes
So, Node-1 will never receive
site-local addresses for nodes in Site-B. Node-1 will not realize
I think this is over-simplification (or does not describe the actual
issue). Technically, DNS-A can also store site-local addresses for
site-B. The essential problem here is that Node-1 cannot disambiguate
the site-local addresses returned from DNS-A. (So, as a conclusion, I
agree that this is a problematic case.)
3.4 Mobile IPv6 Issues
The use of site-local addresses in the MIPv6 home address option
may cause security concerns. If site-local addresses are used as
an access control mechanism, it is important that MIPv6
implementations do not represent packets to upper layers as being
addressed to or from site-local addresses if those packets may
actually have originated outside of the local site.
I don't get why this is specific to SLs. It seems to me this is a
general issue like "if particular prefixes (as a home address) are
used as an access control mechanism, it is important ...".
3.6 Network Management Issues
This problem also exists for link-local addresses. However, the
inclusion of site-local addresses in the DNS, preferring them in
address selection rules, and using them for access control could
result in site-local addresses being used much more widely than
link-local addresses.
Is this really true? In network management cases, I believe we'll see
many link-local addresses off-link, since all IGP uses link-local
addresses to represent next-hops.
3.7 Application Protocol Issues
The application space can be broken down into several categories,
each of which will be impacted differently by IPv6 site-local
addressing:
This classification is very helpful, but it would be much better with
concrete examples. In fact, I've seen requirements for concrete
examples on IPv4 link-local discussions in the zeroconf ML so many
times. Answering the requirements here would simplify future
discussions.
Application user-interfaces will need to support the inclusion of a
zone ID whenever an IP address is entered by the user,
I'm not 100% sure what "Application user-interfaces" means here.
Scope-aware getaddrinfo() can provide a transparent user-interface to
specify zone ID, regardless of the scope type.
and
applications will have to add a default zone ID to IP addresses
when one is not provided.
This is not necessarily true, or at least an implementation dependent.
In fact, implementation in fact supports the ability to set a default
zone ID in the kernel, so that applications need not be scope-aware.
3.8.1 IP Security Issues
(Just as a comment) The problem described in this section is specific
to scope-border nodes (i.e., site-border nodes for the site-local
case). Also, the same problem exist for link-local addresses.
3.8.2 Key Exchange Protocol Issues
Key exchange protocols pass around information that is used to
populate security tables. In order for appropriate security
policies to be enforced for site-local communication, keys will
need to be distributed for site-local IPv6 addresses.
This is okay, but
However, key
exchange protocols are unaware of site boundaries, and it is
unclear how they will determine how far site-local keying
information should be distributed.
I don't understand this. I'm not even sure if this is a description
about key exchange protocols in general or if this assumes a
particular key exchange protocols such as IKE. Could you be more
specific?
4.3 Networks behind NATs
This includes IPv6 sites that are connected to the IPv4
Internet via an IPv6-to-IPv4 NAT solutions, such as NAT-PT [NATPT],
as well as IPv6 sites that may be connected to an IPv6 Internet
using IPv6-to-IPv6 NAT.
I don't understand the intended usage about sites using IPv6-to-IPv6
NAT. Could you be more specific please?
4.5.1 Site-Local Access Control and Tunneling
It seems to me this section talks about generic security issues on
tunneling, not ones specific to SLs.
12 Appendix A: "Limited Use" Proposal
So, the author of this document recommends that IPv6 site-local
addresses be reserved for use on isolated, single-site networks or
behind NATs (either IPv4-to-IPv6 or IPv6-to-IPv6 NATs).
Do you actually mean IPv6-to-IPv4 NAT (not IPv4-to-IPv6)?
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
