Subject: RE: Textual Address Change for Scope-IDs

From: Tim Hartrick <[email-masked]>
Date: Mon, 22 Nov 1999 10:34:04 -0800 (PST)

Brian,

> 
> 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?
> 

Well it didn't really happen that way.  The working group rejected embedding
the interface identifier in the addresses but those opposed to the embedding
didn't really make a counter proposal on how to deal with the inherent ambiguity
of this address type.  There were at least a couple implementations at the
the time that were using this trick but were actually transmitting the bits
on the wire.  Once the working group decided not to do the embedding the
implementations stopped putting the bits on the wire.  At the time, all of
the discussion really centered around link/interface identification.  Nobody
had really been paying attention to the site-local address issue.

Some number of IETFs later (I think the second LA?) there was a long drawn
out discussion about how site local addresses were supposed to work.  There
was a camp which insisted that the site boundaries should go through links
so that we could avoid the inherent ambiguity which would result if site
boundaries went through nodes.  The other camp argued that it was more natural
to have site boundaries go through nodes even though this caused multi-sited
ambiguity.  The link boundary folks lost the day (I was in this camp).

It was after this discussion that I started to think that it was essential
that we come up with a standard API mechanism to deal with the interface and
site ambiguity issue.  I wasn't the first to think this.  The KAME (then WIDE)
folks had broached the subject quite a while before.  The working group just
didn't get it at the time.

Now the arguments that killed the embedding solution were largely akin to the
arguments we are seeing now.  There was also a general unhappiness with
attempting to identify links with some bits "stolen" from the middle of the
address.  Since these bits are only meaningful within the node, putting them
on the wire was frowned upon.  I am having trouble summerizing the arguments
made by the opponents.  This is for a couple of reasons.  First, at the time
I was arguing the other side and second most of this argument occured at an
IETF meeting.  I can't recall which one so I can't provide a pointer to the
minutes.  It was one of the San Jose meetings I think.

I am sure I have some of the facts and chronology incorrect but that is the
best I can do without looking through archives and minutes.

In any event, at this point I am opposed to trying this embedding idea.  We
have the tools we need to solve this problem without stepping back in time
three years.  In retrospect I believe that I was wrong to favor this em-
bedding approach at that time.  It is a quick and dirty way to make a multi-
homed node work but it is (no offense intended) a hack.  We can make things
work without embedding scope information in the addresses and without breaking
existing binaries anymore than they are already broken.  We should just do that.

Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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: Christian Huitema <[email-masked]>
Date: Mon, 22 Nov 1999 16:45:49 -0500

I have always considered the "site address" an atrocious leftover of Net
10, and the more I see this discussion unfolding, the stronger my
conviction. I can swallow the unidentified link address -- such address are
necessary for autoconfig. But I have a very hard time trying to understand
what exactly is good in the site address format:

1) It does not exactly simplify autoconfig, since one has to program some
form of site identifier in the nodes, 
2) It cannot be stored in a directory,
3) It should not be routed, but then it has to be propagated for the needs
of mobile nodes,
4) It is very hard to handle in multisited nodes.

It seems that allowing some actual identifier, or magic number, or
whatever, in the uppermost bits of the site addresses would go a long way
towards solving the problem. Consider an address form of <standard
prefix><site-id><link-id><host-id>, where "site-id" is a flat binary
identifier:

1) It can be autoconfigured through router advertisements,
2) It can be stored in the DNS, and the hosts can easily be instructed to
only use an address of this format if the "site-id" matches one of the
sites to which they belong,
3) Routers can easily be instructed to only forward the site id that they
recognize, and to ignore all other ids, thus limiting possible leakage,
4) Multi-sited hosts can use classic routing techniques to direct
site-addressed packets to the most appropriate interface, or tunnel.

It may be too late to get rid of the site-id entirely. But we could very
well start experimenting with the insertion of magicg numbers in the
structure, or maybe with an alternate address format.
-- Christian Huitema

---

From: Jim Bound <[email-masked]>
Date: Mon, 29 Nov 1999 12:43:47 -0500

Christian,

>what exactly is good in the site address format:

I agree 100%.

>form of site identifier in the nodes, 

Exactly.

>2) It cannot be stored in a directory,

Exactly.

>3) It should not be routed, but then it has to be propagated for the needs

Exactly.

>4) It is very hard to handle in multisited nodes.

Exactly.

Also as a network implementor for over 15 years I am feeling deja vu
(been here before) here.  I recall having to implement and make a
protocol work that had unknowns and not-well-defined features that
affected applications (thats the key if it affects applications) that
architects thru over the wall to implementors and it was also one of the
proposed IPng solutions back in 1994.  The horrors of this to the APIs
and apps caused this prootocol to never reach the market on any wide
scale.  The architects defined a neat idea (in their mind) but never
really waited to see if it would work in practice.  

IPv6 can work but I strongly urge you to help me and anyone else shoot
these site-local addresses in the head.  We have enough global address
space with IPv6 that we can re-create a Net-10 within the IPv6
exponential number of addresses.

As far as renumbering the only way to solve that is develop further
addrconf and router-renumbering and get folks to stop hard coding
address semantics in configuration files via sys admins.  IPv6 can be
extended to do this and this is a wonderful part of our basic
architecture.

I consider site-local addresses as bad as variable address lengths and
we did not permit them in the architecture.

>prefix><site-id><link-id><host-id>, where "site-id" is a flat binary

If we make it part of the actual address that is a differnt discussion I
think.

>1) It can be autoconfigured through router advertisements,

Yes it can.

>sites to which they belong,

Yes it can.

>recognize, and to ignore all other ids, thus limiting possible leakage,

Yes they can.

>site-addressed packets to the most appropriate interface, or tunnel.

Yes they can.

>structure, or maybe with an alternate address format.

I don't think its too late to shoot them in the head at all.

But if we cannot I think any discussions of using them in the real world
are premature until we define how they can be used.

Its an idea that has not been discussed and parsed enough to be used in
practice.

/jim