orgensen <[EMAIL PROTECTED]>
CC: IETF IPv6 Mailing List
Asunto: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA
draft
On 2007-06-12 22:19, Roger Jorgensen wrote:
On Tue, 12 Jun 2007, Manfredi, Albert E wrote:
Is this a little like the RH0 thread? When it was a choice of
> Para: <[EMAIL PROTECTED]>
> CC:
> Asunto: [***SPAM*** Score/Req: 10.4/4.5] Re: [***SPAM*** Score/Req: 10.4/4.5]
> Re: Revising Centrally Assigned ULA draft
>
> On 2007-06-14 11:30, JORDI PALET MARTINEZ wrote:
>> Operators have said that they will not be able to use ULA,
; CC: ARIN People Posting Mailing List <[EMAIL PROTECTED]>, ,
> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Asunto: Re: Revising Centrally Assigned ULA draft
>
> [cc'ing RIPE address policy + ARIN PPML where the discussion on this
> happened, I have not se
>-Original Message-
>From: james woodyatt [mailto:[EMAIL PROTECTED]
>Sent: Thursday, June 14, 2007 14:10
>To: IETF IPv6 Mailing List
>Subject: Re: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally
>Assigned ULA draft
>
>On Jun 14, 2007, at 02:56, JO
On 14-Jun-2007, at 14:09, james woodyatt wrote:
On Jun 14, 2007, at 02:56, JORDI PALET MARTINEZ wrote:
Just avoiding ANY collision risk. VERY VERY VERY LOW is not enough
for them.
My attitude is that IETF should tell them that's THEIR problem, not
OURS. Has the operator community expla
On Jun 14, 2007, at 02:56, JORDI PALET MARTINEZ wrote:
Just avoiding ANY collision risk. VERY VERY VERY LOW is not enough
for them.
My attitude is that IETF should tell them that's THEIR problem, not
OURS. Has the operator community explained why the odds of a
collision in a 2^40 addres
> -Original Message-
> From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
> The *only* possible argument for centrally allocated ULAs is for those
> who believe that the birthday paradox in a 2^40 address space causes
> a real danger of colliding with another business partner's ULA prefix.
TECTED]>
Fecha: Thu, 14 Jun 2007 11:42:20 +0200
Para: <[EMAIL PROTECTED]>
CC:
Asunto: Re: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned
ULA draft
On 2007-06-14 11:30, JORDI PALET MARTINEZ wrote:
Operators have said that they will not be able to use ULA, but they could
On Thu, 14 Jun 2007, Jeroen Massar wrote:
JORDI PALET MARTINEZ wrote:
Operators have said that they will not be able to use ULA, but they could
use ULA-C, for example for thinks like microallocations for internal
infrastructure's.
what operators? I cant remember to have seen one operator supp
[cc'ing RIPE address policy + ARIN PPML where the discussion on this
happened, I have not seen any 'operators' who have said the below, if
there are they are there and can thus raise their voices because they
will see this message; removed the silly spam scoring subject...]
JORDI PALET MARTINEZ wr
Re: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned
> ULA draft
>
> On 2007-06-14 11:30, JORDI PALET MARTINEZ wrote:
>> Operators have said that they will not be able to use ULA, but they could
>> use ULA-C, for example for thinks like microallocations
IETF IPv6 Mailing List
Asunto: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA
draft
On 2007-06-12 22:19, Roger Jorgensen wrote:
On Tue, 12 Jun 2007, Manfredi, Albert E wrote:
Is this a little like the RH0 thread? When it was a choice of disabling
by default or removing enti
D]>
> CC: IETF IPv6 Mailing List
> Asunto: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA
> draft
>
> On 2007-06-12 22:19, Roger Jorgensen wrote:
>> On Tue, 12 Jun 2007, Manfredi, Albert E wrote:
>>
>>>
>>> Is this a little l
On 2007-06-12 22:19, Roger Jorgensen wrote:
On Tue, 12 Jun 2007, Manfredi, Albert E wrote:
Is this a little like the RH0 thread? When it was a choice of disabling
by default or removing entirely? My vote is, don't forward ULA-Cs by
default, but let us use them as we used RFC 1918. It was also
> Someone pointed out that ([RFC4193], Section 4) provides
> operational guidelines, and I think the same guidelines
> would be true for ULA-Cs as they are for ULAs?
when there's a draft for ula-c, we'll know. it's been described here as
"ula but with working in-addr.arpa lookups", and as long as
gt; Subject: Re: Revising Centrally Assigned ULA draft
>
> "Templin, Fred L" <[EMAIL PROTECTED]> wrote:
>
> > > so my previous question stands. what's a "site"?
> >
> > Paraphrasing from the 'draft-templin-autoconf-dhcp' de
> A site (or site-of-sites to use the MANET terminology) is defined by the
> routability of a particular ULA prefix.
>
> - Bernie
from a process point of view that would be circular, since we're hoping
to use the meaning of "site" to help us define the proposed rules for ULA.
--
"Templin, Fred L" <[EMAIL PROTECTED]> wrote:
> > so my previous question stands. what's a "site"?
>
> Paraphrasing from the 'draft-templin-autoconf-dhcp' definition
> for "Mobile Ad-hoc Network (MANET)":
>
>site
> a connected network region that comprises routers that
> maintain
Couple more thoughts ...
>From: Paul Vixie [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, June 12, 2007 17:54
>To: 'IETF IPv6 Mailing List'
>Subject: Re: Revising Centrally Assigned ULA draft
>
>> ... It is meant to be a private address space, to be routed /
>&
Does anyone have an answer to this? Site local were deprecated because
the consensus was that there's no need for "private" addresses in
IPv6.
Are these ULA-Cs simply taking their place?
No, that's not correct. It had more do with their non-unique
properties and the notion of a unicast s
uesday, June 12, 2007 5:49 PM
To: Paul Vixie; IETF IPv6 Mailing List
Subject: RE: Revising Centrally Assigned ULA draft
> so my previous question stands. what's a "site"?
Paraphrasing from the 'draft-templin-autoconf-dhcp' definition
for "Mobile Ad-hoc Network (MA
On Tue, 12 Jun 2007 15:36:42 -0400
"Manfredi, Albert E" <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > From: Paul Vixie [mailto:[EMAIL PROTECTED]
>
> > site-local was deprecated because nobody could agree what a
> > "site" was, which
> > in other words means it's down under the s
> ... It is meant to be a private address space, to be routed / routable as
> private address space should be - specifically NOT on the public internet.
what we mean it to be routed to is less important than what people who use it
will actually route it to. let's focus for now on examples involv
> so my previous question stands. what's a "site"?
Paraphrasing from the 'draft-templin-autoconf-dhcp' definition
for "Mobile Ad-hoc Network (MANET)":
site
a connected network region that comprises routers that
maintain a routing structure among themselves. A site
may be as
On Tue, 12 Jun 2007 06:59:11 -0700
Bill Manning <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 12, 2007 at 10:11:19PM +0930, Mark Smith wrote:
> > On Tue, 12 Jun 2007 03:35:36 -0700
> > Bill Manning <[EMAIL PROTECTED]> wrote:
> >
> > > >
> > > > I think a better way of describing it is "administrative
...
>-Original Message-
>From: Manfredi, Albert E [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, June 12, 2007 16:29
>To: Roger Jorgensen
>Cc: IETF IPv6 Mailing List
>Subject: RE: Revising Centrally Assigned ULA draft
>
>> -Original Message-
>> Fro
... My $.02 or so, inline ...
>-Original Message-
>From: Manfredi, Albert E [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, June 12, 2007 14:58
>To: Paul Vixie; IETF IPv6 Mailing List
>Subject: RE: Revising Centrally Assigned ULA draft
>
>> -Original Message-
On Tue, 12 Jun 2007, Paul Vixie wrote:
I work on a quite similar network and we have the same issues. And I've
concluded that ULA-C would work great at our place, IF, please note that
BIG IF there, if we get reverse DNS. Without that, it is useless for us and
we might just aswell go with regular
> so is it the case that the long-dead proposal to add an icmp
> message type
> for "tell me your hostname" would be quite useful in this application?
RFC4620?
Fred
[EMAIL PROTECTED]
IETF IPv6 working group mailing list
ipv6@i
> I work on a quite similar network and we have the same issues. And I've
> concluded that ULA-C would work great at our place, IF, please note that
> BIG IF there, if we get reverse DNS. Without that, it is useless for us and
> we might just aswell go with regular "PA" address-space.
so is it the
On Tue, 12 Jun 2007, Manfredi, Albert E wrote:
-Original Message-
From: Roger Jorgensen [mailto:[EMAIL PROTECTED]
Why are we even talking about ULA-C now? What you want is
nicely covered
by ULA... not ULA-C but regular plain stright forward ULA.
Largely, but not completely. Think in
Paul,
> so far, there've been two answers, coincidentally both from
> boeing.com.
Please do not read too much into this. I respect the other
poster's opinions but, as for multiple posters from other
organizations, we are both bringing our own individual
opinions to this that do not necessarily
On Tue, 12 Jun 2007, Durand, Alain wrote:
My not-well-articulated point was: if everyone seems to have made RFC
1918 work quite well, why do we need to get overly precise in
this time around?
I happen to work for a network that has to deal on a very regular basis
with the nightmare of overlap
> -Original Message-
> From: Roger Jorgensen [mailto:[EMAIL PROTECTED]
> Why are we even talking about ULA-C now? What you want is
> nicely covered
> by ULA... not ULA-C but regular plain stright forward ULA.
Largely, but not completely. Think in terms of large platforms that have
sever
On Tue, 12 Jun 2007, Durand, Alain wrote:
Site local were deprecated because they were re-creating overlapping
address space a la RFC1918. This was considered a bad property
for multi-party applications that couldn't tell if they could
forward them as reference or not.
Some people believed that
On Tue, 12 Jun 2007, Manfredi, Albert E wrote:
Is this a little like the RH0 thread? When it was a choice of disabling
by default or removing entirely? My vote is, don't forward ULA-Cs by
default, but let us use them as we used RFC 1918. It was also my vote
when we were discussing site-local.
> -Original Message-
> From: Manfredi, Albert E [mailto:[EMAIL PROTECTED]
> My not-well-articulated point was: if everyone seems to have made RFC
> 1918 work quite well, why do we need to get overly precise in
> this time around?
I happen to work for a network that has to deal on a v
Manfredi, Albert E wrote:
[..]
> If we get more restrictive about ULA-Cs, my bet is that something else
> will morph to take their place (and the place of site-local addresses).
> I guess people just like to have this tool.
The "ULA-C tool" already exists: IPv6 PI space from the RIRs.
That satisf
> -Original Message-
> From: David Conrad [mailto:[EMAIL PROTECTED]
> I thought "Site Locals" were deprecated because people
> couldn't agree on what a "site" was.
>
> > Are these ULA-Cs simply taking their place?
>
> That's my impression, but then again, I haven't see the
> revised
> -Original Message-
> From: Paul Vixie [mailto:[EMAIL PROTECTED]
> site-local was deprecated because nobody could agree what a
> "site" was, which
> in other words means it's down under the same swamp we are
> now waist deep in.
Okay, I'll gladly agree on both points.
> so my previou
On Jun 12, 2007, at 11:57 AM, Manfredi, Albert E wrote:
if i seem anxious to cut to the chase it's because i've read
all this before when "site local" was first proposed and then
later, again,
when it was deprecated. so let's keep our feet on the ground and
define
our terms and make sure we
in response to this prompt:
Paul Vixie <[EMAIL PROTECTED]> wrote:
> > if we're going to expect routability to provide connectivity in some cases
> > but not all, which is what's implied by saying "never appear off-site",
> > then we need to know what cases and exactly what noncases. so what's a
>
> -Original Message-
> From: Paul Vixie [mailto:[EMAIL PROTECTED]
> if we're going to expect routability to provide connectivity
> in some cases
> but not all, which is what's implied by saying "never appear
> off-site", then
> we need to know what cases and exactly what noncases. so
s
into any other arbitrary site; there should be an explicit
peering arrangement first.
Fred
[EMAIL PROTECTED]
> -Original Message-
> From: Paul Vixie [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 12, 2007 9:44 AM
> To: IETF IPv6 Mailing List
> Subject: Re: Revising Cen
> I think a better way of describing it is "administrative domain". ...
in addition to bmanning's worthy comments, let me say that this redescription
entirely removes the point of my question. the assertion i first quoted was:
> > > Not that it really matters, since ULAs never appear off-site an
On Tue, Jun 12, 2007 at 10:11:19PM +0930, Mark Smith wrote:
> On Tue, 12 Jun 2007 03:35:36 -0700
> Bill Manning <[EMAIL PROTECTED]> wrote:
>
> > >
> > > I think a better way of describing it is "administrative domain". A
> > > home and the devices in it are an administrative domain - the person w
On Tue, 12 Jun 2007 03:35:36 -0700
Bill Manning <[EMAIL PROTECTED]> wrote:
> >
> > I think a better way of describing it is "administrative domain". A
> > home and the devices in it are an administrative domain - the person who
> > bought or looks after the devices has to administer, or at least
>
> I think a better way of describing it is "administrative domain". A
> home and the devices in it are an administrative domain - the person who
> bought or looks after the devices has to administer, or at least take
> ownership of the administration of those devices. That ownership could
> be a
On Tue, 12 Jun 2007 07:27:08 +
Paul Vixie <[EMAIL PROTECTED]> wrote:
> > Not that it really matters, since ULAs never appear off-site anyway.
>
> depending on what you mean by a site, both in relative and absolute terms
> of space and of time, there might be general agreement on this point, o
On Mon, 11 Jun 2007 17:28:07 +0200
Brian E Carpenter <[EMAIL PROTECTED]> wrote:
> It seems that what you describe is a prime candidate
> for metro addressing, not for ULAs of any kind. And a metro
> prefix is not really any different from a PA prefix, except
> that it's assigned to a municipality.
On 2007-06-12 09:27, Paul Vixie wrote:
Not that it really matters, since ULAs never appear off-site anyway.
depending on what you mean by a site, both in relative and absolute terms
of space and of time, there might be general agreement on this point, or not.
hopefully the regress isn't infini
the IPv6 routing capability)
Regards,
Mark.
> G/
>
> -Original Message-
> From: Mark Smith
> [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 10, 2007 1:45 AM
> To: Bernie Volz (volz)
> Cc: ipv6@ietf.org
> Subject: Re: Revising Centrally Assigned ULA draft
&
> Not that it really matters, since ULAs never appear off-site anyway.
depending on what you mean by a site, both in relative and absolute terms
of space and of time, there might be general agreement on this point, or not.
hopefully the regress isn't infinite. care to take it a step and see?
--
On 2007-06-11 19:45, james woodyatt wrote:
...
I don't see why residential users should even need ULA, much centrally
assigned ULA.
Assuming you mean "the vast majority of residential users" I agree. But there
will always be exceptions, and there will be a soft boundary between small
offices
On Jun 11, 2007, at 07:21, Paul Vixie wrote:
to your last question, i do think that residential users will have
small
routed networks in the future, rather than a flat neighborhood-wide
or even
city-wide L2, simply because the broadcast domain for things like
Bonjour
will be too large othe
It seems that what you describe is a prime candidate
for metro addressing, not for ULAs of any kind. And a metro
prefix is not really any different from a PA prefix, except
that it's assigned to a municipality.
ULAs should be kept in-house, literally.
Brian
On 2007-06-11 16:21, Paul Vixie w
>
> BTW do the ops lists where this is discussed have archives?
>
> Brian
>
for ARIN's ppml list: http://www.arin.net/mailing_lists/index.html
and follow the link for "archives"
--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't
On 2007-06-11 15:51, Paul Vixie wrote:
... I *would* recommend that the robot be hosted by a trusted
organization.
... most organizations are trusted by most people, but no organization is
trusted by everybody. what specific trust threshold are you aiming for in
the above stated requirement?
> I suppose most of these users will have big (actually a quite small) flat
> infrastructure to keep it simple? Hence what limits them to use just LL?
> Why ULA? What would be the residential users benefit? Do you think that
> residential users will have small routed networks in the future?
i th
> >> ... I *would* recommend that the robot be hosted by a trusted
> >> organization.
> > ... most organizations are trusted by most people, but no organization is
> > trusted by everybody. what specific trust threshold are you aiming for in
> > the above stated requirement?
>
> IANA, under the
Mark Smith wrote:
> Any residential user who needs to have non-globally accessible devices
> attached to their home network could use them.[..]
the "normal" ULA (RFC4193) provides this already. The "user interface"
is simply the box that auto generates it and then applies it. Presto.
This thus al
/
-Original Message-
From: Mark Smith
[mailto:[EMAIL PROTECTED]
Sent: Sunday, June 10, 2007 1:45 AM
To: Bernie Volz (volz)
Cc: ipv6@ietf.org
Subject: Re: Revising Centrally Assigned ULA draft
On Sat, 9 Jun 2007 10:06:16 -0400
"Bernie Volz \(volz\)" <[EMAIL PROTECTED]> wrote:
On 2007-06-09 17:41, Paul Vixie wrote:
... I *would* recommend that the robot be hosted by a trusted organization.
as ietf, itu, icann, ep.net, and isc have all proved, most organizations are
trusted by most people, but no organization is trusted by everybody. what
specific trust threshold ar
On Sat, 9 Jun 2007 10:06:16 -0400
"Bernie Volz \(volz\)" <[EMAIL PROTECTED]> wrote:
> IANA already manages things like enterprise-id numbers. And, then
> there's the existing IPv4 address space (how many assigned addresses are
> returned or reclaimed?).
>
> While ULA's could potentially be used b
> So, I think this "property rights" issue FUD.
please don't shoot the messenger. but in most of meatspace, if there's a
thing you pay (either one time or recurring) to get exclusive use of, and it's
of value (if you lost your use of it, it would financially injure you), then
it's property. the
> ... I *would* recommend that the robot be hosted by a trusted organization.
as ietf, itu, icann, ep.net, and isc have all proved, most organizations are
trusted by most people, but no organization is trusted by everybody. what
specific trust threshold are you aiming for in the above stated requ
er be a need for it.
- Bernie
-Original Message-
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 09, 2007 3:05 AM
To: Bill Manning
Cc: Brian Haberman; Ipv
Subject: Re: Revising Centrally Assigned ULA draft
On 2007-06-08 17:15, Bill Manning wrote:
> presuming this cours
On 2007-06-08 17:15, Bill Manning wrote:
presuming this course of action is taken, it raises a much larger
issue consisting of the IETF creating "property rights" in the
address space arena.
I decline to take the issue of property rights seriously in a
pseudo-random space of 2**40 natural nu
> CC:
> Conversación: Revising Centrally Assigned ULA draft
> Asunto: Re: Revising Centrally Assigned ULA draft
>
> I do not have an issue (yet?) with the draft. I have an issue with the process
> to create a draft about a very controversial issue in a wg that is not meeting
> f
, 2007 8:09 AM
> To: Durand, Alain
> Cc: Ipv
> Subject: Re: Revising Centrally Assigned ULA draft
>
> All,
>
> Durand, Alain wrote:
> >
> >
> >> -Original Message-
> >> From: Paul Vixie [mailto:[EMAIL PROTECTED]
> >> Sent: Thurs
Vixie <[EMAIL PROTECTED]>; Ipv
Sent: Fri Jun 08 11:08:51 2007
Subject: Re: Revising Centrally Assigned ULA draft
All,
Durand, Alain wrote:
>
>
>> -Original Message-
>> From: Paul Vixie [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, June 07, 2007 11:57 PM
&
> Rather than assume the contents of the draft and argue their merits,
> please wait for the posting of the new draft and then comment.
i understood alain to be asking that the ipv6 wg be de-mothballed in
order that the upcoming revised ULA I-D will be properly reviewed. i
hope that alain may eve
presuming this course of action is taken, it raises a much larger
issue consisting of the IETF creating "property rights" in the
address space arena. To date, (AFAIK) most legal arguments have
taken the line that IP addresses are NOT property, come from a
common resource that the RIR's administ
All,
Durand, Alain wrote:
>
>
>> -Original Message-
>> From: Paul Vixie [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, June 07, 2007 11:57 PM
>> To: 'Ipv'
>> Subject: Re: Revising Centrally Assigned ULA draft
>>>> I say wrap
> -Original Message-
> From: Paul Vixie [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 07, 2007 11:57 PM
> To: 'Ipv'
> Subject: Re: Revising Centrally Assigned ULA draft
>> > I say wrap it up and ship it.
>
> if that's what we're
I trust that the new version will include the proposal
for a fully robotic solution for creating and escrowing
guaranteed-unique ULAs. That's the only missing property in
existing ULAs, and we should certainly consider a purely
robotic solution with no need for registry action or registry
policy o
> ARIN & NANOG are nothing more than heat lately (all hot air?). As I
> suggested at NANOG this week, the right thing to do is for the WG to define
> the space, and turn it over to IANA to manage.
the internet's addressing system uses a combination of top-down architectural
guideance (from IAB and
ED]
> Sent: Thursday, June 07, 2007 1:17 PM
> To: Brian Haberman; Ipv
> Subject: RE: Revising Centrally Assigned ULA draft
>
> Brian,
>
> Give the heat this proposal is generating (at least in the ARIN region)
> it does not seem very constructive to tackle this issue
> in
Brian,
Give the heat this proposal is generating (at least in the ARIN region)
it does not seem very constructive to tackle this issue
in a sleeping working group that is not meeting face to face.
- Alain.
> -Original Message-
> From: Brian Haberman [mailto:[EMAIL PROTECTED]
> Sent:
79 matches
Mail list logo
