Subject: RE: Textual Address Change for Scope-IDs

From: Richard Draves <[email-masked]>
Date: Sun, 21 Nov 1999 15:22:25 -0800

> 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 is an intriguing idea, but I haven't decided yet if it's good or bad.

Let me rephrase it (maybe change it a little):
- the in6_addr binary representation would take some of the currently unused
bits in link-local, site-local (and multicast? did we ever figure out if
sin6_scope_id is used for multicast?) addresses for storing the scope-id.
- however, in the textual representation those bits would appear to be zero
and the scope-id would be indicated with a separate delimiter character and
number, like the jinmei draft.

For example (assuming a 16-bit scopeid):
binary representation is fe80 0001 0000 0000 0a00 46ff fe04 6747
text representation is 1/fe80::a00:46ff:fe04:6747 or
fe80::a00:46ff:fe04:6747@1

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

The disadvantage of this scheme is that everything that takes a binary IPv6
address and puts it on the wire needs to be cognizant of the special
scope-id bits and zero them out. For the IPv6 stack itself, this isn't such
a big deal. However applications put binary addresses into data streams that
go on the wire. So it would impact applications.

The counter-argument is, applications that are putting scoped addresses into
their data streams probably need to know what they are doing anyway, or else
they'll screw up and send the scoped address outside of its scope zone.

Rich
--------------------------------------------------------------------
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] (Sam Manthorpe)
Date: Sun, 21 Nov 1999 15:43:24 -0800 (PST)

Richard,

> fe80::a00:46ff:fe04:6747@1

Yes, exactly.  Thanks for the example.

> go on the wire. So it would impact applications.

Good point.  I agree that those who write apps that send binary addresses
over the while should know what they are doing.  However, it does introduce
a backwards compatability problem for legacy apps who are not expecting
the embedded scope-ids.

This problem can be solved in part for getipnodebyname() by adding a flag
requesting embedded scope-id and changing AI_DEFAULT to include that new
flag.  inet_ntop() is more problematic.

-- 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: Stig Venaas <[email-masked]>
Date: Mon, 22 Nov 1999 01:28:21 +0100

> a backwards compatability problem for legacy apps who are not expecting

I think some apps that pass binary addresses might have to pass scope-id
as well. I've had a hard time figuring out what to think of scope-ids. It
really depends a lot on what they are. If a scope-id is just an interface
identifier, it won't make sense using them in DNS, scripts etc. and I
think things could get messy quite easily. I tend to think that link-
local doesn't belong in DNS at all, site-local might be possible, using
Jim's idea of looking at the scope for the interface the DNS lookup was
sent from. Users really shouldn't have to know what interface to use
though. If scope-ids should be something else, there must be some way to
configure what the id should be, and the id allocation might have to be
administered, one could perhaps use AS-numbers for site-local scope-id.
If one ends up administrating id's, why not just use global addresses?

I actually think that we can cope without scope-ids for site-local
addresses. In most cases where two sites are interconnected, they
would have global addresses in order to have communication between
internal hosts at the two sites. One could then use global addresses for
all communications, or at least for traffic originating at border hosts.

Stig

-- 
Stig Venaas
UNINETT/NTNU

---

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

Date:        Mon, 22 Nov 1999 01:28:21 +0100
    From:        Stig Venaas <[email-masked]>
    Message-ID:  <[email-masked]>

  | If one ends up administrating id's, why not just use global addresses?

This again all comes down to what you think the less than global
scope addresses are to be used for,

One use that I think everyone seens is as a kind of replacement for
IPv4 "private" addresses (net 10 and the like) for disconnected sites.

That is, if global addresses come only from your upstream site (to get
aggregation to work) and there is no generic "assign me a global address
without me telling you where I will connect it, as I don't know, and
might never" type service anywhere, then some other kind of address
needs to be available, and link local and site local, can fill that
need.   That much is pretty simple, and if that is the only use, then
in a sense scope-ids aren't needed (link locals would be used when
there is only one link - and for the purposes defined to require them,
which need no scopes as they're already bound to interfaces - there would
only be one site local address).

However, another theory is that site local addresses (or link local
when it works) ought to be used for *all* communications between nodes
when they can work, to insulate those connections from changes to global
addressing (your local fileserver to client connections don't all
die because you have changed provider - they can remain stable for years).

If that is what ends up happening, then we do need to cope with the
nodes with more than one local zone (for link locals, this means
everything with more than one interface).

Again, I just don't think we have enough experience with the
possibilities of such things yet to actually make a decision.

kre

---

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

In your previous mail you wrote:

=> the best answer is the user should use names (in fact the user
would like to use names for IPv4 and will *want* to use names for IPv6 :-).

=> even we can get rid of site-local addresses (or apply Christian's idea)
the problem remains for link-local addresses which are useful in some
cases (mainly emmergency situations then I agree that common users
should not use scoped & numerical addresses but I can't accept
that all users must not use them).

=> I never have a concern about this use of site-local addresses.

=> this will be the case if we adopt the address selection rules but
this should be internally managed by the API, ie. the user will give
a name and the right thing will happen.

=> there are nodes with more than one interface then the problem is *real*.

=> I disagree. At the beginning we have no way to specified the outgoing
interface then we have to wait the in6_pktinfo stuff which gave a solution
for special cases (like RIPng tools) but not a general one.
Then we have got RFC 2553 with the scope ID and the chance to get a
general solution and to apply it to all applications, then we need
a standard syntax (draft-ietf-ipngwg-scopedaddr-format-00.txt) and
a way to use it in the API (current discussion).
Unfortunately we have enough experience to know what we need...

Regards

[email-masked]