Subject: Site Identifiers and IPv6 Multisited Applications Nodes

From: Jim Bound <[email-masked]>
Date: Fri, 25 Feb 2000 12:08:06 -0500

Folks,

In rfc2373.txt

2.1 Addressing Model

   IPv6 addresses of all types are assigned to interfaces, not nodes.
   An IPv6 unicast address refers to a single interface.  Since each
   interface belongs to a single node, any of that node's interfaces'
   unicast addresses may be used as an identifier for the node.

It is wise to permit the last sentence and many network application in
fact to identify a node or connection by its address.  Like DNS and
DHCP.

Do we realize what we have done here?

We are telling applications that exist on a multisited node that it must
replicate the data for a site like in 2face DNS or change their
application to be site-aware for the database key lookup.  I am not
convinced that the application vendors who are ISVs are going to be too
happy about this or the vendors who ship network apps like DNS and DHCP.

I think we need to poll applications vendors and get their reading on
what we have done here.  It may be too painful for them and the market.

Comments?

regards,
/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: Robert Elz <[email-masked]>
Date: Sat, 26 Feb 2000 10:06:57 +1100

Date:        Fri, 25 Feb 2000 12:08:06 -0500
    From:        Jim Bound <[email-masked]>
    Message-ID:  <[email-masked]>

  | 2.1 Addressing Model
  | 
  |    IPv6 addresses of all types are assigned to interfaces, not nodes.
  |    An IPv6 unicast address refers to a single interface.  Since each
  |    interface belongs to a single node, any of that node's interfaces'
  |    unicast addresses may be used as an identifier for the node.
  | 
  | It is wise to permit the last sentence and many network application in
  | fact to identify a node or connection by its address.  Like DNS and
  | DHCP.
  | 
  | Do we realize what we have done here?

Jim, maybe you could explain what you'e seeing as a problem there,
because at the minute, I just don't see it?   To me this just looks
like the current practice with IPv4 addresses (when you need to
identify a node, pick one of its addresses).   Or is the problem
that a link-local or site-local address might qualify as "any of the
node's interfaces' unicast addresses" ?   That I suspect might lead
to some problems - perhaps a few extra words requiring an address of
the widest scope available on the host?

kre

---

From: Jim Bound <[email-masked]>
Date: Fri, 25 Feb 2000 19:22:04 -0500

| 2.1 Addressing Model
  | 

>the widest scope available on the host?

Yes I was terse.  I figured I would start there.

First yes it is like IPv4 when you want to identify a node just use the
address.  Here I was stating the obvious (though some disagree with
this).  My statement "Do we realize what we have done here?" was really
in reference to the site-local address and from that the need for a site
identifier.  

Let me take a few steps back OK.

A multisited sever is one which has link connections to different sites.

In each of those sites we cannot be guranteed that the site-local
addresses in those sites are not duplicated.

Because of the above an Application like DNS or DHCP, or a NASTRAN
application that distributes computational elements to nodes on multiple
networks in a discrete manufacturing customer site (my company has these
types of customers) identifying the nodes by addresses and within their
database, in the case of IPv6 with site-local addresses for a multisited
node has ramifications that must be addressed within IPv6 and does not
occur with IPv4.

Either the application must replicate the database, queue, whatever the
state for each site link it communicates on, OR change its key to access
and identify nodes (which are clients) to hold a site-identifier with
the address.  Ergo DNS would have to contain a site identifier with the
address entry (AAAA or A6).  Or as I said have to separate databases for
each link (or set of links) in a site.  This is a significant change to
the operation for Application vendors or those who provide
infrastructure with products like BIND or DHCP.

So when I said "do we realize what we have done" I mean do we realize:

  1.  That a site-local cannot uniquely identify a node to a multisited
      server and this breaks what I put out from rfc2373.
  2.  That we have greatly affected applications that operate as 
      I state above.

This is why I think we owe IPv6 another look at embedding
site-identifiers inside the IPv6 address as you suggested and this time
not have a mail discussion but a real proposed draft if we (those that
join me) can accomplish this task and make it work and then have it
discussed by the working group.

Sorry for being long winded but did that help?

regards,
/jim

---

From: Robert Elz <[email-masked]>
Date: Sat, 26 Feb 2000 12:05:41 +1100

Date:        Fri, 25 Feb 2000 19:22:04 -0500
    From:        Jim Bound <[email-masked]>
    Message-ID:  <[email-masked]>

  | Sorry for being long winded but did that help?

Well, yes, I think i understand the problem - and yes, there are
some problems with site addressing that haven't been sorted out.

I'm not sure that attaching the problem to that one sentence in 2373
is exactly how I would have come at it though.

kre

---

From: [email-masked]
Date: Sat, 26 Feb 2000 12:55:56 +0900

(snip)
>Sorry for being long winded but did that help?

	The above story is not special for site-local address, I believe.
	We already have other scoped address: link-locals.
	The above looks exactly the same story with link-local addresses.
	- a server connected to multiple links need to disambiguate links,
	  since there can be fe80::1%link1 and fe80::1%link2
	- sin6_scope_id disambiguates them

	Putting site identification into site-local address is one of the
	solution that works.  I took your saying as "put site identification
	into DNS database, wire address format, and other things as well,
	is it correct?  We will see packets with, say,
		fec0:1::abcd:efgh
	on ip6_dst on the wire.  I think I'm okay with this, as long as
	routers can be configured not to forward them across different sites.
	(fec0:1::1 <-> fec0:2::1 should not be able to communicate directly)

	Another solution is to always use scoped address notation when you
	make a database.
	- distinguish sites by sin6_scope_id 
	- DNS resolver for multi-sited server needs to be improved, so that
	  it would fill in appropriate site identifier into sin6_scope_id.
	  (NOTE: getipnodebyname is not useful for multi-scope boundary,
	  as we have discussed.  we need to use getaddrinfo)

DNS server for site A --128bit---> resolver --128bit + site id A--> apps
DNS server for site B --128bit---> resolver --128bit + site id B--> apps
			(AAAA, or A6)		(sockaddr_in6)
	- applications will hold addresses in jinmei format (fec0::1%cisco)
	  into database 
	Since we need to solve multi-liked this way, I think solving site-local
	case with same way has a merit.

	Easiest workaround for "site-unaware servers on multi-sited node"
	is to run multiple servers, one for each site.  This solves many of
	typical cases.
  
itojun

---

From: Jim Bound <[email-masked]>
Date: Sat, 26 Feb 2000 21:15:23 -0500

Itojun,

Thanks for the dialogue.  A draft will be produced to embed the
addresses I hope by June 2000 and maybe before.  Not going to get into
it now as its just an idea, and a few of us will put the energy and time
into working it as engineers, and then bring it to the IETF.

I speak at various functions and talk to the press about IPv6.  Here is
what I am recommending regarding this whole issue at this point it does
not relfect my companies views or the views of the IPv6 Forum.

1. For now use caution with site-local addresses.

2. DO NOT USE LINK-LOCAL ADDRESSES for user applications their purpose is to
be used by network wire control functions for node discovery in IPv6.

I say lots of other stuff but these are relative to the mail response
you sent.  Of course there are a lot more words that go with the two
sentences.

/jim

---

From: Jim Bound <[email-masked]>
Date: Sat, 26 Feb 2000 21:19:36 -0500

Itojun,

Also I say:

ALL ISVs move to getaddrinfo/getnameinfo now.  Even if we find
alternative solution to scoping (as you pointed out) these APIs will
support your software for the future better, because of their breadth 
and extended argument types.

/jim

---

From: [email-masked]
Date: Sun, 27 Feb 2000 12:39:00 +0900

>you sent.  Of course there are a lot more words that go with the two

	I personally agree with the above two items, scoped addresses put
	novice users into confusion.  I have been telling prople, or writing
	webpage, which means similar things.

itojun

---

From: [email-masked]
Date: Sun, 27 Feb 2000 12:40:30 +0900

>and extended argument types.

	the proposal I've posted one mail ago will use getaddrinfo.
	anyway, it's good to hear that more people is using getaddrinfo.

itojun

---

From: Jim Bound <[email-masked]>
Date: Sat, 26 Feb 2000 22:51:52 -0500

Very well put.

/jim

---

From: "Matt Crawford" <[email-masked]>
Date: Sun, 27 Feb 2000 08:22:14 -0600

> >be used by network wire control functions for node discovery in IPv6.

Whatever happened to our dentist?
Farewell to zeroconf?

---

From: Jim Bound <[email-masked]>
Date: Sun, 27 Feb 2000 17:18:08 -0500

>Whatever happened to our dentist?

They got into the web.

>Farewell to zeroconf?

Different set of issues.  zeroconf will still work out of the box which
it its point.

With caution one can use site-local addresses too.  But one should 
really just go get a global one from ones ISP.

/jim

---

From: Francis Dupont <[email-masked]>
Date: Tue, 29 Feb 2000 09:47:33 +0100

In your previous mail you wrote:

   Folks,
   
   In rfc2373.txt
   
   2.1 Addressing Model

   
   
=> I think we have to add "in the zone" in order to solve this issue
(it should be in the future "zone document" :-).

   We are telling applications that exist on a multisited node that it must
   replicate the data for a site like in 2face DNS or change their
   application to be site-aware for the database key lookup.

=> a multisited node is already a strange thing then don't expect to
have nothing a bit special to do with this beast...

Regards

[email-masked]

PS: I believe Itojun's suggession is the best one (as usual).

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Feb 2000 11:50:15 -0800 (PST)

Jim,

> 1. For now use caution with site-local addresses.

Agreed.

> be used by network wire control functions for node discovery in IPv6.

There might be zeroconf and ad-hoc networking situations where the only 
IPv6 address you have is a link-local address. Thus I don't think we should
recommend that applications explicitly fail to communicate using link-local
addresses.

Applications should never prefer a link-local address over a larger
scope address, and they should use caution when there is only a link-local
address to use.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Feb 2000 11:40:03 -0800 (PST)

> 	is to run multiple servers, one for each site.  This solves many of

Do the APIs we've specified have the needed features to run
one server application per site on a multi-sited node?

An application can bind to in6addr_any and some port but that
would not restrict the server to only handle connections/datagrams
from one site.

  Erik

---

From: [email-masked]
Date: Wed, 01 Mar 2000 13:01:00 +0900

>would not restrict the server to only handle connections/datagrams

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

itojun