Subject: comments on sl-impact-02

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sat, 15 Mar 2003 18:38:42 +0900

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-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Mika Liljeberg <[email-masked]>
Date: 15 Mar 2003 13:44:40 +0200

> 	if (sa6_dst.sin6_scope_id != zone) {

Exactly. Our implementation does the same thing.

While the text in SCOPARCH is already reasonably clear on this, I think
this is important enough that it would be worthwhile to put the above
code into SCOPARCH in pseudo code format.

	MikaL

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 15 Mar 2003 07:40:45 -0500

Hi Jinmei,

Thank you for your detailed feedback.

A few questions about your response...  I'll try to respond
to the more substantive points later.

>Technically, this is not really true since links are larger scope than

Does anyone have an implementation today that has any special
handling for multi-interface links?  If you want to send a
packet to a LL address, are you supposed to send it out all of
the interfaces for that link, or only one of them (if so, which
one)?

>Is such usage included in the "general" use?

I don't know...  What are you doing this for?  If you are doing it
to configure and test a router, then I would say 'no', this isn't
general use.

>it back to the same interface.

We definitely need to discuss this "links are larger than interfaces"
concept...  This will probably lead to link-local addresses having
more of the problems associated with site-local addresses than I
originally thought.

>resolvers?  Why is this paragraph here, not in 3.3.2.2?

Actually, all hosts will have to insert a zone ID.  It will be
easier to do this on single-site systems (since they only have
one ID to insert), but it is needed on all systems.  I could
make this clearer.

>resolver?  If so, I don't think this is not a so common

I'll have to ask whoever sent me the text :-).  I think it was
Rob Austein.

>specify zone ID, regardless of the scope type.

Sorry, I don't understand your statement, either.

If the application has a dialogue box in which the customer can specify
an IP address (instead of a host name), the UI will need to allow the
user to enter a zone ID, as well.  That isn't true in IPv4, but it will
be needed in IPv6.

>zone ID in the kernel, so that applications need not be scope-aware.

Do you set a default zone ID for each scope?  So, there would be a
default link and a default site?

>NAT.  Could you be more specific please?

We don't have any plans to provide portable addresses in IPv6, so
people will end-up deploying IPv6<->IPv6 NAT in order to gain address
portability/ISP-independence for their internal addresses.  I don't
like this, but I consider it a fact of life.

When they do deploy IPv6<->IPv6 NAT, it is important to have a set
of readily-identifiable non-global addresses to use behind the NAT,
so that we can prefer IPv4 global addresses to local IPv6 addresses
(and vice versa).  I am suggesting that site-local addresses be used
for this purpose.

>Do you actually mean IPv6-to-IPv4 NAT (not IPv4-to-IPv6)?

I mean both NAT-PT (IPv4<->IPv6) and IPv6<->IPv6 NAT (translating
internal IPv6 addresses to external IPv6 addresses).

Margaret

---

From: Mika Liljeberg <[email-masked]>
Date: 15 Mar 2003 16:24:00 +0200

Hi Margaret,

> I'll have to ask whoever sent me the text :-).  I think it was

It's not so unheard of to run a local copy of BIND for caching. I used
to do this at home myself when my ISP was having problems with their DNS
servers. Some people also routinely use pdnsd with their Linux/FreeBSD
boxes:

http://home.t-online.de/home/Moestl/

> default link and a default site?

I can't comment on the KAME implementation, but in general you can just
specify a default interface and read the default zone IDs for each scope
level from the scope table of that interface.

Our implementation actually has a mechanism, whereby we let the stack
select the default interface, but we can constrain the set of possible
interfaces to any specific zone. So we can say, for instance, pick any
interface from this link, or pick any interface from this site.

	MikaL

---

From: Markku Savela <[email-masked]>
Date: Sat, 15 Mar 2003 16:31:28 +0200

> the interfaces for that link, or only one of them (if so, which

No special handling, you can just have multiple interfaces on the same
link. When sending to a link local address, system picks one interface
(unless application or some other configuration setting does not give
some preference).

> user to enter a zone ID, as well.  That isn't true in IPv4, but it will

Actually, almost similar thing is needed in IPv4 due nasty use of
private addresses (ISP offers link with 10-net addresses, and your
company has also internal net with 10-net addresses (via VPN
tunnel). Now, when you type in addresses, you need to specify whether
you mean address within ISP space or company space... And, even
nastier, you have to specify the "scope" for DNS too: resolve from ISP
nameserver or company nameserver (via VPN)? Not really doably with
traditional IPv4 stack, but with scoped IPv6/4 stack you can actually
make it work.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sun, 16 Mar 2003 01:06:59 +0900

>(unless application or some other configuration setting does not give

	to be clear: for outgoing packet, that should be enough.  for incoming
	packet, you will need to have a mapping table of
		interface id -> link id
	and translate id accordingly and use "fe80::1%linkX" as the identifier
	for the peer.

>traditional IPv4 stack, but with scoped IPv6/4 stack you can actually

	the key issue here is whether to mandate the above nastiness (multiple
	routing table for fec0::/10 space) for every node or not.  i personally
	vote for simpler implementation, therefore vote for very limited
	site-local address usage.

itojun

---

From: Markku Savela <[email-masked]>
Date: Sat, 15 Mar 2003 18:15:25 +0200

> 	and translate id accordingly and use "fe80::1%linkX" as the identifier

Such mapping is very simple: you just have each interface associated
array of scope id's (16). For incoming packet, you just complete the
source and destination addresses with: linkX =
interface->scopes[scope_of_addr]. Works also for multicast
destinations, which may have almost any scope.

---

From: Mika Liljeberg <[email-masked]>
Date: 15 Mar 2003 18:41:45 +0200

> 	site-local address usage.

Pending GUPI addresses, it's hard to see how such nastiness can be
avoided with nodes that must occupy a site border (e.g. wireless hosts
that connect to more than one site). Not that a full implementation
needs to be mandated for all nodes, but the applicability of a simpler
implementation will necessaarily be limited to single-site contexts.

	MikaL

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 17 Mar 2003 15:56:45 +0900

>>>>> On 15 Mar 2003 16:24:00 +0200, 
>>>>> Mika Liljeberg <[email-masked]> said:

>> >resolver?  If so, I don't think this is a so common
>> >configuration.
>> 

> It's not so unheard of to run a local copy of BIND for caching.

(I corrected a typo in my original message.)
I know, and I myself run a BIND caching server on my laptop, but my
point is that "not so unheard" does not mean "common configuration".

> level from the scope table of that interface.

Hmm, perhaps I was not clear in the reply to Margaret (I should have
read the entire thread before replying to the first one...).  We
actually implemented this way; we support the ability to specify the
"default interface."

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 17 Mar 2003 16:03:46 +0900

>>>>> On Sat, 15 Mar 2003 18:15:25 +0200, 
>>>>> Markku Savela <[email-masked]> said:

> interface-> scopes[scope_of_addr]. Works also for multicast

Yes, that's exactly what our current implementation does (except the
"fe80::1%linkX" notation).  So, in some points, our implementation
have already prepared for the "links are larger than interfaces"
model.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 17 Mar 2003 15:50:42 +0900

>>>>> On Sat, 15 Mar 2003 07:40:45 -0500, 
>>>>> Margaret Wasserman <[email-masked]> said:

> the interfaces for that link, or only one of them (if so, which

Though we've not implemented multi-interface links, I'd implemented
this function so that only one of the interfaces should be the
outgoing link for each link-local destination.

> to configure and test a router, then I would say 'no', this isn't

We use this for management purposes, especially when we have a routing
trouble.  A typical case is that

- we have a point-to-point link where we only assign link-local
  addresses.
- a routing trouble happens around one side of the router, and we
  cannot send packets beyond the router.
- to diagnose this, we first try to ping the router using its
  link-local address.
- if the router is still alive, we'll then try to log in to the router
  (via ssh or telnet) using the link-local address.

I guess this is NOT a "general use" according to your reply, and it's
okay since this is a matter of wording definition in the draft.  But
I'd like the draft to make what "specialized purposes" means clearer
so that the reader can easily understand the above usage is a special
case.

> more of the problems associated with site-local addresses than I

I partly agree.  Unfortunately, however, the designer of this model is
Steve, who is out for a long sabbatical...  Besides, please note that
even if we adopt the "links is equal to interfaces" model, the issue
raised in this section still exists as I said above.

> I'll have to ask whoever sent me the text :-).  I think it was

Okay, btw, I actually meant "I don't think this is a so common
configuration," though you seemed to read this correctly:-)

> user to enter a zone ID, as well.  That isn't true in IPv4, but it will

That's correct.  What I'm trying to say is that the dialog box can
just accept the format like "fec0::1%X", as a string, using
getaddrinfo() as a backend.  Then the UI itself does not need to care
about a "zone ID".  Of course, you can call this "Application
user-interfaces will need to support the inclusion of a zone ID".

> Do you set a default zone ID for each scope?

Yes.  More accurately, we allow the administrator to specify the
default zone ID for each scope.

> So, there would be a

Again, yes.  However, a node is not multi-scoped for scopes
larger than links (or subnets for multicasts) by default according to
the default configuration described in the scoping arch draft.  So,
the administrator does not have to set the default site zone in the
default configuration.

> (and vice versa).  I am suggesting that site-local addresses be used

I see your points.  Then please make this clear in this section.

> internal IPv6 addresses to external IPv6 addresses).

I see, so you mean "between IPv4 and IPv6", not "from IPv4 to IPv6".
Then I'd like the former notation than the latter.  Also, you use a
different notation in Section 4.3:

    This includes IPv6 sites that are connected to the IPv4
    Internet via an IPv6-to-IPv4 NAT solutions, such as NAT-PT [NATPT],
                    ^^^^^^^^^^^^
which is one of the source of confusion (for me).  If you intend the
same mechanism (e.g. NAT-PT) both in Section 4.3 and in Section 12,
please be consistent on the notation.

					JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Mar 2003 01:45:26 +0100 (CET)

> the interfaces for that link, or only one of them (if so, which

The way multi-interfaces to a link work in Solairs (using
something called IP Multipathing) is merely a re-interpretation of
API constructs. For instance, if an application says it wants to
send multicast packets out a particular interface (using IPV6_MULTICAST_IF)
the stack reinterprets this as "any interface in the group of interfaces
attached to the same link". The reason for this reinterpretation is because
the purpose of this multipathing feature is resiliency against interface 
failures. If the API was different (e.g. IPV6_MULTICAST_IF was instead
called IPV6_MULTICAST_ZONE with a scope zone id) the reinterpretation
wouldn't be necessary I think.

But the packet only goes out one interface in any case.

  Erik