Re: [v6ops] draft-ietf-v6ops-6to4-to-historic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Subject:
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
From:
Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>
Date:
Sat, 2 Jul 2011 23:10:47 -0400
To:
Cameron Byrne <cb.list6@xxxxxxxxx>
CC:
"v6ops@xxxxxxxx" <v6ops@xxxxxxxx>, IETF Discussion <ietf@xxxxxxxx>
Precedence:
list
MIME-Version:
1.0 (Apple Message framework v1084)
References:
<13205C286662DE4387D9AF3AC30EF456D3F3507EDA@xxxxxxxxxxxxxxxxxx> <CAKD1Yr2Smvm0RY5iV2y06wD=RRz-uW4VbaaairnoAkSR7zLdtg@xxxxxxxxxxxxxx> <BANLkTimpRDNQKc1XTafSkKOo5dCX3Gc8Yw@xxxxxxxxxxxxxx>
In-Reply-To:
<BANLkTimpRDNQKc1XTafSkKOo5dCX3Gc8Yw@xxxxxxxxxxxxxx>
Message-ID:
<E817A524-9DB7-4553-A76F-25A9907E7C2D@xxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]