Subject: RE: Textual Address Change for Scope-IDs

From: Brian Zill <[email-masked]>
Date: Sun, 21 Nov 1999 03:03:26 -0800

Sam Manthorpe wrote: 
> Brian Zill wrote:
> > The problem with this scheme [...]
> 
> Oh, sorry, I wasn't clear enough in the explanation.
> 
> The model I had in my head (which I forgot to write)
> is that getipnodebyname() and inet_pton() _do_ parse
> the standardized representation of an IPv6 address
> with a scope-id tagged on (e.g. link1:fe80...).
> They have to do that in order to set the
> scope-id in the binary IPv6 address they create.

Oh, okay.  Thanks for clarifying.  I thought you meant they'd only be able
to return a scope-id when talking to scope-aware name resolvers.  But I
think the other direction (getipnodebyaddr and inet_ntop) is important too.
Then we're getting close to Jim's earlier idea of just doing this
packing/unpacking before/after calling one of these "legacy" APIs.

> I'm trying to find a way for getipnodebyname()
> and inet_pton() to recognize scope-ids that keeps
> everybody happy.

An excellent goal, but it's beginning to look like a tall order :-)

> I want these functions to do that because adding
> per-application functionality for this is silly IMHO.

Except for Jim, I think we're pretty much agreed on that too.

> Sure, you can make new functions to do this but
> then getipnodebyname() and inet_pton() get obsoleted
> which is even worse than breaking the API/ABI.

Is it worse?  What if it turns out to be impossible to make them fully
scope-aware while maintaining backwards binary compatibility?  Jim seems to
be pretty adament about not breaking backwards binary compatibility, it's
less clear as to whether he'd agree to keeping them around in some sort of
deprecated state.

On the positive side, it looks like we now have a couple of ideas for making
these scope-aware without breaking existing apps.  Personally, I still need
some time to think them through before I'll decide which direction to
support.  And yes, it's too late tonight to do that :-)

> I guess this does require an update to the rfc/draft
> but doesn't break the API (btw I'm still unclear if
> Jim objects as strongly to reving the inet-draft as
> he does to breaking the API).

Yes, it would be nice if Jim would clarify this.

Thanks,
--Brian
--------------------------------------------------------------------
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: Brian Zill <[email-masked]>
Date: Sun, 21 Nov 1999 12:59:25 -0800

> From: [email-masked] 
> > Robert Elz <[email-masked]> said:
> > The difference here is who gets the pain.   In the
> > first it is the application programmers, who have
> > to manage to provide a (fairly) consistent user
> > interface and deal with it all over the place.
> > In the second it is the users who have to figure
> > out when they need to add the stray extra syntax, 
> > and what it should be
>
> I think that users will get the pain in the former approach as well;

I agree with Jinmei, the user pain is at least as bad in the non-standard
format case as in the standard format case.  I won't argue that the standard
format case is pain-free, but it is certainly easier for a user to remember
a consistent syntax that works across all commands than to remember all the
different flags that the various commands take (since it's unlikely that
they'll be consistent).

I agree with both Robert and Jinmei that the standard format case is easier
for the programmer.

> I agree that we need try to get the general sense, but I belive we
> should do now. I think that IPv6 is now fairly mature and that (at
> least) the semantics, usage, and importance of link-local addresses
> are clear enough.

I agree again.

--Brian

---

From: Brian Zill <[email-masked]>
Date: Sun, 21 Nov 1999 13:22:57 -0800

Hi Jim,

> From: Jim Bound <[email-masked]>
> 
> >> It may make revisiting the api easier :---)....
> 
> > Adopting it would break binary compatibility with
> > existing apps, which I thought you were against.
> 
> Not at all. I said it would make it easier.
> If I get back an adress like this:
> 
>   fe80::FUZZY::1 with getipnodebyname we would strip out
>   the fuzzy at the resolver and stick it in sin6_scope_id.  
> 
>     1) we would need new flag for getipnodebyname
>        to pass sockaddr_in6
>     2) change hostent to be different in backwards
>        compatible way
>     3) shoot getipnodebyname in the head and
>        use getaddrinfo

Is this an acceptable solution for you?  It is for me.

But what you're describing here isn't the "Robert Elz proposal" (for lack of
a better name -- thanks Robert for clearing that up).  Robert's proposal is
to change all uses of in6_addr to contain embedded scope ids.  This includes
the sockaddr_in6 sin6_addr field, which means we'd no longer need or want
the separate sin6_scope_id field.  Thus my claim that adopting this proposal
would break binary compatibility with the existing API (which has the
sin6_scope_id field).

> > At the risk of repeating myself a billion times,
> > the same issue exists for link-local addresses.
> > Getting rid of site-local addresses would not make
> > this issue go away.
> 
> Well I am not going to repeat my self I have already
> answered you on this twice. 

I'm sorry you feel that way, Jim.  I have read and reread your messages on
this subject, and nothing you've said makes me think that this issue doesn't
exist for link-local addresses.

--Brian

> /jim

---

From: Brian Zill <[email-masked]>
Date: Sun, 21 Nov 1999 13:41:32 -0800

Jim,

> >> If one should add a scope-id to the address
> >> in a string representation as you suggest
> >> it no longer is an IPv6 Address by any standard
> >> we have today.  Hence, it should have its own
> >> API for parsing.  This should not be a change
> >> to the APIs that work with IPv6 addresses.
> >
> >So as long as we retain the current behavior of inet_pton,
> >inet_ntop, getipnodebyaddr and getipnodebyname for backwards
> >compatibility with existing deployed applications, you'll be
> >happy?  Or at least quit complaining?
> 
> I resent your coment using the word "complaining".  But will
> not say more and will let you imagine what I want to say to you.

I meant no negative connotations towards you by the use of the word
"complaining".  Feel free to change the last sentence to "... have no
objections" or "... could live with".  Either one would convey what I meant
to say.
 
> I am discussing an issue with you and others.
> 
> I have no problem changing anything as long as
> its well thought out and will work and is considerate
> of what has been deployed.

Good, I feel the same way.  I think everything I've discussed has been
considerate of what has been deployed.  You convinced me at IETF that we
shouldn't change the API in a way that is not backwards binary compatible,
and I haven't been arguing anything else.  I hope nobody comes up with a
convincing argument for doing so, I don't think anyone has so far.

--Brian

---

From: Brian Zill <[email-masked]>
Date: Sun, 21 Nov 1999 20:01:49 -0800

Can someone (Tim?) who remembers the discussion regarding this proposal from
three (?) years ago summarize why the working group decided not to pursue
this direction and instead choose to have the separate sin6_scope_id field?

Besides the couple of issues discussed below and in Itojun's mail, the only
other argument against it that is immediately apparent to me is that
switching to this scheme would break backwards binary compatibility for apps
that currently expect the sockaddr_in6 struct to contain a sin6_scope_id
field.  And that obviously wasn't an issue back then.  Was there some other
showstopper argument?

Thanks,
--Brian

Sam Manthorpe wrote:
> Richard Draves wrote:
> > 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
> 
> Yes, exactly.  Thanks for the example.
> 
> > 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.
> 
> 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]

---

From: Richard Draves <[email-masked]>
Date: Mon, 29 Nov 1999 11:05:34 -0800

> But I am more interested in this case:
> 
> user app like Netscape, Oracle, MSA-Accounting Network Software, etc.
> does:
> 
>   getaddrinfo (host.foo.com) I will use your preferred API OK.
> 
> When it comes back the node has an address which it got from a DNS
> lookup of the name for the dst of the node.
> 
> How does the node know what the dst scope-id is for host.foo.com?

Jim, I think you're asking where the getaddrinfo() implementation (when
resolving names, not literal addresses) gets the scope-ids that it returns?

For names that resolve to link-local addresses: presumably some special
link-local name resolution method is being used, like the ICMP-based
mechanism. In any case, the scope-id should identify the link on which the
name resolution was performed.

For names that resolve to site-local addresses: Erik's site-prefixes draft
needs some additional explanation of this point, but I think it's a pretty
simple extension of the procedure in the "host name lookups" section. (I've
recently implemented Erik's draft and I have a list of comments to send when
I get some time - this is one of them.)

For name that resolve to global addresses: the scope-id is zero.

Rich