Trong nhiều năm, báo chí đã viết về vấn đề hiện tại có rất ít địa chỉ IPv4 có sẵn. Nhưng mặt khác, tôi đang sử dụng một công ty lưu trữ máy chủ sẵn sàng cung cấp địa chỉ IPv4 công khai cho một số tiền nhỏ. Và kết nối internet riêng của tôi đi kèm với một địa chỉ IPv4 công cộng.

Làm thế nào là có thể? Là vấn đề tồi tệ như báo chí muốn chúng ta tin tưởng?

Nó rất tệ. Dưới đây là danh sách các ví dụ về những gì tôi có kinh nghiệm đầu tiên với các ISP tiêu dùng đang làm để chống lại sự thiếu hụt địa chỉ IPv4:

• Liên tục xáo trộn xung quanh các khối IPv4 giữa các thành phố gây ra sự cố ngừng hoạt động và thiết lập lại kết nối cho khách hàng.
• Rút ngắn thời gian thuê DHCP từ vài ngày xuống vài phút.
• Cho phép người dùng chọn nếu họ muốn dịch địa chỉ mạng (NAT) trên Thiết bị tiền đề của khách hàng (CPE) hay không, sau đó bật lại cho mọi người.
• Kích hoạt NAT trên CPE cho những khách hàng đã sử dụng cơ hội từ chối NAT.
• Giảm giới hạn số lượng địa chỉ kiểm soát truy cập phương tiện hoạt động đồng thời (MAC) được thi hành bởi CPE.
• Triển khai NAT cấp nhà cung cấp dịch vụ (CGN) cho khách hàng có địa chỉ IP thực khi họ đăng ký dịch vụ.

Tất cả những điều này đang làm giảm chất lượng sản phẩm mà ISP đang bán cho khách hàng của họ. Giải thích hợp lý duy nhất cho lý do tại sao họ sẽ làm điều này với khách hàng của họ là thiếu địa chỉ IPv4.

Việc thiếu địa chỉ IPv4 đã dẫn đến sự phân mảnh không gian địa chỉ có nhiều thiếu sót:

• Chi phí hành chính không chỉ tốn thời gian và tiền bạc mà còn dễ bị lỗi và dẫn đến mất điện.
• Việc sử dụng nhiều dung lượng bộ nhớ có thể định địa chỉ nội dung (CAM) trên các bộ định tuyến đường trục mà vài năm trước đã dẫn đến sự cố ngừng hoạt động đáng kể trên nhiều ISP khi nó vượt qua giới hạn của một mô hình bộ định tuyến phổ biến cụ thể.

Không có NAT, không có cách nào chúng ta có thể có được ngày hôm nay với 3700 triệu địa chỉ IPv4 có thể định tuyến. Nhưng NAT là một giải pháp dễ vỡ mang đến cho bạn một kết nối kém tin cậy và các vấn đề khó gỡ lỗi. Càng nhiều lớp NAT thì nó sẽ càng tệ. Hai thập kỷ làm việc chăm chỉ đã tạo ra một lớp NAT chủ yếu hoạt động, nhưng chúng ta đã vượt qua điểm mà một lớp NAT đủ để hoạt động xung quanh việc thiếu địa chỉ IPv4.

Trước khi chúng tôi bắt đầu dùng hết địa chỉ IPv4, chúng tôi đã không (sử dụng rộng rãi) NAT. Mỗi máy tính được kết nối internet sẽ có địa chỉ duy nhất trên toàn cầu. Khi NAT lần đầu tiên được giới thiệu, nó đã chuyển từ việc cung cấp cho khách hàng của ISP 1 địa chỉ thực trên mỗi thiết bị mà khách hàng đã sử dụng / sở hữu để cung cấp cho 1 khách hàng 1 địa chỉ thực. Điều đó đã khắc phục sự cố trong một thời gian (năm) trong khi chúng tôi phải chuyển sang IPv6. Thay vì chuyển sang IPv6, (hầu hết) mọi người đều chờ đợi mọi người khác chuyển đổi và vì vậy (hầu hết) không ai triển khai IPv6. Bây giờ chúng tôi lại gặp vấn đề tương tự, nhưng lần này, một lớp NAT thứ hai đang được triển khai (CGN) để các ISP có thể chia sẻ 1 địa chỉ thực giữa nhiều khách hàng.

Kiệt sức địa chỉ IP không phải là vấn đề lớn nếu NAT không khủng khiếp, kể cả trong trường hợp người dùng cuối không có quyền kiểm soát đối với nó (Carrier Carrier NAT hoặc CGN).

Nhưng tôi sẽ lập luận rằng NAT rất tệ, đặc biệt là trong trường hợp người dùng cuối không có quyền kiểm soát nó. Và (với tư cách là một người có công việc là kỹ sư / quản trị mạng nhưng có bằng kỹ sư phần mềm), tôi sẽ lập luận rằng bằng cách triển khai NAT thay vì IPv6, các quản trị viên mạng đã chuyển trọng lượng giải quyết việc cạn kiệt địa chỉ khỏi lĩnh vực của họ và cho người dùng cuối và các nhà phát triển ứng dụng.

Vì vậy (theo ý kiến ​​của tôi), tại sao NAT là một điều khủng khiếp, xấu xa nên tránh?

Hãy xem liệu tôi có thể làm điều đó công bằng trong việc giải thích những gì nó phá vỡ (và những vấn đề gây ra mà chúng ta đã quá quen thuộc đến mức chúng ta thậm chí không nhận ra rằng nó có thể tốt hơn):

• Độc lập lớp mạng
• Kết nối ngang hàng
• Đặt tên nhất quán và vị trí của tài nguyên
• Định tuyến tối ưu của lưu lượng, máy chủ biết địa chỉ thực của họ
• Theo dõi nguồn lưu lượng độc hại
• Các giao thức mạng phân tách dữ liệu và kiểm soát thành các kết nối riêng biệt

Hãy xem tôi có thể giải thích từng mục đó không.

Độc lập lớp mạng

Các ISP được cho là chỉ vượt qua các gói lớp 3 và không quan tâm những gì trong các lớp trên đó. Cho dù bạn đang chuyển qua TCP, UDP hoặc thứ gì đó tốt hơn / kỳ lạ hơn (SCTP có thể? Hoặc thậm chí một số giao thức khác tốt hơn TCP / UDP, nhưng bị che khuất vì thiếu hỗ trợ NAT), ISP của bạn không được phép quan tâm; tất cả đều được coi là trông giống như dữ liệu đối với họ.

Nhưng nó không - không phải khi họ đang thực hiện "làn sóng thứ hai" của NAT, "Lớp tàu sân bay" NAT. Sau đó, họ nhất thiết phải xem xét và hỗ trợ các giao thức lớp 4 bạn muốn sử dụng. Ngay bây giờ, điều đó thực tế có nghĩa là bạn chỉ có thể sử dụng TCP và UDP. Các giao thức khác sẽ bị chặn / bỏ (phần lớn các trường hợp theo kinh nghiệm của tôi) hoặc chỉ được chuyển tiếp đến máy chủ cuối cùng "bên trong" NAT đã sử dụng giao thức đó (tôi đã thấy 1 triển khai thực hiện điều này). Ngay cả việc chuyển tiếp đến máy chủ cuối cùng sử dụng giao thức đó cũng không phải là một sửa chữa thực sự - ngay sau khi hai máy chủ sử dụng nó, nó sẽ bị hỏng.

Tôi tưởng tượng có một số giao thức thay thế cho TCP & UDP hiện không được kiểm tra và chưa được sử dụng chỉ vì vấn đề này. Đừng hiểu sai ý tôi, TCP & UDP được thiết kế rất ấn tượng và thật đáng kinh ngạc khi cả hai đều có thể mở rộng quy mô theo cách chúng ta sử dụng internet ngày nay. Nhưng ai biết những gì chúng ta đã bỏ lỡ? Tôi đã đọc về SCTP và nghe có vẻ hay, nhưng chưa bao giờ sử dụng nó vì nó không thực tế vì NAT.

Kết nối ngang hàng

Đây là một vấn đề lớn. Trên thực tế, lớn nhất theo ý kiến ​​của tôi. Nếu bạn có hai người dùng cuối, cả hai đều đứng sau NAT của chính họ, bất kể ai cố gắng kết nối trước, NAT của người dùng khác sẽ bỏ gói của họ và kết nối sẽ không thành công.

Điều này ảnh hưởng đến các trò chơi, trò chuyện thoại / video (như Skype), lưu trữ máy chủ của riêng bạn, v.v.

Có cách giải quyết. Vấn đề là những cách giải quyết đó làm tốn thời gian của nhà phát triển, thời gian của người dùng cuối & sự bất tiện hoặc chi phí cơ sở hạ tầng dịch vụ. Và họ không ngu ngốc và đôi khi phá vỡ. (Xem bình luận của người dùng khác về việc ngừng hoạt động của Skype.)

Một cách giải quyết khác là chuyển tiếp cổng, trong đó bạn lập trình thiết bị NAT để chuyển tiếp một cổng đến cụ thể đến một máy tính cụ thể phía sau thiết bị NAT. Có toàn bộ trang web dành cho cách làm điều này cho tất cả các thiết bị NAT khác nhau hiện có. Xem https://portforward.com/ . Điều này thường tốn thời gian của người dùng cuối và sự thất vọng.

Một cách giải quyết khác là thêm hỗ trợ cho những thứ như bấm lỗ cho các ứng dụng và duy trì cơ sở hạ tầng máy chủ không nằm sau NAT để giới thiệu hai máy khách NAT. Điều này thường tốn thời gian phát triển và đặt các nhà phát triển vào vị trí có khả năng duy trì cơ sở hạ tầng máy chủ, nơi mà trước đây không cần phải có.

(Hãy nhớ những gì tôi đã nói về việc triển khai NAT thay vì IPv6 chuyển trọng số của vấn đề từ quản trị viên mạng sang người dùng cuối và nhà phát triển ứng dụng?)

Đặt tên nhất quán / vị trí của tài nguyên mạng

Do không gian địa chỉ khác được sử dụng ở bên trong NAT sau đó ở bên ngoài, nên bất kỳ dịch vụ nào được cung cấp bởi một thiết bị bên trong NAT đều có nhiều địa chỉ để tiếp cận và địa chỉ chính xác sẽ sử dụng tùy thuộc vào nơi khách hàng truy cập từ đó . (Đây vẫn là một vấn đề ngay cả sau khi bạn chuyển tiếp cổng hoạt động.)

Nếu bạn có máy chủ web bên trong NAT, hãy nói trên cổng 192.168.0.23 cổng 80 và thiết bị NAT (bộ định tuyến / cổng) của bạn có địa chỉ bên ngoài là 35.72.216.228 và bạn thiết lập chuyển tiếp cổng cho cổng TCP 80, bây giờ là của bạn máy chủ web có thể được truy cập bằng cách sử dụng cổng 192.168.0.23 80 OR 35.72.216.228 80. Cổng bạn nên sử dụng tùy thuộc vào việc bạn ở trong hay ngoài NAT. Nếu bạn ở ngoài NAT và sử dụng địa chỉ 192.168.0.23, bạn sẽ không đến nơi bạn mong đợi. Nếu bạn ở trong NAT và bạn sử dụng địa chỉ bên ngoài 35.72.216.228, bạn có thể đến nơi bạn muốn, nếu triển khai NAT của bạn là địa chỉ nâng cao hỗ trợ kẹp tóc, nhưng sau đó máy chủ web phục vụ yêu cầu của bạn sẽ thấy yêu cầu đến từ thiết bị NAT của bạn. Điều này có nghĩa là tất cả lưu lượng truy cập phải đi qua thiết bị NAT, ngay cả khi có một đường dẫn ngắn hơn trong mạng phía sau NAT và điều đó có nghĩa là các bản ghi trên máy chủ web trở nên ít hữu ích hơn vì tất cả đều liệt kê thiết bị NAT là nguồn của sự kết nối. Nếu triển khai NAT của bạn không hỗ trợ kẹp tóc, thì bạn sẽ không đến được nơi bạn muốn đến.

Và vấn đề này trở nên tồi tệ hơn ngay khi bạn sử dụng DNS. Đột nhiên, nếu bạn muốn mọi thứ hoạt động chính xác cho thứ gì đó được lưu trữ phía sau NAT, bạn sẽ muốn đưa ra các câu trả lời khác nhau về địa chỉ của dịch vụ được lưu trữ bên trong NAT, dựa trên người đang hỏi (DNS chia chân trời AKA, IIRC). Kinh quá.

Và đó là tất cả giả sử bạn có ai đó am hiểu về chuyển tiếp cổng và kẹp tóc NAT và DNS chân trời phân chia. Còn người dùng cuối thì sao? Cơ hội nào để mọi thứ này được thiết lập đúng khi họ mua bộ định tuyến tiêu dùng và một số camera an ninh IP và muốn nó "chỉ hoạt động"?

Và điều đó dẫn tôi đến:

Định tuyến tối ưu của lưu lượng, máy chủ biết địa chỉ thực của họ

Như chúng ta đã thấy, ngay cả với lưu lượng truy cập NAT kẹp tóc tiên tiến không phải lúc nào cũng chảy qua đường dẫn tối ưu. Đó là ngay cả trong trường hợp một quản trị viên am hiểu thiết lập một máy chủ và có NAT kẹp tóc. (Cấp DNS, đường chân trời phân chia có thể dẫn đến việc định tuyến tối ưu lưu lượng truy cập nội bộ trong tay quản trị viên mạng.)

Điều gì xảy ra khi nhà phát triển ứng dụng tạo một chương trình như Dropbox và phân phối nó cho người dùng cuối không chuyên cấu hình thiết bị mạng? Cụ thể, điều gì xảy ra khi tôi đặt tệp 4GB trong tệp chia sẻ của mình và sau đó thử truy cập vào máy tính tiếp theo? Liệu nó có chuyển trực tiếp giữa các máy không, hay tôi phải đợi nó tải lên máy chủ đám mây thông qua kết nối mạng chậm, và sau đó đợi lần thứ hai để nó tải xuống qua cùng một kết nối mạng chậm?

Đối với việc triển khai ngây thơ, nó sẽ được tải lên và sau đó được tải xuống, sử dụng cơ sở hạ tầng máy chủ của Dropbox không nằm sau NAT làm trung gian hòa giải. Nhưng nếu hai máy chỉ có thể nhận ra rằng chúng nằm trên cùng một mạng, thì chúng có thể chuyển trực tiếp tệp nhanh hơn nhiều. Vì vậy, để thử triển khai ít ngây thơ đầu tiên của chúng tôi, chúng tôi có thể hỏi HĐH về địa chỉ IP (v4) mà máy có, sau đó kiểm tra xem các máy khác đã đăng ký trên cùng một tài khoản Dropbox. Nếu nó nằm trong cùng phạm vi với chúng tôi, chỉ cần chuyển trực tiếp tệp. Điều đó có thể làm việc trong rất nhiều trường hợp. Nhưng thậm chí sau đó có một vấn đề: NAT chỉ hoạt động vì chúng ta có thể sử dụng lại địa chỉ. Vậy nếu địa chỉ 192.168.0.23 và 192.168.0. 42 địa chỉ được đăng ký trên cùng một tài khoản Dropbox có thực sự trên các mạng khác nhau (như mạng gia đình và mạng làm việc của bạn) không? Bây giờ bạn phải quay lại sử dụng cơ sở hạ tầng máy chủ Dropbox để làm trung gian. (Cuối cùng, Dropbox đã cố gắng giải quyết vấn đề bằng cách cho mỗi máy khách Dropbox phát trên mạng cục bộ với hy vọng tìm thấy các máy khách khác. Nhưng những chương trình phát sóng đó không vượt qua bất kỳ bộ định tuyến nào bạn có thể có sau NAT, có nghĩa đó không phải là một giải pháp đầy đủ ,đặc biệt là trong trường hợp của CGN .)

IP tĩnh

Ngoài ra, do sự thiếu hụt đầu tiên (và làn sóng NAT) xảy ra khi nhiều kết nối của người tiêu dùng không phải lúc nào cũng kết nối (như quay số), các ISP có thể sử dụng địa chỉ của họ tốt hơn bằng cách chỉ phân bổ địa chỉ IP công cộng / bên ngoài khi bạn thực sự được kết nối. Điều đó có nghĩa là khi bạn kết nối, bạn có bất kỳ địa chỉ nào có sẵn, thay vì luôn luôn nhận được cùng một địa chỉ. Điều đó làm cho việc chạy máy chủ của bạn trở nên khó khăn hơn rất nhiều và nó khiến việc phát triển các ứng dụng ngang hàng trở nên khó khăn hơn vì chúng cần phải xử lý các đồng nghiệp di chuyển xung quanh thay vì ở các địa chỉ cố định.

Obfuscation nguồn lưu lượng độc hại

Bởi vì NAT ghi lại các kết nối gửi đi như thể chúng đến từ chính thiết bị NAT, tất cả các hành vi, tốt hay xấu, được đưa vào một địa chỉ IP bên ngoài. Tôi chưa thấy bất kỳ thiết bị NAT nào ghi lại từng kết nối đi theo mặc định. Điều này có nghĩa là theo mặc định, nguồn lưu lượng độc hại trong quá khứ chỉ có thể được truy tìm đến thiết bị NAT mà nó đã đi qua. Mặc dù nhiều thiết bị lớp doanh nghiệp hoặc nhà cung cấp hơn có thể được cấu hình để ghi nhật ký từng kết nối đi, tôi chưa thấy bất kỳ bộ định tuyến tiêu dùng nào làm điều đó. Tôi chắc chắn nghĩ rằng sẽ rất thú vị để xem liệu ISP (và trong bao lâu) các ISP sẽ giữ một bản ghi của tất cả các kết nối TCP và UDP được thực hiện thông qua CGN khi họ triển khai chúng. Những hồ sơ như vậy sẽ là cần thiết để giải quyết các khiếu nại lạm dụng và khiếu nại DMCA.

Một số người nghĩ rằng NAT tăng cường an ninh. Nếu nó làm, nó làm như vậy thông qua tối nghĩa. Việc giảm lưu lượng truy cập đến mặc định mà NAT thực hiện bắt buộc cũng giống như có tường lửa trạng thái. Theo hiểu biết của tôi, bất kỳ phần cứng nào có khả năng thực hiện theo dõi kết nối cần thiết cho NAT đều có thể chạy tường lửa trạng thái, vì vậy NAT không thực sự xứng đáng với bất kỳ điểm nào ở đó.

Các giao thức sử dụng kết nối thứ hai

Các giao thức như FTP và SIP (VoIP) có xu hướng sử dụng các kết nối riêng biệt để kiểm soát và nội dung dữ liệu thực tế. Mỗi giao thức thực hiện điều này phải có phần mềm trợ giúp được gọi là ALG (cổng lớp ứng dụng) trên mỗi thiết bị NAT mà nó đi qua hoặc xử lý vấn đề với một số loại trung gian hoặc bấm lỗ. Theo kinh nghiệm của tôi, ALG hiếm khi được cập nhật và là nguyên nhân của ít nhất một vài vấn đề tôi đã giải quyết liên quan đến SIP. Bất cứ khi nào tôi nghe ai đó báo cáo rằng VoIP không hoạt động với họ vì âm thanh chỉ hoạt động theo một cách, tôi ngay lập tức nghi ngờ rằng ở đâu đó, có một cổng NAT bỏ các gói UDP mà nó không thể biết phải làm gì.

Tóm lại, NAT có xu hướng phá vỡ:

• giao thức thay thế cho TCP hoặc UDP
• hệ thống ngang hàng
• truy cập một cái gì đó được lưu trữ đằng sau NAT
• những thứ như SIP và FTP. ALGs để giải quyết vấn đề này vẫn gây ra các vấn đề ngẫu nhiên và kỳ lạ ngày nay, đặc biệt là với SIP.

Về cốt lõi, cách tiếp cận nhiều lớp mà ngăn xếp mạng thực hiện tương đối đơn giản và thanh lịch. Cố gắng giải thích nó cho một người mới biết về mạng và chắc chắn họ cho rằng mạng gia đình của họ có lẽ là một mạng tốt, đơn giản để cố gắng hiểu. Tôi đã thấy điều này dẫn đến một vài trường hợp cho một số ý tưởng khá thú vị (quá phức tạp) về cách định tuyến hoạt động vì sự nhầm lẫn giữa các địa chỉ bên ngoài và bên trong.

Tôi nghi ngờ rằng nếu không có NAT, VoIP sẽ có mặt ở khắp mọi nơi và được tích hợp với PSTN và việc thực hiện cuộc gọi từ điện thoại di động hoặc máy tính sẽ miễn phí (ngoại trừ internet bạn đã trả tiền). Rốt cuộc, tại sao tôi lại trả tiền điện thoại khi bạn và tôi chỉ có thể mở một luồng VoIP 64K và nó hoạt động tốt như PSTN? Có vẻ như ngày nay, vấn đề số 1 với việc triển khai VoIP là thông qua các thiết bị NAT.

Tôi nghi ngờ chúng ta thường không nhận ra nhiều thứ có thể đơn giản hơn nhiều như thế nào nếu chúng ta kết thúc việc kết nối mà NAT bị phá vỡ. Mọi người vẫn tự gửi email (hoặc Dropbox) các tệp vì nếu vấn đề cốt lõi là cần một người hòa giải khi hai khách hàng đứng sau NAT.

Một triệu chứng lớn của sự cạn kiệt IPv4 mà tôi không thấy được đề cập trong các câu trả lời khác là một số nhà cung cấp dịch vụ di động đã bắt đầu sử dụng IPv6 chỉ vài năm trước. Có một cơ hội bạn đã sử dụng IPv6 trong nhiều năm và thậm chí không biết đến nó. Các nhà cung cấp dịch vụ di động mới hơn trong trò chơi Internet và không nhất thiết phải có các khoản phân bổ IPv4 rất lớn hiện có để rút ra. Họ cũng yêu cầu nhiều địa chỉ hơn cáp / DSL / cáp quang, vì điện thoại của bạn không thể chia sẻ địa chỉ IP công cộng với các thành viên khác trong gia đình bạn.

Tôi đoán là các nhà cung cấp IaaS và PaaS sẽ là người tiếp theo, do sự tăng trưởng của họ không gắn liền với địa chỉ vật lý của khách hàng. Tôi sẽ không ngạc nhiên khi thấy các nhà cung cấp IaaS chỉ cung cấp IPv6 với giá giảm.

Các RIR chính đã hết dung lượng để phân bổ bình thường một thời gian trước đây. Do đó, đối với hầu hết các nhà cung cấp, các nguồn địa chỉ IPv4 duy nhất là kho dự trữ của riêng họ và thị trường.

Có những kịch bản trong đó tốt hơn là nên có một IP IPv4 công cộng chuyên dụng nhưng nó không thực sự cần thiết. Ngoài ra còn có một loạt các địa chỉ IPv4 công cộng được phân bổ nhưng hiện không được sử dụng trên internet công cộng (chúng có thể được sử dụng trên các mạng riêng hoặc chúng hoàn toàn không được sử dụng). Cuối cùng, có các mạng cũ hơn với các địa chỉ được phân bổ lỏng lẻo hơn nhiều so với mức cần thiết.

Ba RIR lớn nhất hiện nay cho phép các địa chỉ được bán cả giữa các thành viên của họ và cho các thành viên khác. Vì vậy, chúng tôi có một thị trường giữa các tổ chức có địa chỉ mà họ không sử dụng hoặc những người có địa chỉ có thể được giải phóng với chi phí ở một bên và các tổ chức thực sự cần nhiều địa chỉ IP ở bên kia.

Điều khó dự đoán là sẽ có bao nhiêu cung và cầu tại mỗi điểm giá và do đó giá thị trường sẽ làm gì trong tương lai. Cho đến nay, giá mỗi IP dường như vẫn còn thấp đáng ngạc nhiên.

Lý tưởng nhất là mọi máy chủ lưu trữ trên internet sẽ có thể có được địa chỉ IP phạm vi toàn cầu, tuy nhiên việc cạn kiệt địa chỉ IPv4 là có thật, ARIN nguyên vẹn đã hết địa chỉ trong nhóm miễn phí của họ .

Lý do tại sao mọi người vẫn có thể truy cập các dịch vụ internet tốt, là nhờ các kỹ thuật Dịch địa chỉ mạng (NAT) cho phép nhiều máy chủ chia sẻ địa chỉ IP công cộng. Tuy nhiên, điều này không đến mà không có vấn đề.

ISP được sử dụng để cung cấp khối 256 địa chỉ IP cho các công ty. Bây giờ, ISP rất keo kiệt và cung cấp cho bạn (một công ty) như 5. Trước đây (2003), mọi PC và thiết bị được kết nối trong nhà bạn đều có địa chỉ IP internet riêng. Bây giờ, bộ định tuyến cáp / DSN / Fios có một địa chỉ IP và cung cấp địa chỉ IP 10.0.0.x cho tất cả các PC trong nhà bạn. Tóm tắt: ISP được sử dụng để lãng phí địa chỉ IP và giờ đây họ sẽ không lãng phí chúng nữa.

Bạn đã có nhiều câu trả lời xuất sắc, nhưng tôi muốn thêm một số điều chưa được đề cập.

Có, cạn kiệt địa chỉ IPv4 là xấu, tùy thuộc vào cách bạn đo lường nó. Một số công ty vẫn có nguồn cung cấp lớn các địa chỉ IPv4, nhưng chúng tôi bắt đầu thấy các cách giải quyết như NAT cấp nhà mạng.

Nhưng nhiều câu trả lời sai khi họ chuyển sang IPv6.

Dưới đây là danh sách các công nghệ có thể giúp giải quyết tình trạng thiếu địa chỉ IPv4. Mỗi cái đều có ưu điểm và nhược điểm riêng.

• IPv6

  • Ưu điểm: được chuẩn hóa và có sẵn trong hầu hết các hệ điều hành.
  • Nhược điểm: mặc dù thường xuyên tuyên bố ngược lại, vấn đề bảo mật nghiêm trọng. Cho đến tận năm 2005, CERT Hoa Kỳ đã cảnh báo về các vấn đề bảo mật gây ra bởi việc đánh địa chỉ toàn cầu của IPv6. IPv6 có thể được bảo mật đúng cách, nhưng với trạng thái của bộ định tuyến người tiêu dùng, điều đó có thể không xảy ra.
  • Nhược điểm: di chuyển mất thời gian, tiền bạc và chuyên môn.
  • Nhược điểm: nhiều thiết bị cấp tiêu dùng bị thiếu sót nghiêm trọng. Chẳng hạn, một số bộ định tuyến D-Link hỗ trợ IPv6 bằng cách chuyển tiếp tất cả lưu lượng mà không cung cấp bất kỳ tường lửa nào.

Một cân nhắc khác: ngay cả khi IPv6 bắt đầu hoàn toàn vào ngày hôm nay, vẫn sẽ mất thêm 20 năm nữa để loại bỏ IPv4, do thiết bị cũ mà mọi người sẽ sử dụng trong một thời gian rất dài (tôi vẫn thấy máy chủ Windows 2003 và máy trạm Windows XP thỉnh thoảng! Không đề cập đến tất cả các máy in, máy ảnh và tiện ích IoT không hỗ trợ IPv6).

• CGNat:
  • Ưu điểm: hoạt động mà không thay đổi trên cơ sở khách hàng.
  • Nhược điểm: chỉ hỗ trợ các kết nối ra.
  • Nhược điểm: có thể không hỗ trợ một vài giao thức.

Cuối cùng, CGNat sẽ không đủ. Có thể IPv6 sẽ bắt kịp, nhưng cũng có khả năng là chúng ta sẽ thấy NAT cấp quốc gia, hoặc một cái gì đó dọc theo các dòng đó.

Hiện tại, với tư cách là một nhà tư vấn, tôi thường phải chỉ ra cho khách hàng của mình rằng họ được tiếp xúc trên IPv6 (thường là nhờ Teredo). Câu hỏi tiếp theo sẽ luôn là: "Chi phí để sửa nó là bao nhiêu?" và sau đó "Chi phí để chặn nó là bao nhiêu? Chúng ta sẽ mất gì nếu tắt nó đi?" Đoán xem quyết định sẽ là gì mỗi lần.

Điểm mấu chốt: để trả lời câu hỏi của bạn, vâng, cạn kiệt IPv4 là có thật. Và chúng ta sẽ thấy khá nhiều cơ chế để đối phó với nó. IPv6 có thể hoặc không thể là phương trình.

Để rõ ràng: Tôi không nói rằng tôi thích tình huống này. Tôi muốn IPv6 thành công (và tôi muốn thấy một số cải tiến đối với IPv6). Tôi chỉ đang nhìn vào tình huống như nó đang ở trên mặt đất ngay bây giờ.

NAT là những gì đã xảy ra khi IPv6 là một ý tưởng, trước khi nó trở thành hiện thực và việc phân bổ địa chỉ IP đang trở thành một vấn đề thực sự (có ai còn nhớ khi họ đưa ra lớp C về cơ bản để hỏi không?) Và thế giới thực trong lúc đó cần một giải pháp .

NAT không đủ cho IoT. Nếu IoT sẽ xảy ra, nó sẽ xảy ra với IPv6. Bản chất của IoT phù hợp chặt chẽ hơn với cách thế giới quay số hoạt động, ngoại trừ việc sẽ có một số đơn đặt hàng nhiều thiết bị được kết nối cùng một lúc.

Toàn bộ vấn đề địa chỉ IPv4 khá phức tạp. Bạn có thể thấy một số bài báo nhất định báo cáo rằng nó đã cạn kiệt, nhưng một bài viết khác nói về số lượng lớn địa chỉ dư thừa (không bao giờ được sử dụng) được bán từ bên này sang bên khác. Câu hỏi đặt ra là tại sao những thứ này không có sẵn cho những người (khu vực mới nổi và khu vực nông thôn của các nước phát triển) thiếu chúng?

Dưới đây là kết quả của một nghiên cứu mà chúng tôi vô tình mạo hiểm vào. Nó sử dụng không có gì nhiều hơn giao thức IPv4 gốc RFC791 và khối địa chỉ 240/4 được bảo lưu lâu nhưng hầu như không được sử dụng để mở rộng nhóm IPv4 gấp 256M. Chúng tôi đã gửi một đề xuất dự thảo có tên EzIP (phiên âm cho Easy IPv4) tới IETF:

https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03

Về cơ bản, cách tiếp cận EzIP sẽ không chỉ giải quyết các vấn đề thiếu địa chỉ IPv4, mà còn giảm thiểu phần lớn nguyên nhân gốc rễ đối với các lỗ hổng bảo mật mạng, cộng với mở ra các khả năng mới cho Internet, tất cả nằm trong giới hạn của tên miền IPv4. Trên thực tế, kế hoạch này có thể được triển khai "lén lút" cho các khu vực bị cô lập khi cần thiết. Những điều này sẽ làm giảm sự cấp bách để triển khai IPv6 trong một khoảng thời gian đáng kể và làm mất hiệu lực thị trường giao dịch các địa chỉ IPv4.

Bất kỳ suy nghĩ hoặc nhận xét sẽ được nhiều đánh giá cao.

Abe (2018-07-15 17:29)

Thành thật mà nói, tôi nghĩ nó không tệ như mọi người nghĩ. Vâng, có thể ở một số nơi, nhưng không nhiều vì không có đủ địa chỉ. Đó là bởi vì tất cả họ đều thuộc sở hữu. Có thể đó là vị trí của tôi hoặc một cái gì đó, nhưng tôi đã làm công việc CNTT cho một loạt các doanh nghiệp vừa và nhỏ trong bảy năm qua hoặc lâu hơn, và tất cả những điều bạn đang nói về thường chỉ là thiết lập tiêu chuẩn. Khá dễ dàng trừ khi bạn có một thiết bị tào lao, hoặc có một thiết lập tồi tệ với mạng ở nơi đầu tiên cần được sắp xếp.

Cá nhân tôi ổn với NAT. Nói chung, đó là một lớp bảo vệ bổ sung. Ít nhất là họ hoặc phải thông qua một thiết bị bổ sung, hoặc tìm cách gián tiếp chiếm quyền điều khiển kết nối của tôi. Theo như các máy chủ đang chạy, điều đó thường nằm ngoài và / hoặc bị coi là vi phạm hợp đồng với ISP của bạn trừ khi bạn trả tiền cho nó. Chắc chắn bạn có thể làm điều đó, và họ có thể sẽ không làm phiền bạn về điều đó, nhưng họ có thể.

Chuyển tiếp cổng và tất cả những gì không chính xác phức tạp. Bây giờ, có thể một số thiết bị không dễ cấu hình, nhưng đó không phải là do IPv4. Nó vẫn cung cấp khả năng tương thích đơn giản nhất vì nó có mặt khắp nơi.

Không ai thực sự cần phải tự gửi email và gửi một cái gì đó đến Drop-box hoặc Google Drive, hoặc một triệu dịch vụ tương tự khác không chính xác là khoa học tên lửa, cũng không chậm, trong những ngày này. Ý tôi là mọi thứ đều đồng bộ. Bạn thả nó vào một thư mục. Trừ khi bạn không thích tôi, và bạn làm mọi thứ thông qua ssh / sftp (không phải tất cả mọi thứ ). Và nếu bạn có một số lý do bạn thực sự muốn chạy máy chủ của riêng mình, thì lưu trữ đám mây rất rẻ-- Tôi đã có một máy chủ ảo chuyên dụng chạy linux trên một ssd. Băng thông là điên nhanh. Nó khởi động nhanh hơn tôi có thể gõ một mũi tên lên và nhấn Enter. Và có thể mở rộng Toàn bộ chi phí thiết lập từ 5 đến 10 đô la một tháng, với các bản sao lưu miễn phí và không có hóa đơn điện.

Đừng thực sự cần một giải pháp mạng ngang hàng. Ngay cả hầu hết các trò chơi nhiều người dùng hiện nay đều là thiết lập để tương tác thông qua một máy chủ can thiệp, tất cả các thiết lập và cấu hình sẵn. Mặt khác, nếu những gì tôi đọc trong bài viết này hoàn toàn là sự thật, CNTT sẽ quá đông và rẻ nếu / khi IPv6 cất cánh. Ngay cả điện thoại di động đang tiếp cận tốc độ giống như sợi. Hoặc ít nhất là cáp.

Nếu bạn chạy một máy chủ nội bộ và bạn cần phải đánh nó với cùng một tên miền trong hoặc ngoài mạng của mình, bạn luôn có thể giả mạo địa chỉ của nó bằng bộ định tuyến dựa trên linux và dnsmasq hoặc bất kỳ mục nhập và tùy chỉnh nào trong máy chủ lưu trữ tập tin để chuyển hướng bạn đến địa chỉ địa phương nếu bạn ở bên trong.

Thực sự, tôi không nghĩ rằng thực sự mong muốn có mọi thiết bị đều có địa chỉ riêng ngay ngoài mạng. Nếu ai đó muốn tự làm khổ mình trong khi tấn công bạn, điều đó sẽ xảy ra bất kể. Nhưng bạn là một con vịt ngồi nếu bạn chỉ ngồi đó bóng trong gió nhẹ. Không, tôi sẽ lấy IPv4 và NAT của tôi bất cứ ngày nào. Nhưng thật tốt khi nó ở đó.

Anywa, ngủ ngay bây giờ ... có lẽ nhiều điều để nói nhưng tôi sẽ kiểm tra vào ngày mai trong trường hợp tôi bỏ lỡ điều gì đó. Tôi chắc chắn có nhiều hơn nữa.