Subject: Re: Regarding site-local addresses

From: Jim Bound <[email-masked]>
Date: Wed, 01 Dec 1999 00:06:06 -0500

Steve,

Per site-locals in DNS:
I did not say there is consensus, if I did I mean't it appears to be
moving in that direction IMO.  The issue is still to-be-discussed.
But if you read the mails you will find people saying they don't belong in
DNS.  Which is what I was reflecting.  

But site-locals now that we are trying to use them in an interoperable
manner are showing pain that we have not worked out standard details
for their use.  We will do that now, whether you get your doc done or not
as time is of the essence as I watch what folks want to do with them.
But your doc would be very timely now and a big help.

As far as the API issue you say:

>I feel badly about not paying more attention to the API specs when
>they were first being written.  I had hoped that the few discussions
>we had during IETF meetings (e.g., the discussions that clarified that
>scope boundaries cut through nodes, not links), would have been
>sufficient to make clear the consequences of scoped addresses on the
>APIs, forwarding rules, routing data structures, user interfaces, etc.,
>but that was wishful thinking on my part.  Clearly some people
>understood these issues at the time, but others have had to spend a lot 
>of time and email discovering them, effort that could have been avoided 
>if I had delivered on my frequent promises to write up what I understood 
>about scoped addresses (something I *still* intend to do).

We understood the issues with RFC2553 but we were faced with moving
forward and there was much discussion about scope_id at that time. The
WG agreed to put a field in sockaddr_in6 till we learned more about
scope_ids.  Any implementer has had to deal with site-local simply
because of RFC 2373 in their implementation.  It is not an issue of
understanding them in that sense at all.  It is a matter of how they
should be applied to the API semantics so they can be used with a
scope_id.  It is serendipity that we have an API fallback with
getaddrinfo which we all must move to now simply because of this issue.
We have Keith Sklower to thank for that all the way back at the
Stockholm meeting I think in 1996, who explained this advantage.
We all understood but we did not all agree on its use with each other.
So don't feel bad about it in that sense we will survive the API
debaucle and fix it quickly.  Those wheels have already started to turn.

From RFC2553:

   The sin6_scope_id field is a 32-bit integer that identifies a set of
  interfaces as appropriate for the scope of the address carried in the
  sin6_addr field.  For a link scope sin6_addr sin6_scope_id would be
   an interface index.  For a site scope sin6_addr, sin6_scope_id would
  be a site identifier.  The mapping of sin6_scope_id to an interface
   or set of interfaces is left to implementation and future
   specifications on the subject of site identifiers.

Everyone you have been listening too except for a few on this discussion
(who are new WG members) saw this in the spec and knew it was there.  But 
we had to move on and it was good we did as the rest of the API parts 
were able to solidify.  It was not because we were clueless, or needed
your guidance that we made this engineering trade-off. It was
time-to-market for this API.

But I would take this issue as caution to you as chair that anything in
IPv6 that changes now that affects the API or user applications will get
more and more painful as we progress.  In 2000 I think we will see
more real products with IPv6 stacks and IPv6 APIs; and continuing to break
them because it was not perceived important on the WG list of issues, 
is not a good strategy for the IPv6 work and we must look at the priority 
as far as work that affects those products.  Just saying thats the risk you 
take is not a very good answer if the IETF expects continued development of 
IPv6 "products" and not just research or early adopter kit efforts.  
Likewise IPv6 deployment, which will require "products".

>I also don't think the lack of a current agreement on how name
>resolution will be done for site-locals represents any sort of major 
>"flaw" in IPv6.

Well put 2373 up for DS and I will make my case to the IESG it is a flaw 
and we can find out?  It is much more than name resolution.  But we are not 
ready for 2373 for DS and I have agreed to move on here and will help fix 
the issues beyond name resolution, which will hopefully make site-locals
work in practice between multiple independent implementations, which is 
also a test for DS.

>The same is true for the notion of embedding a site ID inside a site-
>local address

I don't agree with this at all.  Are you saying we can't work on this
during the effort to resolve how to use site-local addresses?  It could
be a tool we need at the end-of-the-day.  Are you saying or mandating we
cannot discuss proposals to do this on the IPng list as a WG chair,
as we work out site-local address issues or scope-id issues?

I hope not!!!!

Lastly to believe now that what we have done with IPv6 is just a tweak
to the network layer keeping as much of the IP stack in tact may be 
partically true for implementation in stack kernel space (but that was a lot 
of work to make it perform well with IPv4), but is not true at all for
user space.  IPv6 system implementation in user space is far more
complex than IPv4.  So the theory back in the days of the IPng Directorate
that the basis for IPv6 was incremental was not quite true, as it turns
out as I see it, as a note.  Site-Local addresses contribute to that
complexity and against that axiom.

/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: "Brian Haberman" <[email-masked]>
Date: Wed, 01 Dec 1999 08:53:49 -0500

Jim,
     Sorry I have not gotten involved in this discussion earlier.  I want to
point out
that some people have looked at site-local addresses and how they should or
could work.  Erik's draft is a start from the point of view of DNS and I have a
draft that addresses some of the questions in this thread concerning the routing

and forwarding of site-local prefixes.  However, Erik and I have gotten few
comments on the drafts.  The idea in Minneapolis was that Steve, Erik, and I
were going to use these two existing documents as supporting docs for the
architecture that Steve mentions.  I believe that implementors can proceed using

these docs while Steve works on the architecture doc.

Brian

--
Brian Haberman
Advanced Network Research
Nortel Networks
[email-masked]

---

From: Jim Bound <[email-masked]>
Date: Wed, 01 Dec 1999 23:29:00 -0500

Hi Brian,

I recall that you guys were to do this too.  Sounds like we still need
it.

thanks
/jim

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 1999 22:59:30 +0100

In your previous mail you wrote:

   local address.
   
=> I don't know if Christian's idea is good or bad. Current specs
give something like the net 10 in space (same number of subnet than
the 10 class A split into class C chuncks) but there are these
*unused* bits which can reduce collisions (I believe some users
won't resist temptation, perhaps we should give them? :-)

   if I had delivered on my frequent promises to write up what I
   understood about scoped addresses (something I *still* intend to do).

=> still a good idea to do it (mieux vaut tard que jamais :-)
   
   I must disagree with Jim that there is WG consensus that site-local
   addresses must never appear in (any part of) the DNS.  Too few people
   have commented on that, and there is insufficient agreement among those
   who have commented, to conclude that there is any such consensus.

=> I agree there is no consensus today for a "must not" but I don't
know if we can get one soon for a "should not".

   I can well imagine that name resolution for site-locals would best be
   handled by DNS servers within each site, and I think it is far too
   premature to rule that out.
   
=> I am for a "should not" because:
 - it is simpler to have only globals in DNS and there is no real needs
   for site-locals in DNS (ie. this part of Erik's proposal seems to
   work without major issue).
 - DNS is always the wrong tool when location (here be in/outside a site)
   is involved. I strongly dislike two headed animals!

Thanks

[email-masked]