At 09:59 AM 8/25/2003 -0700, Tony Hain wrote:
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
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
Hi,
this thread seems to have wandered into the border between IPv6
and the IRTF Peer-to-peer Research Group (the [EMAIL PROTECTED] 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
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
At 09:26 AM 8/22/2003 -0700, Tony Hain wrote:
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
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
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.
A tactic often used to stall a technology by people or organizations
that can't deliver when
On Aug 22, 2003, at 10:03 PM, Bound, Jim wrote:
mdns or LLMNR are not widely implemented and if you bring your
implementation to one of the many test events for IPv6 where your node
must interoperate on the deployed implementations testing network most
nodes will not respond to mdns. I am sure
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.
A tactic often used to stall a technology by people or organizations
that can't
Tony Hain [EMAIL PROTECTED] writes:
Yet you continue to insist that passing around incomplete topology
information is not only valid, it is an inherent right of all application
programmers for all time. It is fine for you to have that view. It is not
fine when you use that view to prevent
Suggesting that applications should avoid IPv6LLs at all cost is silly.
suggesting that apps in general can use IPv6LLs is also silly.
OTOH, promoting the use of mDNS and LLs for IPv6 is criminally irresponsible.
IETF IPng
--On Friday, August 22, 2003 18:03:45 +1000 Andrew White
[EMAIL PROTECTED] wrote:
* Applications should not assume that all addresses are equal.
Do not mention the war. It is over.
--
Måns NilssonSystems Specialist
+46 70 681 7204 KTHNOC MN1334-RIPE
We're sysadmins.
Tony Hain Wrote:
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.
Michel Py wrote:
A tactic often used to stall a technology by people or
Keith Moore wrote:
And if you are claiming that I have ANYTHING at all to do with
promoting ANY vendor's products, then you are WAY out of line,
and I demand an apology.
As always you don't read what other people post. Read my text again
and explain me where you find the words
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
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
Tony Hain [EMAIL PROTECTED] wrote:
Keith Moore wrote:
L3 makes routing look flat to the end systems. That's its
job - to steer packets through
Bound, Jim wrote:
The fact is that the WG believes this is important
discussion.
It is an important discussion. There is a very critical architectural point
here, and it is being glossed over by 'the sky is falling' claims that apps
might fail, or have to do some work.
The architectural
On Sat, 23 Aug 2003 13:10:56 -0700
Tony Hain [EMAIL PROTECTED] wrote:
Bound, Jim wrote:
The fact is that the WG believes this is important
discussion.
It is an important discussion. There is a very critical architectural point
here, and it is being glossed over by 'the sky is falling'
Jim Bound wrote:
What was my point of compromise for SLs in that past
discussion before this wise WG consensus deprecated
them? Ok age happens I will respond :--). PUT
CONTROLS ON THEM SO THEY DON'T EVER LEAVE A SITE AND
AGREE TO THE RULES FOR THE SITE BORDER ROUTERS. But
Keith Moore wrote:
The fact is that the WG believes this is important
discussion.
It is an important discussion. There is a very critical
architectural
point here, and it is being glossed over by 'the sky is falling'
claims that apps might fail, or have to do some work.
It is an important discussion. There is a very critical architectural
point here, and it is being glossed over by 'the sky is falling' claims
that apps might fail, or have to do some work.
It's become clear that you don't know what you're talking about.
On the contrary, I know
SLs are bad, what are we getting insead? IPv6 swamp and NAT.
it's not as if keeping SLs would have made the routing problem any easier.
IETF IPng Working Group Mailing List
IPng Home Page:
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
At 10:00 PM 8/21/2003 -0700, Tony Hain wrote:
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???
'I strongly disagree that this practice adds value to IPv6.', as a response
to a vendor that was describing where they find value in general app use of
LL is being obstructionist.
no, shipping code that does this is being obstructionist to apps that don't
work under those conditions.
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
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.
filters don't mess up addressing. ambiguous addresses do.
In closing, three guidelines / work items:
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
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, ...
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,
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
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),
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.
uh, no. you're the one insisting on burdening apps with
unnecessary complexity and limiting
Keith Moore wrote:
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
Keith Moore wrote:
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
On Thursday, August 21, 2003, at 6:56 , Keith Moore wrote:
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.
you have it
Keith Moore wrote:
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
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
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
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
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.
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
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
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
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
Keith Moore wrote:
Expecting the network to be globally
accessable and flat is not reality.
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
: Some IPv6LL operational experience
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
On Fri, 22 Aug 2003 15:15:34 -0700
Tony Hain [EMAIL PROTECTED] wrote:
Keith Moore wrote:
Expecting the network to be globally
accessable and flat is not reality.
the network has never been flat in reality, but part of the
purpose of IP has always been to provide the
At 05:16 PM 8/21/2003, Keith Moore wrote:
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.
Worse than NAT. Coming from you that must be pretty bad.
I said that because I did a quick mental
you know, I'm really fed up with your misrepresenting my positions.
I not speaking to Mr. Hain for awhile but I feel the same.
The fact is that the WG believes this is important discussion. Whether
Mr. Hain likes it or not.
/jim
Joshua,
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
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.
you have it exactly opposite. one of the major drivers for
On Thu, 2003-08-21 at 16:56, Keith Moore wrote:
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.
Nevertheless, this is exactly what users expect. Therein lies the
challenge.
MikaL
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:
Keith Moore wrote:
I'm all for enabling ad hoc networks, and I'm all
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.
I agree entirely that it's not desirable to expect ad hoc networks to
be a single link. However,
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
.
thanks
/jim
-Original Message-
From: Joshua Graessley [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2003 1:24 AM
To: [EMAIL PROTECTED]
Subject: Some IPv6LL operational experience
I realize that as an employee of a company that sells a product and
tries to implement
]; [EMAIL PROTECTED]
Subject: Re: Some IPv6LL operational experience
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.
I agree entirely that it's
IPv6LL operational experience
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
]
Sent: Thursday, August 21, 2003 11:26 PM
To: Bound, Jim
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Some IPv6LL operational experience
I wish I could share your confidence in the wisdom of the
market. In my experience, the market does
Jim Bound wrote:
The reason NAT got away with what it did is the users got
blind sided and then IETF got sucked into building a special
NAT working group (which I objected to at Munich) and look
at the mess we have out there today. At least to me it's a
complete mess.
I have to disagree
On Thu, 21 Aug 2003 23:44:37 -0400
Bound, Jim [EMAIL PROTECTED] 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.
But it has turned into another absurd
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
]
Sent: Friday, August 22, 2003 12:02 AM
To: Bound, Jim
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Some IPv6LL operational experience
On Thu, 21 Aug 2003 23:44:37 -0400
Bound, Jim [EMAIL PROTECTED] wrote:
I came here and asked a simple
PROTECTED]
Sent: Friday, August 22, 2003 12:06 AM
To: Bound, Jim
Cc: [EMAIL PROTECTED]
Subject: RE: Some IPv6LL operational experience
Jim Bound wrote:
The reason NAT got away with what it did is the users got
blind sided
and then IETF got sucked into building a special NAT working group
Jim,
Jim Bound wrote:
100% agree. I was stating the tremor before IPv4 NAT actually
happened not why they are using it. I also don't think users
are stupid but maybe far to trusting of vendors and the IETF
like MObile IPv6 WG was of IPsec :--)
What drives me nuts with you is that although
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
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.
Message-
From: Michel Py [mailto:[EMAIL PROTECTED]
Sent: Friday, August 22, 2003 12:25 AM
To: Bound, Jim
Cc: [EMAIL PROTECTED]
Subject: RE: Some IPv6LL operational experience
Jim,
Jim Bound wrote:
100% agree. I was stating the tremor before IPv4 NAT
actually happened
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
Keith Moore wrote:
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
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
72 matches
Mail list logo
