Question Re: best practices

[Ted Mittelstaedt]

That is a draft, not a real RFC.  The only reason it exists is that
the vendors who are pushing this continually re-file it every 6 months
when the draft expires.  It allows them to slap "RFC" on their marketing
slicks but because it's not a real standard, it's going to be as 
flexible as the wind, and any time one of the vendors decides to change
it they will put their changes in the next refiling.

What this boils down to is a contrived situation.  Nobody providing
server services to the Internet from a cloud is doing it with 
standardized equipment, they are all using black-boxes that either
do proxying or nat64.  So it is hogwash to try to select black-box
vendors on the basis of a supposed "standard" because such a standard
doesn't exist - calling a proposed draft standard a standard is a
bald faced lie.

Best practice is to issue your RFP to the major black box vendors
then bend over and grab your ankles to make it more comfortable for
them to extract huge amounts of money from you.  Because unless your
going to dual stack, that is all this boils down to, is who is going
to get to take the most money out of your wallet.

If your unwilling to dual stack then pick the black-box on the basis
of price and vendor relations and please quit trying to mislead the
general public with these ridiculous, perennial RFC drafts.

Ted

On 5/9/2011 9:45 AM, Cameron Byrne wrote:
> On Mon, May 9, 2011 at 9:38 AM, Austin Schutz<tex at off.org>  wrote:
>>
>> I'm curious about this having read a couple books about the IPv4 ->  IPv6
>> transition. I would like to know what the current best practice is.
>>
>> Given: A small set ipv6 only network running various protocols, call this
>> the "IPv6 only server network", and a large legacy client IPv4 network, call
>> this, say, "The Internet".
>>
>> In this scenario the operator of the ipv6 network may not have the luxury of
>> implementing dual stack on the legacy IPv4 network. Given that the
>> methodology of providing access to this network via NA(P)T-PT has been
>> obsoleted, what is the current best practice for solving this problem?
>>
>> I'm not really interested in a philosophical sort of "what I think should
>> happen" sort of debate, but rather a practical "this is what I have
>> implemented in my network" or "this is how I would solve this issue given
>> currently available equipment, software, and configurations techniques".
>>
>> Answers involving proposed but not implemented drafts are interesting but
>> not necessarily helpful.
>>
>>
>> Answers much appreciated.
>>
>
> http://tools.ietf.org/html/rfc6146
>
> Several major vendors are supporting this code today
>
> Cameron
> =================================
> T-Mobile USA IPv6 Beta http://bit.ly/9s0Ed3
> =================================
>
>>
>> Austin
>>