Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt

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

>1. Introduction
>
>   There are several types of scoped addresses defined in the "IPv6
>   Addressing Architecture" [ADDRARCH]. Since uniqueness of a scoped
>   address is guaranteed only within the according scope, the semantics
>  for a scoped address is ambiguous on a scope boundary. For example,
>   when a user specifies to send a packet from a node to a link-local
>   address of another node, the user must specify the link of the
>   destination as well, if the node is attached to more than one link.

The last sentence is not necessarily true.  It is not the link that must
be specified but the scope.  This is much different.  And as you say
below:

>   This characteristic of scoped addresses may introduce additional cost
>  to scope-aware applications; a scope-aware application may have to
>   provide a way to specify an instance of a scope for each scoped
>   address (e.g. a specific link for a link-local address) that the
>   application uses. Also, it is hard for a user to "cut and paste" a
>   scoped address due to the ambiguity of its scope.

The key phrase is scope-aware applications.  It is not required by IPv6
that any application be "scope aware".   It is a feature we are in the
process of defining and the semantics and the syntax.

I look forward to the discussion at the ipng meeting, but I think this
draft is premature similar to 6to4 specifying the address selection
mechanism before we had a src address selection plan.  Likewise we need
a plan for scoping and what it means.  I believe that was an action item
to discuss and get started for ipng and I believe that work must be a
predecessor to this work before we can agree this spec is valid.

I also think we may or may not need to have the address as part of the
sin6_scope_id field.  It could be any type of data to-be-defined.

Also unless this is to be anymore than an informational RFC for general
knowledge but not a standard.  Either put your discussion of
getaddrinfoo in an appendix or address all parts of the base API.  We
cannot have specs that only work with one part of the base API. 

/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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 05 Nov 1999 20:36:15 +0900

Thanks for your comments.

>>>>> On Fri, 05 Nov 1999 00:22:26 -0500, 
>>>>> Jim Bound <[email-masked]> said:

> be specified but the scope.  This is much different.  And as you say

I'm sorry for the confusing text, but the last sentence is just an
example for a link-local address. In general, of course, we should use
the term "scope".

> that any application be "scope aware".

That's right. So the proposal is meaningful only for scope-aware
applications. And there exist such applications definitely.

> It is a feature we are in the

Exactly.

> predecessor to this work before we can agree this spec is valid.

I agree that we should define "scope" more specifically, but I still
believe that our proposal can progress on a parallel with defining the
semantics of scope.

> sin6_scope_id field.  It could be any type of data to-be-defined.

The mapping between the proposed format and the sin6_scope_id field
described in the draft is just an example. We won't require the
mapping.

> cannot have specs that only work with one part of the base API. 

I apologize for the incomplete examples. I didn't intend to get rid of
other functions defined in the basic API such as
getipnodebyname(). It's (again) just an example as a reference.

In a revised version of the draft, I'll put the examples in an
appendix and/or show some extension to the hostent structure so that
getipnodeby*() can also handle the proposed format of scoped
addresses.

					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: Fri, 05 Nov 1999 09:15:51 -0500

OK... another question..........

another point.......

do you believe the sin6_scope_id should be used to define scope?

Or where Francis's PS comment where scope is inherent in the
sockaddr_in6 address?

this is a critical point.

thanks
/jim

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sun, 07 Nov 1999 02:50:56 +0900

>>>>> On Fri, 05 Nov 1999 09:15:51 -0500, 

> do you believe the sin6_scope_id should be used to define scope?

Yes.

> Or where Francis's PS comment where scope is inherent in the

I may miss your point, but do you mean the in6_addr structure here? As
far as I know, his proposal is like this:

struct in6_scaddr {
	struct in6_addr sc6_addr;
	uint32_t sc6_scope_id;
};

which should replace the in6_addr structure itself. But, okay, this is
a minor detail.

> this is a critical point.

Hmm...this seems a difficult question to answer..

If I could design the basic API from the scratch, I'd support the
Francis' idea, since a scoped address without its scope identifier is
incomplete as an IP address. However, from a deployment point of view,
replacing such a fundamental structure has too big impact. It'll
affect many existing applications and break source/binary level
compatibility.

So my current position is:
  - we should keep the sockaddr_in6 structure and just define the
    semantics of the sin6_scope_id field.
  - we could define a new structure like in6_scaddr, but the new
    structure should not affect existing applications and library
    functions.

Is this clear (and acceptable, I hope) for you?

Thanks,

					JINMEI, Tatuya

---

From: Jim Bound <[email-masked]>
Date: Mon, 08 Nov 1999 07:28:50 -0500

>Is this clear (and acceptable, I hope) for you?

Yes it is.  I am not sure we need a new structure if we define 
semantics of sin6_scope_id.  Good response..thanks...

/jim

---

From: Francis Dupont <[email-masked]>
Date: Mon, 08 Nov 1999 20:44:28 +0100

Yes.
   
=> there is a misunderstanding. I think in some cases an IPv6 address
alone (an in6_addr structure) is not enough and a scope ID must be
provided with it. Of course the sin6_scope_id field should be used
when a full sockaddr_in6 is there.
 My problem is that for perhaps not so good reasons some applications
use directly in6_addr structures without scope IDs. This is wrong and
can be fixed in two ways:
 - use a sockaddr_in6 in place of an in6_addr
 - add a scope ID field in these applications.
The second solution may be useful if the price of a sockaddr_in6
(or a sockaddr_storage) is too high but we want the same thing,
ie. kill wrong ways to deal with IPv6 addresses in applications...

   
   If I could design the basic API from the scratch, I'd support the
   Francis' idea, since a scoped address without its scope identifier is
   incomplete as an IP address.

=> we agree about what is the problem to solve.

   However, from a deployment point of view,
   replacing such a fundamental structure has too big impact. It'll
   affect many existing applications and break source/binary level
   compatibility.
   
=> this is not my proposal! I don't want to change the in6_addr
everywhere, I'd just like to convince people who use in6_addr today
to change to something with a scope ID and if sockaddr_in6 is too
expensive I propose a cheap way to do it. There are many places
where an address with a scope is enough, the first example is
the in6_pktinfo structure...

   
=> this is my position too.

BTW about getipnodebyname(), we need to get a way to have scope ID(s)
added to the result (the hostent structure). If we don't do that
getipnodebyname() won't be used because it will be too easy to find
examples which break it.
A scope ID is more a property of an address than of a hostent,
then we should restrict hostent to one address if we can put only
one scope ID in it, or add an optional (default value will be 0)
scope ID per address. I've just given a way to code (address, scope ID)
pairs...

Regards

[email-masked]

---

From: [email-masked] (Sam Manthorpe)
Date: Mon, 8 Nov 1999 19:22:05 -0800 (PST)

> getipnodebyname() won't be used because it will be too easy to find

Yes that was exactly the point of the related tributary-thread.

> scope ID per address. I've just given a way to code (address, scope ID)

Yes, as you and Brian have explained, per hostent or per-call-to-
getipnodebyname() scope-ids aren't really sound; I now think the only
real way to solve the problem is to change the data types used
in the list of addresses from in6_addr to either sockaddr_in6 or
your proposed sockaddr_in6_lite (if I may call it that).  Should
this just be done, breaking the existing API?    What about the
additional getipnodebyname() flag indicating that a scope-id
is desired that I suggested in my last mail?

-- 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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 09 Nov 1999 13:21:44 +0900

>>>>> On Mon, 08 Nov 1999 20:44:28 +0100, 
>>>>> Francis Dupont <[email-masked]> said:
   
> ie. kill wrong ways to deal with IPv6 addresses in applications...

Ah, okay. Sorry for misunderstanding and thank you for clarification.

   
> => this is my position too.

Okay, thanks.

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Tue, 09 Nov 1999 16:27:22 +0100

Should this just be done, breaking the existing API?

=> to break the API is a non-goal...
The choice is between to show the extra infos in the h_length or not.
First is better but has more impact.

   What about the additional getipnodebyname() flag indicating that a
   scope-id is desired that I suggested in my last mail?
   
=> a new flag will help if the h_length reflects more than an in6_addr
but the issue becomes "is this flag set in the default?".

Thanks

[email-masked]

---

From: Jim Bound <[email-masked]>
Date: Tue, 09 Nov 1999 11:04:14 -0500

I strongly objecty to this and will object as far as need be.

getipnodebyanme is frozen and in products we cannot change it.

if we change it we don't have a clue and should never work on APIs in
the ietf for IPv6 again.  

I am serious folks.  Changing this will break products and cause a
deployment of IPv6 issue.  I am bringing this up at the IAB this wed
evening at the IETF.

/jim

---

From: [email-masked] (Sam Manthorpe)
Date: Tue, 9 Nov 1999 10:24:58 -0800 (PST)

Jim,

> I strongly objecty to this and will object as far as need be.

What exactly do you object to?  changing the default behaviour
of getipnodebyname() or changing the API period?  I don't see
any harm in updating the spec with additional functionality that
does not influence existing apps either at the API or ABI level.
(i.e. the new flag requesting sockaddr_in6_lite).  I do of course
see the harm in _breaking_ an API, but my proposal wasn't to
break it.

We (SGI) don't currently have this issue since we haven't shipped yet,
so I don't really care much either way.  However, if getipnodebyname()
doesn't have _any_ possibility of supporting scope-ids I will
never use it.

Cheers,
Sam.

---

From: Jim Bound <[email-masked]>
Date: Tue, 09 Nov 1999 17:12:05 -0500

Sam,

I object to changing the API at all.  It sends the wrong message to the
market and ISVs.  But I will discuss an adjunct to the Base API that
does not break the API.  In fact will provide the update.  But what I
don't want is for RFC 2553 to become obsolete.

But first I think we need a write up on scope-ids so we are all
understanding the same problem and not talking past each other.
I think that is in process now.   

I would like to see us all agree to the problem we are trying to solve.

I would also like to see a list of applications that exist today that
need to be scope aware?

I would like to see a list of applications in the future that could use
scoping?

What I don't want is to say getipnodebyname won't work until we have
discussed the possibilities.  

I don't think DNS RRs should carry scope-ids either.

I am open to "engineering analysis in this working group"  what I am not
open to is vague principals changing our Base API for IPv6.

/jim

---

From: Francis Dupont <[email-masked]>
Date: Wed, 10 Nov 1999 22:02:13 +0100

=> all the management applications (ping, traceroute, SNMP tools, ...)
and some last chance applications like telnet.

=> any applications which should not be used only at a global scope
(like whois for instance).

=> I think you don't want to convert near all the applications to
getnameinfo only because of this problem...

=> DNS should never have a location function IMHO.

=> we agree about what is the problem and a set of reasonable solution.
Now we have to pick one and to find the best way to apply it.

[email-masked]

---

From: Jim Bound <[email-masked]>
Date: Wed, 10 Nov 1999 17:11:57 -0500

francis et al...

I agree.........

/jim