Subject:
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
From:
Keith Moore <mo...@network-heretics.com>
Date:
Sat, 2 Jul 2011 23:10:47 -0400
To:
Cameron Byrne <cb.li...@gmail.com>
CC:
"v6...@ietf.org" <v6...@ietf.org>, IETF Discussion <ietf@ietf.org>
Precedence:
list
MIME-Version:
1.0 (Apple Message framework v1084)
References:
<13205c286662de4387d9af3ac30ef456d3f3507...@embx01-wf.jnpr.net>
<CAKD1Yr2Smvm0RY5iV2y06wD=rrz-uw4vbaaairnoaksr7zl...@mail.gmail.com>
<banlktimprdnqkc1xtafskkoo5dcx3gc...@mail.gmail.com>
In-Reply-To:
<banlktimprdnqkc1xtafskkoo5dcx3gc...@mail.gmail.com>
Message-ID:
<e817a524-9db7-4553-a76f-25a9907e7...@network-heretics.com>
Content-Type:
multipart/alternative; boundary=Apple-Mail-111-642965515
Message:
2
I find myself wondering what you mean by REAL IPv6. For me, REAL IPv6
is code that uses the IPv6 programming model, 128 bit addresses,
end-to-end transparency, no NATs. 6to4 certainly qualifies.
Keith
Many people have many more requirements. For example, an SLA for
availability and latency, low support costs, firewall security, DSCP
quality of service, ability to log end point communications, intrusion
detection, WAN acceleration, a deployment model that does not rely on
allocating even more IPv4 addresses (that many don't have or won't have)
or the good nature of other providers to provide a working relay .......
6to4 fails to meet many of those requirements. Granted, it isn't the
only transition mechanism that fails to do so.
IMHO Right now, we need services with native IPv6 based interfaces, with
equivalent performance and equivalent features and equivalent price that
we have today with IPv4. Anything that detracts from the roll out of
native IPv6 based service interfaces at this time is a bad move IMVHO
and hastens the day that the Internet fragments into a bunch of CGN
zones, that is dominated by businesses that can afford to buy public
IPv4 addresses for their servers or services, or whose business model
relies on NAT traversal being difficult. I personally don't want that
sort of Internet.
Given that development and engineering support time is finite, I'd much
rather that 6to4 was declared historic so that developers and engineers
could spend more time on deployment of native IPv6 service interfaces.
Having said all that, 6to4 has also caused me issues with traffic
predictability, and cost significant engineering time. Turning 6to4 off
by default would not be the ideal solution in my view, but it should
address many if not all of my own particular issues. If that's all
that's on offer, I'll take it.
regards,
RayH
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
