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 enterprise? The stability of my home network is more important
to me than the stability of any
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 switch.
Today, ISPs experience a cost advantage when they limit the
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 switch.
|
|Today, ISPs
We're getting way outside IETF territory here. This is my
last note on this subthread:
Dan Lanciani wrote:
Brian E Carpenter [EMAIL PROTECTED] wrote:
|Dan Lanciani wrote:
|...
| Please explain *specifically* what new mechanism v6 supports for providers to
| realize their service
Why would you expect an ISP to give up this revenue stream?
Your theory that the ISP's cost advantage in limiting the number and
stability
of addresses is solely (or even mostly) a result of scarcity is not consistent
with the ISP industry as it currently exists.
|We aren't here to provide
Brian E Carpenter [EMAIL PROTECTED] wrote:
|We're getting way outside IETF territory here.
Come on. Understanding the availability of global addresses from ISPs is
critical to analyzing the need for various kinds of local addressing solutions.
It is unreasonable to assert such availability as a
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 enterprise? The stability of my home network is more important
to me than the stability of any enterprise network.
|Frankly, I do
Brian, Dan,
|
|Because one of their competitors decides to do so, forcing them to do
|so as well. Absent scarcity, charging for something that has zero cost
|simply isn't sustainable in a competitive market.
That's what they said about the phone companies, yet I still pay lots of
Tim Hartrick [EMAIL PROTECTED] wrote:
|Brian, Dan,
|
| |
| |Because one of their competitors decides to do so, forcing them to do
| |so as well. Absent scarcity, charging for something that has zero cost
| |simply isn't sustainable in a competitive market.
|
| That's what they said about the
Dan,
Actually, I'm not sure I do agree. I can imagine address allocation and
routing protocols which would vest far less power in the existing oligopoly,
thus promoting true competition.
|The best we can do is design tools that, when applied
|to a competitive environment, will yield
Tim Hartrick [EMAIL PROTECTED] wrote:
| Designing tools that yield the desired results only when applied to a
| competitive environment (assuming there is no valid technical reason
| for the limitation) is at best bad engineering. Doing so when there
| is good evidence that the competitive
This does not answer the question of why you assume that ISPs will change
their business models under v6.
I said:
|The ISPs business model is about service differentiation.
And I agree that they most likely will continue with service differentiation.
But I think they can change the
Erik Nordmark [EMAIL PROTECTED] wrote:
| This does not answer the question of why you assume that ISPs will change
| their business models under v6.
|
|I said:
| |The ISPs business model is about service differentiation.
|
|And I agree that they most likely will continue with service
Erik Nordmark [EMAIL PROTECTED] wrote:
| |Sorry for the delayed response - didn't see me in the to: or cc: fields.
|
| I try to keep all the mail to the list just to the list...
|
|As long as you don't ask me direct questions and expect me to answer
|than would be fine. This time it took almost
|Sorry for the delayed response - didn't see me in the to: or cc: fields.
I try to keep all the mail to the list just to the list...
As long as you don't ask me direct questions and expect me to answer
than would be fine. This time it took almost 2 months...
|You seem to be assuming flash
This assumes that ISPs will use site-locals.
Where does this come from? There is nothing in Richard's text that
implies anything about the ISPs _using_ site locals. It talks about
_filtering_ them.
Sorry, I meant to say using them by configuring site boundaries
but I agree that it is
I certainly agree with your first point: considering a block of addresses
trustworthy is silly. What site locals give you is a component of defense
in depth: if an application listen only to a local scope addresses, it will
not receive any packet that come directly from the Internet. Like it
Perhaps more importantly, I don't buy the argument that *any* set of
addresses should be considered trustworthy, by default or otherwise.
Addresses are simply not sufficient as an authentication mechanism.
This is not a practice that IETF standards should endorse or encourage.
I
On torsdag, nov 21, 2002, at 04:01 Europe/Stockholm, Erik Nordmark
wrote:
This assumes that ISPs will use site-locals. So far I haven't seen any
claims of benefits for ISPs to configure site boundaries and use
site-local
addresses in their network.
If the ISPs don't use it the only boundaries
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?
Folks on this list
Erik,
Michel Py wrote:
Where does this come from? There is nothing in Richard's
text that implies anything about the ISPs _using_ site
locals. It talks about _filtering_ them.
Erik Nordmark wrote:
Sorry, I meant to say using them by configuring site
boundaries but I agree that it is
Sorry for the delayed response - didn't see me in the to: or cc: fields.
|In terms of the stability of the addresses one has to take into account
|both stability as it relates to local communication and stability for
|global communication.
We have always been told that stable global v6
For the disconnected site I think the site-locals work just fine, and
I haven't seen any strong arguments against using site-locals for
a disconnected site.
As many others have pointed out the complexity is not associated
with the case of the disconnected site.
Agreed, however my problem with
Not surprisingly, this reminds me of our discussion of Default Address
Selection. :-) Obviously, an application or device must have *some*
out of the box configuration.
Unfortunately there is a trade-off between security usability. One can
imagine several possible out of the box
First, site-locals offer better security than a single firewall, because
typically there will be multiple routers on the path between an attacker
and a customer site, all filtering site-locals. Second, I agree that
strong security is great and we should work towards it. But defense in
depth
Perhaps more importantly, I don't buy the argument that *any* set of
addresses should be considered trustworthy, by default or otherwise.
Addresses are simply not sufficient as an authentication mechanism.
This is not a practice that IETF standards should endorse or encourage.
I certainly
On Thu, 21 Nov 2002, Erik Nordmark wrote:
This assumes that ISPs will use site-locals. So far I haven't seen any
claims of benefits for ISPs to configure site boundaries and use site-local
addresses in their network.
If the ISPs don't use it the only boundaries would be at the attacker (which
Erik,
Richard Draves wrote:
First, site-locals offer better security than a
single firewall, because typically there will be
multiple routers on the path between an attacker
and a customer site, all filtering site-locals.
Second, I agree that strong security is great
and we should work
Erik Nordmark writes:
I don't think stable addresses per se is the key
thing - it is the robustness of the communication
that is important.
I agree with this. However, the minimal degree of robustness
is working at all - something which requires some address of
some sort. There
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? I can see ISPs wanting to charge for extra services where they
I agree with this. However, the minimal degree of robustness is working
at all - something which requires some address of some sort. There
needs to be a way to get an address when you don't have a provider.
This means either scoped addresses as we have defined them already (and
in
Erik Nordmark [EMAIL PROTECTED] wrote:
|Being the probable guilty party for introducing this thought back in
|draft-*-site-prefixes-00.txt I can offer a slightly expanded perspective.
|
|I don't think stable addresses per se is the key thing - it is
|the robustness of the communication
I think, but I'm not certain, that most of the large sites
that do this have completely different DNS content in the
two-faces i.e. it is more like two separate DNS services than
two-faces of the same DNS database. That is, the DNS outside
the firewall contain a subset of the RRs and
Yes, needless complexity is bad. But site-locals don't add any
significant complexity to applications (which I think I've demonstated
enough in too many emails already).
this is only true if globals are always available to any node that
potentially participates in an application that
Hi Jim,
There needs to be a way to get an address when you don't
have a provider. This means either scoped addresses as we
have defined them already (and in multi-link locations, this
means either site-local or multi-link subnet routers and
link-local), or some sort of
Yes, needless complexity is bad. But site-locals don't add any
significant complexity to applications (which I think I've
demonstated
enough in too many emails already).
this is only true if globals are always available to any node
that potentially participates in an application
Richard Draves writes:
Yes, needless complexity is bad. But site-locals don't add any
significant complexity to applications (which I think I've
demonstated
enough in too many emails already).
this is only true if globals are always available to any node
that
I find this kind of thinking rather suspect. The
question in my mind shouldn't be why global, but
why not global. There seems to an underlying
assumption that site locals would give better
security properties due to their global
inaccessibility. I find that rather uncompelling
and
I think the vendor of one of
these devices should have the freedom to determine the
device's out
of the box configuration, based on expected usage patterns.
Here I strongly disagree. It's simply not reasonable in
general for a vendor to make assumptions about the
distribution of
It doesn't matter how many times you write this, you can not make it
become true. Brian keeps pointing out the simple case of an
intermittently connected network getting a different prefix on each
connect, but you keep ignoring it. STABLE ADDRESS SPACE IS A MAJOR
APPLICATION REASON TO HAVE
So let's not loose sight of the fact that the goal is a robust network.
well said. and offhand I don't see any reason to assume that SL addresses
are more stable/robust than globals.
IETF IPng Working Group Mailing List
IPng
Erik Nordmark [EMAIL PROTECTED] wrote:
|Being the probable guilty party for introducing this thought back in
|draft-*-site-prefixes-00.txt I can offer a slightly expanded perspective.
|
|I don't think stable addresses per se is the key thing - it is
|the robustness of the communication that is
Erik Nordmark writes:
I don't think stable addresses per se is the key
thing - it is the robustness of the communication
that is important.
I agree with this. However, the minimal degree of robustness is working
at all - something which requires some address of some sort. There
needs to be a
There is no compromise position between the two points of view here.
Personally I'm hopeful that the opportunity for some us to talk about this
face-to-face in Atlanta will give us a chance to resolve these differences.
I do see some convergence happening, even over email.
Keith Moore writes:
In either example the problem is solved if B and C
have global addresses, and all referrals filter
SL addresses.
Yes, nodes communicating globally should have global addresses, and then
there is no problem. (Although again, I think you're being overly
draconian with the
I miss something ?
Yoann
-Message d'origine-
De : Alain Durand [mailto:Alain.Durand;Sun.COM]
Envoye : mercredi 13 novembre 2002 19:57
A : NOISETTE Yoann FTRD/DMI/CAE
Cc : [EMAIL PROTECTED]
Objet : Re: Proposal for site-local clean-up
NOISETTE Yoann FTRD/DMI/CAE wrote:
Hi all,
I would
--On onsdag, november 13, 2002 14:20:42 -0800 Tony Hain [EMAIL PROTECTED]
wrote:
Margaret Wasserman wrote:
How often do you think that people really set-up a private,
disconnected network and later connect it to the Internet?
Do you think this will be a common real-life case, or is this
Zill [EMAIL PROTECTED]
cc:Brian E Carpenter [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject:RE: Summary Re: Proposal for site-local clean-up
How often do you think that people really set-up a private,
disconnected network and later connect it to the Internet?
Do you think
Keith Moore writes:
In either example the problem is solved if B and C
have global addresses, and all referrals filter
SL addresses.
Yes, nodes communicating globally should have global addresses, and then
there is no problem.
they don't need to be communicating globally, or to have
On Wed, 13 Nov 2002 23:48:54 -0500,
Keith Moore [EMAIL PROTECTED] said:
I would say, hoping this does not cause another flame, that the issues
of site-local are not crucial for the deployment of IPv6.
I respectfully disagree. I think it's critical that we solve this
issue; otherwise
I think Brian's proposal, if adopted, makes my worry about site-locals
inducing complexity in naming lookup mechanisms go away (naming mechanisms
for disconnected networks have to be different from those for connected
networks anyway).
So you can count me as supporting the proposal.
That
If I could sleep assured that site-locals would not be used for any
other network than networks not connected to global Internets, I would
be all for this. What still have me really worried is that there is no
way to enforce this, and it is just inviting NATv6.
In that case Brians wording
Hi all,
I would possibly agree with this change, but it must be clear that some
ongoing work or considered solutions will be restricted or even totally
impossible after this new statement becomes effective.
For instance, draft-ietf-ipv6-dns-discovery-07.txt gives many examples
of a Customer
Keith Moore writes:
Hesham writes:
- MUST NOTs are there for a reason, saying MUST NOT
when it can be done and protocols don't break is not
a good idea.
I agree with Hesham. We shouldn't be applying MUST NOTs to situations
where we have workable solutions. Restricting site-locals to
I agree with Hesham. We shouldn't be applying MUST NOTs to situations
where we have workable solutions.
the closest thing we have to a workable solution is to find a way to
give every site that connects to another network a global prefix
(whether it's globally connected or not) and have
From: Harald Tveit Alvestrand [EMAIL PROTECTED]
every time we come across a case where complexity is increased by
considering how to use site-local concurrently with global addresses (my
favourite list starts with source address selection and DNS lookup, but
does not end there.),
--On onsdag, november 13, 2002 16:38:55 +0200 Markku Savela
[EMAIL PROTECTED] wrote:
(my
favourite list starts with source address selection and DNS lookup, but
does not end there.),
1. There is NO PROBLEM with source address selection.
- if your destination is site local, your source
Well, there are far more people saying yes than no, but let me
respond to some of the comments made.
1. Process (Tony Hain). Of course. If we make a substantive change
to a draft that's already passed the IESG, a last call is needed IMHO. It
would still be cleaner than publishing the RFC and then
Brian E Carpenter wrote:
Proposed new text:
Site-local addresses are designed to be used for addressing inside of
a site which is not connected to the Internet and therefore does not
need a global prefix. They must not be used for a site that is connected
to the Internet. Using
My view on this is that you need the scoped DNS architecture, which
can be seens as extension to two-faced DNS. You can have
DNS is only one of many applications that have this problem. you can't
solve the DNS problem and ignore those of the other applications.
also, scoped DNS will break
Vladislav Yasevich wrote:
Brian E Carpenter wrote:
Proposed new text:
Site-local addresses are designed to be used for addressing inside of
a site which is not connected to the Internet and therefore does not
need a global prefix. They must not be used for a site that is
Brian,
I don't think it is wise to ask the IESG to reconsider the address
architecture (this is more than an editorial change to the RFC-editor). I
also think the issues regarding the usage of site-local are more
complicated that can be expressed in a paragraph.
I don't think we will get a
Keith Moore wrote:
the closest thing we have to a workable solution is to find a
way to give every site that connects to another network a
global prefix
(whether it's globally connected or not) and have applications
ignore the SLs (at least for purpose of referrals). and if you do
Keith;
At 09:27 PM 11/12/02 -0500, Keith Moore wrote:
[snip snip snip]
No. Scopes reduce the ablity of the network to support apps.
They make it harder to produce an app that works independently
of network location, and they don't add a single extra capability
that wasn't present already.
You
Keith;
At 09:27 PM 11/12/02 -0500, Keith Moore wrote:
[snip snip snip]
No. Scopes reduce the ablity of the network to support apps.
They make it harder to produce an app that works independently
of network location, and they don't add a single extra capability
that wasn't
No. Scopes reduce the ablity of the network to support apps.
They make it harder to produce an app that works independently
of network location, and they don't add a single extra capability
that wasn't present already.
You keep saying that some apps will fail with scoped addresses. My
= I think he did to some extent, but the point
is Brian Z. and Rich already showed how this can be
done. Sure there is additional complexity, but
didn't we know this 3 years ago ? I think we did.
It is simply not acceptable to expect apps to absorb all of this
complexity for the sake of the
So much traffic has flown by on this subject that my head is still spinning.
But, let me give one example in which the use of site-locals on globally
connected networks might be useful.
While at SRI International, I had the privilege of participating in a study of
autonomous teams of unmanned
NOISETTE Yoann FTRD/DMI/CAE wrote:
Hi all,
I would possibly agree with this change, but it must be clear that some
ongoing work or considered solutions will be restricted or even totally
impossible after this new statement becomes effective.
For instance, draft-ietf-ipv6-dns-discovery-07.txt
FWIW,
This study, along with others in the US Army CECOM division,
produced the transition mechansim now known as ISATAP.
Fred Templin
[EMAIL PROTECTED]
Fred L. Templin wrote:
So much traffic has flown by on this subject that my head is still
spinning.
But, let me give one example in which
Hi Fred,
That's interesting. There has been some talk about multiple ISATAP site
routers, and scalability. Can you comment on how ISATAP performed in this
network of thousands of (mobile) hosts? (I assume you meant hundreds or
thousands, not hundreds of thousands)
Tim
On Wed, Nov 13, 2002 at
IMHO, it would almost be easier to remove the must not be used sentence
from the above paragraph.
Yes, I like that suggestion. It's consistent with Harald's comment
that we don't have an enforcement department.
Well, I don't think the paragraph is sufficient without it.
How about
Michael Thomas wrote:
So I have a question for those who support
connected site locals: what would prevent a new
RFC from updating Brian's wording for site locals
(if that's the right thing)?
I say this because it seems to me that there's a
lot of issues being conflated in these arguments
Tony Hain writes:
Michael Thomas wrote:
So I have a question for those who support
connected site locals: what would prevent a new
RFC from updating Brian's wording for site locals
(if that's the right thing)?
I say this because it seems to me that there's a
lot of issues
Tony,
Michael Thomas wrote:
So I have a question for those who support
connected site locals: what would prevent a new
RFC from updating Brian's wording for site locals
(if that's the right thing)?
I say this because it seems to me that there's a
lot of issues being conflated
Take the case of a 20,000 node network where half are allowed global
access and half are not. It is much more complex to sort through a
10,000 node list per packet for access filtering than it would be to
have two entries, SL deny PA allow. Yes the list of which 10,000 nodes
are allowed the
Mohan Parthasarathy wrote:
...
I miss something here. How do you make sure that nodes
configure just site local and not global address on seeing an
RA ? Are you keeping them in separate networks i.e not mixing
nodes that require globals and site locals ? If so, then I
can do the same
Margaret Wasserman wrote:
...
How are you planning to configure and organize these 20,000 nodes?
The ones that should not have public access would be configured to only
listen for the SL prefix in an RA, or could be fed by DHCP.
If the private nodes are randomly distributed around the
Brian Carpenter writes:
3. Can't stop NAT's anyway. (several people).
That may sadly be true, but we shouldn't publish
specs that seem to encourage them.
I would argue the opposite -- *preventing* site-locals and globals from
co-existing encourages NAT. We're better off today than we would be
Keith Moore wrote:
Finally, the team as a whole is only intermittently connected to the
global Internet - perhaps with long periods of disconnected operation.
yes, intermittent connection is one of the genuinely valid justifications
for SLs.
Glad to hear you agree.
however even with
How often do you think that people really set-up a private,
disconnected network and later connect it to the Internet?
Do you think this will be a common real-life case, or is this
more of a theoretical edge case?
Margaret
At 04:51 PM 11/13/02, Brian Zill wrote:
Brian Carpenter writes:
3.
I miss something here. How do you make sure that nodes
configure just site local and not global address on seeing an
RA ? Are you keeping them in separate networks i.e not mixing
nodes that require globals and site locals ? If so, then I
can do the same with globals with appropriate
Tim Chown wrote:
Hi Fred,
That's interesting. There has been some talk about multiple ISATAP site
routers, and scalability. Can you comment on how ISATAP performed in this
network of thousands of (mobile) hosts?
I don't have any scaling figures from actual experiments, but scaling is
bounded
Margaret Wasserman wrote:
How often do you think that people really set-up a private,
disconnected network and later connect it to the Internet?
Do you think this will be a common real-life case, or is this
more of a theoretical edge case?
Said real company needed to get IPv6 running
Margaret Wasserman wrote:
How often do you think that people really set-up a private,
disconnected network and later connect it to the Internet?
Do you think this will be a common real-life case, or is this
more of a theoretical edge case?
Here again is the case for mobile ad-hoc networks. By
Mohan Parthasarathy wrote:
...
I miss something here. How do you make sure that nodes
configure just site local and not global address on seeing an
RA ? Are you keeping them in separate networks i.e not mixing
nodes that require globals and site locals ? If so, then I
can do
Roy Brabson wrote:
...
So, instead of filtering global addresses at the firewall,
you go to each
individual box in the network which you want to restricted
access to/from
and configure it to only use restricted (i.e., site-local)
addresses? And,
as a bonus, you get to deal with all
Mohan Parthasarathy wrote:
I agree that this is possible. But this is extra
configuration and assumption that the restricted box IPv6
implementation has support for such policy knobs.
Yes. It also aligns the policy implementation with the device that is
restricted, rather than trying to
On Wed, Nov 13, 2002 at 02:30:55PM -0800, Fred L. Templin wrote:
IPv6 is about anticipating and designing for *future* use cases
as well as the existing paradigms of today, right? I'm *not*
suggesting that we drop back into research-mode - only that
we keep our sights set forward while we
Keith Moore wrote:
...
Even
when it is available, that does not automatically create a
reason to
restrict the use of SL. It will always be easier to filter
a short /10
than to maintain a long list of access controls at the
border. THIS IS
A MAJOR OPERATIONAL REASON TO USE SL.
Well, there are far more people saying yes than no, but let
me respond to some of the comments made.
1. Process (Tony Hain). Of course. If we make a substantive
change to a draft that's already passed the IESG, a last call
is needed IMHO. It would still be cleaner than publishing the
I don't know how you can get from needing a simple filter to not needing
a filter...
A simple example would be; as per spec, SL is blocked at the border,
globals are allowed without restriction, and hosts that are allowed out
have a policy that allows them to configure a global prefix along
Finally, the team as a whole is only intermittently connected to the
global Internet - perhaps with long periods of disconnected operation.
yes, intermittent connection is one of the genuinely valid justifications
for SLs.
however even with intermittent connection it is often possible to use
On Wed, 13 Nov 2002 09:30:23 -0800,
Bob Hinden [EMAIL PROTECTED] said:
I don't think it is wise to ask the IESG to reconsider the address
architecture (this is more than an editorial change to the RFC-editor). I
also think the issues regarding the usage of site-local are more
Keith Moore wrote:
Well, there are far more people saying yes than no, but let me
respond to some of the comments made.
1. Process (Tony Hain). Of course. If we make a
substantive change
to a draft that's already passed the IESG, a last call is needed
IMHO. It would still
Keith Moore wrote:
I don't know how you can get from needing a simple filter to not
needing a filter... A simple example would be; as per spec, SL is
blocked at the border, globals are allowed without restriction, and
hosts that are allowed out have a policy that allows them
to
This is not a bug, it is an architectural principle. Those are not
changed on a whim after the review process has completed.
Come on, Tony. If we have a principle that justifies burdening
applications with unnecessary complexity for dubious and marginal
gain, aren't we better off without it?
One opinion. You keep saying that, but it is not requiring that the app
work using SL across the border. In fact the reason the network manager
likes SL is the apps will explicitly not work in that case.
Actually that's a delusion. In today's networks the apps are still
expected to work in
Keith Moore wrote:
This is not a bug, it is an architectural principle. Those are not
changed on a whim after the review process has completed.
Come on, Tony. If we have a principle that justifies burdening
applications with unnecessary complexity for dubious and marginal
gain,
Hi Tony,
Unnecessary, dubious, marginal are one perspective. The point is that
the recommendation to preclude simultanious use of SL global is a
serious architectural change. It is not a minor edit.
I'm not sure where the concern is coming from that we will make
a major change to the
1 - 100 of 144 matches
Mail list logo
