be unenforceable.'' Then after the next election: ``It's really hard to enforce
the law against x. We really need to ban y and z to make sure people can't do
x. After all, some previous set of elected politicians decided to make a law
against x, so
Andrew White <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|>
|> Andrew White <[EMAIL PROTECTED]> wrote:
|>
|> |Dan Lanciani wrote:
|> |
|> |> There is a huge difference between requiring a /48 and allowing anything
|> |> greater than /8. The former ..
Andrew White <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|
|> There is a huge difference between requiring a /48 and allowing anything
|> greater than /8. The former ...
|> while the latter means that you can bypass the black hole with 2 or 4
|> route additions.
|
|Of cou
override
|for the black hole was quite deliberately crafted so that several
|interpretations are possible;
We aren't talking about a partial override. We are talking about a complete
override which your wording clearly prohibits. If that isn't what you mean
then change the wording.
ith 2 or 4
route additions. You can't have it both ways.
Dan Lanciani
[EMAIL PROTECTED]
IETF IPng Working Group Mailing List
IPng Home Page:
han it needs to be. If you are going to require
something as specific as a /48 to escape the black hole (and that's exactly
where this proposal seems to be going) then you are creating an artificial
barrier to an overlay network b
beyond site boundaries. We need to make it clear
that "beyond site boundaries" does not equate to "on the public internet".
Dan Lanciani
[EMAIL PROTECTED]
---
"Tony Hain" <[EMAIL PROTECTED]> wrote:
|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 tru
nsport interface at all costs'.
As a practical matter, this is probably true.
Dan Lanciani
[EMAIL PROTECTED]
IETF IPng Working Group Mailing Li
it
|might work), but I am not sure.
As long as this default can be changed without the cooperation on the
applications (i.e., a global option for the stack) it would be ok...
Dan Lanciani
all? Similarly, why should the number of addresses
provided change? ISPs that currently seek to detect and prevent NAT activity
are not doing so out of a sense of architectural purity.
Dan Lanciani
[EMAIL PROTECTED]
--
ry only for the mythical "enterprise" and thus be cost-
prohibitive for the small business and home user. We really need so see the
replacement first...
Dan Lanciani
[EMAIL PROTECTED]
|/jim
|
|> -Original Message-
between
B & C. Therefore I wish to cast my vote against A more than for C...
Dan Lanciani
[EMAIL PROTECTED]
IETF IPng Working Group Mailing List
so in a way that is not prohibitively
difficult/expensive to deploy.
Dan Lanciani
[EMAIL PROTECTED]
IETF IPng Working Group Mailing List
IPng Home Page:
=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[EMAIL PROTECTED]> wrote:
|On lördag, apr 5, 2003, at 22:24 Europe/Stockholm, Dan Lanciani wrote:
|
|> -When (and how) did site-locals become the main obstacle standing in
|> the
|> way of solving the routing/identifier problem?
|>
|>
deprecated, I
look forward to seeing serious discussions of those routing solutions very
soon.
Dan Lanciani
[EMAIL PROTECTED]
IETF IPng Working Group Mailing List
IPng Home Page:
Leif Johansson <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|
|>
|>That may be what you want, but that is not what you have been saying. You
|>are advocating taking away private address space. Contrary to recent popular
|>(yet incomprehensible) thought these actions are no
ested that there is a reason not to work on this
|problem. In fact, I think that it is vitally important to solve
|this problem, and people are working on it (in the IRTF and the
|multi6 WG, among other places). If you have a viable proposal to
|solve this problem, I&
Leif Johansson <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|
|>the causes--of a restrictive address allocation policy. Would you deprive
|>people of the address space they need to run the applications they need to
|>run just to make it easier to write some other super-apps t
Leif Johansson <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|
|>What makes you think that the apps people who say it *will not work* are
|>correct? Especially when they are talking about models that are already in
|>use?
|>
|>
|>
|Which models would that be exa
t;solution"
for multi-homing: send more money to your ISP and they will make their
links more reliable and refrain from renumbering you as frequently.
Dan Lanciani
[EMAIL PROTECTED]
---
=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[EMAIL PROTECTED]> wrote:
|On lördag, apr 5, 2003, at 00:37 Europe/Stockholm, Dan Lanciani wrote:
|
|> Great. Let's make this PI space available FIRST and THEN we can get
|> rid
|> of site-locals with little trouble.
|>
|> |Yes,
njunction with the deprecation of site-locals. The it's ok because we
know that once site-locals are gone we can forget about PI again...
Dan Lanciani
[EMAIL PROTECTED]
-
Leif Johansson <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|
|>[This response was apparently lost, so I'm resending it.]
|>
|>
|>
|>We know how to achieve it. You may not like the way we achieve it because
|>it doesn't meet your standards for architectu
e it?
Making globally unique "unroutable" (but tunnelable) address space available
would be a good start.
Dan Lanciani
[EMAIL PROTECTED]
IE
[This response was apparently lost, so I'm resending it.]
Thomas Narten <[EMAIL PROTECTED]> 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
Thomas Narten <[EMAIL PROTECTED]> 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 agre
at
|you could choose to filter at your firewalls?
Give me that prefix and tell me how source address selection works and
I'll let you know. In the meantime, site-local addresses as currently
defined are the only solution that is currently defined...
D
it were otherwise.
It is true that site-locals do not by their mere existence automatically
protect a site against renumbering, but that is a straw man. Site-locals
allow a site that cares to protect connections that it cares about. This
is an important capability. Do not be so quick t
h SLs. We need to accept that we have
| no solution and SL is doesn't really seem to be a help here.
Please explain why you feel that internal connections using site-locals will
not survive global prefix renumbering.
Dan Lanciani
"Jeroen Massar" <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|
|> "Jeroen Massar" <[EMAIL PROTECTED]> wrote:
|>
|> |[EMAIL PROTECTED] wrote:
|> |
|> |> NO - Do NOT Deprecate Site-Local Addressing.
|> |>
|> |> There are
Brian E Carpenter <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|>
|> Brian E Carpenter <[EMAIL PROTECTED]> wrote:
|>
|> |I think we should clear the desktop first, by getting rid of ambiguous
|> |site-local address space, and then discuss possible new solutions.
|
you make the ISPs work the way you think they should?
Then NAT would go away and you wouldn't have to try to ban it. NAT
is the effect, not the cause.
Dan Lanciani
[EMAIL PROTECTED]
--
ciated problems as problems.
Dan Lanciani
[EMAIL PROTECTED]
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP a
s.
So in other words, IP renumbering *is* that much of a problem...
Dan Lanciani
[EMAIL PROTECTED]
IETF IPng Working Group Mailing List
IPng Home Page: htt
"NO -- Do not deprecate site-local unicast addressing".
Dan Lanciani
[EMAIL PROTECTED]
IETF IPng Working Group Mailing List
IPng Home Page:
space to make v6 appear commercially
viable is a sham. We cannot afford to defer support of the small- and home-
office environment forever.
Dan Lanciani
ddl@danlan.*com
Brian E Carpenter <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|...
|> |I wasn't around then, but from what I have been told and read I think
|> |everyone was very aware of the scaling issues. But decided to put them
|> |forward and buy time.
|>
|> Well, I was aro
ed to be a temporary
fix quickly evolved into the effective extinction of new portable addresses.
Since then, hierarchical allocation has become so ingrained that some people
have trouble even conceptualizing other solutions.
Dan Lanciani
"Tony Hain" <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|> "Tony Hain" <[EMAIL PROTECTED]> wrote:
|>
|> |Suspend disbelief for a moment, and consider a name
|> resolution service
|> |where the consumer edge widget was responsible for both
David Conrad <[EMAIL PROTECTED]> wrote:
|On Saturday, February 1, 2003, at 09:35 AM, Dan Lanciani wrote:
|> I was actually referring to the practice of inserting 48-bit (or even
|> 64-bit)
|> hardware identifiers into the address in the name of easy
|> configuration.
David Conrad <[EMAIL PROTECTED]> wrote:
|On Friday, January 31, 2003, at 11:27 PM, Dan Lanciani wrote:
|> |Or, better yet, 64 bits. Say, the lower 64 bits of a 128 bit value?.
|> Sure, this has been proposed before, but I think the main complaint was
|> that 64 bits is no longer
David Conrad <[EMAIL PROTECTED]> wrote:
|Again, in the vein of willing suspension of disbelief...
|
|On Friday, January 31, 2003, at 04:55 PM, Dan Lanciani wrote:
|> Using name strings may be no more difficult with respect to the
|> implementation
|> of the name service, but i
s would also
include the usual TTL values and such much as a DNS response does. The mapping
service actually scales a lot better than the DNS because it can increase the
depth of the tree as necessary by splitting on arbitrary bit fields in the
identifier. This should be transparent (think unix D
etter
in practice? Or is the jump from strict source routing to hybrid too big to
make the case?
Dan Lanciani
ddl@danlan.*com
IETF IPng Working Group Mailing
Brian E Carpenter <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|>
|> "Michel Py" <[EMAIL PROTECTED]> wrote:
|...
|> |One billion routes in the global routing table = does not scale.
|>
|> This is the main fallacy in your statement. You are assuming that
"Michel Py" <[EMAIL PROTECTED]> wrote:
|> Dan Lanciani wrote:
|> You are confusing the portability attribute of the address with
|> the implementation of its routing. By the definition you chose,
|> PI is a type of address. It is not a routing mechanism.
|
|This
uch models are outdated. We can do better.
|
|Why don't you write something about it?
I have written about it, most recently in 1999. Why don't you read about
it in the archives?
|The entire world is waiting for
|it.
The world, perhaps. But it is never a popular topic on this list...
"Michel Py" <[EMAIL PROTECTED]> wrote:
|>> Michel Py wrote:
|>> PI = Does *NOT* scale.
|
|> Dan Lanciani wrote:
|> Please define "PI".
|
|ftp://ftp.ripe.net/ripe/docs/ripe-185.txt
This is a rather long document and I was hoping you would provide the
Brian E Carpenter <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|>
|> Quality Quorum <[EMAIL PROTECTED]> wrote:
|>
|> |It seems to me that stability and security of internal enterprise
|> |addressing is a very serious requirement.
|>
|> And why just ente
"Michel Py" <[EMAIL PROTECTED]> wrote:
|This is the semantics police speaking:
|PI = Does *NOT* scale.
Please define "PI".
Please define "scale".
(If your usage in unconventional, please define "*NOT*".)
Dan Lanci
ot;IETF consensus" on
|that choice, though.
Given the strong voices that oppose anything that would change the economic
status quo, you are almost certainly correct.
Dan Lanciani
ddl@danlan.*com
--
than was elicited in the recent site-local debate...
Dan Lanciani
ddl@danlan.*com
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive:
uot;desires"
I think it is also valid to talk about the end users' requirements...
Dan Lanciani
ddl@danlan.*com
IETF IPng Working Group Mailing List
IPng
dition to painless renumbering) a reasonable number (say, > 5)
or truly independent ISPs competing for the business of the end user in
question. I just don't see this happening for the majority of users any
time soon.
Dan Lanciani
t down on the grounds that
it could subvert the all-important MLM^H^H^H hierarchical addressing scheme.
Dan Lanciani
ddl@danlan.*com
IETF IPng Working Group Mai
lability as a justification for removing
local address space and then claim that discussion of the assertion is out of
bounds.
|Dan Lanciani wrote:
|>
|> Brian E Carpenter <[EMAIL PROTECTED]> wrote:
|>
|> |Dan Lanciani wrote:
|> |...
|> |> Please explain *specifical
Brian E Carpenter <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|...
|> Please explain *specifically* what new mechanism v6 supports for providers to
|> realize their service differentiation without limiting IP addresses, and show
|> why providers will be inclined to make the s
ut my paying my provider for a second address?
Please explain *specifically* what new mechanism v6 supports for providers to
realize their service differentiation without limiting IP addresses, and show
why providers will be inclined to make the switch.
o operate. If the intended architecture does not provide a clean
way to do what the vast majority of users are going to see as an obvious given
(i.e., operate a stable local network) then NAT will "route around" the blatant
deficiency. While you can define the protocol to favor the ISP's
s (of both sorts) over SLs.
I trust that it goes without saying that these GUPIs will have to
actually be available *before* this change to the default address
selection rules is made.
Dan Lanciani
almost
|unique *and* something like what I proposed which is completely unique
|at the same time.
Absolutely. What's the point of all these wonderful prefix bits if you
don't use them?
Dan Lanciani
proach. Anything that leaves sites with some
way to control address space will ultimately support a tunneling solution
independent of whether the ISPs allow the addresses to be routed.
Dan Lanciani
ddl@danlan.*com
--
l be good enough for
this as well. If (as is more likely) the DNS won't be up to the task the
situation can be improved by having tunnel end points send hints to recent
partners when their addresses are renumbered.
Dan Lanciani
ls, bypassing ISP restrictions on address count and stability.
By treating "native" aggregated addresses in effect as routes we can easily
build a distributed routing layer that scales indefinitely and hides all the
problems of unstable addresses from the applicat
Tim Chown <[EMAIL PROTECTED]> wrote:
|On Mon, Nov 18, 2002 at 10:49:42PM -0500, Dan Lanciani wrote:
|>
|> We have always been told that stable global v6 addresses will not be available
|> to end users, or at least will not be available to end users at a low cost.
|
|Told by who?
d of kludges.
|So let's not loose sight of the fact that the goal is a robust network.
I think that the goal is a useful network--useful not only for ISPs and
application vendors but for consumers.
mporary and long-term storage) the aggregate
bandwidth of the network grows as well.
Dan Lanciani
ddl@danlan.*com
IETF IPng Working Group Mailing List
IPng Ho
to the application layer. So it goes.
Dan Lanciani
ddl@danlan.*com
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ip
Harald Tveit Alvestrand <[EMAIL PROTECTED]> wrote:
|--On søndag, november 10, 2002 15:25:56 -0500 Dan Lanciani
|<[EMAIL PROTECTED]> wrote:
|
|> As long as we are stuck with a totally non-scalable address allocation
|> system (remember, provider-based aggregated addressin
ses.
So far, nobody has proposed a viable alternative to scoped addresses.
Dan Lanciani
ddl@danlan.*com
IETF IPng Working Group Mailing List
IPng Home Page:
ercial value their price will
increase as well.
Dan Lanciani
ddl@danlan.*com
IETF IPng Working Group Mailing List
IPng Home Page: h
andwidth. That's why some of them are so hot to
detect and eliminate v4 NAT.
Dan Lanciani
ddl@danlan.*com
IETF IPng Working Group Mailing List
IPng Home P
"Michel Py" <[EMAIL PROTECTED]> wrote:
|> Dan Lanciani wrote:
|> Let's say I have an Ethernet segment with 20 workstations
|> and 5 printers. I determine that two of the workstations
|> need access to the Internet so I rent 2 global addresses
|> from my ISP. A
here's no sense trying to prevent it by decree.
Dan Lanciani
ddl@danlan.*com
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive
on site-local addresses are being bandied
about without much thought as to their impact. Any one of these constraints
probably makes site-locals useless for the purposes originally promised. Given
subject of these messages I suppose that could be the idea, but it's going to
cause a
finition local. The only thing
|they bring to the table over SL is ambiguity in the scope of
|routability.
They may help with site merger. My only point is that they don't remove the
need to deal with scopes, so they aren't in any sense an alternative--just a
vari
my local network printer really depend on an address assignment from my
ISP? Even for remote devices accessed via third-party infrastructure the
increased use of VPNs may well mean that those remote devices will have
addresses local to the the owner.
|fourth, I don't buy th
tack and application vendors an excuse to fail to support such
configurations. I don't think you want to open such a huge can of worms as
it will entail revisiting every problem that has been ``resolved'' with an
admonition to simply use site-local addresses.
Michel Py" <[EMAIL PROTECTED]> wrote:
|> Dan Lanciani wrote:
|> An obvious reason would be that the one who wishes to subnet
|> the /64 is not the same one who should have used a /48, with
|> the former one having little control over the latter one.
|
|A dial-up connectio
have used a /48, with the former one
having little control over the latter one.
Dan Lanciani
[EMAIL PROTECTED]
IETF IPng Working Group Mailing Lis
no other way to accomplish this interaction
with UDP port unreachables. Fancy new APIs may allow the same thing to be
accomplished by other means, but in any case you are talking about slightly
more (structurally) than simply removing a check on the reply.
Dan
;s a lot better than
nothing. I will probably prototype on FreeBSD. Because this approach doesn't
require any changes at all to the core protocols I won't trouble this list
further with the project. If anyone else is interested, please contact me
directly.
Free market competition could have sorted
out the results. None of this can happen if IPv6 imposes exactly the same
constraints as (current) IPv4.
Dan Lanciani
[EMAIL PROTECTED]
---
e, how many support calls do we expect from users,
|etc.
I think that might be a bit of an oversimplification...
Dan Lanciani
[EMAIL PROTECTED]
IE
for different functions within a single computer. This imply
|that the "native v6" ISP will be expected to provide users with a
|prefix, not a single host address -- otherwise, the native v6 solution
|will be perceived as inferior to the existing 6to4 solution.
Yes, and that&#x
David Terrell <[EMAIL PROTECTED]> wrote:
|On Tue, May 08, 2001 at 05:02:26AM -0400, Dan Lanciani wrote:
|>It's relevant unless you eliminate 6to4 and any other scheme that
|>generates portable v6 address space from v4 space. 6to4 is actually
|>rather interesting in that it
. Sites care about internal stability as well as external. Site
local addresses are yet another IPv6 hack that recognizes this fact and tries
to partially mask the problem.
|The
|only advantage to stable addresses (aside from the problem of renumbering
|your site) is where it is known to oth
ldn't
live without them. It didn't work out that way. Now there seems to be some
expectation that people will trade in their NATs for shiny new public per-host
IPv6 addresses (that the ISP can charge for and renumber of a whim) just because
there are more address bits. This
o practice the above mentioned
|specification, if any, on a reciprocal basis.
If the IETF would like to use the similar "technology" that I described
on this list back in 1999 (refer to portable identifier thread), I'll put
it in the public domain. :)
end users to own any
kind of global (provider-independent) unique address (or address-like object)
even if it is not directly routable. Perhaps now that 6to4 has let the genie
out of the bottle it will be more palatable to allow users not fortunate enough
to own any IPv4 space to play as well...
xempt them from the prefix
length constraints?
|(Some would argue that having packets take the scenic
|route as you describe is desirable, however.)
What is the argument for this?
Dan Lanciani
[EMAIL PROT
eated as more
than a temporary hack if people are to commit. (Alternately, I suppose
6to4 addresses could simply overtake "real" addresses. :)
Dan Lanciani
[EMAIL PROTECTED]
ven made a hand-waving proposal to allow for this with
relatively minor protocol modifications) there never seemed to be much interest.
So the market pressures will continue to operate in an IPv6 environment just as
they have in the IPv4 one. All IMHO, of course...
Dan Lan
94 matches
Mail list logo
