This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[ipv6-wg] Follow up on RIPE67 IPv6 Only experiment
- Previous message (by thread): [ipv6-wg] Follow up on RIPE67 IPv6 Only experiment
- Next message (by thread): [ipv6-wg] New on RIPE Labs: How Many RIPE Atlas Probes Can Resolve IPv6-only Domain Names?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Benedikt Stockebrand
bs at stepladder-it.com
Fri Jan 10 12:13:00 CET 2014
Hi Dan and list, Dan Luedtke <maildanrl at gmail.com> writes: > On Mon, Dec 16, 2013 at 3:56 PM, Benedikt Stockebrand > <bs at stepladder-it.com> wrote: >> If I may offer one more suggestion, what about a "real" IPv6-only >> network without 464XLAT or anything, preferably as yet another SSID? I > NAT64/DNS64 works fine (until someone decides to validate DNS records) Now I assume that there may be some people who are willing to keep NAT64/DNS64 and/or 464XLAT and/or NAT-PT and/or TRT and/or SIIT and/or whatever else they've already set up alive and available all the time, but I know that there are people who intend to get rid of them---and IPv4 in general---and the additional workload they generate as soon as possible. The point of my suggestion is to see how dependent we still are on IPv4 and identify the things we still need to work on. As far as "works fine" is concerned: It adds work to the admins, depending on your enterprises's size it adds extra hardware, it makes troubleshooting more complex and as such it increases cost while lowering reliability/availability. >> This *will* break things, but that way we can see *what* breaks, so we >> can figure out what things need to be fixed. > From my experience with NAT64 you only break protocols that are > already fundamentally broken :) Nonsense. If you add ever more restrictions to what protocols are allowed to do and what not, then all you achieve is that coders will add more and more violations to your restrictions, either because they can't really keep track of your restrictions or because your restrictions break their perfectly valid application requirements. RFC 3439, section 2, has more on this in a general way. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.stepladder-it.com/
- Previous message (by thread): [ipv6-wg] Follow up on RIPE67 IPv6 Only experiment
- Next message (by thread): [ipv6-wg] New on RIPE Labs: How Many RIPE Atlas Probes Can Resolve IPv6-only Domain Names?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]