Subject: RE: Some IPv6LL operational experience

From: "Bound, Jim" <[email-masked]>
Date: Fri, 22 Aug 2003 00:31:45 -0400

> Bound, Jim wrote:
> > I came here and asked a simple question.  Look what happened.
> >  In industry this would be a no brainer and most would take 
> > your view is my opinion.  Don't use these for applications. 
> 
> That is one opinion. In reality industry will build what 
> customers are paying for. If your customers are not demanding 
> network applications that work without any infrastructure, 
> you will not need to support this.

I know a few of those too and it will happen today with state at the
user level and command line interface yes.  With the
local-unicast-global address problem is gone too and LLs are not
required.  They can be annouced on ad hoc net (my definition previously
stated) per the draft too without a router via NAs and NSs by user
override command line interface which is backup to all addrconf
essentially in IPv6, but then ND, DAD, NUD, et al can be used to support
them as viable addresses avoiding the multilink problem of LLs.  

> 
> > But it has turned into another absurd avoidance of basic
> > principles because folks have their heals dug in on for some reason.
> 
> Look carefully before you speak. From another perspective, 
> those who are insisting that IPv6 not be capable of anything 
> more than the limitations of IPv4 are the ones with their 
> heals dug in.

To the contrary.  These proponents want to use LLs for what they were
mean't to do very well in an IPv6 network and avoid their limitations
where appropriate.  Not just support a free-for-all with mission
critical operational networks out of convenience.

/jim
> Tony

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 21 Aug 2003 22:00:42 -0700

Bound, Jim wrote:
> I know a few of those too and it will happen today with state 
> at the user level and command line interface yes.  With the 
> local-unicast-global address problem is gone too and LLs are 
> not required.  They can be annouced on ad hoc net (my 
> definition previously
> stated) per the draft too without a router via NAs and NSs by 
> user override command line interface which is backup to all 
> addrconf essentially in IPv6, but then ND, DAD, NUD, et al 
> can be used to support them as viable addresses avoiding the 
> multilink problem of LLs.  

So you are going to tell the army private that is ducking the barrage of
gunfire that he can get the critical info he needs from the marine he just
bumped into, if he only types these (what to him are pseudo-random) 32 hex
characters for both the src & dst. Or you are going to answer all the
support calls to Apple, MS, Palm, ... when Joe-sixpack meets his buddy and
try to connect their 802.11 capable devices in ad-hoc mode to share a file.
Get real. This is a clear capability & advantage that IPv6 brings over IPv4.
The only thing holding it back is the obstinate views of those who don't
want to make the scenarios work. After-all they don't work in IPv4, so they
must not be really needed, right???

> 
> To the contrary.  These proponents want to use LLs for what 
> they were mean't to do very well in an IPv6 network and avoid 
> their limitations where appropriate.  Not just support a 
> free-for-all with mission critical operational networks out 
> of convenience.

I admit I am tired, but I can't tell what you are saying. People want to
solve real world problems, and to a very large degree they don't know or
care how it works. Our job is to provide the tools so the vendors can build
interoperable products that solve the end user problem. Unlicensed wireless
and other non-traditional plug-n-play link types are changing the way people
expect their devices and applications to work. The application developers
that continue to insist it is 1985, where the world is a single global flat
routing space, will not be able to deliver products that solve problems in
this millennium. Those that account for the reality of the network
randomness will find a larger customer base.

Tony

---

From: Ralph Droms <[email-masked]>
Date: Fri, 22 Aug 2003 06:10:47 -0400

At 10:00 PM 8/21/2003 -0700, Tony Hain wrote:
>This is a clear capability & advantage that IPv6 brings over IPv4.

Tony - (assuming "they" == IPv6LL) can you explain why IPv6LL will work
while "they don't work in IPv4"?  My experience with IPv4LL has been
uniformly bad; I've never intentionally used an IPv4LL address and the
automatic assignment of an IPv4LL address has on several (many?) occasions
silently interfered with my ability to assign a non-LL address and use
greater internet connectivity. I will admit ignorance and am happy to hear
success stories about IPv4LL.

I don't know that some folks "don't want to make the scenario work".  I
don't understand the advantage to IPv6LL from the scenario you described.
We can assign IPv4LL addresses today in a one-link, no router ad-hoc
network.  But we have to enter the addresses manually and those addresses
get in the way when full Internet connectivity becomes available.  What's
different with IPv6LL?

- Ralph

---

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

> want to make the scenarios work. 

nope, the thing that's holding this back is the obstinate views of those who
insist, in the absence of compelling analysis to the contrary, that LL
addressing works just fine for this case.

by all means let's make ad hoc networks work reliably.  that means considering
a wide range of apps, and the boundary cases where some machines on the net
are in ad hoc mode while others are connected, and ad hoc networks that extend
beyond a single link.  don't just throw something together, claim that it
works, and ship it in products.

---

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

Ralph Droms wrote:
> Tony - (assuming "they" == IPv6LL) can you explain why IPv6LL 
> will work while "they don't work in IPv4"?  My experience 
> with IPv4LL has been uniformly bad; I've never intentionally 
> used an IPv4LL address and the automatic assignment of an 
> IPv4LL address has on several (many?) occasions silently 
> interfered with my ability to assign a non-LL address and use 
> greater internet connectivity. I will admit ignorance and am 
> happy to hear success stories about IPv4LL.

Not having been there when your interference issues occurred, I can only
guess that they were related to the default IPv4 perspective that an
interface only has one dynamic address at a time. In that environment it
takes explicit effort (user initiated or stack timer) to change the
available address. There is no such restriction in an IPv6 environment, so
the existence of an IPv6 LL can't interfere with global connectivity. In
fact it is much more likely that intermittent global access (such as
changing radio attachment points) would interfere with the stablility of an
app that is running locally.

> 
> I don't know that some folks "don't want to make the scenario 
> work".  I don't understand the advantage to IPv6LL from the 
> scenario you described. We can assign IPv4LL addresses today 
> in a one-link, no router ad-hoc network.  But we have to 
> enter the addresses manually and those addresses get in the 
> way when full Internet connectivity becomes available.  
> What's different with IPv6LL?

There is no 'get in the way' limitation. Simultaneous support for multiple
dynamically acquired addresses is a major advantage of IPv6, as it enables
scenarios that are simply not possible in the IPv4 model of a single address
at a time. What this bumps into here is the fallacious assumption by some
app developers that the routing space is globally flat, so if by chance
there is more than one address, every available address can be treated
equally. This is not a real problem in the market when only their apps fail,
but it is a real problem when they try to prevent other app developers from
taking advantage of the opportunities through limitations in the standards. 

Tony

---

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

> What this bumps into here is the fallacious assumption by some
> app developers that the routing space is globally flat, so if by
> chance there is more than one address, every available address can be
> treated equally.

Well, duh.  This is the way the Internet was designed to work.  The
Internet was specifically designed to not require apps to know about
the topology of the network.

Now if we can improve service for apps by substituting addresses while
still providing the same functionality, and if we can make this
reasonably transparent to apps, that's worth considering.  But none of
the proposals for using scoped addresses manage to do this. 

Too many people seem to forget that the purpose of the Internet is to
support a diverse set of applications.  

Keith

---

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

Keith Moore wrote:
> Too many people seem to forget that the purpose of the 
> Internet is to support a diverse set of applications.  

Yet you are in fact the one insisting on limiting that diversity. There is a
clear flag for the apps you seem to be focused on (ie: not equal FE80 or
FEC0 or FC00), but you want to preclude anyone else from being able to use
those for different kinds of apps. Instead of preventing all apps from using
them, it makes more sense to put a heath warning that any apps that pass
around addresses to third parties should not use these. Anything beyond that
is precluding diversity.

Tony

---

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

> Yet you are in fact the one insisting on limiting that diversity.

uh, no.  you're the one insisting on burdening apps with
unnecessary complexity and limiting the kinds of apps that the network
can support by encouraging networks to misuse scoped addresses.

> There is a clear flag for the apps you seem to be focused on (ie: not
> equal FE80 or FEC0 or FC00), but you want to preclude anyone else from
> being able to use those for different kinds of apps.

you know, I'm really fed up with your misrepresenting my positions.

Keith

---

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

> you know, I'm really fed up with your misrepresenting my positions.

I am not trying to misrepresent them. From my perspective, they are
frequently circular and self contradictory so I am trying to sort them out.

Tony

---

From: Fred Templin <[email-masked]>
Date: Fri, 22 Aug 2003 12:43:53 -0700

Hi Ralph,

I think I'm beginning to notice a trend in these discussions. There seem to
be strong arguements against site-local addresses, link-local addresses,
multi-addressing, and even "limited-range" addresses such as those
proposed in the Hinden/Haberman draft. Without any of these options,
it seems to me that all we would have left to consider would be globals.

But, how can a host get a global if it comes up in an ad-hoc network with
no router? The only option I can see is for the host to have a "burned-in"
global address that comes from, e.g., a centralized addressing authority and
is assigned, e.g., by the manufacturer, by the user's manual configuration,
etc. So, the global would be just like a MAC address in this sense - right?
This would all be fine, but we are hit once again with the question of
how this would impact routing scalability. Any ideas?

Fred
[email-masked]

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sat, 23 Aug 2003 07:58:29 +0900

And what about privacy then ? I agree there is a balance between privacy and features, always, but ...

Regards,
Jordi

----- Original Message ----- 
From: "Fred Templin" <[email-masked]>
To: "Ralph Droms" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, August 23, 2003 4:43 AM
Subject: Re: Some IPv6LL operational experience

> > get in the way when full Internet connectivity becomes available.  What's

*****************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on-line at:
http://www.ipv6-es.com

---

From: Ralph Droms <[email-masked]>
Date: Sun, 24 Aug 2003 13:14:53 -0400

>app that is running locally.

Certainly some of my problems with IPv4LL have resulted, as you suggest,
from the restriction that an interface have just one dynamic IPv4 address at
a time.  I think there's more to the problem - my experience has been that
the IPv4LL address is configured *silently*, so I have no expectation that
the interface is configured in an unexpected way and that, because of that
configuration, none of my applications will work.

Perhaps the "configured silently" problem is a UI issue?  I'd also like, as
a UI issue I guess, the ability to turn off the configuration of IPv4LL
addresses.  Personally, I don't have any convenient way to use an IPv4LL
address, and I'd rather not have any address configured at all than an
IPv4LL address.  (Note that I'm still talking about IPv4 here and not making
any predictions about the availability of applications that can use IPv6LL
addresses.)

So, will this problem be solved in IPv6LL addressing?  Will I either get
some indication from the stack that "no global addresses are configured" or
will applications work as usual within the constraints of the network
resources that can be reached on the LL?

In any event, I should be a little more precise when I say "applications
can't use LL addresses". What I mean here is that the applications won't
work in the way I expect.  That is, I can't use DNS to identify hosts the
application should communicate with, so I have to use an out of band
(shout-down-the-hall?) protocol to ask "What's the address of your host" so
I have an IP address to give to the application.  I don't see where IPv6LL
addressing works any differently in this regard than IPv4LL addressing, so I
don't see how applications will work any better with IPv6LL addresses.

> > work".

Just to be clear - I think I'm in the "I'd like to know how the scenario
will work" camp and am trying to tease out all the pieces that have to be in
place so that it can work.  I don't think IPv6LL addresses taken alone are
the whole story (based on my experience with IPv4LL addresses)...

>  I don't understand the advantage to IPv6LL from the

I may have misunderstood your part of your original message, in which you 
wrote:

>characters for both the src & dst.

Are you describing configuring the interface, configuring the src and dst in
a specific datagram or specifying addresses to an application?

- Ralph

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 25 Aug 2003 09:59:48 -0700

Ralph Droms wrote:
> ...
> Certainly some of my problems with IPv4LL have resulted, as 
> you suggest, from the restriction that an interface have just 
> one dynamic IPv4 address at a time.  I think there's more to 
> the problem - my experience has been that the IPv4LL address 
> is configured *silently*, so I have no expectation that the 
> interface is configured in an unexpected way and that, 
> because of that configuration, none of my applications will work.
> 
> Perhaps the "configured silently" problem is a UI issue?  I'd 
> also like, as a UI issue I guess, the ability to turn off the 
> configuration of IPv4LL addresses.  Personally, I don't have 
> any convenient way to use an IPv4LL address, and I'd rather 
> not have any address configured at all than an IPv4LL 
> address.  (Note that I'm still talking about IPv4 here and 
> not making any predictions about the availability of 
> applications that can use IPv6LL
> addresses.)

I understand the 'not configured as expected' issue. What I don't understand
is why you would rather have no address, unless your stack does not recover
and obtain a different IPv4 address when available. If it does recover, I
don't see any failure modes that having an IPv4LL creates. If it doesn't
recover, I would consider that to be a broken stack.

> 
> So, will this problem be solved in IPv6LL addressing?  Will I 
> either get some indication from the stack that "no global 
> addresses are configured" or will applications work as usual 
> within the constraints of the network resources that can be 
> reached on the LL?

This is of course implementation dependent. Personally I believe
applications need to work within the constraints of LL on both ends at a
minimum. If an app is trying to reach a global, but doesn't have an address
of that scope, a UI should complain. I don't know if it should be the app or
stack, but in the context of my 'solving the right problem' note, I would
rather keep that knowledge contained inside the stack. Actually making the
connection between LL & Global is probably best left as a local policy
decision, with the default to deny out of scope connections.

> 
> In any event, I should be a little more precise when I say 
> "applications can't use LL addresses". What I mean here is 
> that the applications won't work in the way I expect.  That 
> is, I can't use DNS to identify hosts the application should 
> communicate with, so I have to use an out of band
> (shout-down-the-hall?) protocol to ask "What's the address of 
> your host" so I have an IP address to give to the 
> application.  I don't see where IPv6LL addressing works any 
> differently in this regard than IPv4LL addressing, so I don't 
> see how applications will work any better with IPv6LL addresses.

Well to start with, unless your host has a host file, or you happen to be on
the same link as a DNS service/proxy, you will never get a DNS response so
the whole scenario breaks down. Today if there is no DNS response, people
either type in addresses or give up. The yet to be determined 'shout down
the hall' protocol provides an alternative for the situations where the
nodes happen to share the same link. It doesn't break the primary DNS path,
it just adds in to forestall the giving up point. Since typing in IPv6
addresses will really not be feasible, mdns/LLMNR/... really takes that
slot.

> ...
> >So you are going to tell the army private that is ducking 
> the barrage 
> >of gunfire that he can get the critical info he needs from 
> the marine 
> >he just bumped into, if he only types these (what to him are 
> >pseudo-random) 32 hex characters for both the src & dst.
> 
> Are you describing configuring the interface, configuring the 
> src and dst in a specific datagram or specifying addresses to 
> an application?

Anything that would need to be configured. IPv6LL is autoconfigured, so that
would not need to be typed in, but if there is a directive that applications
can't use LL, then some other address might need to be added. The point was
that the situation calls for recognizable strings of characters, therefore
some kind of mapping service to whatever addresses are in use. With
LLMNR/mdns/... type of service, there is no need to type in literal
addresses to the application, or to the stack to make sure there is
something other than a LL there.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 25 Aug 2003 09:59:48 -0700

Tony

---

From: Ralph Droms <[email-masked]>
Date: Thu, 28 Aug 2003 15:51:02 -0400

>recover, I would consider that to be a broken stack.

Well, if I don't have any way to use a LL address, I would rather not have
it configured, so that (presumably) I would get an active indication that
"sumthin's broke" and, if I know to use ipconfig or the right twisty little
maze of control panels, I'll see 0.0.0.0 or 0::0, which is more obviously
broken than a LL address.  To most people, including myself if I don't look
carefully, looks like a valid IP address.

That is, if "the network is not working", and I poke at the IP address and
see something vaguely right, then I'll start looking somewhere else for the
problem.  Which I've done and wasted more time at than I care to think about.
So, maybe it's really a UI problem - in any event, that's why I would rather
have no address at all than an LL address.

>addresses will really not be feasible, mdns/LLMNR/... really takes that

So do we really not have a complete LL story until mdns/LLMNR/... is
standardized and available?

>something other than a LL there.

But there's the rub...we don't have LLMNR/mdns/..., so we don't really have 
a LL story.  I'm all for incremental development like IPv6LL - but it's not 
a panacea until we have a complete system that lets me use my laptop in 
exactly the same way on a LL-only network as on the global Internet.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 28 Aug 2003 16:01:47 -0400

Fred - I'm not sure I have a strong argument against link local addresses, 
per se.  I do observe that, as of today, we don't have a complete system 
for building an ad hoc network - of which LL addresses would be a 
part.  That is, I don't see how the average Internet user can sit at a 
table in a bar with a couple of other folks and "do networking".  We have a 
way for getting LL addresses, but as far as I know  nothing better than 
"hey, what's your IP address" as a way to use applications to communicate 
on that network.

Site-local addresses are more problematic - they cross more 
architectural/political/layer 8 boundaries.  As you suggest, there are 
issues with address assignment and delegation, routing, provider 
independence, etc.  I'm not sure we have a tight/complete set of 
requirements that are not met by global addresses to guide the design of 
some other form of addressing ... so I don't know that we can effectively 
discuss whether one solution or another is the right solution.

- Ralph

---

From: George Gross <[email-masked]>
Date: Fri, 29 Aug 2003 06:14:19 -0400 (EDT)

Hi,
	this thread seems to have wandered into the border between IPv6
and the IRTF Peer-to-peer Research Group (the [email-masked] list).
perhaps moving this discussion of link local addresses and name resolution
in adhoc networks might find folks in that group who know of solution(s)
or the related research?

	George

---

From: Fred Templin <[email-masked]>
Date: Fri, 29 Aug 2003 13:57:19 -0700

Ralph,

Ralph Droms wrote:

> Fred - I'm not sure I have a strong argument against link local 
> addresses, per se.  I do observe that, as of today, we don't have a 
> complete system for building an ad hoc network - of which LL addresses 
> would be a part.  That is, I don't see how the average Internet user 
> can sit at a table in a bar with a couple of other folks and "do 
> networking".  We have a way for getting LL addresses, but as far as I 
> know  nothing better than "hey, what's your IP address" as a way to 
> use applications to communicate on that network.

Well, I have seen certain "controlled arenas" in which a central 
authority can
provision, e.g., static host tables, unique MAC addresses, etc. among 
the nodes
they control such that local networking can take place even in random ad-hoc
encounters. Granted this only works for communications within the controlled
arena and may be an exceptional situation even then as it places an 
administrative
burden on the central authority that grows in complexity with the number of
nodes - but in some environments, the overhead may be acceptable.

> requirements that are not met by global addresses to guide the design 
> of some other form of addressing ... so I don't know that we can 
> effectively discuss whether one solution or another is the right solution.

Well, whatever it takes to achieve such as set of requirements would be 
welcome;
it seems there may be more work  remaining in the wg discussions so 
let's see if
we can continue to make progress.

Thanks - Fred
[email-masked]