On 2/11/12 04:52 , Ralph Droms wrote:
> But, what we've been told by operators in the discussion about this
> draft is that "very unlikely" is not "sufficiently unlikely", and
> that no /10 within the set of RFC 1918 addresses makes the
> probability of a collision sufficiently unlikely. You may
> From: Doug Barton
> We already have a way to make collisions "very unlikely," don't use
> either of 192.168.[01].
I gather that that's not desirable, because otherwise people wouldn't be
asking for another block. Of course it could probably be made to work
somehow - with enough th
> But, what we've been told by operators in the discussion about this
^ some
> draft is that "very unlikely" is not "sufficiently unlikely", and that
> no /10 within the set of RFC 1918 addresses makes the probability of a
> collision sufficiently unlikely. You may di
On 02/11/2012 04:52, Ralph Droms wrote:
>
> On Feb 11, 2012, at 12:27 AM 2/11/12, Doug Barton wrote:
>> Ok, let's go with that. We already have a way to make collisions
>> "very unlikely," don't use either of 192.168.[01]. Fortunately this
>> method doesn't require allocation of a new block.
>
>
Nilsson wrote:
For which there is better use than prolonging bad technical solutions.
A problem is that IPv6 is a bad technical solution.
For examples, its bloated address space is bad, ND with full
of bloated useless features is bad and multicast PMTUD only
to cause ICMP implosions is bad.
On Sat, Feb 11, 2012 at 08:34, John C Klensin wrote:
> So, Chris, if you expect this allocation will avoid the costs of
> signing everyone up for IPv6-capable CPE, what is your
> transition plan? Or are you advocating an IPv4-forever model?
> If the latter, can you explain succinctly to the rest
On Feb 11, 2012, at 12:27 AM 2/11/12, Doug Barton wrote:
> On 02/10/2012 20:44, Noel Chiappa wrote:
>>> From: Doug Barton
>>
>>> You snipped the bit of the my post that you're responding to where I
>>> specifically disallowed this as a reasonable argument.
>>
>> What an easy way to win a debat
> From: Nilsson
> Address translation has set the state of consumer computing back
> severely.
We basically all know that. I myself am not happy with NAT either - in
fact, back in 1992 (!!) I myself wrote what was perhaps the first
"problems with NAT document". So?
> Allocating
--On Saturday, February 11, 2012 11:00 -0200 Arturo Servin
wrote:
>
> On 10 Feb 2012, at 22:12, Chris Grundemann wrote:
>
>> Are you volunteering to buy everyone on earth a new CPE? If
>> not, who do you suggest will?
>
> I suggest the ISPs, they are charging for the service, right?
O
On Sat, Feb 11, 2012 at 12:31:22PM +0100, Roger Jørgensen wrote:
> On Sat, Feb 11, 2012 at 9:32 AM, Måns Nilsson
> wrote:
> > On Fri, Feb 10, 2012 at 11:44:42PM -0500, Noel Chiappa wrote:
> >
> >> This is only about allocating a chunk of address space.
> >
> > For which there is better use than p
On Sat, Feb 11, 2012 at 9:32 AM, Måns Nilsson wrote:
> On Fri, Feb 10, 2012 at 11:44:42PM -0500, Noel Chiappa wrote:
>
>> This is only about allocating a chunk of address space.
>
> For which there is better use than prolonging bad technical solutions.
>
> Address translation has set the state of
On Fri, Feb 10, 2012 at 11:44:42PM -0500, Noel Chiappa wrote:
> This is only about allocating a chunk of address space.
For which there is better use than prolonging bad technical solutions.
Address translation has set the state of consumer computing back severely.
It might be all nice and pro
On Fri, Feb 10, 2012 at 10:13:25PM -0500, Noel Chiappa wrote:
> > I still strongly oppose the publication of this draft. In any form
> > except a complete rewrite telling providers to use RFC1918 and be done
> > with it.
>
> If you have any good technical reasons for finding this a bad
13 matches
Mail list logo
