Giao thức IP

(Internet Protocol - Giao thức Liên mạng) là một giao thức hướng dữ liệu được sử dụng bởi các máy chủ nguồn và đích để truyền dữ liệu trong một liên mạng chuyển mạch gói.

Dữ liệu trong một liên mạng IP được gửi theo các khối được gọi là các gói (packet hoặc datagram). Cụ thể, IP không cần thiết lập các đường truyền trước khi một máy chủ gửi các gói tin cho một máy khác mà trước đó nó chưa từng liên lạc với.

Giao thức IP cung cấp một dịch vụ gửi dữ liệu không đảm bảo (còn gọi là cố gắng cao nhất), nghĩa là nó hầu như không đảm bảo gì về gói dữ liệu. Gói dữ liệu có thể đến nơi mà không còn nguyên vẹn, nó có thể đến không theo thứ tự (so với các gói khác được gửi giữa hai máy nguồn và đích đó), nó có thể bị trùng lặp hoặc bị mất hoàn toàn. Nếu một phần mềm ứng dụng cần được bảo đảm, nó có thể được cung cấp từ nơi khác, thường từ các giao thức giao vận nằm phía trên IP.

Các thiết bị định tuyến liên mạng chuyển tiếp các gói tin IP qua các mạng tầng liên kết dữ liệu được kết nối với nhau. Việc không có đảm bảo về gửi dữ liệu có nghĩa rằng các chuyển mạch gói có thiết kế đơn giản hơn. (Lưu ý rằng nếu mạng bỏ gói tin, làm đổi thứ tự hoặc làm hỏng nhiều gói tin, người dùng sẽ thấy hoạt động mạng trở nên kém đi. Hầu hết các thành phần của mạng đều cố gắng tránh để xảy ra tình trạng đó. Đó là lý do giao thức này còn được gọi là cố gắng cao nhất. Tuy nhiên, khi lỗi xảy ra không thường xuyên sẽ không có hiệu quả đủ xấu đến mức người dùng nhận thấy được.)

Giao thức IP rất thông dụng trong mạng Internet công cộng ngày nay. Giao thức tầng mạng thông dụng nhất ngày nay là IPv4; phiên bản từ 0 đến 3 hoặc bị hạn chế, hoặc không được sử dụng. Phiên bản 5 được dùng làm giao thức dòng (stream) thử nghiệm. Còn có các phiên bản khác, nhưng chúng thường dành là các giao thức thử nghiệm và không được sử dụng rộng rãi.

Kề từ khi chính thức đựơc đưa vào sử dụng và được định nghĩa trong kiến nghị RFC791 năm 1981 đến nay, cho tới bây giờ phiên bản này vẫn đang được sử dụng rộng rãi và cũng đã góp phần tạo ra sự phát triển bùng nổ của các mạng máy tính.

Network Information Center (NIC)

Định tuyến và địa chỉ IP

Có lẽ các khía cạnh phức tạp nhất của IP là việc đánh địa chỉ và định tuyến. Đánh địa chỉ là công việc cấp địa chỉ IP cho các máy đầu cuối, cùng với việc phân chia và lập nhóm các mạng con của các địa chỉ IP. Việc định tuyến IP được thực hiện bởi tất cả các máy chủ, nhưng đóng vai trò quan trọng nhất là các thiết bị định tuyến liên mạng. Các thiết bị đó thường sử dụng các giao thức cổng trong (interior gateway protocol, viết tắt là IGP) hoặc các giao thức cổng ngoài (external gateway protocol, viết tắt là EGP) để hỗ trợ việc đưa ra các quyết định chuyển tiếp các gói tin IP (IP datagram) qua các mạng kết nối với nhau bằng giao thức IP. Giao thức này hiện nay là rất phổ biến: internet protocol, song hành với PCI, hiện nay ở Việt Nam có công ty Ebiz đang rất thành công trong lĩnh vực này cùng với sự liên kết với tập đoàn FPT.

Nói thêm về Router, hay thiết bị định tuyến hoặc bộ định tuyến, là một thiết bị mạng máy tính dùng để chuyển các gói dữ liệu qua một liên mạng và đến các đầu cuối, thông qua một tiến trình được gọi là định tuyến. Định tuyến xảy ra ở tầng 3 tầng mạng của mô hình OSI 7 tầng.

Router dùng để làm gì : Theo cách nói thông thường, một router hoạt động như một liên kết giữa hai hoặc nhiều mạng và chuyển các gói dữ liệu giữa chúng. Router đưa vào bảng định tuyến (routing table) để tìm đường đi cho gói dữ liệu. Bảng định tuyến được quản trị mạng cấu hình tĩnh (static), nghĩa là được thiết lập 1 lần và thường do quản trị mạng nhập bằng tay, hoặc động (dynamic), nghĩa là bảng tự học đường đi và nội dung tự động thay đổi theo sự thay đổi của tô pô mạng. Một cách giúp xây dựng bảng định tuyến là theo hướng dẫn của CCNA.

Router không phải một thiết bị chuyển mạch (network switch).

Các lớp giao thức định tuyến :Dựa vào quan hệ của các dòng router với các hệ thống tự trị, có nhiều lớp giao thức định tuyến như sau:

Giao thức định tuyến trong mạng Ad-hoc xuất hiện ở những mạng không có hoặc ít phương tiện truyền dẫn.

Interior Gateway Protocols (IGPs) trao đổi thông tin định tuyến trong một AS. Các ví dụ thường thấy là:

o IGRP (Interior Gateway Routing Protocol) o EIGRP (Enhanced Interior Gateway Routing Protocol) o OSPF (Open Shortest Path First) o RIP (Routing Information Protocol) o IS-IS (Intermediate System to Intermediate System)

Chú ý: theo nhiều tài liệu của Cisco, EIGRP không phân lớp như giao thức trạng thái kết nối.

Exterior Gateway Protocols (EGPs) định tuyến giữa các AS. EGPs gồm: o EGP (giao thức cũ để nối mạng Internet trước đây, bây giờ đã lỗi thời) o BGP (Border Gateway Protocol: phiên bản hiện tại, BGPv4, có từ khoảng năm

1995)

Cấu trúc IPv4

IPv4 là địa chỉ IP dùng 32 bit chia thành 4 octet, mỗi octet có 8 bit tương đương với 1 byte. Mỗi octet được cách nhau bởi dấu "." và các bit được đánh dấu từ trái sang phải. IPv4 có 3 thành phần chính:

Class bit Net ID Host ID Bit 1..........................32 Trong đó: Class bit là bit nhận dạng lớp Net ID là địa chỉ mạng Host ID là địa chỉ máy chủ

Trong thực tế 32 bit này sẽ được biểu diễn bằng hệ thập phân để thuận tiện khi sử dụng.

+ Class ID

Là những bit nhận dạng lớp. Trong IPv4 có 5 lớp: A,B,C,D,E (D,E chỉ dùng để nghiên cứu) Trong mỗi lớp người ta lấy số bit đánh dấu khác nhau. Ví dụ: Lớp A người ta lấy 1 bit đầu là 0, lớp B lấy 2 bit đầu là 10 và lớp C là 110 để đánh dấu lớp. Tất cả những bit này đều nằm trong octet 1.

+ Net ID

Gồm các bit trong 1 hoặc nhiều octet tùy thuộc vào các lớp khác nhau để mã hóa địa chỉ.

Trong lớp A: Người ta lấy các bit trong octet 1(trừ đi Class bit) để mã hoá Net ID => trong Class A chúng ta có 7 bit để mã hoá Net ID, tức là mã hoá được 27=128 địa chỉ mạng.

Trong lớp B: Người ta lấy các bit trong 2 octet 1 và 2(trừ Class bit) để mã hóa Net ID tức là có 14 bit mã hóa được 214=16384 địa chỉ mạng.

Trong lớp C: tương tự Class A và B chỉ khác người ta lấy các bit trong 3 octet 1,2,3 để mã hóa mà thôi.

+ Host ID

Tương ứng với mỗi lớp mà người ta lấy tất cả các bit còn lại để mã hóa Host ID.

Ví dụ:

Class A có 24 bit đễ mã hóa Host ID (mã hóa được 224=16777216 địa chỉ. Class B có 16 bit Class C có 8 bit

Như vậy, mỗi class có số lượng mạng và máy chủ thay đổi ít nhiều khác nhau tùy nhu cầu sử dụng mà phân chia. Để tránh tình trạng lãng phí do sự mất cân đối này người ta cho ra đời khái niệm Subnet Mask để giải quyết tình trạng trên.

Không gian địa chỉ IPv4

Với 32 bit, địa chỉ IPv4 có thể tạo nên 232 con số định danh thiết bị. Tuy nhiên theo phương thức truyền tải thông tin theo giao thức Internet, không phải toàn bộ số đó được dùng để đánh số thiết bị mạng. Hơn nữa, địa chỉ IPv4 được thiết kế vào thời điểm số lượng thiết bị ít, vấn đề tiết kiệm không gian địa chỉ chưa được quan tâm. Ví dụ chỉ với mục đích cho chức năng loopback đã phải dung vùng địa chỉ 127.0.0.0/8.

Đối diện với thực trạng lượng địa chỉ IP tăng với tốc độ chóng mặt, người ta đã quy định trong không gian địa chỉ IPv4 một số vùng địa chỉ private với mục đích kết nối trong phạm vi nội bộ của 1 tổ chức ( site ) mà không định tuyến ra mạng toàn cầu. Như vậy các vùng địa chỉ này có thể được dùng trùng lặp ở nhiều mạng mà không gây ra hiện tượng xung đột định tuyến toàn cầu.

Hiện nay những vùng địa chỉ sau đây được quy định là địa chỉ private:_ 10.0.0.0/8

_ 172.16.0.0/12

_ 192.168.0.0/16

Việc sử dụng những vùng địa chỉ này nảy sinh nhu cầu kết nối những mạng địa chỉ

private với mạng toàn cầu. Công nghệ biên dịch địa chỉ NAT ( Network Address

Transmission ) của IPv4 được thiết kế để khắc phục vấn đề này. Tuy tiết kiệm

không gian địa chỉ IPv4 nhưng mô hình NAT cũng có những nhược điểm lớn.

Đặc biệt là khó thực hiện kết nối điểm – điểm và gây trễ, ảnh hưởng nhiều đến

nhiều dạng dịch vụ ( mạng riêng ảo – VPN, dịch vụ thời gian thực . Làm khó khăn

và ảnh hưởng tới nhiều dạng dịch vụ (VPN, dịch vụ thời gian thực). Thậm chí đối với

nhiều dạng dịch vụ cần xác thực port nguồn/ đích, sử dụng NAT là không thể được.

Trong khi đó, các ứng dụng mới hiện nay, đặc biệt các ứng dụng client-server ngày càng

đòi hỏi kết nối trực tiếp end-to-end. Bên cạnh đó việc gói tin không được giữ nguyên

tình trạng từ nguồn tới đích và bị can thiệp trong quá trình truyền tải dẫn đến tồn

tại lỗ hổng bảo mật.

Các hạn chế hiện tại của IPv4

Tuy nhiên đến thời điểm hiện tại, chính việc phát triển ồ ạt các ứng dụng và công nghệ cũng như các thiết bị di động khác đã làm bộc lộ những yếu điểm của IPv4:

- Thiếu địa chỉ IP Theo tính toán, sớm thì 2008, muộn nhất là 2011, thế giới sẽ hết địa chỉ Internet IPv4 và không thể cấp phát mới. Một trong những nguyên nhân dẫn tới việc IPv4 có thể cạn kiệt nhanh hơn hiện nay đó là các nước có xu hướng xin nhiều địa chỉ lên và tích trữ; Tình hình thuê bao Internet băng rộng bùng nổ như ADSL, kết nối Internet qua truyền hình cáp (cable TV) ..., những dạng thức kết nối này đòi hỏi tỉ lệ 1IP/1 người sử dụng; Rồi yêu cầu xin cấp địa chỉ IPv4 cho dịch vụ di động (3G) đã xuất hiện...

Trong những năm 1990, CIDR được xây dựng dựa trên khái niệm mặt nạ địa chỉ (address mask). CIDR đã tạm thời khắc phục được những vấn đề nêu trên. Khía cạnh tổ chức mang tính thứ bậc của CIDR đã cải tiến khả năng mở rộng của IPv4. Mặc dù có thêm nhiều công cụ khác ra đời như kỹ thuật subnetting (1985), kỹ thuật VLSM (1987) và CIDR (1993), các kỹ thuật trên đã không cứu vớt IPv4 ra khỏi một vấn đề

đơn giản: không có đủ địa chỉ cho các nhu cầu tương lai. Có khoảng 4 tỉ địa chỉ IPv4 nhưng khoảng địa chỉ này là sẽ không đủ trong tương lai với những thiết bị kết nối vào Internet và các thiết bị ứng dụng trong gia đình có thể yêu cầu địa chỉ IP. Do đó, một vài giải pháp tạm thời, chẳng hạn như dùng RFC1918 trong đó dùng một phần không gian địa chỉ làm các địa chỉ dành riêng và NAT là một công cụ cho phép hàng ngàn host truy cập vào Internet chỉ với một vài IP hợp lệ để tận dụng tốt hơn không gian địa chỉ của IPv4. Đại diện của Trung Tâm Internet Việt Nam (VNNIC) cho biết, đến thời điểm này, Việt Nam chưa sử dụng nhiều tài nguyên Internet và cũng chưa có nguy cơ quá tải. Tuy nhiên việc cạn kiệt IPv4 trên thế giới sẽ ít nhiều gây ảnh hưởng đến Việt Nam.Vị đại diện này cho biết thêm, hiện VNNIC đang thử nghiệm cung cấp địa chỉ IPv6. Tập đoàn Bưu chính Viễn thông Việt Nam (VNPT) là đơn vị duy nhất hiện đang thực hiện triển khai thử nghiệm IPv6 tại Việt Nam.

- Quá nhiều các rounting entry (bản ghi định tuyến) trên các backbone

router : Với tình hình hiện tại, do không có sự phân cấp địa chỉ IPv4 nên số lượng các

rounting entry trở nên rất lớn, lên tới 110.000 bản ghi. Mỗi router phải duy trì bảng

thông tin định tuyến lớn, đòi hỏi router phải có dung lượng bộ nhớ lớn. IPv4 cũng yêu

cầu router phải can thiệp xử lý nhiều đối với gói tin IPv4, ví dụ thực hiện phân mảnh, điều này

tiêu tốn CPU của router và ảnh hưởng đến hiệu quả xử lý (gây trễ, hỏng gói tin)(Việc này làm

chậm quá trình xử lý của router, làm giảm tốc độ của mạng)

- Hạn chế về tính bảo mật và kết nối đầu cuối – đầu cuối.Trong cấu trúc thiết kế của IPv4 không có cách thức bảo mật nào đi kèm, IPv4 không cung cấp các phương tiện hỗ trợ mã hóa dữ liệu. Kết quả là bảo mật ở mức ứng dụng được dùng phổ biến nhưng không bảo mật lưu lượng truyền tải giữa các máy. Với IPv4, đã có nhiều giải pháp khắc phục nhược điểm này như IPSec, DES, 3DES… nhưng các giải pháp này đều phải cài đặt thêm và có nhiều phương thức khác nhau đối với mỗi loại sản phảm chứ không được hỗ trợ ở mức bản thân của giao thức.Nếu áp dụng IPSec ( IP Security – phương thức bảo mật phổ biến tại tầng IP ) thì mô hình bảo mật chủ yếu là bảo mật lưu lượng giữa các mạng, việc bảo mật lưu lượng đầu cuối – đầu cuối được sử dụng rất hạn chế.

Nói thêm về IPSec: IPSec là phương thức bảo mật phổ biến tại tầng IP, nó thực hiện chức năng xác thực nơi gửi và mã hóa đường kết nối, do vậy đảm bảo có kết nối bảo mật. IPSec có 2 phương thức làm việc: “phương thức đường hầm – tunnel mode” và “phương thức truyền tải – transport mode”. Tunnel mode áp dụng IPSec bằng cách: thiết bị thực hiện IPSec ( firewall…) sẽ thêm 1 Header mới và lấy toàn bộ gói tin IP trước kia làm phần dữ liệu ( payload ). Chế độ này thường được sử dụng trong VPN sử dụng 2 thiết bị thực hiện bảo mật giữa 2 mạng. Transport mode áp dụng IPSec cho truyền gói tin IP bởi host, được sử dụng trong bảo mật kết nối đầu cuối – đầu cuối giữa các node.- Nhu cầu về các ứng dụng thời gian thực hay vấn đề đảm bảo chất lượng dịch vụ QoS : Các thách thức mới từ việc nảy sinh các dịch vụ viễn thông, các yêu cầu truyền thời gian thực cho các dịch vụ multimedia, video, âm thanh qua mạng, sự phát triển của thương mại điện tử đã đặt ra việc đảm bảo QoS cho các ứng dụng này. QoS trong IPv4 cũng được xác định trong trường TOS và phần nhận dạng tải trọng của gói tin IP. Tuy nhiên trường TOS này có ít tính năng.

Nói thêm về QOS :Trong hoạt động mạng, chất lượng ( Quality ) tức là truyền tải dữ liệu tốt hơn bình

thường. Nó bao gồm: độ mất dữ liệu, trễ ( hay còn gọi độ dịch – jitter ), băng thông… Dịch vụ ( Service ) là

những gì cung cấp cho người sử dụng, có thể là kết nối đầu cuối – đầu cuối, các ứng dụng chủ - khách,

truyền tải dữ liệu… Như vậy, chất lượng dịch vụ QoS được nhắc đến là phương thức đo đạc cách thức cư

xử đáp ứng của mạng đối với lưu lượng. Thông tin để router thiết lập cách thức xử lý cụ thể đối với gói tin

có thể được chuyển tới bằng 1 thủ tục điều khiển hoặc bằng chính thông tin chứa trong gói tin.

Một cách lý thuyết, QoS được nhắc đến là phương thức đo đạc cách thức cư xử của mạng (của các router)

đối với lưu lượng, trong đó có để ý tới những đặc tính nhất định của những dịch vụ xác định. Thông tin để

router thiết lập cách thức cư xử cụ thể đối với gói tin có thể được chuyển tới bằng một thủ tục điều khiển,

hoặc bằng chính thông tin chứa trong gói tin.Có thể thấy đây là một định nghĩa không thật sự rõ ràng, khó

có thể phân định thật rạch ròi. Tuy nhiên, có một số khái niệm thông thường trong mọi định nghĩa về QoS.

Đó là:

-      Lưu lượng (traffic) và sự phân biệt về dạng thức dịch vụ

-     Người sử dụng có khả năng đối xử khác nhau đối với một hay nhiều loại lưu lượng.

Nói thêm về hỗ trợ QoS trong địa chỉ IPv4

Header của địa chỉ IPv4 có trường Service Type 8 bít có thể giúp phân định mức độ ưu tiên và một số giá

trị khác dành cho lưu lượng IPv4 .3 bít đầu xác định độ ưu tiên (precedence) của gói tin . Với 3 bít, có thể

có 8 mức độ ưu tiên khác nhau đối với lưu lượng IPv4. 4 bít tiếp theo được gọi là ToS (Type of Service)

giúp xác định dịch vụ và một số các thông số khác như độ trễ, thông lượng, độ tin cậy.

Tuy nhiên, sử dụng các giá trị của Service Type trong việc phân định loại dịch vụ và mức ưu tiên phục vụ

cho QoS có một số vấn đề như sau

-      Trường này cung cấp một mô hình cố định và hạn chế trong việc phân dạng loại dịch vụ

-      Gía trị độ ưu tiên: Chỉ mã hoá một cách tương đối mức ưu tiên

Địa chỉ IPv4 có những hạn chế như sau trong hỗ trợ QoS:

-      Phân mảnh gói tin trong IPv4: Việc thực hiện phân mảnh gói tin tại router là một vấn đề điển hình

của IPv4. Nó dẫn đến khả năng làm tắc nghẽn mạng, tiêu tốn bằng thông và CPU của thiết bị.

-     Quá tải về quản lý: ICMPv4 có quá nhiều tuỳ chọn (option)

-      Định tuyến không hiệu quả: Đây cũng là một hậu quả trực tiếp của việc phân mảnh gói tin. Mặc

khác, nó cũng do cấu trúc đánh số và quản lý địa chỉ không hoàn toàn phân cấp.

Những yếu tố đó ảnh hưởng đến khả năng hỗ trợ QoS trong IPv4, đặc biệt trong phạm vi rộng lớn.

Giới thiệu về IP v6.

Giao thức IPng (Next General Internet Protocol) là phiên bản mới của giao thức IP được IETF (Internet Engineering Task Force) đề xướng và năm 1994, IESG (Internet Engineering Steering Group) phê chuẩn với tên chính thức là IPv6. IPv6 là phiên bản kế thừa phát triển từ IPv4. 1. Nguyên nhân ra đời của IPv6 - Internet phát triển mạnh, nhu cầu sử dụng địa chỉ IP tăng dẫn đến không gian địa chỉ ngày càng bị thu hẹp và tình trạng thiếu hụt địa chỉ tất yếu sẽ xảy ra trong vài năm tới. - Việc phát triển quá nhanh của mạng Internet dẫn đến kích thước các bảng định tuyến trên mạng ngày càng lớn. - Cài đăt IPv4 bằng thủ công hoặc bằng giao thức cấu hình địa chỉ trạng thái DHCP (Dynamic Host Configuration Protocol), khi mà nhiều máy tính và các thiết bị kết nối vào mạng thì cần thiết phải có một phương thức cấu hình địa chỉ tự động và đơn giản hơn. - Trong quá trình hoạt động IPv4 đã phát sinh một số vấn đề về bảo mật và QoS. Khi kết nối thành mạng Intranet cần nhiều địa chỉ khác nhau và truyền thông qua môi trường công cộng. Vì vậy đòi hỏi phải có các dịch vụ bảo mật để bảo vệ dữ liệu ở mức IP. - Mặc dù có các chuẩn đảm bảo chất lượng dịch vụ QoS trong IPv4 trường IPv4 TOS (Type of Service), nhưng hạn chế về mặt chức năng, cần thiết hỗ trợ tốt hơn cho các ứng dụng thời gian thực.

-Vì vậy việc cần thiết phải thay thế giao thức IPv4 là tất yếu. Thiết kế IPv6 nhằm mục đích tối thiểu hóa ảnh hưởng qua lại giữa các giao thức lớp trên và lớp dưới bằng cách tránh việc bổ sung một cách ngẫu nhiên các chức năng mới.2.Các đặc trưng của IPv6 IPv6 được chọn thay thế cho giao thức IPv4 không chỉ do IPv4 không còn phù hợp với yêu cầu phát triển hiện tại của mạng Internet mà còn vì những ưu điểm của giao thức IPv6: -Đơn giản hoá Header: Một số trường trong Header của IPv4 bị bỏ hoặc chuyển thành các trường tuỳ chọn. Giảm thời gian xử lý và tăng thời gian truyền. -Không gian địa chỉ lớn: Độ dài địa chỉ IPv6 là 128 bit, gấp 4 lần độ dài địa chỉ IPv4. gian địa chỉ IPv6 không bị thiếu hụt trong tương lai. -Khả năng địa chỉ hoá và chọn đường linh hoạt: IPv6 cho phép nhiều lớp địa chỉ với số lượng các node. Cho phép các mạng đa mức và phân chia địa chỉ thành các mạng con riêng lẻ. Có khả năng tự động trong việc đánh địa chỉ. Mở rộng khả năng chọn đường bằng cách thêm trường “Scop” vào địa chỉ quảng bá (Multicast). -Tự động cấu hình địa chỉ: Khả năng tự cấu hình của IPv6 được gọi là khả năng cắm và chạy (Plug and Play). Tính năng này cho phép tự cấu hình địa chỉ cho giao diện mà không cần sử dụng các giao thức DHCP. -Khả năng bảo mật: IPsec bảo vệ và xác nhận các gói tin IP:

Mã hóa dữ liệu: Phía gửi sẽ tiến hành mã hóa gói tin trước khi gửi.

Toàn vẹn dữ liệu: Phía nhận có thể xác nhận gói tin nhận được để đảm bảo rằng dữ liệu không bị thay đổi trong quá trình truyền.

Xác nhận nguồn gốc dữ liệu: Phía nhận có thể biết được phía gửi gói tin. Dịch vụ này phụ thuộc vào dịch vụ toàn vẹn dữ liệu.

Antireplay: Phía nhận có thể phát hiện và từ chối gói tin gửi lại.-Chất lượng dịch vụ QoS (Quanlity Of Service): Chất lượng dịch vụ QoS trong IPv4 không cao.Trong Header IPv4 chứa địa chỉ nguồn và địa chỉ đích, truyền có độ tin cậy không cao. IPv6 Header có thêm một số trường mới để xử lý và xác định lưu lượng trên mạng. Do cơ chế xác nhận gói tin ngay trong Header nên việc hỗ trợ QoS có thể thực hiện được ngay cả khi gói tin được mã hóa qua IPsec. - Giao thức phát hiện lân cận NDP (Neighbor Discovery Protocol) của IPv6 là một dãy các thông báo ICMPv6 cho phép quản lý tương tác giữa các node lân cận, thay thế ARP trong IPv4. Các thông báo ICMPv4 Router Discovery và ICMPv4 Redirect được thay bởi các thông báo Multicast, Unicast

Neighbor Discovery. - Khả năng mở rộng: Thêm vào trường Header mở rộng tiếp ngay sau Header, IPv6 có thể được mở rộng thêm các tính năng mới một cách dễ dàng. - Tính di động: IPv4 không hỗ trợ cho tính di động, IPv6 cho phép nhiều thiết bị di động kết nối vào Internet theo chuẩn của PCMCIA (Personal Computer Memory Card International Association) qua mạng công cộng nhờ sóng vô tuyến.

Các ưu điểm của IPv6 so với IPv4

Để có cái nhìn tổng quan nhất, tớ tổng hợp lại một số các đặc điểm chinh như sau:

Do các vấn đề đặt ra ở trên nên một phiên bản của giao thức đã được giới thiệu. Xuất phát điểm của IPv6 có tên gọi là IPng (Internet Protocol Next Generation). Sau đó, IPng được gán với phiên bản 6 và lấy tên chính thức IPv6. Quan điểm chính khi thiết kế IPv6 là từng bước thay thế IPv4, không tạo ra sự biến đổi quá lớn với các tầng trên và dưới. - Mở rộng của không gian địa chỉ : Địa chỉ của IPv6 bao gồm 128bit so với 32 bít của địa chỉ IPv4. Với phạm vi của địa chỉ IPv6, việc cung cấp địa chỉ trở nên thoải mái hơn rất nhiều. Về mặt lý thuyết, 128bit địa chỉ có khả năng cung cấp 2 128 = 340 282 366 920 938 463 374 607 431 768 211 456 địa chỉ, nhiều hơn địa chỉ của IPv4 khoảng 8 tỷ tỷ tỷ lần (vì 232 lấy tròn là 4x109 còn 2128 lấy tròn là 340x1036). Số địa chỉ này nếu rải đều trên bề mặt trái đất thì trung bình mỗi mét vuông sẽ có khoảng 665 570 tỷ tỷ địa chỉ. Số lượng địa chỉ này sẽ đáp ứng được sự bùng nổ của các thiết bị IP trong tương lai. Ngoài ra IPv6 còn cung cấp phương thức mới tự động cấu hình địa chỉ và xây dựng một phép kiểm tra tính duy nhất của địa chỉ IP.- Kết cấu địa chỉ định tuyến được phân cấp hiệu quả: Địa chỉ IPv6 được thiết kế để tạo ra cơ sở định tuyến phân cấp, hiệu quả và có khả năng tập hợp lại dựa trên sự phân cấp thành nhiều mức của các nhà cung cấp dịch vụ (ISP). Như vậy các bảng định tuyến trên các router backbone sẽ gọn nhẹ hơn nhiều.- Đơn giản hóa dạng thức của Header: Mặc dù chiều dài bit của địa chỉ IPv6 gấp 4 lần chiều dài bit địa chỉ IPv4 nhưng kích thước Header IPv6 chỉ gấp 2 lần Header IPv4. Phần Header của IPv6 được giảm xuống tới mức tối thiểu bằng việc chuyển tất cả các trường phụ thuộc hoặc không cần thiết xuống phần header mở rộng nằm ngay sau phần header của IPv6 Phần Header cơ bản có kích thước cố định giúp tăng hiệu quả router. Việc đặt các tùy chọn sang phần Header mở rộng cho phép nâng cao tính linh hoạt, có thể đáp ứng được nếu trong tương lai có thêm các tùy chọn mới.Việc tổ chức hợp lý phần header này làm tăng hiệu quả xử lý tại các router trung gian. IPv6 header và IPv4 header là không tương thích với nhau, do đó các node phải được cài đặt 2 phiên bản IP mới có thể xử lý được các header khác nhau này - Tự động cấu hình địa chỉ : Tương tự như IPv4, IPv6 cũng cung cấp khả năng cấu hình địa chỉ tự động bởi DHCP, ngoài ra còn đưa thêm khả năng tự động cấu hình địa chỉ khi không có DHCP Server. Trong một mạng, các host có thể tự động cấu hình địa chỉ của nó bằng cách sử dụng IPv6 Prefix nhận được từ router(gọi là địa chỉ link-local). Hơn nữa trong một mạng mà không có router thì host cũng có thể tự động cấu hình địa chỉ link-local để liên lạc với các host khác.- Bảo mật : Hỗ trợ IPSec đã được hỗ trợ ở ngay bản thân của IPv6. Yêu cầu bắt buộc này như là một tiêu chuẩn cho an ninh mạng, đồng thời mở rộng khả năng làm việc được với nhau của các loại sản phẩm.Trong IPv6 thực thi IPSec được định nghĩa như là 1 đặc tính bắt buộc của địa chỉ IPv6 khi các thủ tục bảo mật của IPSec được đưa thành 2 đặc tính là 2 Header mở rộng của địa chỉ IPv6: Authentication Header – AH ( phần đầu xác thực ) và Encapsulating Security Payload – ESP ( phần đầu mã hóa ). Hai Header này có thể được sử dụng cùng lúc hoặc riêng rẽ để cung cấp các mức bảo mật khác nhau.IPSec được coi là 1 trong những đặc tính cơ bản của địa chỉ IPv6. Tuy nhiên tại thời điểm hiện nay, dù nhiều hệ điều hành có hỗ trợ IPSec nhưng việc sử dụng IPSec trong

IPv6 cho kết nối đầu cuối – đầu cuối là chưa phổ biến. Một trong những nguyên nhân gây nên là do mô hình kết nối có tường lửa hiện nay và thói quen sử dụng những thủ tục bảo mật tại tầng ứng dụng. Mục tiêu sắp tới là hoàn thiện sửa đổi các tiêu chuẩn hóa liên quan đến IPSec như về AH, ESP và tiến đến mọi node IPv6 đều có khả năng sử dụng IPSec, đưa IPSec phổ dụng cùng với sự phổ biến ngày càng nhiều của địa chỉ IPv6.

- Chất lượng dịch vụ tốt hơn (QoS) : Phần header của IPv6 được đưa thêm một số trường mới. Trường nhãn luồng (Flow Label) ở IPv6 header được dùng để đánh nhãn cho các luồng dữ liệu. Từ đó các router có thể có những xử lý khác nhau với các gói tin thuộc các luồng dữ liệu khác nhau. Do trường Flow Label nằm trong IPv6 header nên QoS vẫn được đảm bảo khi phần tải trọng được mã hóa bởi IPSec.

Hỗ trợ QoS trong địa chỉ IPv6:

IPv6 header có hai trường dữ liệu Traffic Class (8 bít) và Flow label (20 bít). Một host có thể sử

dụng Flow Label và Traffic trong IPv6 header để phân dạng gói tin trong đó host yêu cầu IPv6

router có những cách cư xử đặc biệt nào đó. Ví dụ, host có thể yêu cầu chất lượng dịch vụ khác

mặc định cho những dịch vụ thời gian thực.

Traffic Class: Trường Traffic Class thực hiện chức năng tương tự trường “Service Type” của địa

chỉ ipv4. Trường này được sử dụng để biểu diễn mức ưu tiên của gói tin. Node gửi gói tin cần

thiết lập giá trị phân loại độ ưu tiên nhất định cho gói tin IPv6, sử dụng trường Traffic Class.

Router khi xử lý chuyển tiếp gói tin cũng sử dụng trường này cho mục đích tương tự.

Đối với thế hệ địa chỉ IPv6, trường Traffic Class với số bít nhiều hơn sẽ giúp phân định tốt hơn

mức độ ưu tiên cho gói tin.

Flow Label : Trường Flow label sử dụng để định danh một dòng dữ liệu giữa nguồn và đích.

Flow Label được sử dụng trong IPv6 sẽ hỗ trợ tốt hơn thực thi QoS.

Khái niệm một dòng (flow):Một dòng (flow) là một chuỗi các gói tin được gửi từ một

nguồn tới một đích nhất định (có thể là unicast hay multicast). Nguồn sẽ yêu cầu các

router có các cư xử đặc biệt đối với các gói tin thuộc một flow. Việc cần phải cư xử như

thế nào đối với gói tin có thể được truyền tới router bằng một thủ tục điều khiển, hoặc

cũng có thể là thông tin chứa trong chính gói tin của dòng, ví dụ như header mở rộng

hop-by-hop của gói tin.

Giữa một nguồn và một đích có thể có nhiều dòng. Việc kết hợp giữa địa chỉ nguồn và một số

Flow label khác 0 sẽ xác định duy nhất một dòng. Những gói tin không thuộc dòng nào cả sẽ

được thiết lập toàn bộ các bít Flow Label có giá trị 0. 

Mọi gói tin thuộc cùng một dòng phải được gửi với cùng địa chỉ nguồn, cùng địa chỉ đích, và

cùng có một số Flow label khác 0. Router xử lý gói tin sẽ thiết lập trạng thái xử lý đối với một

label cụ thể và có thể lựa  chọn lưu trữ thông tin (cache), sử dụng giá trị địa chỉ nguồn và flow

label làm khoá. Đối với những gói tin sau đó, có cùng địa chỉ nguồn và giá trị flow label, router

có thể áp dụng cách thức xử lý dựa trên thông tin hỗ trợ từ vùng cache.

Một nguồn IPv6 có thể sử dụng 20 bít flow label trong IPv6 header để xác định gói tin gửi đi

trong một dòng nhất định, yêu cầu cách thức cư xử đặc biệt của router. Ví dụ nguồn yêu cầu chất

lượng dịch vụ không mặc định hoặc dịch vụ thời gian thực.

Tại thời điểm hiện nay, việc sử dụng trường này trong thực thi QoS vẫn nằm ở mức thử nghiệm,

các tiêu chuẩn hoá trường này còn chưa hoàn thiện. Hiện nay chưa có một cấu trúc thông dụng

cho việc sử dụng nó. IETF đang tiếp tục tiêu chuẩn hoá và đưa ra những yêu cầu rõ ràng hơn cho

Internet về hỗ trợ trường Flow Label. Nhiều router, host chưa hỗ trợ việc sử dụng trường label.

Đối với những router và host này, toàn bộ các bít của trường label sẽ được thiết lập giá trị 0 và

các host, router này bỏ qua trường đó khi nhận được gói tin. 

Bên cạnh những cải tiến trong IPv6 header, cùng với những ưu điểm khác của IPv6 như: không

phân mảnh, định tuyến phân cấp, đặc biệt gói tin IPv6 được thiết kế với mục đích xử lý thật hiệu

quả tại router. Tất cả tạo ra khả năng hỗ trợ tốt hơn cho chất lượng dịch vụ QoS. Tuy nhiên để đạt

tới trạng thái hoàn thiện và sử dụng rộng rãi thống nhất, còn cần thời gian và công sức của những

tổ chức nghiên cứu và tiêu chuẩn hoá.

- Khả năng mở rộng tốt : IPv6 có khả năng mở rộng tốt bằng việc sử dụng phần header mở rộng ngay sau phần IPv6 header. Điều này cho phép thêm vào các chức năng mạng mới. Không giống như IPv4, phần lựa chọn chỉ có 40 byte thì với IPv6, phần mở rộng chỉ bị hạn chế bởi kích thước của gói tin IPv6.

---------------------------Tham kh ảo------------------------------------------------------------

Một số giao thức cơ bản của bộ giao thức TCP/IP

1).Giao thức điều khiển truyền TCP (Transmission Control Protocol) TCP là một giao thức hướng liên kết (Connection Oriented), tức là trước khi truyền dữ liệu, thực thể TCP gởi và thực thể TCP nhận thương lượng để thiết lập một kết nối logic tạm thời, tồn tại trong quá trình truyền số liệu. TCP nhận thông tin từ tầng trên, chia dữ liệu thành nhiều gói theo độ dài quy định và chuyển giao các gói tin xuống cho các giao thức tầng mạng (Tầng IP) để định tuyến. Bộ xử lý TCP xác nhận từng gói, nếu không có xác nhận gói dữ liệu sẽ được truyền lại. Thực thể TCP bên nhận sẽ khôi phục lại thông tin ban đầu dựa trên thứ tự gói và chuyển dữ liệu lên tầng trên. TCP cung cấp khả năng truyền dữ liệu một cách an toàn giữa các thành trong bộ liên mạng. Cung cấp các chức năng kiểm tra tính chính xác của dữ liệu khi đến đích và truyền lại dữ liệu khi có lỗi xảy ra. TCP cung cấp các chức năng chính sau :- Thiết lập, duy trì, giải phóng liên kết giữa hai thực thể TCP.- Phân phát gói tin một cách tin cậy. - Tạo số thứ tự (Sequencing) các gói dữ liệu. - Điều khiển lỗi. - Cung cấp khả năng đa kết nối cho các quá trình khác nhau giữa thực thể nguồn và thực thể đích thông qua việc sử dụng số hiệu cổng. - Truyền dữ liệu theo chế độ song công (Full-Duplex). TCP có những đặc điểm sau: - Hai thực thể liên kết với nhau phải trao đổi, đàm phán với nhau về các thông tin liên kết. Hội thoại, đàm phán nhằm ngăn chặn sự tràn lụt và mất dữ liệu khi truyền.

- Máy nhận phải gửi xác nhận cho máy gởi biết rằng nó đã nhận gói dữ liệu. - Các Datagram IP có thể đến đích không đúng theo thứ tự , TCP nhận sắp xếp lại. - Hệ thống chỉ phát lại gói tin bị lỗi, không loại bỏ toàn bộ dòng dữ liệu.

2).Giao thức gói tin người sử dụng UDP (User Datagram Protocol) UDP là giao thức không liên kết (Connectionless). UDP sử dụng cho các tiến trình không yêu cầu về độ tin cậy cao, không có cơ chế xác nhận ACK, không đảm bảo chuyển giao các gói dữ liệu đến đích và theo đúng thứ tự và không thực hiện loại bỏ các gói tin trùng lặp. Nó cung cấp cơ chế gán và quản lý các số hiệu cổng để định danh duy nhất cho các ứng dụng chạy trên một Client của mạng và thực hiện việc ghép kênh. UDP thường sử dụng kết hợp với các giao thức khác, phù hợp cho các ứng dụng yêu cầu xử lý nhanh như các giao thưc SNMP và VoIP. - Giao thức SNMP (Simple Network Management Protocol) là giao thức quản lý mạng phổ biến, khả năng tương thích cao. SNMP cung cấp thông tin quản trị MIB (Management Information Base) và hỗ trợ quản lý và giám sát Agent. - VoIP ứng dụng UDP: Kỹ thuật VoIP (Voice over IP) được thừa kế kỹ thuật giao vận IP. Các mạng IP sử dụng hai loại giao thức định tuyến: định tuyến vectơ khoảng cách và định tuyến trạng thái liên kết. Hệ thống đảm bảo tính năng thời gian thực, tốc độ truyền cao, các gói thoại không có trễ quá mức và độ tin cậy cao.

3). Giao thức mạng IP (Internet Protocol) IP (Internet Protocol) là giao thức không liên kết. Chức năng chủ yếu của IP là cung cấp các dịch vụ Datagram và các khả năng kết nối các mạng con thành liên mạng để truyền dữ liệu với phương thức chuyển mạch gói IP Datagram, thực hiện tiến trình định địa chỉ và chọn đường. IP Header được thêm vào đầu các gói tin và được giao thức tầng thấp truyền theo dạng khung dữ liệu (Frame). IP định tuyến các gói tin thông qua liên mạng bằng cách sử dụng các bảng định tuyến động tham chiếu tại mỗi bước nhảy. Xác định tuyến được tiến hành bằng cách tham khảo thông tin thiết bị mạng vật lý và logic như ARP giao thức phân giải địa chỉ. IP thực hiện việc tháo rời và khôi phục các gói tin theo yêu cầu kích thước được định nghĩa cho các tầng vật lý và liên kết dữ liệu thực hiện. IP kiểm tra lỗi thông tin điều khiển, phần đầu IP bằng giá trị tổng CheckSum.

4).Giao thức thông báo điều khiển mạng ICMP (Internet Control Message Protocol) Giao thức IP không có cơ chế kiểm soát lỗi và kiểm soát luồng dữ liệu. Các nút mạng cần biết tình trạng các nút khác, các gói dữ liệu phát đi có tới đích hay không… Các chức năng chính: ICMP là giao thức điều khiển của tầng IP, sử dụng để trao đổi các thông tin điều khiển dòng dữ liệu, thông báo lỗi và các thông tin trạng thái khác của bộ giao thức TCP/IP. - Điều khiển lưu lượng (Flow Control): Khi các gói dữ liệu đến quá nhanh, thiết bị đích hoặc thiết bị định tuyến ở giữa sẽ gửi một thông điệp ICMP trở lại thiết bị gửi, yêu cầu thiết bị gửi tạm thời ngừng việc gửi dữ liệu. - Thông báo lỗi: Trong trường hợp không tới được địa chỉ đích thì hệ thống sẽ gửi một thông báo lỗi "Destination Unreachable". - Định hướng lại các tuyến (Redirect Router): Một Router gửi một thông điệp ICMP cho một trạm thông báo nên sử dụng Router khác. Thông điệp này có thể chỉ được dùng khi trạm nguồn ở trên cùng một mạng với hai thiết bị định tuyến. - Kiểm tra các trạm ở xa: Một trạm có thể gửi một thông điệp ICMP "Echo" để kiểm tra trạm có hoạt động hay không.Các loại thông điệp ICMP: Các thông điệp ICMP được chia thành hai nhóm: các thông điệp truy vấn và các thông điệp thông báo lỗi. Các thông điệp truy vấn giúp cho người quản trị mạng nhận các thông tin xác định từ một node mạng khác. Các thông điệp thông báo lỗi liên quan đến các vấn đề mà bộ định tuyến hay trạm phát hiện ra khi xử lý gói IP. ICMP sử dụng địa chỉ IP nguồn để gửi thông điệp thông báo lỗi cho node nguồn của gói IP. 5).Giao thức quản lý nhóm Internet IGMP (Internet Group Management Protocol) Giao thức quản lý nhóm Internet IGMP (Internet Group Management Protocol) là một giao thức quản lý các trạm thành viên trong nhóm truyền IP multicast. Một nhóm IP multicast, đ¬ược biết đến như¬ một nhóm trạm. Gói tin IP multicast đ¬ược truyền tới một địa chỉ MAC đơn như¬ng đ¬ược xử lý bởi nhiều trạm sử dụng giao thức IP. Một trạm cụ thể sẽ nghe một địa chỉ gói tin IP multicast cụ thể và nhận tất cả các gói tin từ địa chỉ đó.6).Giao thức phân giải địa chỉ ARP (Address Resolution Protocol) Giao thức TCP/IP sử dụng ARP để tìm địa chỉ vật lý của trạm đích. Ví dụ khi cần gửi một gói dữ liệu IP cho một hệ thống khác trên cùng một mạng vật lý Ethernet, hệ thống gửi cần biết địa chỉ Ethernet của hệ thống đích để tầng liên kết dữ liệu xây dựng khung gói dữ liệu. Thông thường, mỗi hệ thống lưu giữ và cập nhật bảng thích ứng địa chỉ IP-MAC tại chỗ (còn được gọi là bảng ARP Cache). Bảng thích ứng địa chỉ được cập nhật bởi người quản trị hệ thống hoặc tự động bởi giao thức ARP sau mỗi lần ánh xạ được một địa chỉ tương ứng mới. Trước khi trao đổi thông tin với nhau, node nguồn cần phải xác định địa chỉ vật lý MAC của node đích

bằng cách tìm kiếm trong bảng địa chỉ IP. Nếu không tìm thấy, node nguồn gửi quảng bá(Broadcast) một gói yêu cầu ARP(ARP Request) có chứa địa chỉ IP nguồn, địa chỉ IP đích cho tất cảc các máy trên mạng. Các máy nhận, đọc, phân tích và so sánh địa chỉ IP của nó với địa chỉ IP của gói. Nếu cùng địa chỉ IP, nghĩa là node đích tìm trong bảng thích ứng địa chỉ IP-MAC của nó và trả lời bằng một gói ARP Rely có chứa địa chỉ MAC cho node nguồn. Nếu không cùng địa chỉ IP, nó chuyển tiếp gói yêu cầu nhận được dưới dạng quảng bá cho tất cả các trạm trên mạng. Tóm lại tiến trình của ARP được mô tả như sau: - IP yêu cầu địa chỉ MAC. - Tìm kiếm trong bảng ARP. - Nếu tìm thấy sẽ trả lại địa chỉ MAC. - Nếu không tìm thấy, tạo gói ARP yêu cầu và gửi tới tất cả các trạm. - Tuỳ theo gói tin trả lời, ARP cập nhật vào bảng ARP và gửi địa chỉ MAC cho IP. 7).Giao thức phân giải địa chỉ ngược RARP (Reverse Address Resolution Protocol) -RARP là giao thức phân giải địa chỉ ngược. Quá trình này ngược lại với quá trình ARP ở trên, nghĩa là cho trước địa chỉ mức liên kết, tìm địa chỉ IP tương ứng. Như vậy RARP được sử dụng để phát hiện địa chỉ IP, khi biết địa chỉ vật lý MAC. Và cũng được sử dụng trong trường hợp trạm làm việc không có đĩa -Khuôn dạng gói tin RARP tương tự như khuôn dạng gói ARP đã trình bày, chỉ khác là trường Opcode có giá trị 0×0003 cho mã lệnh yêu cầu(RARP Request) và có giá trị 0×0004 cho mã lệnh trả lời(RARP Reply). -Nguyên tắc hoạt động của RARP ngược với ARP, nghĩa là máy đã biết trước địa chỉ vật lý MAC tìm địa chỉ IP tương ứng của nó. Hình 3.12 minh họa hoạt động của giao thức RARP. Máy A cần biết địa IP của nó, nó gửi gói tin RARP Request chứa địa chỉ MAC cho tất cả các máy trong mạng LAN. Mọi máy trong mạng đều có thể nhận gói tin này nhưng chỉ có Server mới trả lại RARP Reply chứa địa chỉ IP của nó.

RFC

Trong kỹ nghệ liên mạng và mạng máy tính, các tài liệu RFC (tiếng Anh: Request for Comments - Đề nghị duyệt thảo và bình luận) là một chuỗi các bản ghi nhớ chứa đựng những nghiên cứu mới, những đổi mới, và những phương pháp luận ứng dụng cho công nghệ Internet.

Thông qua Đoàn thể Internet (Internet Society), các kỹ sư và các nhà khoa học máy tính có thể công bố luận văn dưới hình thức là một bản ghi nhớ RFC, hoặc là để cho những người đồng nghiệp phê bình (peer review), hoặc chỉ đơn thuần thông báo những quan điểm mới, tin tức, hoặc (thỉnh thoảng) hài hước về kỹ thuật. Tổ chức Lực lượng chuyên trách về kỹ thuật liên mạng (Internet Engineering Task Force - IETF) chấp nhận một số những lý thuyết thông tin đã ứng dụng được công bố trong các bản RFC như những tiêu chuẩn về liên mạng (Internet standards).

* Sự kiến tạo và tiến triển của RFC

Chủ biên tập RFC phát hành cho mỗi một bản tài liệu RFC một số đăng ký duy nhất. Một khi số đăng ký đã được phát hành và công bố, bản RFC sẽ không bao giờ bị hủy bỏ hay bị sửa đổi; nếu bản tài liệu cần phải được chỉnh lý, các tác giả của nó sẽ công bố một bản chỉnh lý; chính vì vậy, một số RFC trở nên lỗi thời vì những bản mới của nó. Các bản RFC đã được đăng ký cùng nhau tạo nên một loạt hồ sơ nối tiếp, hình thành lịch sử tiến triển của tiêu chuẩn liên kết mạng (Internet standards).Xin chú ý cụm từ "RFC" không phải là đặc thù riêng cho loạt các tài liệu này. Một số tổ chức khác cũng cho xuất bản

những tài liệu, dùng cụm từ "RFC". Dầu vậy, cụm từ này đã từ lâu được nổi tiếng là cụm từ chỉ loạt tài liệu "RFC" về Internet;

Tiến trình kiến tạo RFC không giống với những tiến trình tiêu chuẩn hóa do những tổ chức chính quy về tiêu chuẩn như ANSI thường làm. Những chuyên gia về kỹ thuật liên mạng truyền thông có thể tự đề bạt một bản dự thảo Internet (Internet Draft) mà không cần có sự hỗ trợ từ những cơ quan bên ngoài. Những bản RFC được công nhận là tiêu chuẩn thường được công bố với sự phê chuẩn của Lực lượng chuyên trách kỹ thuật kết nối mạng (IETF), và đa số do những chuyên gia tham dự trong các nhóm điều hành của IETF thi hành. Khi mới bắt đầu, chúng đều là những bản dự thảo Internet. Cách sắp xếp này cho phép những bản dự thảo được thông qua những vòng thăm dò ý kiến ban đầu, từ những đồng nghiệp, trước khi tài liệu được thanh lọc và trưởng thành nên những bản RFC.

Truyền thống của RFC dựa vào tính thực dụng, vào kinh nghiệm từng trải, quyền tiêu chuẩn hóa những bản thảo thông qua thực tế đạt được bởi các cá nhân hoặc một nhóm cộng tác nhỏ, có những ưu điểm, hơn rất nhiều tiến trình chính quy do hội đồng điều khiển, mà chúng ta thường thấy ở ANSI hoặc ISO.

Ví dụ điển hình cho những ưu điểm trên đây là sự tồn tại phồn thịnh của truyền thống những RFC hài hước (joke RFCs), được công bố vào ngày hài hước tháng Tư (April Fool's Day) hằng năm.

Các bản RFC đã từng nổi tiếng vì chất lượng của chúng. Trong các bản RFC chúng ta vừa không gặp những sự nhập nhằng khó hiểu, một vấn đề phổ biến trong các bản thiết kế dự thảo, vừa không có những chức năng ngoài dự kiến do sai lầm của hội đồng gây ra, là những cái ám ảnh các tiêu chuẩn chính quy, và chúng vạch đường cho một mạng lưới đang được phát triển tới tầng cỡ toàn cầu. Để biết thêm chi tiết về RFC và tiến trình của RFC, xin xem RFC 2026, "Tiến trình của tiêu chuẩn Internet, phiên bản số 3" ("The Internet Standards Process, Revision 3).

*Lịch sử

Mẫu hình RFC được khởi đầu vào năm 1969, khi nó là một phần trong hội thảo của dự án ARPANET. Hiện nay, nó là tuyến công bố chính thức của IETF, của Ủy ban kiến trúc liên kết mạng (Internet Architecture Board - viết tắ là IAB)), và tới một mức độ nào đó, của cộng đồng những kỹ sư nghiên cứu về mạng lưới truyền thông vi tính toàn cầu.

Những bản RFC đầu tiên được tác giả của chúng đánh bằng máy chữ và truyền tay các bản in giữa nhóm những kỹ sư nghiên cứu tại ARPA. Tháng 12 năm 1969, các kỹ sư nghiên cứu phân phát các bản RFC mới được viết thông qua mạng lưới truyền thông, vốn là ARPANET, mà hiện nay đang hoạt động. Bản RFC số 1, với đề tài "Phần mềm dành cho máy chủ" (Host Software), được Steve Crocker sinh viên trường đại học California (University of California, Los Angeles - viết tắt là UCLA) viết, và được công bố vào ngày 7 tháng 4, năm 1969. Crocker đã thảo bản dự thảo này trong phòng tắm để tránh đánh thức bạn cùng phòng của mình.

Trong phiên bản RFC số 3, khai điểm của chuỗi các bản RFC, Steve Crocker đặt các bản RFC đưới quyền của "Nhóm điều hành liên mạng" (Network Working Group). Nhóm này hình như chưa bao giờ tồn tại một cách chính thức, chỉ được định nghĩa là "nhóm người này", song sự ủy quyền vẫn còn tồn tại trong các RFC cho đến ngày nay.

Trường đại học UCLA tiếp tục cho ra nhiều các bản RFC trong những năm của thập niên kỷ 1970, không những vì chất lượng uyên thâm, song còn là vì UCLA là những Bộ điều hành giao diện thông điệp (Interface Message Processor) (nút kết nối mạng) đầu tiên trên mạng ARPANET.

Trung tâm nghiên cứu phát triển (Augmentation Research Center - viết tắt là ARC) của ông Douglas Engelbart tại Học viện nghiên cứu Stanford (Stanford Research Institute) - là một trong bốn nút mạng đầu tiên của mạng ARPANET. Nó cũng đồng thời là Trung tâm tin tức liên mạng (Network Information Centre) đầu tiên, đồng thời nó còn là (như đã được nhà xã hội học Thierry Bardini ghi chú) nguồn gốc của một số lớn những RFC ở thời kỳ đầu.

Từ năm 1969 đến năm 1998, ông Jon Postel làm chủ biên tập RFC. Sau khi hợp đồng ủng hộ tài chính của chính phủ Mỹ hết hạn, Hội đồng Internet (thay mặt cho IETF) ký hợp đồng với Chi nhánh điều hành liên mạng (Networking Division) của trường đại học miền Nam California (University of Southern California - viết tắt là USC) đứng ra làm quyền biên tập và chịu trách nhiệm về việc xuất bản (dưới sự chỉ đạo của IAB). Jon Postel tiếp tục giữ chức chủ biên tập cho đến khi ông mất; sau này, Bob Braden lãnh chức chủ nhiệm đề án, trong khi Joyce Reynolds tiếp tục làm một thành viên của nhóm.

*Cấp bậc

Không phải bản RFC nào cũng là tiêu chuẩn. Chỉ có nhóm IETF đại diện cho Nhóm chỉ đạo kỹ thuật liên kết mạng (Internet Engineering Steering Group - viết tắt là IESG) là có quyền chuẩn y các bản RFC đang trên đà trở thành tiêu chuẩn. Cấp bậc của các bản RFC được chia ra thành những phần như đề cử (proposed) (PS), dự thảo (draft) (DS), và toàn phần (full) tiêu chuẩn Internet (Internet Standards (STD)). Mỗi một biên tập phụ, thuộc một tiêu chuẩn STD nào đó, đều có riêng một con số đặc thù; Kể từ năm 2006 trở đi, tiêu chuẩn số 1 là RFC 3700. Một số các STD tạo nên nhiều nhóm nhỏ, gồm nhiều những RFC liên quan.

Một bản RFC thử nghiệm có thể là một tài liệu của IETF, hoặc một bản đệ trình cá nhân lên chủ biên tập RFC. Trên lý thuyết, thực trạng của các bản tài liệu như là cái tên của nó ám chỉ - chúng chỉ là các "Đề nghị duyệt thảo và bình luận". Trên thực tế một số bản tài liệu không được nâng đỡ trên đà tiêu chuẩn vì không có người tình nguyện thi hành những chi tiết cụ thể trong thủ tục. Một số tài liệu quan trọng cũng chỉ tổn tại như một Bản thảo Internet, trong khi đó lại có những bản RFC chính quy hầu như trở nên lỗi thời (historic). Kể từ năm 2006 trở đi, so sánh bản TAObis I-D với bản RFC 3160, còn được gọi là "The Tao of IETF" (Bản chất Tao trong IETF).

Một bản RFC tin tức hầu như có thể là bất cứ một thứ gì, từ những bản RFC hài hước mùng 1 tháng Tư (April 1st jokes) về những giao thức sở hữu (proprietary protocols) cho đến những bản RFC chủ chốt, được đại đa số biết đến, như bản RFC 1591. Một số bản RFC tin tức được nhóm lại thành một loạt các bài "tin tức đáng để ý" (for your information - viết tắt là FYI). Tuy hiện nay ít ai đăng thêm, một số những FYI cũ vẫn còn rất thích thú, chẳng hạn FYI 18 còn được gọi là RFC 1983, bản "Từ vựng dành cho người dùng Internet". (Internet User's Glossary)

Một bản RFC tồn kho (historic) là một bản lỗi thời và đã có một phiên bản mới thay thế nó. Những bản này liệt trình một giao thức không được coi là đáng để ý trong Internet hiện tại, hoặc đã bị mang ra khỏi đà tiêu chuẩn hóa vì những lý do nào đó. Một số những bản RFC lỗi thời còn không được liệt kê vào hàng các bản tồn kho, vì "Tiến trình tiêu chuẩn hoá Internet" (Internet Standards Process) thường không cho phép những tham chiếu có tính quy chuẩn (normative references) đối với một bản RFC đang trên đà tiêu chuẩn hóa, từ một RFC có địa vị thấp hơn. Đồng thời, ít người chú ý đến việc giải quyết những chi tiết thủ tục yêu cầu, để những bản RFC được phân loại là tồn kho, và những thay đổi được đánh dấu vào tất cả các bản RFC phụ thuộc vào nó.

Dạng vô danh thường được đặt cho những bản RFC quá cũ, không rõ cấp bậc của nó phải là gì nếu phải công bố. Trong một vài trường hợp, những bản RFC ấy còn hoàn toàn không được công bố. Những bản RFC cũ thường, như cái tên của nó ám chỉ, chỉ đơn thuần là những bản "Yêu cầu duyệt thảo và bình luận", không chủ tâm đặc tả một giao thức, một chu trình quản lý, hoặc bất cứ một cái gì khác mà các RFC hiện nay đang được dùng để thực hiện.

Một loạt các bài những thực hành ưu ái (best common practice - viết tắt là BCP) thu thập các tài liệu về quản lý và những văn bản được công nhận là những luật lệ chính quy, và không thuộc dạng tin tức, song chúng không ảnh hưởng đến những dữ liệu được truyền thông qua đường dây. Danh giới giữa các bản trên đà tiêu chuẩn hóa và các bản BCP thường, là một danh giới rất khó phân định. Nếu một tài liệu chỉ ảnh hưởng đến Tiến trình tiêu chuẩn hoá Internet (Internet Standards Process), còn được gọi là BCP 9 hoặc Sự quản lý IETF thì nó rõ ràng là một bản BCP. Nếu bản RFC ấy chỉ định nghĩa những luật lệ và qui định cho những cơ quan đăng ký IANA (Internet Assigned Numbers Authority), thì khó mà có thể phân định được nó là cái nào. Đa số những bản tài liệu này được liệt kê là các bản BCP, song cũng có một số đang trên đà được tiêu chuẩn hóa.

Loạt các bài BCP còn đồng thời nói đến những đề bạt kỹ thuật về phương pháp thực hành những tiêu chuẩn Internet, chẳng hạn đề bạt về cách dùng những bộ lọc nguồn (source filtering) làm cho những tấn công DoS (Denial of Service - Tấn công từ chối dịch vụ) trở nên khó khăn hơn như (RFC 2827: "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing" - tạm dịch là "Thanh lọc nội mạng: Hủy diệt các tấn công từ chối dịch vụ dùng cách đóng địa chỉ IP giả") - là bản BCP 38.

IPv4

From go6 Wiki

Internet Protocol version 4 is version 4 of the Internet Protocol (IP) and it is the first version of the Internet Protocol to be widely deployed. IPv4 is the dominant network layer protocol on the internet and when ignoring its successor — IPv6 — it is the only protocol used on the internet.

It is described in IETF RFC 791 (September 1981) which obsoleted RFC 760 (January 1980). The United States Department of Defense also standardized it as MIL-STD-1777.

IPv4 is a data-oriented protocol to be used on a packet switched internetwork (e.g., Ethernet). It is a best effort protocol in that it doesn't guarantee delivery. It doesn't make any guarantees on the correctness of the data; it may result in duplicated packets and/or packets out-of-order. All of these things are addressed by an upper layer protocol (e.g., TCP, UDP).

The entire purpose of IP is to provide unique global computer addressing to ensure that two computers over the internet can uniquely identify one another.

Addressing

IPv4 uses 32-bit (4-byte) addresses, which limits the address space to 4,294,967,296 possible unique addresses. However, many are reserved for special purposes such as private networks (~18 million addresses) or multicast addresses (~1 million addresses). This reduces the number of addresses that can be allocated as public Internet addresses and as the number of addresses available is consumed, an IPv4 address shortage appears to be inevitable in the long run.

This limitation has helped stimulate the push towards IPv6, which is currently in the early stages of deployment and is currently the only contender to replace IPv4.

Address representations

When writing IPv4 addresses in strings the most common notation is the dot-decimal notation. There are other notations based on the values of the octets of the IP address.

For example, the IPv4 address for www.wikipedia.org is 207.142.131.235 in the dot-decimal notation which comprises four octets in decimal separated by periods. This is the base format used in the conversion in the following table:

Notation Value Conversion from dot-decimal Dot-decimal 207.142.131.235 N/A

notation Dotted Hexadecimal

0xCF.0x8E.0x83.0xEB Each octet is individually converted to hex

Dotted Octal 0317.0216.0203.0353 Each octet is individually converted into octal

Hexadecimal 0xCF8E83EB Concatenation of the octets from the dotted hexadecimal

Decimal 3482223595 The hexadecimal form converted to decimal Octal 031743501753 The hexadecimal form converted to octal

All/most of these formats should work in all browsers. Additionally, in dotted format, each octet can be of the different bases. For example, 207.0x8E.0203.235 is a valid (though unconventional) equivalent to the above addresses.

A final form is not really a notation since it is rarely written in an ASCII string notation. That form is a binary form of the hexadecimal notation in binary. This difference is merely the representational difference between the string "0xCF8E83EB" and the 32-bit integer value 0xCF8E83EB. This form is used in both the source and destination fields.

Allocation

Originally, the IP address was divided into two parts:

network id – first octet host id – last three octets

This created an upper limit of 256 networks and led to the creation of classful networks. Under classful networking, 5 classes were created (A, B, C, D, & E) with 3 created (A, B, & C) with different lengths of network number and rest fields to change the number of IPs in each range: few networks with lots of addresses and numerous networks with only a few addresses. Class D was for multicast addresses and class E is reserved.

Around 1993, the classful networks were replaced with a Classless Inter-Domain Routing (CIDR) scheme. CIDR's primary advantage is to allow subdivision of networks to let entities sub-allocate IPs (e.g., an ISP to a customer).

The actual assignment of an address is not arbitrary. The fundamental principle of routing is that address encodes information about a device's location within a network. This implies that an address assigned to one part of a network will not function in another part of the network. A hierarchical structure, created by CIDR and overseen by the Internet Assigned Numbers Authority (IANA) and its Regional Internet Registries (RIRs), manages the assignment of Internet address worldwide. Each RIR maintains a publicly searchable WHOIS database that provides information about IP address assignments; information from these databases plays a central role in numerous tools that attempt to locate IP addresses geographically.

Reserved address blocks CIDR address block Description Reference 0.0.0.0/8 Current network (only valid as source address) RFC 1700 10.0.0.0/8 Private network RFC 1918 14.0.0.0/8 Public data network RFC 1700 39.0.0.0/8 Reserved RFC 1797 127.0.0.0/8 Localhost RFC 1700 128.0.0.0/16 Reserved   169.254.0.0/16 Zeroconf RFC 3927 172.16.0.0/12 Private network RFC 1918 191.255.0.0/16     192.0.0.0/24     192.0.2.0/24 Test network RFC 3330 192.88.99.0/24 IPv6 to IPv4 relay RFC 3068 192.168.0.0/16 Private network RFC 1918 198.18.0.0/15 Network benchmark tests RFC 2544 223.255.255.0/24 Reserved RFC 3330 224.0.0.0/4 Multicasts (former Class D network) RFC 3171 240.0.0.0/4 Reserved (former Class E network) RFC 1700 255.255.255.255 Broadcast  

Private networks

Of the 4+ billion addresses allowed in IPv4, three ranges of address are reserved for private networking use only. These ranges are not routable outside of private network and private machines cannot directly communicate with public networks. They can, however, do so through network address translation.

The following are the three ranges reserved for private networks:

Name IP address range number of IPs

classful description

largest CIDR block

24-bit block

10.0.0.0 – 10.255.255.255

16,777,215 single class A 10.0.0.0/8

20-bit block

172.16.0.0 – 172.31.255.255

1,048,576 16 contiguous class Bs

172.16.0.0/12

16-bit block

192.168.0.0 – 192.168.255.255

65,535 256 contiguous class Cs

192.168.0.0/16

Localhost

Template:Main

In addition to private networking, the IP range 127.0.0.0 – 127.255.255.255 (or 127.0.0.0/8 in CIDR notation) is reserved for localhost communication. Any address within this range should never appear on an actual network and any packet sent to this address does not leave the source computer, and will appear as an incoming packet on that computer (known as Loopback).

Resolving

Template:Main

The Internet is most publicly known not by IP addresses but by names (e.g., www.wikipedia.org, www.whitehouse.gov, www.freebsd.org, www.mit.edu). The routing of IP packets across the Internet is oblivious to such names. This requires translating (or resolving) names to IP address.

The Domain Name System (DNS) provides such a system to convert names to IP address(es) and IP addresses to names. Much like CIDR addressing, the DNS naming is also hierarchical and allows for subdelegation of name spaces to other DNS servers.

Exhaustion

A concern that has spanned decades to the 1980s is the exhaustion of available IP addresses. This was the driving factor in classful networks and then later in the creation of CIDR addressing.

Today, there are several driving forces to the next address allocation solution:

Mobile devices — laptop computers, PDAs, mobile phones Always-on devices — ADSL modems, cable modems Rapidly growing number of internet users

The most visible solution is to migrate to IPv6 since the address size jumps dramatically from 32-bit to 128-bit which would allow about 18 quintillion people their own set of 18 quintillion addresses (3.4e38 total addresses). However, migration has proved to be a challenge in itself, and total Internet adoption of IPv6 is unlikely to occur for many years.

Some things that can be done to mitigate the IPv4 address exhaustion are (not mutually exclusive):

Network address translation (NAT) Use of private networks Dynamic Host Configuration Protocol (DHCP) Named based virtual hosting Tighter control by Regional Internet Registries on the allocation of addresses to

Local Internet Registries

Network renumbering to reclaim large blocks of address space allocated in the early days of the Internet

As of 2004, predictions for the exhaustion of the IPv4 address space range from 2016 (for unallocated pool exhaustion) to 2023 (for complete exhaustion of the address space). Historically, though, forward predictions for the date of address exhaustion have been unreliable; predictions from the late 1980s have not been borne out in practice.

Network address translation

One method to increase both address utilization and security is to use network address translation (NAT). By assigning one IP to a public machine as an internet gateway and using a private network for an organization's computers allows for considerable address savings. This also increases security by making all of the computers on a private network not directly accessible from the public network.

Virtual private networks

Since private address ranges are deliberately ignored by all public routers, it is not normally possible to connect two private networks (e.g., two branch offices) via the public Internet. Virtual private networks (VPNs) solve this problem.

VPNs work by inserting an IP packet (encapsulated packet) directly into the data field of another IP packet (encapsulating packet) and using a publicly routable address in the encapsulating packet. Once the VPN packet is routed across the public network and reaches the endpoint, the encapsulated packet is extracted and then transmitted on the private network just as if the two private networks were directly connected.

Optionally, the encapsulated packet can be encrypted to secure the data while over the public network (see VPN article for more details).

Address Resolution Protocol

Since IP is an upper layer protocol to the data link layer there arises a problem of when a computer with IP address A wants to communicate with IP address B. In order to send a packet from A to B, A needs to know the hardware address of B. This discovery is done through Address Resolution Protocol (ARP).

Reverse Address Resolution Protocol/DHCP

Unlike the situation outlined for ARP, the case arises when a computer knows its data link layer address but not its IP address. This is a common scenario in private networks and Digital Subscriber Line (DSL) connections when the IP address of the machines are irrelevant. This is usually the case for work stations but not servers.

RARP is an obsoleted method for answering this question: This is my hardware address, what is my IP address? RARP was replaced by BOOTP which, in turn, was replaced by Dynamic Host Configuration Protocol (DHCP).

In addition to sending the IP address, DHCP can also send the NTP server, DNS servers, and more.

Packet structure

An IP packet consists of two sections:

header data

Header

The header consists of 13 fields, of which only 12 are required. The 13th field is optional (red background in table) and aptly named: options. The fields in the header are packed with the most significant byte first (big endian), and for the diagram and discussion, the most significant bits are considered to come first. The most significant bit is numbered 0, so the version field is actually found in the 4 most significant bits of the first byte, for example.

+ Bits 0 - 3 4 - 7 8 - 15 16 - 18 19 - 31

0 Version Header length Type of Service(now DiffServ and ECN)

Total Length

32 Identification Flags Fragment Offset 64 Time to Live Protocol Header Checksum 96 Source Address 128 Destination Address 160 Options

160/192+  Data 

Version  The first header field in an IP packet is the 4-bit version field. For IPv4, this has a value of 4 (hence the name IPv4).

Internet Header Length (IHL)  The second field is a 4-bit Internet Header Length (IHL) telling the number of 32-bit words in the header. Since an IPv4 header may contain a variable number of options, this field specifies the size of the header (this also coincides with the offset to the data). The minimum header size is 20 bytes, so the minimum value

for this field is 5 (5×4 = 20 bytes). Being a 4-bit field the maximum length is 15 words or 60 bytes.

Type of Service (ToS)  In RFC 791, the following 8 bits were allocated to a Type of Service (ToS) field:

bits 0-2: precedence bit 3: 0 = Normal Delay, 1 = Low Delay bit 4: 0 = Normal Throughput, 1 = High Throughput bit 5: 0 = Normal Reliability, 1 = High Reliability bits 6-7: Reserved for future use

This field is now used for DiffServ and ECN. The original intention was for a sending host to specify a preference for how the datagram would be handled as it made its way through an internetwork. For instance, one host could set its IPv4 datagrams' ToS field value to prefer low delay, while another might prefer high reliability. In practice, the ToS field has not been widely implemented. However, a great deal of experimental, research and deployment work has focused on how to make use of these eight bits. These bits have been redefined, most recently through DiffServ working group in the IETF and the Explicit Congestion Notification codepoints (see RFC 3168). New technologies are emerging that require real-time data streaming and therefore will make use of the ToS field. An example is Voice over IP (VoIP) that is used for interactive data voice exchange.

Total Length  This field defines the entire datagram size, including header and data, in bytes. The minimum-length datagram is 20 bytes (20 bytes header + 0 bytes data) and the maximum is 65,535 — the maximum value of a 16-bit word. The minimum size datagram that any host is required to be able to handle is 576 bytes, but most modern hosts handle much larger packets. Sometimes subnetworks impose further restrictions on the size, in which case datagrams must be fragmented. Fragmentation is handled in either the host or packet switch in IPv4 (see #Fragmentation and reassembly).

Identification  This field is an identification field and is primarily used for uniquely identifying fragments of an original IP datagram. Some experimental work has suggested using the ID field for other purposes, such as for adding packet-tracing information to datagrams in order to help trace back datagrams with spoofed source addresses.

Flags  A 3-bit field follows and is used to control or identify fragments. They are (in order, from high order to low order):

Reserved, must be zero Don't Fragment (DF) More Fragments (MF)

If the DF flag is set and fragmentation is required to route the packet then the packet will be dropped. This can be used when sending packets to a host that does not have sufficient resources to handle fragmentation.

When a packet is fragmented all fragments have the MF flag set except the last fragment, which does not have the MF flag set. The MF flag is also not set on packets that are not fragmented — clearly an unfragmented packet can be considered the last fragment.

Fragment Offset  The fragment offset field is 13-bits long and allows a receiver to determine the place of a particular fragment in the original IP datagram, measured in units of 8-byte blocks. This method allows a maximum offset of 65,528 ((2^13 - 1)*8 which would exceed the maximum IP packet length of 65,535 with the header length counted with it. Therefore the 1st bit of the Fragment Offset is mostly unused and is, for an April 1st joke, proposed in RFC 3514 as the "Evil bit" header flag.

Time To Live (TTL)  An 8-bit time to live (TTL) field helps prevent datagrams from persisting (e.g. going in circles) on an internetwork. Historically the TTL field limited a datagram's lifetime in seconds, but has come to be a hop count field. Each packet switch (or router) that a datagram crosses decrements the TTL field by one. When the TTL field hits zero, the packet is no longer forwarded by a packet switch and is discarded. Typically, an ICMP message (specifically the time exceeded) is sent back to the sender that it has been discarded. The reception of these ICMP messages is at the heart of how traceroute works.

Protocol  This field defines the protocol used in the data portion of the IP datagram. The Internet Assigned Numbers Authority maintains a list of Protocol numbers and were originally defined in RFC 790. Common protocols and their decimal values are shown below (see #Data).

Header Checksum  The 16-bit checksum field is used for error-checking of the header. At each hop, the checksum of the header must be compared to the value of this field. If a header checksum is found to be mismatched, then the packet is discarded. Note that errors in the data field are up to the encapsulated protocol to handle — indeed, both UDP and TCP have checksum fields. Since the TTL field is decremented on each hop and fragmentation is possible at each hop then at each hop the checksum will have to be recomputed. The method used to compute the checksum is defined within RFC 791: The checksum field is the 16-bit one's complement of the one's complement sum of all 16-bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero. In other words, all 16-bit words are summed together using one's complement (with the checksum field set to zero). The sum is then one's complemented. This final value is then inserted as the checksum field.

Source address  An IP address is a group of 4 8-bit octets for a total of 32 bits. The value for this field is determined by taking the binary value of each octet and concatenating them together to make a single 32-bit value. For example, the address 10.9.8.7 (00001010.00001001.00001000.00000111 in binary) would be 00001010000010010000100000000111.

This address is the address of the sender of the packet. Note that this address may not be the "true" sender of the packet due to network address translation. Instead, the source address will be translated by the NATing machine to its own address. Thus, reply packets sent by the receiver are routed to the NATing machine, which translates the destination address to the original sender's address.

Destination address  Identical to the source address field but indicates the receiver of the packet.

Options  Additional header fields (called options) may follow the destination address field, but these are not often used. Note that the value in the IHL field must include enough extra 32-bit words to hold all the options (plus any padding needed to ensure that the header contains an integral number of 32-bit words). The list of options may be terminated with an EOL (End of Options List) option; this is only necessary if the end of the options would not otherwise coincide with the end of the header. The use of the LSSR and SSRR options (Loose and Strict Source and Record Route) is discouraged because they create security concerns; many routers block packets containing these options.

Data

The last field is not a part of the header and, consequently, not included in the checksum field. The contents of the data field are specified in the protocol header field and can be any one of the transport layer protocols.

Some of the most commonly used protocols are listed below including their value used in the protocol field:

1: Internet Control Message Protocol (ICMP) 2: Internet Group Management Protocol (IGMP) 6: Transmission Control Protocol (TCP) 17: User Datagram Protocol (UDP) 89: Open Shortest Path First (OSPF) 132: Stream Control Transmission Protocol (SCTP)

See List of IPv4 protocol numbers for a complete list.

Fragmentation and reassembly

To make IPv4 more tolerant of different networks the concept of fragmentation was added so that, if necessary, a device could break up the data into smaller pieces. This is necessary when the maximum transmission unit (MTU) is smaller than the packet size.

For example, the maximum size of an IP packet is 65,535 bytes while the typical MTU for Ethernet is 1,500 bytes. Since the IP header consumes 20 bytes (without options) of the 1,500 bytes leaving 1,480 bytes of IP data per Ethernet frame (this leads to an MTU

for IP of 1,480 bytes). Therefore, a 65,535-byte data payload would require 45 packets (65535/1480 = 44.28).

The reason fragmentation was chosen to occur at the IP layer is that IP is the first layer that connects hosts instead of machines. If fragmentation were performed on higher layers (TCP, UDP, etc.) then this would make fragmentation/reassembly be redundantly implemented (once per protocol); if fragmentation were performed on a lower layer (Ethernet, ATM, etc.) then this would require fragmentation/reassembly be performed on each hop (could be quite costly) and redundantly implemented (once per link layer protocol). So doing fragmentation at the IP layer is the most efficient layer for this to be done.

Fragmentation

When a device receives an IP packet it examines the destination address and determines the outgoing interface to use. This interface has an associated MTU that dictates the maximum data size for its payload. If the MTU is smaller than the data size then the device must fragment the data.

The device then segments the data into segments where each segment is less-than-or-equal-to the MTU less the IP header size (20 bytes minimum; 60 bytes maximum). Each segment is then put into its own IP packet with the following changes:

The total length field will be adjusted to the segment size The more fragments (MF) flag is set for all segments except the last one The fragment offset field is set accordingly based on the offset of the segment in

the original data payload

For example, for an IP header of length 20 bytes and an Ethernet MTU of 1,500 bytes the fragment offsets would be: 0, 1480, 2960, 4440, 5920, etc.

By some chance if a packet changes link layer protocols or the MTU reduces then these fragments would be fragmented again.

For example, if a 4,500 byte data payload is inserted into an IP packet with no options (thus total length is 4,520 bytes) and is transmitted over a link with an MTU of 2,500 bytes then it will be broken up into two fragments:

# Total length More fragments (MF)

flag set? Fragment offset Header Data

1 2500

rowspan="2" align="center" Template:Yes 0

20 2480

2 2040

rowspan="2" align="center" Template:No 2480

20 2020

Now, let's say the MTU drops to 1,500 bytes. Each fragment will individually be split up into two more fragments each:

# Total length More fragments (MF)

flag set? Fragment offset Header Data

1 1500

rowspan="2" align="center" Template:Yes 0

20 1480

2 1020

rowspan="2" align="center" Template:Yes 1480

20 1000

3 1500

rowspan="2" align="center" Template:Yes 2480

20 1480

4 560

rowspan="2" align="center" Template:No 3960

20 540

Indeed, the amount of data has been preserved — 1480 + 1000 + 1480 + 540 = 4500 — and the last fragment offset plus data — 3960 + 540 = 4500 — is also the total length.

Note that fragments 3 & 4 were derived from the original fragment 2. When a device must fragment the last fragment then it must set the flag for all but the last fragment it creates (fragment 3 in this case).

Reassembly

When a receiver detects an IP packet where either of the following is true:

"more fragments" flag set "fragment offset" field is non-zero

then the receiver knows the packet is a fragment. The receiver then stores the data with the identification field, fragment offset, and the more fragments flag. When the receiver receives a fragment with the more fragments flag not set then it knows the length of the original data payload since the fragment offset plus the data length is equivalent to the original data payload size.

Using the example above, when the receiver receives fragment #4 the fragment offset (3960) and the data length (540) added together yield 4500 — the original data length.

Once it has all the fragments then it can reassemble the data in proper order (by using the fragment offsets) and pass it up the stack for further processing.