1 |
On 03/11/2013 06:34 PM, Kevin Chadwick wrote: |
2 |
>> On 03/09/2013 07:53 AM, Kevin Chadwick wrote: |
3 |
>>>> "There is no reason to believe that IPv6 will result in an |
4 |
>>>> increased use of IPsec." |
5 |
>>>> |
6 |
>>>> Bull. The biggest barrier to IPsec use has been NAT! If an |
7 |
>>>> intermediate router has to rewrite the packet to change the |
8 |
>>>> apparent source and/or destination addresses, then the |
9 |
>>>> cryptographic signature will show it, and the packet will be |
10 |
>>>> correctly identified as having been tampered with! |
11 |
>>>> |
12 |
> |
13 |
> http://marc.info/?l=openbsd-misc&m=135325641430178&w=2 |
14 |
|
15 |
I believe you've misunderstood what Brauer is saying there. |
16 |
|
17 |
"" NAT needs to process every packets |
18 |
" |
19 |
" opposed to the !NAT case, where a router doesn't have to "process" |
20 |
" every packet. rrright. |
21 |
" |
22 |
|
23 |
Here, when Brauer is talking about processing, he's not talking about |
24 |
tampering with (modifying) packets, he's talking about inspecting them |
25 |
as part of connection state and for other things. |
26 |
|
27 |
This is absolutely distinct from *modifying* the packet, which is what |
28 |
IPsec is intended to detect. I also wouldn't count 'dropping' packets as |
29 |
modification, as: |
30 |
|
31 |
A) an intermediate firewall isn't likely to allow any packet of a stream |
32 |
through to begin with if it's going to block any packet in the stream at |
33 |
all. |
34 |
B) Handling of dropped packets is the responsibility of the transport |
35 |
layer. UDP is supposed to handle it in stride. TCP is supposed to notice |
36 |
and retry. |
37 |
|
38 |
> |
39 |
>>> |
40 |
>>> It's hardly difficult to get around that now is it. |
41 |
>> |
42 |
>> Sure, you can use an IP-in-IP tunnel...but that's retarded. IPSec |
43 |
>> was designed from the beginning to allow you to do things like sign |
44 |
>> your IP header and encrypt everything else (meaning your UDP, TCP, |
45 |
>> SCTP or what have you). |
46 |
>> |
47 |
>> Setting up a tunnel just so your IP header can be signed wastes |
48 |
>> another 40 bytes for every non-fragmented packet. Ask someone |
49 |
>> trying to use data in a cellular context how valuable that 40 bytes |
50 |
>> can be. |
51 |
>> |
52 |
>>> You are wrong the biggest barrier is that it is not desirable to |
53 |
>>> do this as there are many reasons for firewalls to inspect |
54 |
>>> incoming packets. I don't agree with things like central virus |
55 |
>>> scanning especially by damn ISPs using crappy Huawei hardware, |
56 |
>>> deep inspection traffic shaping rather than pure bandwidth usage |
57 |
>>> tracking or active IDS myself but I do agree with scrubbing |
58 |
>>> packets. |
59 |
>> |
60 |
>> It's not the transit network's job to scrub packets. Do your |
61 |
>> scrubbing at the VPN endpoint, where the IPSec packets are |
62 |
>> unwrapped. |
63 |
>> |
64 |
>> Trusting the transit network to scrub packets is antithetical to |
65 |
>> the idea of using security measures to avoid MITM and traffic |
66 |
>> sniffing attacks in the first place! |
67 |
>> |
68 |
> |
69 |
> I never said it was. I was more thinking of IPSEC relaying which |
70 |
> would be analogous to a VPN end point but without losing the end-end, |
71 |
> neither are desirable, |
72 |
|
73 |
Please, explain to me what the heck you mean, then? When you say |
74 |
|
75 |
>>> You are wrong the biggest barrier is that it is not desirable to |
76 |
>>> do this as there are many reasons for firewalls to inspect |
77 |
>>> incoming packets. |
78 |
|
79 |
I can't possibly understand what you're talking about except with the |
80 |
context you've given me. |
81 |
|
82 |
The only other thing I can take from what you're saying up to this point |
83 |
is that you believe VPNs are bad, which I find, well, laughable. |
84 |
|
85 |
> NAT has little to do with the lack of IPSEC deployment. |
86 |
|
87 |
You keep saying this, but saying a thing doesn't make it understood; you |
88 |
have to explain why. |
89 |
|
90 |
> |
91 |
> What do you gain considering the increased resources, |
92 |
|
93 |
You mean the bandwidth overhead of the ESP and/or AH headers? As opposed |
94 |
to, what, TLS? GRE? IP-in-TLS-in-IP? |
95 |
|
96 |
Let me have a clean, cheap TCP-on-ESP-on-IP stack for my |
97 |
campus-to-campus connections! |
98 |
|
99 |
> pointlessly increasing chances of cryptanalysis and pointlessly |
100 |
> increasing the chances of exploitation due to the fact that the more |
101 |
> complex IPSEC itself can have bugs like Openssl does, |
102 |
|
103 |
If I read your argument correctly, you would view encryption in general |
104 |
as harmful? |
105 |
|
106 |
> not to mention amplifying DDOS without the attacker doing anything, |
107 |
> which is the biggest and more of a threat than ever, |
108 |
|
109 |
One of my servers is currently undergoing a SYN flood. I'm well aware |
110 |
that the Internet is a dangerous place. |
111 |
|
112 |
Honestly, if someone wants to DDOS you, the increased amplification |
113 |
factor of DNSSEC isn't going to be the deciding factor of whether your |
114 |
server stays up or goes down. |
115 |
|
116 |
> or are you going to stop using the internet. |
117 |
|
118 |
Use hyperbole much? |
119 |
|
120 |
> When ipv4 can utilise encryption without limitations including IPSEC |
121 |
> but more appropriately like ssh just fine when needed you see it is |
122 |
> simply not desirable and a panacea that will not happen. You are |
123 |
> simply in a bubble as the IETF were. |
124 |
|
125 |
For the purposes of tunnels, I've used IPsec on IPv4, SSH and TLS. |
126 |
|
127 |
Quite frankly? IPsec on IPv6 is the least painful option of all of these. |
128 |
|
129 |
IPsec on IPv4 is frustrating because the VPN clients are poorly |
130 |
implemented, and you *must* use TCP/UDP-in-ESP/AH-in-(optional TCP or |
131 |
UDP in)-IP, or you're not going to get through NAT without getting the |
132 |
network administrator to explicitly set up a forward for you. |
133 |
|
134 |
TLS works (and is very common for tunneling), but you're again stuck |
135 |
with whatever-in-IP-in-TLS-in-TCP/UDP-in-IP. Or, more commonly, |
136 |
whatever-in-IP-in-Ethernet-in-TLS-in-TCP/UDP-in-IP. I'd be amazed if you |
137 |
didn't think that was a royal mess. |
138 |
|
139 |
SSH for tunneling? *Royal* PITA, especially when you have to connect to |
140 |
multiple places at once. If all you have is one endpoint you have to |
141 |
connect to to get where you're going, you can use SOCKS. Otherwise, |
142 |
you're forwarding ports. If you're forwarding ports, you're OK, so long |
143 |
as you don't have to use the same local port for two different purposes. |
144 |
And, yes, I've *seen* setups so convoluted that there were explicit |
145 |
instructions stating which local port would have to be used for each |
146 |
remote service, with server-side accommodations to suit, simply so that |
147 |
those local ports wouldn't conflict. |
148 |
|
149 |
With IPsec on IPv6, in *all* of the circumstances where I've required a |
150 |
VPN, the setup would have been a clean (whatever)-in-ESP/AH-in-IP. That |
151 |
would be *much* cleaner, and *much* more efficient at all levels of the |
152 |
network. |
153 |
|
154 |
> |
155 |
>>> |
156 |
>>>> With IPsec, NAT is unnecessary. (You can still use it if you |
157 |
>>>> need it...but please try to avoid it!) |
158 |
>>>> |
159 |
>>> |
160 |
>>> Actually it is no problem at all and is far better than some of |
161 |
>>> the rubbish ipv6 encourages client apps to do. (See the links I |
162 |
>>> sent in the other mail) |
163 |
>> |
164 |
>> Please read the links before you send them, and make specific |
165 |
>> references to the content you want people to look at. I've read and |
166 |
>> responded to the links you've offered (which were links to archived |
167 |
>> messages on mailing lists, and the messages were opinion pieces |
168 |
>> with little (if any) technical material.) |
169 |
>> |
170 |
> |
171 |
> |
172 |
>>> |
173 |
>>>> Re "DNS support for IPv6" |
174 |
>>>> |
175 |
>>>> "Increased size of DNS responses due to larger addresses might |
176 |
>>>> be exploited for DDos attacks" |
177 |
>>>> |
178 |
>>>> That's not even significant. Have you looked at the size of DNS |
179 |
>>>> responses? The increased size of the address pales in |
180 |
>>>> comparison to the amount of other data already stuffed into the |
181 |
>>>> packet. |
182 |
>>> |
183 |
>>> It's been ages since I looked at that link and longer addresses |
184 |
>>> would certainly be needed anyway but certainly with DNSSEC again |
185 |
>>> concocted by costly unthoughtful and unengaging groups who chose |
186 |
>>> to ignore DJB and enable amplification attacks. |
187 |
>> |
188 |
>> What from DJB did they ignore? I honestly don't know what you're |
189 |
>> talking about. |
190 |
>> |
191 |
> |
192 |
> They completely ignored dnscurve.org |
193 |
|
194 |
You know, I managed to read up on DNSCurve thanks to the link Michael |
195 |
Orlitzky provided, and you know what I think of it? |
196 |
|
197 |
I think it would do more harm to the DNS infrastructure than good. The |
198 |
implementation advocated would disallow intermediary DNS servers, and |
199 |
that is a *very bad thing*, because it disallows caching. |
200 |
|
201 |
Caching isn't just about being able to get a response to the client |
202 |
quickly. It's also about being able to get a response to the client *at |
203 |
all*. |
204 |
|
205 |
By default, a DNS resolver will make a query, wait 30s for a timeout, |
206 |
retry their query, wait significantly longer for a timeout, and then try |
207 |
a third time while waiting significantly longer. |
208 |
|
209 |
If the resolver's query reaches the DNS server fine, and the DNS |
210 |
server's response reaches the resolver fine, all is well. If the query |
211 |
or response packets get lost along the way, then the resolver (which is |
212 |
probably someone's web browser) waits 30s before it tries again. 30s is |
213 |
a *long* time. Your average user will only wait 10s before hitting F5 or |
214 |
moving along. |
215 |
|
216 |
Now, consider a typical modern residential network: |
217 |
|
218 |
{( internet )} -> ISP -> ADSL -> home router -> end user. |
219 |
|
220 |
That ADSL link is an absolutely treacherous beast. It drops packets |
221 |
without mercy, and the more you can accomplish without having to send |
222 |
packets across it, the better. Unfortunately, your average modern |
223 |
website includes files from up to a dozen different domains, with a few |
224 |
redirections involved for most of them. |
225 |
|
226 |
The typical modern home router has a caching DNS server built-in because |
227 |
DNS commonly operates over UDP, and UDP does not provide delivery |
228 |
guarantee. The end user's resolver (which is in their web browser) |
229 |
queries the home router, which then recurses and makes the query of the |
230 |
upstream servers on the end-user's behalf. Once the recursive resolver |
231 |
gets a response, it caches that response. |
232 |
|
233 |
I use a Debian PC as my home router. When I was on DSL, I initially |
234 |
didn't set up a caching recursive resolver. (I also didn't have caching |
235 |
recursive resolvers installed locally on my machines.) The Internet felt |
236 |
terrible. Half the resources on any given social media site or complex |
237 |
web page didn't load until the second or third refresh, simply because |
238 |
the DNS requests to find the relevant servers got lost along the way. |
239 |
|
240 |
Once I set up a caching recursive resolver on my router, my Internet |
241 |
experience improved dramatically. |
242 |
|
243 |
Now consider a more painful (yet still typical) network: |
244 |
|
245 |
{( internet )} -> ISP -> ADSL -> wifi hot spot -> end user |
246 |
|
247 |
That wifi hot spot hammers packets harder than the ADSL link that's also |
248 |
taking its due. Between having too many APs in a given area, too many |
249 |
clients on a public network and too much ambient noise in the 2.4GHz ISM |
250 |
band, getting a packet through that network is like playing frogger |
251 |
blind; you only accomplish it because your computer plays the game with |
252 |
infinite lives and doesn't let you see all the times the frog got squished. |
253 |
|
254 |
This is why all Windows systems have had caching recursive resolvers |
255 |
built-in for years, and why NetworkManager likes to use dnsmasq; you've |
256 |
added caching to local systems to work around terrible local physical |
257 |
layers. |
258 |
|
259 |
Do we need to get into using cellular connections and tethering in |
260 |
non-urban areas? I could tell you about a six-mile stretch on my wife's |
261 |
daily commute that the phone claims to have data service in, but can't |
262 |
get a packet through to save its battery. |
263 |
|
264 |
> or that RSA768 was not strong enough to be a good choice |
265 |
|
266 |
I don't think many people seriously anticipated how rapidly Moore's law |
267 |
would catch up with public-key cryptography. I'm not sure *anybody* |
268 |
without security clearance or heavy NDAs could have anticipated it using |
269 |
any sane series of logic. |
270 |
|
271 |
> and ECDSA should be looked at and most importantly the DOS |
272 |
> amplification (we are talking years ago). |
273 |
|
274 |
I understand that this is a key issue for you. I can't comprehend why, |
275 |
as I can't see why it's as significant an issue as you seem to believe |
276 |
it to be. |
277 |
|
278 |
> I even had a discussion with a dns caching tools (that I do like a |
279 |
> lot) author who completely dismissed the potential of RSA being |
280 |
> broken for years and years. Guess what's come to light since. |
281 |
|
282 |
As I said, Moore's law managed to surprise a great number of very |
283 |
reasonable people. There's *no* way that anyone in 1995 could have |
284 |
reasonably anticipated the rise of fully-programmable |
285 |
mass-parallel-calculation engines whose development was driven and made |
286 |
cheap (and thus highly, highly scaleable) by *video games*. |
287 |
|
288 |
> |
289 |
>>> |
290 |
>>> His latest on the "DNS security mess" |
291 |
>>> |
292 |
>>> http://cr.yp.to/talks/2013.02.07/slides.pdf |
293 |
>> |
294 |
>> I've never before in my life seen someone animate slideshow |
295 |
>> transitions and save off intermediate frames as individual PDF |
296 |
>> pages. That was painful. |
297 |
>> |
298 |
> |
299 |
> Yeah, xpdf worked well though. I actually couldn't find the link and |
300 |
> looked it up and thought it was just an update of 2012 as it had the |
301 |
> same title and only got around to reading it about an hour later. |
302 |
> |
303 |
>> So, I read what was discussed there. First, he describes failings |
304 |
>> of HTTPSEC. I don't have any problem with what he's talking about |
305 |
>> there, honestly; it makes a reasonable amount of sense, |
306 |
>> considering intermediate caching servers aren't very common for |
307 |
>> HTTP traffic, and HTTPS traffic makes intermediate caching |
308 |
>> impossible. (unless you've already got serious security problems by |
309 |
>> way of a MITM opening.) |
310 |
>> |
311 |
>> Then he turns around and dedicates two slides showing a DNS |
312 |
>> delegation sequence...and then states in a single slide that DNSSEC |
313 |
>> has all the same problems as HTTPSEC. |
314 |
>> |
315 |
>> DNSSEC doesn't have the same problems as HTTPSEC, because almost |
316 |
>> *every* recursive resolving DNS server (which is most of the DNS |
317 |
>> servers on the Internet) employs caching. |
318 |
>> |
319 |
> |
320 |
> I suggest you read the 2012 slides. |
321 |
|
322 |
Provide me with a link, and I will. I'm not going to go digging without |
323 |
a strong idea of what I'm looking for, and where to find it. |
324 |
|
325 |
> |
326 |
>>> |
327 |
>>>> "An attacker can connect to an IPv4-only network, and forge |
328 |
>>>> IPv6 Router Advertisement messages. (*)" |
329 |
>>> |
330 |
>>>> Again, this depends on them being on the same layer 2 network |
331 |
>>>> segment. |
332 |
>>> |
333 |
>>>> The same class of attacks would be possible for any IPv4 |
334 |
>>>> successor that implemented either RAs or DHCP. |
335 |
>>> |
336 |
>>> Neither of which I use. |
337 |
>> |
338 |
>> You're telling me you don't use DHCP? Seriously, that you |
339 |
>> statically configure the IPv4 addresses of all the hosts on your |
340 |
>> network? |
341 |
>> |
342 |
>> With one exception, I haven't personally seen a network configured |
343 |
>> in that way since 1998! Certainly, every network has some hosts |
344 |
>> configured statically, but virtually no network I've observed (and |
345 |
>> I've seen private networks between 2 and 50 hosts, and commercial |
346 |
>> networks between 5 and 30k hosts) managed completely statically. |
347 |
>> |
348 |
> |
349 |
> None of my networks for way over a decade have ever employed DHCP |
350 |
> and boy am I glad in avoiding many security issues. That was one of |
351 |
> the first decisions in network design I made as a teenager. |
352 |
> |
353 |
> In fact the only networks that do use DHCP by definition are not |
354 |
> well cared for such as roaming or tethering a laptop I trust little |
355 |
> to my phone which I also trust little and for many good, sorry very |
356 |
> bad mobile network reasons. |
357 |
|
358 |
You're pretty much in a class of your own, there. I'm sorry to say I |
359 |
can't empathize or agree in the slightest... |
360 |
|
361 |
> |
362 |
>>> |
363 |
>>> As I said we would be here all day and that link wasn't as good |
364 |
>>> as the one I was actually looking for. |
365 |
>>> |
366 |
>>> local NAT done right is no problem and actually a good thing and |
367 |
>>> I have no issues playing games, running servers or anything else |
368 |
>>> behind NAT. |
369 |
>> |
370 |
>> See others' responses about port standardization, and about how it |
371 |
>> enforces a distinction between 'clients' and 'servers' that's |
372 |
>> unnecessary (and even harmful) for a variety of applications. |
373 |
>> |
374 |
> |
375 |
> Boy should there be a distinction between clients and servers, |
376 |
> without it we would be in a world of pain. |
377 |
|
378 |
Why? You keep making statements without giving reasons for them. |
379 |
|
380 |
> However I still atest that there is no problem and far less than |
381 |
> what ipv6 advocates. |
382 |
|
383 |
Are you referring to the problems identified by the slides you've |
384 |
referenced so far? And that I've largely addressed, debunked or pointed |
385 |
out are no worse than IPv4? You never gave me a point-by-point |
386 |
response...instead you indicated the slide deck wasn't as good as the |
387 |
one you were looking for. Apart from your finding any dynamic network |
388 |
configuration appalling, I don't know what you're talking about. |
389 |
|
390 |
> |
391 |
>>> Global NAT works well enough |
392 |
>> |
393 |
>> With global NAT, anything you do that depends on port forwarding is |
394 |
>> broken. |
395 |
>> |
396 |
>>> but isn't a good thing and wouldn't exist if they had simply |
397 |
>>> added more addresses quickly. The hardware uptake would have been |
398 |
>>> no issue rather than a decade of pleads. |
399 |
>> |
400 |
>> There's almost nothing you've pointed at so far that would have |
401 |
>> prevented backbones from IPv6 uptake...and the backbones dragged |
402 |
>> their heels long enough. IPv4 with expanded address bits would have |
403 |
>> been worse; IPv6 explicitly includes features intended to ease the |
404 |
>> strain on the size of a global routing view! |
405 |
>> |
406 |
> |
407 |
> And much more which is the problem |
408 |
|
409 |
Wait, what? No! |
410 |
|
411 |
I'm talking about route aggregation, which comes in part from the use of |
412 |
CIDR notation. Through route aggregation, you reduce the number of |
413 |
entries in the routing table. Yes, the byte size of the global routing |
414 |
view will grow with IPv6. IPv4 with 128 address bits would have been far |
415 |
worse, unless route aggregation was made part of its design (as was done |
416 |
with IPv6). |
417 |
|
418 |
> and yet still including the bad parts of ipv4 apparently. |
419 |
|
420 |
Are there any parts of IPv4 that IPv6 carries that you consider bad |
421 |
parts, or are we just talking about DHCP again? |
422 |
|
423 |
> |
424 |
>>> |
425 |
>>> We haven't even touched on the code yet and so all the vulnerable |
426 |
>>> especially home hardware which yes often has vulnerable sps |
427 |
>>> anyway but by no way just home hardware. |
428 |
>>> |
429 |
>>> The ipvshit links give an insight into the code complexity. |
430 |
>> |
431 |
>> You call that code complex? (and I still don't know what 'ipvshit' |
432 |
>> is, except possibly one guy's pejorative description of IPv6) |
433 |
> |
434 |
> Think about what it is doing from the comment not the actual code. |
435 |
|
436 |
You mean this seemingly harmless comment? |
437 |
|
438 |
/* |
439 |
* sin6_len is the size of the sockaddr so substract the offset of |
440 |
* the possibly truncated sin6_addr struct. |
441 |
*/ |
442 |
|
443 |
Or do you mean this advocacy of NAT444 |
444 |
|
445 |
" who sez that your made up isp has to hand out network-wide unique IPs |
446 |
" to his customers? |
447 |
|
448 |
This attack on the person he's replying to: |
449 |
|
450 |
" why do i even waste time on some ipvshit advocate that acts like a |
451 |
" politician claiming we have to eat shit because there wouldn't be an |
452 |
" alternative, making up a case out of nothing to "prove" his case? |
453 |
|
454 |
Or his diatribe about IPv6? |
455 |
|
456 |
" look at the oh so bright future yourself, look at the code required to |
457 |
" deal with that misdesigned piece of shit. |
458 |
" did i just say "designed"? sorry. it's obvious that nothing remotely |
459 |
" related to design was involved. |
460 |
|
461 |
I'm not seeing what I've misinterpreted. |
462 |
|
463 |
> |
464 |
>> |
465 |
>>> Note OpenBSDs kernel which is very secure (unlike Linux whose |
466 |
>>> primary goal is function) |
467 |
>> |
468 |
>> I have no complaints about OpenBSD. |
469 |
>> |
470 |
>>> and has had just a few remote holes in well over a decade, one of |
471 |
>>> which was in ipv6 |
472 |
>> |
473 |
>> So OpenBSD, who you venerate, had a bug in its IPv6 implementation, |
474 |
>> and for that you view IPv6 as an abomination? Is that it? (Or is it |
475 |
>> because the guy who wrote the buggy code thinks so, and you |
476 |
>> venerate him? Because that seems plausible, too.) |
477 |
>> |
478 |
> |
479 |
> You seem to underestimate the gravity or such a bug making it into |
480 |
> the OpenBSD kernel. |
481 |
|
482 |
You seem to labor under the misunderstanding that OpenBSD is perfect. |
483 |
|
484 |
> |
485 |
> However, not just that, try searching osvdb.org for ipv4 = < 1 page |
486 |
> |
487 |
> ipv6 = > 3 pages |
488 |
|
489 |
You know what I'm noticing in those three pages? Most of those bugs are |
490 |
in hardware vendor firmware. I don't think it would have been any better |
491 |
if they'd had to implement a "IPv4 with extended address bits" protocol. |
492 |
Say what you want about IPv6 being complex, the truth is that IPv6 was |
493 |
explicitly designed to simplify and streamline packet routing. |
494 |
|
495 |
> |
496 |
>>> and which I had avoided without down time because I won't and |
497 |
>>> what's more shouldn't use ipv6 wherever possible |
498 |
>> |
499 |
>> Do you mean that as "I'll avoid IPv6 as much as possible" or do you |
500 |
>> mean that as "I won't use IPv6 in all places where it's possible to |
501 |
>> use IPv6"? |
502 |
>> |
503 |
> |
504 |
> Former |
505 |
> |
506 |
>> If the former, I'm afraid I still haven't seen a solid technical |
507 |
>> case against it. |
508 |
>> |
509 |
> |
510 |
> |
511 |
>>> and had actually removed it from the kernel all together. |
512 |
>> |
513 |
>> That's sensible; if you're not going to use code, remove it. |
514 |
>> |
515 |
> |
516 |
> You would be surprised, many security books used to say it was a |
517 |
> waste of time. I ignored them. |
518 |
> |
519 |
>>> |
520 |
>>> If I am Trolling rather than simply trying to make people aware |
521 |
>>> then stating ipv6 is wonderful is Trolling just as much or more. |
522 |
>> |
523 |
>> IPv6 fixes things about the Internet that are currently broken by |
524 |
>> IPv4 address exhaustion. I try to point out where IPv6 fixes |
525 |
>> things, I try to clear up popular misconceptions about IPv6, and I |
526 |
>> try to help people understand a thing rather than simply fear it. |
527 |
>> |
528 |
>> If you take a highly competent IPv4 network administrator and drop |
529 |
>> him into IPv6 territory without ensuring that he has knowledge of |
530 |
>> IPv6 best practices and practical concerns, you're likely to get a |
531 |
>> broken network out of it. I try to help keep that from happening. |
532 |
> |
533 |
> It is more than that. Though I am glad you are reducing the problems |
534 |
> out there. |
535 |
|
536 |
I want to highlight this next bit. |
537 |
|
538 |
> IPV6 unarguably is worse than IPV4. You can argue it is |
539 |
> also better |
540 |
|
541 |
... |
542 |
|
543 |
> but where if it is it serves no useful purpose for me |
544 |
> that would make me even consider using it unless it is redesigned. |
545 |
|
546 |
I can't say nobody is going to force you to use IPv6. That would be a |
547 |
lie. Eventually, there will be services on the Internet which you won't |
548 |
be able to access without using IPv6 in some way. |
549 |
|
550 |
It's far better to learn how to use the thing (better still, learn how |
551 |
to use it properly!) than to get pushed deeper into the pool without |
552 |
first learning how to swim. |