On Feb 10, 2012 4:25 PM, "Måns Nilsson" <mansaxel@xxxxxxxxxxxxxxxx> wrote:
>
> On Fri, Feb 10, 2012 at 05:12:31PM -0700, Chris Grundemann wrote:
> > On Fri, Feb 10, 2012 at 15:13, Doug Barton <dougb@xxxxxxxxxxxxx> wrote:
> > > On 02/10/2012 10:22, Chris Grundemann wrote:
> > >> This is not about IPv4 life-support.
> > >
> > > Seriously?
> >
> > Seriously.
> >
> > The birth of a shared CGN space in no significant way extends the life
> > of IPv4. It does provide the best possible solution to a necessary
> > evil (CGN inside addresses).
>
> We do not need another reason for people to delay v6 deployment. Just
> saying "this isn't about sticking your head in the sand" does not make
> it any more so. This _will_be_used_ as an excuse for not rolling out v6.
>
+1. This is all business. Companies have made their choices.
> > >> This is about providing the best answer to a difficult problem.
> > >
> > > The best answer is to make sure that CPEs that will be doing CGN can
> > > handle the same 1918 space inside the user network and at the CGN layer.
> >
> > Are you volunteering to buy everyone on earth a new CPE? If not, who
> > do you suggest will? My bet is that no one is willing to drop the
> > billions of dollars required - if they were, we could just sign
> > everyone up for IPv6 capable CPE and skip the whole debate... ;)
>
> There are more than 1 prefix in RFC1918. Tell the customers to use
> another one than the one you inflict on them as bad excuse for not
> doing v6 quick enough. That there will be increased support load on any
> provider not giving customers public space is a suitable punishment for
> above mentioned failure to deliver v6.
>
> 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.
>
This is the logical path for the cgn minded. They need to deal with the challenge of renumbering users.
I also oppose this draft.
Cb
> --
> Måns, sadly enough not surprised by the fact
> that this bad idea still isn't properly killed.
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf