Subject: (IPng 6740) scope_id questions

From: [email-masked] (Sam Manthorpe)
Date: Thu, 12 Nov 1998 20:34:21 -0800 (PST)

My view of the scope_id field in the sockaddr_in6 structure is as
a kernel `cookie'; i.e. the kernel gives the value to userspace
to identify a particular scope and applications pass it back to 
the kernel, right?

So, now a few questions:

    1)	How is an operating system meant to assign scope_ids to
	different interfaces for multi-sited hosts?

    2)	How does a kernel, when configuring a site-local address
	on an interface, presumably due to a userland request,
	know which other site-local addresses on the same host
	(if any) share the same scope_id?

    3)	If the answer to the above questions is something like
	`This is user-specified, since the site-boundries are
	purely administrative boundries and therefore specified
	in a configuration file somewhere' does anybody have
	any ideas on how, exactly, scope_ids should be communicated
	_to_ the kernel during address configuration?  Using
	scope_ids themselves seems bad, due to their ephemeral
	nature, but maybe with a slight shift in semantics of scope_ids,
	it would be okay for the user to specify it.  It would
	then be the user's responibility to maintain the scope_id
	space (at least for site-locals).  Has anyone already 
	implemented this?

Any answers appreciated,

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: Erik Nordmark <[email-masked]>
Date: Thu, 12 Nov 1998 21:05:13 -0800 (PST)

> 	different interfaces for multi-sited hosts?

Assuming it knows the which interfaces belong in which sites
all it needs is to assign unique integers to the "site ids"
much like it generates interface ids today.
 
> 	(if any) share the same scope_id?

It doesn't. But assuming the interfaces are configured automatically
then the mechanisms in draft-ietf-ipngwg-site-prefixes-nn.txt can
help. Once your "addrconf daemon" has the site-prefixes for each interface
it can make intelligent guesses of how to determine which interfaces
belong to the same site.
Thus it can tell the kernel what site id to use for each autoconfigured
interface.

> 	space (at least for site-locals).  Has anyone already 

At some level it is user-specified but with the site-prefixes draft mechanism
this would be done on the routers (or border routers if we extend the router
renumbering protocol). Thus a router would now that "this site has the 
prefixes 1:2::0/48 and 2:4::0/48" and a router in another site would
be configured with "site prefix 9:9::0/48". A host connected to both routers
can determine that they are different sites since the site-prefixes are
different.

In terms of communicating this to the kernel I'm planning on adding
SIOC{S,G}LIFSITEID much like SIOC{S,G}LIFINDEX for the interface
index. But I'd expect these ioctls only be used by the "addrconf daemon".
Thus the actual ids can be assigned serially at boot just like the
interface indicies.

BTW: A "link id" concept might also be useful down the road to deal 
with the cases when there are multiple interfaces (and interface indicies) that
apply to the same link.

   Erik

---

From: [email-masked] (Sam Manthorpe)
Date: Fri, 13 Nov 1998 13:34:23 -0800 (PST)

Erik,

Thanks for the reply.  I'm afraid I'm still a bit in the dark:

> renumbering protocol). 

If we are considering a multi-sited host then aren't we actually talking
about a router rather than a host?

> Thus a router would now that "this site has the 

Okay, I'm confused.  Are you saying that part or all of the subnet ID
can be used to distinguish between sites?  Surely not.  I don't see
any reason why the host connected to both sites can't receive exactly
the same subnet IDs from both routers (using your scheme), even though 
they come from different sites.  Surely, I, wearing my site-administrator
hat, am allowed to allocate my subnet-ID address space however I chose,
and my neighbouring site-admin is free to do the same.  Taking your model 
(where a host is connected to multiple sites rather than a router being
connected to multiple sites):

                   site A             site B
            |----------------|  |-----------------|

             r1 ------------- h1 -------------- r2
                         if_0    if_1
                fec0:0:0:1::1    fec0:0:0:1::2

Host h1 is connected to site A on interface if_0 and to site B on
interface if_1.  The subnet to which if_0 is connected has a subnet
ID of 1 (on site A) and the subnet to which if_1 is connected also
has a subnet ID of 1 (on site B), which is okay because each interface
belongs to a different scope.  Host h1, however, must be aware that
the two belong to different sites.  Among other things, it must
not forward packets from site A to site B.

If subnet IDs must be globally unique, as you are suggesting, then
what's the difference between site-local and global addresses?

> index. But I'd expect these ioctls only be used by the "addrconf daemon".

Sounds reasonable.  This pushes the fundamental question out of the
kernel into the "addrconf daemon", which I beleive is the correct
place for it to be.  So now, how does the "addrconf daemon" 
distinguish between sites?  The conceptual model I have seems to be 
different to the one you have.  I'm assuming that any node connected 
to more than one site is a router and so there's no question of 
receiving site prefixes or any other kind of config information from 
a router.  The buck stops here, so to speak.

> Thus the actual ids can be assigned serially at boot just like the

No, because that would force each interface to belong to a different
site, which isn't what I want.  The allocation of interface to site
seems to me to be a sysadmin decision.

> with the cases when there are multiple interfaces (and interface indicies) that

Agreed.

-- Sam

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Nov 1998 15:36:28 -0800 (PST)

Sorry for the slow response.

> about a router rather than a host?

I don't think we want to require that all multi-sited nodes be routers.
It might make sense to have large multihomed servers that actually serve
multiple sites (for instance when a some service is outsourced to an ISP
the ISP might run a single server for multiple sites.)

> connected to multiple sites):

No, I'm saying that the first bits (often 48 of them in the current address 
allocation scheme: TLA + NLA(s)) of the global addresses 
can identify the sites - this is what
I call the "site prefix" in the draft. Two different sites
will have different TLA + NLA(s) prefixes.

The site-local addresses can of course be the same.

>                    site A             site B
Add global addrs:  1:2:0:1:1	   2:4:0:1::2
> what's the difference between site-local and global addresses?

I didn't suggest that.

> seems to me to be a sysadmin decision.

Sorry for being unclear. What I meant to say was that when the addrconf
daemon detect (using the mechanism suggested in
draft-ietf-ipngwg-site-prefixes) that it is connected to different sites it
can pick serial numbers 1,2,3 etc to identify the sites. Thus initially all
interfaces are considered to be in site id #1. When it detects that some
interfaces have different  site-prefixes it can declare those to be in site id
#2. The point is that the site id is just a locally significant identifier
that doesn't have to be stable across reboots (just like the interface index).

  Erik