Subject: RE: Textual Address Change for Scope-IDs

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

> From: Sam Manthorpe <[email-masked]>
>  
> There is another possibility which I don't think
> has been considered yet:
> 
> Put the scope-id in the in6_addr in the same way as
> KAME do (did?) it, _but_ only in the binary instances
> of the address, never in textual representation.
> 
> [...]
>
> I can't think of any disadvantages to this scheme, but I'm sure
> somebody else on the list can :-)

No doubt :-)  

The problem with this scheme is that it doesn't solve the textual
representation problem.  Users should be able to specify scoped addresses in
a standard way that doesn't change when they move from implementation to
implementation.

--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: [email-masked] (Sam Manthorpe)
Date: Sun, 21 Nov 1999 02:20:17 -0800 (PST)

Brian,

> a standard way that doesn't change when they move from implementation to

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.

I'm trying to find a way for getipnodebyname() and inet_pton()
to recognize scope-ids that keeps everybody happy.  I want these
functions to do that because adding per-application functionality
for this is silly IMHO.  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.

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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: Jim Bound <[email-masked]>
Date: Sun, 21 Nov 1999 14:58:34 -0500

Hi Sam,

>reving the inet-draft as he does to breaking the API).

putting my co-author hat on now for RFC 2553 (not my architect or
implementors view which is much different OK).

Once we agree to the answer that solves the problem at hand we will take
that input and rev another version of RFC 2553.

I think how we know when the answer is completed will help when we get
Carl's write up on the API and Carl is also doing a write up on the
whole scope-id issue and I think Brian has defined that part well.

They we need to make sure all other ideas are dead or we have consenus.

Then I will start writing.

Then I will put out a draft of the changes for this work.

The WG can review it and XNET.

We move forward here.

As an author though I will have to really search hard if we break binary
compatibility and will need vendor input and some market input on such a
decision.

I have already scheduled time in my work load as this will be a task I
bet around January 2000 for me.  I think the discussion and review of
what Carl will do will take this long.

with my rfc co-author hat on only,
/jim