Subject: Re: Textual Address Change for Scope-IDs

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 03 Dec 1999 00:29:07 +0900

Sorry for the long delay, but please let me supplement the discussion.

>>>>> On Sun, 21 Nov 1999 14:32:56 -0500, 
>>>>> Jim Bound <[email-masked]> said:

> Are you saying that a user must need to know the scope-id in
> addition to the IPv6 address when it keys in the dst address for ftp,
> telnet, ping etc.. If so I strongly disagree with you and if this were
> true IPv6 is dead right now in the market.  It also completely broke the
> key concept of Ipv6 which is simplicity and that it is extensible to the
> IPv4 architecture.

I agree that a "normal" end user does not (and even should not) care
about scoped addresses, especially about link-local addresses. In fact
I myself don't use them in daily use as an end user. However, as an
administrator of the WIDE IPv6 backbone (called the WIDE 6bone) in
Japan, I sometimes have to type link-local addresses for "normal"
applications such as telnet, ftp, and ssh.

I'll show you a concrete example. This is basically a same example
that Francis mentioned in his earlier mail:

>>>>> On Sun, 28 Nov 1999 18:19:22 +0100, 
>>>>> Francis Dupont <[email-masked]> said:

> => this is NOT reasonable and ping/traceroute are not the only example
> where scoped & numerical addresses should be allowed. For instance when
> you have a major problem in your network you'd like to use a scoped &
> numerical address to do a telnet on your router (in this kind of case
> the DNS is the first thing which breaks :-).

but I'll depict it again more concretely in order to explain that our
approach of textual addresses is not based on (just) an architect's
complacent but on a request from practical operation.

We have many ATM point-to-point links in the WIDE 6bone, and most of
the ATM interfaces have link-local addresses only (i.e. usually we
don't assign a global address to an ATM p2p interface). Here is a
typical configuration:

       ethernet                 ethernet
      |----+----|                   |
           |                        |
           |  (pvc1)  ATM           |
        router-A===========router-C-|
     (pvc0)||                       |
           ||                
          ATM
           ||
           ||
        router-B
           |
       |---+----|ethernet

Each router assigns its global address to its ethernet interface
only. No ATM interface in the above picture has a global address.
Router-A has two ATM interfaces; pvc0 and pvc1. The link designated by
the interface pvc0 connects router-A and router-B, and the link
designated by the interface pvc1 connects router-A and router-C.

Now, suppose that the routing daemon on router-B hangs up. I have to
reinvoke the daemon, but I have to do it via network since router-B is
located far from my office. Apparently I can't use FQDN (resolved to
a global address of router-B) nor even a textual global address,
because this is a routing trouble.

So I have to login router-A first, and then try to login router-B
using link-local addresses. The procedure is as follows:

1. Confirming the link-local address assigned to the ATM interface of
   router-B.
router-A% ping ff02::1@pvc0
PING(56=40+8+8 bytes) fe80::a --> ff02::1
16 bytes from fe80::a@lo0, icmp_seq=0 hlim=64 time=0.474 ms
16 bytes from fe80::b@pvc0, icmp_seq=0 hlim=64 time=0.374 ms(DUP!)

So the address should be fe80::b.

2. Logging in router-B using the address by the telnet command.
% telnet fe80::b@pvc0

Trying fe80::b... 
Connected to fe80::b@pvc0.
Escape character is '^]'.
login: root
Password: ****
(login OK)
...

Note that we can't just type
% telnet fe80::b
here, since router-A has more than one interface(i.e. link) and hence
the kernel can't detect which link it should try to connect.

Although the kernel could spray neighbor solicitations for fe80::b on
all links that router-A attaches in order to detect an appropriate
link, we can't completely rely on the result. This is because router-C
might also assign fe80::b to its ATM interface and might return a
neighbor advertisement faster than router-B. Currently we have no
mechanism to (automatically) resolve such conflict. Even if we had
one, the administrator of router-C might not accept to change the
link-local address especially when he/she belongs to a different
organization than ours.

3. Reinvoking the routing daemon
router-B# gdc restart(or something)

[end of the procedure]

Sometimes just reinvoking the daemon is not sufficient. We might have
to upgrade the daemon in advance. In such a case, we use the ftp
command with a link-local address for example.

# ftp fe80::b@pvc0
Connected to fe80::b@pvc0
220 router-B FTP server (Version 6.00) ready.
Name (fe80::a@pvc0:jinmei): root
331 Password required for root.
Password:XXXX
230 User root logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> put gated
local: gated remote: gated
200 EPRT command successful.
150 Opening BINARY mode data connection for 'gated'.
226 Transfer complete.
...
[end of the example]

I believe that the above examples show link-local addresses (and our
extended format for them) are meaningful at least for network
administrators. I admit the number of network administrators is much
less than the number of *normal* end users, but we can't ignore
administrators to deploy IPv6. I believe that Miyakawa-san, who
commented on this issue before, has the same idea as an ISP guy.

The followings are my comments on some related issues.

As for impacts on existing APIs and applications:
I know your position; you don't want *any* modifications to existing
APIs and applications. But please let me explain some compatibility
issues again.

First of all, please note that I don't intend to obsolete the current
format for scoped addresses. As others said, we can define a "default
scope zone" and just use the current format, and the default zone can
be trivially (and automatically) specified for a *normal* end host
that has only a single network interface.

Also, I don't deny per-application mechanisms (like a command line
option) to specify a "scope zone". We can continue to use them, but
I'd like to provide a standard way to specify a zone as well by
extending the address format.

Our approach surely introduces some modifications to existing
library functions. But we need no modification to applications. We
can just recompile them using the modified library. So the only
difference is in library functions.

If we use the current library and try to use the current address
format:
  It's just OK, but we need a per-application mechanism to handle
  scoped addresses.

If we use the current library and try to use the extended address
format:
  It will fail with an error, and hence we can't handle scoped
  addresses. We need a per-application mechanism (and the current
  address format) to handle scoped addresses.

(in any case, we need a per-application mechanism if we want to handle
 scoped addresses.)

If we use the extended library and try to use the current address
format:
  It's just OK, but we need a per-application mechanism to handle
  scoped addresses.

If we use the extended library and try to use the extended address
format:
  We can handle scoped addresses using the extended library. We can
  also use a per-application mechanism (if provided).

As for standardization:
Though I presented our approach as an I-D, I didn't necessarily intend
to force every vendor to adopt the idea. I submitted the I-D just as a
start point for discussion, and was convinced that there was surely an
issue about scoped addresses. So far, I'm satisfied the result (though
we've not got a consensus of how to solve it).

However, I still believe our approach is useful even from a practical
point of view, and at least several people agreed with us, e.g. Brian,
Francis, and Matt...(if I'm wrong, please correct the list). Even if
the idea will not be standardized as an IETF standard (including
informational), and I don't mind if not, I'd like to continue
to cooperate with the supporters so that we can define a *unified*
address format as an implementation characteristic and thus provide a
unified (and convenience) way to handle scoped addresses for our
(including the supporters') users.

Finally, I'd like to comment on the relationship between KAME and
commercial products.

> Also I appreciate your aggressiveness and your hard work on KAME, but
> you are not planning on shipping a product that a customer will use to
> my knowledge and KAME is a pub domain code base.  I don't see GM or
> Toyota using KAME or freebsd to run their manufacturing or business
> operations.  So please try to see my viewpoint here that is affected by
> production quality products as vendors alter the base operating system
> and networking subsystem for our customers.  

I admit that we KAME team tend to be much aggressive to implement
something about IPv6. But please do not forget that each implementor
of the project comes from a commercial company. We can't provide our
code just as a hobby. We have to (and do) consider how to apply the
code in a commercial usage. In fact, some Japanese network vendors are
trying to port KAME to their (commercial) network products. For
example, please see the following URL:
http://www.wide.ad.jp/events/199909.ipng-interim/japan-slides/sumikawa/

If the companies we belong to stop us implementing something from
their commercial point of view, we can't continue the project. When we
try to implement something, we always consider the companies' position
and can't implement anything just from implementors' interests. I'd
appreciate if you understand the circumstance.

Please also note that we recognize and appreciate Jim's great
contribution to IPv6 in commercial/market side as well as in technical
side. I believe we share the same goal: widely deploying IPv6. I'll
never intend (and have never intended, I believe) to propose/implement
anything that prevents the goal.

> I have to be much more conservative in my thinking than if I was working
> on a public domain code base such as KAME.  

> Somewhere there is a balance that needs to happen I realize but I think
> this whole notion of scope-ids needs a lot of discussion, attention, and
> review before we change anything in IPv6 like the APIs, DNS, Resolver
> code etc.. I am glad KAME is experimenting with this now but please
> don't always assume you experiments are going to be the answer to the
> standard we all use for IPv6.

As for standardization, I already stated my opinion above.

Thanks for reading the lengthy text. Regards,

					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: Jim Bound <[email-masked]>
Date: Thu, 02 Dec 1999 13:22:13 -0500

all good points and I appreciate you taking the time to write them down.
We have to figure out scope-ids and site-local addresses.  and we will
enhance the api spec too working with xnet much closer this time.

thanks
/jim

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 07 Dec 1999 02:07:42 +0900

>>>>> On Thu, 02 Dec 1999 13:22:13 -0500, 

> enhance the api spec too working with xnet much closer this time.

Thanks for reading and responding so quickly. I'm willing to join the
discussion about the above issues, too.

By the way, do you mind if I continue to discuss the extension of
textual address representation for scoped address in this list? If so,
I'll discuss it in a closer place (maybe a closed list or something
which consists of interested people). Otherwise, I'd like to continue
here in order to share the idea as many people as possible.

Thanks,

					JINMEI, Tatuya

---

From: Jim Bound <[email-masked]>
Date: Mon, 06 Dec 1999 14:22:12 -0500

I think thats what this mail thread is for..textual addresses
discussion.

/jim

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 08 Dec 1999 01:40:33 +0900

>>>>> On Mon, 06 Dec 1999 14:22:12 -0500, 

> I think thats what this mail thread is for..textual addresses

Okay, thanks.

					JINMEI, Tatuya