มันถูกต้องหรือไม่ที่จะมีส่วนของที่อยู่ IPv4 ตั้งค่าเป็นศูนย์


36

ฉันกำลังทำงานเกี่ยวกับการเปลี่ยนแปลงในโปรแกรม Java EE ที่จะรับรองความถูกต้องตามที่อยู่ IP ของผู้ใช้โดยใช้ServletRequest.getRemoteAddr เราจัดเก็บช่วงที่อยู่ IP (FROM_IP และ TO_IP) ในฐานข้อมูลและระบบจะตรวจสอบความถูกต้องเฉพาะเมื่อที่อยู่ IP ของผู้ใช้อยู่ในช่วง

ตอนนี้ผู้ทดสอบได้ชี้ให้เห็นว่าไม่อนุญาตให้ใช้ตัวเลข 0 (ศูนย์) ในค่า FROM_IP และ TO_IP (ไม่ว่าที่ใด) โปรดทราบว่านี่เป็นแอปพลิเคชั่นที่เชื่อมต่ออินเทอร์เน็ตดังนั้นเราจะได้รับที่อยู่ IP สาธารณะเท่านั้น

ผู้ทดสอบถูกต้องหรือไม่ในการแนะนำการตรวจสอบความถูกต้องนั้น? เหตุใดเราจึงไม่มีศูนย์ในค่าของช่วงเช่นใน 167.23.0.1 - 167.23.255.255


11
และนี่คือลิงก์บังคับสำหรับSubnetting ทำงานอย่างไร คำถาม.

8
ฉันคิดว่ามันน่าประหลาดใจที่ผู้ทดสอบของคุณนำเรื่องนี้มาใช้เมื่อที่อยู่ IPv6 สามารถมีจำนวน 0 โหล PS คุณควรทำให้ฟิลด์ที่อยู่ IP ของคุณพอดีกับที่อยู่ IPv6 หากยังไม่สาย คุณจะไม่ต้องปวดหัวในอนาคต
Mark Henderson

2
127.0.0.1 มีสองศูนย์
John Smith

1
โดยวิธีการที่อยู่ IP ของฉันเองปรากฏบนwhatismyipaddress.comมี 0 ในนั้น (67.xx.0.xx)
Ritesh

1
คำถามที่คล้ายกันที่นี่: XYZ0 เป็นที่อยู่ IP ที่ถูกต้องหรือไม่
splattne

คำตอบ:


70

ไม่พวกเขาไม่ถูกต้องสมบูรณ์

อันที่จริงนี่คือที่อยู่ IP ที่ถูกต้อง: 192.168.24.0

167.23.0.1ในฐานะที่เป็น

การแยกที่อยู่ IP ออกเป็นส่วนประคือความสะดวกสบายของมนุษย์ในการแสดงผล มันง่ายมากที่จะจำได้มากกว่า192.168.1.423232235818

สิ่งที่สำคัญสำหรับคอมพิวเตอร์ก็คือการแยก (netmask) ไม่ถูกต้องที่จะมีที่อยู่โฮสต์ที่มีส่วนโฮสต์ของที่อยู่ที่ตั้งค่าเป็น 0 หรือ 1 ทั้งหมด

ดังนั้น 192.168.24.0 ตราบเท่าที่ netmask เป็นเช่นนั้นบางบิตได้รับการตั้งค่าในส่วนโฮสต์ ดูการคำนวณต่อไปนี้:


michael@challenger:~$ ipcalc 192.168.24.0/16
Address:   192.168.24.0         11000000.10101000. 00011000.00000000
Netmask:   255.255.0.0 = 16     11111111.11111111. 00000000.00000000
Wildcard:  0.0.255.255          00000000.00000000. 11111111.11111111
=>
Network:   192.168.0.0/16       11000000.10101000. 00000000.00000000
HostMin:   192.168.0.1          11000000.10101000. 00000000.00000001
HostMax:   192.168.255.254      11000000.10101000. 11111111.11111110
Broadcast: 192.168.255.255      11000000.10101000. 11111111.11111111
Hosts/Net: 65534                 Class C, Private Internet

ในกรณีนี้ส่วนที่อยู่ (ด้านขวา) มีการตั้งค่า 2 บิต นี่คือที่อยู่โฮสต์ที่ถูกต้องในเครือข่ายย่อย 192.168.0.0/16


michael@challenger:~$ ipcalc 192.168.24.255/16
Address:   192.168.24.255       11000000.10101000. 00011000.11111111
Netmask:   255.255.0.0 = 16     11111111.11111111. 00000000.00000000
Wildcard:  0.0.255.255          00000000.00000000. 11111111.11111111
=>
Network:   192.168.0.0/16       11000000.10101000. 00000000.00000000
HostMin:   192.168.0.1          11000000.10101000. 00000000.00000001
HostMax:   192.168.255.254      11000000.10101000. 11111111.11111110
Broadcast: 192.168.255.255      11000000.10101000. 11111111.11111111
Hosts/Net: 65534                 Class C, Private Internet

ในกรณีนี้ส่วนที่อยู่มีการตั้งค่า 10 บิตและไม่ได้ตั้งค่า 6 บิต นี่คือที่อยู่โฮสต์อื่นที่ถูกต้องในซับเน็ตเดียวกัน


michael@challenger:~$ ipcalc 192.168.24.0/24
Address:   192.168.24.0         11000000.10101000.00011000. 00000000
Netmask:   255.255.255.0 = 24   11111111.11111111.11111111. 00000000
Wildcard:  0.0.0.255            00000000.00000000.00000000. 11111111
=>
Network:   192.168.24.0/24      11000000.10101000.00011000. 00000000
HostMin:   192.168.24.1         11000000.10101000.00011000. 00000001
HostMax:   192.168.24.254       11000000.10101000.00011000. 11111110
Broadcast: 192.168.24.255       11000000.10101000.00011000. 11111111
Hosts/Net: 254                   Class C, Private Internet

ในกรณีนี้ส่วนที่อยู่มีการตั้งค่าเป็นศูนย์บิต นี่ไม่ใช่ที่อยู่โฮสต์ที่ถูกต้องในเครือข่าย 192.168.24.0/24


11
ฉันจะข้ามไปยังคำตอบนี้ซึ่งถูกต้องเพื่อเพิ่มจุดเพิ่มเติม: รูปแบบ "รูปสี่เหลี่ยมประ" สำหรับที่อยู่ IP ในขณะที่บัญญัติเป็นรูปแบบที่ไม่ได้เป็นตัวแทนเท่านั้น ลองใช้คำสั่งping 2130706432หรือping 017700000001(ใช่แม้กระทั่งบน Windows) คุณอาจรู้สึกประหลาดใจกับผลลัพธ์ที่ได้
BMDan


1
ในขณะที่สิ่งที่ถูกกล่าวถึงในที่นี้เป็นความจริง แต่ก็น่าเสียดายที่มีอินเทอร์เฟซผู้ใช้จำนวนมากที่คิดว่าศูนย์ต่อท้าย (หรือ 255) ไม่ดีโดยไม่คำนึงถึงความยาวของคำนำหน้า
Theobroma Cacao

1
192.168.0.257ไม่ถูกต้อง แต่192.168.257เป็นตัวแทนที่ถูกต้องของ192.168.1.1(ตามที่เป็น192.11010305) inet_aton(3)ดู
BMDan

2
@Raffael: subnet zero เป็นโฮลด์จริง ๆ จากวันกำหนดเส้นทาง classfull เมื่อคุณมีเครือข่ายคลาส B (129.97.0.0/16) เครือข่ายศูนย์จะเป็นเครือข่ายใด ๆ ที่มีบิต 17 → X ตั้งค่าทั้งหมดเป็นศูนย์ (โดยที่ X คือความยาวของเครือข่ายย่อย) ดังนั้นเครือข่าย 129.97.0.0/24 จะเป็นเครือข่ายย่อยเป็นศูนย์และไม่อนุญาตในวันแรก ๆ ทุกวันนี้ (ขอบคุณ) เราใช้ CIDR และไม่ต้องกังวลกับมัน
MikeyB

16

ผู้ทดสอบของคุณจะผิดไปเว้นแต่ว่าฉันเข้าใจผิด ที่อยู่ IP ที่ถูกต้องสามารถมี 0 ในนั้น


12

โดยทั่วไป: ไม่มันไม่สำคัญว่ามี 0 ในที่อยู่หรือไม่

อย่างไรก็ตามมีความจริงในสิ่งที่ผู้ทดสอบพูด ในบางกรณีอุปกรณ์เครือข่ายเก่าหรือที่ชำรุดจะทำงานไม่ถูกต้องในที่อยู่ที่มี 0 ใน octests ล่าสุด นี่เป็นเพราะกฎการกำหนดเส้นทาง classfull แบบเก่า ในการกำหนดเส้นทาง Classfull คุณสามารถบอก netmask จาก octet แรกของที่อยู่ หากอุปกรณ์ยังคงปฏิบัติตามกฎการกำหนดเส้นทาง classfull มีแนวโน้มที่จะจัดการที่อยู่เช่น 200.100.1.0/16 อย่างไม่ถูกต้อง


3

สมมติว่าคุณต้องการที่อยู่ IP 510 รายการในช่วงเดียวและที่อยู่เครือข่ายของคุณคือ 192.1.1.0 คุณจะมีซับเน็ต / 23 ซึ่งหนึ่งในโฮสต์ IP ของคุณคือ IP แอดเดรส 0.0 ผู้ทดสอบของคุณผิดถ้าที่อยู่. 0 เป็นที่อยู่โฮสต์ หากคุณมีเครือข่าย / 24 มันจะถูกต้องที่จะบอกว่ามันผิด


2

เพื่อให้คำตอบที่ง่ายมาก: หนึ่งศูนย์หรือมากกว่านั้นในที่อยู่ IP นั้นใช้ได้อย่างสมบูรณ์แบบสำหรับที่อยู่โฮสต์ตราบใดที่ที่อยู่เหล่านั้นไม่ใช่เครือข่ายหรือที่อยู่ออกอากาศ

ที่อยู่เครือข่ายและการออกอากาศเป็นที่อยู่ IP ที่ถูกต้องพวกเขาไม่สามารถใช้งานได้โดยโฮสต์


1
สิ่งที่เกี่ยวกับที่อยู่การออกอากาศของ XY0.255?
Random832

2
คุณสามารถใช้ที่อยู่เครือข่ายสำหรับโฮสต์และการทำเช่นนั้นเคยเป็นการทดสอบทั่วไปของ "leetness" ถึงแม้ว่าโชคดีที่มันหลุดพ้นจากความนิยม ในหลอดเลือดดำที่คล้ายกัน RFC 3021 อนุญาตให้ใช้ทั้งที่อยู่ "ออกอากาศ" และ "เครือข่าย" ใน / 31 แม้ว่าเงื่อนไขจะค่อนข้างไม่เหมาะสมเมื่อคุณจัดการกับสองโฮสต์ที่จะเริ่มต้นด้วย
BMDan
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.