Subject: Some IPv6LL operational experience

From: Joshua Graessley <[email-masked]>
Date: Wed, 20 Aug 2003 22:24:27 -0700

I realize that as an employee of a company that sells a product and 
tries to implement standards the IETF blesses to solve problems, my 
voice doesn't really count, but I wanted to toss in my two cents.

We have been using IPv6LL addresses with some success. The next release 
of Mac OS X implements something similar to LLMNR that we call mDNS 
with support for IPv6. For the time being, the only IPv6 addresses we, 
or most of our customers have, are IPv6LL addresses. This combination 
of mDNS and IPv6LL addresses works very well. IPv6LL addresses are 
important to us because a multi-homed host may not have an IP address 
on every interface. IPv4LL addresses don't work on more than one 
interface because they lack a scope id. The scope id in IPv6LL 
addresses makes them much more compelling.

IPv6LL addresses let us enable networking in situations that wouldn't 
otherwise work. For example, we've implemented IP and IPv6 over 
Firewire. In most cases, it is unlikely that an IPv4 address will be 
assigned to the IP over Firewire link. This is usually used in the 
scenario where two computers are hooked directly together. We can't 
assign an IPv4LL address to the Firewire interface because it causes a 
number of problem on a multi-homed host. The IPv6LL address is 
configured automatically and is always there. Very few people have the 
skill required to successfully type an IPv6 address, which is why the 
mDNS component is so important. In addition to allowing users the 
ability to type a name instead of an address, the question of scope id 
goes away. The name is resolved using mDNS. The scope id is derived 
from the interface the response came back from. The application is none 
the wiser because it gets a full sockaddr_in6 from the call to resolve 
the name.

Applications that perform referrals may fail, but I'm not aware of any 
of these that are currently shipping and support IPv6. IPv6 is a new 
beast, we don't have to be as concerned about applications making 
stupid assumptions. If we explain that IPv6 link local addresses work 
this way and here's a list of limitations, that's good enough. The 
advantages of IPv6 link-local addresses far outweigh the disadvantages.

IPv6LL is a major selling point. IPv6LL is a sneaky way to get everyone 
exposed to IPv6 and to encourage developers to start supporting IPv6. 
Sure, connectivity off of the local link for those of us in the US is 
only for a few elite, but IPv6 on the local link can solve real world 
problems today and work for everyone.

-josh

--------------------------------------------------------------------
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: Thu, 21 Aug 2003 09:56:19 -0400

> stupid assumptions. 

you have it exactly opposite.  one of the major drivers for IPv6 will
be apps that cannot run over IPv4+NAT, and an important class of these
will be apps that do referrals.  and the stupid assumptions that are being
made is by people who think that IPv6 apps don't need to do this, and by
people who think that currently shipping IPv6 apps are representative
of future usage of IPv6.  

> If we explain that IPv6 link local addresses work 

you made similar arguments for v4 link-local addresses, and you were wrong
there also.

v6 link-locals make good sense as a mechanism to provide uniform 
(independent of link technology), inherently link-local services,
like ND/RA.  they are usable by a limited class of applications, but
not applications in general. 

> exposed to IPv6 and to encourage developers to start supporting IPv6. 

great.  let's encourage people to use IPv6 in a dysfunctional way, one that
only works for a limited subset of apps, so that they'll never be able to
realize the real advantages of IPv6. 

I'm all for enabling ad hoc networks, and I'm all for enabling link-specific
applications.  But trying to overload IP to do these is doing real harm.  
There's nothing wrong with using the packet format on an ad hoc network, the
problem is it's the expectation that apps have that IP equates to Internet
access.  An ad hoc network is a different beast than the Internet and you
can't expect apps in general to transparently work on both kinds of network.
At the very least you need an API to allow apps to declare whether they work
on one kind or both.  And the default needs to be the Internet.

> only for a few elite,

until native v6 service is available, anybody can still run 6to4.

Keith

---

From: Mika Liljeberg <[email-masked]>
Date: 21 Aug 2003 21:18:17 +0300

On Thu, 2003-08-21 at 16:56, Keith Moore wrote:
> An ad hoc network is a different beast than the Internet and you

Nevertheless, this is exactly what users expect. Therein lies the
challenge.

	MikaL

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 21 Aug 2003 12:30:13 -0700

Hello Keith,

Something is wrong with the way you seem to be using the term
"ad hoc" network.  It doesn't have to be a single link.  There are
lots of reasons to have a multihop/multi-technology ad hoc network.

Thus when I see:

>applications.  But trying to overload IP to do these is doing real harm.
I wonder just what you might mean.  IP is very good for forwarding 
packets in a
multihop network.

>access.
I thought apps were supposed to care about end-to-end data exchange, 
regardless
of whether the data is exchanged over one or many links.

>can't expect apps in general to transparently work on both kinds of network.
That's news to many people in the [manet] group!  Why not??

>on one kind or both.  And the default needs to be the Internet.
I also can't understand this.

Regards,
Charlie P.

---

From: Keith Moore <[email-masked]>
Date: Thu, 21 Aug 2003 15:51:19 -0400

> lots of reasons to have a multihop/multi-technology ad hoc network.

I agree entirely that it's not desirable to expect ad hoc networks to
be a single link.  However, the proposals for ad hoc networks I've seen
tend to use ambiguous, and often link-local, addressing.  

The zeroconf group attempted to justify v4LL addressing by saying it was
for ad hoc networks; now we see people trying to justify application use
of v6LL in ad hoc networks.  Both are highly dysfunctional (v6LL is not
quite as bad as v4LL, but still not generally usable).

> >There's nothing wrong with using the packet format on an ad hoc
> >network, the problem is it's the expectation that apps have that IP
> >equates to Internet access.
> >
> regardless of whether the data is exchanged over one or many links.

Apps care about more things than end-to-end data integrity.  Some apps
care about having consistent view of addressing across all locations in
the network.  Some apps also care about having consistent naming
across all locations in the network.  IMHO IP-based ad hoc networks need
to provide both of these in order to be viable.
--------------------------------------------------------------------
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: Thu, 21 Aug 2003 20:16:50 -0400

I strongly disagree that this practice adds value to IPv6.  IMHO it has the
potential to do a great deal of harm.  It is even worse that NAT.

Did we go to all of that trouble to deprecate SL only to find that people will
now insist that LLs are generally usable by apps?

If we're going to make IPv6 even less predictable and less functional than
IPv4, why did we bother?

Keith

> Thanks for describing this.  The local discovery and communication problem 
> is important.  I also think this is an important approach because it uses 
> IPv6 in a local environment in a way that adds value without the need for 
> it to be available globally.  It adds value without the need for everyone 
> else to do it first.

---

From: Andrew White <[email-masked]>
Date: Fri, 22 Aug 2003 18:03:45 +1000

Keith Moore wrote:

> Some apps care about having consistent view of addressing across all
> locations in the network.

The trouble is that while filters exist this will NEVER be true, in the
general case.  Having multiple addresses per host confuses the issue as
well.

Similarly, the arguments about rescinding 'scope' are bogus.  Every
address is functionally scoped.  In an extreme model, 'scope' can even
vary dynamically as (say) links fail and recover.  What we really need to
consider is:

* Are there sensible ways of communicating 'scope' information of addresses
to applications? (I expect the answer is 'not easily' for the general case).

* Is there benefit in having classes of addresses with inherent scope
limitations (eg link-local, local)?

Note that any application CAN discover whether it is within the functional
scope of any given address - it tries to use it.  If not done cleverly, this
can cause significant delays and/or traffic, but the option is certainly
there.

In closing, three guidelines / work items:

* Applications should not assume that all addresses are equal.

* Applications should not assume that addresses can be forwarded at-will,
unless provided with additional (configured?) information that would support
this assumption.

* Applications that do not care to do their own address management need a
higher level abstraction to the current sockets and getaddrinfo APIs.

-- 
Andrew White

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Aug 2003 07:34:30 -0400

> general case. 

filters don't mess up addressing.  ambiguous addresses do.

> * Applications should not assume that all addresses are equal.

applications should not have to know which addresses are more equal than
others.

or to state this better, it's fine if apps simply avoid passing some kinds of
addresses around as long as they can easily tell which ones to pass around and
which ones to not pass around.  it's not fine if there's not an
easily-identifiable, portable address available for every host that is
expected to work with an app.

> unless provided with additional (configured?) information that would support

applications should be able to forward addresses to other hosts; this is an
essential capability.  that doesn't mean that they can expect those addresses
to be usable from remote locations.  but if they're not usable, the reason
should be either network failure or administrative prohibition - in other
words, something that the app should not be expected to work around.

> higher level abstraction to the current sockets and getaddrinfo APIs.

not sure what you mean by this.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 22 Aug 2003 09:47:47 -0700

Keith Moore wrote:
> or to state this better, it's fine if apps simply avoid 
> passing some kinds of addresses around as long as they can 
> easily tell which ones to pass around and which ones to not 
> pass around.  

Yet you want to ban apps from recognizing the defined flags FE80, FEC0,
FC00, ...
I am having a hard time following your logic. 

> it's not fine if there's not an 
> easily-identifiable, portable address available for every 
> host that is expected to work with an app.

2::/3 ??? Or are you talking about portable as in PI? 

> 
> > * Applications should not assume that addresses can be forwarded 
> > at-will, unless provided with additional (configured?) information 
> > that would support this assumption.
> 
> applications should be able to forward addresses to other 
> hosts; this is an essential capability.  that doesn't mean 
> that they can expect those addresses to be usable from remote 
> locations.  but if they're not usable, the reason should be 
> either network failure or administrative prohibition - in 
> other words, something that the app should not be expected to 
> work around.

So there should only be a single address per host, or all addresses must
have exactly the same policy and reachability characteristics??? This is the
limitation of the IPv4 world. There is nothing preventing an app from
continuing down that path. Unfortunately there are some who want to preclude
anyone else from taking a different path.

> 
> > * Applications that do not care to do their own address management 
> > need a higher level abstraction to the current sockets and 
> getaddrinfo 
> > APIs.
> 

Not to put words in Andrew's mouth, but I suspect he meant 'if it is more
complex than the app wants to deal with, let the stack take care of it'. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Aug 2003 13:20:39 -0400

> Yet you want to ban apps from recognizing the defined flags FE80,
> FEC0, FC00, ...

more precisely, I want to discourage the expectation that apps can make
do with *just* these.   and if apps have more portable addresses
available to them, why should apps deal with these at all?

> 2::/3 ??? Or are you talking about portable as in PI? 

portable as in uniquely identifying every host that is participating in
the app, and being usable to reach any of those hosts from any of those
hosts if such communication is permitted.

> So there should only be a single address per host, or all addresses
> must have exactly the same policy and reachability characteristics???

more or less.  I'm still trying to formulate a precise statement of
this that accomodates renumbering, multihoming, local addressing, ad
hoc networks, etc.

> This is the limitation of the IPv4 world. 

it's not a limitation,  it's a feature.  and while it was never mandated
in the v4 world, having multiple interfaces per host turned out to cause
problems when it mattered which address you used, so people tended to
avoid doing so except in special cases.

> There is nothing preventing
> an app from continuing down that path. Unfortunately there are some
> who want to preclude anyone else from taking a different path.

some people don't want a predictable environment for applications; or
they want to limit the kinds of apps that can be supported.  one could
conclude that they want to harm the ability of the Internet to support
new apps, or to reduce the size of the market for new apps.  I prefer to
think of them as just naive and/or obtuse.

> Not to put words in Andrew's mouth, but I suspect he meant 'if it is
> more complex than the app wants to deal with, let the stack take care
> of it'. 

the important thing is giving apps a model they can work with.  but it's
not clear you can solve these problems in the stack any better than you
can in the app.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 22 Aug 2003 11:09:29 -0700

> available to them, why should apps deal with these at all?

Some apps should simply ignore them. Some apps would like to leverage them
to solve problems that are not possible when limited to a single globally
reachable address.

> ...
> more or less.  I'm still trying to formulate a precise 
> statement of this that accomodates renumbering, multihoming, 
> local addressing, ad hoc networks, etc.

In other words we should not allow IPv6 to have any more capability than
IPv4 with more bits.?.?.

> it's not a limitation,  it's a feature.  

Ok, call it a feature, but it is one that we need to leave behind because it
constrains the kinds of problems we can solve. 

> and while it was 
> never mandated in the v4 world, having multiple interfaces 
> per host turned out to cause problems when it mattered which 
> address you used, so people tended to avoid doing so except 
> in special cases.

Look around, those special cases are becoming the norm. Portable devices
have multiple different interface types, and the reachability
characteristics of those interfaces is very different. By insisting on a
flat space, you preclude the ability to have the flags above available to
sort out which interfaces might be appropriate for which uses. 

> some people don't want a predictable environment for 
> applications; 

No, they want a predictable way for apps to deal with the reality of the
underlying network.

> or they want to limit the kinds of apps that 
> can be supported.  

No, they want to expand the kind of apps to include those that are not
possible with a monolithic view of the world. 

> one could conclude that they want to harm 
> the ability of the Internet to support new apps, or to reduce 
> the size of the market for new apps.  I prefer to think of 
> them as just naive and/or obtuse.

One could also conclude that IPv6 won't reach its full potential until a new
generation of app developers are free to explore the space beyond the
boundaries of 20 year old technology restrictions.

Tony

---

From: Joshua Graessley <[email-masked]>
Date: Fri, 22 Aug 2003 11:52:45 -0700

> people who think that currently shipping IPv6 apps are representative

That is your opinion, and you're welcome to have an opinion. I do wish 
you wouldn't bash it over the head of anyone with a differing opinion 
and use it to derail IETF working groups.

Is it invalid to base assumptions on what can be observed? IPv6 has 
been deployed for a while now. There are applications that support 
IPv6. This applications work well with IPv6. This applications have to 
deal with IPv6LL addresses because IPv6LLs have existed for as long as 
most stable implementations have existed. I'm not sure why you are so 
concerned about the negative impact of IPv6LL addresses when almost 
every shipping implementation of IPv6 has implemented IPv6LLs and no 
one has had serious problems with them.

In my opinion, speculating on the wonderful ways that IPv6 could be 
used (but isn't presently) and making assumptions that the ways in 
which IPv6 might possibly be used and outlawing any other uses is a 
foolish thing.

My posting to this list was not intended to elicit so many responses 
and drive the working group in to another mindless yelling match. I 
wanted to share my experience. We have found a real world use for 
IPv6LLs. It works, it doesn't appear to cause any harm. With our use of 
mDNS, it is nearly transparent to most applications.

If you try to remove IPv6LL you will get push back from the industry. 
If you try to deprecate APIs, such as removing the scope id, when there 
is no clear reason why, you will get push back. This working group may 
do these things to satisfy the loud and obnoxious people on the list. 
It will drive the IETF further in to irrelevancy as vendors stop paying 
attention to and participating in the IETF. These are not threats, 
these are observations.

> you made similar arguments for v4 link-local addresses, and you were 

Again, that is your opinion. The major difference between IPv4LL and 
IPv6LL is that IPv6LL is a part of IPv6 from the start. There are no 
applications that are developed for IPv6 that don't experience IPv6LL 
addresses. It doesn't matter how the developer tests the application, 
if there are any IPv6 addresses, there will be an IPv6LL addresses. If 
a developer runs in to problems, the developer will work around them or 
suffer public humiliation and financial ruin when they release a 
sub-par product. Pointing the finger and saying "I can't make it work 
because there's this extra address there that's easy to identify as 
link-local and I just can't figure out how to ignore it" isn't going to 
cut it.

> not applications in general.

Does it not make sense to use them in that "limited class of 
applications"? They sure work well for ssh, even when the rest of the 
network is falling apart. As long as there are link-locals and the 
local link is working, ssh can work. http will work as well, along with 
many network file systems and games.  To suggest that the use of IPv6LL 
for anything other than ND/RA is unholy is just ridiculous.

> realize the real advantages of IPv6.

How is it dysfunctional? It solves real problems and it works. Stop 
driving this working group in to the weeds Keith.

Quite often, you compare the harm this will cause to the harm that NAT 
causes. I don't think you're right, but if you are, I suggest you start 
taking a different approach. NAT is a huge pain. The biggest pain stems 
from the fact that the IETF shunned the idea instead of embracing it. 
Instead of developing a standard so that all NATs behave the same, the 
IETF ignored NATs. NATs are very popular because they solve a problem. 
If the IETF had blessed NAT we may have consistent behavior in NATs and 
we may have a standard method of poking holes through NATs to make peer 
to peer applications, such as video chat, work.

I've said it before and I'll say it again. IPv6LLs are useful. We will 
use them. The industry will use them. There is nothing you can do to 
prevent that, just as there is nothing you can do to stop the spread of 
NATs. Embrace it, and you may just have an opportunity steer it in a 
direction that will be less destructive. Condone it and you will lose 
control.

> network, the

No they can't. A large number of people use NAT. You can't use 6to4 if 
you're stuck behind NAT. Oh, that's right, NAT doesn't fit in to your 
model of the internet.

-josh

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Aug 2003 14:56:41 -0400

> Some apps should simply ignore them. Some apps would like to leverage
> them to solve problems that are not possible when limited to a single
> globally reachable address.

I don't object to that.  I do object to treating LL as if they were 
generally applicable, or expecting apps to be able to use them and
saying that networks don't need portable addresses.

> > > So there should only be a single address per host, or all
> > > addresses must have exactly the same policy and reachability 
> > characteristics???
> > 
> In other words we should not allow IPv6 to have any more capability
> than IPv4 with more bits.?.?.

You have a strange notion of capability.  You seem to want to claim that
a less functional and less predictable network, one that supports fewer
apps and imposes more constraints on those it does support, has more
capability.

> Ok, call it a feature, but it is one that we need to leave behind
> because it constrains the kinds of problems we can solve. 

Nope.  Expecting apps to use scoped addresses constraints the kinds of
apps we can run.

> Look around, those special cases are becoming the norm. Portable
> devices have multiple different interface types, and the reachability
> characteristics of those interfaces is very different. By insisting on
> a flat space, you preclude the ability to have the flags above
> available to sort out which interfaces might be appropriate for which
> uses. 

I certainly acknowledge the existence of such devices; I have one on my
desk.  And I don't claim that it's easy to deal with having multiple
interfaces.  But having scoped addresses only makes the problem worse.
Nor do the flags help an app sort out which is appropriate to use.
So by all means let's try to solve the problem of hosts with multiple
interfaces, but let's not try to make our task even more difficult by
insisting that apps support ambiguous addresses or addresses with
inherently limited reachability.

> > > an app from continuing down that path. Unfortunately there are
> > > some who want to preclude anyone else from taking a different
> > > path.
> > 
> No, they want a predictable way for apps to deal with the reality of
> the underlying network.

Or they want to say that it's okay for the network to impose a version
of "reality" that doesn't adequately support apps. 

> possible with a monolithic view of the world. 

Or they want to make the network so unpredictable that the market for
apps is fragmented - some apps can work in one kind of network, some in
another.

Look - the whole idea of IP is that the apps don't concern themselves
with routing, and the network doesn't concern itself with data.
trying to take away this separation of function doesn't make the network
more flexible, it makes it less flexible.  And it doesn't allow the
network to support more apps, it reduces the number of apps that the
network can support.  It balkanizes the network.
 
> One could also conclude that IPv6 won't reach its full potential until
> a new generation of app developers are free to explore the space
> beyond the boundaries of 20 year old technology restrictions.

You're trying to cast the most important design feature of the Internet
as a technology restriction.   Forgive me if I'm not sympathetic.

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 22 Aug 2003 12:33:27 -0700

Keith Moore wrote:
> ...
> but let's not try to make our task even more difficult by 
> insisting that apps support ambiguous addresses or addresses 
> with inherently limited reachability.

For one ambiguity and reachability are different concepts, and for two there
is no ambiguity required. It may happen, so we need to provide ways to
remove or deal with it when it does.

> ...
> Or they want to say that it's okay for the network to impose 
> a version of "reality" that doesn't adequately support apps. 

The network connectivity is reality. If the app doesn't work in that
reality, it simply doesn't work. Expecting the network to be globally
accessable and flat is not reality.

> Or they want to make the network so unpredictable that the 
> market for apps is fragmented - some apps can work in one 
> kind of network, some in another.

Such is life. The network connectivity will not change, so the best we can
do is provide hints to the app about how to deal with it.

> 
> Look - the whole idea of IP is that the apps don't concern 
> themselves with routing, and the network doesn't concern 
> itself with data. trying to take away this separation of 
> function doesn't make the network more flexible, it makes it 
> less flexible.  And it doesn't allow the network to support 
> more apps, it reduces the number of apps that the network can 
> support.  It balkanizes the network.

Balkanization is derived from both policy and technology and has happened
even with the separation. Allowing the apps to have a hint about what is
happening down below is not going to make a difference to that. Apps can
choose to continue with the separation model, and they will work wherever
they work. Other apps can choose to pay attention to the hints and find ways
to work around and within the reality of connectivity.

Tony

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Aug 2003 16:26:06 -0400

> Is it invalid to base assumptions on what can be observed?

Yes, if you fail to consider the limitations of your observations.  

Most of the apps that exist today for IPv6 are just conversions of IPv4
apps - they are not representative of what can be done with IPv6.  It's
not even appropriate to judge the future of IPv4 based on current IPv4
applications.  The way that the network is used keeps changing.  For
instance, p2p file transfer is a much bigger deal now than it was a
couple of years ago.  Why do you think it's reasonable to make the same
error in predicting IPv6 usage, when IPv6 has far less deployment or
usage history on which to base any extrapolation?

> which IPv6 might possibly be used and outlawing any other uses is a 

The whole purpose of the Internet is to support diverse applications -
and yes, this includes apps that neither you nor I know about.  It's not
"foolish" to consider the needs of such apps, it's realistic.  What's
foolish is to assume that everyone uses the Internet, now and in the
future, exactly like you've seen it used within your limited experience.

> IPv6LLs. It works, it doesn't appear to cause any harm. With our use
> of mDNS, it is nearly transparent to most applications.

And you failed to realize that it causes problems in wider use.
When someone points this out to you, rather than getting a clue, you try
to discredit them.  Denial is not in anyone's interest.

Did it occur to you that your emperical testing is inherently biased
toward apps that don't have problems?  Did it occur to you that "most"
present applications that you've seen are not representative of anything
else?  Certainly not "all" applications or "all useful" applications or
"most" apps that others are or will be using, or "future" applications.

> If you try to remove IPv6LL you will get push back from the industry. 

Who said anything about removing IPv6LL?  But if the industry is trying
to push LL for general purpose use they damn well should get pushback.

Why are you trying to defend industry shortsightedness?

> If you try to deprecate APIs, such as removing the scope id, when
> there is no clear reason why, you will get push back. 

Nobody said anything about doing that either.  We just need to realize
that it's of very limited utility.

> This working
> group may do these things to satisfy the loud and obnoxious people on
> the list. 

Which loud and obnoxious people - those who are trying to make the
Internet safe for apps or those who keep trying to insist that
IETF bless whatever dysfunctional practice they're trying to push in
products?

The IETF does not exist to bless stupidity or shortsightness.

> It will drive the IETF further in to irrelevancy as vendors
> stop paying attention to and participating in the IETF. These are not
> threats, these are observations.

Who is being irrelevant - the industry that fails to realize the
consequences of its actions, or the people in IETF that try to explain
these consequences but keep getting rebuffed by people who insist that
"it just works" based on an inadequate amount of testing?

> The major difference between IPv4LL and 
> addresses.

Yes, and this *is* better than IPv4LL.  (though it's not the only major
difference - ability to have multiple addresses per interface is
significant also).  

But the point is that v6LL was not intended for, and is not suitable
for, general use by apps.  It's intended for specialized use by
specialized apps - as an alternative to every link layer having to
define its own way to propagate reachability and routing information.

> a developer runs in to problems, the developer will work around them
> or suffer public humiliation and financial ruin when they release a 
> sub-par product.

Meanwhile, the v6 net is screwed up worse than the v4 net with NATs. 
I'm perfectly willing to let commercial developers live or die by the
products they produce.  But I'm not willing to let developers take the
net down with them.  At least, not without a fight.

> Pointing the finger and saying "I can't make it work 
> link-local and I just can't figure out how to ignore it" isn't going
> to cut it.

Ignoring such addresses is fine.  But we have people arguing that it's
reasonable to expect apps in general to use these things.  Apps can't
ignore those addresses if they're expected to use them.

> local link is working, ssh can work.

Sure!  Knock yourself out.  I certainly have used ssh with LL addresses,
once or twice.

> http will work as well,

Maybe, as long as you don't do redirects.

> along
> with many network file systems and games.  To suggest that the use of
> IPv6LL for anything other than ND/RA is unholy is just ridiculous.

It's the other way around.  You're saying "there are limited cases where
LLs work".   I'm saying "they weren't designed for this purpose, there
are lots of cases where LLs won't work, so don't count on LLs working
in general, and don't encourage people to use LLs in general".

What's your objection to telling the truth?

> > great.  let's encourage people to use IPv6 in a dysfunctional way,
> > one that only works for a limited subset of apps, so that they'll
> > never be able to realize the real advantages of IPv6.
> 
> How is it dysfunctional? It solves real problems and it works. 

It works in a pinch, sometimes, but it also causes lots of apps to
fail.

> Stop driving this working group in to the weeds Keith.

In case you haven't noticed, I'm trying to get it back on the road - the
road that leads to a generally useful network that can support a wide
range of apps.  Trying to make scoped addresses generally applicable is
a lot like being off in the weeds, because that path won't get us
anywhere useful, and all it will do it frustrate those who try to follow
it.

> NAT is a huge pain. The biggest
> pain stems from the fact that the IETF shunned the idea instead of
> embracing it. 

That's because there's no way to make NATs work well.  They're
inherently broken.

> Instead of developing a standard so that all NATs behave
> the same, the IETF ignored NATs.

Wrong.  If all NATs were alike we'd still have most of the same
problems.

Your efforts to blame industry mistakes on IETF aren't going to
accomplish anything that's technically useful, so please take it
elsewhere.  

> prevent that, just as there is nothing you can do to stop the spread
> of NATs. Embrace it, and you may just have an opportunity steer it in
> a direction that will be less destructive. Condone it and you will
> lose control.

You can't fix something that's fundamentally broken, and life is much
too short to waste your time trying to do so. Indeed, the reason I'm
trying to fix IPv6 is that IPv4 is already hopeless.

You keep talking as if the industry is going to screw the net anyway,
and you might be right. But if I were to accept that argument, it would
be like accepting your argument that we can all extrapolate how well
IPv6LL works in general from your limited experience with it.  There's
simply no justification for either conclusion. 

> you're stuck behind NAT. Oh, that's right, NAT doesn't fit in to your 

They need a NAT that runs 6to4.  I have one at home, so it's clearly
possible.  Or maybe noncommercial products don't fit into your model of
the Internet?

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Aug 2003 16:35:38 -0400

> For one ambiguity and reachability are different concepts, and for two
> there is no ambiguity required. It may happen, so we need to provide
> ways to remove or deal with it when it does.

for LL as currently defined, ambiguity is part of the equation. another
kind of address might provide a way to resolve that ambiguity.

> reality, it simply doesn't work.

networks are designed to support apps.  it's not as if apps can tolerate
arbitrary amounts of delay, loss, jitter, etc.  providing sane
addressing is just another aspect of good network design.

> Expecting the network to be globally

the network has never been flat in reality, but part of the purpose of
IP has always been to provide the illusion of a flat network.  we're
also a long way from any time when it could be expected that every host
in the network could access any other host in the network, but nobody's
asking for that now (and I wish you'd stop claiming that people were).

> Balkanization is derived from both policy and technology and has
> happened even with the separation. 

just because it has happened to some degree is not a justification for
making it worse.

> Allowing the apps to have a hint
> about what is happening down below is not going to make a difference
> to that.

yes, it can - because it's a slippery slope from saying "here's a hint"
to "it's okay to do this".  and the hints aren't of much use to the apps
unless it's to say "it's okay to ignore these addresses".  what you're
arguing is that it's not okay for apps to ignore these addresses - and
that makes the hints irrelevant.

the network has a job to do.  there's a separation of function between
the network and apps inherent in the end-to-end model.  if the network
fails to do its job, it's not as if the apps are in a good position to
take over.  what you end up with is a lot of complexity and guesswork
on the part of the apps in order to get less functionality, less
reliability, more slowly.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 22 Aug 2003 13:47:10 -0700

Keith Moore wrote:
> ...  What's foolish is to assume 
> that everyone uses the Internet, now and in the future, 
> exactly like you've seen it used within your limited experience.

Yet you want to do exactly that by insisting that all apps for all time want
to view the network as a globally flat-routed space.

> The IETF does not exist to bless stupidity or shortsightness.

I couldn't have said it better myself.

> Maybe, as long as you don't do redirects.

Redirects work fine if they are based on names rather than literals.

Tony

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Aug 2003 16:59:40 -0400

> Yet you want to do exactly that by insisting that all apps for all
> time want to view the network as a globally flat-routed space.

I have yet to see anything that would justify changing this fundamental
design feature of IP.

> I couldn't have said it better myself.

glad you agree :)

> Redirects work fine if they are based on names rather than literals.

nope, that just causes a different set of failures under different
circumstances.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 22 Aug 2003 14:13:04 -0700

Keith Moore wrote:
> for LL as currently defined, ambiguity is part of the 
> equation. another kind of address might provide a way to 
> resolve that ambiguity.

There is nothing about the address type the creates ambiguity. These
addresses are not meant to be used off of the current link. That means not
forwarding packets containing them to other links (including in the content
part). Since the routers will only see the headers, it becomes the
application's responsibility to keep them on-link. If the application can't
do that it simply can't put them in packets.

> networks are designed to support apps.  it's not as if apps 
> can tolerate arbitrary amounts of delay, loss, jitter, etc.  
> providing sane addressing is just another aspect of good 
> network design.

Networks and applications are designed to allow people to accomplish tasks.
Sometimes the network designs are focused on very specific tasks and the
applications needed to accomplish them. The fact that other apps are run on
that same network is an artifact of the flexibility of IP. Trying to require
the network to be designed to optimally support the other apps is not
realistic.

> the network has never been flat in reality, but part of the 
> purpose of IP has always been to provide the illusion of a 
> flat network.

That would be the purpose of the illusionary session layer ...

>  we're also a long way from any time when it 
> could be expected that every host in the network could access 
> any other host in the network, but nobody's asking for that 
> now (and I wish you'd stop claiming that people were).

'networks are designed to support apps. ' appears to be demanding that the
network provide global accessibility.

> ...
> yes, it can - because it's a slippery slope from saying 
> "here's a hint" to "it's okay to do this".  and the hints 
> aren't of much use to the apps 

For the apps you care about, maybe, but that does not represent all apps. 

> unless it's to say "it's okay to ignore these addresses". 
>  what you're arguing is that it's 
> not okay for apps to ignore these addresses - and that makes 
> the hints irrelevant.

It is not ok to ignore them, but it is ok to use the hint in prioritizing.
Some apps will want to prioritize them high while others like your favorites
will want to prioritize them low. Refusing to allow them to be used only
ensures that app doesn't work without explicit manual intervention. Since
many of the target environments are trying to avoid explicit manual
intervention, they need to be used.

Tony

---

From: Fred Templin <[email-masked]>
Date: Fri, 22 Aug 2003 14:35:15 -0700

Folks - do we have consensus to accept this document as an
IPv6 wg item (see below)?

Fred
[email-masked]

Subject:
I-D ACTION:draft-hain-templin-ipv6-limitedrange-01.txt
From:
[email-masked]
Date:
Thu, 14 Aug 2003 10:27:13 -0400

To:
IETF-Announce: ;

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Addressing Requirements for Local Communications 
                          within Sites
	Author(s)	: T. Hain, F. Templin
	Filename	: draft-hain-templin-ipv6-limitedrange-01.txt
	Pages		: 19
	Date		: 2003-8-14
	
The IPv6 addressing architecture specifies global and local-use
unicast addressing schemes, but provides no operational guidelines or
requirements for their use. There is a strong requirement for
addressing to support local communications within sites. Of special
interest are 'active sites', e.g., sites that are
intermittently-connected or disconnected from the global Internet,
sites that frequently change provider points of attachment, sites
that temporarily or permanently merge with other sites, multi-homed
sites, etc. This memo will discuss addressing requirements for local
communications within sites.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hain-templin-ipv6-limitedrange-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-hain-templin-ipv6-limitedrange-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-hain-templin-ipv6-limitedrange-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Aug 2003 17:55:04 -0400

> do that it simply can't put them in packets.

All well and good, until someone starts saying that it's okay to expect apps
to use v4LL addresses.

> the network to be designed to optimally support the other apps is not

Trying to require apps to run on arbitrary networks isn't realistic either. 

If you understand that you're building a network to support a very specific
set of apps, you can cut corners, but then you're responsible for whatever you
create.  it's not IETF's job to specify how that network operates or the
constraints for apps running on that network.  it's IETF's job to specify how
a general purpose network operates, and how apps need to behave if they expect
to function on general purpose networks.

> That would be the purpose of the illusionary session layer ...

uh, no.  that's what layer 3 is for.  you have heard of routing?

> network provide global accessibility.

certainly not what I had in mind.  of course if the network administratively
prevents the app from communicating, you don't expect the app to work.  but
then the responsibility is (or should be) clear.

> For the apps you care about, maybe, but that does not represent all apps. 

the apps that work with LL anyway don't need the hints.
the apps that can't work with LL could use the hints to avoid using
those addresses, but the existence of those hints doesn't help if those apps
are expected to work with LL addresses.

it's not the existence of v6 LL addresses that causes the problems, it's the
idea that they're suitable for general purpose use.

> will want to prioritize them low. 

prioritizing doesn't make the app work.  it just changes when and how the
failures are detected.

> Refusing to allow them to be used only
> ensures that app doesn't work without explicit manual intervention.

nobody has suggested refusing to allow them to be used -  what is at issue
here is whether it's okay to mislead people.

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 22 Aug 2003 15:15:34 -0700

> uh, no.  that's what layer 3 is for.  you have heard of routing?

Yes I have heard of routing. Its job is to deliver the packets between the
current attachment points. There is no requirement for L3 to maintain a
consistent flat perspective up to the app. That only happens because the app
has the illusion of a stable session identifier that it derived from L3
information that was valid at one point in time. 

> ...
> it's not the existence of v6 LL addresses that causes the 
> problems, it's the idea that they're suitable for general purpose use.
> ...
> nobody has suggested refusing to allow them to be used -  

Please get the story straight here. In that last comment they can be used,
but the prior one precludes them from being used. 

As I see it, in the absense of any other address, there is no choice so
every app must have the option to use them. With other options available,
the app should have the opportunity to decide which it wants to use based on
it operational characteristics and goals. Either way the app needs a flag to
indicate what it is dealing with. 

Tony

---

From: Bob Hinden <[email-masked]>
Date: Fri, 22 Aug 2003 17:27:48 -0700

Keith,

>potential to do a great deal of harm.  It is even worse that NAT.

"Worse than NAT".  Coming from you that must be pretty bad.....

>If we're going to make IPv6 even less predictable and less functional than

I see it another way.  It seems to me that in cases where there are no 
routers, globally assigned prefixes, DNS, servers, etc., if nodes can 
discover each others IPv6 link-local addresses and use them for 
communications, this is a good thing.  Especially when the alternative is 
for them to not communicate at all.  I think this is a very legitimate use 
of IPv6 link-local addresses and do not think we should restrict it (even 
if we could).  Note that I don't think it is trivial to do this and that 
there are no issues with the transition between this environment and a 
global environment.  Nor do I think we should put IPv6 link-local address 
in the global DNS.

My other point was that IPv6 suffers from only adding value when everyone 
else has it and there is global IPv6 connectivity.  I think it is a good 
thing if people find good uses for IPv6 with needing everyone else to have 
it first.  I think this will have the effect of getting us to global IPv6 
faster.  It give people local incentive to use it.  I think this is a good 
thing.

Bob

p.s. Please accept that we may disagree about this.

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Aug 2003 21:06:21 -0400

On Fri, 22 Aug 2003 15:15:34 -0700
"Tony Hain" <[email-masked]> wrote:

> consistent flat perspective up to the app. 

L3 makes routing look flat to the end systems.  That's its job - to steer
packets through the network.  The network is aware of topology so that end
systems don't have to be.

Of course the original design of IP routing expected end systems to be
more-or-less fixed relative to the network.  It's true that mobile/nomadic
systems aren't well-served by traditional IP routing.  That's why people
are working on mobile IP.  It's also true that ad hoc networks aren't well
served by traditional IP routing mechanisms.  Still, these are properly
L3 functionality, even if they're not well served by existing mechanisms.

> That only happens because the app

The design of both IPv4 and IPv6 uses addresses as both endpoint identifiers
(hence their use in TCP) and locators.  This was (and still IMHO is) a
reasonable compromise for hosts with fixed locations.  For mobile or nomadic
hosts you need to seperate them somehow. 

> but the prior one precludes them from being used. 

I don't know why you can't see the difference.  Why don't you go back and read
those two sentences over again and again until you get it?

> every app must have the option to use them. 

If there are no other address available, the network is dysfunctional.  This
might be an acceptable condition for a test bench, say, or while debugging a
network that is broken, or to support a few very specific apps.  It's not an
acceptable condition for normal operation.

> With other options available,

I'll certainly agree that as long as v6LL's exist, it's important to be able
to distinguish them from real addresses.   But this doesn't make them suitable
for general use.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Aug 2003 21:19:18 -0400

> "Worse than NAT".  Coming from you that must be pretty bad.....

I said that because I did a quick mental comparison of restrictions and
decided that a network using LLs was actually less functional than one using
private addresses and NAT.  

> >Did we go to all of that trouble to deprecate SL only to find that people
> >will now insist that LLs are generally usable by apps?
> >
> communications, this is a good thing. 

It might be useful for them to do so in a pinch.  That's a long way from
saying that this is a practice that we should recommend or that apps in
general should support.  (of course if the app works fine with v6LL
and no changes, there's no reason for the app to not use v6LL.  what
we need to avoid is to create an expectation that apps in general should
be able to make use of v6LL)

What we need to do is to figure out how to make such networks work well,
rather than throwing the IPv6 LL bone at them and telling them to make
do with it.

> Note that I don't think it is trivial to do this and that 

I don't think LLs belong in DNS at all.  We should not endorse multi-faced
DNS.

> else has it and there is global IPv6 connectivity.  

I disagree.  I find IPv6 extremely valuable even though I rarely use it to
connect to anyone else's machines.  It would cost me hundreds of dollars more
per month to get enough distinct IPv4 addresses to connect all of my machines
directly to the net.  

> I think it is a good 
> it first. 

I agree - as long as the widespread use of IPv6 in this way does not do much
harm to IPv6.  My assertion is that widespread use of v6LL does cause harm.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Aug 2003 21:53:16 -0400

On Fri, 22 Aug 2003 14:35:15 -0700

> IPv6 wg item (see below)?

what does it mean to do this?  

if it means we generally support the requirements, I say no.

if it means we are going to try to refine these into a set of requirements we
can agree on, I am still dubious.

it if just means that we allow the document to be renamed draft-ipv6-*
then it doesn't bother me too much one way or the other.

but I think we should leave the door open for other attempts at drafting
sets of design considerations.

and we should probably not call them requirements in any case.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Sat, 23 Aug 2003 12:36:59 -0700

Keith Moore wrote:
> L3 makes routing look flat to the end systems.  That's its 
> job - to steer packets through the network.  The network is 
> aware of topology so that end systems don't have to be.

Step back from the trees and notice the forest. The L3 attachment point of
each end system is part of the topology information. Both end sytems are
required to know that part of the topology. That is the only part of the
topology they are required to know. 

> 
> Of course the original design of IP routing expected end 
> systems to be more-or-less fixed relative to the network.  
> It's true that mobile/nomadic systems aren't well-served by 
> traditional IP routing.  That's why people are working on 
> mobile IP.  

People have to work on mobile IP, because there is nothing to isolate the
app from changes in the topology attachment point. If there had been a
session layer between the app and transport, there would be no issue with
changing attachment points or failure restoration through an alternate
prefix.

> It's also true that ad hoc networks aren't well 
> served by traditional IP routing mechanisms.  Still, these 
> are properly L3 functionality, even if they're not well 
> served by existing mechanisms.

The issue in the ad-hoc network is the limitation of a single address per
interface, coupled with apps being directly glued to transport. There is no
way for the topology attachment points to compensate for network realities
without impacting the app when they are forced to use one value at a time.
Allowing multiple addresses to exist mitigates some of the impacts of
topology change.

> > has the illusion of a stable session identifier that it 
> derived from 
> > L3 information that was valid at one point in time.
> 
> The design of both IPv4 and IPv6 uses addresses as both 
> endpoint identifiers (hence their use in TCP) and locators.  
> This was (and still IMHO is) a reasonable compromise for 
> hosts with fixed locations.  For mobile or nomadic hosts you 
> need to seperate them somehow. 

It was never reasonable for fixed hosts, as even you admit that there is no
way to sort out multiple interfaces. Much of the baggage in BGP is there to
compensate for the inability of apps to deal with multiple addresses having
different reachability characteristics. 

> ...
> If there are no other address available, the network is 
> dysfunctional.  This might be an acceptable condition for a 
> test bench, say, or while debugging a network that is broken, 
> or to support a few very specific apps.  It's not an 

This is reality for a network where 2 nodes share a link technology and
there is no infrastructure node to provide an RA to indicate any other
prefixes. You may consider it dysfunctional for the apps you want to build,
but others have apps they are building to solve the lack-of-technical-clue,
zero-infrastructure case. As long as there is a clear flag to indicate LL,
you should have no problem ignoring them. 

> > the app should have the opportunity to decide which it wants to use 
> > based on it operational characteristics and goals. Either 
> way the app 
> > needs a flag to indicate what it is dealing with.
> 
> I'll certainly agree that as long as v6LL's exist, it's 
                            ^^^^^^^^^^^^^^^^^^^^^^^
So your goal is to kill LL's???

> important to be able

If an address does not meet the needs of the application, use the provided
flag to ignore it. Trying to prevent others from using a technology that
solves their problem is simply being obstructionist. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Sat, 23 Aug 2003 15:44:11 -0400

I don't think the list is served any longer by carrying on this discusion in
public, so I'll reply privately...

On Sat, 23 Aug 2003 12:36:59 -0700

> topology they are required to know. 

[...etc...]

---

From: Leif Johansson <[email-masked]>
Date: Sun, 24 Aug 2003 11:35:35 +0200

>what does it mean to do this?  
I'd also like an answer to this question.
      
       Cheers Leif

---

From: Måns Nilsson <[email-masked]>
Date: Sat, 23 Aug 2003 15:54:33 +0200

> IPv6 wg item (see below)?

It smells of something we've already decided to reject (not as draft but as
idea.) so I am for accepting it as a wg item in order to be able to kill it
again. 
-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

---

From: Måns Nilsson <[email-masked]>
Date: Sat, 23 Aug 2003 15:11:20 +0200

> * Applications should not assume that all addresses are equal.

Do not mention the war. It is over.

---

From: Pekka Savola <[email-masked]>
Date: Sun, 24 Aug 2003 13:32:37 +0300 (EEST)

Hi,

As some others have also commented, I have serious concerns about the 
hain/templin draft.

An observation:

This document seems to take for granted that local-use addressing is 
needed.  Moreover, it lists requirements for every possible case where 
local-use address could be applied to (and, not for example, those cases 
where the local-use addressing is really necessary).

Process questions:

 1. Shouldn't we first see the requirements for site-local replacement
(and other issues) and not jump straight to the requirements for local
addressing?

 2. Then if we see that local addressing is required to do X, see that 
this document covers X adequately?

 3. Not consider those not listed in the sum-of-all-X at all? (or at 
least, make the separation what scenarios require specific features 
clearer)?

I don't send in more detailed comments on the draft, because I pretty much 
disagree with everything it says.  If we explicitly make the decision that 
local-use addressing is needed in some scenarios, I might accept that and 
review it again with that in mind.

 Just two notes:

 3.1 -- "Network managers have stated, and historical experience has 
shown, that there is a need for addresses that do not require public 
registration."  
 ==> there is no supporting evidence of this expect vague statements.  
Please be more explicit as I don't see how we can take this for given.

 3.2 "Applications require addresses that remain stable during 
intermittent connectivity, site mergers, ..."
 ==> it is not clear what you mean with stability, i.e. what the _real_ 
requirement is.  Connection survibability, or something else?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Bob Hinden <[email-masked]>
Date: Thu, 21 Aug 2003 16:45:39 -0700

Joshua,

At 10:24 PM 8/20/2003, Joshua Graessley wrote:

>I realize that as an employee of a company that sells a product and tries 
>to implement standards the IETF blesses to solve problems, my voice 
>doesn't really count, but I wanted to toss in my two cents.

I hope you were being sarcastic, but I think you voice should count a 
lot.  The goal of IETF standardization is interoperability and getting 
operational experience is very important.

>We have been using IPv6LL addresses with some success. The next release of 
>Mac OS X implements something similar to LLMNR that we call mDNS with 
>support for IPv6. For the time being, the only IPv6 addresses we, or most 
>of our customers have, are IPv6LL addresses. This combination of mDNS and 
>IPv6LL addresses works very well. IPv6LL addresses are important to us 
>because a multi-homed host may not have an IP address on every interface. 
>IPv4LL addresses don't work on more than one interface because they lack a 
>scope id. The scope id in IPv6LL addresses makes them much more compelling.
>
>otherwise work. For example, we've implemented IP and IPv6 over Firewire. 
>In most cases, it is unlikely that an IPv4 address will be assigned to the 
>IP over Firewire link. This is usually used in the scenario where two 
>computers are hooked directly together. We can't assign an IPv4LL address 
>to the Firewire interface because it causes a number of problem on a 
>multi-homed host. The IPv6LL address is configured automatically and is 
>always there. Very few people have the skill required to successfully type 
>an IPv6 address, which is why the mDNS component is so important. In 
>addition to allowing users the ability to type a name instead of an 
>address, the question of scope id goes away. The name is resolved using 
>mDNS. The scope id is derived from the interface the response came back 
>from. The application is none the wiser because it gets a full 
>sockaddr_in6 from the call to resolve the name.
>
>Applications that perform referrals may fail, but I'm not aware of any of 
>these that are currently shipping and support IPv6. IPv6 is a new beast, 
>we don't have to be as concerned about applications making stupid 
>assumptions. If we explain that IPv6 link local addresses work this way 
>and here's a list of limitations, that's good enough. The advantages of 
>IPv6 link-local addresses far outweigh the disadvantages.
>
>Sure, connectivity off of the local link for those of us in the US is only 
>for a few elite, but IPv6 on the local link can solve real world problems 
>today and work for everyone.

Bob

---

From: Keith Moore <[email-masked]>
Date: Sun, 24 Aug 2003 09:54:55 -0400

> (and other issues) and not jump straight to the requirements for local

even that seems to me to be asking the question in terms of an assumed
answer.

I want to see the questions asked in terms of real problems, not in terms
of assumed solutions.

---

From: "Tony Hain" <[email-masked]>
Date: Sun, 24 Aug 2003 13:24:45 -0700

Leif Johansson wrote:
> >>Folks - do we have consensus to accept this document as an IPv6 wg 
> >>item (see below)?
> >>    
> >>
> >

As with all working group documents, it means that the resulting text will
be something the working group has reached concensus on as worth
publication. It does not mean that the existing text will be published as an
RFC under the IPv6 WG name, but that it moves from being personal drafts
where some might not be paying attention, to a draft-ipv6 name. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Sun, 24 Aug 2003 13:24:45 -0700

Tony

---

From: Keith Moore <[email-masked]>
Date: Sun, 24 Aug 2003 16:44:50 -0400

> where some might not be paying attention, to a draft-ipv6 name. 

in that case, I don't think we should accept this as a WG document -
at least, not at this time.

I do accept it as valuable input, though not all input to a WG should be
published as an RFC.  Sometimes we publish valuable input for the historical
record, and that's a good thing to do as long as it's properly labelled.  The
time to decide on publication for that reason should be after the group has
reached consensus on technical mechanisms.
--------------------------------------------------------------------
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: Leif Johansson <[email-masked]>
Date: Sun, 24 Aug 2003 23:03:32 +0200

>be something the working group has reached concensus on as worth
I don't believe that it is possible to turn the current draft into a 
requirements
document which does not assume the outcome. Given your reply to my question
I oppose the publication of this draft as a wg document.

>where some might not be paying attention, to a draft-ipv6 name. 
Imo, you are wrong about the merit of wg status. There are several examples
in the IETF of good work beeing done as individual submission drafts. 
Its not
the filename, its what you write that matters.

          Cheers Leif

---

From: "Tony Hain" <[email-masked]>
Date: Sun, 24 Aug 2003 14:09:14 -0700

> As some others have also commented, I have serious concerns about the 

Thank you for providing constructive text, rather than simply complaining.

> where the local-use addressing is really necessary).

Necessity is both the perception of the network manager in trying to
implement a local policy, and the availability of alternatives that actually
fit all of the local constraints. 

> 
> Process questions:
> 
>  1. Shouldn't we first see the requirements for site-local 
> replacement (and other issues) and not jump straight to the 
> requirements for local addressing?

I don't understand the question. My original draft started from the premise
that the WG should at least have the requirements for local addressing
before deciding that any given technology is either acceptable or
unacceptable. Site-local is a specific technology that meets many of the
needs of local addressing, but creates other problems through its ambiguity.
Getting rid of ambiguity does not remove the requirements for local
addressing.

> this document covers X adequately?

If the goal is to design specific approaches for every scenario, then this
suggestion would be appropriate. The goal of the requirements document at
the moment is to aggregate multiple needs under a single technical approach.
If the WG decides that multiple approaches make more sense, then there will
need to be multiple requirements documents.

> least, make the separation what scenarios require specific features 

I am not sure what you are trying to say, but I think this is a continuation
of 2.

> disagree with everything it says.  

I understand your network does not have these requirements, and if we
required everyone to implement local addresses I could understand some
degree of concern. What I don't understand is why you believe it is
appropriate to tell another network manager that his stated requirements are
invalid.

> If we explicitly make the 
> decision that 

See 2 above.

> Please be more explicit as I don't see how we can take this for given.

Chasing down quotes is not appropriate. If you want to see more text about
people grabbing random space from documentation or currently using 1./8, I
suspect we can come up with that.

> requirement is.  Connection survibability, or something else?

See my note this morning about solving the right problem. Applications
frequently fail if the addresses are changed out from under them. This is
not a requirement, but a fact supported by empirical evidence. The real
requirement is that local applications continue to function even if the
external connectivity is intermittent or changing. I know you have offered
ways to mitigate the problem, but they all come with constraints that, while
appropriate for your network environment, do not meet the needs of other
networks. 

It appears you would rather do targeted engineering for individual
scenarios. We can take that approach, and will likely end up with a variety
of technologies that people then need to figure out which one(s) apply. At
the same time it is very likely that there will be a suppression of many
requirements, because the participants are either not vocal enough, or don't
represent a large enough segment of the community to deserve valuable WG
focus. Forgive me if I consider suppression of requirements to be in direct
conflict with providing solutions.

Tony

> > sites that frequently change provider points of attachment, 
> sites that 
> > temporarily or permanently merge with other sites, 
> multi-homed sites, 
> > etc. This memo will discuss addressing requirements for local 
> > Internet-Drafts are also available by anonymous FTP. Login with the 
> > username "anonymous" and a password of your e-mail address. After 
> > logging in, type "cd internet-drafts" and then
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> > 	"FILE 
> /internet-drafts/draft-hain-templin-ipv6-limitedrange-01.txt".
> >

---

From: "Tony Hain" <[email-masked]>
Date: Sun, 24 Aug 2003 14:09:14 -0700

See 2 above.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Aug 2003 16:02:22 +0200

> idea.) so I am for accepting it as a wg item in order to be able to kill it

Er, what on earth are you talking about? On the contrary, this draft is an
attempt to express what we need in place of the existing definition of SL.
That is what we've been discussing for the last many months. Tony and Fred
have written it down. I'm grateful to them and I fully support this becoming
a WG draft at this time. 

I do agree to replacing the R-word. Some people in the IETF seem to over
interpret "requirements" so we should use some other word such as "goals."

> at least, not at this time.

I think you're missing the point of the word "resulting" above. Obviously,
what would get published as an RFC would not be the current draft. It would
be whatever it turns into after WG discussion. If we don't accept this
draft, someone is going to have to write another one, and we waste yet more
time.

> reached consensus on technical mechanisms.

Yes. But that is nothing to do with accepting this draft as a WG draft. The
way to make progress is to start with this draft and improve it.

Leif Johansson wrote:
> document which does not assume the outcome. 

Perhaps that is because there is only one class of solution that
meets these important goals. If you have an alternative statement
of goals that leads to a different class of solution, please
publish your own draft.

> Given your reply to my question

I think you too have missed the point. Accepting this as
a WG draft is not the same thing as agreeing to publish it as an
RFC. It is merely using it as the starting point. (It is true that
unless the people who disagree send their own alternative text, the
draft won't change...)
> the filename, its what you write that matters.

That isn't the point here. We are halfway through the process of deprecating
SL and designing a replacement. That's by definition a WG activity. We have
a draft set of goals on the table - one draft set of goals - and until 
someobody produces an alternative set of goals, those goals are the ones
I'm looking at. 

   Brian

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Aug 2003 10:39:01 -0400

On Mon, 25 Aug 2003 16:02:22 +0200
Brian E Carpenter <[email-masked]> wrote:

>  We are halfway through the process of deprecating

I guess that's the core of the disagreement.  I don't see our task as that
of replacing SL - certainly not in terms of coming up with "a" replacement.
I recognize that SL was designed to fill certain needs - or probably closer
to the truth is that lots of folks were projecting needs onto SL.  Where
there are legitimate needs, we need to try to address them.  It's also
clear that PA addressing alone cannot meet some legitimate needs.  What's not
clear is that there is a legitimate need for "local" addressing - and stating
things in that way seems to presume a particular kind of solution that we
already know to be problematic.

Keith

---

From: Leif Johansson <[email-masked]>
Date: Mon, 25 Aug 2003 17:09:04 +0200

>of goals that leads to a different class of solution, please
Let me put it this way: I am not sure there is a problem here to solve. 
I expected
to read a draft explaining what the problem is we are trying to solve 
with "scoped"
addresses. The draft (imo) lumps together several problems most of which 
can be
solved by other means in an effort to justify limited range addresses. 
So, no I
don't intend to write a scoped-stuff-draft of my own. Patrik posed a few 
direct
questions to this effect on the list - none of which have been answered.

>unless the people who disagree send their own alternative text, the
If the diff -u is too large there is limited value in providing 
alternative text. I
agree with Pekka in disagreeing with the basic assumptions of the draft.

>someobody produces an alternative set of goals, those goals are the ones
The "and designing a replacement"-part worries me. You assume that there 
is consensus
to only deprecate SL if a replacement can be found. I am quite sure you 
are wrong in
that assumption.

       Cheers Leif

---

From: Tim Chown <[email-masked]>
Date: Mon, 25 Aug 2003 16:28:49 +0100

> to only deprecate SL if a replacement can be found. I am quite sure you 

There was a vote called on this recently.   I don't remember seeing the 
summary of the result.

Tim

---

From: Eliot Lear <[email-masked]>
Date: Mon, 25 Aug 2003 08:41:35 -0700

Fred,

> IPv6 wg item (see below)?

I'll admit to some process fuzziness here, so I'm not quite sure what's 
being asked.  If we are being asked that we agree with the content of 
the document, I'd have to say on the whole at least: not yet.  If you 
want a requirements draft, write requirements and don't wander into the 
solution space.  If you want a solutions draft, that's okay too.  Just 
don't call it a requirements document.

Eliot

---

From: Hans Kruse <[email-masked]>
Date: Mon, 25 Aug 2003 10:58:38 -0400

Actually, I think draft-hinden-ipv6-global-local-addr...  is the higher 
priority as far as becoming a WG item (or have I missed that move in the 
flurry of messages).

However, I support moving the draft below to the WG as well.  I also agree 
that it is not so much a requirements draft as a draft outlining scenarios 
that may not be readily solvable through the use of global PA address 
space.  Maybe a title like "Addressing Support for Sites without Global 
Address Space"?

> I-D ACTION:draft-hain-templin-ipv6-limitedrange-01.txt

Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax
--------------------------------------------------------------------
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: Mans Nilsson <[email-masked]>
Date: Mon, 25 Aug 2003 17:49:36 +0200

> already know to be problematic.

This is close to my perception -- which is why I somewhat harshly advocated 
for the document to be caught and non-sent to IESG. My apologies for choice
of words. 

In this situation I am pretty convinced that we have to deal with
varying cost tradeoffs more than finding Graals of address supply
management. I think that the price paid for "wasting" global address
space by filtering it off at the IGP edge in order to create
non-routed (as opposed to non-routable) address space is worth
paying.

Having recently been provoked in bit-flipping directions by external
input I do see a need for stating *why* I oppose creating dedicatedly
local addresses - it is simply going to occur crashes between mirror
worlds. The discussions on LL address usage are typical for this
-- the LL scope was created to cater to specific functions (RA et.
al.) but the distinction is blurred as soon as the notion "an address
is an address is an address and as long it is unique I can use it
pretty much as I please." takes over peoples minds. It sure has
taken over my brain and it is quite contagious, on both sides of
this long debate. Thus, there is an operational requirement to remove
potential sources of ambiguity because the usage patterns for
addresses tend to approach a state where every service may be
deployed on any address. P2P certainly is a prime example.

Good arguments have been made that this is simply a failure to release
v4 paradigms, and I'm tempted to agree -- but that does not mean
we have a solution to this except forcing uniqe address space onto users 
and programmers.
-- 
Måns Nilsson         Systems Specialist
+46 70 681 7204         KTHNOC
                        MN1334-RIPE

Are the STEWED PRUNES still in the HAIR DRYER?

---

From: Hans Kruse <[email-masked]>
Date: Mon, 25 Aug 2003 11:05:47 -0400

Hm, was the replacement not part of the consensus declaration by the 
chairs.....?

---

From: Leif Johansson <[email-masked]>
Date: Mon, 25 Aug 2003 19:14:19 +0200

>There was a vote called on this recently.   I don't remember seeing the 
The results of the vote (I'll wave the right to instigate a flame-war 
over the choice
of wording :-) ) has not been published yet, but I can count.

    Cheers Leif

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 25 Aug 2003 10:11:16 -0700

Mans Nilsson wrote:
> ... Thus, there is 
> an operational requirement to remove potential sources of 
> ambiguity because the usage patterns for addresses tend to 
> approach a state where every service may be deployed on any 
> address.

Please read the draft so that you can be on the same page as the discussion.
You will find that ambiguity is not required: 3.5 Global Uniqueness 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 25 Aug 2003 10:11:16 -0700

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 25 Aug 2003 10:44:01 -0700

Leif Johansson wrote:
> ... Patrik posed a few direct

I must have missed them, so please send a pointer to the questions.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 25 Aug 2003 10:44:01 -0700

Tony

---

From: Leif Johansson <[email-masked]>
Date: Mon, 25 Aug 2003 19:55:59 +0200

>I must have missed them, so please send a pointer to the questions.
Unfortunately there does not seem to be a hypertext archive of the list but
the post was from 2003-07-08:

=============== paf ===========

I don't know how to attack the people which talk about "intermittent 
connected networks".

The problem I see is that people are locked into the IPv4 world where a 
DSL modem have one address which might change every connect. That is 
extrapolated into one IPv6 prefix which changes every connect.

Instead, to me, the user should get the _same_ IPv6 prefix every time he 
connects. As long as one connect to the same upstream network, the IPv6 
prefix should not have to change. And, switching upstream network will 
force a switch in prefixes of course. The renumbering event comes when 
_connecting_, not disconnecting and connecting as the address can be 
kept until a new prefix is to be used.

Is this not true?

Further, we do not have a good session layer in the IETF which means a 
network _always_ have to reset the connections when a renumbering 
happens, which is the same as a more drastic network topology change 
happens. The solution to this is mobile IP.

What else? What's so difficult here?

   paf

============= paf ============

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 25 Aug 2003 11:22:14 -0700

Leif Johansson wrote:
> Unfortunately there does not seem to be a hypertext archive 
> of the list but the post was from 2003-07-08:

The manual spam filter must have fat-fingered that one into the trash ... 

> prefix should not have to change. 

I believe that most service providers are looking at this as their long term
goal, but as noted there are conflicts with their IPv4 model. 

> And, switching upstream network will 

If there is only one connection to any other network, it is possible for a
disconnected network to continue using a prefix for some time. If there is a
connection to another network and the prefix were reassigned, there is a
clear conflict that needs to be resolved. In any case, this presumes that
the network will always reconnect to the same SP, and that it is ok to
disrupt local communications whenever a connect event happens. Neither of
which are valid for all networks.

> happens. The solution to this is mobile IP.

See my note from yesterday about 'solving the real problem'. Mobile IP is a
hack to create the illusion of stability at L3. Even if we decided that was
the answer, what it means is that every local connection is created as a
mobile IP connection, because there is no guarantee that the routed prefix
won't change do to external events. While we can do that technically, there
will be many who complain about the performance hit of having to pad out
every local packet with a home address.

The application layer wants to see stability, and that is fine. The
transport layer and below deal with the reality of shifting topology. What
we need is a formal layer between transport & applications that provides the
illusion of stability up, while managing the reality of constant changes
below. I specifically used the term stabilization layer, because 'session'
appears to be a loaded term. I really don't care what we call it, but it
appears to logically exist between layers 4 & 7, because that is where the
demands/reality differ. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 25 Aug 2003 11:22:14 -0700

Tony

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Aug 2003 14:58:56 -0400

> transport layer and below deal with the reality of shifting topology.
> What we need is a formal layer between transport & applications that
> provides the illusion of stability up, while managing the reality of
> constant changes below. I specifically used the term stabilization
> layer, because 'session' appears to be a loaded term. I really don't
> care what we call it, but it appears to logically exist between layers
> 4 & 7, because that is where the demands/reality differ. 

No, it doesn't follow.

I demand that my country enforce the freedoms guaranteed in the US
Constitution; in particular the rights of freedom of speech, freedom
from unreasonable searches, equal treatment of people regardless of
race, etc.

Reality is that in many areas, local policemen deny people those rights
on a daily basis.

By your logic, what would be needed is a layer in between citizens and
their local policemen to make it look like those rights were in fact
being preserved even though they weren't.

In fact, the correct place to fix the problem isn't there - nor is it
necessarily helpful to directly attack the local police.  The problem
has to be fixed at the higher layers that are responsible for
condoning or even promoting such abuse.

(It might not be the best analogy, but it's the one that came
immediately to mind.  The point is that it's erroneous to assume that
the place where problems are experienced is the place where they need to
be fixed.)

--

You are arbitrarily calling network conditions "reality" without
recognizing application needs as "reality".  This may be why you persist
in thinking that the problem can be fixed by creating an "illusion".
What we need is not illusion, but to rearrange functionality so that
there is a good match between what the network provides and what
applications need.

Keith

---

From: Hans Kruse <[email-masked]>
Date: Mon, 25 Aug 2003 14:44:34 -0400

Let me jump in with a few observations, I am sure others will too.

1.  In the "be liberal what you accept" approach, solving a network problem 
by stating that you "should always get the same prefix" seems imprudent 
engineering.  You have to assume that the prefix for provider-supplied 
address space will change from time to time, and design your network to 
deal with that.  I am NOT suggesting that I know what the right answer is.

2.  To me the scenario that is very hard to deal with given only routable 
space is the intermittent connection case.  I think of this as a formation 
of cooperating nodes (the hain/templin draft uses a ship, but I am also 
interested in formations of data-gathering drones or satellites, or 
clusters of devices with wireless connections).  In many cases the internal 
connections within the cluster are more critical than the external ones. 
Routable PA space won't work.  Using local addresses (but not link-local, 
IMHO) is certainly one solution.  Mobile IP may work, but I am not 
convinced about that, and in any case it adds "weight" to the network and 
the nodes.

--On Monday, August 25, 2003 19:55 +0200 Leif Johansson <[email-masked]> 
wrote:

> Unfortunately there does not seem to be a hypertext archive of the list
> but the post was from 2003-07-08:
>
> _connecting_, not disconnecting and connecting as the address can be kept
> until a new prefix is to be used.
>
> Is this not true?
>

---

From: Fred Templin <[email-masked]>
Date: Mon, 25 Aug 2003 14:46:35 -0700

Just to respond to the intent of my question, I am asking for consensus to
adopt the hain/templin draft as an IPv6 wg item *so that we can revise the
document based on input from the wg as we work toward a finished product*.
There is no expectation that the document in its current form is ready 
for wg
last-call - indeed, we  anticipate one or more revision update(s) beyond the
current. IMO, wg involvement is needed to help facilitate this process.

In particular, the document focus should be on Requirements (or, as Brian
perhaps more appropriately terms them, "Goals") and Scenarios; not 
solutions.
Guidance from the wg is needed to help identify aspects of the current draft
version that don't fit in well with that focus. Again, IMO, this process 
is best
supported by adopting the hain/templin draft as a wg item, i.e., so we
can *work* on it!

Fred
[email-masked]

Eliot Lear wrote:

> I'll admit to some process fuzziness here, so I'm not quite sure 
> what's being asked.  If we are being asked that we agree with the 
> content of the document, I'd have to say on the whole at least: not 
> yet.  If you want a requirements draft, write requirements and don't 
> wander into the solution space.  If you want a solutions draft, that's 
> okay too.  Just don't call it a requirements document.
>
> Eliot
>
>

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 25 Aug 2003 15:33:12 -0700

Keith Moore wrote:
> You are arbitrarily calling network conditions "reality" 
> without recognizing application needs as "reality".  This may 
> be why you persist in thinking that the problem can be fixed 
> by creating an "illusion". What we need is not illusion, but 
> to rearrange functionality so that there is a good match 
> between what the network provides and what applications need.

That could be because applications don't 'need' stability. They want it, and
I have been trying to recognize that providing it is the result we are
looking for. At the same time, applications can be written to deal with
arbitrary disruptions and reconnection from different topology attachment
points. This makes the applications more complex, but it is technically
possible. Adding complexity to the applications does not lead us closer to
lowest cost for the overall system though, so we should be looking for ways
to mask the complexity of the shifting network topology below. 

Our overall architecture is about reasonably simple building blocks, yet
many of your arguments are about pushing complexity into those building
blocks to keep the view from above as simple as possible. I have no issue
with keeping the view from above simple, but forcing complexity into the
lower layers is not going to get us there. That is why I think we need
something specifically inserted between layers 4 & 7. Unfortunately, there
are many that consider the bond between those layers to be sacred ground.

Tony

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Aug 2003 19:26:01 -0400

> That could be because applications don't 'need' stability.

well, apps don't "need" TCP either.  they could implement all of that
themselves.  and if they don't have stability, then they end up implementing
much of TCP, along with something like mobile IP and who knows what.

yes, all of this is technically possible, but most of us realize it's pretty
suboptimal.  also, we need to be concerned about the impact on existing
software - we might could tolerate minor changes phased in over a period of
several years, but we don't want to start over from scratch.

> Unfortunately, there

there's a reason you put the wheels under the car rather than on top of it. 

Keith

---

From: Pekka Savola <[email-masked]>
Date: Tue, 26 Aug 2003 14:19:52 +0300 (EEST)

On Sun, 24 Aug 2003, Tony Hain wrote:
> > local-use address could be applied to (and, not for example, those
> > cases where the local-use addressing is really necessary).
> 
> implement a local policy, and the availability of alternatives that
> actually fit all of the local constraints.

It may not be our business to enhance misguided perceptions of the network 
managers, rather than correct them.

> I don't understand the question. My original draft started from the
> premise that the WG should at least have the requirements for local
> addressing before deciding that any given technology is either
> acceptable or unacceptable. Site-local is a specific technology that
> meets many of the needs of local addressing, but creates other problems
> through its ambiguity. Getting rid of ambiguity does not remove the
> requirements for local addressing.

The ambiguity was just one reason to get rid of site-locals, and I believe 
a non-ambiguous version is already being worked at.

However, my point is that we should not be advocating local-use addresses.  
It is far from clear where they're actually needed, and where they're 
actually the best solution.

I.e., I think there was some sort of consensus in the SF IETF meeting that 
there is a need to do at least *something* after we deprecate site-local 
addressing; there are some scenarios where SL's were being imagined to be 
used -- and now we should figure out how to address the needs of those 
scenarios *in general terms*, rather than jumping straight to the 
requirements for local addressing.  It might just be that we don't need 
local addressing in all of those scenarios (actually, I'm certain of 
that).

> If the goal is to design specific approaches for every scenario, then
> this suggestion would be appropriate.  The goal of the requirements
> document at the moment is to aggregate multiple needs under a single
> technical approach. If the WG decides that multiple approaches make more
> sense, then there will need to be multiple requirements documents.

Agree.

Note that I'm not really strongly advocating separate documents, but that
we AT LEAST figure out why such-and-such requirements are there.

> appropriate to tell another network manager that his stated requirements
> are invalid.

I do not want a cure that is worse than the disease.  That is, if we make
local-use addresses work "too well", and applicable also in scenarios
where it isn't needed -- people go for locals and not globals.  That would
be a serious disadvantage for IPv6.
 
> suspect we can come up with that.

I fail to see how this leads to the requirement for 
non-publicly-registered addresses.  What's the problem with  public 
registration?  Perhaps there is just a problem how that has been done with 
IPv4.

[snip]

---

From: "Chirayu Patel" <[email-masked]>
Date: Tue, 26 Aug 2003 20:08:57 +0530

Hi,

I am quite satisfied with the coverage of the requirements for local
addressing. That said, I have a few questions, and comments.

Questions
---------

1) What does the 3rd sentence in the 2nd para in section 3.4 mean? The
sentence I am referring to is "Given the presence of the well-known prefix, an
application that chooses to check can infer that there is an explicit....".
What does the application choose to check in this case? 

2) Section 3.5 mentions that absolute uniqueness is not required, but the
probability of collisions should be extremely low. We should add text to make
it mandatory for proposals to define following formulae:
	
	1) Formula for probability of collision when "x" networks are merged,
when "n" addresses have been chosen from the address space of "m" values.

	2) Formula for probability to choose a duplicate address after "a"
addresses have been chosen from the address space of "m". 

Presence of the formulae will allow comparing various proposals on the
uniqueness front.

Maybe we can also describe the values of x, a, and n (as proportions of m) in
this draft. I am not sure how to do it though.

3) The requirement for conflict resolution (section 3.5) through a central
registry seems to clash with section 3.1. On further thinking about it, I feel
we should change the wording of section 3.1, and not make the requirement for
not having public registration mechanism mandatory. I can't think of anything
appropriate....

4) I did not understand the requirement in section 3.6? My understanding is
that this section refers to both - PI and non-globally routed, and PI and
globally routed addresses. If this is so, can we have two subsections, and
state that PI, and globally routed is a advantageous, but a "MAY" requirement,
and if it is not satisfied, PI, and non-globally routed is "MUST".

5) I am not able to form the requirement stated in section 3.10. Can you
rephrase? In the 2nd para of section 3.10, what policies do you imply? Where
are these policies located? It also states that the policy decision moves from
the edge of the originating device. Where does it move to? I guess, I am
confused about the meaning of "policy". Once that is clear, I will get an
answer for the other questions.

6) In the summary section, modify the line about Address to say that the
"Address selection policy tables might need modifications to enable the
selection limited range address space over global addresses". Actual details
about the modifications should be specified in the proposals. 

7) In the same section, I don't quite understand the meaning of the word
"policy" in the first sentence of the 3rd para. 

   Looking a bit closely it seems that there is overuse the word policy. The
document talks of routing policy, operational policy, filtering policy,
one-size-fits-all policy, policy without any qualification in front. At a
minimum, all the usages of the word policy should have some qualification in
front.

7) A high-level comment - Maybe we should add a section that says what
information should be present in the proposals for local addresses apart from
the requirements stated in Section 3. "Probability formulae" and "Effects on
Address Selection" can go there.

8) The draft uses both the terms "limited range" and "local use". Can we
narrow down to one term as much as possible? I prefer "limited range"

Comments:
---------

1. Add a section named "MANETS", and you can put all the examples of the
MANETS (section 4.3, and section 4.4) as subsections within that section.

2. Section 4.1 can be replaced by three sections - "Border filtering",
"Maintaining confidentiality of the address space", and "Test networks".

3. Move some of the examples defined in section 3.5 to the scenarios, and
explain them in more detail. Few on top of my head are - 

	- "Home networks", 

 	- A scenario concerning applications that use IP addresses in the ACL
or 	  configuration can be added. Such applications include license
servers 	  that use the IP address, firewalls within the site, web site
access 	  	  mechanisms to allow access to only certain subnets. Since
renumbering 	  is very difficult for these cases, it is a strong case for
stable IP 		  addresses.

4. Definitions/acronyms - PI, PA, VPN, limited range

5. Move the scenario in Section 4. to a subsection (may be a subsection under
the "Home Networks" section) like all the other scenarios. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Fred Templin
>
----------------

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Aug 2003 16:39:53 +0200

How true. I'd be more than happy to forget the hain/templin draft
if we can get this agreed quickly. The IETF has developed a silly
habit of getting hung up on requirements drafts; maybe we should
just not bother.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 26 Aug 2003 09:59:07 -0700

Brian E Carpenter wrote:
> How true. I'd be more than happy to forget the hain/templin 
> draft if we can get this agreed quickly. The IETF has 
> developed a silly habit of getting hung up on requirements 
> drafts; maybe we should just not bother.

In many cases I agree. Yet one of the justifications for the vote in SF was
that 'SL did not meet the requirements', but there was no documentation of
the requirements. That is specifically why I put my initial draft together.
If we all agree that a general purpose solution to the range of problems
covered in the current draft is necessary, I for one would be happy to drop
it. Unfortunately there appear to be a persistant few that refuse to
acknowledge that some network managers are under different operating
constraints than they are.

Tony

---

From: Fred Templin <[email-masked]>
Date: Thu, 28 Aug 2003 12:31:22 -0700

OK, let's try this again. I have just posted a new version of the 
hain/templin
draft to the I-D registrar that includes updates based on change suggestions
from the wg discussion. (Special thanks to those who sent comments.) While
we await the I-D action announcement, the new version can be found at:

  http://www.geocities.com/osprey67/limitedrange-02.txt

I believe this version should address most of the concerns brought up during
the discussions and thus clear the way for the document becoming a wg item.
Otherwise, please send specific comments as to what still needs to change.

Fred
[email-masked]

---

From: "Chirayu Patel" <[email-masked]>
Date: Fri, 29 Aug 2003 09:19:05 +0530

Hi Fred,

I did a quick comparison with my set of comments, and I am happy. :-)

Just one minor point.

I had asked for adding text that would make it mandatory for each proposal to
include statistical analysis for 

	1) Probability of collision when "x" networks are merged, when "n"
addresses have been chosen from the address space of "m" values.

	2) Probability to choose a duplicate address after "a" addresses have
been chosen from the address space of "m".

I see you have added a sentence stating that proposals should include
statistical analysis. Is there any reason why you do not want to include the
above two points? 

CP

---

From: Fred Templin <[email-masked]>
Date: Fri, 29 Aug 2003 15:03:17 -0700

Chirayu,

>statistical analysis. Is there any reason why you do not want to include the

My concern was that that text was tending toward very specific 
formulation but
I am not yet convinced that it captures the necessary and sufficient 
criteria for
analysis. I believe we are in fact beginning to see a distillation of 
the criteria
through the current wg discussions, but I don't think we are quite ready 
to write
a tight formal specification - perhaps soon.

BTW, the hain/templin -02 draft update is now available at:

http://www.ietf.org/internet-drafts/draft-hain-templin-ipv6-limitedrange-02.txt

Fred
[email-masked]