I vote for
A) Deprecate Site-Local addresses independently from having an
alternative
solution available. This would mean that the working group should
treat
the deprecation, and requirements and solution documents outlined above
independently from each other. If there was no consensus on an
Jim,
On tisdag, aug 19, 2003, at 02:56 Europe/Stockholm, Bound, Jim wrote:
IPv6 IS IPv4 with more bits.
On the contrary it is much more if you go down behind the user and look
at the protocol and implementation. It depends on ones view. I am
debating this with Geoff now on his Myth article
On tisdag, aug 19, 2003, at 16:56 Europe/Stockholm, Kurt Erik Lindqvist
wrote:
On tisdag, aug 19, 2003, at 02:56 Europe/Stockholm, Bound, Jim wrote:
IPv6 IS IPv4 with more bits.
On the contrary it is much more if you go down behind the user and
look
at the protocol and implementation. It
IPv6 IS IPv4 with more bits.
On the contrary it is much more if you go down behind the user and
look
at the protocol and implementation. It depends on ones view. I am
debating this with Geoff now on his Myth article and there will
another
article soon.
In that sense you are probably right. But
Patrik,
The more it is for the end-user and basic administrator (and application)
just more bits, the better.
YES! From the users perspective, the only difference should be that they
get to run new cool applications that were not available to them previously
(due to IPv4's limitations, NATs,
Kurt Erik Lindqvist wrote:
... There
are a number of ways that we have changed HOW things are
done, but it's
still the same things.
That statement exposes the problem here. Some people want to make sure that
IPv6 does *exactly* the same things that IPv4 does, while others want IPv6
to do
Tony Hain wrote:
somebody else does more. Unfortunately there are obstructionists that want
to make sure everyone does exactly the same thing, and no more than they
could do with IPv4.
getting everybody to do the same thing ... that sounds awfully close
to a standard
to me! Horrible!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On onsdag, aug 6, 2003, at 10:30 Europe/Stockholm, Aidan Williams wrote:
-2. Realize that if the issue at stake here has more to do with
getting addresses
than with their actual scope/range, something probably can be
done working
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am away on vacation and have missed all the fun...for what i matters,
I think A is the way to go. That sends a clear signal to network
managers, implementors etc. B and C will leave us in a vacuum.
- - kurtis -
On måndag, aug 4, 2003, at 20:06
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On tisdag, aug 5, 2003, at 00:14 Europe/Stockholm, Michel Py wrote:
If we were not
able to fix site-locals I wonder where the silver bullet to replace
them
is.
Solve the multi6 problem. Look at Geoffs presentations from the last
IEPG. There
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm expecting, by the way, that the deprecation will leave fec0::/10
to be treated as global-scope unicast addresses, rather than making
fec0::/10 addresses cease to function altogether.
That's an interesting expectation. As co-author of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On tisdag, aug 5, 2003, at 01:57 Europe/Stockholm, Jeroen Massar wrote:
Fortunatly there are clued ISP's who do filter accordingly to:
http://www.space.net/~gert/RIPE/ipv6-filters.html
I would advise and even try to pursuade people to run them in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If we had new routing technology that could handle globally routable
provider independent addresses, then it would have to be deployed in
most routers in the Internet before it would be useful. Probably all
routers from the site boundary to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The same is true if we create a swamp again and allow individual /48s
in
the global routing table. Then IPv6 will become IPv4 with more bits,
and
in the current economy the net result will be more NAT-aware apps. I'm
sorry to say it bluntly,
IPv6 IS IPv4 with more bits.
On the contrary it is much more if you go down behind the user and look
at the protocol and implementation. It depends on ones view. I am
debating this with Geoff now on his Myth article and there will another
article soon.
/jim
Actually, I believe we do not have a birthday paradox issue in this case.
The birthday paradox would exist only if ALL 1.2 million self-drawn prefixes would
see each other.
However, in our scenario, the merging of two enterprises, only the two local
prefixes may collide with each other.
]; [EMAIL PROTECTED]
Subject: Re: Moving forward on Site-Local and Local Addressing
Bob Hinden wrote:
[IPv6 working group chair hat on]
I think the working group has been making good progress on replacing
site-local addresses and wanted to get feed back from the working
group
Brian E Carpenter wrote:
3. I feel strongly that this absolutely needs to be a
one-time fee. The idea of constructing an artificial service
industry to maintain an annual registration system for random
numbers is plain wasteful.
Well a database with stale information is of no value either.
On Wednesday, August 6, 2003, at 01:30 AM, Aidan Williams wrote:
Alain Durand wrote:
IMHO, what need to happen is the following:
-1. Make an in-depth study of the consequences of introducing
addresses with different ranges.
How would this different from the material that has been
3. If we say that NAT is acceptable, half-acceptable, maybe OK in the
short term (or whatever) it WILL happen and there will be no way back.
4. If we say that individual /48s in the global routing table are
acceptable, half-acceptable, maybe OK in the short term (or whatever)
they WILL
Based on Ralph's analysis I vote A to support the WG's prevous decision.
That having been said, as I wrote in my previous email, I'd like to
proceed on multiple fronts to develop solutions to the underlying
problems that site-local attempted to address.
By the way, would others please state
Geoff Huston wrote:
At 06:30 PM 6/08/2003 +1000, Aidan Williams wrote:
I can't see significant differences in process between globally unique
local address allocation and a globally unique PI address allocation.
I'd offer the view that there's a lot of difference.
I can't believe I'm reading this.
Site locals were a design error. They have no redeeming qualities, and
they never did. They should never have been in the PS version of the
specification in the first place. It's taken us several years to
start to fix this tragic error, and now we're talking
I'll go for B, or perhaps A.9 (i.e. a version of B in which
we avoid recursive normative references between the two documents).
I don't think we help anyone by delaying the deprecation until a
new solution is in operational practice. Deprecation doesn't mean
switching off; it just means a strong
Patrik Fältström wrote:
From an Application (above TCP) perspective, A, definitely A. Itojun
summarizes well the issues. Mandating a host to know topology is just
a really bad thing. Really really bad.
paf
I am worried that continuing to beat the dead horse gets v6 nowhere. I
know of
To: Alain Durand
Cc: Bob Hinden; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Moving forward on Site-Local and Local Addressing
FWIW, I wasn't there but I agree with Alain. I've
never seen any compelling evidence that scope qua
scope is what people actually need. And scope
brings any
On Mon, Aug 04, 2003 at 11:06:55AM -0700, Bob Hinden wrote:
[IPv6 working group chair hat on]
Well on the assumption that the deprecation actually happens...
A) Deprecate Site-Local addresses independently from having an alternative
solution available. This would mean that the working group
At 06:07 PM 8/5/2003 +0200, Brian E Carpenter wrote:
That's an interesting expectation. As co-author of the planned
deprecation draft, I'd been assuming a more classical deprecation
action, in which we would simply state the previous semantics of
FEC0::/10, state that the prefix SHOULD NOT be
Geoff Huston wrote:
Brian Carptener writes:
http://www.apnic.net/meetings/16/programme/sigs/docs/policy/addpol-doc-huston-local-use-addrs.doc
attempts to to refine this draft into some considerations from a registry
perspective. (If there's interest
I'll put this out as an
Brian E Carpenter writes:
Zefram wrote:
...
I'm expecting, by the way, that the deprecation will leave fec0::/10
to be treated as global-scope unicast addresses, rather than making
fec0::/10 addresses cease to function altogether.
That's an interesting expectation. As co-author
Mika,
Mika Liljeberg wrote:
On Fri, 2003-08-08 at 14:52, Brian E Carpenter wrote:
If they do that, they will have ignored the health warnings
we will put on the RFC.
Seeing as a good many of those networks will be residential, some of
those network managers very probably will not know
Bob Hinden [EMAIL PROTECTED] writes:
I would like to hear from the working group on how we should proceed.
I think the choices are:
My choice is A. Please, just let SL die, as an application programmer, I
find SL to be a mistake as currently designed. Lets move forward.
Love
Alain Durand wrote:
IMHO, what need to happen is the following:
-1. Make an in-depth study of the consequences of introducing
addresses with different ranges.
That's definitely a good idea because that way we might be able to
replace all current local addresses with a single type of
Aidan Williams wrote
The current drafts look like progress to me and
remove the biggest wart of SL: ambiguity.
It's a distraction. The reason SLs are still ambiguous is because of the
deprecation process, not because ambiguity could not be removed. As a
matter of fact, this document is a
At 05:25 PM 8/5/2003 +0200, Brian E Carpenter wrote:
I'll go for B, or perhaps A.9 (i.e. a version of B in which
we avoid recursive normative references between the two documents).
If your version A.9 existed, I would have chosen it...
I don't much care for the idea of gratuitous normative
I would like to hear from the working group on how we should proceed. I
think the choices are:
A) Deprecate Site-Local addresses independently from having an alternative
solution available. This would mean that the working group should treat
the deprecation, and requirements and
C makes sense to me.
Hesham
- Original Message -
From: Bob Hinden [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, August 04, 2003 9:06 PM
Subject: Moving forward on Site-Local and Local Addressing
[IPv6 working group chair hat on]
I
Hello Bob,
I am one of the people Dave refers to:
Dave Thaler wrote:
I believe some people voted to deprecate with the
assumption that a replacement would be made (certainly this concern was
voiced at the mike by multiple people).
Furthermore, I almost abstained for the same
I vote for C, you can't ask people who are up and running with something
today to just stop with out a plan on replacing it. Otherwise FEC0:: will
stay a de facto private range as we will have implementations using it and
ones that are not.
- Original Message -
From: Bob Hinden [EMAIL
forward on Site-Local and Local Addressing
Jordi,
Jordi wrote:
I see your point, but my feeling is that we can only go to the last
step (of the IETF process) IF it make sense (running code,
and then it
means no-brainer), that means that B is fine, but for the
same reason,
I can
The probability of a collision using random choice is not a paradox. Its
a simple calculation, using the formula as given in the document.
Well, the birthday paradox isn't really a paradox either.
The observation is that even though the /8 space contains
1.1 trillion entries, there
If they do that, they will have ignored the health warnings
we will put on the RFC.
Brian
Mika Liljeberg wrote:
Hans,
The application is wireless connectivity to network XYZ, where the
network manager of network XYZ controls the choise of the address space
used. Multi-access basically
I would like to hear from the working group on how we should proceed. I
think the choices are:
A) Deprecate Site-Local addresses independently from having an alternative
solution available. This would mean that the working group should treat
the deprecation, and requirements and solution
From: Michael Thomas writes:
If you truly want to deprecate FECO::/10, I'd say
that it shouldn't be reserved to IANA, but given
to registries with explicit mandate to allocate
it immediately.
This could cause problems with hardware that already is installed, and is
configured to treat
Hans Kruse wrote:
There is real danger here; I have already started to see mailing list
discussion going something like:
Q. What address prefix do I use for this network before I get my
provider prefix?
A1. Use FECO (Site Local).
A2. No, No, FECO has been outlawed by the IETF, just invent a
My preference is A, then B, then C.
I also think we should keep the former site-local prefix IANA-reserved.
BTW Patrik - does this mean you're not a fan of the source/destination
address selection mechanism for IPv6?
Tim
On Tue, Aug 05, 2003 at 05:47:20AM +0200, Patrik Fältström wrote:
From
Margaret Wasserman writes:
At 05:25 PM 8/5/2003 +0200, Brian E Carpenter wrote:
I'll go for B, or perhaps A.9 (i.e. a version of B in which
we avoid recursive normative references between the two documents).
If your version A.9 existed, I would have chosen it...
I don't much
On Thu, 2003-08-07 at 08:52, Brian E Carpenter wrote:
What we're dealing with here is intrinsically a much simpler problem than
the RIRs had to solve for aggregatable address space when CIDR
arrived. There are very good reasons why routeable address space
allocation requires policies,
Jim,
At 07:18 AM 8/9/2003, Bound, Jim wrote:
We now have a combined local addressing requirements document
draft-hain-templin-ipv6-limitedrange-00.txt, a specific
alternative to
site-local addresses draft
draft-hinden-ipv6-global-local-addr-02.txt
(accepted as a working group item at the
Exactly. SLs are dead maybe the only alternative is A.
/jim
-Original Message-
From: Lars Erik Gullerud [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 06, 2003 9:03 AM
To: Bob Hinden
Cc: [EMAIL PROTECTED]
Subject: Re: Moving forward on Site-Local and Local Addressing
: Ralph Droms [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2003 2:54 PM
To: [EMAIL PROTECTED]
Subject: Re: Moving forward on Site-Local and Local Addressing
My understanding of the WG discussion is that deprecation of
site-local
addresses was discussed and consensus was reached
Hans,
The application is wireless connectivity to network XYZ, where the
network manager of network XYZ controls the choise of the address space
used. Multi-access basically stands for simultaneous access to multiple
different networks, possibly under different administration. I.e., the
terminal
, August 04, 2003 3:52 PM
To: [EMAIL PROTECTED]
Subject: Re: Moving forward on Site-Local and Local Addressing
|C) Deprecate Site-Local addresses after an alternative is defined,
|standardized, and in operational practice. This would mean
not advancing a
|deprecation document until
Yes I am. Middle name is risk. Sometimes folks don't want it sometimes
they do.
/jim
-Original Message-
From: Michel Py [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 10, 2003 3:30 PM
To: Bound, Jim
Cc: [EMAIL PROTECTED]
Subject: RE: Moving forward on Site-Local and Local
Alain Durand wrote:
IMHO, what need to happen is the following:
-1. Make an in-depth study of the consequences of introducing
addresses with different ranges.
How would this different from the material that has been presented
already in the SL debate? The whole anti-site-local argument
On torsdag, aug 7, 2003, at 12:03 Europe/Stockholm, Tim Chown wrote:
My preference is A, then B, then C.
I also think we should keep the former site-local prefix IANA-reserved.
BTW Patrik - does this mean you're not a fan of the source/destination
address selection mechanism for IPv6?
To be
Bob Hinden wrote:
I would like to hear from the working group on how we should proceed.
I
think the choices are:
I vote for B, but C would also be acceptable. My reasoning is that they
are deployed and will continue to be used until a replacement is
available. Choosing A means that might not
You are awfully cavalier with taking such risks with the
market. What if the market does not like the replacement? The
market will stay in limbo.
Yes I am. Middle name is risk. Sometimes folks don't want it sometimes
they do.
IPv6 offers no value if it does not do things differently
At Mon, 04 Aug 2003 11:06:55 -0700, Bob Hinden wrote:
Please respond to the list with your preference
Sigh. A.
[But where are the clowns? There ought to be clowns.
Well, maybe next year. -- Stephen Sondheim]
IETF IPng
Jim,
Jim Bound wrote:
But what we cannot do is discuss it for the
next year leaving the market in limbo?
The reason the market is in limbo in the first place is deprecation
without a replacement. If the market did not need SLs it would not have
gone in limbo over the issue.
Michel.
On Mon, 2003-08-11 at 16:05, Brian E Carpenter wrote:
Mika Liljeberg wrote:
On Sun, 2003-08-10 at 12:17, Brian E Carpenter wrote:
I would prefer it if the use of semi-unique local scope addresses were
restricted to non-connected networks. For any connected network you can
assume
On Sun, 2003-08-10 at 12:17, Brian E Carpenter wrote:
I would prefer it if the use of semi-unique local scope addresses were
restricted to non-connected networks. For any connected network you can
assume that the network manager is able go to some registry website and
grab a guaranteed
I've reviewed the minutes from the ipv6 WG meeting in SF and those minutes
reflect my memory that the question about deprecating site-local addresses
was put to the WG independent of any consideration of a replacement
mechanism. Clarifying e-mail to the ipng mailing list from Margaret
(3/28/2003)
At 10:30 AM 9/08/2003 -0400, Bound, Jim wrote:
I think we have this known.
1. Consensus is SLs are not going to achieve consensus.
2. hinden draft works IMO?
What don't you like about hinden draft idea?
Well - to answer this question of Jims, I'm not sure it (the Hinden/Haberman
draft) is
Thanks to everyone who has responded with a preference so far. Please keep
them coming.
To make it a little easier to keep track of the results, please only use
the above subject for direct responses. Move discussions to other Subjects.
Thanks,
Bob
On Tue, Aug 05, 2003 at 02:52:32PM -0400, Keith Moore wrote:
No. That would admit the possibility of reusing that prefix for some
other purpose. What we really need is for all hosts and routers to
filter FEC0://10 packets unless explicitly configured to do otherwise.
Actually while I agree
On Thu, 2003-08-07 at 15:52, Brian E Carpenter wrote:
The observation is that even though the /8 space contains
1.1 trillion entries, there is a greater than 0.5 probability that there will
be a clash after some 1.2 million draws. Normally this would not matter in the
slightest, BUT the
Citerat från Bob Hinden [EMAIL PROTECTED]:
A) Deprecate Site-Local addresses independently from having an
alternative
solution available.
A. Stabilize the patient, then worry about how to make arms and legs work again.
We now have a combined local addressing requirements document
draft-hain-templin-ipv6-limitedrange-00.txt, a specific
alternative to
site-local addresses draft
draft-hinden-ipv6-global-local-addr-02.txt
(accepted as a working group item at the Vienna IETF)
Why do we need both of these?
with new option. But they will use them. SLs
are not going to be used in any form.
/jim
-Original Message-
From: Michel Py [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2003 3:17 PM
To: Bob Hinden; [EMAIL PROTECTED]
Subject: RE: Moving forward on Site-Local and Local Addressing
B. Captures the declared consensus and agreed work items.
Short Reasoning
Politically A. will deprecate site locals and strand their replacement in
the WG forever -- the result will be prefix hijacking -- not good.
C. seems too ambitious given that a group of folks urgently feel that
Agreed. But we had a bug and a big one. I think we still have one with
link-locals too :--)
/jim
-Original Message-
From: Michel Py [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 09, 2003 3:54 PM
To: Bound, Jim
Cc: [EMAIL PROTECTED]
Subject: RE: Moving forward on Site-Local
Zefram wrote:
...
I'm expecting, by the way, that the deprecation will leave fec0::/10
to be treated as global-scope unicast addresses, rather than making
fec0::/10 addresses cease to function altogether.
That's an interesting expectation. As co-author of the planned
deprecation draft, I'd
| To: [EMAIL PROTECTED]
| Subject: Re: Moving forward on Site-Local and Local Addressing
|
|
| |C) Deprecate Site-Local addresses after an alternative is defined,
| |standardized, and in operational practice. This would mean
| not advancing a
| |deprecation document until there was operational evidence
Folks, this is not rocket science. IPv6 needs a known prefix that can
be distinguished from provider-based addressing, and a mechanism to
uniquely (or almost-uniquely) assign addresses out of this prefix.
No it does not. We must not repeat the mistake of RFC 1918.
On tisdag, aug 5, 2003, at 01:14 Europe/Stockholm, Tony Hain wrote:
Alain Durand wrote:
...
IMHO, what need to happen is the following:
-1. Make an in-depth study of the consequences of introducing
addresses with different ranges.
This is not an introduction, they happened long ago ...
My understanding is that the workgroup has voted to deprecate site-locals
unconditionally (having no dependency on the development and acceptance of
alternatives). Thus, I vote for A.
Apart from the above reason, I feel that deprecating site-locals ASAP will
lead to a rapid development of
Geoff Huston wrote:
At 06:30 PM 6/08/2003 +1000, Aidan Williams wrote:
I can't see significant differences in process between globally
unique local address allocation and a globally unique PI address
allocation.
I'd offer the view that there's a lot of difference.
OK, I can see how
Michael,
For a change I mostly agree (will detail below what I don't like) with
what you just posted, especially:
Michael Thomas wrote:
so even these small sensible steps that you propose
nonetheless seem grave in their global implications.
and
But I'm sorry, if NAT's become a de-facto
A) Deprecate Site-Local addresses independently from having
an alternative
solution available. This would mean that the working group
should treat
the deprecation, and requirements and solution documents
outlined above
independently from each other. If there was no consensus on
an
Bob Hinden wrote:
A) Deprecate Site-Local addresses independently from having an alternative
solution available.
A.
--
Dean C. Strik Eindhoven University of Technology
[EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ipnet6.org/
This isn't right. This isn't even wrong. --
I prefer option (B), but I would find option (A) acceptable.
Margaret
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive:
On Mon, 04 Aug 2003 11:06:55 -0700,
Bob Hinden [EMAIL PROTECTED] said:
I would like to hear from the working group on how we should proceed. I
think the choices are:
I prefer this one:
A) Deprecate Site-Local addresses independently from having an alternative
solution available.
I
B
A or C would be acceptable were they to happen but I think they will
not in a reasonable timescale (and as an engineer, I want something
that I can use:-)
In passing, I am one of the third, not the two thirds, and do accept
that we have rough consensus.
Tom Petch
-Original Message-
On Mon, 2003-08-04 at 20:06, Bob Hinden wrote:
I would like to hear from the working group on how we should proceed. I
think the choices are:
I'd like to see A happen. Going for B, and even worse C, will just
prolong the current state of uncertainty where a lot of people have
heard that
Hi Ralph,
At 11:01 PM 8/4/2003 -0400, Ralph Droms wrote:
Bob's e-mail to the ipng mailing list used to judge WG consensus on
deprecating site-local addresses asked:
The question is:
Should we deprecate IPv6 site-local unicast addressing?
Valid responses are:
YES -- Deprecate
Patrik Fältström wrote:
From an Application (above TCP) perspective, A, definitely A. Itojun
summarizes well the issues. Mandating a host to know topology is just
a really bad thing. Really really bad.
I concur with an added really tagged on.
That's an interesting expectation. As co-author of the planned
deprecation draft, I'd been assuming a more classical deprecation
action, in which we would simply state the previous semantics of
FEC0::/10, state that the prefix SHOULD NOT be used, but leave it
permanently assigned by IANA.
Bob Hinden wrote:
[no hats on]
Then, we have a 'requirement' document that pretend to explain why we
need
'local' addresses. If you read it carefully, and as acknowledged by
one of its main
author in Vienna, almost all of those requirements (if not all) would
be fulfilled
by provider
89 matches
Mail list logo
