Dan Lanciani wrote:
|So you prove my original point, 'there is a sacred invariant, and we
|must avoid messing with the app / transport interface at all costs'.
As a practical matter, this is probably true.
Are you saying that for existing apps we can't change (in which case I
agree), or
Jeroen Massar wrote:
[?Does this need to keep going to both [EMAIL PROTECTED] [EMAIL PROTECTED]
Not as far as I am concerned. If we take the suggested path, the work is
clearly outside the IPv6 WG, and anyone on the IPv6 list that cares to
follow the discussion is now aware of it. I will be
[EMAIL PROTECTED] wrote:
A very quick question about your idea. Does this layer have a
protocol / interface to other elements on the network? Or are
you proposing something more like an abstract API?
Simple question, complex answer ... It really depends on where you are
looking at it from,
Jeroen Massar wrote:
... As far as it stands I think that HIP
is going the best way there is. LIN6 is flawed as it won't
scale and can't be deployed easily. Next to those I got my
own odd idea and I will probably work it out and implement it
as a proof of concept. Though timing on when
Iljitsch van Beijnum wrote:
The multi6 wg has been working on locator/identifier separation as a
way to solve the multihoming in IPv6 problem for a while now.
The problems we're facing (apart from the fact that there are
many ways
to skin this particular cat and everyone has a different
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
Eliot Lear wrote:
Brian E Carpenter wrote:
The other point that's been missed here is that the
security-by-hiding
argument is only part of the story. Stable address space for
intermittently connected networks, unambiguous address
space for VPNs,
and stable identifiers for
Pekka Savola wrote:
The document assumes we need local addressing. That's
already solutionism. Having a document which explores local
addressing
requirements may be OK -- but at least state it clearly and
DON'T pretend otherwise! :-)
There is no intent to pretend. Maybe what you are
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
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
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 ...
=== paf ===
I don't know how to attack the people which talk
Leif Johansson wrote:
Sigh. This is almost to dumb to respond to and I'll be kicking myself
when the
next stats come out ;-) It is possible to build a good car lock (I
claim) and some
day someone will find the economic incentive to do so.
So there should be no locks on cars until someone
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
PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tony Hain
Sent: Friday, August 01, 2003 11:36 AM
To: 'Steven M. Bellovin'
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: FW: AD response to Site-Local Appeal
Steven M. Bellovin wrote:
Tony -- to make life easier for all concerned
Leif Johansson wrote:
Keith Moore wrote:
On Fri, 22 Aug 2003 14:35:15 -0700
Fred Templin [EMAIL PROTECTED] wrote:
Folks - do we have consensus to accept this document as an IPv6 wg
item (see below)?
what does it mean to do this?
I'd also like an answer to this
Pekka Savola wrote:
Hi,
As some others have also commented, I have serious concerns about the
hain/templin draft.
Thank you for providing constructive text, rather than simply complaining.
An observation:
This document seems to take for granted that local-use addressing is
needed.
In the ongoing saga about topology reality vs. application perception of
stability, it occurs to me we are not working on the right problem. In short
we have established a sacred invariant in the application / transport
interface, and the demands on either side of that interface are the root of
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
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
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.
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:
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:
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
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
Mika Liljeberg wrote:
However I do think it's necessary to work out these details, and to
make the changes necessary, rather than simply assuming
that one can
just use LL or just use PI or whatever.
It would be nice to see some of this happen. While the bulk
of the work is a matter
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
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
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
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
Bound, Jim wrote:
...
The solution that will work for now is make a statement in the
IETF and in industry IPv6 implementation documentation that
link-local addresses SHOULD not be used as an IPv6 address
type by applications.
Jim, this is simply pointless. I haven't gotten through all
Kurt Erik Lindqvist wrote:
... There
are a number of ways that we have changed HOW things are
done, but it's
still the same things.
That statement exposes the problem here. Some people want to make sure that
IPv6 does *exactly* the same things that IPv4 does, while others want IPv6
to do
Erik Nordmark wrote:
...
FWIW, I think a multi6 solution with id/loc separation will
make the local addressing concerns go away.
Well a 'solution' might do that, but I don't see one happening in our
lifetimes. Any separation will require a mapping infrastructure to
dynamically bind the
Forming a WG to fantasize about renumbering will not suddenly remove the
edge network manager's requirement for stable address space. The only way
this comes close to being an Ops problem is due to the lack of reliability
scale in DNS. As long as end users feel that name resolution is
Brian E Carpenter wrote:
...
The requirement was met fine by the SL prefix; the only reason they
still are ambiguous is because both Bob and I put our
drafts to remove
ambiguity from SLs on the back burner due to the deprecation
situation.
Sure, at one level it doesn't matter
Brian E Carpenter wrote:
I share Tony's frustration with long hiatus in multi6, but it
seems to be unstuck at the moment. I also agree that it's
hard to separate the topics, but I see no practical advantage
in repatriating the multihoming issue into this WG, which
already has a diverse
Brian E Carpenter wrote:
3. I feel strongly that this absolutely needs to be a
one-time fee. The idea of constructing an artificial service
industry to maintain an annual registration system for random
numbers is plain wasteful.
Well a database with stale information is of no value either.
Fältström
wrote:
On onsdag, aug 6, 2003, at 02:05 Europe/Stockholm, Tony Hain wrote:
From the operator perspective, the demand is for address
space that
is architecturally set aside as private use, locally
controlled. That
did not initially exist in IPv4, and history shows
[EMAIL PROTECTED] wrote:
You are assuming that there is only one boundary in that
consumers house.
No, I am assuming there is at least one boundry between the consumer and
other networks.
I can
assure you that the teenage daugther or son in that house will have a
completely different
Alain Durand wrote:
I'm affraid you're overlooking the impact on address selection here.
Back to the flat earth concept ...
Insisting on a single address per interface is the only way to avoid address
selection. Until we have a globally routed PI space we know there will be
multiple PA
Eliot Lear wrote:
...
Failing such, we seem to have limited
range addressing
and graceful renumbering as alternative options. Perhaps
there are
others also?
Yes: a default address, which is different from a limited
range address. The default address goes away when overriden.
Keith Moore wrote:
there is no justification for the idea that internal-use
applications have a greater need for stability than other
applications.
Not in an academic environment, but when people's jobs are on the line they
tend to set the bar *much* higher. One example of an app that
Eliot Lear wrote:
Like it or not, it is accepted
security practice to limit access by filtering on bits in the IP
header, and restricting what prefixes are announced in routing
protocols.
But that filtering is done EXPLICITLY based on a PARTICULAR
device in a
PARTICULAR
August 05, 2003 12:02 PM Keith Moore wrote:
I concur. A real story for renumbering is probably the
biggest missing piece of the IPv6 puzzle, and we need to be
devoting our energies to solving this important problem
rather than to propagating past errors.
August 05, 2003 12:29 PM Keith
Leif Johansson wrote:
Tony Hain wrote:
Leif Johansson wrote:
Of course we filter -
What is your requirement to do that? I am serious, because those are
the things the current draft is trying to document. If it is not
covered by the current text, please send details
Michael Thomas wrote:
The problem is that this draft proceedes from the
premise that the answer is consing up limited
range addresses.
It is not intended to. It is trying to point out the requirements that
network managers have. It uses examples where they have found limited range
addresses
Eliot Lear wrote:
Tony Hain wrote:
There are some historic 'lessons learned' included here,
but the real
issue is meeting the expectations of the network managers who are
currently using IPv4 logic. That is not to say we don't
want them to
change, but we can't assume they will even
Alain Durand wrote:
You're asking the DNS views to be in sync with the routing
views. Possible to achieve at a cost if there is one local
and one global view, as it is current practise with two-fade
DNS, but much harder when you have n enterprise networks
joining to create an extranet. In
Keith Moore wrote:
Since IPv6 prefixes are going to be mapped along the same
boundaries as IPv4 prefixes ie., layer 2 broadcast domains,
IPv6 route filtering in an government network will be just as
dull a tool as it is in IPv4.
This shows IPv4 thinking, where the network has a
Michael Thomas wrote:
The few self-described apps people I've seen take
a stand have to my recollection been strongly
against dealing with locally scoped addresses .
Have I missed anybody? It seems to me that people
with strong app and/or host kernel background
ought to be given a
Keith Moore wrote:
there is no justification for the idea that internal-use
applications have a greater need for stability than other
applications.
Not in an academic environment, but when people's jobs are
on the line
they tend to set the bar *much* higher.
(Should I
Leif Johansson wrote:
Of course we filter -
What is your requirement to do that? I am serious, because those are the
things the current draft is trying to document. If it is not covered by the
current text, please send details.
but we don't NAT!
I never said NAT was a good thing, in fact I
Andrew White wrote:
...
I would like to point out again, that as per my suggestion,
nodes MUST
NOT send, receive or forward traffic in which the source and
destination addresses are not of the same scope.
I think this is unnecessarily stringent. Certainly nodes
should prefer not
Mark Smith wrote:
...
So is this a statement that the approach is not useful in
government
networks, or a statement that the tool is inadequate
because it does
not solve the government network problems?
I think it is inadequate, because it doesn't provide the
resolution
Mans Nilsson wrote:
By forcing the end user to NAT and hide things behind a
broadband router
or similar device, you now give the attacker one convenient weak spot
which, once attacked and brought to its knees, will deny
every node in the
house network service, especially since this box
Mark Smith wrote:
True, but in my experience in a large, multi-departmental
govenment network, is it fairly common that end user security
/ access requirements don't fall neatly along route / prefix
boundaries. Typically this is because security has crept into
the network, triggered by
Leif Johansson wrote:
You should spend some time in the academic world. In most
countries the academic institutions are essentially companies
offering education and research on a competitive market.
There is not inherent difference and real money is just as
much at stake.
I have been in
Pekka Savola wrote:
Why exactly is advertising the aggregate a problem? The
nodes will filter
out those sources they are auto-configured not to speak to
before even
seeing any maliscious packets.
You clearly trust your filter configuration manager. Not everyone does, and
there is ample
Leif Johansson wrote:
Listen Andrew, I am sort of impressed by your tennacity (if
that is the
word I
am looking for) but writing a loop through a table does not quite
constitute
running code. You actually need to use this in an application and
demonstrate
its utility on the Internet.
Keith Moore wrote:
Anything that involves ambiguous addresses will cause problems.
Please read
http://www.ietf.org/internet-drafts/draft-hain-templin-ipv6-limitedrange-00.
txt and note there is no requirement for ambiguous addresses. Please read
Alain Durand wrote:
So what we have here is a case where you are multihomed with
one side that is permanently unreachable from a large portion
of the universe.
The only difference between this and the case for 90% of the deployed end
systems today is the multihoming. Using PA addresses with
Eliot Lear wrote:
Tony Hain wrote:
Assuming 'inherently' means 'well-known', yes it is true
that manually
configured filtering does not *require* a well-known prefix. It is
also true that automation is required for consumers. Just
because it
is possible to do manual filtering
Hans Kruse wrote:
...
and in draft-hain-templin-ipv6-limitedrange-00.txt
In the simple case, hosts that are allowed external access have a
policy that allows them to configure both global and limited range
prefixes, while those that are not allowed global access have a
policy
Keith Moore wrote:
...
I think the requirement is better stated that apps (not just
local apps) continue to operate independent of any normal
address change events, whether or not at the SP edge.
Nice goal, but requires changes to transport to pull it off. The point is to
deliver service
Brian E Carpenter wrote:
...
No, a link must be wholly contained within a site, and by
definition
anything that is less than global fits wholly within global. Yes
multiple local regions can overlap, but that does not
invalidate the
overall model.
I think it does, because it
Eliot Lear wrote:
...
No, I think that given today's technology I
believe we need
stable addresses so that lack of connectivity does not cause internal
transport connections to fail.
?!?
Yes, I wonder whether this could be
sufficiently handled by minimum length leases that are
Check
http://www.ripe.net/ripencc/mem-services/registration/ipv6/ipv6allocs.html
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Leonardo
Saavedra Henriquez
Sent: Thursday, August 07, 2003 4:24 PM
To: [EMAIL PROTECTED]
Subject: RFC 2928
Margaret Wasserman wrote:
At 10:26 AM 8/7/2003 -0700, Tony Hain wrote:
Right now I cannot find a single application where locally scoped
addresses give me anything worth the effort. Those are my
5 cents -
since you asked for
details :-)
Wait, you started off by saying that you
Brian E Carpenter wrote:
Well, here's my attempt at becoming flame bait :-)
I'm close to concluding that address scope is simply a bogus concept.
1. We've been arguing about it for years and have reached no
sort of consensus. That suggests to me that there is in fact
no consensus to be
Pekka Savola wrote:
So, what exactly is wrong with the Bellovin/Zill Router
Advertisement option proposals which make it very easy for
normally local-only appliances to restrict the nodes they
allow access from?
For the function it performs, nothing. What it lacks is a prefix space to
Andrew,
Would you mind if we put this sequence in the requirements doc?
Tony
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andrew White
Sent: Wednesday, August 06, 2003 6:55 PM
To: IPng
Subject: Real life scenario - requirements (local
George Michaelson wrote:
...
What is special about a number allocated by
the blessed
agency in the case we're discussing?
Strong admission checks into routing are going to make Joe's
numbers less useful.
Admission checks by which authority? Remember we are talking about
prefixes
Margaret,
I am not trying to twist words, I am reflecting what I hear as it
applies to the reality of the deployed network. Our primary disagreement
is over process. Forgive me but I can't figure out the technical
differences that exist, because at this point it is not clear to me what
you
Randy Bush wrote:
just in case folk have short memories, i am strongly against
site-locals. they attempt to solve a routing problem with an
address hack, a la rfc 1918. they are unneeded complexity.
now is the time to abjure them.
They solve an addressing problem PI, where other proposed
Margaret Wasserman wrote:
...
What we _really_ want is to achieve all three of the
following things simultaneously:
- All addresses are globally routable (note that this doesn't
preclude filtering some addresses or
address/port combos).
- Addresses are
Thomas Narten wrote:
Dan Lanciani [EMAIL PROTECTED] writes:
I can't speak for others, but to me it is very interesting (and
important) to have internal connections that are not at the
mercy of
my ISP's renumbering policy.
I agree that this is a very desirable property to have. But
Måns Nilsson wrote:
...
So, I'm glad that you call on the operator community, but I
think you will be surprised at what they say.
I am not surprised because ISPs have a different perspective on this
issue (and many others) than enterprise network managers. The network
managers that will
Christian Huitema wrote:
...
Bad, bad application developers. We should really punish them! :-)
Recognizing the smile, punishment was not my point. What many are
missing here is that the perspective of a single address scope does not,
and will not match the reality of the deployed network.
Thomas Narten wrote:
Tony Hain [EMAIL PROTECTED] writes:
The discussion that should have happened first is 'what
alternatives
do we have to deal with the requirements that network managers are
using SL to deal with?' Without a clear replacement, and
with comments
that some real
Bill Manning wrote:
... Even if a site uses global scope addresses for its %
internal use nodes applications, a name resolution that
includes both % filtered and unfiltered addresses will cause
applications that falsely % assume a single address scope to fail.
%
% Tony
This is
Erik Nordmark wrote:
...
I think #4 (which I didn't talk about at the mike) is a red
herring. Perhaps the issue is a restatement of #1 (due to the
ISP implicitly forcing a
renumbering each time the site connects) in which case the
points about #1 applies. And note that making site-locals
Margaret Wasserman wrote:
...
The work to keep, and finish, site-locals is much greater
than the work to deprecate them.
Wishful thinking...
To deprecate them, I think that the addressing architecture
and the default address selection rules would be the only
RFCs (both at PS) that we
Margaret Wasserman wrote:
...
Access control is also useful, and a simple form of access
control will be needed in IPv6. However, site-local
addresses are a poor form of access control for two reasons:
- Site-local boundaries need to be at routing area
or AS
Eliot Lear wrote:
...
Access control is also useful, and a simple form of access
control will be needed in IPv6. However, site-local
addresses are a poor form of access control for two reasons:
- Site-local boundaries need to be at routing area
or AS boundaries (not
Margaret Wasserman wrote:
Hi Tony,
At 10:23 AM 4/3/2003 -0800, Tony Hain wrote:
Margaret Wasserman wrote:
...
Access control is also useful, and a simple form of
access control
will be needed in IPv6. However, site-local addresses are a poor
form of access control for two
Dan Lanciani wrote:
...
Charging for addresses has nothing to do with an IPv4
mentality. It has to do with a business model. There is
absolutely nothing in IPv6 that would cause this business
model to change.
Customers insisting that their privacy is important, so the ISP must
support
Brian E Carpenter wrote:
What was the consensus, if any, on alternatives to
site-locals when SL
is deprecated?
As I've already said, I think that is the wrong order of discussion.
I think we should clear the desktop first, by getting rid of
ambiguous site-local address space, and
Jeroen Massar wrote:
...
If someone doesn't want/like this they can pick a random
number and use that, they still have to renumber when they
interconnect to another site or the internet.
Renumbering in an IPv6 context means adding a prefix. Unlike IPv4 it
does not mean removing the existing
Jeroen Massar wrote:
Brian McGehee [mailto:[EMAIL PROTECTED] wrote:
*Notes below
* I agree NAT != SL! Except in the case that hosts need global
connectivity and they ONLY have a SL address will require
NAT. Or they should have a second IPv6 globally unique unicast
address
Jeroen Massar wrote:
...
Then don't route a certain prefix.
Using filtering on a single global prefix does not work when
nodes that
need external access are on the same segment with those
that shouldn't
have it. Prefix filtering is the answer, but the prefix to filter is
Michael Thomas wrote:
... Scoped addresses as have been pretty well
demonstrated take us down some pretty scary paths.
This sums up the whole anti-SL campain, which is spread FUD based on one
technically valid point; applications can't arbitrarily pass around
topology information. Applications
Jeroen Massar wrote:
...
Talking about that, maybe a clause in some document should
hint ISP's to start billing based on traffic consumption and
not on IP usage. IP usage is a unmeasurable thing when the
endsite gets a /48 unless the ISP is going to sniff all the
packets and account them
Jeroen Massar wrote:
...
Did you even _read_ the two drafts? one even has the
word 'auto' in it. There will be no registry involved here,
except for the one registering MAC/EUI64 or other unique
addresses from which the automatic unique address is derived.
No money involved there, just a
This proposal is essentially what
draft-hinden-ipv6-global-site-local-00.txt does. I have no problem with
carving off a chunk of FEC0::/10 space for something like this, but that
approach does not solve all problems. In particular it creates an
unroutable mess for sites with a large number of
Pekka Savola wrote:
...
By the ISP? RFC3041 doesn't give you anything except a false
sense of anonomity and broken apps.
It provides anonomity for devices that appear on multiple networks. It
does not prevent an ISP from identifying the customer demarc. It does
not break apps that were not
NO -- Do not deprecate site-local unicast addressing
- Site-locals should be retained for disconnected sites.
Easy to get
No public registration, payment, customer/provider relationship, or
approval required.
- Site-locals should be retained for intermittently
Brian E Carpenter wrote:
Markku Savela wrote:
...
Even if IPv6 is enabled, the system administrator WILL not
give global
addresses to the internal nodes anyways. If site locals are not
available, they invent something else for the purpose.
Access control lists in routers were in
1 - 100 of 303 matches
Mail list logo
