Tại sao 192.168. *. * Cho địa chỉ địa phương? [đóng cửa]


34

Tiêu chuẩn tôi đã thấy cho đến nay là sử dụng 192.168. *. * Địa chỉ IP cho các thiết bị trên mạng cục bộ.

Tại sao sự kết hợp này? Nếu là tôi, tôi đã chọn một cái gì đó đơn giản hơn, như 1.0. *. *. Lý do lịch sử là gì?


5
10.0.0.0/8 là không gian địa chỉ riêng tư hợp lệ ... khá đơn giản
Mike Pennington

5
Phần 192gần như chắc chắn xuất phát từ thực tế rằng đây là khối sử dụng riêng được liên kết với các địa chỉ IP lớp C (trở lại vào những ngày đầu, lớp học) và lớp C bắt đầu từ 192.0.0.0. Có nhiều thông tin hơn tại sao các mạng gia đình có tiền tố 192.168? (Siêu người dùng) và Tại sao 192.168.xy được sử dụng cho IP cục bộ? (Stack Overflow), nhưng tôi không thể tìm thấy lý do cho sự lựa chọn của 168bất kỳ nơi nào trên Internet.
Pops

4
@pops, điều tốt nhất tôi tìm thấy là tin nhắn này của Steven Ehrbar , người đã tuyên bố rằng 192.168. *. * đã được sử dụng bởi một công ty hệ thống trong sách hướng dẫn; điều này dẫn đến một số lượng đáng kể người sử dụng không gian địa chỉ này trên các mạng nội bộ của họ. Điều này nghe có vẻ quen thuộc đến mức Randy Bush nghĩ rằng đó là Mặt trời (nhưng không phải vậy)
Mike Pennington

Các câu hỏi về những câu đố lịch sử rõ ràng lạc đề ở đây.
Ron Maupin

Câu trả lời:


34

Lưu ý: Trừ khi chúng tôi có thể nhận được một trong những tác giả gốc của RFC 1918 / RFC 1597 hoặc ai đó từ InterNIC / RIPE NCC tại thời điểm đó (1994-1996) để nhận xét *, chúng tôi có thể để lại những phỏng đoán và câu trả lời cho câu hỏi này chủ yếu dựa trên ý kiến.


Theo RFC 1918 , ba phạm vi sau được dành riêng để sử dụng trên các mạng riêng:

10.0.0.0        -   10.255.255.255  (10/8 prefix)
172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

Đây là lý do tại sao bạn sẽ thấy chúng được sử dụng cho các thiết bị trên mạng cục bộ.

Lý do đằng sau ít nhất một phần của ba phạm vi địa chỉ "riêng tư" này khá đơn giản, nhưng một lần nữa nằm ngoài logic, đây là những phỏng đoán dựa trên bài đọc của tôi trong nhiều năm qua.

Trước tiên hãy xem xét rằng các mạng lớp là như sau ( bài viết Wikipedia nguồn trên Mạng lớp ):

Class A
  0.  0.  0.  0 = 00000000.00000000.00000000.00000000
127.255.255.255 = 01111111.11111111.11111111.11111111
                  0nnnnnnn.HHHHHHHH.HHHHHHHH.HHHHHHHH

Class B
128.  0.  0.  0 = 10000000.00000000.00000000.00000000
191.255.255.255 = 10111111.11111111.11111111.11111111
                  10nnnnnn.nnnnnnnn.HHHHHHHH.HHHHHHHH

Class C
192.  0.  0.  0 = 11000000.00000000.00000000.00000000
223.255.255.255 = 11011111.11111111.11111111.11111111
                  110nnnnn.nnnnnnnn.nnnnnnnn.HHHHHHHH

Class D
224.  0.  0.  0 = 11100000.00000000.00000000.00000000
239.255.255.255 = 11101111.11111111.11111111.11111111
                  1110XXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX

Class E
240.  0.  0.  0 = 11110000.00000000.00000000.00000000
255.255.255.255 = 11111111.11111111.11111111.11111111
                  1111XXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX

Như bạn có thể thấy, mỗi một trong ba phạm vi RFC1918 sẽ cắt một khối riêng tư khỏi một trong các phạm vi mạng "đẳng cấp" cũ. (Lớp A, Lớp B và Lớp C trong trường hợp này.)

Trích lời Dumbledore, "Từ thời điểm này trở đi, chúng ta sẽ rời khỏi nền tảng vững chắc của thực tế và cùng nhau hành trình qua những đầm lầy âm u của ký ức thành những bụi cây phỏng đoán điên rồ nhất."

Các IANA đã được gán các địa chỉ trong nhiều năm trước khi bắt đầu RFC 1918 (tháng 2 năm 1996) . (Trên thực tế, phạm vi riêng tư được đưa ra lần đầu tiên trong RFC 1597 vào tháng 3 năm 1994.) Ví dụ: nếu bạn tiến hành whois 8.0.0.0tra cứu, bạn có thể thấy rằng Cấp 3 có khối này được gán vào năm 1992-12-01.

Do đó, có thể giả định rằng các tác giả của RFC1918 đã phải làm việc với IANA / Jon Postel để tìm các phạm vi có sẵn, cung cấp cho chúng tôi các phạm vi riêng tư được liệt kê ở trên.

Nhưng một lần nữa, trừ khi ai đó trực tiếp tham gia vào quá trình * lên tiếng, điều này có thể vẫn là phỏng đoán.

* Hoặc chỉ là người có Google-foo tốt hơn tôi. Tôi không thể tìm thấy một nguồn chính cho thông tin này.


1
Chính xác. Vào thời điểm đó, địa chỉ kính được sử dụng. Để phù hợp với các mạng có kích thước khác nhau, một mạng lớp A, 32 lớp B và 256 lớp C đã được chỉ định. Tại sao 10, 172.16 và 192.168? Bởi vì đó là một suy nghĩ lại và những thứ đó đã có sẵn.
bahamat

4
@bahamat 192.168.1.0/24 và 10.1.1.0/24 là tương đương nhau. Cả hai mạng con đều phù hợp với cấu trúc C có cùng kích thước ... không có bộ nhớ nào được lưu với 192.168
Mike Pennington

2
CIDR khoảng 20 tuổi, không ai có bộ định tuyến tại nhà 20 năm trước
Mike Pennington

2
@bahamat, 9 lần trong số 10 bộ định tuyến gia đình không cần chạy IGP (có đủ hay không) và phạm vi DHCP trên chúng hoàn toàn có thể định cấu hình người dùng nên tôi không thấy tính hợp lệ của xác nhận của bạn.
John Jensen

2
10/8 là ARPANET cũ. Sau khi không gian của nó quay trở lại ARIN, nó đã được đánh dấu dành riêng và trở thành đầu tiên / 8 theo như tôi biết là có sẵn cho sử dụng cá nhân. 172.16 / 12 có phân bổ lớn nhất, liên tục không được chỉ định. Không chắc chắn về 192.168 / 16 ngoài nó có sẵn trong phạm vi Class C cũ.
generalnetworkerror

5

Như những người khác đã chỉ ra, RFC1918 định nghĩa 3 dải IP riêng. Vào năm 1996, vẫn còn các thiết bị cũ xung quanh không hỗ trợ CIDR , do đó, một phạm vi đã được tạo cho mỗi lớp. Địa chỉ lớp B bắt đầu từ 128.0.0.0 và địa chỉ lớp C bắt đầu từ 192.0.0.0; 168 đã được chọn chỉ vì nó chưa được phân bổ.

Nhưng điều này đặt ra một câu hỏi khác - tại sao phải có phạm vi lớp C? Vì sự khác biệt duy nhất giữa các lớp A, B và C là kích thước mạng, tại sao không sử dụng 10.0.0.0/8? Theo RFC1918:

Nếu một sơ đồ mạng con phù hợp có thể được thiết kế và được hỗ trợ bởi các thiết bị liên quan, thì nên sử dụng khối 24 bit (mạng lớp A) của không gian địa chỉ riêng và lập kế hoạch xử lý địa chỉ với lộ trình tăng trưởng tốt. Nếu mạng con là một vấn đề, có thể sử dụng khối 16 bit (mạng lớp C) hoặc khối 20 bit (mạng lớp B) của không gian địa chỉ riêng.

Tôi không chắc chính xác loại "vấn đề" nào với việc thuê lại các tác giả đã nghĩ đến. Có lẽ một số phần cứng trước CIDR không hỗ trợ mạng Lớp A do hạn chế về bộ nhớ (mặc dù bạn sẽ nghĩ rằng đó là số lượng máy chủ chứ không phải số lượng máy chủ tiềm năng mới là vấn đề).

Ngoài ra, mạng lớp C là / 24 giây, mặc dù 192.168.xx là / 16 - vì vậy, trong mạng lớp đầy đủ 192.168.xx thực sự chứa 256 mạng con. Điều này có thể hữu ích cho các tổ chức lớn muốn chạy mạng con riêng trên phần cứng trước CIDR.


ừm a / 24 có thể là Mạng loại C nếu các bit đầu tiên của địa chỉ là 110. Nhưng bạn cũng nhận được a / 24 từ Mạng loại A hoặc B. Mạng lớp là chết trong một thời gian dài. Người ta chỉ nên sử dụng Class-A, -B, -C trong bối cảnh lịch sử.
Liên kết Jens

-1

Vui lòng sử dụng 10.0.0.0 - 10.255.255.255, mỗi RFC 6890 , trang 6.

Tôi đã từng nghĩ rằng trả lời các câu hỏi lịch sử là một ý tưởng tốt, nhưng tôi muốn tránh làm điều này một cách thường xuyên, do kinh nghiệm giúp đỡ ma cà rồng xấu. Nó không có vẻ cần thiết trong trường hợp này. 10.0.0.0/8 là đủ đơn giản.


1
Thẳng thắn mà nói, bạn không trả lời câu hỏi. Tôi đang hỏi về lịch sử của nó, không phải cho một phạm vi địa phương đơn giản hơn. Nếu bạn không nghĩ đó là một câu hỏi hay, hãy đóng nó lại.
Hoàn tác

1
Tiền đề đằng sau sự phản đối của bạn đối với 192.168. *. * Là bạn đã "chọn một cái gì đó đơn giản hơn". Vấn đề là 10.0.0.0/8 cũng là không gian RFC1918 và nó đơn giản hơn, nhưng bạn không thể quyết định ngẫu nhiên chọn bất kỳ không gian địa chỉ nào trên internet mà không gặp rắc rối . Nếu cộng đồng muốn đóng cửa thì không sao ... Tóm lại, tôi nghĩ rằng bạn đang quá phũ phàng WRT "Đừng nói với tôi về 10.0.0.0/8 vì tôi đã hỏi về không gian 192.168".
Mike Pennington

2
Tôi hoàn toàn tôn trọng bạn và tôi không muốn nói khác đi. Tuy nhiên, có vẻ như trả lời một câu hỏi với 'Tôi không muốn trả lời câu hỏi như bây giờ, vì vậy đây là câu trả lời cho một câu hỏi rất liên quan' không hoàn toàn đúng. Tôi đang tìm kiếm nhiều hơn cho động lực đằng sau nó, không nhất thiết là lịch sử. Cảm ơn vì đã cởi mở để thảo luận!
Hoàn tác

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.