A simple end to end solution is to send multiple copies of a data to
multiple pathes. Mission critical application over SONET is already
doing so and it is said that, even if a path fails, not even a single
bit is lost.
No.
- kurtis -
Kurt Erik Lindqvist wrote:
This I thought was more or less standard. I was talking about
less than 100ms convergence.
Dude, this requires a keepalive or hello at 10ms intervals and a 25~30
ms rtt. You might need to talk to a guy named Albert Einstein; he
wrote
interesting RFCs about the speed of
Kurt Erik Lindqvist wrote:
This I thought was more or less standard. I was talking about
less than 100ms convergence.
Dude, this requires a keepalive or hello at 10ms intervals and a 25~30
ms rtt. You might need to talk to a guy named Albert Einstein; he wrote
interesting RFCs about the speed of
There is no technical reason why a single service provider network
can
do better than a similar network that consists of several smaller
See Abha and Craigs paper on convergence of BGP. Personally I would go
for a large provider with multiple connections.
Based on this paper? What I see is
multihoming [Re: Enforcing
unreachability of site local addresses]
There is no technical reason why a single service provider
network
can
do better than a similar network that consists of several smaller
See Abha and Craigs paper on convergence of BGP. Personally I
would go
for a large provider
Kurt Erik Lindqvist wrote:
This I thought was more or less standard. I was talking about
less than 100ms convergence.
Dude, this requires a keepalive or hello at 10ms intervals and a 25~30
ms rtt. You might need to talk to a guy named Albert Einstein; he wrote
interesting RFCs about the speed
Folks,
I am on multi6 and just listen and send clarification questions to
various participants. But a short comment here.
Has the end-to-end principle failed to teach us anything?
Reliability begins and ends in the end hosts. If each host is
connected over two service providers there are
I'll take one particular issue, and Cc: to multi6 as I believe it is a
very important thing to consider.
On Fri, 14 Feb 2003, Alan E. Beard wrote:
Most of the end-user-network managers among my clients now
multihome,
and
will continue to require multihomed service in future. In every
case
where
In a perfect world I'm sure I'd agree with you. In real life however,
the fact of the matter is that customers want multihoming, and it
doesn't matter to the customers if that is a problematic approach that
doesn't scale for the SPs. Doesn't even matter if it's technically the
best solution for
There is no technical reason why a single service provider network can
do better than a similar network that consists of several smaller
See Abha and Craigs paper on convergence of BGP. Personally I would go
for a large provider with multiple connections.
Last fall I was invited to a conference
Alan E. Beard wrote:
Folks:
OK. In the past several days, I have:
read Tony's ipv6ipaddressusage-04 draft
read Michel's gapi-00 draft
reviewed the site-local use discussion in the IPv6 WG
read the Multi6 charter
read the Multi6 requirements draft
re-read RFC 2373 and RFC 2374
re-read
Michel:
On Sat, 15 Feb 2003, Michel Py wrote:
Alan,
Alan E. Beard wrote:
No wonder we're at an impasse: we have a blind-men-and-the-elephant
problem here!
No. We know what the elephant looks like. This is not the issue. The
issue is that for the last eight years we have been trying
read Tony's ipv6ipaddressusage-04 draft
read Michel's gapi-00 draft
reviewed the site-local use discussion in the IPv6 WG
read the Multi6 charter
read the Multi6 requirements draft
re-read RFC 2373 and RFC 2374
re-read the addr-arch-v3 draft
re-read the ipv6-prefix-delegation-requirement-00 draft
(Randy removed from CC as I only had him in CC for the comments on the
RIPE meeting)
Most end-user network managers I deal with require these
characteristics
of their public network address allocations:
1) uniqueness (sometimes expressed as autonomy)
Wait. This is interesting. From what
On Fri, Feb 14, 2003 at 08:59:21PM -0500, Alan E. Beard wrote:
I agree that NREN networks differ from other networks, but it does not
follow that other networks should thereby be forced to discriminatory
treatment while NREN networks obtain top-quality service. (BTW, Brown v.
Board is a
Dan, Margaret, et al:
I have given some thought to the matters raised below. This note will
address the questions raised by Dan in his first paragraph; the second
paragraph will see a later response. Please be aware that the below
should be considered, at its most ambitious, not more than a
Alan E. Beard wrote:
...
What think ye all?
We are at an impass. The right outcome is that multi6 defines an
approach that works for end sites, while scaling appropriately for the
ISP concerns. The reality is that multi6 is off in the weeds
rearchitecting the Internet, with no more hope of a
Tony Hain wrote:
We are at an impass.
Indeed.
this puts the ADs in a bind, because they would have a hard
time justifing that the IPv6 wg should be tasked with defining
an operational plan that an Operations Area wg is already
tasked to do.
Yep. Some will remember that in an attempt to
Kurtis:
Thanks for your thoughtful response. I'll reply to your queries inline.
AEB
On Fri, 14 Feb 2003, Kurt Erik Lindqvist wrote:
Most end-user network managers I deal with require these
characteristics
of their public network address allocations:
1) uniqueness (sometimes
Alan,
Excellent post, thanks. I just have two things to comment.
Alan E. Beard wrote:
managers who chose to play ostrich (you know what that
bird exposes when it sticks its head in the sand)
That must be the same place some stick their heads when
there's no sand around.
The cat and the
On Thu, 13 Feb 2003, Michel Py wrote:
Alan E. Beard wrote:
I strongly suspect that end-user networks will not embrace
IPv6 enthusiastically unless registered, globally routable
PI space is readily available.
I will modulate this by saying that end-user networks don't necessarily
want
On Tue, Feb 11, 2003 at 09:25:24AM +0100, Kurt Erik Lindqvist wrote:
1) Address space shortage
2a) No scalable PI solution
2b) No scalable IDR solution
I said it before and I will say it again, without a solution to 2a, no
enterprises will go to IPv6, with no enterprises on IPv6 there
Tim, Kurt:
I will add some comments from the end-user-network perspective on behalf
of my client base. Please see inline.
AEB
On Thu, 13 Feb 2003, Tim Chown wrote:
On Tue, Feb 11, 2003 at 09:25:24AM +0100, Kurt Erik Lindqvist wrote:
1) Address space shortage
2a) No scalable PI solution
Alan E. Beard [EMAIL PROTECTED] wrote:
|Yes, I think you are probably right in speculating that any technically
|sound mechanism which preserves the virtues of provider independence,
|portability, and stability in configuration of end-user-network devices
|will satisfy the functional requirements
Michel Py wrote:
This is why I used the term gambling before. What you are
lobbying for is to say that it is OK to give away PI and
create the IPv6 swamp
Kurt Erik Lindqvist wrote:
yes.
Brian E Carpenter wrote:
I disagree. If our goal (as it should be) is a 10 billion
node network (at least)
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 around and I don't recall any major
Dan, Brian:
A bit of historical information and some comments on the current issue
included below.
AEB
On Tue, 11 Feb 2003, Dan Lanciani wrote:
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
|
a billion /48 prefixes in the global routing table, what do
you call this? I call it IPv6 swamp.
Kurt Erik Lindqvist wrote:
It is! No question, but do you want to wait 5+ years?
You are missing the point. If we had a reasonable expectation that a
scalable flat routing protocol would be
Kurt Erik Lindqvist wrote:
a billion /48 prefixes in the global routing table, what do
you call this? I call it IPv6 swamp.
Kurt Erik Lindqvist wrote:
It is! No question, but do you want to wait 5+ years?
You are missing the point. If we had a reasonable expectation that a
I disagree. If our goal (as it should be) is a 10 billion node
network (at least) then the risks in allowing even the beginning
of a swamp are too great.
I don't mind us looking at a 10 billion node solution. But I am fairly
skeptical that any of the proposals we have today will scale to that
Brian / Kurtis,
Michel Py wrote:
This is why I used the term gambling before. What you are
lobbying for is to say that it is OK to give away PI and
create the IPv6 swamp
Kurt Erik Lindqvist wrote:
yes.
Brian E Carpenter wrote:
I disagree. If our goal (as it should be) is a 10 billion
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 around and I don't recall any major concern.
This is hard to reconcile with some of the
Assuming? Hello? This exactly what PI is. If there is no central
routing
it's not PI anymore. PI is what we have _today_.
Exactly. And today we don't have a billion routes.
Fortunately enough, if you would like the routing algorithms to
converge in real time.
I rather come up with a
but even if we in San Fransisco would agree on a new routing model,
it would still take us at least 3-5 years to implement.
See the migration to BGP4 as example.
5 years is overly optimistic, IMHO.
Probably.
I say go for /48 PI space. Take a /16 (or something suitable) and
divide it per RIR,
Kurt Erik Lindqvist [EMAIL PROTECTED] wrote:
| But, doing this would put research efforts to a halt. 10 years down the
|
|On the contrary. It will buy us time and give us experience.
And besides, a looming deadline might accelerate rather than halt research.
Currently solutions to the
Kurtis,
Michel Py wrote:
a billion /48 prefixes in the global routing table, what do
you call this? I call it IPv6 swamp.
Kurt Erik Lindqvist wrote:
It is! No question, but do you want to wait 5+ years?
You are missing the point. If we had a reasonable expectation that a
scalable flat
David Conrad wrote:
Brian,
On Wednesday, January 29, 2003, at 02:33 AM, Brian E Carpenter wrote:
If we achieve stable locators, this problem largely goes away,
but stable names in themselves are insufficient IMHO.
The problem isn't the DNS, but the concept of 'stable locators'.
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 tracking
|topology changes, and updating a branch of the name tree to keep it
|aligned. Said widget
David Conrad wrote:
...
Assume at the end point an address consists of a 64 bit value stuffed
into the lower 8 bytes of an IPv6 address with the upper 64 bits 0.
The lower 64 bits of the destination would be put into an
in-addr.arpa-like tree, mapping that end point into multiple s
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 tracking
| |topology changes, and updating a branch of the name
Dan Lanciani wrote:
| ...
|There is an important difference between pushing all the way
to the end
|system, vs. the edge router. While architecturally there is little
|difference, when the mapping function is in the end system
the level of
|churn on the registration infrastructure is
Dan,
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 enough for the wasteful allocation policies
we
have
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 enough for the
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.
|
|One allocation mechanism is
Assuming? Hello? This exactly what PI is. If there is no central
routing
it's not PI anymore. PI is what we have _today_.
Exactly. And today we don't have a billion routes.
- kurtis -
IETF IPng Working Group Mailing List
IPng
If we are seriously considering doing PI allocations then
we should probably start the process of collecting
proposals for how to make it scale.
This is the semantics police speaking:
PI = Does *NOT* scale.
Tim, I don't doubt your intentions, but please don't call it scalable
PI. There is no
Personally, I _would_ like to see the IETF seriously pursue PI
allocations.
I'm not sure where to start, though. Perhaps we should get some
proposals together and hold a BOF?
Why not just write a draft? I would be willing to do it if noone else.
It's not that much that needs to go in
Kurt Erik Lindqvist wrote:
Assuming? Hello? This exactly what PI is. If there is no central
routing
it's not PI anymore. PI is what we have _today_.
Exactly. And today we don't have a billion routes.
Fortunately enough, if you would like the routing algorithms to
converge in real time.
Brian,
On Wednesday, January 29, 2003, at 02:33 AM, Brian E Carpenter wrote:
If we achieve stable locators, this problem largely goes away,
but stable names in themselves are insufficient IMHO.
The problem isn't the DNS, but the concept of 'stable locators'. Given
the need to aggregate, you
David Conrad wrote:
On Wednesday, January 29, 2003, at 02:33 AM, Brian E Carpenter wrote:
If we achieve stable locators, this problem largely goes away, but
stable names in themselves are insufficient IMHO.
The problem isn't the DNS, but the concept of 'stable
locators'. Given
the
Kurtis,
Kurt Erik Lindqvist wrote:
but even if we in San Fransisco would agree on a new routing model,
it would still take us at least 3-5 years to implement.
See the migration to BGP4 as example.
5 years is overly optimistic, IMHO.
I say go for /48 PI space. Take a /16 (or something
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 tracking
|topology changes, and updating a branch of the name tree to keep it
|aligned. Said widget would need a secure mechanism to
Tony Hain wrote:
Are we wasting a lot of time and energy trying to solve
the problem in routing, when the real solution lies in a
complete overhaul of the DNS?
I don't think so, here's the rationale: It is clear that this DNS
overhaul will have to introduce better security and reasonable
Hi,
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 it leverages far less existing code than
would a fixed-
length
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 it leverages far less
David Conrad wrote:
... and unfortunately DNS is not as solid as you hope.
Oh? Do tell.
I'm not insulting your software :-)
When addresses change, you have all the problems of propagation
delay and security for updates.
So, even if x.example.com is stable in the sense of always
Michel Py wrote:
Margaret,
Michel Py wrote:
...
Possibilities for how to allocate aggregable
provider-independent addresses could include (among other options)
the geographical addresses that Tony Hain has proposed.
What term should I use for that?
If it is any different than the
Tony Hain
Even if you disagree with the geo approach, I would appreciate
comments on the current update to the companion document that
discusses the need for PI.
http://www.tndh.net/~tony/ietf/ipv6piaddressusage-04.txt
This text is very good, very comprehensive. I encourage everyone to read
Margaret Wasserman wrote:
But the problem remains as hard as it was in 1992. We don't know how
to aggregate routes for such addresses, and we don't know how to scale
the routing system without aggregation. Solve either of those
problems and you're done.
Maybe we can't solve this
Quality Quorum wrote:
...
...The thing which is doable is to assign moveable transport-bound
addresses + independent non-globally-visible and non-globally unique
permanent local addresses + NAT, with DNS names being the only fixed
points in this permanently shifting environment.
As I
Hi Brian,
When 8+8 first appeared, I was delighted and referred to it as
architected NAT. I think that is what we need, either in the form
of 8+8/GSE, map-and-encap, MHAP, or something like those. To me
that is by far the most hopeful class of solutions.
I agree. There are some potential
... and unfortunately DNS is not as solid as you hope.
Oh? Do tell.
Thanks,
-drc
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive:
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 a billion
| PI address blocks has to equate to a
On Tue, 28 Jan 2003, Dan Lanciani wrote:
No, this is exactly the fallacy that leads to failure. There is no need
for summarization of routes because there is no need for any given node
to have a complete picture (even summary) of the topology. The whole point
of distributing the routing task
|Pekka Savola [EMAIL PROTECTED] wrote:
|
|Would you mind collecting the old ideas (which you mentioned went back to
|1999),
Actually, 1999 was just the most recent time I had brought this up.
|honing them perhaps a bit (if they need a polish) and putting them
|out as a short Internet-Draft?
I'm
Brian,
Michel Py wrote:
... There is nothing that says that the scalability
should come from aggregation either.
Brian E Carpenter
There certainly is, if you generalize aggregation to
mean abstraction and summarization as noted above. But
Noel has ranted on this subject so many times that
There seem to be at least a couple of possible PI schemes that are being or
have been kicked around in the past. Dan referenced a solution that he has
worked on and Tony Hain's geographic scheme, while currently targetted at the
multi-homing problem, might well offer a solution. If we are
This is the semantics police speaking:
PI = Does *NOT* scale.
Starting with this assumption leads us to two bad choices. Maybe it
is time to question this assumption?
Same here. I did not comment on this before, but I think that what
Margaret really means here is:
This is the crux of
Michel Py wrote:
PI = Does *NOT* scale.
Dan Lanciani wrote:
Please define PI.
ftp://ftp.ripe.net/ripe/docs/ripe-185.txt
Please define scale.
One billion end-sites. This is the baseline number for multihoming
solutions. Smaller numbers have been deemed insufficient.
One billion routes in
Margaret Wasserman wrote:
This is the semantics police speaking:
PI = Does *NOT* scale.
Starting with this assumption leads us to two bad choices. Maybe it
is time to question this assumption?
Same here. I did not comment on this before, but I think that what
Margaret really means
Michel,
Tim Hartrick wrote:
If we are seriously considering doing PI allocations then
we should probably start the process of collecting
proposals for how to make it scale.
This is the semantics police speaking:
PI = Does *NOT* scale.
Tim, I don't doubt your intentions, but
Michel Py wrote:
Margaret,
Michel Py wrote:
PI = Does *NOT* scale.
Do you base this statement on hard evidence or conventional wisdom?
Brian Carpenter wrote:
But the problem remains as hard as it was in 1992. We don't
know how to aggregate routes for such addresses, and we don't
know how
But the problem remains as hard as it was in 1992. We don't know how
to aggregate routes for such addresses, and we don't know how to scale
the routing system without aggregation. Solve either of those
problems and you're done.
Maybe we can't solve this problem
If not, then we won't have
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 part of
the definition that you are actually using. This
[EMAIL PROTECTED]
To: Erik Nordmark [EMAIL PROTECTED]
Cc: Keith Moore [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, January 26, 2003 1:30 PM
Subject: Re: Enforcing unreachability of site local addresses
I think, but I'm not sure, that this assumes that we will have
Hi Tim,
Not to pick on you... You are making some excellent points, and I
want to make sure I understand them.
And, I have serious doubts that
they will ever scale. But, if that is the case and we are going to be
forbidden from seeking other solutions that involve site-local addressing and
Dan,
Michel Py wrote:
One billion routes in the global routing table = does not scale.
This is the main fallacy in your statement. You are assuming
that a billion PI address blocks has to equate to a billion
routes in some global routing table (or even that there has to
*be* a global
Michel Py [EMAIL PROTECTED] wrote:
| Michel Py wrote:
| One billion routes in the global routing table = does not scale.
|
| This is the main fallacy in your statement. You are assuming
| that a billion PI address blocks has to equate to a billion
| routes in some global routing table (or even
Margaret,
Not to pick on you... You are making some excellent points, and I
want to make sure I understand them.
And, I have serious doubts that
they will ever scale. But, if that is the case and we are going to be
forbidden from seeking other solutions that involve site-local
Tim,
Tim Hartrick wrote:
given the current centralized routing architecture, PI
addresses don't scale. And, I have serious doubts that
they will ever scale.
But, if that is the case and we are going to be forbidden from
seeking other solutions that involve site-local addressing and
Dan,
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 is not the way PI is being understood in the realm that deals
with them, the
Fred,
Fred L. Templin
Your statements seem to be focused on the solutions we have
at hand today along with the unspoken assumptions we have
held as truths in the past. I used to think that carefully
managed hierarchical routing was the only way to go to
achieve scalability, but I am no
This is not the way PI is being understood in the realm that deals
with them, the RIRs. PI does not only mean portability, it also means
the routing mechanism that is (and always has been) in use, which is to
announce the prefix in the global routing table, making it grow.
No matter what
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 is not the way PI is being understood in
What term should I use for that?
Aggregatable PI addresses, which is however kind of a contradiction in
terms. Addresses are as much aggregatable as their assignment reflects
the underlying topology, which includes the split of the network among
various providers. By definition, a structure
Margaret,
Michel Py wrote:
This is not the way PI is being understood in the realm that
deals with them, the RIRs. PI does not only mean portability,
it also means the routing mechanism that is (and always has been)
in use, which is to announce the prefix in the global routing
table, making
I think, but I'm not sure, that this assumes that we will have a scalable PI
scheme some time in the future (presumably by separating PI identifiers
from PA locators).
Actually, this is quite tricky...
If we _don't_ allocate PI addresses soon, enterprises will demand
IPv6 NAT to allow them to
Margaret Wasserman [EMAIL PROTECTED] wrote:
|But, if we do allocate PI addresses soon, we will need to do that without
|any certainty that we can come up with a scalable PI routing scheme.
Do you really think that there is any question of whether we could if we
actually wanted to? The arguments
Margaret,
Margaret Wasserman wrote:
Actually, this is quite tricky...
[snip]
I generally agree with the analysis you posted.
Choices seem to be:
(A) Continue with PA addressing, and accept that enterprises
will use IPv6 NAT to get provider-independence.
(B) Allocate PI addresses, and
Dan, Margaret,
|Some folks have argued that easy renumbering would eliminate the need
|for enterprises to have provider-independent addressing, but I don't
|agree. Addresses are stored in many places in the network besides
|the interfaces of routers and hosts, such as access control
Tim / Margaret,
Tim Hartrick wrote:
If we are seriously considering doing PI allocations then
we should probably start the process of collecting
proposals for how to make it scale.
This is the semantics police speaking:
PI = Does *NOT* scale.
Tim, I don't doubt your intentions, but please
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 Lanciani
ddl@danlan.*com
I suspect we all agree that crushing the routing system would be bad .
It seems like the question is what mechanism (other than ambiguity)
would be sufficient to prevent that happening.
Assuming we have the SHOULD NOT be routed globally in the spec.
Then if the PI addresses come from a
Kurt:
First, my apologies for the delayed reply. Response inline.
AEB
On Mon, 2 Dec 2002, Kurt Erik Lindqvist wrote:
My memory of the discussions accords with the summary given by Keith
above. In addition, the general tenor of the discussion indicated to
me
that the two issues were
Bob,
Margaret Wasserwan wrote:
In my opinion, the only way that we will stop people from
using NAT (with or without IPv6 site-local addresses) will
be to provider better (architecturally cleaner, more
convenient, more functional) mechanisms for people to get
the same benefits that they get
I believe that Bob has it right here. Enterprises may well use NAT for
provider independence and easier multi-homing, but in the home and
small business area NAT is driven by address scarcity. That address scarcity
is artificial in many cases. ISPs can charge for address space so they do.
Margaret,
In my opinion, the only way that we will stop people from using NAT
(with or without IPv6 site-local addresses) will be to provider better
(architecturally cleaner, more convenient, more functional) mechanisms
for people to get the same benefits that they get from NATs today.
Although
Margaret, Bob,
In my opinion, the only way that we will stop people from using NAT
(with or without IPv6 site-local addresses) will be to provider better
(architecturally cleaner, more convenient, more functional) mechanisms
for people to get the same benefits that they get from NATs
I had proposed limiting the use of site-locals to completely isolated
networks (i.e. test networks and/or networks that will never be
connected to other networks). This would give administrators of
those networks an address space to use (FECO::/10) for those networks
The first question that
GUPI would not be globally routable. It would be a way to make sites
privately communicate, as neither the limited usage or the
moderate
usage of site-locals provides this.
And compared to global addresses the advantage is?
Besides not having to go to a RIR?
not having to have a connection
1 - 100 of 145 matches
Mail list logo
