Subject: FW: Consensus on Site-Local Addressing

From: "Tony Hain" <[email-masked]>
Date: Thu, 10 Apr 2003 10:31:47 -0700

Bob &  Margaret,

As I noted to Thomas a few moments ago, I have already raised concerns
about the initial action of calling the ambiguous question. I believe
his response indicates I also need to raise a concern with you about
this specific action of declaring consensus. As the content of the note
below indicates, there can be no consensus because the question was not
clear. At best, this activity shows a desire to change the status quo,
but it does not and can not indicate anything else. The consensus
declaration must be voided. 

As I note below, steps 4) & 5) indicate work that the group believes we
should take on. *If* the result of that work leaves us with no further
use for the current definition for an ambiguous address space, then in
that context I believe steps 1) & 3) are appropriate. Until then they
are not, and are very likely to create chaos, particularly if done
before 4) delivers complete alternatives.

You must void the declaration of consensus, and should recognize that
the original question was not clear. 

Tony

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tony Hain
> Sent: Wednesday, April 09, 2003 5:42 PM
> To: 'Thomas Narten'; 'Erik Nordmark'
> Cc: [email-masked]
> Subject: FW: Consensus on Site-Local Addressing
> 
> 
> Thomas & Erik,
> 
> Please consider this the second step in the appeal process, 
> as I have already discussed these issues with the chairs on 
> more than one occasion. 
> 
> 'we reject kings, presidents and voting...'
> The consensus measurement on the mail list was much more 
> indicative of the real lack of it (60/40%), than what was 
> effectively ballot stuffing by WG visitors without a complete 
> context. There was a very short presentation in the apps open 
> area, intended to raise concerns and incite involvement, were 
> those in the apps area were agitated, then invited to the 
> IPv6 WG session in SF to discuss the potential issues. The 
> subsequent short discussion in the IPv6 WG showed there were 
> issues to work through, and at least one question voiced 
> about understanding the requirements. Rather than deal with 
> the issues raised, the chairs decided to call an ambiguous 
> question of yes/no for deprecation. 
> 
> While the chairs do in 2) recognize their interpretation of 
> the consensus that the WG will investigate other forms of 
> local addressing, there is no mention of ambiguity and the 
> rest of the wording of 1) & 2) can be interpreted as local 
> scope addressing is deprecated. The concern is that we will 
> end up with a document lacking local scope addressing, and 
> claims that we had consensus to remove local scope from the 
> architecture. Many of those who bothered to state why they 
> were expressing a yes opinion claimed ambiguity was the 
> reason, while others were only interested in removing special 
> handling for local scope addresses. Those are technically 
> different issues, so they need different questions. What we 
> have is an indication that many are unhappy with the status 
> quo, but a lack of recognition that the call ended up 
> combining yes opinions for removing ambiguity with yes 
> opinions for removing local scope addresses from the 
> architecture. From subsequent discussions with the chairs, it 
> is clear that was not their intent, but never the less that 
> is the result of the lack of clarity in this consensus call.
> 
> '... we believe in rough consensus & running code' & from the 
> Tao : 'running code wins' On several related mail threads 
> there were many comments about running code, and at least 
> Brian Zill & Brian Haberman said they collectively had host, 
> application, and router implementations of the current SL 
> running. Point 3) even acknowledges there are existing 
> implementations. This consensus call intends to invalidate 
> the running code, and all we have to replace it is a promise 
> in 4) that if the group can ever agree that operational 
> requirements of the site network manager are worth solving, 
> we might start to work on solutions, subject to appropriate 
> charter updates. This whole discussion is based on the 
> argument that some developers couldn't create running code 
> for an arguably bogus scenario where topology locators are 
> blindly passed outside their scope of relevance. Bias was 
> given to the opinions of those with a lack of running code, 
> at the expense of, and with the specific intent of 
> invalidating the code that exists.
> 
> There were also claims in the meeting and mail threads that 
> we have analyzed site local as currently defined, and it 
> doesn't meet the requirements. At the same time, there is a 
> recognition by many of the same people that we need to 
> develop a complete set of requirements. It should be obvious 
> that the analysis is flawed if the complete set of 
> requirements are not understood first. To that end, and in 
> the spirit of making progress, 
> draft-hain-ipv6-sitelocal-00.txt was processed by the I-D 
> editor on 4/8, and is offered as an attempt to document the 
> requirements for address space with a local scope of 
> relevance. It is clearly incomplete, and largely based on my 
> previous email on the subject. 
> 
> While I contest the claim that the Yes/No opinions expressed 
> measured consensus for a consistent interpretation of what 
> 'deprecate site local addresses' means, I do believe that a 
> set of work items for the group were identified. It is also 
> clear that we can add new work to a group at any time, 
> without the need to remove existing items first. I agree with 
> the chairs that items 4) & 5) are valid outcomes of the 
> subsequent discussion, though one thing that their 
> interpretation of the result does not make clear is the 
> meaning of 'accomplish the following things in parallel:'. In 
> talking to the chairs it appears the intent is to start the 
> work at the same time, but we need to avoid invalid 
> transition states, so parallel needs to mean that all 5 are 
> to be forwarded to the IESG at one time. In particular, 
> without solutions to the requirements in hand, any documents 
> for 1) & 3) that intend to deprecate the only local use 
> address space will simply create chaos, and might need to be 
> rescinded if the complete set of requirements shows a need 
> with no other technical approach.
> 
> In short, I do not believe the consensus call measured the 
> opinions that were consistent the chairs interpretation of 
> the question, so the claimed results are invalid. I do 
> believe that the effort identified work items 4) & 5), with 
> the potential that 1) & 3) might follow if there are no 
> outstanding requirements for ambiguous address space. I 
> question the wisdom of 2), but will reserve judgment until 
> the complete text identifying further work is spelled out. In 
> any case, I hope this appeal can be dealt with at this level, 
> and that the overall effort results in an expedited charter 
> update. It is imperative that new approaches exist prior to 
> removal of the current, and there is a very real danger that 
> the current destructive energy will dissipate in the face of 
> the hard work of creating replacements.
> 
> Tony
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Bob 
> > Hinden & Margaret Wasserman
> > Sent: Wednesday, April 09, 2003 3:11 PM
> > To: [email-masked]
> > Subject: Consensus on Site-Local Addressing
> > 
> > 
> > Hi All,
> > 
> > Well, that was fun!  :-)
> > 
> > All told, there were over 200 responses to the consensus 
> call on IPv6
> > site-local addressing, approximately 3-to-1 in favor of 
> > deprecating IPv6 
> > site-local unicast addressing.  The final count (including 
> > the room and the 
> > mailing list) was:  155 YES, 56 NO (211 Total).
> > 
> > There were also a significant number of the people on both
> > sides of this 
> > issue that voiced (in their original responses, or in 
> > subsequent messages) 
> > a strong belief that we should investigate alternative 
> > mechanisms for local 
> > addressing and local access control.
> > 
> > The chairs have read all of the messages on the list, and
> > based on your 
> > considerable input, we have determined that the IPv6 WG does 
> > have rough 
> > consensus to deprecate the usage of IPv6 site-local unicast 
> > addressing AND 
> > to investigate alternative mechanisms for local addressing 
> > and local access 
> > control.
> > 
> > In particular, the IPv6 WG will work to accomplish the
> > following things in 
> > parallel:
> > 
> >    (1) Publish an informational document that explains the issues
> >        encountered with site-local addressing and our reasons
> >        for deprecating IPv6 site-local unicast addresses.  This
> >        document will officially deprecate site-local addressing.
> > 
> >    (2) Remove site-local unicast addressing from the IPv6
> >        scoped addressing architecture I-D, and publish the
> >        parts of the document on which we do have consensus
> >        (i.e., link local addresses, multicast, etc.).  This
> >        will include a note that the IPv6 working group is
> >        investigating other forms of local IPv6 addressing and
> >        that the usage of any new forms of local addresses will be
> >        documented elsewhere.
> > 
> >    (3) Update the IPv6 addressing architecture to indicate that the
> >        usage of the FECO::/10 prefix for site-local addressing is
> >        deprecated.  To maintain backward compatibility with existing
> >        implementations the prefix should be reserved and should not
> >        be allocated for other purposes.
> > 
> >    (4) Define and publish the requirements for a local addressing
> >        mechanism to provide:
> >          - Addresses for disconnected networks.
> >          - Addresses for intermittently connected networks.
> >          - Addresses that support merging of sites.
> >          - Stable local addresses for changing ISPs without
> >            disrupting local communication.
> >        Once we have consensus on the requirements, the IPv6
> >        WG will work on solutions for local addressing that
> >        meet those requirements.
> > 
> >    (5) Define and publish the requirements for a local access
> >        control mechanism, then work on a solution that meets
> >        those requirements.
> > 
> > Each of these new work items will need to be added to the
> > IPv6 WG charter 
> > and will go through the normal IETF document processes.  For 
> > (4) and (5) it 
> > is important to make the rest of the IETF community aware 
> > that the IPv6 WG 
> > is undertaking these tasks, so we will consider methods to 
> > invite wider 
> > review and discussion of these problems.
> > 
> > IPv6 site-local addressing has been a contentious issue in
> > the IPv6 WG for 
> > some time, and we are both glad to see the WG reach 
> consensus on this 
> > issue.  This will allow us to complete and publish the IPv6 scoped 
> > addressing architecture document, an important part of the 
> > IPv6 specification.
> > 
> > We hope that people on all sides of this issue will respect 
> the rough
> > consensus of the WG, and will work with us to achieve the 
> > goals outlined above.
> > 
> > Thanks to everyone who expressed an opinion during this discussion.
> > 
> > Bob Hinden & Margaret Wasserman
> > IPv6 WG Chairs
> > 	
> > 
> > --------------------------------------------------------------------
> > 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]
> > --------------------------------------------------------------------
> > 
> 
> 
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Fri, 11 Apr 2003 16:24:16 -0400

> the original question was not clear. 

Tony,

that's absolute rubbish.  the question was crystal clear.  different
people may have had different reasons for the way they made individual
decisions, but that doesn't mean that the question was ambiguous.

what should be recognized instead is that site-locals have never been
clearly defined - there were too many unsolved problems with them that
were written off by just handwaving. once people took the trouble to
enumerate the unsolved problems, it became clear that they were
unworkable.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 18 Apr 2003 09:05:57 -0700

Keith Moore wrote:
> that's absolute rubbish.  the question was crystal clear.
> different people may have had different reasons for the way 
> they made individual decisions, but that doesn't mean that 
> the question was ambiguous.

It does when the individual reasons were for vastly different
architectural concepts. In particular when one of the more popular
reasons is about removing local scope from consideration. Declaring
local scope to be deprecated has just as much affect on reality as
declaring the earth to be flat, or that there will be an end to rain in
Seattle. The filtering that local network managers do and will continue
to do creates addresses with local scope. All the votes for removing
local scope must be considered void.

> 
> what should be recognized instead is that site-locals have
> never been clearly defined - there were too many unsolved 
> problems with them that were written off by just handwaving. 
> once people took the trouble to enumerate the unsolved 
> problems, it became clear that they were unworkable.

The real hand waving going on here are the BS claims that all problems
will go away if we only get rid of the current SL definition.
Particularly when it is recognized by many of the same people that we
don't have a complete list of the requirements for a replacement. From
what I can see, the current SL is the only approach that can meet a
requirement for a site to have completely stable self-controled address
space, and the routing community requirement that any non-PA mechanism
have an absolutely enforceable mechanism to prevent that space from
showing up in the global routing system.

Tony

---

From: Eliot Lear <[email-masked]>
Date: Fri, 18 Apr 2003 10:53:34 -0700

> local scope must be considered void.

This statement is false on its face.  Much of the filtering network 
managers do has nothing whatsoever to do with IP addresses and has to do 
with interfaces and ports.  Certainly any network manager that filters 
on source address is asking for a snoot full of trouble.  Network 
managers that filter on destination address do so with an interface in 
mind.  And in general even if they filter on destination address they 
ALSO filter on part.  Like it or not, that's the real world.

Eliot

---

From: Keith Moore <[email-masked]>
Date: Fri, 18 Apr 2003 13:55:00 -0400

> All the votes for removing local scope must be considered void.

In other words, whatever you think means more than what the clear
consensus of the group thinks. 

> will go away if we only get rid of the current SL definition.

we already know what that world is like from experience with IPv4.  It
doesn't solve all problems, but introduction of scoped addresses causes
far more problems than it solves.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 18 Apr 2003 15:12:54 -0700

Keith Moore wrote:
> It doesn't solve all problems, but introduction of 
> scoped addresses causes far more problems than it solves.

I would like to understand how many people that voted YES on the
question of deprecating SL concur with Keith's assertion.

Tony

Note: I cc'd the IETF list to catch those who may have been in the room
in SF, but aren't on the IPv6 list.

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 18 Apr 2003 16:54:43 -0700

Dave Crocker wrote:
> let me turn it around:

Not at this time. I am looking for a simple yes/no answer to a simple
question:
How many people that voted YES on the question of deprecating SL concur
with Keith's assertion.
KM> It doesn't solve all problems, but introduction of
KM> scoped addresses causes far more problems than it solves.

Tony

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 19 Apr 2003 16:28:30 -0500

Thus spake "Keith Moore" <[email-masked]>
> > Nothing of the kind.   1918 addresses were created because there
> > was demonstrated demand for stable local use only addressing.
>
> 1918 addresses were created because there was a need for isolated
> networks to be able to get address space, and having them pick space
> at random was believed to be problematic.

Perhaps that's why we allocated those addresses, but that's not the most
common usage anymore; IP networks not connected to the Internet have become
vanishingly rare.

Today, sizeable numbers -- perhaps even the majority -- of residential
broadband and corporate users sit in RFC1918 space behind NATs.  This is not
a small mess you can wipe under the carpet and ignore.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 17:27:13 -0400

>   | Unbfortunately, I don't see where the biggest problems with 1918
>   | addresses were cleaned up for site-local.
> 
> Two aspects.   First, they're clearly of local use (defined in the 
> architecture), hence if they do leak, at least it is obvious what is
> happening.

right.  but the anticipated use was such that if 1918 addresses leaked, this
would be treated as an indication of an error - namely that a non-isolated
network was connected to the Internet - and that the correction would be to
renumber the formerly isolated network.  the intent of 1918 was to enable
correction of the error of giving a non-isolated network non-unique address
space, not to encourage that error to the point that it became common
practice (as has happened).

>   | The problems with 1918 space were well understood at the time:
>   | 
>   |    A major drawback to the use of private address space is that it may
>   |    actually reduce an enterprise's flexibility to access the Internet.
> 
> Is not true for site locals, as no-one anticpiates that a SL address is
> all an enterprise will be using (unless it is not connected to the
> internet, in which case questions of its flexibility of access don't arise).

on the contrary, having an enterprise use both SLs and globals creates
significant new problems of its own, and results in even less flexibility
than if SLs were used only by isolated networks.

> Similarly:
> 
>   |    Once one commits to using a private address, one is committing to
>   |    renumber part or all of an enterprise,
> 
> is not true of SL addresses, as one doesn't "renumber" them, one just
> augments with a global address.

this is a bug, not a feature.

> You may notice that it isn't *just* site locals that provide the cleanup
> here, it is the whole IPv6 architecture, considered as a whole.   That
> includes having multiple prefixes announced to nodes, 

multiple addresses at a node were available in IPv4, but the problems
associated with doing this have never been solved, not even in IPv6.  so while
having multiple prefixes per node is clearly useful for renumbering, it's not
at all clear that this is a "cleanup" to the IP architecture.  it's more
complexity that has to be dealt with.

>   |    Another drawback to the use of private address space is that it may
>   |    require renumbering when merging several private internets into a
>   |    single private internet.
> 
> This one was certainly true of the original site local ("may require").
> (Only may because it all depends on how the merge gets done, and the
> actual subnet numbers).   Now that site locals have been extended to use
> fec0::/10 instead of fec0::/48 it is much less likely (but still not
> impossible).

depends on how subnets are allocated.  my guess is that sites are more likely
to allocate subnet bits from left to right, rather than allocating from the
right and picking the leftmost subnet bits at random - so that collisions are
still likely whenever sites merge. 

> No, this is exactly the kind of thing that was considered in the SL design.

unfortunately, many important considerations were ignored in that design.

Keith

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 19 Apr 2003 16:13:48 -0500

> >   | site local is, in fact, an addition to the IP architecture and
> >   | that is what is causing the controversy.
> >
> > No, it isn't.   It is a cleaned up replacement for 1918 addresses.
>
> which by itself is reason enough to kill it.

I detest NAT and private addresses nearly as much as you do, but the simple
matter is that many, if not most, people are going to continue using these
technologies with IPv6 whether the IETF standardizes it or not.

Today, NAT is a solution to political and business problems, even if IPv6
fixes the technical problems NAT was originally invented to solve.  The IETF
cannot eliminate these political and business problems by fiat, nor can it
prevent vendors from selling IPv6 NAT devices.

You are fighting the good fight, but you will surely lose nonetheless.

S

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 17:42:56 -0400

> common usage anymore; IP networks not connected to the Internet have become

so we should move 1918 to Historic.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 19 Apr 2003 17:13:55 -0500

Thus spake "Robert Elz" <[email-masked]>
> For internet access, a global address is used.   Sites (and hosts) have
> both.

I had always planned on using only SL addresses within the enterprise, and
then NATing those SLs to public addresses at the ISP.  That way, none of the
enterprise network is polluted with (frequently changing) global
addresses -- just like common IPv4 practice today.

To assign more than one address to every host means the host must have an
intelligent means of deciding which address to use.  I don't trust the hosts
(either OS or the user) with that decision any more than I trust them with
QOS.

S

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 17:42:21 -0400

On Sun, 20 Apr 2003 04:22:20 +0700
Robert Elz <[email-masked]> wrote:

>     Date:        Sat, 19 Apr 2003 16:59:21 -0400
>     From:        Keith Moore <[email-masked]>
>     Message-ID:  <[email-masked]>
> 
>   | 1918 addresses were created because there was a need for isolated
>   | networks to be able to get address space, and having them pick space
>   | at random was believed to be problematic.
> 
> Yes, and nothing has changed.

wrong.  we know now that 1918 addresses created a big mess.  and nothing about
IPv6 use of SLs reduces that mess.

> If you (and/or the WG as a whole) can come up with a replacement that is
> better than site local, and meets the objectives, that's fine.  Until then
> don't destroy what we have now, which works now (as in, in in day to day use
> now).

no, you have it backwards.  SLs destroy the utility of IPv6.

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 16:59:21 -0400

>   | > No, it isn't.   It is a cleaned up replacement for 1918 addresses.
>   | which by itself is reason enough to kill it.
> 
> Nothing of the kind.   1918 addresses were created because there was
> demonstrated demand for stable local use only addressing.  

1918 addresses were created because there was a need for isolated networks to
be able to get address space, and having them pick space at random was
believed to be problematic.

> Nothing
> has changed in the Internet to cause that demand to go away.

what has changed is that we now have experience with RFC 1918, and we know now
that it is far more of a mess than was anticipated.

---

From: Robert Elz <[email-masked]>
Date: Sun, 20 Apr 2003 04:49:44 +0700

Date:        Sat, 19 Apr 2003 17:27:13 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | not to encourage that error to the point that it became common
  | practice (as has happened).

Usage alters to meet the demands of the users.  That's nothing new.

  | on the contrary, having an enterprise use both SLs and globals creates
  | significant new problems of its own, and results in even less flexibility
  | than if SLs were used only by isolated networks.

Nothing that IPv4 doesn't have as well (if perhaps less commonly).

  | multiple addresses at a node were available in IPv4, but the problems
  | associated with doing this have never been solved, not even in IPv6.

True.   But it is still used regardless.   There are unsolved problems
should be a challenge, not something to fear.

  | so while having multiple prefixes per node is clearly useful for
  | renumbering,

Yes - but more than that - as long as addresses reflect topology, multiple
addresses are the only way to have multiple topological attachments,
aren't they?

This is seen both in a host that is connected to two LANS, and an organisation
that has two ISPs.

So, unless there's some routing revolution, you're just going to have
to learn to deal with multiple addresses, and unless LL addresses go
away, you're also going to have to deal with scoped addresses.

  | so that collisions are still likely whenever sites merge. 

I think I'd say possible, rather than likely.   But of all the problems,
this is the one that bothers me least - sites aren't required to merge
after all (when that does get to be a requirement, it is likely that
far more significant changes are made than just "let those two sites have
unified site local addresses).   After all, you want to abolish the things
completely - if it would be acceptable to not have them (and do remember,
no organisation is going to be compelled to use them) then worrying about
how to unify if they do exist them can't be high on anyone's agenda can it?

That is, merging site locals would only be an issue of site locals are
actively being used - if they're useless, and problematic, as you're
claiming, then surely people won't be using them (the "I can't get enough
address space" excuse for using 1918 addresses won't exist after all).

If no-one uses them, merging won't be a problem, and nor will any of the
other issues you see, surely?

So, if you're worried about this, then you must be assuming that they
will in fact be used - which to me means, that you can see that there is
actually a demand for something to solve the problems that (apparently)
only SL addresses currently can do (that's obvious, as if there was some
other available solution, then people would use that, rather than these
problematic SL things, wouldn't they???)

So...

  | unfortunately, many important considerations were ignored in that design.

Let's see your design that handles the issues that you must agree that the
users need solved, and which actually takes note of all of those other
considerations.

Until we have that, and agree that it is a better design, let's just agree
that there really is no choice - we either keep SLs in the design (however
far from absolute perfection that actually are) or the users will invent their
own variations, in a thousand different ways - which I really can't believe
that you consider a preferable answer.

kre

---

From: Robert Elz <[email-masked]>
Date: Sun, 20 Apr 2003 03:41:37 +0700

Date:        Sat, 19 Apr 2003 15:23:23 -0400
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | Unbfortunately, I don't see where the biggest problems with 1918 addresses
  | were cleaned up for site-local.

More importantly ...

For internet access, a global address is used.   Sites (and hosts) have both.

Similarly:

You may notice that it isn't *just* site locals that provide the cleanup
here, it is the whole IPv6 architecture, considered as a whole.   That
includes having multiple prefixes announced to nodes, and the ability to
seemlessly add new ones.

Some kind of global assignment policy for those 38 bits would fix this,
but adds the costs of managing such a scheme.

  | Unfortunately, people seem to want to forget about those two paragraphs.

  | I'm afraid that unless site-local includes a 'MUST renumber' requirement
  | for *BOTH* cases, it's a complete and total non-starter in my book.

IPv6 requires renumbering when an address that has been used is no longer
appropriate (which will generally be because of changed topology, which
may be local topology changes - moving a host to a different LAN, or global
ones - connecting to a different provider).   That is the only reason.
As long as prefixes remain usable, they can keep on being used, with other
prefixes added as required.

kre

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 20:26:37 -0400

> > I don't have a problem with LL being used for a few special-purpose things
> > that can deal with it, so long as we don't expect LL to work for all or
> > even most apps.
> 
> that is a big change in the IPv6 architecture. 

anyone who ever thought that scoped addresses were generally applicable was
deluded.

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 19:15:07 -0400

>  Site local addressing in IPv6 is a concept which has been 
> mentioned in RFC 1884, 2373 and 3513, the progression of Proposed 
> Standards. This is a string of documents dating back to 1995. For eight 
> years this concept was apparently considered a good thing. 

it is indeed unfortunate that it took several years before there was serious
consideration to the impact of site-local on networks, DNS, and applications. 
I view this as an indication of serious failures in our process - IPv6 was
approved (under pressure, it must be said) by the working group and IESG
despite serious technical omissions.  fortunately proposed standards are not
carved in stone, and these particular omissions are easy to fix.

> I'd like to know why it's taken eight years for folks to decide it's 
> bad.

because few serious applications people were in the discussion, and there
wasn't enough review by those people during Last Call.  most apps people
probably assumed that the changes between IPv4 and IPv6 would be transparent
to them, other than having to use a different size for the address.

also IPv6 took so long getting out the door that it was widely viewed as
on a distant horizon - something that could be dealt with when it finally
arrived (if that ever happened).

> Is it that folks are just now implementing IPv6?

no, but most of the early apps that were ported to IPv6 were two-party apps,
often apps that were used in conjunction with either a v4-v6 translator or
proxy.  many problems with SLs don't show up for these apps; they show up for
multi-party apps.  also, even though there were v6 stacks there were probably
not many early networks that made heavy use of both SLs and globals.

> It is not unprecedented to change or remove a feature as a document 
> advances through the standards track. Such changes, however, can have 
> significant impact on already-implemented and deployed solutions. Such 
> matters should be considered carefully in that light. Perhaps removal of 
> features should receive substantially more scrutiny after publication on 
> the standards track.

I don't disagree.  but surely the months of discussion on this topic qualify
as a substantial amount of scrutiny.  and surely you'd agree that features in
published documents that appear to cause problems should also receive a
substantial amount of scrutiny before advancing those documents?
--------------------------------------------------------------------
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: "Stephen Sprunk" <[email-masked]>
Date: Sat, 19 Apr 2003 19:27:38 -0500

>   | To assign more than one address to every host means the host must
>   | have an intelligent means of deciding which address to use.
>
> Yes, but the amount of intelligence actually needed is pretty minimal.
> (It is actually harder to decide between multiple available global
> prefixes, than to decide between global and site local - the former is
> a difficult problem, the latter is almost trivial).

Agreed.  But the former is a problem nobody has solved after a couple
decades' effort.  Choosing a source address today is a problem only for
dual-homed hosts, which are fairly rare; I see no compelling reason to bring
this afflication to every IPv6 host until the problem is solved.

>   | I don't trust the hosts (either OS or the user) with that decision
>   | any more than I trust them with QOS.
>
> But you do trust them to select a suitable outgoing interface, to pick
> a usable router, and to choose amongst several different possible
> addresses for the destination (over which you most often have no
> control).

Most hosts have one interface, one source address, and one default gateway
(or two that are equally valid).  Recall the KISS principle.

S

---

From: Robert Elz <[email-masked]>
Date: Sun, 20 Apr 2003 05:42:23 +0700

Date:        Sat, 19 Apr 2003 17:13:55 -0500
    From:        "Stephen Sprunk" <[email-masked]>
    Message-ID:  <00d001c306c0$faeadf90$93b58742@ssprunk>

  | To assign more than one address to every host means the host must have an
  | intelligent means of deciding which address to use.

But you do trust them to select a suitable outgoing interface, to
pick a usable router, and to choose amongst several different possible
addresses for the destination (over which you most often have no control).

This all seems rather arbitrary.

Forcing NAT on hosts & users because you're afraid that the OS/app
designers can't tell what's global and what is site local seems rather
heavy handed.   I'm sure glad I don't have to live with your policies.

kre

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 19:20:24 -0400

>   | To assign more than one address to every host means the host must have
>   | an intelligent means of deciding which address to use.
> 

disagree.  the app can choose any global prefix and reasonably expect it to
work, modulo link failures. but when choosing between a global and a site
local the app needs to know whether the site local address will be valid for
the hosts that need to use it, and it has no way to know this.   the app may
also have to choose which interface to use with the site-local prefix,
and it has no good way to know this either.
--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 17:40:32 -0400

> technologies with IPv6 whether the IETF standardizes it or not.

yawn.  I'm tired of baseless assertions.

many of the reasons for using NAT do not apply to IPv6.   if you're going
to use NAT, you may as well use IPv4.  a big reason to move to IPv6 is to
get away from the problems that are caused by NATted IPv4 networks.

Keith

---

From: Robert Elz <[email-masked]>
Date: Sun, 20 Apr 2003 05:22:37 +0700

Date:        Sat, 19 Apr 2003 17:51:19 -0400
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | So if it's expected that both global and site-local addresses are available,
  | why are we bothering with making things more complicated?

Because we need stable addresses for local use.

Something tells me you've never actually lived in an environment where your
global address changes moderately frequently.   If you had, you wouldn't
be so quick to ignore this need.

  | That's exactly *why* they're broken - if you've suddenly had a global
  | address show up, there's now a danger of leaking a local address, so it's
  | not safe to use site-local anymore.

What is the danger here, and why do I, the user, care?   What I know is
that I want me local communications to just keep on working smoothly,
whatever happens to external connectivity and the addresses I get from
there.

  | Well.. all you need to do to fix this is to make a rule that if a
  | global prefix becomes available, the site-local prefix is no longer
  | appropriate and must be withdrawn.

Can't possibly work.

  | This *still* leaves the problem of using site-local behind a NAT, though.

First, while I can imagine people existing who would be stupid enough to
do that, I find it hard to figure out what their reasoning would be.

But if you assume that there are people (and there most probably are) who
are so sold on the "benefits" of NAT, that they're going to use NAT no
matter how much you show them that there is in fact no benefit at all
(which for a site with an IPv6 global /48, and site locals, is certainly
true) then why would you care what address they're using behind the NAT?
That is, whether it is SL, LL, or some random "global" prefix they calculated
by tossing coins.

I find it almost inconceivable to believe that anyone is deciding the fate
of SL addressing by reference to NAT - that's simply too ludicrous (and sad)
to contemplate.

kre

---

From: Ole Troan <[email-masked]>
Date: Sun, 20 Apr 2003 00:22:00 +0100

[...]

> LL use can and should be reserved for bootstrapping and diagnostics.

LL is used in applications already. e.g LL addresses are commonly used
to address BGP endpoints on exchanges. so unless you suggest to remove
LL addresses (and MPLS VPNs) implementations will need to handle
ambiguous and topologically scoped addresses, even without
site-locals.

/ot

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 19 Apr 2003 19:19:30 -0500

> >   | To assign more than one address to every host means the host
> >   | must have an intelligent means of deciding which address to use.
> >
> disagree.  the app can choose any global prefix and reasonably expect
> it to work, modulo link failures.

Nit: the vast majority of apps today bind to INADDR_ANY (or its IPv6
equivalent), so it's really the OS which is choosing the source address.  If
the app binds a specific source address, it is invariably user-configurable
and thus not an application problem.

> but when choosing between a global and a site local the app needs to
> know whether the site local address will be valid for the hosts that need
> to use it, and it has no way to know this.

Well, since one can easily determine whether the destination address is SL
or not, picking a source address of the correct class is trivial.

> the app may also have to choose which interface to use with the site-
> local prefix, and it has no good way to know this either.

Ah, but it'll have a different SL address on each interface, so that's no
worse than having multiple global addresses.  The truly interesting case is
connecting to a LL address with multiple interfaces.

S

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 18:35:55 -0400

>   | significant new problems of its own, and results in even less
>   | flexibility than if SLs were used only by isolated networks.
> 

there's a reason that most v4 hosts don't have multiple addresses with varying
scopes - it doesn't work well, and it creates problems for apps.  putting
sitelocals in v6 is trying to impose those problems on all host.

> should be a challenge, not something to fear.

by that logic we should make the architecture as 'challenging' as possible.
personally I think getting the network to work well is enough of a challenge
without adding needless complexity.

> addresses are the only way to have multiple topological attachments,

yes there are other justifications for multiple prefixes.  I think that
overall they are valuable enough that I'm not suggesting that we get rid of
them.  what we need to do is to get rid of the idea that it matters which
address you use.

> address space" excuse for using 1918 addresses won't exist after all).

SLs aren't useless - it's just that their use causes so many problems
that we're better off providing that functionality in other ways.

> problematic SL things, wouldn't they???)

no, it's the other way around - the expectation of using SLs thus far has
pre-empted development of better solutions.  (by your logic the network
already works as well as it possibly can, if a better network were possible
then it would exist, wouldn't it?)

> that there really is no choice - we either keep SLs in the design 

we've already agreed to get rid of them.  it's just that some people are in
denial about that.

---

From: Ole Troan <[email-masked]>
Date: Sun, 20 Apr 2003 01:14:30 +0100

>> to address BGP endpoints on exchanges. 
>
> I don't think of BGP as operating at level 7.

well, BGP uses TCP as transport and most of the implementations I've
seen use POSIX socket API just like any other application. the socket
API needs let the application choose zone, and pick a suitable source
address accordingly.

> that can deal with it, so long as we don't expect LL to work for all or even
> most apps.

that is a big change in the IPv6 architecture. throwing all the cards
up in the air every second year or so (anyone recorded what the
frequency is for old and closed discussions reappearing on the ipng
list?) gets rather trying after a while. perhaps about time to shut
the IPv6 W.G down?

/ot

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 20:36:06 -0400

> equivalent), so it's really the OS which is choosing the source address.

one of the problems introduced by scoped addresses is that this is no longer
sufficient for some kinds of apps.

> If the app binds a specific source address, it is invariably
> user-configurable and thus not an application problem.

or to put it more clearly, the only way an app can choose reasonably
between multiple addresses of varying scopes is to be explicitly configured as
to how to do so.  otherwise, the app has no idea whether one scope or another
is more suitable for its purposes.   any assumptions about whether, for
instance, site-locals are more secure or more stable than globals, or
whether the app will need to communicate with off-site nodes, need to be
explicitly configured.

of course, if the app weren't being forced to choose between addresses of
differing scopes then it wouldn't need to bind to specific source addresses
(no more than v4 apps do), and such configuration would not be necessary.

> or not, picking a source address of the correct class is trivial.

wrong again.  it's not reasonable to assume that the source address will not
be used by off site nodes.  (of course, specific apps can make that
assumption, but the architecture should not)

> worse than having multiple global addresses. 

depends on what is driving the selection -  I don't think it's reasonable
to assume that all interfaces on a host are within a single site.

Keith

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 19 Apr 2003 19:11:28 -0500

> | So if it's expected that both global and site-local addresses are
> | available, why are we bothering with making things more complicated?
>

Any unique global address will work fine for local use, even if you're
disconnected from the Net.  Or do you expect your global prefix(es) to be
withdrawn from hosts every time your upstream connection flaps?

> Something tells me you've never actually lived in an environment where
> your global address changes moderately frequently.   If you had, you
> wouldn't be so quick to ignore this need.

But haven't you heard?  With IPv6, renumbering will be so easy you'll do it
for fun!  </sarcasm>

The pain renumbering is one of the main motivators for NAT today, and I have
yet to see any reason to believe it'll be easier in IPv6.

>   | appropriate and must be withdrawn.

If site-locals and globals are to coexist, the obvious solution is to
specify that when the destination is SL, an SL should be preferred as
source, and likewise for globals.

Of course, that doesn't fix the case where you have multiple globals, or
multiple interfaces.  We haven't figured out how to fix that with IPv4
either, except for specific cases like "backside networks".

> do that, I find it hard to figure out what their reasoning would be.

Avoiding renumbering, avoiding exposing internal identities, etc.

It's all the same reasons you might use IPv4 NAT, with the possible
exception of address shortages.  I know several very large corps that use
legacy class B space inside and NAT to provider-assigned CIDR space
outside -- they're obviously not doing it because of address shortages,
they're doing it for administrative and scoping reasons.

> of SL addressing by reference to NAT - that's simply too ludicrous
> (and sad) to contemplate.

Well, IPv6 NAT proponents expected to use the SL prefix as their private
addressing, so eliminating SL will require another prefix for that purpose.
I don't see any other direct connection, however.

S

---

From: Robert Elz <[email-masked]>
Date: Sun, 20 Apr 2003 01:32:46 +0700

Date:        Sat, 19 Apr 2003 07:07:19 -0700
    From:        Dave Crocker <[email-masked]>
    Message-ID:  <[email-masked]>

  | site local is, in fact, an addition to the IP architecture and that is
  | what is causing the controversy.

  | when we go around making basic additions to an architecture, we should
  | try to be very clear on how it will be used, how it will impact the rest
  | of the architecture, and what the benefits and problems are likely to
  | be.

This "addition" was made years ago.   It is used now.   The only thing
being contemplated now is removing it without providing a replacement.

kre

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 15:13:29 -0400

---

From: Richard Carlson <[email-masked]>
Date: Sun, 20 Apr 2003 13:55:56 -0500

At 02:16 PM 4/20/03 -0400, Daniel Senie wrote:
>At 01:00 PM 4/20/2003, Richard Carlson wrote:
>>At 07:20 PM 4/19/03 -0400, Keith Moore wrote:
>>> have
>>>work,
>>I completely disagree with this assumption.  Firewalls and address 
>>filters mean that no app can make any reasonable assumption.  Some 
>>addresses will work and others will fail.  The app is left with no clues 
>>as to why the connection failed.  Assuming it's just a link failure and 
>>retrying sometime in the future things will work is a receipt for user 
>>frustration.
>>
>>>modulo link failures. but when choosing between a global and a site
>>The decision process is not forced on the app/host by the existence of 
>>the site-local prefix.  It is due to the emergence of firewalls and 
>>address filters.  The reality is that non-global routing scopes exist 
>>today.  The question is - how do we provide some feedback to apps that 
>>they are trying to cross a scope boundary that it's a permanent error 
>>condition (5xx in SMTP verbiage)?  One proposed notification method is 
>>the site-local prefix.  Other methods can be created, but something needs 
>>to be done and simply killing site-locals and ignoring the underlying 
>>scoping issue is a non-starter.
>
>You mean aside from applications understaning that an ICMP Destination 
>Unreachable / Administratively Prohibited response from the site firewall?

An ICMP message is one way of providing this information.  There may be 
others, I don't know by folks are free to develop them.

>For that matter, IPv6 machines arguably could try their Site Local address 
>and be given that same feedback from the border router or firewall, and 
>use the response as an indication to go use their assigned global address. 
>It's not clear to me that the host or application need contain the 
>intelligence (nor is there any way to determine scoping unassisted, IMO), 
>however through use of ICMP responses it certainly should be possible to 
>determine reachability or lack thereof. It may be useful to expand the 
>responses routers and firewalls give to hosts within sites to help 
>accomplish this.
>
>We have the problem of scoped addresses whether the "site local" mechanism 
>is retained or not. Providing guidance on the responses an application is 
>to receive in response to scoping controls (firewalls) would be useful 
>regardless. If this problem is worth solving for the already-common case 
>of firewalls, solving it for site-local addressing does not seem to be too 
>much of a stretch.

Exactly, the only thing an address with a site-local prefix tell me is that 
a filtering router or firewall is guaranteed to be in some arbitrary 
path.  I'm mystified as to why an app would treat it any differently that 
an IPv6 address generated with any other prefix.

Rich

------------------------------------

Richard A. Carlson                              e-mail: [email-masked]
Network Research Section                        phone:  (630) 252-7289
Argonne National Laboratory                     fax:    (630) 252-4021
9700 Cass Ave. S.
Argonne,  IL 60439

---

From: Robert Elz <[email-masked]>
Date: Sun, 20 Apr 2003 04:22:20 +0700

If anything, the demand now is greater than it was when 1918 addresses
were first created, as addresses now are much less stable - 1918 addresses
also fill the role of stable addressing for internal site use.

  | what has changed is that we now have experience with RFC 1918, and we
  | know now that it is far more of a mess than was anticipated.

Which explains some of the cleanups.

But even ignoring that, you cannot just wish the demand away.   One way
or another, the users are going to meet their demands.   If that means
just picking space at random again, that's what they'll do (which will
likely mean that they'll need to use NAT as well, which with SL they don't).

kre

---

From: Keith Moore <[email-masked]>
Date: Sun, 20 Apr 2003 16:22:54 -0400

> The vast majority of applications do not pick their source address, nor is
> there a compelling reason for them to do so. 

not in IPv4.  if IPv6 has site locals more applications will need to do so.

> A large number of applications
> don't even handle multiple destination addresses properly, so expecting this
> additional intelligence for the source address is irrational.

again, you're trying to extrapolate from ipv4 experience to ipv6, but such 
experience isn't necessarily a good indicator when ipv6 presents a more 
challenging environment than ipv4.  then again, if dealing with multiple
addresses for a host was hard in ipv4, it's not going to be easier in ipv6.
--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 20:00:49 -0400

---

From: Keith Moore <[email-masked]>
Date: Sun, 20 Apr 2003 15:10:59 -0400

> and be given that same feedback from the border router or firewall

how does any party - the host, border router or firewall - know whether the SL
address is from that site or some other site?  SLs are inherently ambiguous.

> , and use 
> the response as an indication to go use their assigned global address. 

if the destination has a global address, it should *always* be used in
preference to the site local, at least in the absence of external
configuration.

> is retained or not. 

I disagree, or at least, I think it's misleading to use  the term "scoped
addresses" to cover all filtering, because this is conflating two things - use
of filtering on one hand and use of ambiguous addresses on the other.  It's
useful to be able to refer to a host even if you can't send traffic there.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 18:27:35 -0400

> > may be local topology changes - moving a host to a different LAN, or
> > global ones - connecting to a different provider).   That is the only
> > reason. As long as prefixes remain usable, they can keep on being used,
> > with other prefixes added as required.
> 
> Well.. all you need to do to fix this is to make a rule that if a
> global prefix becomes available, the site-local prefix is no longer
> appropriate and must be withdrawn.

this only solves one of several problems with site-locals, and it removes one
of the few supposed benefits of site-locals - that such addresses will be
stable across prefix changes.
--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Sun, 20 Apr 2003 05:13:26 +0700

Date:        Sat, 19 Apr 2003 17:42:21 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | wrong.  we know now that 1918 addresses created a big mess.

No, we don't know that, because that's incorrect.   1918 addresses
are just numbers, they can't have created the mess.   The mess was created
by the demands of the users that led to the creation of the 1918 addresses.
That is, the mess would still have been there, but worse, had 1918 never
existed.

  | and nothing about IPv6 use of SLs reduces that mess.

I think it does, but even if you're right, the mess is there anyway.
It isn't going away, whatever you do with SLs.

This is just like not liking shit, so you're going to ban the sewer system.
Great plan.

  | no, you have it backwards.  SLs destroy the utility of IPv6.

There's a quote I remember that seems apt, I'm sure someone will
remember who it was said this ...

	"yawn.  I'm tired of baseless assertions."

kre

---

From: Eliot Lear <[email-masked]>
Date: Sun, 20 Apr 2003 06:51:32 -0700

Hi,

Daniel Senie wrote:
> Example of usage: I use RFC 1918 space for private networks within 
> server farms. There's no connection to the public network from this 
> private segment. Servers connect to both public and private networks. 
> Backups, NFS mounts, SNMP and SQL data flows over the private network. 
> The isolated network segment keeps traffic off the public network for 
> performance reasons.

This has become an acceptable use of RFC 1918 addresses.  On the other 
hand, there is no need to support this sort of use in the v6 
architecture.  The address space is simply too vast for people to have 
to economize like this.

> All the world of private addressing is not NAT, regardless of how many 
> times people say it is.

My major concern that does drive NAT is the expressed desire on the IPng 
list to isolate sites from having to renumber.  That use of SLs requires 
NAT or proxy.  Rob may call it crazy, but the demand is there right now.

> I am saddened by the fact that Tony's simple question could not be 
> addressed. Site local addressing in IPv6 is a concept which has been 
> years this concept was apparently considered a good thing. The 
> discussion on the mailing lists makes it sound like site-local 
> addressing is a new idea. I'd like to know why it's taken eight years 
> for folks to decide it's bad. Is it that folks are just now implementing 
> IPv6? Is it because the documents these eight years never made the 
> concept clear, and now it appears too hard to implement? In all those 
> years, has no vendor implemented site local? Are there any other 
> features we should reconsider as long as we're ripping the documents open?

Quite simply it is something we seem to have forgotten about: learning 
from operational experience.  Since 1995 the use of private address 
space has changed, as has been said.  Also, I don't think people fully 
understood the ramifications of SLs.  I certainly didn't, initially.  We 
also learned that using EUI-64s as end identifiers has certain privacy 
considerations, so this is not a first.  I think we do have to take some 
care when making changes to the addressing architecture.  If the 
decision of the group holds, it seems to me that those of us who voted 
"YES" have the burden to now provide an alternative that addresses the 
real requirements that SLs attempt to tackle.

> features should receive substantially more scrutiny after publication on 

I agree.  The vote was for deprecation.  That means we need to deprecate 
in favor of something better.

Happy holidays,

Eliot

---

From: Keith Moore <[email-masked]>
Date: Sun, 20 Apr 2003 15:26:24 -0400

> path. 

but you don't know which paths, so you don't know how to use that.

> I'm mystified as to why an app would treat it any differently that 

some people believe that SLs would be more secure than globals, even though
this is an unwarranted assumption.  some people believe they would  be more
stable than globals, but providing stable local addresses isn't a good
solution to the renumbering problem - it's not as if all of the important
apps affected by renumbering are local.  some people believe SLs would be more
efficient.  some apps writers would avoid using SLs whenever possible because
they're not portable (and they'll lose when SLs are all that are available),
some apps writers will use them in preference to globals (and they'll lose
when they're expected to communicate across site boundaries), and other apps
writers will try to deal with all cases (adding a lot of complexity and still
not able to avoid the app failing for apparently arbitrary reasons). any of
these makes the behavior of apps less predictable.

Keith

---

From: Robert Elz <[email-masked]>
Date: Sun, 20 Apr 2003 03:28:54 +0700

Date:        Sat, 19 Apr 2003 15:13:29 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

Nothing of the kind.   1918 addresses were created because there was
demonstrated demand for stable local use only addressing.   Nothing
has changed in the Internet to cause that demand to go away.

We either provide a mechanism, or the users provide one of their own.

kre

---

From: Keith Moore <[email-masked]>
Date: Sun, 20 Apr 2003 22:13:19 -0400

> b) if there's a strong need for appropriate 
> ICMP responses to make IPv6 function well, then an RFC stating as much 
> could be published.

like, for instance, a need for path mtu discovery to work reliably?
(since v6 routers don't fragment packets)

> >there a compelling reason for them to do so.  A large number of
> >applications don't even handle multiple destination addresses properly, so
> >expecting this additional intelligence for the source address is
> >irrational.
> 
> At which point they might as well just select their global address unless 
> the destination address for a service is site local. This decision could 
> (should?) be in the hands of the IP stack, unless the application 
> specifically asks for such control.

I disagree that the IP stack can supply reasonable defaults in the face of
multiple scopes.  The criteria for choosing a source address varies widely
from one application to another.  Some applications need stable addresses,
others need addresses usable from all of their potential peers, others need to
choose the source address that results in the best performance (where there is
more than one meaning of 'best performance').  The default address selection
rules are at best a guess.  

We should let the network do routing, so that hosts and apps aren't expected
to make routing decisions.
--------------------------------------------------------------------
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: "Stephen Sprunk" <[email-masked]>
Date: Sun, 20 Apr 2003 14:50:00 -0500

Thus spake "Daniel Senie" <[email-masked]>
> >The question is - how do we provide some feedback to apps that
> >condition (5xx in SMTP verbiage)?  One proposed notification
> >method is the site-local prefix.  Other methods can be created, but
> >something needs to be done and simply killing site-locals and
> >ignoring the underlying scoping issue is a non-starter.
>
> You mean aside from applications understaning that an ICMP
> Destination Unreachable / Administratively Prohibited response from
> the site firewall?

Many firewalls simply drop packets which are prohibited without sending ICMP
responses, not to mention all the places that filter all ICMP
indiscriminately.

> For that matter, IPv6 machines arguably could try their Site Local
> address and be given that same feedback from the border router or
> firewall, and use the response as an indication to go use their assigned
> global address.

The vast majority of applications do not pick their source address, nor is
there a compelling reason for them to do so.  A large number of applications
don't even handle multiple destination addresses properly, so expecting this
additional intelligence for the source address is irrational.

S

---

From: Richard Carlson <[email-masked]>
Date: Sun, 20 Apr 2003 12:00:55 -0500

>disagree.  the app can choose any global prefix and reasonably expect it to

I completely disagree with this assumption.  Firewalls and address filters 
mean that no app can make any reasonable assumption.  Some addresses will 
work and others will fail.  The app is left with no clues as to why the 
connection failed.  Assuming it's just a link failure and retrying sometime 
in the future things will work is a receipt for user frustration.

>and it has no good way to know this either.

The decision process is not forced on the app/host by the existence of the 
site-local prefix.  It is due to the emergence of firewalls and address 
filters.  The reality is that non-global routing scopes exist today.  The 
question is - how do we provide some feedback to apps that they are trying 
to cross a scope boundary that it's a permanent error condition (5xx in 
SMTP verbiage)?  One proposed notification method is the site-local 
prefix.  Other methods can be created, but something needs to be done and 
simply killing site-locals and ignoring the underlying scoping issue is a 
non-starter.

Rich

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 18:46:17 -0400

> then NATing those SLs to public addresses at the ISP. 

we can't stop you from screwing up your network.  just don't expect us to
endorse such practices, and don't expect apps to work across your network
boundary.

> That way, none of the

and the network is dysfunctional, just like common IPv4 practice today.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 19 Apr 2003 19:51:54 -0500

Thus spake <[email-masked]>
> There's this big assumption on the part of the pro-site-local crew that
> we "need" a stable address.  I posit that this is a crock, and that
> what we *need* to do is iron out the rough edges of IPv6 renumbering
> so hosts don't care *what* they have, as long as they have *some*
> prefix.

Changing the address on a host's interface is easy -- too bad there's a lot
more involved in renumbering.

For one thing, we need a TCP that can support address changes during a
session, and it can't rely on a deprecation period.  Beyond that, we'll need
widespread deployment of DDNS, which scares the heck out of most DNS admins
I know, with or without PKI.

S

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 18:43:51 -0400

> That is, the mess would still have been there, but worse, had 1918 never

not clear.  as someone pointed out, the intended use case for 1918 has all but
disappeared, so maybe we wouldn't have had such a mess afterall. 

of course we would have had to have some kind of scoped addresses by now
anyway due to the address shortage in v4.  that doesn't justify putting them
in v6.

> This is just like not liking shit, so you're going to ban the sewer system.

well, the damage caused by SLs spreads to every aspect of the network from
apps on down.  so having SLs in v6 is like saying that since we are going to
have shit no matter what we do, we might as well spread it everywhere rather
than try to promote any kind of sanitation.

Keith

---

From: Leif Johansson <[email-masked]>
Date: Mon, 21 Apr 2003 22:29:57 +0200

>to them, other than having to use a different size for the address.
I believe this is essentially correct.

---

From: Randall Stewart <[email-masked]>
Date: Mon, 21 Apr 2003 16:12:52 -0500

> and it has no good way to know this either.

Keith:

I agree 100%.. it is quite difficult to choose a site local... and a
real pain to be able to tell which interface to use or if the
peer host can really speak on that site local.... very very
ugly... and I say this with respect to trying to make things
work in the kame SCTP implementation.. As far as I am concerned
we could do with-OUT site-locals.. but of course I have
said this before too :>

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 21 Apr 2003 14:22:01 -0700

> (since v6 routers don't fragment packets)

This is veering a bit off topic, but in the plpmtud bof at IETF 56
we were shown a method for determining path mtu that does not rely
on ICMPs. (ICMPs are untrustworthy and unreliable in any case, so
let's stop this red herring before it goes any farther.)

Thanks,

Fred
[email-masked]

---

From: Randall Stewart <[email-masked]>
Date: Mon, 21 Apr 2003 16:27:10 -0500

> and thus not an application problem.
Nit2Nit :>

That may be.. but it sure does not help us poor kernel developers any
:-<

> or not, picking a source address of the correct class is trivial.

I don't know if that is true.. if a host has multiple sites
on it and each site is multi-homed... aka

-------Intf-A---+----------+----Intf-D------
                 |          |
-------Intf-B---+----------+----Intf-C------

Say Intf-A/Intf-B are on one site
and
Intf-C/Intf-D are on another site..

Then if the SCTP stack is told to send a INIT -> out to a SL
address on Intf-A selecting the source address is somewhat ok
if the routing is set up.. but what other addresses do I list
in my INIT?

Ideally I would like to list the address for A and B. This way
my peer could take advantage of my multi-homing.. but instead
I can't... since when the peer receives the INIT it would have
no way of knowing the scope for the address and what interface
the address went with...

Other more complicated scenario's can also be imagined with
the above.. multiple sites on each host.. some shared some
not.. aakk... yuck...

It seems to me that with all the available address space having
a SL is just a waste.. If an enterprise is worried about
security put up something that is real aka a firewall.. not a
NAT...It does not really add anything but it does drag
along an ugly abomination that was needed as a stop-gap measure
for the  address shortfall.. Now we have the solution we are
dragging the old junk along.. how silly...

This SL thing seems to me like a un-needed complication..

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 22 Apr 2003 14:32:46 +0200

just to provide a "simple" answer to a simple question:

NO - I do not agree with Keith's assertion as quoted.
YES - I agree with what I *believe* Keith wanted to say, which is that 
"introduction of *site-scoped* addresses causes far more problems than it 
solves".

I do NOT believe that introduction of link-local addresses causes far more 
problems than it solves.

My position on SL should be well known. I'll try to avoid repeating the 
rest of my arguments once again in this discussion tree.

                Harald

---

From: Keith Moore <[email-masked]>
Date: Tue, 22 Apr 2003 09:36:49 -0400

> I do NOT believe that introduction of link-local addresses causes far more 

I see scoped addressing as a general problem, of which v6 site-locals and v4
link-locals are both examples.  That said, I think v6 link-locals as "mostly
harmless" provided that we use them only for things like router discovery.
If we started expecting ordinary applications to be able to use them, I'd move
them back to the "harmful" category - they'd have most of the problems of
site-locals.
--------------------------------------------------------------------
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: Markku Savela <[email-masked]>
Date: Tue, 22 Apr 2003 17:09:14 +0300

[I cleaned up the CC-list, as this reply is techical, not IETF issue]

> From: Randall Stewart <[email-masked]>
> 

I'm not sure I can read above correct. Do you mean (e.g. a node has 4
interfaces as follows?):

----Intf-A---+          +----Intf-D-
             |-- node --|
 ---Intf-B---+          +----Intf-C-

> if the routing is set up.. but what other addresses do I list

Any other SL addresses from Intf-A and Intf-B (and perhaps globals
from any interface, but would prefer always to use only addresses of
matching scopes). If destination is global, you do not include SL
addresses.

> no way of knowing the scope for the address and what interface

Yes, it would. The scope id for the SL's are just picked from the
incoming interface.

Actual values for the id's are totally local to the node, and can be
generated internally. The only external configuration is to tell which
interfaces belong to same site, actual id numbers need never be
referenced by the configuration.
--------------------------------------------------------------------
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: Michael Thomas <[email-masked]>
Date: Tue, 22 Apr 2003 07:32:18 -0700 (PDT)

There seems to be an underlying assumption that
address selection wrt site locals presumes a
policy that site-locals are preferable (security,
reachability...) to globals where the narrower
scopes allow communication.

Is there any reason to believe that this implicit
policy is the only one people will cook up, and
that there won't be other policies in the future?
If not, what are the implications for address
selection?

At some level we need to deal with multiple
addresses due to multihoming, but the
combinatorics when you start adding other kinds of
addresses, scoping, policies, and transience
considerations seems, well, a heck of lot more
complicated that the socket (), gethostbyname(),
and connect() most apps do today.

	      Mike

---

From: Randall Stewart <[email-masked]>
Date: Tue, 22 Apr 2003 09:44:16 -0500

> scopes allow communication.

yep .. one never knows what slick things the users will
want to cook up..

> and connect() most apps do today.

Yep. and even more pain will then come forth for
us poor kernel hackers :-0

You said it a lot more elogantly than I .. as usual
but you are smack on...

R

---

From: Randall Stewart <[email-masked]>
Date: Tue, 22 Apr 2003 09:41:39 -0500

>  ---Intf-B---+          +----Intf-C-

Yep...

> matching scopes). If destination is global, you do not include SL

Yes, if you send to a SL you can include all the globals (for sure). But
you really don't know what SL's to include unless you somehow have
some configuration that tells you what site the interfaces belong to...

This may be a scope variable or some such.. but it is a real pain.. it
can be done.. but a pain...

> referenced by the configuration.

Yes.. in theory one would need to have the SL's configured
in such a way that they had the same scope.. then when
you figure out what interface you are routing out (via the route
table) one could then find the scope_id and hunt back through the
addresses... but this of course is like I said a pain and a lot
of cycles for something I just don't understand the need for..

R

---

From: Markku Savela <[email-masked]>
Date: Tue, 22 Apr 2003 18:00:30 +0300

> From: Michael Thomas <[email-masked]>
> 

Any application using that sequence will continue working as before,
even in presense of SL's.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Apr 2003 08:14:03 -0700 (PDT)

> even in presense of SL's.

Really? I think you're making some pretty large
assumptions about DNS doing the right thing, for
one. And a lot more assumptions about the stack
finishing the job. Not to mention the unstated
assumption that DNS and the stack are the right
places to hide those selection details.

Why should you assume any of this?

	   Mike

---

From: Markku Savela <[email-masked]>
Date: Tue, 22 Apr 2003 18:19:55 +0300

> some configuration that tells you what site the interfaces belong to...

Not really difficult. Each interface includes array of zone ids. If
you are passing multiple addresses now, I presume you have something
like follows:

 for (all interfaces)
    include addresses by some logic;

In scoped architecture, the above would change into

  level = scope_level(destination address);
  destid = destination_interface->zone[level];
  for (all interafaces)
    if (interface->zone[level] == destid)
       include address with "scope >= level";

Yes, somewhat more convoluted, maybe a small pain :-)

> of cycles for something I just don't understand the need for..

All you need is the zone-id vector in interfaces. If destination is SL
with 'site-id', then route search will not match routes that point to
interface with interface->zone[site-level] != site-id. Yes, another
additional "pain" in implementation, but I don't see this too
difficult.

---

From: Keith Moore <[email-masked]>
Date: Tue, 22 Apr 2003 23:12:09 -0400

let me see if I can clarify this by restating it.

1. Apps know best what kinds of services they need.  The network doesn't know
this unless the app has some way of telling the network 
(e.g. TOS/QoS/diffserv/intserv/packet-class flavor-of-the-year).

2. The network knows best where hosts are located, and how to get packets from
here to there (if possible). The network also knows whether it's permitted to
send packets from here to there (perhaps limited by available routes or
policy, perhaps limited by packet filtering).  Most apps don't know these
things and shouldn't have to know them.  However it can be useful if the
network has some way to tell hosts and apps that it's not possible to get
packets from here to there, and the reason for that.  Traditionally ICMP has
fulfilled this role.

Now there are apps that have to know about network topology, such as network
management tools.  But in general we don't want to burden hosts and apps with
having to have this kind of knowledge, because there's no good way to get it
from the network, and to make it work reliably would require requiring the
network to feed routing and policy information to potentially all hosts.

3. Neither the kind of service being requested/provided nor information
about whether traffic is permitted should be wired into an IP address -
First because it forces a binding between policy and/or service and network
location which is inflexible and doesn't scale well; second because it
invites/begs/demands hosts and apps to know about network topology - i.e. to
second-guess the network.

4. Hosts shouldn't have to pick the "right" source or destination address in
order to get the network to do its job of getting the bits from here to there
(for some well-defined "here" and "there"), because hosts don't have the
requisite knowledge to do this, and because a requirement to pick the right
destination address means that addresses don't have a consistent meaning from
one source host to another.  To the extent that a host has to pick the "right"
interface, it needs to be possible to make the right choice from information
that the host normally has at hand (like matching prefix lengths).

Similarly, using address selection as a means to select a particular service
quality, or a particular security level, etc. is a best a stopgap measure 
because once again it requires apps to know about specific address ranges
and/or network topology.  

Note that scoped addresses make it difficult for each of the network, hosts,
and apps to do  their jobs - the network can't tell whether it can get the
traffic to the destination because the destination address is ambiguous (so
for instance, how can it tell the difference between "prohibited" and "no
route to destination" and "no such host" - and while it might have unambiguous
rules for how to route such addresses, that doesn't mean the traffic went to
the right place); hosts can't tell which interface to use to send the traffic;
and apps can't tell whether or not the address is usable to reach the desired
peer (either locally or by another peer).

--

Does any of the above mean that apps should never explicitly select source
and/or destination addresses or interfaces?  No, it means our network
architecture should not expect ordinary apps to make such selections
in order to sucessfully obtain services from the network. 

Now, because of mobile IP and privacy addresses, we're still going to have
situations where apps need to give their hosts an idea of what kinds of
addresses they need.  E.g. Does the app need an address that continues to work
as the host moves, or will the in-care-of address do?  Does it prefer an
address that is stably associated with the host, or is a temporary address
more appropriate?  But the answers to both of these questions *are* things
that the app can be expected to know.  Furthermore, unlike service quality or
security, these things inherently require address selection.  And unlike
site-local, these properties are essentially opaque to other hosts in the
network - thus we cannot expect/demand that other hosts use information
embedded in the address and behave differently for different kinds of
addresses.

And of course it will always be possible to set up or encounter situations
where apps that have knowledge about the network topology (or which
exhaustively try all known source/destination pairs) can succeed where apps
that don't go to extreme measures will fail.  In some ways this is an argument
about how we divide up the burden - which burdens we should place on hosts and
apps and which ones we should place on the network.  And the essence of the 
argument is:  don't expect either one to make decisions about things it
doesn't know about.  And this further argues for not having more addresses for
a host than necessary,  for not using multiple addresses as a mechanism to
provide different levels of access to a host, and for eschewing ambiguous
addresses.

Keith

> > I disagree that the IP stack can supply reasonable defaults in
> > the face of multiple scopes.  The criteria for choosing a
> > source address varies widely from one application to another.
> > Some applications need stable addresses, others need addresses
> > usable from all of their potential peers, others need to
> > choose the source address that results in the best performance
> > (where there is more than one meaning of 'best performance').
> > The default address selection rules are at best a guess.
> >
> > We should let the network do routing, so that hosts and apps
> > aren't expected to make routing decisions.
> 
> Keith,
> 
> I don't understand your point here, and would like to.  It seems 
> to me that your first paragraph ("I disagree...") suggests that 
> the applications need to specify the addresses/interfaces 
> because they know their needs and the stack can't figure it out. 
> And the second argues for pushing the decisions onto the 
> network, which has no information at all (and, if it had it, 
> could probably apply it only by changing addresses mid-flight -- 
> NAT-like or worse).  That suggests to me a conclusion of "not 
> application, not stack, not network either" which leaves very 
> few options.
> 
> If I ignore that apparent contradiction, I'm left with the 
> conclusion that we need some new addressing and routing 
> abstractions so that the applications can tell the stack (and 
> the stack might tell, or negotiate with, the network) what 
> considerations they need optimized and do so without specifying 
> specific addresses or inspecting components of addresses.  It 
> seems to me that such abstractions would also eliminate one of 
> the arguments against site local: having an application able to 
> tell the stack:
> 
> 	* I need a local address
> 	
> 	* I need an appropriate address for routing to <DNS name>
> 	
> 	* I need a completely-global address
> 
> Are all far more reasonable than having the application itself 
> recognize particular addresses or prefixes and trying to figure 
> out which ones make sense in its context.  It also _might_ 
> suggest that we need to reexamine ICMP in the IPv6 context to be 
> sure that, if the stack needs information from the network to 
> make satisfactory choices along these lines, it can ask them 
> without, e.g., trying to set up one or more TCP connections (or 
> sending UDP packet using an unspecified protocol) and waiting 
> for the responses or timeouts.
> 
> Is that really where we need to be headed and, if so, is anyone 
> doing the work rather than being stuck on "local-good / 
> local-bad", "scope-necessary / scope-bad", types of arguments?

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Apr 2003 07:42:08 -0700

Thank you, this was the only simple answer to the simple question. 

For the followup question: 
Do you believe that the IETF created the architectural concept of
addresses with a limited scope?

Tony

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Harald Tveit Alvestrand
> Sent: Tuesday, April 22, 2003 5:33 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: A simple question
> 
> 
> > Note: I cc'd the IETF list to catch those who may have been in the 
> > room in SF, but aren't on the IPv6 list.
> >
> >

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 23 Apr 2003 17:33:03 +0200

> addresses with a limited scope?

no; I believe the community-that-became-the-IETF created the Internet by 
*denying* that concept, which was already well known long before TCP/IP.

Because of the realities of 32 bits of address in IPv4, that denial became 
more and more untenable as the years went by, until RFC 1597 
re-acknowledged the existence of such IPv4 addresses in 1994.

                   Harald

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Apr 2003 10:12:08 -0700

> re-acknowledged the existence of such IPv4 addresses in 1994.

Though IP addresses that were only reachable from a limited part of the
network existed long before 1994. These were implicit through filtering
of routing announcements, or explicit through access control mechanisms.
So to clarify the question, do you believe the establishment of a set of
local use prefixes is the root cause of the unsolved problems that
applications developers are complaining about? 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Apr 2003 12:25:29 -0700

Daniel Senie wrote:
> ... The IPv6 mechanism to give hosts a-priori 
> knowledge that the "site local" block is flawed in that it 
> cannot truly 
> provide the scoping information, since it does not address 
> the wider issues 
> associated with administrative address scoping. 

You assume an outcome ('flawed') without first discussing the full set
of requirements. 

> ...
> There will remain a need and desire for private address 
> space, be that the 
> assigned "site local" block (without the "special treatment" in the 
> stacks), RFC 1918 space, or a combination. I think it would 
> be useful to 
> decouple the issue of the special treatment of the Site Local 
> address block 
> from the religious war over whether private address space and other 
> mechanisms sometimes associated are beneficial or not. In 
> reviewing the 
> recent discussion, it is clear the two are being intertwined, and it 
> appears to be adding to the heat, and producing no light.

I have no argument with discussing them separately, as long as we don't
end up with the usual discussion where it is the private address space
causing the problems. There is a general lack of recognition that
private addresses only exposes the underlying mis-match in the
perceptions of scope. 

> 
> Separately, if there is genuine interest in addressing the 
> scoping problem, 
> I suggest that be addressed separately. 

Reset your clocks to 1995 ...

> A proper effort might encompass 
> mechanisms to deliver indications to applications as to the scoping 
> limitations causing communications to be blocked, as well as 
> wire protocol 
> issues to carry such signalling. 

You assume such signaling would somehow solve the problem of A using a
literal referral to C that Bl is the address it is using, when C can
only see Bg. How is A supposed to know that Bl has a scope limitation
when it can get there without receiving any signaling? How is the
infrastructure supposed to know that A intends to tell C a literal
address rather than a name? If Bl & Bg had indicators of scope
differentiation in the prefix, A could recognize the difference if it
bothered to look. It wouldn't have to, but if it didn't it would either
have to refer the name, or provide C with the entire list so it could
figure out which one works. Brian's C000 thread was exploring this
space. 

> In a broader sense, there is a need to 
> deal with signalling issues as well. There are network 
> operators, firewall 
> vendors and network administrators who've been taught ICMP 
> packets are 
> inherently dangerous and must be filtered. The work output of 
> such efforts 
> should span the Internet Area producing standards track documents to 
> specify how to properly implement mechanisms in hosts, routers and 
> firewalls, and the Operations Area to provide BCPs giving guidance to 
> network administrators and service providers on the 
> operational needs of 
> such issues.
> 

I agree education is appropriate. Part of that is educating the
application development community that the real network has addressing
with limited scopes of relevance, so blindly assuming a flat routing
space and passing around topology specific information will result in
broken apps.

Tony

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Apr 2003 15:26:07 -0400

> I would be thrilled if we spent some time thinking about ICMP in
> an architectural way - however beautiful it was before ICMP
> black holing, what we have now isn't consistently usable today.
> We're spending time on point solutions (Matt Mathis on non-ICMP
> path MTU discovery as one example), but is this the best we can
> do?

I don't think we're likely to be able to dispense with ICMP.  Maybe we
can find more ways to make it more trustworthy.  Or maybe we just need
to discourage people from filtering it.

> > Note that scoped addresses make it difficult for each of the
> > network, hosts, and apps to do  their jobs - the network can't tell
> > whether it can get the traffic to the destination because the
> > destination address is ambiguous (so for instance, how can it tell
> > the difference between "prohibited" and "no route to destination"
> > and "no such host" - and while it might have unambiguous rules for
> > how to route such addresses, that doesn't mean the traffic went to
> > the right place); hosts can't tell which interface to use to send
> > the traffic; and apps can't tell whether or not the address is
> > usable to reach the desired peer (either locally or by another
> > peer).
> 
> This was my point (perhaps I wasn't clear enough) about the
> difference between site-local and firewalling - if your peer
> isn't reachable because of an explicit decision from a network
> operator (firewall), that's one class of problem; if your peer
> isn't reachable because you have an address that doesn't work,
> BUT YOU COULD HAVE BEEN GIVEN ANOTHER ADDRESS THAT WOULD HAVE
> WORKED (site-local), that's a different class of problem.
> 
> The thing that bugs me is, I don't have any idea how the
> application can tell that they have the second class of problem
> - even ignoring ICMP Unreachable black-holing for a moment. Am I
> missing something? (I don't think I'm a Genius of IPv6)

What I want to say is that if the peer isn't reachable because the
host or application didn't choose the right source or destination
address, this is never the host or the application's problem - it's
always the network's problem - because I don't see any way to allow 
hosts and apps to reliably make the "right choice" in the absence of
routing information, and which allows addresses to be used in referrals.
(and while separating endpoint identifiers from addresses might be a
laudible architectural goal, we're nowhere near being able to integrate
it into the current archtitecture).

> > Now, because of mobile IP and privacy addresses, we're still going
> > to have situations where apps need to give their hosts an idea of
> > what kinds of addresses they need.  E.g. Does the app need an
> > address that continues to work as the host moves, or will the
> > in-care-of address do?  Does it prefer an address that is stably
> > associated with the host, or is a temporary address more
> > appropriate?  But the answers to both of these questions *are*
> > things that the app can be expected to know.  Furthermore, unlike
> > service quality or security, these things inherently require address
> > selection.  And unlike site-local, these properties are essentially
> > opaque to other hosts in the network - thus we cannot expect/demand
> > that other hosts use information  embedded in the address and behave
> > differently for different kinds of addresses.  
> 
> From RFC 3344, the current Mobile IP spec:
> 
> 1.1. Protocol Requirements
> 
> [deleted down to]
> 
>    A mobile node must be able to communicate with other nodes
> that do not implement these mobility functions.  No protocol
> enhancements are required in hosts or routers that are not acting as
> any of the new architectural entities introduced in Section 1.5. 
> 
> And I agree I'm extrapolating, but - I always thought language
> like this said Mobile IP is a host IP networking thing, not a
> host application thing.
> 
> I'm not sure I'm understanding what you're saying - are you
> saying that my mobile host should know it's mobile (I believe
> you), or that Mozilla on a mobile host should know it's mobile
> (I'm struggling here)?

I'm saying that if your application knows that a particular connection
is only likely to be open for a short time, and/or that it can reliably
recover from broken connections, and that the source address isn't going
to be used for referrals to peers on other hosts, then it might want to
somehow tell its TCP/IP stack this, so the stack can use the in-care-of
address as the source address rather than the home address, thereby
bypassing any tunneling that might otherwise take place.  

Which isn't quite the same thing as letting an app know it's on a mobile
host - though that would also be useful for some apps.  

> My understanding of Mobile IP was that the mobile host knows,
> not Mozilla (or, at least, Mozilla works if it doesn't know).
> 
> Re: security - are you thinking of applications that prefer
> site-local (in IPv4, probably NATed 1918 addresses) for
> "security", or is there another common use of
> addresses-for-security I don't know about?

I don't think address selection is an appropriate means for an
application to specify security.  That's what IPsec and/or TLS are
for.  (and yes, we need IPsec APIs)  

nor do I think that an application should invest greater or less trust
in traffic that is sourced from or sunk to a particular address, at
least not without specifically being configured to do so, and certainly
not based on whether the address is site-local.

Keith

---

From: Brian Haberman <[email-masked]>
Date: Wed, 23 Apr 2003 15:51:10 -0400

> it into the current archtitecture).

But the stack can help in this case.  There is provision in the existing
scoped addressing architecture to return an ICMP message that will
specify that the reason the packet was dropped was due to a scoped
boundary (Destination Unreachable, Code=2).  The current ICMP spec
says it is for when the source address exceeds the scope boundary, but
the original intent was for it to be used for either address.

Do admins block ICMP messages that originate from within their own
networks?

Brian

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Apr 2003 12:56:47 -0700

John C Klensin wrote:
> ... Maybe that  to get there 
> means that we need to revisit, not just ICMP as Daniel suggests, 
> but the "no TCPng" decision... I don't know. 

Maybe that is the path out. 

>  But, if we can 
> figure out a way to clean this up and make it work well, we 
> could easily end up with a stronger justification for deploying 
> IPv6 than anything (at least anything real) we have had to date.

Depends on where you are in the world, and how much IPv4 address space
you are sitting on. I am aware of organizations in the US today that
can't get enough IPv4 address space fast enough by current ARIN policy
to meet a viable business plan for ramp up rate. 

> ... I'm just committed to a network and implementation 
> model in which they are kept below me in the stack. 
> Consequently, the only thing I want to need to know about an IP 
> address is how to pick it up from one source, carry it around 
> opaquely, and ultimately pass it to something else or use it in 
> an opaque way in a protocol transaction. 

But you just said you wanted to keep it below you in the stack. You
can't have it both ways... You either get to keep it below you by
passing around name objects, or you are taking on the responsibility of
getting it right because you are passing around topology information.

>  The challenge to those 
> of you who are for, or against, SL at the IP level is to justify 
> it in a context in which applications really don't need to know 
> anything about them, or other address scope/ reachability/ 
> routability issues except through the addressing-independent 
> abstractions that we can agree on.  

I don't care if it is TCP-ng, or something else between IP & the app
that takes care of figuring out the topology difference, but signaling
by itself won't solve the problem of literal referrals. If the app is
going to insist on passing around topology information, it has to make
sure that matches the topology being used.

> If the applications don't 
> need to know, and can function in a multiple-address-per-host 
> environment without --in the application-- having to determine 
> which one to use by some type of iteration process, then you 
> need to justify specialized addresses only in terms of their 
> requires lower in the stack.  If the applications do need to 
> know, then the complexity costs appear to be high enough to 
> present an insurmountable barrier.

The current IPv4 network already requires this of applications, the
developers simply choose to ignore reality. There is nothing different
in a unique prefix for local use, other than the ability for the app
(stack) that chooses to look to figure out that some pairings won't
work. If the app does as it currently will and passes an out-of-scope
address, the application will fail. This is not a new requirement, it is
simply exposing the fact that applications have been ignoring reality
for a long time now. If there are other ways to mitigate the issue, I am
all for developing them. My primary issue is that there are a variety of
things people want to use SL for and removing an existing mechanism
without appropriate replacements for all of them first is an
irresponsible act.

Tony

---

From: David Conrad <[email-masked]>
Date: Wed, 23 Apr 2003 13:57:13 -0700

Tony,

On Wednesday, April 23, 2003, at 12:56  PM, Tony Hain wrote:
> I am aware of organizations in the US today that

As this would appear to be an indication of a failure of allocation 
policy, a discussion of details on an appropriate list ([email-masked] 
would probably be best) would be appreciated.

Rgds,
-drc

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Apr 2003 17:26:48 -0400

> > routing information, and which allows addresses to be used in
> > referrals.(and while separating endpoint identifiers from addresses
> > might be a laudible architectural goal, we're nowhere near being
> > able to integrate it into the current archtitecture).
> 
> But the stack can help in this case.  There is provision in the
> existing scoped addressing architecture to return an ICMP message that
> will specify that the reason the packet was dropped was due to a
> scoped boundary (Destination Unreachable, Code=2). 

it doesn't help.  the problem is that the scoped address is inherently
ambiguous, and therefore any error that results from attempting to use
the scoped address occurs for ambiguous reasons. so even if the app gets
an ICMP unreachable message it doesn't know whether this is because it
was trying to use the scoped address in the wrong context or for some
other reason.  nor does the ICMP message help the app figure out the
right context, or whether it has access to the right context.

Ketih

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Apr 2003 18:07:31 -0400

> If the app is

agreed.  and by far the easiest way to do this is to have all points on
the network use consistent names for points in the network topology.

the real problem is that people have been conditioned to believe that
ambiguous addresses are a security feature, when what this actually
serves to do is reduce their ability to apply security in depth.

> developers simply choose to ignore reality. 

until recently 'reality' was that the vast majority of ipv4 hosts had
only one network interface, and one address, and most of the rest
of the hosts could act as if they only had one interface and one
address.  so application writers were paying attention to reality, even
if they weren't handling (or able to handle) every case that might
potentially arise.

> My primary issue is that there
> are a variety of things people want to use SL for and removing an
> existing mechanism without appropriate replacements for all of them
> first is an irresponsible act.

we need a list of these things, so we can work on a list of
replacements.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Apr 2003 18:12:27 -0400

> space and passing around topology specific information will result in

This is ridiculous.  Tony, we understand that we don't have a
completely connected network.  We've understood that for years. 
But we're not willing to adopt your delusions that this is the same
problem as having ambiguous addresses.

Keith

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 23 Apr 2003 17:44:31 -0500

Thus spake "Tony Hain" <[email-masked]>
> If Bl & Bg had indicators of scope differentiation in the prefix, A could
> recognize the difference if it bothered to look. It wouldn't have to, but
> if it didn't it would either have to refer the name, or provide C with the
> entire list so it could figure out which one works. Brian's C000 thread
> was exploring this space.

"Global" addresses can be scoped by administrative/security devices just as
easily as non-globals, so a scope indicator in the address is merely a hint
which may lead the app/stack astray.  The only way to determine if a given
address, global or otherwise, will work is to try using it.

SL does not solve -- nor did it create -- this problem any more than RFC1597
did.

S

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Apr 2003 15:53:36 -0700

Keith Moore wrote:
> But we're not willing to adopt your delusions that this is 
> the same problem as having ambiguous addresses.

I am focusing on your 4/18 assertion: introduction of scoped addresses
causes far more problems than it solves.

I am not talking at all about ambiguity.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Apr 2003 15:51:40 -0700

> we need a list of these things, so we can work on a list of 

I am accepting comments for:
http://www.ietf.org/internet-drafts/draft-hain-ipv6-sitelocal-00.txt

Tony

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Apr 2003 19:38:25 -0400

> >  Tony, we understand that we don't have a 

ambiguity is certainly one class of problems that site locals cause.

now whether you define scoped addresses as "names for locations in the
network whose meanings are relative to a particular subset of the
network, and which may have other meanings in other subsets of the
network", or "addresses are only reachable from a particular portion of
the network" is, I suppose, fairly arbitrary. I've been using the former
definition.

Keith

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 23 Apr 2003 18:29:18 -0500

> > My primary issue is that there are a variety of things people want to
> > use SL for and removing an existing mechanism without appropriate
> > replacements for all of them first is an irresponsible act.
>

Top of the list: a portable but unroutable prefix, say a /48, that doesn't
require recurring fees to an RIR or ISP.  I don't require it to be unique
(since it's unroutable), but that's your call.

S

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Apr 2003 21:31:56 -0400

Daniel Senie writes:

> > scoping problem, I suggest that be addressed separately.

I guess it depends on what you define as "the scoping problem".  If the
problem is that the network can impose apparently arbitrary restrictions
on whether hosts can communicate between point A and point B (for
arbitrary A and B) I don't see that as an architectural problem, nor
something that should be the responsibility of applications to solve. 

and if you define the problem as that hosts are expected to be able to
simultaneously have access to multiple scopes that must be accessed via
different source addresses or different network interfaces or different
tunnels, and to be able to provide connectivity to each of those for
applications on that host, I still have to question whether giving each
scope a separate address prefix is a constructive way to implement that.

so is there a definition for "the scoping problem" that you have in
mind?

John Klensin writes:

> Tony, I think this pretty well reflects where I've found myself 
> going on this, fwiw.   From an applications standpoint, the 
> scoping issues, and what is, or is not, "topology information", 
> just obscure the problem.  "The problem", from an applications 
> point of view, is that, if we are going to stop pretending that 
> the address space is completely flat and global --and I agree 
> that to do otherwise is unrealistic at this stage-- then we need 
> a model by which the application can specify to the stack what 
> it needs/ expects, and the stack can tell the application 
> whatever the latter really needs to know about what is 
> happening.  

I don't see why it's unrealistic to have a global address space that
encompasses all hosts that are connected any network that is connected
to the Internet, and to expect applications to use that global address
space.  I agree that we cannot expect complete or near-complete
connectivity.

In my mind, the reason we need feedback from the network to applications
about when applications try to violate administrative prohibitions on
use of the network is not so that applications can try to route the
messages through other paths (though it does enable that to some
limited degree) but so that applications can provide accurate
indications to their users as to why they're failing.

> ICMP, as now defined and used, won't help with the 
> problem for a reason much more pervasive than the one Daniel and 
> others have identified: most of our current applications have no 
> interaction with either ICMP or IP -- they call on TCP or UDP 
> functions and don't know about the internet layer.  The Internet 
> layer doesn't have any path (by "signalling" or otherwise) to 
> pass information back to the apps.

I don't see why TCP and/or UDP stacks can't provide such interfaces
to applications, even though of course this means that there will need
to be other interfaces (invisible to applications) between TCP and IP
and UDP and IP to pass that information upstream.

> So, I would suggest that we really do have a problem here. 
> Unless we have a realistic proposal for a routing fabric that is 
> not dependent on the addresses used, the solution-set almost 
> certainly includes being able to use multiple addresses per 
> host, with different semantics associated with those addresses. 

the solution set to what?  I don't see what problem this is attempting
to solve, but I do see lots of problems that this creates.

> As the competence level of the average ISP declines (which seems 
> to have been a clear trend for the last several years), 
> multihoming (in some form) needs to increase as the only 
> satisfactory alternative... and it better not be only for the 
> rich or the huge.  The idea of a single, exclusively-global, 
> flat address space has been history for years; we clearly aren't 
> going to get back there as long as different providers charge 
> differently for different paths (independent of any of the 
> enterprise localization, firewall, RIR-granted PI space, or 
> other issues).

radical idea: we need to get away from the notion that the IP address is
a path specifier and back to the notion that an IP address is a
location or interface identifier or (possibly virtual) host identifier.

> But, unless we are prepared to discard the model of a layered 
> stack architecture, or accept our applications becoming as (or 
> more) complex and knowledgeable about network architectures as 
> switches get in the PSTN, then we should be looking at stack 
> abstractions that permit applications to express their needs, 
> and get information back, without deducing network topology, 
> transport or mobility economics, etc. 

I don't think these things need to be provided in the "stack" at all -
for the same reason that apps don't want to cope with them - neither the
host nor the app has the information needed to make those decisions. 
and lacking a uniform address space, there's no basis for lower layers
to make the decisions.  (for some reason a potentially-changing set of
IP addresses doesn't strike me as a good endpoint identifier for any
layer)  so we need a uniform location name space to be used by higher
layers, and we need for the network to make the path selection
decisions.  now maybe these decisions need to be made at border routers
rather than core routers (so that finer details of path selection are
handled in the periphery where you get better scaling, and the core
routers just forward things along pre-determined paths) but you don't
want to push the routing information all the way to hosts.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Apr 2003 00:18:16 -0400

> 	* We don't have a routing architecture that is
> 	independent of the structure of IP addresses.  I wish we
> 	did.  I think the fact that we don't is going to lead us
> 	into [other] very serious problems in the long term.
> 	But the fact remains that we don't have anything
> 	resembling an IP-address-independent routing fabric
> 	proposal on the table, certainly not one that is
> 	complete enough to be plausible.
> 	
> 	* We are seeing more and more requirement for
> 	multihoming of one type or another, whether you count
> 	community wireless schemes or other small-group or
> 	small-ISP models into the mix or not.
> 
> One implication of the first problem is that one can't solve the 
> second one by giving everyone who wants to connect to more than 
> one provider independently-routable PI space.  Now, if we don't 
> come up with a solution to both of those problems, it doesn't 
> make any difference what features are in IPv6, because IPv6 will 
> fail, and it will fail because the Internet --at least the 
> Internet as we know it-- will fail.  I think we even know what 
> the alternative looks like, at least in general terms, with 
> islands of walled gardens, each with independent address spaces, 
> and connected by bilateral agreements being the most likely of 
> those alternatives.  Those proposals have been around for years, 
> we know what they look like, and they don't provide the 
> edge-oriented, end-to-end, "dumb" network we all believe is the 
> core strength of the Internet.

I don't doubt this, but it's fairly clear to me that having multiple
addresses per host and expecting hosts to make decisions about which
prefix to use is also highly undesirable - in the sense that it will
drastically limit the set of applications that can work well.  But yes,
we have more of a chance of things working if they're all using a
single shared address space, than we do with disjoint address spaces.

I also don't see how this problem is any different between IPv4 and
IPv6, except that we might eventually expect IPv6 to scale to more
prefixes than IPv4.  Yes, v6 hosts have the code to handle multiple
prefixes and addresses, but that doesn't mean that the apps can deal
reasonably with them.  And in my experience even the simplest apps fail
to deal reasonably with multiple prefixes.  (trial-and-error, waiting
tens of seconds to timeout before proceeding to the next address, is
not reasonable)

But we need to distinguish between what we can do in the short term and
what we need to do in the long term.  In the short term our choices are
either to allow some form of provider-independent addressing (with all
that this means for the scalability of routing) or to expect hosts and
apps to deal with multiple prefixes.  Which choice is better is not
obvious - it depends on whether you want to optimize IPv6 for easy
deployment or eventual scalability.  Your answer to this question
probably depends on what layer you live at.

In the longer term we need to develop a way of doing a mapping from
location names or endpoint names to paths through the network, one that
preserves the uniqueness and structure of IPv6 addresses.

> At least so far, "give every host one address and let the 
> network (the routers?) sort out the routing" seems to me to 
> reproduce the current IPv4 situation.  That doesn't seem to me 
> to be a solution because it:
> 
> 	* Assumes that everyone who has a LAN that they want to
> 	connect to multiple providers will have routable PI
> 	space.  Or
> 	
> 	* Assumes that everyone who has a LAN that they want to
> 	connect to multiple providers will be able to do so by
> 	punching holes in CIDR blocks.

To my routing-naive mind, two mechanisms seem worth investigating:

- One is a mapping at the BGP layer from what I'll call path-independent
prefixes to path-specific prefixes.   e.g. BGP could propagate
information of the form "route prefix X as if it were prefix Y". 
Routers wouldn't have to compute routes for prefix X, they could just
compute routes for Y and then use the same entry for X as for Y in the
fowarding table.  This lets the number of prefixes grow to some degree
without directly increasing the complexity of routing computations, as
long as the set of distinct destination networks as viewed from the core
did not get larger. In effect it would allow non-adjacent prefixes to be
aggregated for the purpose of route table computations. Which is not to
say that this comes for free, but it would let us to some degree move
toward a routing structure for the core that was independent of the IP
addresses used by hosts - in effect hosts and routing would use
different portions of the IP space, though some amount of overlap could
be tolerated.

- A mobileIP-like scheme for border routers, that could issue redirects
for prefixes as well as individual IP addresses.  So packets for a
particular destination prefix would initially go to "home network
agents" that could live anywhere on the network (including a database
distributed across multiple exchange points in diverse locations, all of
which advertise reachability via BGP) but which (in addition to
forwarding initial packets) would return redirects for entire prefixes
that caused subsequent packets to be sent to the "in care of prefixes".
These redirects would be intercepted and acted on by routers near the
source, not (or not only) by the sending host. Yes, it would still
require tunneling, or MPLS, or some other way of telling the network 
"route this traffic to here rather than to the destination  address in
the IP packet; that's for use after the packet exits our network".  But
there are lots of ways to do this, and perhaps they'll become more
widely available over time. 

And for those who think these ideas are naive, keep in mind that I did
say they're not near-term solutions, and that in the near term we're
stuck with less sophisticated mechanisms.  But we need to insist on
global addressing now so that we have a way to move to better routing
systems once we do solve the problems.

> > I don't see why it's unrealistic to have a global address
> > space that encompasses all hosts that are connected any
> > network that is connected to the Internet, and to expect
> > applications to use that global address space.  I agree that
> > we cannot expect complete or near-complete connectivity.
> 
> But, if we have a one-address-per-host global address space -- 
> which I think is what you are asking for-- and don't have 
> near-complete connectivity, then we are either going to see 
> rising times to set up the typical TCP connection, and a lot of 
> UDP attempts fall off the edge, or we are going to need a lot 
> more PI space.  I don't see realistic alternatives for the 
> reasons discussed above.  Do you?  And, if so, what are they?

I doubt we'll see a one-size-fits-all kind of solution any time soon. 
Some sites will be able to make do with multiple advertised prefixes,
perhaps with clever DNS tricks to try to minimize the connection
failures (yeech).  Other sites will be able to tolerate a single
provider.  Others will demand PI space and perhaps get it. Maybe they'll
have to buy an ISP, or masquerade as one, to accomplish this. I've
always thought the distinction between an ISP and a multi-homed,
multi-sited customer was fairly arbitrary.    I could imagine an
arrangement where limited-time leases for use of some amount of what was
effectively PI space (even if it came out of providers' allocations, it
could be routed to multiple providers)  was auctioned off to the highest
bidders, like radio spectrum. Or maybe the problems will create a demand
for more stable/clueful/expensive IP routing service.  

Or maybe the public Internet will just degrade to the point that it's
not useful for very much.  I'm not discounting that possibility, but
neither do I want to dwell on it.

> > In my mind, the reason we need feedback from the network to
> > applications about when applications try to violate
> > administrative prohibitions on use of the network is not so
> > that applications can try to route the messages through other
> > paths (though it does enable that to some limited degree) but
> > so that applications can provide accurate indications to their
> > users as to why they're failing.
> 
> Keith, while I'm very much in favor of accurate feedback, 
> messages with the ultimately semantics of "you lose" have a long 
> and well-documented history of being unpopular with users. 

Granted.  But there is no way that the reliability of internet
applications can improve unless the network can provide such feedback
to *somebody*.  Now maybe it shouldn't always be the user, but the
application, or the user's network administrator, or the application
author/vendor.  to some degree it depends on the application.  But
nobody can do anything about the problem without some indication that
the problem exists and some way to distinguish one kind of problem
from another.

> I'd rather focus on getting the network to work better and more often,
> while reporting  accurately on failures if there is no alternative but
> to fail.

No question there, but if the failure is due to an administrative
prohibition (which is where I thought this started), it's hard
to see what it means to have the network work better and more often -
unless it's to discourage use of packet filtering.  :)

> > I don't see why TCP and/or UDP stacks can't provide such
> > interfaces to applications, even though of course this means
> > that there will need to be other interfaces (invisible to
> > applications) between TCP and IP and UDP and IP to pass that
> > information upstream.
> 
> They can't provide it because we don't have a model, or set of 
> abstractions, for providing it.  If it is important, maybe we 
> had better get started.

Has anyone made a list of important core problems that need to be
worked on?

Keith

---

From: Ignatios Souvatzis <[email-masked]>
Date: Thu, 24 Apr 2003 10:18:43 +0200

Hi,

> to discourage people from filtering it.

I don't understand why this is even a point of discussion. Next you hear
some people will like to globally filter TCP RST - will you rewrite TCP
to work without that?

Regards,
	-is

---

From: Shannon -jj Behrens <[email-masked]>
Date: Thu, 24 Apr 2003 09:28:08 -0700

> http://www.ietf.org/internet-drafts/draft-hain-ipv6-sitelocal-00.txt

Dear Sir,

Please forgive my rough tone (in fact, I have great respect for you as an
engineer), but it would be much more interesting if you wrote a document that
provided solutions for all of the problems that people have claimed
site-locals cause.  While I hear you saying that the wg should replace all of
the features that site-locals provide before removing them from the
architecture, I challenge you to instead take the impetus of fully specifying
site-locals.  I do believe, based on other comments on the list, that such a
challenge has existed for five years and has yet to be answered.  Having fully
specified site-locals, I do believe the wg would be much more willing to accept
them into the architecture.  Although I clearly am not capable of providing the
full list of questions that you must answer, perhaps the following questions
are helpful:

o In light of the fact that not every host has a DNS name, how do you propose
multi-party P2P applications should do referrals? It would be helpful if you
established the normal mode of operation for such situations.

o Should site-locals be put in DNS?  Should multiple views of DNS be used?  If 
so, how do you address the apparent apprehension in the DNS community toward
multiple views (I don't know about this first-hand--I've only read about it 
from this list)?  Should zone information be kept in DNS?

o Do you foresee all nodes being multi-site nodes?  If I'm at work and wish to 
use both my work network *and* my home network via a VPN connection, I expect
I would want my laptop to be a multi-site node.  If this is the case, do I 
need to use %interface_name at the end of all IP's I give to applications I 
use?  How would DNS lookups work on a multi-site node if site-locals are stored
in DNS?

o If, as you say, we should provide site-locals because, "we need to meet the
network manager at his comfort zone and provide a familiar tool," how do we 
convince the network manager not to use NAT since this is also a familiar tool
in most people's comfort zone.  I'm not willing to argue that site-locals 
necessarily lead to NAT, but many people are, so you should probably have some
answer. 

o Do you envision support for Margaret's idea of multiple concentric rings of
security (possibly using site-locals)?  If a node in the outermost ring is not
able to talk to a node in the innermost ring using a site-local address because
of filtering, but is permitted to use a global address, how shall applications
react when the site-local "hint" is actually misleading?

Again, I'm sure there are many more such questions, and I think it would be 
helpful (and in fact requisite) that you answer such questions in an Internet
Draft in order to achieve your goal of restoring site-locals to the 
architecture.  I thank you for your time and *patience* if you have made it all
the way through this message.

Best Regards,
-jj

-- 
Hacker is to software engineer as 
Climbing Mt. Everest is to building a Denny's there.
--------------------------------------------------------------------
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: "Tony Hain" <[email-masked]>
Date: Thu, 24 Apr 2003 12:55:29 -0700

Shannon -jj Behrens wrote:
> Please forgive my rough tone (in fact, I have great respect 
> for you as an engineer), 

I try to avoid taking any IETF discussions personally, one way or the
other.

> but it would be much more 
> interesting if you wrote a document that provided solutions 
> for all of the problems that people have claimed site-locals 
> cause.  

I understand that is what some people want, but I think we need to first
agree on the problems that need solving. We have many opinions on why SL
creates problems, but a blatant lack of recognition of the problems that
need to be solved. 

> While I hear you saying that the wg should replace 
> all of the features that site-locals provide before removing 
> them from the architecture, I challenge you to instead take 
> the impetus of fully specifying site-locals.  

I believe the first step to doing that is to agree on the problems that
need solving, then see if there are alternative approaches. 

> I do believe, 
> based on other comments on the list, that such a challenge 
> has existed for five years and has yet to be answered.  
> Having fully specified site-locals, I do believe the wg would 
> be much more willing to accept them into the architecture.  

I thought we were going there with the scoped arch document, but lacking
agreement on the problems to be solved, it became easier to spread FUD
and give up on addressing the issues than to sit down and work them
through.

> Although I clearly am not capable of providing the full list 
> of questions that you must answer, perhaps the following 
> questions are helpful:
> 
> o In light of the fact that not every host has a DNS name, 
> how do you propose multi-party P2P applications should do 
> referrals? It would be helpful if you established the normal 
> mode of operation for such situations.

As I said in the note to JCK, I have been imprecise about 'name' so
whatever the app uses to get a handle from the local stack is what it
needs to pass around. Doing otherwise ignores the reality that the
network does not look the same from all points.

> so, how do you address the apparent apprehension in the DNS 
> community toward multiple views (I don't know about this 
> first-hand--I've only read about it 

Implementation details of a multi-faced DNS are best addressed by those
that already ship them. Any service that provides topology specific
information has to do that with an understanding of the topology being
described by that information. 

> 
> o Do you foresee all nodes being multi-site nodes?  

Certainly not all, my light switch should not be in any site except my
house. At the same time I may want it to be in multiple scopes, so I can
get to it and turn on the driveway light from the car as I approach.

> If I'm at 
> work and wish to 
> use both my work network *and* my home network via a VPN 
> connection, I expect I would want my laptop to be a 
> multi-site node.  If this is the case, do I 
> use?  How would DNS lookups work on a multi-site node if 
> site-locals are stored in DNS?

The name resolver would have to track which interface / site it got
answers from because any limited scope resolution is only applicable in
that interface / site context. 

> 
> o If, as you say, we should provide site-locals because, "we 
> need to meet the network manager at his comfort zone and 
> provide a familiar tool," how do we 
> convince the network manager not to use NAT since this is 
> also a familiar tool in most people's comfort zone.  I'm not 
> willing to argue that site-locals 
> necessarily lead to NAT, but many people are, so you should 
> probably have some answer. 

Leading people away from something comfortable requires providing
something that meets the same basic need and is easier/cheaper/more
comfortable. Many use NAT because they can't get STABLE addresses
otherwise, and NAT is simply the cost of getting that. Providing STABLE
local use prefixes simultaneously with global prefixes that may change
over time is a cheaper way to meet the need for STABLE addresses. 

* I emphasize STABLE because that is a invariant requirement by many
managers of large networks. 

> 
> o Do you envision support for Margaret's idea of multiple 
> concentric rings of security (possibly using site-locals)?  
> If a node in the outermost ring is not able to talk to a node 
> in the innermost ring using a site-local address because of 
> filtering, but is permitted to use a global address, how 
> shall applications react when the site-local "hint" is 
> actually misleading?

Personally I consider those security zones as different sites. This gets
into the poor definition of 'site', but we were intentionally vague
there. There is no difference between an FEC0 or 2001-w/Bellovin-Zill
flag prefix in how one would solve this problem. The fact that SL does
not provide multiple concentric security zones is not a failure of SL,
because that was not a design requirement (again we need to agree on the
problems to be solved). 

> helpful (and in fact requisite) that you answer such 
> questions in an Internet Draft in order to achieve your goal 
> of restoring site-locals to the 
> architecture.  I thank you for your time and *patience* if 
> you have made it all the way through this message.

I agree that we need answers to all these issues, and that was the
intent of the scoped arch doc. Once people realize that they continue to
exist for any local use prefix, we will stop the nonsense about SL is
the evil that causes the problems and get back to developing the needed
documents.

Tony

---

From: Shannon -jj Behrens <[email-masked]>
Date: Thu, 24 Apr 2003 14:24:48 -0700

On Thu, Apr 24, 2003 at 12:55:29PM -0700, Tony Hain wrote:

(I'm going to clip much of this email to concentrate on those areas that need
further discussion.)

> needs to pass around. 

If A connects to B, and B wishes to pass the connection info to C, B only has
the address with which A accessed B.  If A and B are in the same site and used
site-local communication, and C is not in that site, B does not have enough
information to refer C to A.  Hence, your suggestion does not solve this case.

> Doing otherwise ignores the reality that the

I agree, and in fact, that's what I'm asking you how to work around.

> that interface / site context. 

That's true, and that sufficiently solves one side of the problem.  However, 
the other side of the problem is knowing which name resolver to go to in the
first place.  If I use my home resolver, I won't be able to get the address of
(e.g.) my printer, but if I use my work resolver, I won't be able to get the 
address of my toaster.  Do I need to always check both?  It seems that we're
encountering this situation because DNS implicitly assumes (at least in my
limited understanding) that choice of a DNS proxy should not affect the
results.

> because that was not a design requirement (again we need to agree on the

Well, that's a fair answer.

By the way, I do applaud your effort in making a site-locals requirements
document.  I think such a document will ultimately be useful if it presents
requirements in such a way that people who wish to replace the functionality
that site-locals provide know what needs replacing.

Thanks,
-jj

---

From: Alain Durand <[email-masked]>
Date: Thu, 24 Apr 2003 14:59:57 -0700

I agree with Dave Crocker that the post from John Klensin is the
first one in thousand of emails that put the discussion in a new
(and very interesting) perspective.

In the goold old IPv4 word, locators & identificators are the same thing.
This is, as many people pointed out, the root cause for a lot of the
hard problems we see today, such as multi-homing & mobility.

We have made the problem even harder in IPv6 by adding more sementic
to specific addresses: we now have addresses that are non permanent
with privacy extensions (RFC3041), transition addresses (6to4, isatap,
IPv4 compatible,...), scoped addresses (Link locals and hoppefuly defunct
site locals), home address vs care-of address, crypto-generated addresses,
and the list grows every day.

Add to this that it is now more and more common for nodes to have multiple
interfaces to different types of networks with different physical 
caracteristics
(wired/wireless, high bandwidth, expensive access..)...

...and we made it even more complex now in the early days of coexistence
of IPv4 and IPv6, when an IPv6 address may have been registered in the DNS
but there is no actual IPv6 path to go there, or if there is
one, it is sometime so boggus that it leads to very bad performances.
(note: nothing to do with v6, just the sate of current deployment)

There is a proposal to create an API to enable the
application creating the socket to specify some of the
properties that it desires/requires. This is a step in the right
direction, but I'm not convinced this can go far enough.
So I fully support this idea of lifting the ban on TCPng
(or any transport layer for that matter) to de-couple
the abstraction needed by applications to the one required
by the network. This is in fact introducing some of the semantic
of a session layer between the application and the network.
Can this be done at the transport layer in the form of TCPng
or does this require and actual additional session layer?
I'm not sure at this point in time.

    - Alain.

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 24 Apr 2003 15:00:54 -0700

Shannon -jj Behrens wrote:
> If A connects to B, and B wishes to pass the connection info 
> to C, B only has the address with which A accessed B.  If A 
> and B are in the same site and used site-local communication, 
> and C is not in that site, B does not have enough information 
> to refer C to A.  Hence, your suggestion does not solve this case.

I agree, but is it reasonable for B to tell C to talk to A, or is it
more reasonable for B to tell A to connect to C by the 'name blob' it
would have used to contact C? 

Please don't think I am picking on this instance, but the whole mode of
attack by finding a failure case, without thinking through alternatives
is a waste of everyone's time.

> I agree, and in fact, that's what I'm asking you how to work around.

See above about changing the message sequence.

> the other side of the problem is knowing which name resolver 
> to go to in the first place.  

Unless there is some hint in the name string, the only approach I know
of is to shotgun all the servers.

> If I use my home resolver, I 
> won't be able to get the address of
> address of my toaster.  Do I need to always check both?  It 
> seems that we're encountering this situation because DNS 
> implicitly assumes (at least in my limited understanding) 
> that choice of a DNS proxy should not affect the results.

Which is my argument to the IAB: the infrastructure components that pass
around topology information are completely out of step with the reality
of the deployed network topology. We need to fix this because it will
not get better on its own.

> ...
> > The fact that SL does not provide multiple concentric 
> security zones 
> > is not a failure of SL, because that was not a design requirement 
> > (again we need to agree on the problems to be solved).
> 
> By the way, I do applaud your effort in making a site-locals 
> requirements document.  I think such a document will 
> ultimately be useful if it presents requirements in such a 
> way that people who wish to replace the functionality that 
> site-locals provide know what needs replacing. 

I am not trying to claim I have all the answers, so if anyone has
content for it, please send them.

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Apr 2003 18:10:19 -0400

> would have used to contact C? 

let me rephrase the question.  is it reasonable to expect that every 'blob'
that can be used to derive a set of locators for a host is tightly bound to
that host?   or is it more reasonable for the network infrastructure to
provide a token, independent of any application-specific blob, that can be
tightly bound to that host?

back in the mid 1990s I had a system for looking up URLs or URNs in a
distributed database which would return blobs that could be used to find
accurate replicas of those resources.  those blobs included IP addresses in
order to speed up access (requiring clients to do extra DNS lookups
drastically slowed the system down).  but those blobs weren't bound to hosts,
they were bound to resources, and the mapping between resources and hosts was
(by design) arbitrary.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 26 Apr 2003 13:53:16 -0400

> Applications have bad habits.
> 
> They cache network addresses when they should be caching names.  

nice theory.  the fact is that names are imprecise; they're not always
bound to what we think they're bound to, there's no way to tell what
they're bound to, and the bindings are subject to change.  and DNS
in particular can be slow and unreliable.  

in short- you can lose by storing names in your application just as
easily as you can lose by storing IP addresses in your application.
anytime you do either one, you're making assumptions about the bindings
of those names or addresses with hosts that are subject to change,
often by factors outside your control.

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 27 Apr 2003 20:17:55 -0400

Hi Dave,

At 04:12 PM 4/18/2003 -0700, Dave Crocker wrote:
>please point us to some text that gives a clear and complete discussion
>of the benefits that accrue from this new feature, as well as a fair
>consideration of its difficulties.

I wrote such a document.  It can be found at:

http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.txt

This is a personal draft, not a work item of the IPv6 WG.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 27 Apr 2003 20:21:50 -0400

>We either provide a mechanism, or the users provide one of their own.

As John Klensin pointed out on this same list several weeks ago
(and I'm sure he said it better than I will), the decision to
use ambiguous local addressing in IPv4 (i.e. RFC 1918 addresses)
was partially motivated by the desire to conserve IPv4 address
space.  In IPv6, we don't have an address space shortage, so there
is no reason to introduce architectural complexity to conserve
address space.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 27 Apr 2003 20:32:06 -0400

>carved in stone, and these particular omissions are easy to fix.

There is currently no RFC that defines the usage model for IPv6
site-local addressing.  The prefix is defined in the addressing
architecture RFC (currently at PS), but the usage model is defined
in the scoped addressing architecture (a WG I-D).

This I-D has been relatively stable for a couple of years, but has
not gone to the IESG, mostly due to IPv6 WG deadlock over the
architectural issues regarding site-local addressing.  During that
time, we have been slowly working through the various architectural
issues caused by site-local addressing, and building WG
consensus regarding what to do about it.

So, I think that this is actually a case of the WG process working
properly (if a bit too slowly).

Margaret

---

From: David Conrad <[email-masked]>
Date: Sun, 27 Apr 2003 19:38:37 -0700

Margaret,

> was partially motivated by the desire to conserve IPv4 address

Yes.  Of course, there were and are other reasons, the most significant 
of which is in conjunction with the use of NAT to provide some level of 
provider independence (both in terms of avoiding the necessity to 
renumber when changing providers as well as not having to "purchase" 
additional IP addresses from the service provider).

>  In IPv6, we don't have an address space shortage, so there

While it is true that address conservation isn't that significant an 
issue, the whole issue of provider independence (or lack thereof) 
continues to exist.

Continuing to ignore this fundamental requirement on the part of 
enterprise network operators is getting us no where.  It certainly 
isn't getting us to IPv6 deployment.

Rgds,
-drc

---

From: Bill Manning <[email-masked]>
Date: Sun, 27 Apr 2003 22:24:52 -0700 (PDT)

% As John Klensin pointed out on this same list several weeks ago
% (and I'm sure he said it better than I will), the decision to
% use ambiguous local addressing in IPv4 (i.e. RFC 1918 addresses)
% was partially motivated by the desire to conserve IPv4 address
% space.  In IPv6, we don't have an address space shortage, so there
% is no reason to introduce architectural complexity to conserve
% address space.
% 
% Margaret

	"dont' have an address space shortage..." - Margaret 
	-YET-
	IPv4 didn't have one either, in its early days.

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).
--------------------------------------------------------------------
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: Margaret Wasserman <[email-masked]>
Date: Mon, 28 Apr 2003 05:53:20 -0400

Hi Robert,

>That is, whether it is SL, LL, or some random "global" prefix they calculated

Actually, it isn't true that an IPv6 global /48 prefix plus site
locals would provide all of the "benefits" of NAT.

In particular, you would still need to renumber your local network
(the global prefixes) when your provider-allocated global
addresses change.  Having extra addresses available for internal
traffic (the site-locals) does not make renumbering the global
prefix any easier or less expensive.

Although NAT causes various problems, it does offer a high degree
of provider-independence for internal nodes.  You won't get this
using provider-allocated global addresses in IPv6, no matter how
many other addresses you add to each node.

Of course, this isn't why NAT is most often used...  NAT is most
often used to extend a single address to cover multiple systems
in a home or small office environment.  For that environment,
an IPv6 /48 (without site-locals) would suffice to replace NAT.

>of SL addressing by reference to NAT - that's simply too ludicrous (and sad)

I am similarly disturbed that there are people who want to
specify site-local addressing because they think it will offer
the provider-independence currently offered by NAT.

Margaret

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 28 Apr 2003 11:23:25 -0500

Thus spake "Margaret Wasserman" <[email-masked]>
> an IPv6 /48 (without site-locals) would suffice to replace NAT.

When you are talking about tens of millions of customers, it's not feasible
to give each a subnet even if you have the space to do it.  IMHO, most
customers will be placed on a /64 that's shared across hundreds of
customers, similar to IPv4 common practice.

There is nothing to indicate that ISPs are going to change their business
models simply because IPv6 address space is plentiful; they charge extra for
two hosts because it is assumed two hosts consume more bits than one, not
because a second IPv4 address is hard to come by.

S

---

From: Robert Elz <[email-masked]>
Date: Mon, 28 Apr 2003 22:37:20 +0700

Date:        Mon, 28 Apr 2003 05:53:20 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | In particular, you would still need to renumber your local network
  | (the global prefixes) when your provider-allocated global
  | addresses change.

Yes.

  | Having extra addresses available for internal
  | traffic (the site-locals) does not make renumbering the global
  | prefix any easier or less expensive.

No, that's simply wrong.   One of the biggest costs in renumbering
is the disruption it causes.   The actual cost of editing the files,
etc, is trivial by comparison.

If all of the internal operations of an organisation are going to
be disrupted, then the organisation is really going to resist any
renumbering.

But if everything just sails on through, operating as normal, then
adding a prefix, and later deleting an old one, is must less intrusive,
and less costly.

  | Although NAT causes various problems, it does offer a high degree
  | of provider-independence for internal nodes.  You won't get this
  | using provider-allocated global addresses in IPv6, no matter how
  | many other addresses you add to each node.

It would be nice if everyone would stop using "provider" in this context.

What matters here is the use of topology sensitive addresses.   If the
address reflects the topology of the network, then it has to change when
the topology changes.

It happens that in the current network environment, the topology is
controlled by the providers, so we have provider supplied addressing
to correctly reflect the topology.

Getting provider independent addressing is plausible - we just need
to make the network topology (somehow) stop being controlled by the
providers.

Getting addressing that is independent of the topology is a much more
interesting problem.  That one I don't believe we have any way to
accomplish yet, that works with routing.   Until we do, we need
addressing for local use.

  | Of course, this isn't why NAT is most often used...  NAT is most
  | often used to extend a single address to cover multiple systems
  | in a home or small office environment.

I think you're living in a sanitised enviornment.   NAT is used almost
everywhere (perhaps outside the US) - almost everywhere.

  | For that environment,
  | an IPv6 /48 (without site-locals) would suffice to replace NAT.

It might.   I'm not sure it will however.   I don't know that I want
even my home connectivity (connections between controllers and
appliances and such) to be disrupted when I change providers (or
when my provider alters the prefix temporarily allocated to me).

  | I am similarly disturbed that there are people who want to
  | specify site-local addressing because they think it will offer
  | the provider-independence currently offered by NAT.

I have no idea who those people are.   I am surprised that you (seem to)
believe that NAT offers provider independence.   It doesn't.   What it
does is allows the renumbering task to be simplified (quite a lot usually
in that case) - but that's all.   Site locals do the same, they allow the
renumbering task to be simplified, as there's one less thing that needs
to be worried about.

By no means do they solve the entire problem, they're just one nail.
But they (or something essentially equivalent) are required, something
needs to provide the kind of address stability that anyone can now have
in IPv4 using NAT.

We could recommend NAT for IPv6, that would certainly do it, but I hope
we don't, there has to be better ways than that.

If you think you have a better way than site locals, please describe it.

I don't want to know what you think the problems with site locals are,
I know they're not perfect.   I want to know what is the better solution.
Until there is one, site locals need to remain.

kre

---

From: Robert Elz <[email-masked]>
Date: Mon, 28 Apr 2003 23:46:17 +0700

Date:        Sun, 27 Apr 2003 20:21:50 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | As John Klensin pointed out on this same list several weeks ago
  | (and I'm sure he said it better than I will), the decision to
  | use ambiguous local addressing in IPv4 (i.e. RFC 1918 addresses)
  | was partially motivated by the desire to conserve IPv4 address
  | space.

That was most probably a small part of it.   The real motivation was
that people were simply numbering their nets out of random numbers,
and that was a bigger problem, for everyone, than 1918 addresses ever
were.

Keith has said that he feels that the decision to go with 1918 (and
1597 before that) was wrong.  He's mistaken.   The net would have
been a disaster without it, and not just because we would have run
out of addresses more quickly (given sufficient incentive, we could
have found a solution to that much more quickly than we have been
doing).

Please remember the dual goals of IPv6 - they show the dual problems
that the net was facing in the early 90's.   More addresses, and
routing simplification.   We haven't found a newer routing solution
than (now) exists for IPv4 - which means topological addressing.
We have to make that work, or find something else.

  | In IPv6, we don't have an address space shortage, so there
  | is no reason to introduce architectural complexity to conserve
  | address space.

Of course there isn't.   You can go on refuting claims that no-one is
making forever if you want, that won't get us any closer to anything.

I'd have every node given a global address (whether it wants to use it
or not).   Site local addresses are an extra.   As are link locals.
There's no address conservation happening here.

Either of those -local addresses adds the architectural complexity.
Only by removing both of them can you simplify things.

While simplification is a good thing, I certainly don't feel that we
can sacrifice link local addressing to get it.   And as long as we're
keeping link local, the extra complexity added by site local is close
to zero (and essentially would be zero if we eliminated multi-site nodes
from the architecture).

kre

---

From: Eliot Lear <[email-masked]>
Date: Mon, 28 Apr 2003 09:55:02 -0700

> customers, similar to IPv4 common practice.

Why?

Eliot

---

From: Keith Moore <[email-masked]>
Date: Mon, 28 Apr 2003 13:21:03 -0400

> been a disaster without it,

IMHO, the net is a disaster with RFC 1918.  We've got no way to tell for
sure what would have happened had we not approved 1918.  My guess is
that it would have made NATs a tad more difficult to deploy in large
numbers, and it would have increased the rate of v4 prefix consumption. 
Whether or not this would have increased demand for v6 is anybody's
guess.  It might even have increased demand for v6 to the point that
we'd already be stuck with site-locals and A6 records and other
unfortunate choices.

> routing simplification. 

...and more complications for applications... 

> Only by removing both of them can you simplify things.

As long as you only use link-locals for a small number of network
configuration functions, and apps aren't ever expected to use them, I
don't see v6LL as a problem.  Of course I bought a similar argument
about 1918 - that it would stay within intended usage -  and I was wrong
there.  

Ultimately, I don't think there's any way to discourage people from
doing shortsighted things.  The best we can do is to try to provide
farsighted ways to do those things.

> to zero (and essentially would be zero if we eliminated multi-site
> nodes from the architecture).

Disagree.  I think we can effectively eliminate both as far as apps are
concerned, even if we keep LL for network configuration and deprecate
SL.

Keith

---

From: Andrew White <[email-masked]>
Date: Tue, 29 Apr 2003 12:37:02 +1000

> to zero (and essentially would be zero if we eliminated multi-site nodes

Where multi-site means nodes that are simultaneously operating in two
(potentially) overlapping address spaces distinguished from each other only
by a 'site identifier'?

-- 
Andrew White

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 29 Apr 2003 10:20:29 -0500

> to give each a subnet even if you have the space to do it.

Why on earth not?  You give them one "thing" either way.  Same
overhead to issue, same overhead to route.

> because a second IPv4 address is hard to come by.

This is not the least bit believable.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 29 Apr 2003 19:11:11 -0500

Thus spake "John C Klensin" <[email-masked]>
> It seems to me that if you, or anyone else, wants to make the
> case that the IPv6 address space isn't going to be large enough,
> you need to do so explicitly and immediately (five years ago
> would have been better, but maybe we know more now).   While I,
> personally, would have preferred extendable length addresses, it
> feels to me that saying "yet" at this stage in the game is just
> pointless sniping unless you are willing to argue for calling a
> halt at this stage and redesigning.

I see no reason to believe that the address length is insufficient on its
own; however, allocation policies and the way those bits are used may cause
exhaustion and/or a different way of looking at those bits.

Based on the number of hosts connected to the Internet today compared to the
total number of unicast IPv4 addresses, we are nowhere near a shortage.
Even so, pre-CIDR allocation policies resulted in vast amounts of unused
space.  Rationing of the remaining space has made NAT a necessary evil just
to keep the beast functional for the masses.

Are we doing the same thing with IPv6?  Maybe.  At worst, we're not making
any mistakes we can't correct later when we learn more.  I'm particularly
suspicious of the decision to use a /64 for each subnet instead of the
original /80 plan, and the allocation of a /3 to the RIRs is mind-boggling.
But I do think we bought ourselves enough headroom to seriously screw up
several times and not need a whole new protocol.

S

---

From: [email-masked]
Date: Wed, 30 Apr 2003 10:48:11 +1000

> because a second IPv4 address is hard to come by.

	There is nothing to indicate that they won't change either.

	ISP will meet their customers expectations or they will go
	out of business.  Today you expect to get a single IP address.
	If you make the expectation be that you will get a prefix ISP
	that fail to do this will go the way of the dodo.

	The cable provider I'm using didn't allow home networks at
	one time (they also had a single flat fee).  They do now
	though they leave the implementation and support to you
	(multiple volume based plans).  Customers expect to be able
	to connect their home network and the expectation is now
	being met.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [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: Michael Thomas <[email-masked]>
Date: Mon, 28 Apr 2003 13:16:11 -0700 (PDT)

> > customers, similar to IPv4 common practice.

   Network puritanism: the haunting fear that someone,
   somewhere may be happy with their own subnet.

	     Mike