Alain Durand wrote:
>
> Zefram wrote:
>
> >Alain Durand wrote:
> >
> >
> >>If this is the case, what will we have gained from fec0::/48?
> >>
> >>
> >
> >The opportunity to avoid this numbering clash. Idiots who use fd00::/48
> >will clash with each other, but the rest of us avoid clashes with e
Zefram wrote:
Alain Durand wrote:
If this is the case, what will we have gained from fec0::/48?
The opportunity to avoid this numbering clash. Idiots who use fd00::/48
will clash with each other, but the rest of us avoid clashes with each
other and with the idiots.
If you look at RFC3513,
Alain Durand wrote:
>Tim Chown wrote:
>>I think we will see a lot of people using fd00::/48 or fd00::/64 for
>>their sites/links purely becuase it's less effort to type.
>>
>If this is the case, what will we have gained from fec0::/48?
The opportunity to avoid this numbering clash. Idiots who us
Alain Durand wrote:
Tim Chown wrote:
I think we will see a lot of people using fd00::/48 or fd00::/64 for
their sites/links purely becuase it's less effort to type.
If this is the case, what will we have gained from fec0::/48?
One year of extremely heated discussion, appeal, gazillions
of em
Tim Chown wrote:
I think we will see a lot of people using fd00::/48 or fd00::/64 for
their sites/links purely becuase it's less effort to type.
If this is the case, what will we have gained from fec0::/48?
One year of extremely heated discussion, appeal, gazillions
of email, just to replace
On Mon, Nov 10, 2003 at 09:36:29PM +1100, Geoff Huston wrote:
>
> After thinking about this and looking at the evident need to make some
> progress
> here I'd like to believe that this level of resolution of potential
> ambiguity
> is adequate, given that there is always the option to use a cent
> > "Private" implies security virtues that they don't have.
> > "Local" implies geographical limitations that they don't have.
> > "Site" ditto.
> > "Organizational" implies usage limitations that they don't have.
> > "Limited scope" upsets people because of the complexity of the scope
> debate.
On Tue, Nov 11, 2003 at 05:46:18PM +0100, Brian E Carpenter wrote:
> "Private" implies security virtues that they don't have.
> "Local" implies geographical limitations that they don't have.
> "Site" ditto.
> "Organizational" implies usage limitations that they don't have.
> "Limited scope" upsets
Brian E Carpenter wrote:
>Does anybody have a thesaurus handy?
"Non-global"?
-zefram
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--
"Private" implies security virtues that they don't have.
"Local" implies geographical limitations that they don't have.
"Site" ditto.
"Organizational" implies usage limitations that they don't have.
"Limited scope" upsets people because of the complexity of the scope debate.
"Entity" really isn't d
IMHO, "private" is appropriate. As noted in other emails, "organization"
is bit too specific. Plus, "Private (IPv4) addresses" is a well known
concept, and it would simpler for IPv4 network (home, organization, etc
networks) operators to extend the same understanding to IPv6.
CP
On Mon, 10 Nov
On Tue, 11 Nov 2003 02:29:55 -
[EMAIL PROTECTED] wrote:
> > How about simply calling whatever we end up with
> > "organizational addresses"?
> > I think that captures it much better than "local", "site
> > local", "private"
> > or whatever.
>
> as others have pointed out these addresses wil
> How about simply calling whatever we end up with
> "organizational addresses"?
> I think that captures it much better than "local", "site
> local", "private"
> or whatever.
as others have pointed out these addresses will be used in
non-'organisational' scenarios. therefore i prefer 'local' as
Only nit aside from a flavour of OSI is having to grep for "organi[sz]ational"
in drafts/RFCs.
Most use of "site local" may be in SOHO networks; not sure the word fits
well for home use, but if site local has stigma attached...
Tim
On Mon, Nov 10, 2003 at 07:54:05PM -0500, Hans Kruse wrote:
> T
Oops, sorry, just looked at the ID again, noticed that it states they are unique.
Along those lines "Unique Organizational IPv6 Unicast Addresses" would be an
acceptable title.
Hmm, at least for me, I would take the word "unique" to guarantee no duplication. With
local generation, this isn't a
On Mon, 10 Nov 2003 15:25:14 -0800
Bob Hinden <[EMAIL PROTECTED]> wrote:
I'd be inclined to go with this one, as it avoids implying a guarantee of uniqueness,
which would then imply they could be used as PI addresses from day one.
>Organizational IPv6 Unicast Addresses
Regards,
Mark.
That works for me...
--On Monday, November 10, 2003 21:52 +0100 Brian E Carpenter
<[EMAIL PROTECTED]> wrote:
How about simply calling whatever we end up with "organizational
addresses"? I think that captures it much better than "local", "site
local", "private" or whatever.
Brian
Hans Kruse,
At 02:55 PM 11/10/2003, Mark Smith wrote:
On Mon, 10 Nov 2003 21:52:46 +0100
Brian E Carpenter <[EMAIL PROTECTED]> wrote:
> How about simply calling whatever we end up with "organizational
addresses"?
> I think that captures it much better than "local", "site local", "private"
> or whatever.
>
I
On Mon, 10 Nov 2003 21:52:46 +0100
Brian E Carpenter <[EMAIL PROTECTED]> wrote:
> How about simply calling whatever we end up with "organizational addresses"?
> I think that captures it much better than "local", "site local", "private"
> or whatever.
>
I agree. I think it is a more descriptive n
Thus spake "Brian E Carpenter" <[EMAIL PROTECTED]>
> Stephen Sprunk wrote:
> > I also object to this part of the draft as well. IMHO, the registry
should
> > list who the registrant is for a particular prefix, but not allow
non-exact
> > searches.
>
> I think there are privacy and secrecy-by-hidin
Stephen Sprunk wrote:
>
> Thus spake "Alain Durand" <[EMAIL PROTECTED]>
> > Brian E Carpenter wrote:
> > >I meant PA because that is all that is in the implementors and
> > >registries' hands today. Actually any form of PI would do (they are
> > >all equally unrouteable today). I regard the Hinden
Thus spake "Alain Durand" <[EMAIL PROTECTED]>
> Brian E Carpenter wrote:
> >I meant PA because that is all that is in the implementors and
> >registries' hands today. Actually any form of PI would do (they are
> >all equally unrouteable today). I regard the Hinden/Haberman addresses
> >as an easy-t
I would oppose dropping the self-generated portion. I think we have been
pretty clear about the fact that anyone expecting to use locals for long
periods of time with some chance of merging later should get the registered
kind. There is real value in the self-generated version, and I simply
c
How about simply calling whatever we end up with "organizational addresses"?
I think that captures it much better than "local", "site local", "private"
or whatever.
Brian
Stephen Sprunk wrote:
>
> Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]>
> > 1. To number systems/interfaces that a
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]>
> > I don't see how this can be true in general.
> > Here is an example using referrals; the three nodes involved are A, B,
> > C. Node A and B are in the same site, have both local and global
> > addresses, and C is in a different site.
>
> > N
Fred and Alain,
I am simply not as scared of unregistered prefixes as Alain, because
I believe there will always be rogue prefixes. At least you can
tell these are rogues simply by looking at the prefix, unlike the case
of rogues that are stolen PA prefixes. So I don't accept the thesis
that they
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]>
> 1. To number systems/interfaces that are only accessible from withing
> the local network.
>...
> In the case of 1. the scope is site local, although the difinition of
> "site" may be subject to change.
Perhaps it'd clear things up if we chan
How about this - what if we let individual users randomly self
generate an address which they then take to the registration
authority. If no one else has previously registered the address,
the registration authority grants the assignment and records
it in the registration database. If the address w
I think that if you were to drop entirely the randomly self generated
addresses
and do not say anything about the fee scruture except it has to
be low cost, it would be a much more swallable pill.
- Alain.
Bob Hinden wrote:
Geoff,
After thinking about this and looking at the evident need to
Geoff,
After thinking about this and looking at the evident need to make some
progress
here I'd like to believe that this level of resolution of potential ambiguity
is adequate, given that there is always the option to use a central
registry draw to
obtain a global id that is assuredly unique.
At 12:51 PM 9/11/2003 +, Tim Chown wrote:
On Sun, Nov 09, 2003 at 08:49:40PM +0900, Jun-ichiro itojun Hagino wrote:
>
> - it is not expected to be routable, however, it will be treated
> as if it is a global address. therefore it is likely to be
leak out.
> 1.0 asserts t
Itojun,
i object to publish this document as a standard track document.
experimental would be more preferable.
I don't agree. I think this is appropriate for standards track.
unique local IPv6 unicast address avoids some problems of site-local,
but not all; there
]
> Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6
> Unicast Addresses"
>
>
> > > This is a IPv6 working group last call for comments on
> advancing the
> > > following document as an Proposed Standard:
> > >
> > > Title
itojun,
Tim has replied technically.
I would object to this being published as Experimental. That would be
the worst solution, since nobody would have any idea whether it was safe
to use it. I'd rather we simply started misusing PA or, indeed, 6to4
space to solve the operational problem. In fact
On Sun, Nov 09, 2003 at 08:49:40PM +0900, Jun-ichiro itojun Hagino wrote:
>
> - it is not expected to be routable, however, it will be treated
> as if it is a global address. therefore it is likely to be leak out.
> 1.0 asserts that "even if it leaks out there's no conflict"
> > This is a IPv6 working group last call for comments on advancing the
> > following document as an Proposed Standard:
> >
> > Title : Unique Local IPv6 Unicast Addresses
> > Author(s) : R. Hinden, B. Haberman
> > Filename: draft-ietf-ipv6-unique-local-01.txt
On Wed, 22 Oct 2003, Brian Haberman wrote:
> This is a IPv6 working group last call for comments on advancing the
> following document as an Proposed Standard:
>
> Title : Unique Local IPv6 Unicast Addresses
> Author(s) : R. Hinden, B. Haberman
> Filename:
At 08:10 22/10/2003, Brian Haberman wrote:
This is a IPv6 working group last call for comments on advancing the
following document as an Proposed Standard:
Title : Unique Local IPv6 Unicast Addresses
Author(s) : R. Hinden, B. Haberman
Filename: draft-
Brian E Carpenter wrote:
Alain Durand wrote:
Brian E Carpenter wrote:
Alain,
Do you think it is better to let the RIRs develop a policy for
allocating PA space for local use, i.e. create a swamp like IPv4?
PA... Do you PI for Provider Independant?
If it is the case, yes I think
Alain Durand wrote:
>
> Brian E Carpenter wrote:
>
> >Alain,
> >
> >Do you think it is better to let the RIRs develop a policy for
> >allocating PA space for local use, i.e. create a swamp like IPv4?
> >
> PA... Do you PI for Provider Independant?
> If it is the case, yes I think it would be less
Brian,
In your note to Alain you pose the question:
>Do you think it is better to let the RIRs develop a policy for
>allocating PA space for local use, i.e. create a swamp like IPv4?
It appears to me that you see this as being an either / or situation,
where we accept the document as is or we d
Brian E Carpenter wrote:
Alain,
Do you think it is better to let the RIRs develop a policy for
allocating PA space for local use, i.e. create a swamp like IPv4?
PA... Do you PI for Provider Independant?
If it is the case, yes I think it would be less damaging to do that.
See below.
In detail..
Alain,
Do you think it is better to let the RIRs develop a policy for
allocating PA space for local use, i.e. create a swamp like IPv4?
In detail...
Alain Durand wrote:
>
> I think that this effort is not ready for prime time.
>
> This document is creating a explosive cocktail made of:
>
>
I think that this effort is not ready for prime time.
This document is creating a explosive cocktail made of:
- policy: creation of a new authority to perform address assignment
outside of the regular channels
- economy: imposition of a fixed one time fee model, preventing
competition
> > The problem is that there are two types of uses for local
> > addresses:
> >
> > 1. To number systems/interfaces that are only accessible from withing
> > the local network.
> >
> > 2. To have stable addresses for systems/interfaces regardless of
> > intermittant external connectivity and re
Iljitsch van Beijnum wrote:
>
> On 24 okt 2003, at 18:14, Hans Kruse wrote:
>
> > 2. Several folks stumbled over the wording (in section 1.0) that
> > "applications may treat these address[sic] like global scoped
> > addresses". How about:
>
> > "Applications may treat these addresses like glob
Exactly. Either we put this solution on the standards track,
eliminating many of the problems of both RFC 1918 and FEC0::/10,
and meeting a range of needs, or we continue searching for
the perfect solution. If we take the latter approach, we will
surely see PA space used for these needs instead, o
On 24 okt 2003, at 18:14, Hans Kruse wrote:
2. Several folks stumbled over the wording (in section 1.0) that
"applications may treat these address[sic] like global scoped
addresses". How about:
"Applications may treat these addresses like global scoped addresses;
such applications will functi
Some notes on the draft as well as some of the comments on the list:
1. I think this draft is appropriately being prepared as Proposed
Standard. Trying to side-line local addressing to Experimental is not in
keeping with the declared consensus on work towards a "replacement for
site-locals" (
Please send substantive comments to the ipv6 mailing list, and minor
editorial comments to the authors. This last call period will end on 5
November 2003.
I do not believe that this document is ready for Proposed Standard.
My comments (both as suggested text corrections and as more
substantive c
Summary:
- I do not think it is appropriate to publish this document as Proposed
Standard at this time.
- I believe the structure of these addresses and means of assigning
prefixes are basically sound. However, I have several problems with
sections 7 on.
- I would support publication o
On 22 okt 2003, at 17:51, Erik Nordmark wrote:
- In practice, applications may treat these address like
global scoped addresses.
I don't see how this can be true in general.
Here is an example using referrals; the three nodes involved are A, B,
C. Node A and B are in the same site, hav
> This is a IPv6 working group last call for comments on advancing the
> following document as an Proposed Standard:
>
> Title : Unique Local IPv6 Unicast Addresses
> Author(s) : R. Hinden, B. Haberman
> Filename: draft-ietf-ipv6-unique-local-01.txt
I ass
Brian Haberman wrote:
> Filename: draft-ietf-ipv6-unique-local-01.txt
That should be draft-ietf-ipv6-unique-local-addr-01.txt.
Section 3.1 is still written from the point of view of having no
definitely determined format prefix, which is appropriate for discussion
but not in a Propo
54 matches
Mail list logo
