On Tue, Nov 12, 2002 at 02:03:43PM +1100, Mark Smith wrote:
>
> However, I can't see a typical organisation changing its global prefix
> more than once every thirty days. If you do, maybe Mobile IPv6 is the
> thing for you (I could be speaking out of turn here, I don't know much
> about Mobile IPv
- Address lookup is significantly more complex in the presence of
site-local than if only global-scoped addresses are used
I agree with this conclusion. But I think that site-locals comes with a
lot more problems than that. I think it will drag us into the "RFC1918
swamp" of problems we have
David Conrad wrote:
>
> Hi,
>
> On 11/11/02 9:15 AM, "Harald Tveit Alvestrand" <[EMAIL PROTECTED]> wrote:
> > my personal opinion is that the only people who feel any possessive
> > instinct towards 2002:d90d:1cca:2:210:dcff:fe5a:f1fd are the people who
> > have to reconfigure other stuff when it
On Tue, Nov 12, 2002 at 09:52:37AM +0100, Brian E Carpenter wrote:
> David Conrad wrote:
> >
> > Welcome to NATv6.
>
> It's our job to stop that happening.
>
> Also, the vast majority of Internet users are not in the least
> possessive about their IP address; it's different every time they
> con
Hi Tim,
Our "job" is to provide a well-engineered alternative that the
market will demand.
Excellent point, and well put.
Margaret
IETF IPng Working Group Mailing List
IPng Home Page: http://playground
below...
Margaret Wasserman wrote:
>
> Hi Brian,
>
> > > Welcome to NATv6.
> >
> >It's our job to stop that happening.
>
> I agree, and I actually consider our job to be even bigger
> than this...
>
> We need to create the technologies and policies that will enable a
> globally-addressable, "f
Hi Brian,
So, why not simply deprecate SL for sites that have at least one
global prefix? Or am I too simple minded?
If you are too simple minded, then I am right there with you.
My making this exact suggestion is what started the 500+ message
mail storm two weeks ago that has received so muc
My biggest concern is that there is the assumption that there will ALWAYS
be more than enough IP numbers in IPv6. Wasn't that the thought when IPv4
was started?
Is NAT or a "NAT-like" option the best thing to use? No, but it WILL be
used. Whether it is due to some network engineer that doesn't un
> But, what I don't understand is how the use of overlapping
> site-local addresses on globally-attached networks is any
> better than NAT.
It is not. Same problems that NAT has. And loss of e2e: apps,
security, and mobility for those who only have those SLs. Not good.
As a note industry wi
I am also of this simple mind.
/jim
[In matters of style, swim with the currentsin matters of principle,
stand like a rock. - Thomas Jefferson]
IETF IPng Working Group Mailing List
IPng Home Page: http
> Does anyone think that a validity lifetime should be associated to the
> prefix during prefix delegation?
that's a good point.
> Indeed RAs sent on a link associate a valid lifetime and a preferred
> lifetime to the advertised prefixes.
I would like to take this idea to the next draft. thanks
Gary,
That is the slippery slope that got RFCs 1597 and 1631 published, and
led us to a sea of troubles.
Let's do better this time: just say no. Keep site locals for their
intended purpose, i.e. isolated sites.
Brian
[EMAIL PROTECTED] wrote:
>
> My biggest concern is that there is the ass
Unfortunately it's too late to catch the addressing architecture
document unless we recall it from the RFC Editor and cycle it
through the IESG again. But I propose that we do exactly that,
in order to change the following paragraph in section 2.5.6:
Current text:
>Site-local addresses are de
Current text:
Hi Brian,
>Site-local addresses are designed to be used for addressing inside of
>a site without the need for a global prefix. Although a subnet ID
>may be up to 54-bits long, it is expected that globally-connected
>sites will use the same subnet IDs for site-l
Margaret Wasserman wrote:
Current text:
Hi Brian,
>Site-local addresses are designed to be used for addressing
inside of
>a site without the need for a global prefix. Although a subnet ID
>may be up to 54-bits long, it is expected that globally-connected
>sites will use t
On Tue, Nov 12, 2002 at 12:07:03PM +0100, Brian E Carpenter wrote:
>
> So, why not simply deprecate SL for sites that have at least one
> global prefix? Or am I too simple minded?
I think a site getting global connectivity would find it hard to migrate
instantly from site-locals to globals. The
On Tue, 12 Nov 2002, Brian Haberman wrote:
> Margaret Wasserman wrote:
> >
> >>
> >> Current text:
> >
> >
> > Hi Brian,
> >
> >> >Site-local addresses are designed to be used for addressing
> >> inside of
> >> >a site without the need for a global prefix. Although a subnet ID
> >> >
... look at draft-chelius-adhoc-ipv6-00.txt
>In this document, a new
>addressable object is defined: the ad hoc connector. It virtualizes
>several ad hoc network interfaces into a single addressable object.
>To locally address ad hoc connectors, a third IPv6 local-use unicast
>
> From: Tim Chown <[EMAIL PROTECTED]>
> I think a site getting global connectivity would find it hard to migrate
> instantly from site-locals to globals. The suggestion to prefer globals
> over site locals in the default address selection spec, along with Brian's
> suggested text a couple of mai
On Tue, 12 Nov 2002, Brian E Carpenter wrote:
[...]
> Otherwise, we will need a whole new RFC just for this paragraph.
>
> Alternatively, we could spend the next 5 years discussing the
> unnecessary complexities of using site-locals on connected sites.
Note that we will need at least one more RFC
I understand the theoretical issue, but is this a real-life issue?
How many huge non-globally-connected IP networks will ever need to
join the Internet?
Margaret
At 09:25 AM 11/12/02, Tim Chown wrote:
On Tue, Nov 12, 2002 at 12:07:03PM +0100, Brian E Carpenter wrote:
>
> So, why not simply de
I also totally agree.
/jim
[In matters of style, swim with the currentsin matters of principle,
stand like a rock. - Thomas Jefferson]
> -Original Message-
> From: Pekka Savola [mailto:pekkas@;netcore.fi]
> Sent: Tuesday, November 12, 2002 9:31 AM
> To: Brian Haberman
> Cc: Margare
On Tue, Nov 12, 2002 at 05:12:22PM +0200, Markku Savela wrote:
>
> Why should it be a problem?
>
> - it seems that it would be advantageous for nodes within the site to
> use sitelocals whenever possible, especially if your global
> connection is via flaky connection.
Indeed, but this is the
Brian E Carpenter writes:
> David Conrad wrote:
> > > my personal opinion is that the only people who feel any possessive
> > > instinct towards 2002:d90d:1cca:2:210:dcff:fe5a:f1fd are the people who
> > > have to reconfigure other stuff when it changes.
> >
> > Or the people who are aff
> Margaret Wasserman wrote:
> But, what I don't understand is how the use of
> overlapping site-local addresses on globally-attached
> networks is any better than NAT.
It's not as bad (does not break apps that embed port numbers in the
payload, for example) but this is an irrelevant argument: it s
> As far as I can see, the safe way to do "two-faced" DNS with site locals is
there is no safe way to do DNS with site locals, because the DNS server
has no idea who is acutally going to use the results of the query.
it's not reasonable to assume that the results will be used by the
host immediate
Tim Chown wrote:
>
> On Tue, Nov 12, 2002 at 05:12:22PM +0200, Markku Savela wrote:
> >
> > Why should it be a problem?
> >
> > - it seems that it would be advantageous for nodes within the site to
> > use sitelocals whenever possible, especially if your global
> > connection is via flaky conn
Count me in on agreeing with Brian too.
Mike
Pekka Savola writes:
> On Tue, 12 Nov 2002, Brian Haberman wrote:
> > Margaret Wasserman wrote:
> > >
> > >>
> > >> Current text:
> > >
> > >
> > > Hi Brian,
> > >
> > >> >Site-local addresses are designed to be used for add
> > > - it seems that it would be advantageous for nodes within the site to
> > > use sitelocals whenever possible, especially if your global
> > > connection is via flaky connection.
> >
> > Indeed, but this is the dilemma between preference for globals to avoid the
> > site-local scoping "h
On Tue, Nov 12, 2002 at 06:21:42PM +0200, Markku Savela wrote:
>
> > Er, but I use global addresses every day on good ol' IPv4, within my
> > employer's internal network, and they work just fine when external
> > connectivity is broken. I see no advantage in local addresses here.
>
> Well, but th
One more try on sin6_flowinfo for 2553bis, adopting Brian's
verbage and laying the foundation for application compatibility
with future use of the field:
The sin6_flowinfo field is a 32-bit field intended to contain
flow-related information. The exact way this field is mapped
to or
> Here are three models for address selection when both site-local and global
> addresses are available. Which (if any) is preferred:
fourth model:
discourage use of site-locals when stable global addresses are available:
Pros: drastically reduces complexity of applications that would otherwise
Brian E Carpenter wrote:
Unfortunately it's too late to catch the addressing architecture
document unless we recall it from the RFC Editor and cycle it
through the IESG again. But I propose that we do exactly that,
in order to change the following paragraph in section 2.5.6:
[...]
Alternati
Summary: a provider independent addressing solution is proposed so that
site-locals are not necessary.
One of the chief reasons proposed for the use of site-locals is for stable
addressing (especially if you need to change ISP's). A nicer solution, that
has so far proven unimplementable is prov
Harald,
>> Michel Py wrote:
>> What would be the difference between this and the good
>> old "8K DFZ", except one more digit and that ISPs could
>> get a block matching their size instead of what used to
>> be called a TLA?
> Harald Tveit Alvestrand wrote:
> Apart from not having any administrati
> Er, but I use global addresses every day on good ol' IPv4,
> within my employer's internal network, and they work just
> fine when external connectivity is broken. I see no advantage
> in local addresses here.
Same here for me. I see not advantage at all and lots of pain.
/jim
---
OK folks I am counting and I see clear majority for margarets proposal?
/jim
[In matters of style, swim with the currentsin matters of principle,
stand like a rock. - Thomas Jefferson]
> -Original Message-
> From: Alain Durand [mailto:Alain.Durand@;Sun.COM]
> Sent: Tuesday, Novembe
I support this suggested course of action and the proposed new text.
- Ralph
At 01:53 PM 11/12/2002 +0100, Brian E Carpenter wrote:
Unfortunately it's too late to catch the addressing architecture
document unless we recall it from the RFC Editor and cycle it
through the IESG again. But I propose
I strongly disagree with this suggestion.
Site-local addresses (and more generally, scoped addresses) are a
fundamental part of the IPv6 architecture. They are an important
feature of IPv6, one of the great improvements that makes IPv6 better
than IPv4. It would be a serious loss to IPv6 if site
> I think NATv6 is inevitable, because some site policy makers will demand
> it.
which is why we need to make it very clear that NAT is not acceptable
in IPv6.
IETF IPng Working Group Mailing List
IPng Home Page:
I don't really have a strong opinion one way
or the other, but I would like to make the following
observations:
- "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.
- People have shown that there are ways of using
site-locals f
Hi Brian,
> Welcome to NATv6.
It's our job to stop that happening.
I agree, and I actually consider our job to be even bigger
than this...
We need to create the technologies and policies that will enable a
globally-addressable, "flat" IPv6 Internet.
We need to understand and document how a
I support this change and the new text.
Mark.
> At 01:53 PM 11/12/2002 +0100, Brian E Carpenter wrote:
> >Unfortunately it's too late to catch the addressing architecture
> >document unless we recall it from the RFC Editor and cycle it
> >through the IESG again. But I propose that we do exactly
Margaret,
> But, why make them inherently private, non-routable
> addresses? If we come up with a reasonable way to
> allocate globally-unique, provider-independent
> addresses, is there a reason to require that they
> be non-globally-routable?
Network administrators want private (read: not publi
> Those who are possessive are those who run services of one
> kind or another.
I think this is a bit too specific - until we produce a good way of
doing renumbering, any site with more than a few hosts has good reason
to want its addresses to be stable, whether or not it thinks it
is running 'se
> Unfortunately it's too late to catch the addressing architecture
> document unless we recall it from the RFC Editor and cycle it
> through the IESG again. But I propose that we do exactly that,
> in order to change the following paragraph in section 2.5.6:
>
> Current text:
>
>> Site-local addr
What Brian C., Margaret, Brian H., Pekka, Mike, Jim, Alain, Ralph,
Keith, and Mark said, but not what Brian Z. said :).
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP a
> What Brian C., Margaret, Brian H., Pekka, Mike, Jim, Alain, Ralph,
> Keith, and Mark said, but not what Brian Z. said :).
what he said
IETF IPng Working Group Mailing List
IPng Home Page: http://playground
> Randy Bush wrote:
> processwise it could be done with a note to the rfc
> editor or in the 48 hour edit call as s/he is doing
> the final edits.
Processwise a recall from the RFC editor could also be challenged all
the way to the IAB or even the ISOC and lead us to 1000+ more emails up
front and
Hi All,
Maybe, but I think most Network administrators understand that using
guess-what-I-hijacked addresses is risky. Instead I bet you'll see them
rolling their own NATv6 solutions. It's lot easier for us v4-ish
old-timers to understand than some of what I've read here today :-)
-JB-
M
Hi,
What they said.
I mean, I support Brian's wording change in the RFC. Being a newbie on
this list I probably shouldn't get a vote, but being a newbie I may have
a new perspective. A lot of the networking world sees IPv6 as still
thrashing and not ready for prime time. A year ag
>
> Personally, I don't have a big problem with the suggestion
> itself, but I do not agree with it, simply because it's a
> meaningless restriction. I'd rather see a
> separate BCP for this, or at least say should not and
> explain why.
>
I agree with Hesham here. Should we not explain w
Mohan Parthasarathy writes:
>
> >
> > Personally, I don't have a big problem with the suggestion
> > itself, but I do not agree with it, simply because it's a
> > meaningless restriction. I'd rather see a
> > separate BCP for this, or at least say should not and
> > explain why.
>
Turn your back to cover day-job issues for a couple of days, and all
hell breaks loose
There is absolutely no reason to restrict SL to disconnected sites. If
someone wants to write an RFC on why they increase complexity for
multi-party apps, fine. That does not mean we need to significantly
ch
> What I want to know is why the concept "local" in
> the absense of enforceability (cf strong auth)
> isn't a thoroughly bogus concept.
for the purpose of security, in any network of significant size,
it certainly is.
if site-locals are useful at all it is not because of security.
Keith
--
What I want to know is why the concept "local" in
the absense of enforceability (cf strong auth)
isn't a thoroughly bogus concept. Site-locals seem
to be trying to cling to that discredited
bogosity.
Mike
Keith Moore writes:
> > Here are three models for address selection when both si
I haven't caught up with the whole thread (as can well be imagined), but I
agree as well.
-jj
On Tue, Nov 12, 2002 at 02:58:42PM -0500, Bound, Jim wrote:
> OK folks I am counting and I see clear majority for margarets proposal?
>
> /jim
> [In matters of style, swim with the currentsin matte
Keith Moore writes:
> > What I want to know is why the concept "local" in
> > the absense of enforceability (cf strong auth)
> > isn't a thoroughly bogus concept.
>
> for the purpose of security, in any network of significant size,
> it certainly is.
>
> if site-locals are useful at all
> > > What I want to know is why the concept "local" in
> > > the absense of enforceability (cf strong auth)
> > > isn't a thoroughly bogus concept.
> >
> > for the purpose of security, in any network of significant size,
> > it certainly is.
> >
> > if site-locals are useful at all it is n
> As I said before, it seems that everyone agrees that a globally unique
> site-local would be the way to go, but there are two major roadblocks to
> remove on that path:
> - Make sure that site-locals are not globally routable (I posted some
> comments about this earlier)
seems fairly easy. the
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 addressing consumes address
|> spac
Do you meant to imply that a separate block of addresses should be
set aside for non-globally-routable globally-unique addresses?
I'm not sure what we gain by doing that, as opposed to setting aside
private address space from any global prefix by filtering it at
administrative boundaries...
Marg
> Do you meant to imply that a separate block of addresses should be
> set aside for non-globally-routable globally-unique addresses?
yes.
> I'm not sure what we gain by doing that, as opposed to setting aside
> private address space from any global prefix by filtering it at
> administrative boun
> I'm not sure what we gain by doing that, as opposed to setting aside
> private address space from any global prefix by filtering it at
> administrative boundaries...
we need the ability to assign global prefixes to sites that aren't
directly connected to the public Internet, even though they
> > > I'm not sure what we gain by doing that, as opposed to setting aside
> > > private address space from any global prefix by filtering it at
> > > administrative boundaries...
> >
> > we need the ability to assign global prefixes to sites that aren't
> > directly connected to the public Intern
On Tue, 12 Nov 2002, Keith Moore wrote:
> > I'm not sure what we gain by doing that, as opposed to setting aside
> > private address space from any global prefix by filtering it at
> > administrative boundaries...
>
> we need the ability to assign global prefixes to sites that aren't
> directly co
On Tue, 12 Nov 2002, Keith Moore wrote:
> > > > I'm not sure what we gain by doing that, as opposed to setting aside
> > > > private address space from any global prefix by filtering it at
> > > > administrative boundaries...
> > >
> > > we need the ability to assign global prefixes to sites that
> Okay.
>
> But, why make them inherently private, non-routable addresses?
> If we come up with a reasonable way to allocate globally-unique,
> provider-independent addresses, is there a reason to require
> that they be non-globally-routable?
those would be okay for my purposes. because I see gl
Totally unacceptable.
/jim
[In matters of style, swim with the currentsin matters of principle,
stand like a rock. - Thomas Jefferson]
> -Original Message-
> From: Keith Moore [mailto:moore@;cs.utk.edu]
> Sent: Tuesday, November 12, 2002 11:12 AM
> To: Tim Chown
> Cc: IPng
> Subjec
> > > > > I'm not sure what we gain by doing that, as opposed to setting aside
> > > > > private address space from any global prefix by filtering it at
> > > > > administrative boundaries...
> > > >
> > > > we need the ability to assign global prefixes to sites that aren't
> > > > directly connec
I support this text.
should "must not" be in upper case?
>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 i
Keith Moore <[EMAIL PROTECTED]> wrote:
|Neither does it scale to expect all hosts to maintain
|enough information to let them do routing.
On the contrary, distributed host-based routing is one of the few solutions
that does scale well. The availability of resources to deal with the routing
grow
> Site-local addresses (and more generally, scoped addresses) are a
> fundamental part of the IPv6 architecture. They are an important
> feature of IPv6, one of the great improvements that makes IPv6 better
> than IPv4. It would be a serious loss to IPv6 if site-local addresses
> were only allowe
> On Tue, 12 Nov 2002 13:53:00 +0100,
> Brian E Carpenter <[EMAIL PROTECTED]> said:
> Unfortunately it's too late to catch the addressing architecture
> document unless we recall it from the RFC Editor and cycle it
> through the IESG again. But I propose that we do exactly that,
> in orde
> I don't really have a strong opinion one way
> or the other, but I would like to make the following
> observations:
>
> - "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.
perhaps not, but protocols DO break when we subject
Processwise a recall from the RFC editor could also be challenged all
the way to the IAB or even the ISOC and lead us to 1000+ more emails up
front and 1 more before all the appeal processes have been
exhausted. Is this the road we are taking?
Without pointing at anyone in particular...
Why
> Network administrators want private (read: not publicly routable)
> addresses.
a) they are not the same thing
b) I also maintain that this is not really what network administrators
want. they may equate what they want to this, but see a.
Keith
---
>Unfortunately it's too late to catch the addressing architecture
>document unless we recall it from the RFC Editor and cycle it
>through the IESG again. But I propose that we do exactly that,
>in order to change the following paragraph in section 2.5.6:
>
>Current text:
>
>>Site-local addresse
> There is absolutely no reason to restrict SL to disconnected sites.
Tony, we've been discussing the reasons for weeks now. It's pretty
disingeneous to say 'absolutely no reason' in the face of this.
Face it, SLs as originally conceived are broken. This is the simplest fix.
Keith
Michael Thomas wrote:
> Keith Moore writes:
> > > What I want to know is why the concept "local" in
> > > the absense of enforceability (cf strong auth)
> > > isn't a thoroughly bogus concept.
> >
> > for the purpose of security, in any network of significant
> size, > it certainly is. >
Keith Moore wrote:
> > There is absolutely no reason to restrict SL to disconnected sites.
>
> Tony, we've been discussing the reasons for weeks now. It's
> pretty disingeneous to say 'absolutely no reason' in the face of this.
>
> Face it, SLs as originally conceived are broken. This is the
> Access control is one aspect of what SL provides.
SL provides no benefits for access control that is not provided by
the ability to filter globals, and you need to do this anyway.
> and enterprise
> managers can filter without having to go into detail about which
> specific devices on a subnet
> The fundemental issue here the architecture has been changed to support
> multiple simultanious scopes.
And it was taken too far before the consequences were understood.
Now we're fixing this bug, and it's about time.
> Those that are having a hard time figuring
> out how to do that are oppo
Keith Moore wrote:
> ...
> Why in the world you should be trying to promote dysfunction in the
> network is beyond me.
I am not promoting dysfunction, that will happen for operational /
policy reasons. I am trying to make sure that when it does happen, there
is a clearly understood mechanism fo
> > Why in the world you should be trying to promote dysfunction in the
> > network is beyond me.
>
> I am not promoting dysfunction, that will happen for operational /
> policy reasons. I am trying to make sure that when it does happen,
> there is a clearly understood mechanism for identifying
85 matches
Mail list logo
