เหตุใดศูนย์ทั้งหมดในส่วนโฮสต์ของที่อยู่ IP จึงไม่สามารถใช้กับโฮสต์ได้

ฉันรู้ว่าถ้าฉันมีเครือข่าย83.23.159.0/24ฉันมีที่อยู่ IP ของโฮสต์ 254 ที่ใช้งานได้เพราะ:

83.23.159.0      (in binary: host portion all zeros) is the subnet address
83.23.159.1-254  are host addresses
83.23.159.255    (in binary: host portion all ones) is the broadcast address

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

เพื่อสรุปคำถามของฉันคือ:

1. ปลายทางของแพ็กเก็ต IP เคยตั้งค่าเป็นที่อยู่ IP เครือข่ายย่อยหรือไม่
2. ถ้าใช่ในกรณีใดและเพราะเหตุใด
3. ถ้าไม่เช่นนั้นทำไมไม่ทำให้ที่อยู่นั้นว่างสำหรับโฮสต์ที่จะใช้

ปลายทางของแพ็กเก็ต IP เคยตั้งค่าเป็นที่อยู่ IP เครือข่ายย่อยหรือไม่

ใช่. เป็น IP ที่ถูกต้องดังนั้นจึงสามารถใช้งานได้

ถ้าใช่ในกรณีใดและเพราะเหตุใด

เป็นเพียงหนึ่งใน 255 IP ที่สามารถใช้งานได้ใน / 24

ถ้าไม่เช่นนั้นทำไมไม่ทำให้ที่อยู่นั้นว่างสำหรับโฮสต์ที่จะใช้

หากคุณมีฮาร์ดแวร์โบราณแล้วคุณต้องตรวจสอบว่ามันใช้ที่อยู่แรกหรือที่อยู่สุดท้ายเป็นที่อยู่เครือข่าย (.0 หรือ. 255 สำหรับเครือข่ายที่มีหน้ากาก FF.FF.FF.00)

นี่เป็นนิสัยที่ดีที่จะข้าม IP นั้น และนิสัยที่เรียนรู้มานานแล้วนั้นยากที่จะเพิกเฉย

และคนที่ไม่ทราบพื้นหลังก็อย่าใช้ 'เพราะคนอื่นไม่ได้ใช้มันดังนั้นมันจะต้องผิดที่จะใช้มัน' หรือเพราะพวกเขาไม่รู้ว่า '0' อาจเป็นหมายเลขแรก

[แก้ไข] Grezzo เพิ่งทดสอบบน Windows XP ซึ่ง GUI ของเครือข่าย windows 'ช่วย' ป้องกันการตั้งค่านี้ Windows 7 มีพฤติกรรมเหมือนกัน ฉันลองบนโฮสต์ที่ไม่ใช่หน้าต่างซึ่งใช้งานได้ หากคุณใช้ windows คุณอาจต้องกำหนดค่าเครือข่ายด้วยตนเองผ่าน IPconfig เพื่อตั้งเป็นศูนย์ทั้งหมด

[แก้ไข 2]

ยิ่งฉันทำงานกับสิ่งนี้นานเท่าไหร่

Rfc4632 - การกำหนดเส้นทาง Inter-domain Classless ดูเหมือนจะไม่ห้าม แต่ก็ไม่อนุญาตอย่างชัดเจน

การโพสต์ ServerFault นี้กล่าวถึง: "ด้วยเหตุผลทางประวัติศาสตร์ OS หลายแห่งถือว่าที่อยู่แรกเป็นรายการออกอากาศตัวอย่างเช่นส่ง Ping xxx0 จาก OS X, Linux และ Solaris บนเครือข่ายท้องถิ่นของฉัน (/ 24) ได้รับการตอบสนอง Windows ไม่อนุญาตให้คุณส่ง Ping ที่อยู่แรกเป็นค่าเริ่มต้น แต่คุณอาจเปิดใช้งานได้โดยใช้วิธี SetIPUseZeroBroadcast WMI ฉันสงสัยว่าคุณสามารถใช้. 0 เป็นที่อยู่โฮสต์ในเครือข่าย Windows ทั้งหมดได้หรือไม่ " .

มันเป็นคำถามเดียวกัน แต่ไม่ใช่คำตอบ

ที่อยู่เครือข่ายยังใช้ในตารางเส้นทาง แต่ฉันล้มเหลวที่จะดูว่าทำไมมันจะไม่ทำงานเนื่องจาก สัญกรณ์เดียวกันในตารางเส้นทางจะเส้นทางไปยังเครือข่ายที่เหมาะสม เมื่ออยู่บนเครือข่ายที่ถูกต้องมันจะมาถึงพีซีที่มี IP 0

(ทั้งหมดนี้สำหรับ 192.168.1 / 24
หากคุณใช้ 192.168.0 / 23 ดังนั้น 192.168.1.0 จะเป็นค่าที่ถูกต้องและปลอดภัยในช่วงกลางของช่วง)

[แก้ไข 3]

อีกหนึ่งลิงก์ไปยังคำถามเดียวกัน ดูเหมือนว่าค่อนข้างเป็นที่นิยมในการแลกเปลี่ยนสแต็ก:

/superuser/379451/why-can-a-network-address-not-be-a-valid-host-address

และหนึ่งความคิด:

Destination_IP น่าจะเป็นAND ed กับเสาเครือข่าย (การดำเนินการอย่างรวดเร็วในฮาร์ดแวร์) ก่อนที่จะถูกเปรียบเทียบกับรายการในตารางเส้นทาง แต่:

(IP แบบกึ่งสุ่ม) 192.168.0.42 และ 255.255.255.0 จะให้ผล 192.168.0.0
แต่ 192.168.0.0 และ 255.255.255.0 ก็จะได้ 192.168.0.0 เช่นกัน

[แก้ไข 4 - อีกไม่นานหลังจากเขียนคำตอบนี้ - ฉันอาจต้องเขียนโพสต์ใหม่ทั้งหมดเนื่องจากข้อมูลใหม่นี้ ]

RFC923ระบุในหน้า 3 ว่า:

  In certain contexts, it is useful to have fixed addresses with
  functional significance rather than as identifiers of specific
  hosts.  When such usage is called for, the address zero is to be
  interpreted as meaning "this", as in "this network".  The address
  of all ones are to be interpreted as meaning "all", as in "all
  hosts".  For example, the address 128.9.255.255 could be
  interpreted as meaning all hosts on the network 128.9.  Or, the
  address 0.0.0.37 could be interpreted as meaning host 37 on this
  network.

อ้างถึง@ylearnในเว็บไซต์ของเรา

ฉันเชื่อว่าเอกสารแรกของที่มาจากRFC950ซึ่งอ้างอิงRFC943 (ซึ่งล้าสมัยRFC923ข้างต้น แต่ใช้ภาษาเดียวกันสำหรับที่อยู่พิเศษ):

     It is useful to preserve and extend the interpretation of these
     special addresses in subnetted networks.  This means the values
     of all zeros and all ones in the subnet field should not be
     assigned to actual (physical) subnets.

ที่อยู่ที่มีส่วนโฮสต์ทั้งหมดเป็นศูนย์หมายถึงเครือข่ายเองแทนที่จะเป็นโฮสต์ใด ๆ

ในอดีตที่อยู่โฮสต์นี้เป็นศูนย์ได้ทำหน้าที่เป็นที่อยู่ออกอากาศทางเลือกและอุปกรณ์ยังคงตอบสนองต่อวิธีการที่

ดังนั้นฉันต้องไม่เห็นด้วยกับคำตอบอื่น ๆ : ไม่ศูนย์ไม่ใช่ที่อยู่โฮสต์ที่ใช้งานได้อย่างสมบูรณ์ หากคุณต้องการที่อยู่มากกว่า 254 แห่งคุณจะต้องสร้างซับเน็ตที่ใหญ่ขึ้น

ดูเราเตอร์ Linksys ของฉันที่มีอยู่คือ.1ตอบสนองต่อการส่ง Ping .0ของ (netmask คือ255.255.255.0ดังนั้น octet ล่าสุดที่สอดคล้องกับหมายเลขโฮสต์)

webserver:~# ping  192.168.1.0
Do you want to ping broadcast? Then -b
webserver:~# ping -b 192.168.1.0
WARNING: pinging broadcast address
PING 192.168.1.0 (192.168.1.0) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.46 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.812 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.819 ms

หากฉันกำหนดที่.0อยู่ให้กับโฮสต์บางแห่งฉันจะไม่สามารถ ping ได้โดยไม่ต้องมีเราเตอร์กำลังจัดการกับคำตอบของมัน และอย่างที่คุณเห็นเครื่องมือบางอย่างเช่นเวอร์ชันการpingรักษาของเราเตอร์0เป็นการออกอากาศ

คุณสามารถโค้งงอกฎถ้าคุณยินดีที่จะแก้ไขโปรโตคอลสแต็คทั้งหมดและซอฟต์แวร์อื่น ๆ ที่ได้รับผลกระทบจากการโค้งดังกล่าว มิฉะนั้นยึดกฎ

กรณีในจุด

ฉันทำงานที่ บริษัท หนึ่งซึ่งออกแบบโหนดเครือข่ายที่สร้างขึ้นใน 14 แชสซีของสล็อตซึ่งใช้อิมเมจระบบปฏิบัติการอิสระจำนวนมากบนการ์ดหลายประเภทการสื่อสารทั้งหมดผ่านแบ็คเพลน มีการติดตั้งระบบเครือข่ายบน backplane ด้วยการประชุมที่127.X.0.Yเป็นที่อยู่ IP ภายในของโหนด Y ในช่อง X ซึ่งมีหมายเลขทั้งหมดตั้งแต่ 1

โดยทั่วไปเราจะทำการวนลูปที่อยู่ย้อนกลับเพื่อวัตถุประสงค์ของเราเอง เพื่อให้มันใช้งานได้เราต้องแก้ไขเคอร์เนลลินุกซ์ที่นี่และที่นั่นและ IIRC ซึ่งเป็นพื้นที่ผู้ใช้เล็กน้อย

เนื่องจากเครือข่ายนั้นใช้เฉพาะภายในกล่องและโปรแกรมส่วนใหญ่ที่ต้องการวนรอบใช้127.0.*เครือข่าย (และในความเป็นจริงที่อยู่เฉพาะ127.0.0.1) ซึ่งยังคงทำงานตามปกติทุกอย่างก็เจ๋ง

ที่จริงแล้วมันขึ้นอยู่กับ netmask ตัวอย่างเช่นสำหรับเครือข่าย 83.23.159.0/23, 83.23.159.0 เป็นที่อยู่ IP ที่ใช้งานได้อย่างสมบูรณ์แบบ

ดูเหมือนจะมีความสับสนเล็กน้อยที่นี่กับเครือข่ายพื้นฐาน

'ฮาร์ดแวร์โบราณ' ที่อ้างถึงในการตอบสนองอย่างใดอย่างหนึ่งจะไม่ใช้ IP Subnet Zero - การใช้ที่อยู่ ip xxx0 กับการตั้งค่าเครือข่ายสำหรับ / 24 CIDR หรือ 255.255.255.0 subnet mask เป็นปัญหาที่แตกต่างอย่างสิ้นเชิง

IP Subnet Zero

• ฮาร์ดแวร์ที่เก่ากว่าจะไม่ใช้ IP Subnet Zero - หมายถึงพวกเขาจะไม่ใช้ซับเน็ตแรกในระบบเครือข่ายหลายเครือข่ายย่อย ดังนั้นในเครือข่าย a / 23 หรือ 255.255.254.0 ซับเน็ต XXX0 และที่อยู่ทั้งหมดจะไม่ถูกใช้ เราเตอร์ที่ทันสมัยไม่มีข้อ จำกัด นี้ แต่สามารถกำหนดค่าให้ใช้รุ่นเก่านี้ได้ IE ไม่ใช้ซับเน็ตศูนย์ถ้าต้องการ

IP แอดเดรสของโฮสต์ที่ใช้งานได้บนซับเน็ต

• เครือข่ายพื้นฐาน:
  • ด้วย / 24 ie subnet mask จำนวน 255.255.255.0
  • xxx0 ถูกสงวนไว้เป็นที่อยู่เครือข่าย เราเตอร์และโปรโตคอลการเราต์ (EIGRP, RIP2 ฯลฯ ) ใช้ที่อยู่เครือข่ายเพื่อกำหนดกลุ่มเครือข่ายสำหรับการย้ายแพ็กเก็ตภายในและข้ามขอบเขตเครือข่ายเครือข่าย
  • xxx255 สงวนไว้สำหรับการออกอากาศที่อยู่
  • เป็นวิธีปฏิบัติทั่วไปในการใช้ที่อยู่ 0.1 หรือ. 254 บนเราเตอร์เพื่อให้มีหมายเลข IP ที่ใช้งานได้ 253 รายการ

ทั้งที่อยู่เครือข่ายและที่อยู่การออกอากาศถูกสงวนไว้และไม่สามารถกำหนด (ตามมาตรฐานเครือข่ายปัจจุบันและก่อนหน้านี้) ให้กับอุปกรณ์ได้ การใช้ xxx0 สำหรับที่อยู่โฮสต์ในระบบ / 24 นั้นไม่ถูกต้อง แม้ว่า Linux จะให้คุณใช้มันไม่ได้หมายความว่ามันถูกต้อง แต่ก็หมายความว่า Linux คิดว่าคุณรู้ว่าคุณกำลังทำอะไรอยู่

หากระบบของคุณอนุญาตให้คุณกำหนด xxx0 เป็นที่อยู่ IP4 ให้กับโฮสต์และดูเหมือนว่าจะใช้งานได้ - โอกาสที่โฮสต์นั้นจะได้รับการรับส่งข้อมูลทั้งหมดที่กำหนดเป้าหมายไปยังอุปกรณ์ใด ๆ ในเครือข่ายนั้น

RFC 1122 ("ข้อกำหนดสำหรับโฮสต์อินเทอร์เน็ต - ชั้นการสื่อสาร") ห้าม:

ที่อยู่ IP ไม่ได้รับอนุญาตให้มีค่า 0 หรือ -1 สำหรับฟิลด์ <Host-number>, <Network-number> หรือ <Subnet- number> ใด ๆ

จริงๆแล้วคำตอบนั้นเป็นพื้นฐานของซับเน็ตติ้ง IP "ศูนย์ทั้งหมด" ของเครือข่ายย่อยของคุณรวมกับรหัสเครือข่ายจะใช้ในการคำนวณว่าจะส่งแพ็คเก็ตไปที่ใด

ในตัวอย่างของคุณคุณมีซับเน็ต 255.255.255.0 อุปกรณ์ใด ๆ ที่รู้ว่าโปรโตคอล TCP / IP จะใช้ netmask รวมกับที่อยู่ IP เพื่อคำนวณว่าแพ็คเก็ตนั้นถูกกำหนดไว้สำหรับเครือข่ายท้องถิ่น (โดยดำเนินการทางตรรกะและการดำเนินการ) หรือต้องส่งผ่านเกตเวย์ / เราเตอร์

ดังนั้นฉันคิดว่าเหตุผลที่ IP ไม่สามารถใช้ได้ก็เพราะมันถูกใช้เพื่อ "กำหนด" ขอบเขตของเครือข่ายร่วมกับ netmask โดยการออกแบบ

มีการร้องขอให้ฉันโพสต์คำตอบของฉันใหม่จากNetworkEngineeringดังนั้นฉันจะทำเช่นนั้นกับการปรับเปลี่ยนบางอย่างสำหรับเว็บไซต์นี้

ในRFC919จะทำการอ้างอิงการยอมรับทั่วไปของที่อยู่เครือข่าย:

However, as a notational convention, we refer to
networks (as opposed to hosts) by using addresses with zero fields.
For example, 36.0.0.0 means "network number 36"

นี่เป็นข้อตกลงที่ควรทำความเข้าใจให้ชัดเจนหากมีใครพูดถึง "10.1.2.0" เป็นเครือข่ายไม่ใช่โฮสต์บนเครือข่าย

จากนั้นการใช้ "0" ในที่อยู่ IP ถูกกำหนดในRFC923และดำเนินการต่อใน RFC ต่อเนื่อง:

Special Addresses:

  In certain contexts, it is useful to have fixed addresses with
  functional significance rather than as identifiers of specific
  hosts.  When such usage is called for, the address zero is to be
  interpreted as meaning "this", as in "this network".  The address
  of all ones are to be interpreted as meaning "all", as in "all
  hosts".  For example, the address 128.9.255.255 could be
  interpreted as meaning all hosts on the network 128.9.  Or, the
  address 0.0.0.37 could be interpreted as meaning host 37 on this
  network.

ตัวอย่างนี้จัดเตรียมสำหรับโฮสต์ที่เฉพาะเจาะจงบนเครือข่ายปัจจุบัน (0.0.0.37) โดยใช้ 0 ในส่วนเครือข่ายของที่อยู่ แต่จริง ๆ แล้วไม่ได้ชี้แจงกรณีตรงข้าม (0 ในส่วนโฮสต์ของที่อยู่) อย่างไรก็ตามเนื่องจากมันกำหนด "0" เป็น "นี่"

ในRFC1060ที่อยู่ "0.0.0.0" ได้รับการบันทึกไว้อย่างชัดเจนว่า "โฮสต์นี้ในเครือข่ายนี้":

     (a)   {0, 0}

        This host on this network.  Can only be used as a source
        address (see note later).

เนื่องจากศูนย์ทั้งหมดสำหรับส่วนโฮสต์ของที่อยู่หมายถึง "โฮสต์นี้" จึงมีเหตุผลดังนี้ว่าไม่สามารถใช้เป็นที่อยู่โฮสต์ได้

กลับไปที่ตอบคำถามของคุณโดยตรง:

1. ปลายทางของแพ็กเก็ต IP เคยตั้งค่าเป็นที่อยู่ IP เครือข่ายย่อยหรือไม่
2. ถ้าใช่ในกรณีใดและเพราะเหตุใด
3. ถ้าไม่เช่นนั้นทำไมไม่ทำให้ที่อยู่นั้นว่างสำหรับโฮสต์ที่จะใช้

ตามสิ่งที่ฉันพบใน RFCs สิ่งนี้ไม่ควรใช้ ฉันจะยอมรับว่ามันไม่ได้ระบุไว้อย่างชัดเจนเหมือนที่ฉันต้องการ แต่นั่นคือทั้งหมดที่พบได้ทั่วไปในหลายมาตรฐาน เมื่อมาตรฐานมีความมั่นคงน้อยกว่าในจุดหนึ่งอุตสาหกรรมก็ดูเหมือนจะ "ตัดสิน" ในการตีความที่เป็นที่ยอมรับโดยทั่วไป

เพิ่มเติมตามเนื้อหาของซอฟต์แวร์ RFCs อาจถูกเขียนขึ้นเพื่อสมมติว่าที่อยู่นี้ใช้เพื่อระบุที่อยู่เครือข่ายไม่ใช่โฮสต์เฉพาะ หรือมากกว่านั้นอย่างแท้จริงว่าเป็น "loopback" บางประเภท (เช่นโฮสต์นี้ในเครือข่ายที่ระบุ)

เหตุใดระบบปฏิบัติการบางระบบจึงอนุญาตให้ใช้อย่างชัดเจน ฉันคิดว่าหลายสิ่งหลายอย่างที่เกี่ยวกับเวลาของนักพัฒนาหรือไม่มีใครคิดที่จะเพิ่มการตรวจสอบความถูกต้อง ตรรกะต้องเกี่ยวข้องมากกว่า "ถ้าลงท้ายด้วย 0" เป็นซับเน็ตขนาดใหญ่ (a / 23 หรือใหญ่กว่า) จะมีที่อยู่ IP ที่ถูกต้องเป็น. 255 และ. 0 (เช่น 10.1.2.0/23 มีทั้ง IP ที่ถูกต้อง ที่อยู่ของ 10.1.2.255 และ 10.1.3.0) แม้ว่าบางองค์กรจะหลีกเลี่ยงการใช้ที่อยู่ที่ถูกต้องในซับเน็ตขนาดใหญ่เพื่อหลีกเลี่ยงปัญหาแปลก ๆ กับซอฟต์แวร์ที่ไม่รองรับซับเน็ตติ้งที่ทันสมัยอย่างถูกต้อง

ทำไมไม่เพิ่มที่อยู่ IP เพียงอันเดียวมันก็ลงมาที่ราคา / ผลประโยชน์ ต้องใช้เวลาและความพยายามอย่างมากในการเปลี่ยนแปลงเพื่อรับที่อยู่ IP หนึ่งรายการต่อซับเน็ตและในกรณีที่คุณต้องการที่อยู่ IP เพิ่มเติมจะมีที่อยู่เพียงแห่งเดียวเพียงพอหรือไม่ มันง่ายกว่ามากในการเพิ่มซับเน็ตที่สองหรือขยายซับเน็ตปัจจุบันอาจให้ที่อยู่มากมายให้คุณใช้แทนเพียงอันเดียวในขณะที่ไม่มีการเปลี่ยนแปลงที่สำคัญในซอฟต์แวร์ / ฮาร์ดแวร์ใด ๆ