Subject: RE: Textual Address Change for Scope-IDs

From: Brian Zill <[email-masked]>
Date: Fri, 19 Nov 1999 09:54:40 -0800

Hi Jim,

Thanks for clarifying your position.

> I think any input to anything with scope-id
> should be put in sin6_scope ID field first.
> I think now we all agree with that it should
> not be part of the IPv6 address.

I believe that in user-space, when an IPv6 endpoint is stored as a binary,
that the scope id should be in its own field (aka sin6_scope_id).  The 128
bit IPv6 "address" should be in a separate field (aka sin6_addr).  So I
think we agree on this.

> For some reason I thought some were
> proposing this.

Well, the common interpretation of the old proposal that Robert Elz recently
brought back up is that you would merge the scope id information into the
sin6_addr field and everywhere else you used a in6_addr.  I'm against this,
because I think it would be too confusing to programmers.

> But if I want to use infconfig for scoped addresses as an example to
> discuss this beast.  It should be keyed in as follows:
> 
>   ifconfig fe80::1 FUZZY le0
> 
> NOT 
> 
>   ifconfig fe80::1|FUZZY le0
> 
> I also don't believe any strings passing around ipv6+scope-ids should
> exist like the above.

Here I disagree with you.  I think it is inevitable that people will want to
put these two together since a scoped address isn't complete without its
corresponding scope id.  At least two existing implementations already do
have such textual representations, and (unfortunately) use a different
format.  So I think something like the Jinmei/Onoe draft (it's not Shin's
draft, he was just commenting on it) is needed.  Otherwise we'll end up with
everybody having their own representation.
  
> So I do not support Shin's draft then
> and think it is not necessary.  I
> thought they wanted be able to identify
> the next field with a delimiter
> separately like:
> 
>   ifconfig fe80::1 | FUZZY le0
> 
> Where "|" tells an application parsing the
> above that following this is the scope-id.
> Which I would agree to.

But this is logically the same thing!  It's just a delimiter that contains
spaces.  Personally, I think it's easier on parsers for us to choose a
delimiter that doesn't contain spaces.

--Brian

> /jim
--------------------------------------------------------------------
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: Fri, 19 Nov 1999 13:14:42 -0500

no big deal we just disagree...

what do others think???  

I will go with consensus as always...

but I don't wnat to change inet_ntop or inet_pton 

if we go down this path we need new apis.

but thats Ok as I already know I am going to have to do update to
rfc2553 I think... but we can't break existing implementations when it
happens.

I will bring up roberts idea again when we discuss eriks site prefix
draft.

/jim

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sun, 21 Nov 1999 13:47:11 +0900

>>>>> On Fri, 19 Nov 1999 09:54:40 -0800, 
>>>>> Brian Zill <[email-masked]> said:

> because I think it would be too confusing to programmers.

Agreed. Merging the scope id into the sin6_addr field was used in
older versions of the KAME (WIDE) IPv6 stack, which was what Robert
Elz mentioned in his previous mail, but we discarded the approach (at
least in the user space) because of the same reason above.

> everybody having their own representation.

I agree with Brian. In fact, one of the motivations of our draft is to
avoid an unfortunate situation that every implementation has its own
(maybe different) representation and users are confused.

Currently, there are at least two different representations
(i.e. MSR's and KAME's), but I believe that the difference is
relatively a minor issue and we can agree on a specific format.

As for the API issues, the new textual representation will surely
introduce some extensions or changes in the current basic and/or
advanced APIs. But without the extensions, you'd modify every
application that should handle scoped addresses. For example, in order
to allow the ifconfig program like 'ifconfig fe80::1 FUZZY le0', you
should introduce some extensions to the existing APIs or modify the
ifconfig program itself. I belive the latter approach is more painful
for programmers and should be avoided.

We should undoubtedly ensure as much lower-compatibilty as possible
when introducing such extensions to the existing APIs and
applications. I'm willing to cooperate with other implementors on this
point and to make an effort to accomplish this.

					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: Sun, 21 Nov 1999 00:19:29 -0500

>for programmers and should be avoided.

I strongly don't agree with the above and its the bottom line I am glad
you articulated this so crystal clear.  

The way I want it as you have it above it causes no change at all to the
API in that case.  All that is done is we go into ifconfig and add
another parameter and move it directly to sin6_scope_id.  Then
sockaddr_in6 is complete architecturally with this issue.  What you,
Brian, and Tim are doing is supporting a change to every module in the
source pool that for some of us vendors has been deployed, where this is
not an issue.  And why if it is adopted needs a new API not additions to
the existing ones.  But I disagree strongly with this premise being used
to concatenate the scope and the address textually.

At the end of the day the scope is not useful if not entered into
sin6_scope_id.  There is no benefit to the code and more work to do this
and is a very bad idea IMO.

>point and to make an effort to accomplish this.

No impact to the APIs is what I am asking.

/jim

					JINMEI, Tatuya

---

From: Jim Bound <[email-masked]>
Date: Sun, 21 Nov 1999 00:37:46 -0500

Where else do you see this being used besides as the user interface.
I think we should discuss where this will be useful.

But is it useful any place else other than the user interface?

If not then this is really an implementation GUI issue only and not an
IETF issue or an API issue.  

The sin6_scope_id should be presented within a software implementation
either as its own parameter or as part of the structure sing6_scope_id.

Also inet_pton and inet_ntop were invented to work with IPv6 addresses
proper.  

If one should add a scope-id to the address in a string representation
as you suggest it no longer is an IPv6 Address by any standard we have
today.  Hence, it should have its own API for parsing.  This should not
be a change to the APIs that work with IPv6 addresses.       

/jim

---

From: [email-masked] (Sam Manthorpe)
Date: Sat, 20 Nov 1999 22:10:07 -0800 (PST)

There is another possibility which I don't think has been considered
yet:

	Put the scope-id in the in6_addr in the same way as
	KAME do (did?) it, _but_ only in the binary instances
	of the address, never in textual representation.

	In other words, getipnodebyname() would give you an in6_addr
	with the scope-id inserted near the top of the address,
	but functions like inet_ntop() would ignore that byte,
	interpreting it as zero, so that the user never actually 
	sees it's there.

This has the following advantages:

    1)	Solves the problem of scope-id ambiguity of addresses
	created by getipnodebyname() and inet_pton().

    2)	The textual representation of IPv6 addresses seen by the 
	user (and passed around from app to app, system to system) 
	would not contain the scope-id and would thus be 
	completely portable, as they should be.

    3)	No changes to applications.

    4)	No changes to the API docs.

    5)	Doesn't break the API or ABI.

I don't _think_ this exactly what KAME are doing, is it?  I'm assuming
not.

I can't think of any disadvantages to this scheme, but I'm sure
somebody else on the list can :-)

Cheers,
Sam.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sam Manthorpe, SGI.  tel: (650)933-2856 fax: (650)932-2856  [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: [email-masked]
Date: Sun, 21 Nov 1999 17:52:25 +0900

>But is it useful any place else other than the user interface?

	Jim, I think you are not getting the reason why jinmei came up
	with the draft.  Please read the following and share the problem
	with us.  It is very long, but please read it patiently (I really
	hoped you to be present at 2nd ipng slot...).  Sorry for possible
	typos and grammatical mistakes, I tried my best.

	(I tend to believe that internet-draft should provide more background
	information that lead us to the resulting specification.  Currently
	drafts tend to describe resulting specification only...)

itojun

***
From now on, please forget about DNS or other FQDN-to-address mapping.
All we have is numeric text representation - like we are in dentist's
office.
***

If you have a node with multiple interface/scope, sin6_scope_id is
*required* to disambiguate two scope instances ("zones" in Steve's
terminology).
For example, if your node have two interfaces, and would like to
throw a packet to fe80::x, you MUST disambiguate it somehow.
Because of the design of link-local scope, fe80::x can be on both
sides, and they can be different node.  Probabilistic selection of
destination is a nightmare.  If you do not supply scope identification
with scoped IPv6 address, that address is not sufficient for pointing
single instance on network.

	fe80::x
	   |
	===+==== ether segment 1
	   |
	your node
	   |
	===+==== ether segment 2
	   |
	fe80::x (different instance)

Jim, what you are trying to push now is:
- modify every application that would specify sin6_scope_id, and
  have additional command line option for them
  (like "ping6 -I link fe80::x)
- and put no modification to RFC2553.

We all have been doing that, and we found it insufficient and
very cumbersome.  This is the very reason why jinmei came up with
draft-ietf-ipngwg-scopedaddr-format-00.txt.
Here are step-by-step description of reasons:
- If you have two or more interfaces on a node, and/or if you have
  reachability to multiple sites, you MUST disambiguate destination
  somehow, for EVERY IPv6 operation you would make
  (telnet, ftp, ping6, rsh, ssh, whatever).
- It is impossible to modify EVERY application that makes IPv6
  operation.  Also, in Jim's way we can't provide the users uniform
  command line syntax, or GUI menu box, for specifying scope (some
  tool may have already using -I, for example).
  You will end up providing:
	% ping6 -I link fe80::x
	% telnet -S link fe80::x
	% ssh -s link fe80::x
  This is not uniform and users will have trouble remembering options.
- So, we needed to come up with uniform way to specify, or print,
  scoped address notation.  For now let us suppose that we agree to use
  fe80::x@link.  This way, you can provide the users a uniform
  syntax, like:
	% ping6 fe80::x@link
	% telnet fe80::x@link
	% ssh fe80::x@link
  Also, if routing table is shown like this by netstat:
	Dest		Gateway		Flags	Refs
	default		fe80::x@link	UG	0
  You can just do a cut-and-paste to perform ping6 to your default
  gateway.

***
The above is what the draft is all about.  Jim do you see the point?
***

How to support this notation by API is totally different story.  Read on.
- It is very easy to do it with get{addr,name}info(), as they return
  sockaddr_in6.
- It is very hard to support it transparently with inet_{ntop,pton}()
  and/or getipnodeby{addr,name}().  There are many options.
  - One choice is to not to support it with those APIs, and document that
    they will not be returning "scope" part.  By using those API functions
    you may not be able to support multiple-zone cases.
    Though they may not be complete, they have their own merit;
    they provide a easy way to porting effort in the early-days (but again,
    the application will have a caveat - it will not be able to handle
    multiple-zone cases).
  - Another choice is to change those APIs, somehow.  I'm not sure
    how to do it, I'm not sure if the change can be backward-compatible,
    I'm not sure if the change worth it, I'm not sure if they make any sense
    (they will return in6_addr and they have no room for returning
    sin6_scope_id).

How to preform FQDN-to-numeric mapping is totally different story.
There are so many options/discussions here, including:
(1) how to provide DNS database for scoped space,
(2) DNS spec itself (DNS is designed as single-tree database to be shared
    among everyone in the world.  I'm not sure if it makes sense to
    provide DNS database for scoped zone.  I'm not sure how we can
    standardize how to provide scoped DNS database.  Nowadays, at firewall
    boundary every admin does it differently.  Proposal we have in our hand
    are:
	draft-ietf-dnsind-local-names-07.txt
	draft-ietf-ipngwg-site-prefixes-03.txt
Here are very general mapping strategies I can imagine:
- I believe that FQDN should need no separate notion of scope.  FQDN should
  be complete by its own, and should be somehow mapped into
  <in6_addr, scope_id> pair.  The DNS mapping provides:
	FQDN -> <in6_addr, scope_id>
  If you have two root for DNS database, you may be able to specify preference
  by DNS search order ("search" keyword in resolv.conf).
- Some would say that we need to map like this:
	<FQDN, scope_id> -> <in6_addr, scope_id>
--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Sun, 21 Nov 1999 22:55:56 +1100

Date:        Sun, 21 Nov 1999 17:52:25 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | If you have a node with multiple interface/scope, sin6_scope_id is
  | *required* to disambiguate two scope instances ("zones" in Steve's
  | terminology).

Yes, that is certainly true.

  | Jim, what you are trying to push now is:
  | - modify every application that would specify sin6_scope_id, and
  |   have additional command line option for them
  |   (like "ping6 -I link fe80::x)

That is fairly unreasonable - though I an not sure it is worse than ...

  | - So, we needed to come up with uniform way to specify, or print,
  |   scoped address notation.  For now let us suppose that we agree to use
  |   fe80::x@link.

The difference here is who gets the pain.   In the first it is the application
programmers, who have to manage to provide a (fairly) consistent user interface
and deal with it all over the place.   In the second it is the users who have
to figure out when they need to add the stray extra syntax, and what it should
be (when it is possible to cut/paste that would not be too hard, but it isn't
always).   Then you have to convince them it is necessary (sometimes) - ping
of a global address will work without it, from some hosts (those with only
one interface, or only in one site) all addresses will work without it.
But sometimes it is needed.    As a user interface, that sucks.   And it
doesn't matter in the slightest what the actual syntax looks like.

This is why I still think that putting the id inside the address makes more
sense than any other proposal I have seen.   Aside to Brian Zill: I don't
think this was originally my idea either - I think I picked it up from a
comment made by someone else ages ago - but it was me who argued for it
back when it was rejected years ago.   Aside to Jim Bound: what I am suggesting
(just like everyone else) *is* an API change.   My one happens to be binary
compatible across the interface with the current API (all variants).  Not
that I think that is essential - early adopters of standards get the benefit
of being their first, the price they may pay for that is that things just
might change from under them.

I am not in the slightest worried about users getting confused by these
things - your average user should *never* see a hex format IPv6 address,
only a domain name format).  The few remaining users, those that do have
to deal with these things can learn this extra bit of trivia as easily as
they can learn about mask and compare type operations, longest match, etc.
The hard part of that learning is to appreciate why it is necessary to
specify this extra piece of info, when it is "obvious to everyone" that
there is only one node anywhere I can reach with the address I am entering.
Once that is grasped, the detail of the syntax of where the number is
written is minor.

I suspect that much of the reason that we can't get much agreement on what
is important here is because we really have no common agreement on how
the limited scope addresses should, or will, be used.  Anything and everything
from "they're useless, they will never be used" to "these addresses should
be used whereevr possible, with global addresses only used when there is no
other way" exists I believe.   This lack of any common ground means that
we all see the issues differently - what is important to one is irrelevant
to another.

I think it might be a good idea to simply forget about standardising this
(in any form - including informational recommendations) until we have a
better general sense of what is needed, where, and why.   This is going to
mean that implementations are all going to do different things, and users
won't get any consistency - but that's normal in an immature product, which
site & link local addressing certainly is (while there are kind of analogs in
IPv4, when you look closely, they're really nothing like the same at all).

kre

---

From: [email-masked]
Date: Sun, 21 Nov 1999 21:24:50 +0900

>The difference here is who gets the pain.

	Yup.  I only described the background thoughts for the draft.

>sense than any other proposal I have seen.   Aside to Brian Zill: I don't

	I can tell you about our experience.
	KAME has been using IPv6 address that embeds interface identifier for
	kernel internal structure, like:
		fe80:1::2e0:98ff:fe00:309f
		for 
		fe80::2e0:98ff:fe00:309f on interface 1
	The embedded form appears on routing table, or interface address
	structure (struct ifnet, for *BSD).  Sometimes embedded form is
	exposed to userland program, via routing socket, ioctl, or kmem.
	We did not hide the 4th byte for quite some time on outputs from
	netstat or ifconfig (which uses routing socket or ioctl), like:
>>ne2: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>>	address: 00:e0:98:00:30:9f
>>	media: Ethernet manual
>>	inet 210.160.95.98 netmask 0xfffffff0 broadcast 210.160.95.111
>>	inet6 fe80:1::2e0:98ff:fe00:309f prefixlen 64

	Our experience is, users will get confused if we print address
	expression that differs from that appears on the wire.  IPv6
	introductory material does not speak about "embedded" form, so they
	have no idea what is the 4th byte (though we document it repeatedly
	in KAME documents, 95% of users do not read them at all :-P).

	So, we are now using fe80::x@link form in many places.  I believe it
	provided much ease of use to the users.  We get less questions
	about embedded form.
>>ne2: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>>	address: 00:e0:98:00:30:9f
>>	media: Ethernet manual
>>	inet 210.160.95.98 netmask 0xfffffff0 broadcast 210.160.95.111
>>	inet6 fe80::2e0:98ff:fe00:309f@ne2 prefixlen 64 scopeid 0x1

itojun

---

From: Robert Elz <[email-masked]>
Date: Mon, 22 Nov 1999 00:31:49 +1100

Date:        Sun, 21 Nov 1999 21:24:50 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	I can tell you about our experience.
  | 	KAME has been using IPv6 address that embeds interface identifier for
  | 	kernel internal structure, like:

Yes, I know, I am running it.   I love it.   I *like* to see the
addresses that way.   It will be a pity to see it vanish the next time
I upgrade (if that is what will happen).

  | 	Our experience is, users will get confused if we print address
  | 	expression that differs from that appears on the wire.  IPv6
  | 	introductory material does not speak about "embedded" form,

yes, right now that would be a problem - as this method is not generally
documented anywhere in particular, people won't expect it.   However, were
this adopted as the "normal" way for these addresses to appear, then all
the rest of that doc (the next edition of Christian's book, etc) would all
get fixed, and this would be much less of a problem.

kre

---

From: [email-masked]
Date: Sun, 21 Nov 1999 22:38:09 +0900

>get fixed, and this would be much less of a problem.

	One additional comment on embedding scope id into address:
	The portion we are using for scope id (3rd and 4th byte of the address
	for KAME case) is not really a reserved field.  We need a update to
	RFC2373 2.5.8 (for scoped unicast) and 2.7 (for multicast)
	as well if we are going to take this route.

itojun

---

From: Bill Sommerfeld <[email-masked]>
Date: Sun, 21 Nov 1999 09:46:31 -0500

I also like the idea of stuffing the scope id into the
more-or-less-unused parts of link-local and site-local addresses, as
done by KAME; having to allocate additional space to possibly store a
scope id seems like a waste.. the addresses are big enough as it is..

As done by Kame, it does limit you to 2**16 different scopes of each
type but this doesn't seem to be a significant restriction (and, at
least for link local addresses, bytes 5 and 6 should be easily
grabbable).

Reserving bytes 3..8 of link-local addresses (and bytes 3..6 of
site-local addresses) seems like a good idea anyway...

					- Bill

---

From: [email-masked]
Date: Mon, 22 Nov 1999 00:03:28 +0900

>scope id seems like a waste.. the addresses are big enough as it is..

	Though I think many understands it, there are some twistswith
	address-with-embedded-scope:
	- on-wire form and printable form will become different.
	  broken implementation may throw embedded form onto the wire and
	  cause problems.
	- printable form cannot be exchanged across machines, like
	  cur-and-paste across xterm for different machines
	  (fe80::x@link has the same problem, though).
	- at IETF meetings, for site-local addresses, there has been
	  discussion about use of "printable" scope name used across a site
	  (like "cisco" and "stanford", advertised somehow across a scope).
	  If we embed scope into address, and if FQDN and numeric address
	  mapping is like
		<FQDN> -> <in6_addr with embedded scope-id>
	  we will have no chance to introduce printable scope name.

itojun

---

From: Robert Elz <[email-masked]>
Date: Mon, 22 Nov 1999 03:27:58 +1100

Date:        Mon, 22 Nov 1999 00:03:28 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	Though I think many understands it, there are some twistswith
  | 	address-with-embedded-scope:
  | 	- on-wire form and printable form will become different.

Yes, that's certainly true.

  | 	  broken implementation may throw embedded form onto the wire and
  | 	  cause problems.

But that is almost irrelevant.  Broken implementations can do almost
anything, and while it is a good idea not to deliberately design things
so as to encourage brokenness, the possibility of something being boken
should not be taken as a restriction (use it to choose between two
otherwise equal choices, but not more than that).

  | 	- printable form cannot be exchanged across machines, like
  | 	  cur-and-paste across xterm for different machines
  | 	  (fe80::x@link has the same problem, though).

Yes, to both.   Though as long as the implementations don't force the
ids upon me, and lets me use whatever I like, I can, if I want, cause
the id's to be consistent across all the systems where cut & paste would
be likely to be useful.   For example, I could use the subnet number
from my global addresses as my interface id's in link local addresses.
(Since the interface id field in a link local will probably be bigger
than the subnet id in a global, I will have lots more id's around to
number the links with no global addressing).  That way, every system will
use the same ID.  I can also pick some random numbering scheme for any sites
I deal with, and assign the same ids to each site on every system.   I
should not be forced to do that, but implementations ought allow me to
(not just force 0 1 2 3 4 .. in some arbitrary order).   Of course, this
is just a quality of implementation issue, and doesn't need to be written
anywhere.

  | 	- at IETF meetings, for site-local addresses, there has been
  | 	  discussion about use of "printable" scope name used across a site
  | 	  (like "cisco" and "stanford", advertised somehow across a scope).
  | 	  If we embed scope into address, and if FQDN and numeric address
  | 	  mapping is like
  | 		<FQDN> -> <in6_addr with embedded scope-id>
  | 	  we will have no chance to introduce printable scope name.

Not necessarily.   If you followed that logic we wouldn't have
printable host names, or printable service (port) names, ...   All
this means is that the way you were thinking of doing it might not work.

As best I recall, the scope_id that exists currently is an integer
anyway, so something would have to map from the name to the number.
Where the number gets put is the only issue after that - is it in
a separate field, or buried inside the address.

kre

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 22 Nov 1999 02:28:13 +0900

>>>>> On Sun, 21 Nov 1999 00:19:29 -0500, 
>>>>> Jim Bound <[email-masked]> said:

> sockaddr_in6 is complete architecturally with this issue.
>...(snip)

Okay, so you prefer the former approach. Now I'm in a different
position than yours, so I'd like to hear other implementors' opinions
and obey the consensus (if we can get one).

Thanks,

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 22 Nov 1999 02:28:29 +0900

>>>>> On Sun, 21 Nov 1999 22:55:56 +1100, 
>>>>> Robert Elz <[email-masked]> said:

> doesn't matter in the slightest what the actual syntax looks like.

I think that users will get the pain in the former approach as well;
"Users have to figure out when they need to add the extra OPTION. ping
of a global address will work without it, all addresses will work
without it".

(snip)

> IPv4, when you look closely, they're really nothing like the same at all).

I agree that we need try to get the general sense, but I belive we
should do now. I think that IPv6 is now fairly mature and that (at
least) the semantics, usage, and importance of link-local addresses
are clear enough.

Thanks,

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 22 Nov 1999 02:28:21 +0900

>>>>> On Sun, 21 Nov 1999 17:52:25 +0900, 
>>>>> [email-masked] said:

> 	with us.

Thank you very much, itojun. Your memo describes our motivation
perfectly. There is nothing that I'd add to respond to the questions
from Jim.

> 	drafts tend to describe resulting specification only...)

Okay, if I have a chance to revise the draft, I'll try to desribe more
precise background.

Thanks,

					JINMEI, Tatuya

---

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

Itojun,

>	typos and grammatical mistakes, I tried my best.

I do get the reason and don't agree with the idea.  Thats all.

>	drafts tend to describe resulting specification only...)

Well I think all drafts should have pretty good overviews for sure. This
is missing in some of my specs too and I intend to correct it.  A good
overview can help reduce discussion.  Thomas Narten has been telling a
few of us we need this in the Internet Area and I for one agree with
him.

>All we have is numeric text representation - like we are in dentist's

This is fine.

>*required* to disambiguate two scope instances ("zones" in Steve's

Agreed.

>single instance on network.

Ok but this has been common knowledge since we invented them and we put
code in to solve the problem in various places.  So OK.. I will keep
reading but have learned nothing new as your stating the obvious.

	fe80::x
	   |
	===+==== ether segment 1
	   |
	your node
	   |
	===+==== ether segment 2
	   |

>- and put no modification to RFC2553.

Yes I am and with great intent too.

>draft-ietf-ipngwg-scopedaddr-format-00.txt.

I have heard you find it cumbersome and Brian finds it cumbersome and I
am still not clear what Tim thinks so when you say "we" please don't
speak for all the implementors or define what we means if that means
KAME thats fine.  

I don't find it cumbersome at all.  In fact I strongly believe
parameterization for user interfaces is fine.  

>  (telnet, ftp, ping6, rsh, ssh, whatever).

I don't agree.  If you are telneting to another node you should just
specify a destination address as a user whether its in the same scope-id
or not users SHOULD NOT have to type ftp FUZZY|FEC0::1 OR ftp FUZZY
FEC0::1 that is unacceptable.  Same for ftp, ping, rsh, ssh, whatever
and I also think having ping6 or ping4 is bogus and it should just be
ping.  But for sysadmin commands like ifconfig that is an entirely
different manner.

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.  Fortuneately I think you have just shown though an
error in your thinking about this problem most likely.  You cannot
specify the dst scope-id for an address at the client, you have know way
of knowning.  And for the apps your listing we don't and should not have
to specify the source address.

>  tool may have already using -I, for example).

This is not impossible and so far I have seen only one application that
needs this at the user interface "ifconfig" I am waiting to hear of
others on the list.

Which by the way was one of my questions you did not answer at all and
proceeded to ask me questions.  Do you want to use two way
communications or just pose the questions you want to talk about.

>  This is not uniform and users will have trouble remembering options.

Users will not want to know about scope IDs at all.

If a user pings another node at FE80::x on another node.  I agree that
is a problem.  But it is the implementation that must resolve the issue
not the user or the user should use a FQDN and this is possible in the
dentist office too. 

But if your saying IPv6 now has caused the following:

 command-to-server dst-address (which is what we have today with ftp, telnet
 etc) 

NOW

 command-to-server scope-id-from-this-client dst-address

Then I think the entire notion of scoped addresses must be revisited and
we should again discuss the idea of EIDs with Locators and ask Noel
Chiappa to come help us sort this out.  Cause I think this is one of his
issues with IPv6 and I am thinking now I agree with him.  Lets not
change just the API lets go back and see if we have to rearchitect this
beast correctly.

I think we are fine though what we need to do is hide this from the user
in some manner and keep ftp, telnet, etc and friends from the client
telling the the application what the scope-id for the client the app
should use to pick the correct source scope-id so it gets to the right
dst address.

This is where Robert Elz's propsal shines.  We embed the scope in the
address and pull it out when we use the address in any manner this way
the DNS works, the user don't have to key in scopes, etc... 

>  You can just do a cut-and-paste to perform ping6 to your default

First I ported ping and got rid of have to use things like ping6.
If you have to use ping6 in KAME you need to fix that one.

Anyway:  I really disagree with the above.  The rt entry for this should
have its own link column.  What you depict is horrible.

>The above is what the draft is all about.  Jim do you see the point?

Itojun I do see the point and I don't agree with the problem statement,
and don't agree with the solution.  Do you get my point.

>    (they will return in6_addr and they have no room for returning

This is different discussion and we will discuss once we get the input
from Carl Williams.

>(1) how to provide DNS database for scoped space,

Different thread but I agree it needs to be resolved.

>	draft-ietf-ipngwg-site-prefixes-03.txt

Which DNS spec?  RFC 1035 or 1036?  If we are to change DNS because of
IPv6 then IPv6 has a major error.

>	FQDN -> <in6_addr, scope_id>

This is the discussion and how we do this is TBD.  

>	<FQDN, scope_id> -> <in6_addr, scope_id>

Well we don't get to reinvent DNS with IPv6 I will tell you that right
now or Internet applications etc.. Or I will become an IPv6 Hater--)...

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 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.

thanks
/jim

---

From: Jim Bound <[email-masked]>
Date: Sun, 21 Nov 1999 15:26:48 -0500

Robert,

>IPv4, when you look closely, they're really nothing like the same at all).

I agree with you in this mail.  I have had to respond to several offline
queries and my real issue is that it would be good if we nail this down
for once and for all before we make further changes.  If we go off now
and change things then I fear we will be changing them again as we learn
more about them.  This IMO is not wise.

I have no issue having pain as an early implementor of a standard.  But
I think there are tests of reaonability to such pain, or we will not get
early implementors of standards, in the IETF.

I do think the idea whoever proposed it to incorporate the scope-id in
the address is a good one.  

But what I have also learned is that the addressing specs as far as
scoped-addresses and I think especially site-local would have no
business or are ready for draft standard.   This is a tell-tale sign of
IPv6 I for one am not happy about and believe it will now hurt IPv6.
We should have left IMO opinion IPv6 with global and link-local addresses
and left the site-local out.  The arguments that they help with
renumbering and permit private address space are not worth the trouble
as global addresses are plentiful for IPv6 and we should just work
harder on the renumbering problems.

/jim

---

From: [email-masked] (Sam Manthorpe)
Date: Sun, 21 Nov 1999 15:02:58 -0800 (PST)

> Once that is grasped, the detail of the syntax of where the number is

I think that isn't the real issue.  The problem with textual
representation of IPv6 addresses with embedded scope-ids is that
they are not portable between nodes.  This is a real issue; one
that will many sysadmin shell scripts to fail.  Or even internally
on the same node.  If you physically unplug interface <A> on a node
then very likely the scope-id of interface <B> will have changed
when the machine is booted.

---

From: [email-masked] (Sam Manthorpe)
Date: Sun, 21 Nov 1999 15:11:03 -0800 (PST)

Itojun,

> 	I can tell you about our experience.

It sounds like you are already doing what I suggested in my mail
yesterday (apologies for not having recognised that beforehand).
Do you have inet_ntop() hide the fourth byte?

In the current IRIX prototype, we have have netstat print scoped
addresses in the form: link1:fe80::...  I agree that this, or the
reverse KAME representation, is a good thing for reducing user confusion.

Your solutions sounds like a good one to me and you have had
real-world exposure of it.

-- Sam

---

From: Robert Elz <[email-masked]>
Date: Mon, 22 Nov 1999 13:04:58 +1100

Date:        Mon, 22 Nov 1999 02:28:29 +0900
    From:        JINMEI Tatuya <[email-masked]>
    Message-ID:  <[email-masked]>

  | I agree that we need try to get the general sense, but I belive we
  | should do now. I think that IPv6 is now fairly mature and that (at
  | least) the semantics, usage, and importance of link-local addresses
  | are clear enough.

Part of IPv6 are now getting quite mature - but the usage of other than
global unicast addresses isn't one of those parts.   There simply aren't
enough big enough sites that are seriously using IPv6 for the various
"wouldn't it be great if I could ..." ideas to have been discovered,
let alone tested yet.

kre

---

From: Robert Elz <[email-masked]>
Date: Mon, 22 Nov 1999 13:13:40 +1100

Date:        Sun, 21 Nov 1999 15:02:58 -0800 (PST)
    From:        [email-masked] (Sam Manthorpe)
    Message-ID:  <[email-masked]>

  | I think that isn't the real issue.  The problem with textual
  | representation of IPv6 addresses with embedded scope-ids is that
  | they are not portable between nodes.  This is a real issue; one
  | that will many sysadmin shell scripts to fail.  Or even internally
  | on the same node.  If you physically unplug interface <A> on a node
  | then very likely the scope-id of interface <B> will have changed
  | when the machine is booted.

If the ids are simply being forced by the kernel, then yes, they would.
But in that case, so would 1/FE...  (or ...@1) type addresses.

As a user interface, having the kernel simply assign sequential numbers
is nice and simple, and for some uses, might be the best.   But for
more general functional useability, I think those identifiers need to be
sysadmin assigned - probably via an arg to ifconfig (or whatever is
like it).   Then they can remain stable, whatever the user interface
looks like.

kre

---

From: Robert Elz <[email-masked]>
Date: Mon, 22 Nov 1999 13:10:46 +1100

Date:        Sun, 21 Nov 1999 14:32:56 -0500
    From:        Jim Bound <[email-masked]>
    Message-ID:  <[email-masked]>

  | This is where Robert Elz's propsal shines.  We embed the scope in the
  | address and pull it out when we use the address in any manner this way
  | the DNS works, the user don't have to key in scopes, etc... 

Ah ... no .. I certainly don't think it is possible to stick embedded
scopes into addresses in the DNS - that would force them to be consistent
everywhere (everyone would have to be using the same values, and I doubt
that is possible).   Except when they are the only addresses, in a private
DNS, I don't believe anything but global addresses should be in the DNS at
all.

kre

---

From: [email-masked]
Date: Mon, 22 Nov 1999 14:00:41 +0900

>Do you have inet_ntop() hide the fourth byte?

	No, we do the following processing in the userland manually:
	- grab address from, say, routing socket
	  it has sockaddr_in6, with:
		sin6_addr: fe80:1::x:y:z:u
		sin6_scope_id: 0
	- if scoped address is returned, userland code modifies it before
	  printing
		sin6_addr: fe80::x:y:z:u
		sin6_scope_id: 1
	- then, give the sockaddr_in6 to getnameinfo() to get:
		"fe80::x:y:z:u@link"

	The above userland tweak is a temporary solution for us.
	I think the right thing to do is to fix kernel routing socket to
	return sockaddr_in6 with scope_id field properly filled in
	(i.e. never show embedded form to the userland).

>real-world exposure of it.

	Do you have getaddrinfo(3) that does "link1:fe80::x:y:z:u"?
	In that case, the above story will be the same.

itojun

---

From: [email-masked]
Date: Mon, 22 Nov 1999 14:50:23 +0900

>ping.  But for sysadmin commands like ifconfig that is an entirely

	ping4/ping6 is not the point of this topic so I'm going to ignore
	the word above.  Hope you are okay with it.

>to specify the source address.

	Aha, this is the point...

	I strongly disagree with you Jim.  What should happen if you do
	"telnet fe80::x" when you have fe80::x on both side of your
	multi-interface host, like the diagram I included in the previous
	email?  Just pick them at random?  That is not user friendly and
	unpredictable.
	Also, it becomes very trivial to do trojan horse on your telnet
	attempt.  I can just place an PC with fe80::x on it, onto your 3rd
	interface (and your multi-interface host will pick my PC in 33% of
	possibility).  User needs to disambiguate the destination, by
	specifying 16bits of in6_addr and scope_id.  Otherwise bad guy will
	be coming to do trojan-horse on you.

	Also, there's NO draft that says "if you have multiple candidate
	zones you MUST transmit NS to all the candidate zones".  This needs
	to be clarified before we go on.

itojun

---

From: [email-masked]
Date: Mon, 22 Nov 1999 15:43:39 +0900

>	be coming to do trojan-horse on you.

	typo.  "128bytes of in6_addr, and scope_id" (or 16bytes).

itojun

---

From: Peter Tattam <[email-masked]>
Date: Mon, 22 Nov 1999 20:54:52 +1100 (EST)

> the address is a good one.  

I thought it was a logical solution to the issue - assumed it was discarded
originally for some reason, hence the search for an alternative since the
standard was laid in concrete.

> harder on the renumbering problems.

Jim, the fact that this earlier alternative was (erroneously?) discarded is
an argument in favour for *NOT* rushing standards, which I believe you have
been pushing for.

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 22 Nov 1999 09:29:52 -0600

I'm convinced.  Not about the particular example of "@" as the
separator, but about the general approach.

Itojun wrote:
> [...]
> 	with us.  It is very long, but please read it patiently  ...

				Matt

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 22 Nov 1999 18:27:37 -0800 (PST)

> 	of the address, never in textual representation.

This assumes that applications always use inet_ntop or equivalent
when they pass the address to a peer over the wire.
I think such an assumption is dangerous - I've seen too much IPv4
code which just prints the octets and is not using inet_ntoa.
If this will be the case for IPv6 applications the effect would be that they
will fail in off ways when using less than global scope addresses.
It will be a pain to debug such problems due to the "hiding" of the scope id.

   Erik

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 22 Nov 1999 21:47:21 -0500

On the other hand, I think the ipv6 textual format is sufficiently
more complicated that programmers will be significantly less likely to
roll their own.

Also, with the KAME representation, the scope-id isn't "hidden" if you
cheat this way; it's actually fairly visible, in the second 16-bit
word of the address..

---

From: Jim Bound <[email-masked]>
Date: Fri, 26 Nov 1999 09:00:52 -0500

>DNS, I don't believe anything but global addresses should be in the DNS at

Then you disagree with Erik's proposal for site prefixes?

I think Sam made a good argument about why not to embed them in the DNS
(le0 crashes and comes back up in different site).

I would like to see us all agree that ONLY global addresses are in the
DNS for sure.  That would be progress.

thanks
/jim

---

From: Jim Bound <[email-masked]>
Date: Fri, 26 Nov 1999 09:23:14 -0500

Hi Itojun,

>	the word above.  Hope you are okay with it.

I am OK with that I was trying to see if that was a tell tale sign of
your implementation choice but I guess not.

>>to specify the source address.

But let me verify something.  

I believe you are NOT saying the user must know the scope_id for the dst
address to use an app?

I believe you are saying the user must convey the source scope_id for
the src of communications?

Which is correct above?  

>	email?  Just pick them at random?  That is not user friendly and

Well for link-local I think this is bogus and link-local addresses
should only be used for ND, DHCPv6, ifconfig, and control protocols they
should not be permitted to be used for higher layer apps.  But I also
think a link-local address should never be used as a source address when
the destination address is global either.  link-local addresses is an
address that most users should not even know about.

But I don't agree it is not user friendly and if we must figure this out
it must be done without the user having to know about scope-ids.  

>	be coming to do trojan-horse on you.

If we do not put scope-ids in the DNS how does one know the scope-id as
a user for destinations in the first place.

The way to fix this for link-local is to extend ND to state that if a
end node has more than one physical link the end node must make sure
that NO link-local address have been duplicated across multiple links.

                               nodeX
                         /                  \
            link FUZZY to nodeY           link CLEAR to nodeZ
 
                     |                          |
                   nodeY                       nodeZ
                  fe80::1                      fe80::2

So during the DAD phase of Addrconf nodeX would inform either nodeY or
nodeZ if they have both configured the address fe80::1.  Details could
be discussed if we want to visit this path.  But this problem should be
fixed in ND + Addrconf not by hacking it to work with APIs and DNS or
other mechanisms.

>	to be clarified before we go on.

I am saying above that may in fact be required.

/jim

---

From: Jim Bound <[email-masked]>
Date: Fri, 26 Nov 1999 09:50:11 -0500

>an argument in favour for *NOT* rushing standards, which I believe you have

I agree we cannot rush them.  But if something more than the API is
radically broken with scopes more than the API we better fix it quick.

I think we now have unearthed a basic flaw in the IPv6 architecture, but
we will see.  I hope I am wrong.

/jim

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 27 Nov 1999 07:06:33 +0900

>I believe you are NOT saying the user must know the scope_id for the dst

	First of all, don't think about DNS mapping here.  Only think about
	numeric addresses.

	I am saying this.  More correctly:
		If you transmit a packet to scoped destination,
		you need to disambiguate between existing scope zones
		(links or sites) and denote a single scope zone
		by the time you reach IPv6 layer.

	There are several chances to disambiguate it.
	- User may specify it explicitly, by "ping6 -S link0 fe80::1"
	- If your node have only one interface, you have no other choice
	  so you can make it a default interface.  NOTE: you have loopback
	  interface always, so actually you have to pick one of two interfaces
	  if you have single ethernet outlet (loopback and ethernet).
	- If user did not specify, the node may be able to obey admin's
	  decision somewhere on the node.  This can be implemented by routing
	  table (like "route add -inet6 fe80::/10 -interface foo"), or
	  some configuration setup into the kernel.

>the src of communications?

	If you send a packet to scoped destination address, scope zone must
	be made un-ambiguous before you reach IPv6 layer.

>address that most users should not even know about.

	There are people trying to use link-local (zeroconf, dentist office)
	for real communication and we can't just ignore them.
	Also you have to support site-locals and multicast scopes.

>it must be done without the user having to know about scope-ids.  

	If you wish, you can let the node admin connfigure default scope
	zone.

>a user for destinations in the first place.

	DNS issues can be solved in multiple ways, and I believe it is
	VERY separate topic.  I want you to think separately.
	I put a possible solution here, but THIS IS OUTSIDE OF THE KEY
	DISCUSSION.

	No, I never said that we are going to put scope-id into DNS.
	Global DNS tree MUST contain global addresses only.  Local DNS tree
	must contain 128bit portion only, and it has no scope-id in it.
	There's no question here.

	If you have site-local connectivity, you are in situation where
	you are in firewalled world.  You have connectivity to inside-firewall
	nodes, who uses fec0::/10 (like 10.0.0.0/8), and global cloud.
	You can have separate DNS tree for each of them, like:
		tree under internal.dec.com.
			which is reachable only in the firewall cloud
			(site-local DNS tree)
		tree under . (root)		
			which is reachable worldwide (global DNS tree)
	You may need to configure extended /etc/resolv.conf to:
		contact DNS server for internal.dec.com first
			if you get the answer, scope id for sitelocal = 3
		next, contact global DNS server
			if you get the answer, scope id for sitelocal = 0
			(invalid)

	Then you kick getaddrinfo(3).  What happens here will be:
	- you say getaddrinfo("jimbound").
	- this is ambiguous and get disambiguated by DNS search order in
	  /etc/resolv.conf, and if you configure "internal.dec.com" and
	  "dec.com" you will have 3 FQDN candidates.
		jimbound.internal.dec.com.
		jimbound.dec.com.
		jimbound.
	- You will try to resolve them looking at extended /etc/resolv.conf.
	  (1) you try to resolve jimbound.internal.dec.com with site-local
	      name server.  if there's an entry like below:
		jimbound.internal.dec.com.	IN AAAA	fec0::x
	      you will get the following answer into struct addrinfo.
	      scopeid is filled in by LOCAL RESOLVER:
		fec0::x, scopeid = 3
	  (2) next, you will contact global DNS server for
	      jimbound.internal.dec.com. (I think you will need to contact
	      regardless of failure or success of (1)).  It will fail.
	  (3) you will try to resolve jimbound.dec.com. with site-local DNS
	      server.  no entry on the database.
	  (4) you will try to resolve jimbound.dec.com.  you get
		jimbound.dec.com.	IN AAAA	3ffe:9999::x
	      and you will get following struct addrinfo.
		3ffe:9999::x, scopeid = 0 (because it is global)
	As a result, you will have two entries for your query:
		fec0::x, scopeid = 3
		3ffe:9999::x, scopeid = 0 (because it is global)

	This story never puts scopeid into DNS database, and works with
	multiple scope zones.

>that NO link-local address have been duplicated across multiple links.

	I strongly disagree.  Admins are using interface id "1" or "2"
	all the time and it is impossible.  If you take link-local scoped
	multicast address, you will have the same solicited node multicast
	address if you have two nodes on different side with same interface ID.

	The strategy never work if you think about site-locals (you have no 
	help from ND)

>I am saying above that may in fact be required.

	No NEVER, this way you can never make scoped addresses work.

	Scoped address will not going to vanish.  Even if you may be able to
	nuke site-local scope at next IETF:-), you can never nuke link-local
	scope and multicast scopes.  Link-locals are essential to ND
	(apparently), and there are scenarios (dentist office) and people
	(like zeroconf) who are trying to use link-locals in real
	communication.  Therefore, we need to make scoped address work.

	Your policy (try to send packet to multiple zones) works only in the
	following situations and you make the problem narrower by dropping
	support for other cases:
	- for link-local, you are assuming that you do not see same fe80::x
	  on both sides.  Once you have same fe80::x on both sides by
	  coincidence, you are doomed.
	- for site-local, you are assuming either (1) node is not placed 
	  at the site border (no node will be connected to two or more sites),
	  or (2) there's no same address used in sites you are connected.
	  Once you have two more or nodes, in different site, which uses
	  the same fec0::x, you are doomed.  This case is worse since if you
	  send two TCP SYN, you are (a) bothering routers in both sites,
	  (b) you may legally get two TCP SYN and bothering one of correct
	  fec0::x.
	In any case, if you do not disambiguate scope zone you would like
	to send, as I wrote trojan horse attack is very easily possible.

	We (KAME team apparently, but others as well) have been thinking how
	scoped address should be handled, and we came to the fact we always
	need to disambiguate scope zones before we reach IPv6 layer like
	ip6_output().

itojun

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 27 Nov 1999 08:37:00 +0900

>		3ffe:9999::x, scopeid = 0 (because it is global)

	Correction.  normal resolver will not do (2) - (4).  It terminates
	at (1)

	As a result of the above, you will have one entry for your query:
		fec0::x, scopeid = 3

	Similarly, if you have configured DNS search order to:
		internal.compaq.com.
		internal.dec.com.
		dec.com.
		. (root)
	The resolver will query the following, in order:
		jimbound.internal.compaq.com.
			-> fec0::y, scopeid 2
		jimbound.internal.dec.com.
			-> fec0::x, scopeid 3
		jimbound.dec.com.
			-> 3ffe:9999::x, scopeid 0
		jimbound.
			-> normally it does not exist
	The first one matched will be used.  You will be configuring which
	scope zone (i.e. "internal.compaq" sitelocal cloud or "internal.dec"
	sitelocal cloud) to prefer, by DNS search order.

itojun

---

From: Robert Elz <[email-masked]>
Date: Mon, 29 Nov 1999 00:58:39 +1100

Date:        Fri, 26 Nov 1999 09:00:52 -0500
    From:        Jim Bound <[email-masked]>
    Message-ID:  <[email-masked]>

  | Then you disagree with Erik's proposal for site prefixes?

Yes.   I haven't commented in detail because I haven't found the time
to read it carefully enough to do that.

kre

---

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

In your previous mail you wrote:

   
=> I believe that now near everybody agree?

   That is fairly unreasonable -

=> 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 :-).

    though I an not sure it is worse than ...

=> don't forget the user should always use *names* then when [s]he uses
numerical addresses you can hammer h{i,e}s fingers. I think the weight
of the hammer doesn't matter but I'd like to get a standard syntax.

   As a user interface, that sucks.

=> yes, using something which is not a name sucks...
I have two (new?) arguments against the embedded scope idea:
 - a name is better than a local/volatile number (if the scope ID is
   an interface index, the index is by definition local to the node
   and on a laptop it can change and is essentially unpredictable
   (a name adds an indirection level which can solve these problems)
 - multicast addresses use scopes and I prefer to pick some bits
   for other purposes than to solve this issue (this argument applies
   to binary format too).

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Sun, 28 Nov 1999 18:50:00 +0100

=> I buy this!
 The DNS is by definition global and can't take care of locations, each
time I've seen something which doesn't follow these principles it has
failed (when I see a dual-head monster I'd like to cut a neck :-).
 But this remark doesn't apply to other name services (ie. tools
which translate names to addresses)

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Sun, 28 Nov 1999 19:08:15 +0100

>	email?  Just pick them at random?  That is not user friendly and
   
=> I'd like to add some multicast applications in examples because
multicast addresses are as ambiguous as possible in this context...

   Well for link-local I think this is bogus and link-local addresses
   should only be used for ND, DHCPv6, ifconfig, and control protocols they
   should not be permitted to be used for higher layer apps.

=> this is not acceptable for me. You are trying to change a "should not"
in a "must not".

   But I also think a link-local address should never be used as a
   source address when the destination address is global either.
   link-local addresses is an address that most users should not
   even know about.

=> I agree but this is not the point.

=> it is not user friendly to disallow something without necessity.

=> I don't know if this is possible to implement and I don't want this.
Ambiguity is a property of the local scope idea, I think it is better
to learn to live with it than to twist the model...

Regards

[email-masked]

PS: your real problem is that getipnodebyxxx() should be updated, isn't it?
About inet_ntop/pton() I believe a new set of functions can be defined
because programmers should deal with *names* (in fact getipnodebyname()
accepts numeric address string then this detail should get a low priority).
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Sun, 28 Nov 1999 19:38:25 +0100

=> because if you have a name the scope ID if needed will be automagically
given by the name to address translation (by construction of this service).

   
=> I think all current implementations use this kind of rule set, don't they?

   >it must be done without the user having to know about scope-ids.  
   
   	If you wish, you can let the node admin configure default scope
   	zone.
   
=> not this can be the only solution because it is usually restricted
to the node admin (ie. to modify the default zone each time you'd like
to use a scoped & numerical address is not an acceptable solution
even this works in many cases (but not all cases)).

   	Scoped address will not going to vanish.  Even if you may be able to
   	nuke site-local scope at next IETF:-)

=> it will be enough to nuke multi-sited situations...

        you can never nuke link-local scope and multicast scopes.
        Link-locals are essential to ND	(apparently),

=> in fact link-locals are essential to autoconfiguration.
For instance link-locals make DHCPv6 far simpler than DHCP
(I've found the real problem of DHCPv6, this is simply its name:
if DHCPv6 was named ISFAA then it had been there since years :-).

        and there are scenarios (dentist office)

=> the simplest scenario: no router at all.

        and people (like zeroconf) who are trying to use link-locals in real
   	communication.  Therefore, we need to make scoped address work.
   
=> I agree!!!

=> I was very happy to get with RFC 2553 a good and general solution for
scope zones (far better than in6_pktinfo) and I'd like to use it with
getipnodebyxxx(). I've changed my stack in order to carry a scope ID
where it is needed and the behavior on a multi-interface node is more
than better, I'd like to go further not backward...
(this is for Jim, as I've said I agree with you at nearly 100%)

Regards

[email-masked]

---

From: Jim Bound <[email-masked]>
Date: Mon, 29 Nov 1999 12:22:28 -0500

>	First of all, don't think about DNS mapping here.  Only think about

You could make this discussion much better by answering my questions
above instead of shouting at me and being controlling.  If you continue to
not answer my questions I will not respond to your mail anymore I don't
like one-way conversations.  

I said nothing about DNS in my above questions.

>	  some configuration setup into the kernel.

This is possible for this type of "systems application" yes.

But I am more interested in this case:

user app like Netscape, Oracle, MSA-Accounting Network Software, etc.
does:

  getaddrinfo (host.foo.com) I will use your preferred API OK.

When it comes back the node has an address which it got from a DNS
lookup of the name for the dst of the node.

How does the node know what the dst scope-id is for host.foo.com?

>	be made un-ambiguous before you reach IPv6 layer.

And I am asking how is that done?  What spec what details?

>	Also you have to support site-locals and multicast scopes.

I agree about the dentist office.  I just don't agree that site-locals
are needed or should ever be used.  

>	If you wish, you can let the node admin connfigure default scope

True.

But how is it automated?

If we just say admins go figure this out they will puke all over IPv6
and sitelocal addresses.

>	VERY separate topic.  I want you to think separately.

Don't EVER TELL ME WHAT TO THINK AGAIN.  

I would like to discuss how this is going to work architecturally before
we go fixing the API mechanisms under getaddrinfo. To use your favorite
API again.

>	No, I never said that we are going to put scope-id into DNS.

I never said you did if I did please send me the mail where I said you
said this?  The mail is fast now and I don't think I said you said this.

>	There's no question here.

Then the only draft we have for site-local addresses will not work if we
all agree to this (and I agree), hence; we have no underlying solution
to scope-ids and we are talking about changing API semantics and syntax
for something that is not well defined for "practice" in a network site.

>	You can have separate DNS tree for each of them, like:

I don't agree with your premise.  If your using sitelocal addresses only
then a firewall may infact not be needed like a Big Dentist Office.
I agree we can have separate DNS trees and some rules but that is not
written down anywhere or described for implementors.

>			if you get the answer, scope id for sitelocal = 3

Whoa here.  Who gave back the sitelocal equalivalent to 3?  
How did it know this?

			(invalid)

>		jimbound.internal.dec.com.

OK this is normal resolver stuff.

>	      scopeid is filled in by LOCAL RESOLVER:

WHere again did the scope-id = 3 come from?
In resolv.conf file?

Then its hardcoded and this breaks renumbering and one of the reasons
for site-local addresses.

>		3ffe:9999::x, scopeid = 0 (because it is global)

But the scope-id was filled in after the Response Query from DNS so your
saying scope-ids are hardwired into files on the node which are then
copied to addrinfo struct?

This breaks renumbering objective and PIER WG would object to this
solution.  And so do I.

>	This story never puts scopeid into DNS database, and works with

Yep and as I said breaks the principles of renumbering which are I think
important or we would not be facing what we face with A6 records.

>	address if you have two nodes on different side with same interface ID.

Well we can agree to disagree no problem.  

>	The strategy never work if you think about site-locals (you have no 

I don't agree.  

>	No NEVER, this way you can never make scoped addresses work.

Have you not learned in your IPv6 work to NEVER say NEVER.

>	communication.  Therefore, we need to make scoped address work.

Well I intend to try to nuke site-local addresses and keep link-locals.
See my mail response to Christian Huitema I am working on now and will
send later.

>	  coincidence, you are doomed.

Wrong.  I will see duplicate NS's in my ND daemon and this can be part
of the NUD software too.  

>	  (b) you may legally get two TCP SYN and bothering one of correct

site-local should be nuked.  this is the problem.

>	to send, as I wrote trojan horse attack is very easily possible.

I agree.

>	need to disambiguate scope zones before we reach IPv6 layer like

We have done the same on Compaq Tru64 UNIX IP stack.  But the
architecture for using scopes in apps with sitelocal is still not
defined and a big hole for us to all interoperate.

/jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 29 Nov 1999 12:31:13 -0500

>=> this is not acceptable for me. You are trying to change a "should not"

Guilty as charged.  Exactly my intentions.

>=> I agree but this is not the point.

It is relative because we cannot continue to just say everything goes if
it can be done and we will make it work later.  This is the wrong
thinking model for IPv6.  It was OK when we lived in architecture and
thinking about it land but we are not in shipping product land and the
rules are way to loose in some places with IPv6.  Thats my input to the
WG after implenting this stuff.  

>=> it is not user friendly to disallow something without necessity.

If it hurts then it either must fixed or removed.

>to learn to live with it than to twist the model...

I strongly disagree.  It is possible to implement or I would not have
brought it up.

>accepts numeric address string then this detail should get a low priority).

I resent your implication.  I would never as a man on the planet play
these kind of games because I don't want to change and API or anything I
work on in the IETF or on my job.  I am convinced we must accept the
pain and shoot getipnodebyname in the head and deprecate it and move to
getaddrinfo.  I thought you knew me better as a person and my own
integrity.  I am quite bummed out you would think this about me
Francis!!

But that does not mean I support putting scope-ids in any API when they
are as ill-defined and unknown as they are today.  We also IMO have to
revisit the entire reason for site-locals one of which was "renumbering"
and you said you agreed with Itojun and his mail will break that as the
scope-id was hardwired.

More when I respond to Christian's mail.

/jim

---

From: [email-masked]
Date: Tue, 30 Nov 1999 03:23:51 +0900

beware: This email is very long.  The summary is:
	- I'm not promoting site-locals.
	- I'm promoting more correct use of scope id.
	- Summary of my thinking on scope id is this.
	  - when user specifies FQDN, it should come with no explicit scope id.
	    FQDN must be resolved into <128bit IPv6 address, scope id> pair.
	  - when user specifies numeric IPv6 address, (1) user must specify
	    scope id explicitly, or (2) system default setting (like routing
	    table) must pick single scope id.
	- There are ways to resolve FQDN into <IPv6 addr, scope id> pair.
	  - draft-ietf-ipngwg-site-prefixes-03.txt.
	    consider the following situation:
	    - you've got site local prefix advertisement A from interface X, 
	      interface X belongs to site ALPHA.
	    - you've got site local prefix advertisement B from interface Y, 
	      interface Y belongs to site BETA.
	    If the given FQDN resolves to an IPv6 address that matches
	    A, it should be in site ALPHA.  Now you have
	    <128-bit IPv6 address, scope> pair.
	  - see the latter half of my previous email.
	- Even if you remove site local from the spec the above use of scope id
	  will not change.
	- sending NDs to multiple interfaces is a bad idea.

	Jim, sorry if you are irritated by my bad English.  I really tried to
	answer your questions.  Let me recap.  There are some reordering
	of sentences.

>>>the src of communications?

	The above question is not "pick one of these" kind of question so
	it did not make sense to me to pick one.  so I answered with
	descriptions.  I need to do it again.

	For both of questions, my answer is like below.
	- when user specifies FQDN, it should come with no explicit scope id.
	  FQDN must be resolved into <128bit IPv6 address, scope id> pair.
	- when user specifies numeric IPv6 address, (1) user must specify
	  scope id explicitly, or (2) system default setting (like routing
	  table) must pick single scope id.

>>	I am saying this.  More correctly:
	tries to answer the first question (the line was right below the first
	question).  I am saying that "the user must know the scope_id for
	the dst address to use an app" if she specifies numeric IPv6 address.

>>	be made un-ambiguous before you reach IPv6 layer.
	tries to clarify the second question.  First of all, "source scope_id"
	in your question is incorrect.  User need not specify "source".
	All she specifies is destination.

>like one-way conversations.  

	I really tried to answer your questions.  I did not try to shout.

>This is possible for this type of "systems application" yes.

	The rule I wrote is for all the applications.  There's no difference
	between systems application (like ifconfig, ping6) and normal
	application (telnet, netscape).  How can a user know which command
	falls into which category?

>How does the node know what the dst scope-id is for host.foo.com?

	FQDN must be resolved into <128-bit IPv6 address, scope> pair,
	by using:
	- draft-ietf-ipngwg-site-prefixes-03.txt.
	  consider the following situation:
	  - you've got site local prefix advertisement A from interface X, 
	    interface X belongs to site ALPHA.
	  - you've got site local prefix advertisement B from interface Y, 
	    interface Y belongs to site BETA.
	  If the given FQDN resolves to an IPv6 address that matches
	  A, it should be in site ALPHA.  Now you have
	  <128-bit IPv6 address, scope> pair.
	- see the latter half of my previous email.

>are needed or should ever be used.  

	There are specs that use site-locals.  To name a few:
	- router renumbering
	- DHCPv6
	How do you plan to change those?

	I'm just okay if you nuke site-local addresses (as long as you update
	those specs).   However, even if you nuke site-locals, you need to
	disambiguagte numeric IPv6 address by specifying scope id.

>If we just say admins go figure this out they will puke all over IPv6

	Even for link-locals you need the above admin configuration, or user
	specification of scope id.

	It looks you are assuming that I'm promoting site-locals.
	I'm not fan of site-locals.  I'm not promoting site-locals.
	I'm just promoting correct use of scope id, which applies
	for ALL scoped addresses we have, like:
	- link-local unicast
	- site-local unicast
	- multicast with 14 non-global scope
	I'll be okay, or happy, if you nuke site-locals.  Even if you nuke
	site-locals, you can't forget about scope id.

>we go fixing the API mechanisms under getaddrinfo. To use your favorite

	I just tried to clarify that scope id issue and DNS issue are
	very separate.  It seem that you are mixing up them so I just
	wanted you to separate these.
	Maybe my wording was wrong, I apologize if it was.

	Here's the line made me write the above:
>>>Message-Id: <[email-masked]>
>>>To: [email-masked]
	You look like assuming that I'm going to put scope-id into DNS
	database.  I may be wrong.

>for something that is not well defined for "practice" in a network site.

	Do you agree with draft-ietf-ipngwg-site-prefixes-03.txt, or my lines
	above?  Anyway, draft-ietf-ipngwg-site-prefixes-03.txt places global
	IPv6 addresses only onto DNS database so I'm saying the same thing
	with draft-ietf-ipngwg-site-prefixes-03.txt.

	We have underlying solution for resolving FQDN into <128bit IPv6
	address, scope-id> pair.  again:
	- draft-ietf-ipngwg-site-prefixes-03.txt.
	  consider the following situation:
	  - you've got site local prefix advertisement A from interface X, 
	    interface X belongs to site ALPHA.
	  - you've got site local prefix advertisement B from interface Y, 
	    interface Y belongs to site BETA.
	  If the given FQDN resolves to an IPv6 address that matches
	  A, it should be in site ALPHA.  Now you have
	  <128-bit IPv6 address, scope> pair.
	- see the latter half of my previous email.

	If you say there's no draft, I'll write up one if you agree that
	use of scope id, and user's explicit specification of scope id
	are very important.

>written down anywhere or described for implementors.

	Correct me if I'm wrong, I believe DNS management in firewalled
	environment is never really documented.  The only document I know of
	is draft-ietf-dnsind-local-names-07.txt.

	Again I'm not promoting site-locals.  I just can't stop people from
	using them as they are on the documents for a very long period of
	time, and there are specs that depend on site-locals.

	Combined use of site-local and global address is very similar to
	firewalled site, with sort of packet filters at the edge.

>Whoa here.  Who gave back the sitelocal equalivalent to 3?  

	You can pick any number as you want, as scope id is local to
	a node.  You just need to give different number to different site
	you belong.

>for site-local addresses.

	Again it is local to your node.  This does not make any harm
	to renumbering.  Renumbering will occur in one of a site you belong,
	not across multiple sites you belong (why "stanford" and "cisco"
	needs to be renumbered at the same time?).  Even if "stanford"
	experiences renumber, you do not need to change your idea of
	scope id for "stanford".

>This breaks renumbering objective and PIER WG would object to this

	Yes to the first 3 lines, scope id will be filled in after the
	resolver got the reply from DNS server.  scope id is hardwired into
	files on the node.

	However, this does not break renumbering.

>important or we would not be facing what we face with A6 records.

	No, renumber should work just fine.

>>	The strategy never work if you think about site-locals (you have no 

	Do you use multihomed nodes every day?  Why can you live with
	"send ND to all interface" node?  I can't.

>See my mail response to Christian Huitema I am working on now and will

	Again, I'm not promoting site-locals.  I'm just fine if you are happy
	with more explicit use of scope id.

>Wrong.  I will see duplicate NS's in my ND daemon and this can be part

	NUD?  isn't it DAD?

	Anyway, I believe you are wrong.  Consider the following diagram.

	fe80::x
	  | network A
	my node
	  | network B
	fe80::x

	On network A, fe80::x will perform DAD to detect other fe80::x on
	network A.  There's no such guy and DAD will success.
	On network B, fe80::x will perform DAD to detect other fe80::x on
	network B.  There's no such guy and DAD will success.
	Therefore, there will be two fe80::x visible from my node.

	You are saying that, any multi-interface node must take care of
	the network on the other side during DAD process
	(i.e. if fe80::x on network A transmit DAD packet, my node needs to
	forward that to network B to make sure that there's no fe80::x on
	network B).  This is not on the spec.

itojun

---

From: Jim Bound <[email-masked]>
Date: Mon, 29 Nov 1999 23:42:26 -0500

>	beware: This email is very long.  The summary is:

thats OK with me.  This is very important.  We should not limit email
size to address issues in IPv6.

>	- I'm not promoting site-locals.

OK.

>	- I'm promoting more correct use of scope id.

OK.  I will comment more on this at the very end OK as I think it will
help clarify my issue here.

>	    table) must pick single scope id.

Agree with you.

>	  - see the latter half of my previous email.

On the surface this will work but one must also accept all the
assumptions in draft-ietf-ipngwg-site-prefixes-03.txt and I do not
believe those assumptions have consensus.

>	- Even if you remove site local from the spec the above use of scope id

This is true in the abstract but the entire draft is about site-local
addresses.  To me that is like saying believe that horses could fly
because of the story I tell, but if the story did not exist the horses
can fly.  So I see your point but cannot take the leap of faith to apply
it to scope-ids for me.  But I do see your point.

>	- sending NDs to multiple interfaces is a bad idea.

I won't go here it will just mess up this discussion I want to keep
where your going.  But I do think my idea will work but that is another
discussion.  If its a bad idea thats not a problem I will present it
anyway to see if all think its a bad idea.

>	Jim, sorry if you are irritated by my bad English.  I really tried to

Itojun.  English is not an issue at this end.  My issue is the notion of
working on scope-ids which I think are only useful for site-local
addresses, because I don't believe link-local addresses should be used
by ftp, ping, telnet and friends.  But I am listening.  As your the only
one disagreeing with me using real examples and abstract code discussion
which I appreciate.

>	answer your questions.  Let me recap.  There are some reordering

OK.

>	descriptions.  I need to do it again.

OK it could be me but I thought they were yes or no answers.  

>	  FQDN must be resolved into <128bit IPv6 address, scope id> pair.

OK.

>	  table) must pick single scope id.

OK.

>	the dst address to use an app" if she specifies numeric IPv6 address.

OK that was not clear for me and I just missed that.  I would agree for
the src address but I am not clear the user can specify that for the dst
address unless it is the default rt_entry or whatever.

>	All she specifies is destination.

If one uses matching scope yes.  But lets use those awful site-local
addresses.

dst address == fec0::2::3

if the node is multi-sited then it is imperative a scope be chosen.  the
address could live in both sites.

>	I really tried to answer your questions.  I did not try to shout.

OK I believe you it sounded like shouting but that could be me.

>	falls into which category?

OK let me try this.  Oracle app does getaddrinfo(host.x.com) [shortened
version OK]....  Well right now consensus is that the DNS only stores
global addresses so if it finds one....

This is where I get lost.  If DNS only stores global addresses why would
the app ever get back a site-local address?  It can't?

Unless we fabricate one from a change to
draft-ietf-ipngwg-site-prefixes-03.txt which would be necessary.

Based on the site-prefix length and some knowledge that host.x.com is in
one of the sites for the node.  Transparent to the app.

>	- see the latter half of my previous email.

Agree and this would work with alteration to the site-prefix draft.

But I would claim after one has done all this just use the global
address.

Why bother with the site-local address and that discussion needs to be
revisited IMO.

>	There are specs that use site-locals.  To name a few:

I would have to go check router renumbering but for DHCPv6 its a
site-local-multicast address which I don't have issues with an are not
an issue as they are common to all sites as we specify.  All nodes
wanting to hear that multicast must join that multicast address so the
sending node does not have to worry about scope-id relating to
interface.

>	How do you plan to change those?

I don't have to change DHCPv6 and will let Matt respond to router
renumbering as opposed to me going and checking.

>	disambiguagte numeric IPv6 address by specifying scope id.

site-local-unicast and site-local-multicast are two different types of
addresses.  multicast does not have the same problem set at all.  

>	specification of scope id.

Right now yes but I may propose a fix for that as we have implemented it
just fine.

>	- multicast with 14 non-global scope
 I don't think multicast has the same problem set.

>	site-locals, you can't forget about scope id.

I would agree we need scope-id for link-local.

For multicast I believe we need to specify the interface for multicast
and also receive the interface it went out on.  But that does no harm as
if no one joined the group no one knows any better.

>	wanted you to separate these.

I was not mixing them up.  I wanted to see what you just did and that is
to make this work without affecting DNS.  But if there is no global
address for the node in the DNS and an app looks for host.x.com then no
address available comes back and even with
 draft-ietf-ipngwg-site-prefixes-03.txt picking a site address with no
global address is very questionable in my mind.  Just use the global
address.

>	Maybe my wording was wrong, I apologize if it was.

No.  the sequence was hard for me to follow reading mail quickly.

>	database.  I may be wrong.

I did not say you were going to do this above you assumed it.  This is
where folks must be very careful with assumptions from email.  I was
asking a question of an if-then construct.  But I did not say you said
put scope-ids in DNS.  This may be an english translation problem on my
part.

>	with draft-ietf-ipngwg-site-prefixes-03.txt.

From draft-ietf-ipngwg-site-prefixes-03.txt 

8.1.  Host Name Lookups

   The node will inspect the AAAA/A6 RRset returned from DNS to check if
  one or more of the global addresses belong to the same site as
   itself.  This is done by comparing all the global addresses against
   all the prefixes in the Site Prefix List.  If there are no matches
   then the site-local addresses in the RRset must not be used.  If
   there are one or more matches then the node should prefer using the
   site-local address(es) over the global addresses.  This can be done
   by sorting the addresses before they are returned to the application
  and excluding the addresses that are subsumed by the site-local
   addresses.

So draft-ietf-ipngwg-site-prefixes-03.txt does say have site-local
addresses in the DNS and there are other examples in the draft.

My issue is if there are no site-local addresses in DNS as you and I
agree with and others.  Then the draft can be made to work if the DNS
returns a global address from the site-prefix length addition to ND
spec.  

But if the node has a global address I say use it.  Thats where I seem
to disagree with a few of you.  

>	- see the latter half of my previous email.

It takes a global address match to find this though... We are going in
circles here.

>	use of scope id, and user's explicit specification of scope id

if we agree on the problem in the working group then we should extend 
draft-ietf-ipngwg-site-prefixes-03.txt and not reinvent the wheel and
make that work is my best guess approach.

>	is draft-ietf-dnsind-local-names-07.txt.

I don't believe that really documents what we are talking about here and
I don't think anyone can.  Thats the whole point of a firewall.  I am
saying above that firewall is a non-issue for the discussion and
resolution of scope-ids.

>	time, and there are specs that depend on site-locals.

Uh... Well based on all this mail.  I don't think any user are using
these in any fashion.  And they are not even Draft Standards so we can
change them at the last minute in the IETF.

>	firewalled site, with sort of packet filters at the edge.

Thats a stretch...but it would work but I would not advise users to do
thsi anymore I would using Net 10 and NAT in IPv4.

>	a node.  You just need to give different number to different site

But how did you know 3 was right?

>	experiences renumber, you do not need to change your idea of

Ohhhhh... cisco and stanford are not different sites but different
domains in the truest DNS sense.  So I don't agree with another of your
premises.  The way I view site is as follows:

General Motors 
  Truck and Bus Building is Site A
  Plant Floor Assembly Building is Site B
  Chasis Division Building is Site C

A Web Server is serving all sites at General Motors to all buildings and
has 3 FDDI ports to each building so each is a different link.

I would claim we all don't agree on the scope of a site and its
boundaries.  One reason I have an issue with them being used.

>	However, this does not break renumbering.

Of course it does.  Esp if only global addresses are stored in the DNS.
These are needed to parse the prefix length to determine the scope-id
for a site.  Hence, the scope-id is relative to the prefix of a global
prefix and if it changes so must the relation to the scope-id (using the
database concept of relation).

Somewhere the file has to relate 3ffe::23::12/48 to Site A (as an
example) which relates to scope-id 3 lets say.  

If your using fec0::23::12/48 to speak with a node in the same site and
the prefix is renumbered to say that 4ffe::45::65/48 now is the prefix
for Site A the connection will break.

>	No, renumber should work just fine.

No it does not.

>	"send ND to all interface" node?  I can't.

I can that is what IPv6 is all about.  Also why multicast scopes don't
break anything.  I just pound it out to all interfaces if the user don't
specify and interface.  I will receive any packets (accepting the ACK
implosion if it happens of course which don't scale) that come back to
me.

Not a problem.

>	with more explicit use of scope id.

I will not buy into scope-id definition until we finish issues with
site-local addresses.  But once we do that I agree we need them for
link-local but that is a different issue.

>>Wrong.  I will see duplicate NS's in my ND daemon and this can be part

No NUD.  This is where ND cache lives (I agree its an implementation
issue) and that is where NS's can be determined.  We could put a check
that when the NS happens we check if there is a similar NS on our other
site interface as this should be one cache IMO.  

DAD could be used to check it too but I think the node should come up
and then realize it has duplicated a link-local with a sister site and
then fix it.  

But that would be part of the discussion and maybe there are other
alternatives.

>	network A.  There's no such guy and DAD will success.

Agreed as I said above UNLESS my-node checks its ND cache.

>	Therefore, there will be two fe80::x visible from my node.

When my-node sees that (it will be in the ND cache) it can tell one of
them hey change your EUI.

So I am not wrong.

>	network B).  This is not on the spec.

After DAD I am saying.  

So its a new spec just like draft-ietf-ipngwg-site-prefixes-03.txt.
If we want to do this I will write the spec.  

But I am not wrong.  

/jim

---

From: [email-masked]
Date: Tue, 30 Nov 1999 14:36:52 +0900

>address could live in both sites.

	I agree that you need to use a source address with matching scope.
	This is true for link-local unicast, and scoped multicasts (14 scopes)
	as well.

>one of the sites for the node.  Transparent to the app.

	Name resolution can be anything.  DNS, icmp namelookup, /etc/hosts,
	whatever.  In firewalled site admins may handcruft their own DNS tree
	to hold scoped address just for local use.

	What we really need to think is how to reach the desired 
	destination the user have specified.  To do this I'm saying that
	more explicit use of scope id is necessary to handle:
	- link-local unicast
	- site-local unicast
	- scoped multicasts

(snip)
>to disagree with a few of you.  

	My apologies.  I need to re-read site-prefixes-03.  But my thinking
	on use of scope id does not change (it is not tightly coupled).

>It takes a global address match to find this though... We are going in

	what cycle?  Could you give me a step-by-step example?

>change them at the last minute in the IETF.

	Another example of the use of site-locals.
	To run IBGP session in a site while allowing the site renumber,
	you would need to run IBGP tcp session over site-local address.

>But how did you know 3 was right?

	The node admin can just pick 3, or 200, or anything.  This is an
	identifier to disambiguate scope seen from a single node (in this case
	the subject scope is "site").
	This is just like you are calling your ethernet interface "de0",
	while I'm calling mine "cnw0".  This will never be exposed to outside.

>>for site-local addresses.

	Again admin can pick one at will and put that into some configuration
	file in the node.

	Even if hardcoded, this does not break renumbering in a site.

>domains in the truest DNS sense.

	In the above "stanford" and "cisco" are different site, and the
	node we're looking at is multi-sited.  Then how do you think.

>So I don't agree with another of your

	My proposal does not break even in the above example.  I can safely
	assign site id 1 to A, 2 to B and 3 to C.  Even when the general
	motors gets renumbered, the site boundary (seen from the 3-legged
	web server) does not change so there's no problem.

	Currently defined router renumbering protocol takes care of renumbering
	single site only.  There is no good way to redefine definition of
	"scope boundary" at runtime.  Are you going to propose the latter?

>for Site A the connection will break.

	You can relate network interface and site id, not the prefix and
	site id (assuming that a network interface belongs to at most 1
	site - draft-ietf-ipngwg-scoped-routing-02.txt).  This was my thinking.
	Apologies if I sounded differently.

>link-local but that is a different issue.

	Hmm.  I would like to know what others say.

>them hey change your EUI.

	How do you notify the victim if you think the victim's link-local
	is invalid?
	Why poor fe80::x on network A needs to change its interface ID
	even if it have passed DAD process successfully???

	Also "my node"'s behavior is probabilistic.  This may be fe80::x on A,
	or fe80::x on B, who will be told to leave.  It must be deterministic.

>If we want to do this I will write the spec.  

	Your proposal does not scale.  If you have more than 2 ethernet
	interfaces (put it as N), with 100 hosts connected to each of the
	medium, you need to deal with tons of such situations.  To conform
	there's no duplicate, you need to send probes to (N-1) ethernet
	interfaces every time you see fe80::x on any of your interface.
	It is not clear when you can be sure if there's no fe80::x on
	other (N-1) interface (timeout parameter is very hard to determine).
	I would say that this is a impossible requirement for a multihomed
	node (both router and host).

	Also this is rather giant leap from the model we used in IPv4 model.
	Network A and B needs to be very separate.

itojun

---

From: Jim Bound <[email-masked]>
Date: Tue, 30 Nov 1999 10:22:37 -0500

>	This is true for link-local unicast, and scoped multicasts (14 scopes)

The reason I don't agree that multicast has the same property set
problem is as a sender I can spray multicast on all scope set of
interfaces.  Its an address to listen too for receivers.  In the
responses to the sender the scope is known from any responses as it
comes back on an interface.  This disambiguates the scope to the sender
from the responses.

Unicast scopes have a different problem set in my view.

>	more explicit use of scope id is necessary to handle:

All multicast addresses are scoped.  These are not the same issue.

>	what cycle?  Could you give me a step-by-step example?

Same algorithm re-stated is all I was saying.

>	you would need to run IBGP tcp session over site-local address.

This I agree could be a good use of site-local addresses. 

>	while I'm calling mine "cnw0".  This will never be exposed to outside.

I know that.  What I was asking where did one set the relation between
Site A = 3 and Site B = 4.  But nevermind I know the answer and how I
would do it.

>	Even if hardcoded, this does not break renumbering in a site.

It does.  Any relations that exist which depend on the site prefix will
break when the site prefix changes.

If the site prefix is based on a global address then the site address
mechanics are affected by a renumber operation on global addresses.

>	node we're looking at is multi-sited.  Then how do you think.

So the node in the middle is connected to both cisco and stanford?
Then that is fine.  That was not clear to me anyway in your mail above.

>	web server) does not change so there's no problem.

Sure it will.  The reason is that a scope-id by itself as a unary type
is useless without an address.  The tuple must have two elements:

   site A or 1 
   prefix associated with this site according to Erik's draft

If the prefix changes then the tuple is invalid and must be updated.

>	"scope boundary" at runtime.  Are you going to propose the latter?

Not me.  You should send this out as separate mail thread and ask Matt
Crawford to respond.

>	Apologies if I sounded differently.

I don't have time right now to go look at that draft today.  I will as
the solution to this progresses.  You may want to point this out too in
a separate mail thread.

OK.

>	How do you notify the victim if you think the victim's link-local

That would be a new ND message type or option.

>	even if it have passed DAD process successfully???

yep.

>	or fe80::x on B, who will be told to leave.  It must be deterministic.

the first one in my-nodes ND cache wins.

>	node (both router and host).

First.  I think in future discussions be careful to say I am wrong.  All
I said is I could make it work.  Saying it don't scale is fine I did not
say it did.  So saying things like "your wrong" is not a good
presentation to one discussing something with another.  It implies it
can't be done.  It can be done but may not scale is a different
statement and a different tone in a discussion.  There are times to say
the words wrong, or you don't have a clue, or whatever, but that is not
I hope where our discussion has been.

But back to the point of scaling.  But again your using the word
"impossible" above.  Please don't do that it is not valid.  You
contradict yourself.  First you say it will not scale meaning to me
anyway it will work but perform poorly.  

You should have said:

  This is not an optimal requirement for a node.

This I would deal with well and I think others.  But I would argue the
entire issue of scopes is not optimal and either will be the solution.

Anyway I will jump into a fight very quickly when folks use fighting
words and I don't think that is what you intended or is your objective
to try to belittle me or anything like that.  But I could perceive that
with some of the words you use at times.

I know what interface and what address is associated with that
interface, hence, what link it is on and thus what site it is in.
I would not have to probe all interfaces or all sites I would know that
from the array of pointers in my ND cache.

It clearly adds more code to ND processing.

But I have decided to go work on Erik's draft for now and get off this
thread as some on the list don't want to discuss this anymore.  

>	Network A and B needs to be very separate.

The entire notion of site-local and link-local addresses and having to
add scope-ids to addresses is a giant leap from the IPv4 model, hence so
is my proposal to fix it for link-local.

/jim