Subject: Re: Site Identifiers and IPv6 Multisited Applications Nodes

From: Erik Nordmark <[email-masked]>
Date: Wed, 1 Mar 2000 12:25:25 -0800 (PST)

> 	(assume this multi-sited server has fec0::1%site0, fec0::1%site1,
> 	and fec0::1%site2)
> 	I thought of binding to more specific address, like:
> 		daemon 1 binds to fec0::1%site0
> 		daemon 2 binds to fec0::1%site1
> 		daemon 3 binds to fec0::1%site2
> 
> 	Given that the interpretation of sin6_scope_id is determined by
> 	sin6_addr, I think binding to ::%site0 is not a good idea.  "::"
> 	does not give context to sin6_scope_id portion...

The problem is that e.g. for site1 the server have multiple interfaces
with different IIDs i.e. there is more than one site-local address for each
site. Thus daemon 2 needs to bind to more than one address
		fec0::a00:20ff:fe01:4444%site1
		fec0::a00:21ff:fe08:5555%site1
		fec0::a00:20ff:fe67:3333%site1
		fec0::a00:20ff:fe01:2222%site1
(assuming there are 4 interfaces to site1).

Doing this would require modifying the application source code.
Perhaps those modifications are less than making the application
site aware (i.e. carrying around sockaddr_in6 instead of in6_addr
internally) - perhaps the modifications are more significant than make
it site aware. I suspect the tradeoff is different for different applications.

Thus my question was really: Do we need to provide a mechanism for
an unmodified application which binds to in6_addr any to limit
it so a given site?

*If* we do the mechanism might need to be something ugly like an environment
variable (e.g. setenv XXX_LIMIT_IPV6_BIND_TO_SITE "site1") that the
bind() library/system call interprets.

Another possible question is: Do we need a mechanism to make it easier for
an application that can be modified to handle the above case with
multiple site-local addresses (due to multiple interfaces) per site?

  Erik

--------------------------------------------------------------------
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: Thu, 02 Mar 2000 12:36:34 +0900

I believe "non site-aware server program on multi-sited node"
	situation is *extremely* rare.  I don't think we need to tweak
	APIs for this - properly written (*) server program can serve on
	multi-sited node okay with the existing API.

	(*) properly written means:
	- always honor sin6_scope_id came from the kernel
	- don't try to pack a sockaddr_in6 by itself.  this usually result in
	  invalid (or unmatched) sin6_scope_id.
	- always use getpeername/getsockname to get remote/local address.
	  gethostname -> gethostbyname for getting local address is wrong.
	- use getaddrinfo and getnameinfo, with jinmei extension format,
	  when you put data into database

>(assuming there are 4 interfaces to site1).

	if this is the case, why not run a daemon on an interface?  I agree
	it is dependent to certain application if we can do it or not.

>multiple site-local addresses (due to multiple interfaces) per site?

	First of all, I believe multi-sited node is extremely rare.
	*If we do*, I vote for something similar to
	setsockopt(IPV6_MULTICAST_IF).

itojun