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 0xCF.0x8E.0x83.0xEB Each octet is individually converted to hex
Hexadecimal
Dotted Octal 0317.0216.0203.0353 Each octet is individually converted into octal
Concatenation of the octets from the dotted
Hexadecimal 0xCF8E83EB
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:

number of classful largest CIDR

Name IP address range
IPs description block
24-bit 10.0.0.0 –
16,777,215 single class A 10.0.0.0/8
block 10.255.255.255
20-bit 172.16.0.0 – 16 contiguous class
1,048,576 172.16.0.0/12
block 172.31.255.255 Bs
16-bit 192.168.0.0 – 256 contiguous
65,535 192.168.0.0/16
block 192.168.255.255 class Cs

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
Type of Service
0 Version Header length Total Length
(now DiffServ and ECN)
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) Fragment

#
Header Data flag set? offset
rowspan="2" align="center"
2500
1 Template:Yes 0
20 2480
rowspan="2" align="center"
2040
2 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) Fragment

#
Header Data flag set? offset
rowspan="2" align="center"
1500
1 Template:Yes 0
20 1480
rowspan="2" align="center"
1020
2 Template:Yes 1480
20 1000
rowspan="2" align="center"
1500
3 Template:Yes 2480
20 1480
rowspan="2" align="center"
560
4 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.