Tiêu chuẩn TCVN 14202:2024 về yêu cầu kỹ thuật đối với nút IPv6

• Số hiệu: TCVN14202:2024
• Loại văn bản: Tiêu chuẩn Việt Nam
• Nơi ban hành: ***
• Người ký: ***
• Ngày ban hành: Năm 2024

TIÊU CHUẨN QUỐC GIA

TCVN 14202:2024

NÚT IPV6 - YÊU CẦU KỸ THUẬT

IPv6 Node - Requirements

Lời nói đầu

TCVN 14202:2024 được xây dựng trên cơ sở tham khảo RFC 8504 (2019) “IPv6 Node Requirements” và QCVN 89:2015/BTTTT.

TCVN 14202:2024 do Học viện Công nghệ Bưu chính Viễn thông biên soạn, Bộ Thông tin và Truyền thông đề nghị, Ủy ban Tiêu chuẩn Đo lường Chất lượng Quốc gia thẩm định, Bộ Khoa học và Công nghệ công bố.

NÚT IPV6 - YÊU CẦU KỸ THUẬT

...

...

...

1  Phạm vi áp dụng

Tiêu chuẩn này quy định các yêu cầu kỹ thuật đối với thiết bị nút IPv6.

IPv6 được dự kiến sẽ triển khai trong nhiều tình huống và môi trường khác nhau. Vì vậy, điều quan trọng là cần phát triển yêu cầu cho các thiết bị nút IPv6 để đảm bảo khả năng tương tác.

2  Tài liệu viện dẫn

Tài liệu viện dẫn sau cần thiết cho việc áp dụng tiêu chuẩn này. Đối với các tài liệu viện dẫn ghi năm công bố thì áp dụng phiên bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp dụng phiên bản mới nhất, bao gồm cả sửa đổi, bổ sung (nếu có).

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987 ("Tên miền - khái niệm và tiện ích", STD 13, RFC 1034, DOI 10.17487/RFC1034, 11/1987).

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987. ("Tên miền - triển khai và thông số kỹ thuật", STD 13, RFC 1035, DOI 10.17487/RFC1035, 11/1987).

[RFC2119] Bradner, S., "Keywords for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997 ("Từ khóa sử dụng trong RFC để chỉ ra mức yêu cầu ", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 03/1997).

[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999. ("Phát hiện lắng nghe phát quảng bá đa hướng (MLD) cho Ipv6", RFC 2710, DOI 10.17487/RFC2710, 10/1999).

...

...

...

[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000. ("Nhóm giao diện MIB", RFC 2863, DOI 10.17487/RFC2863, 6/2000).

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001. ("Bổ sung thông báo tắc nghẽn rõ ràng (ECN)vào IP", RFC 3168, DOI 10.17487/RFC3168, 9/2001).

[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", (" Giao thức cấu hình máy chủ động cho IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, 7/2003).

[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks" (" Kiến trúc mô tả các khuôn khổ quản lý giao thức quản lý mạng đơn giản (SNMP)", STD 62, RFC 3411, DOI 10.17487/RFC3411, 12/2002).

[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6" (" Phần mở rộng DNS để hỗ trợ IP phiên bản 6"), STD 88, RFC 3596, DOI 10.17487/RFC3596, 10/2003.

[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6" ("Dịch vụ Giao thức cấu hình máy chủ động phi trạng thái (DHCP) cho IPv6"), RFC 3736, DOI 10.17487/RFC3736, 04/2004.

[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6" ("Phát hiện lắng nghe phát quảng bá đa hướng phiên bản 2 (MLDv2) cho Ipv6"), RFC 3810, DOI 10.17487/RFC3810, 6/2004.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements" ("Giới thiệu và yêu cầu về bảo mật DNS"), RFC 4033, DOI 10.17487/RFC4033, 3/2005.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose "Resource Records for the DNS Security Extensions", ("Bản ghi tài nguyên cho phần mở rộng bảo mật DNS"), RFC 4034, DOI 10.17487/RFC4034, 3/2005.

...

...

...

[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers" ("Cơ chế chuyển đổi cơ bản cho máy chủ và bộ định tuyến IPv6"), RFC 4213, DOI 10.17487/RFC4213, 10/2005.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture" ("Kiến trúc địa chỉ IP phiên bản 6"), RFC 4291, DOI 10.17487/RFC4291, 01/2006.

[RFC4292] Haberman, B., "IP Forwarding Table MIB" ("Bảng chuyển tiếp IP MIB"), RFC 4292, DOI 10.17487/RFC4292, 4/2006.

[RFC4293] Routhier, S., Ed., "Management Information Base for the Internet Protocol (IP)" ("Cơ sở thông tin quản lý cho Giao thức Internet (IP)"), RFC 4293, DOI 10.17487/RFC4293, 4/2006.

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol" ("Kiến trúc bảo mật cho Giao thức Internet"), RFC 4301, DOI 10.17487/RFC4301, 12/2005.

[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)" ("Tải trọng bảo mật đóng gói IP (ESP)"), RFC 4303, DOI 10.17487/RFC4303, 12/2005.

[RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load Sharing" ("Chia sẻ tải từ máy chủ đến bộ định tuyến IPv6"), RFC 4311, DOI 10.17487/RFC4311, 11/2005.

[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" ("Giao thức bản tin điều khiển Internet (ICMPv6) cho Đặc điểm kỹ thuật Giao thức Internet Phiên bản 6 (IPv6)"), STD 89, RFC 4443, DOI 10.17487/RFC4443, 3/2006).

[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP" ("Phát quảng bá đa hướng nguồn cụ thể cho IP"), RFC 4607, DOI 10.17487/RFC4607, 8/2006.

...

...

...

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)" ("Khám phá lân cận cho IP phiên bản 6 (IPv6)"), RFC 4861, DOI 10.17487/RFC4861, 9/2007.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration" ("Tự động cấu hình địa chỉ phi trạng thái IPv6"), RFC 4862, DOI 10.17487/RFC4862, 9/2007.

[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", ("Mở rộng quyền riêng tư cho cấu hình tự động địa chỉ phi trạng thái trong IPv6"), RFC 4941, DOI 10.17487/RFC4941, 9/2007.

[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6" ("Loại bỏ Tiêu đề định tuyển Loại 0 trong IPv6"), RFC 5095, DOI 10.17487/RFC5095, 12/2007.

[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers" ("Mã định danh giao diện IPv6 được dành riêng"), RFC 5453, DOI 10.17487/RFC5453, 02/2009.

[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments" ("Xử lý các đoạn IPv6 chồng chéo"), RFC 5722, DOI 10.17487/RFC5722, 12/2009.

[RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols" ("Giao thức quản lý nhóm Internet nhẹ phiên bản 3 (IGMPv3) và giao thức khám phá lắng nghe phát quảng bá đa hướng phiên bản 2 (MLDv2)"), RFC 5790, DOI 10.17487/RFC5790, 02/2010.

[RFC5942] Singh, H , Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" ("Mô hình mạng con IPv6: Mối quan hệ giữa các liên kết và tiền tố mạng con"), RFC 5942, DOI 10.17487/RFC5942, 7/2010.

[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation" ("Khuyến nghị về cách thể hiện văn bản địa chỉ IPv6"), RFC 5952, DOI 10.17487/RFC5952, 8/2010.

...

...

...

[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification" ("Đặc điểm kỹ thuật nhãn luồng IPv6"), RFC 6437, DOI 10.17487/RFC6437, 11/2011).

[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and M. Bhatia, "A Uniform Format for IPv6 Extension Headers" ("Định dạng thống nhất cho tiêu đề mở rộng IPv6"), RFC 6564, DOI 10.17487/RFC6564, 4/2012.

[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)" ("Lựa chọn địa chỉ mặc định cho Giao thức Internet Phiên bản 6 (IPv6)"), RFC 6724, DOI 10.17487/RFC6724, 9/2012.

[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS" ("DNS phát quảng bá đa hướng"), RFC 6762, DOI 10.17487/RFC6762, 02/2013.

[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery" ("Khám phá dịch vụ dựa trên DNS"), RFC 6763, DOI 10.17487/RFC6763, 02/2013.

[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" ("Tối ưu hóa phát hiện lân cận cho IPv6 qua Mạng cá nhân không dây công suất thấp (6LoWPAN)"), RFC 6775, DOI 10.17487/RFC6775, 112012.

[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))" ("Cơ chế mở rộng cho DNS (EDNS(0))”), STD 75, RFC 6891, DOI 10.17487/RFC6891, 4/2013.

[RFC6946] Gont, F., "Processing of IPv6" ("Các phân mảnh "Nguyên tử" "), RFC 6946, DOI 10.17487/RFC6946, 5/2013.

[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers" ("Truyền và xử lý tiêu đề mở rộng IPv6"), RFC 7045, DOI 10.17487/RFC7045, 12/2013.

...

...

...

[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains" ("Ý nghĩa của chuỗi tiêu đề IPv6 quá khổ"), RFC 7112, DOI 10.17487/RFC7112, 01/2014.

[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" ("Một phương pháp tạo ra các định danh giao diện mờ ngữ nghĩa với tự động cấu hình địa chỉ phi trạng thái IPv6 (SLAAC)"), RFC 7217, DOI 10.17487/RFC7217, 4/2014.

[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)" ("Giao thức trao đổi khóa Internet phiên bản 2 (IKEv2)"), STD 79, RFC 7296, DOI 10.17487/RFC7296, 10/2014.

[RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E., and W. George, "Enhanced Duplicate Address Detection" ("Phát hiện địa chỉ trùng lặp nâng cao"), RFC 7527, DOI 10.17487/RFC7527, 4/015.

[RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss Resiliency for Router Solicitations" ("Khả năng phục hồi mất gói tin cho các yêu cầu của bộ định tuyến"), RFC 7559, DOI 10.17487/RFC7559, 5/2015.

[RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix Length Recommendation for Forwarding" ("Khuyến nghị về độ dài tiền tố IPv6 để chuyển tiếp"), BCP 198, RFC 7608, DOI 10.17487/RFC7608, 7/2015.

[RFC8021] Gont, F., Liu, W., and T. Anderson, "Generation of IPv6 Atomic Fragments Considered Harmful" ("Tạo ra các phân mảnh nguyên tử IPv6 được coi là có hại"), RFC 8021, DOI 10.17487/RFC8021, 01/2017.

[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by Hosts in a Multi-Prefix Network" ("Lựa chọn bộ định tuyến First-Hop của máy chủ trong mạng đa tiền tố"), RFC 8028, DOI 10.17487/RFC8028, 11/2016.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol" ("Giao thức RESTCONF"), RFC 8040, DOI 10.17487/RFC8040, 01/2017.

...

...

...

[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", ("Tùy chọn quảng bá bộ định tuyến IPv6 cho cấu hình DNS"), RFC 8106, DOI 10.17487/RFC8106, 3/2017.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" ("Sự mơ hồ giữa chữ hoa và chữ thường trong từ khóa RFC 2119"), BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5/2017.

[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification" ("Đặc điểm kỹ thuật của Giao thức Internet, Phiên bản 6 (IPv6)"), STD 86, RFC 8200, DOI 10.17487/RFC8200, 7/2017.

[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6" ("Khám phá MTU đường dẫn cho IP phiên bản 6"), STD 87, RFC 8201, DOI 10.17487/RFC8201, 7/2017.

[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. Kivinen, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)" ("Yêu cầu triển khai thuật toán mã hóa và hướng dẫn sử dụng để đóng gói tải trọng bảo mật (ESP) và tiêu đề xác thực (AH)"), RFC 8221, DOI 10.17487/RFC8221, 10/2017.

[RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, "Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)" ("Yêu cầu triển khai thuật toán và hướng dẫn sử dụng cho Giao thức trao đổi khóa Internet phiên bản 2 (IKEv2)"), RFC 8247, DOI 10.17487/RFC8247, 9/2017.

[RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management" ("Mô hình dữ liệu YANG cho quản lý giao diện"), RFC 8343, DOI 10.17487/RFC8343, 3/2018.

[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management" ("Mô hình dữ liệu YANG cho quản lý IP"), RFC 8344, DOI 10.17487/RFC8344, 3/2018.

3  Thuật ngữ và định nghĩa

...

...

...

Một thiết bị triển khai IPv6.

CHÚ THÍCH: Thuật ngữ thiết bị nút IPv6 (nút IPv6) tương đương với thuật ngữ nút mạng (Node) nêu tại Điều 3.1 trong TCVN 9802-1:2013.

3.2  Bộ định tuyến IPv6 (Router IPv6)

Một nút chuyển tiếp các gói tin IPv6 không được gửi trực tiếp cho nó.

CHÚ THÍCH: Thuật ngữ router IPv6 (router) tương đương với thuật ngữ bộ định tuyến (Router) nêu tại Điều 3.2 trong TCVN 9802-1:2013.

3.3  Máy chủ IPv6 (Host IPv6)

Bất kỳ thiết bị nút IPv6 nào không phải là bộ định tuyến.

CHỦ THÍCH: Thuật ngữ host IPv6 (host) tương đương với thuật ngữ máy chủ (host) nêu tại Điều 3.3 trong TCVN 9802-1:2013.

3.4  Địa chỉ liên kết cục bộ (link-local address)

...

...

...

3.5  Phát hiện nút mạng lân cận

Giao thức sử dụng để giải quyết các vấn đề liên quan đến sự tương tác giữa các nút mạng trên cùng một liên kết như phát hiện bộ định tuyến, phát hiện tiền tố, phân giải địa chỉ.

CHÚ THÍCH: Thuật ngữ nút mạng lân cận sử dụng trong Quy chuẩn này tương đương với thuật ngữ nút láng giềng sử dụng trong TCVN 9802-1:2013.

3.6  MTU liên kết (Link MTU)

Đơn vị truyền tải tối đa của một liên kết, tức là kích thước lớn nhất của một gói tin (tính bằng octet) có thể truyền tải được qua một liên kết.

3.7  MTU hướng/tuyến kết nối (Path MTU)

MTU liên kết nhỏ nhất trong tất cả các MTU liên kết trên một tuyến giữa nút nguồn và nút đích.

CHÚ THÍCH 1: Thuật ngữ MTU hướng/tuyến kết nối tương đương với thuật ngữ MTU tuyến nêu tại Điều 3.12 trong TCVN 9802-1:2013.

CHÚ THÍCH 2: Thuật ngữ tuyến sử dụng trong Quy chuẩn này tương đương với thuật ngữ đường truyền sử dụng trong TCVN 9802-1:2013.

...

...

...

Quá trình nút IPv6 xác định MTU hướng/tuyến kết nối.

3.9  Lựa chọn địa chỉ mặc định IPv6

Việc lựa chọn địa chỉ nguồn hay địa chỉ đích sử dụng mặc định để truyền thông tin trong trường hợp có nhiều địa chỉ khả dụng (nhiều địa chỉ trong một giao diện hoặc nhiều hướng đi khác nhau).

3.10  Tự động cấu hình địa chỉ phi trạng thái IPv6

Kỹ thuật cấu hình địa chỉ cho các máy chủ mà không cần cấu hình thủ công, chỉ yêu cầu cấu hình tối thiểu của các router và không cần máy chủ. Kỹ thuật tự động cấu hình địa chỉ phi trạng thái cho phép máy chủ tạo ra địa chỉ của máy chủ đó bằng cách kết hợp thông tin cục bộ của máy chủ (định danh giao diện) và thông tin quảng bá bởi router (tiền tố).

3.11  Phát hiện đối tượng nghe multicast (MLD)

Kỹ thuật cho phép router phát hiện các đối tượng nghe multicast (tức là các nút mong muốn nhận gói tin multicast) trên các liên kết gắn trực tiếp với router này và phát hiện những địa chỉ multicast nào mà các nút lân cận này quan tâm.

3.12  Công nghệ đường hầm

Công nghệ cho phép gửi các gói tin IP trên các gói tin IP. Ví dụ, đường hầm IPv6 qua IPv4 thực hiện đóng gói các gói tin IPv6 trong các gói tin IPv4 để truyền qua hạ tầng mạng định tuyến IPv4.

...

...

...

Các từ khóa "CẦN", "KHÔNG CẦN", "BẮT BUỘC", "SẼ", "KHÔNG ĐƯỢC", "NÊN", "KHÔNG NÊN", "KHUYẾN NGHỊ", "KHÔNG KHUYẾN NGHỊ", "CÓ THỂ" và "TÙY CHỌN" trong tiêu chuẩn này cần được hiểu như mô tả trong BCP 14 [RFC2119] [RFC8174] khi và chỉ khi, chúng xuất hiện bằng tất cả các chữ hoa, như được hiển thị ở đây.

4  Các từ viết tắt sử dụng trong tiêu chuẩn

AH

Authentication Header

Tiêu đề xác thực

DAD

Duplicate Address Detection

Phát hiện địa chỉ trùng lặp

ESP

...

...

...

Đóng gói tải tin bảo mật

ICMP

Internet Control Message Protocol

Giao thức bản tin kiểm soát Internet

IKE

Internet Key Exchange

Trao đổi khóa Internet

MIB

Management Information Base

...

...

...

MLD

Multicast Listener Discovery

Phát hiện trình nghe đa hướng

MTU

Maximum Transmission Unit

Đơn vị truyền tải tối đa/Kích thước gói tin lớn nhất

NA

Neighbor Advertisement

Quảng bá lân cận/Quảng bá đến nút mạng lân cận

...

...

...

Non-Broadcast Multi-Access

Đa truy cập không truyền phát quảng bá

ND

Neighbor Discovery

Phát hiện lân cận/Phát hiện nút mạng lân cận

NS

Neighbor Solicitation

Yêu cầu lân cận

NUD

...

...

...

Phát hiện không thể kết nối lân cận/Phát hiện không thể kết nối đến nút mạng lân cận

PPP

Point-to-Point Protocol

Giao thức điểm - điểm

5  Giới thiệu

Tiêu chuẩn này xác định chức năng chung cần thiết cho cả máy chủ và bộ định tuyến IPv6. Nhiều nút IPv6 sẽ triển khai các tính năng tùy chọn hoặc bổ sung, nhưng tiêu chuẩn này tập hợp và tổng hợp yêu cầu từ các tài liệu theo vết tiêu chuẩn đã được công bố ở nơi khác.

Tiêu chuẩn này cố gắng tránh thảo luận về chi tiết giao thức và tham chiếu tới các RFC cho mục đích này. Tiêu chuẩn này nhằm mục đích tuyên bố về khả năng áp dụng và cung cấp hướng dẫn về các thông số kỹ thuật IPv6 cần được thực hiện trong trường hợp chung và các thông số kỹ thuật nào có thể hữu ích cho các kịch bản triển khai cụ thể. Tiêu chuẩn này không cập nhật bất kỳ tài liệu giao thức riêng biệt nào của các RFC.

Mặc dù tiêu chuẩn này chỉ ra các thông số kỹ thuật khác nhau, nhưng cần lưu ý rằng trong nhiều trường hợp, mức độ chi tiết của một yêu cầu cụ thể sẽ nhỏ hơn so với một thông số kỹ thuật riêng biệt, vì nhiều thông số kỹ thuật xác định ghép hợp bởi nhiều phần độc lập, trong đó có một số phần có thể không bắt buộc. Ngoài ra, hầu hết các thông số kỹ thuật xác định cả hành vi của máy khách và máy chủ trong cùng một đặc tả, trong khi nhiều triển khai sẽ chỉ tập trung vào một trong hai vai trò đó.

Tiêu chuẩn này xác định mức yêu cầu tối thiểu cần thiết để một thiết bị cung cấp dịch vụ Internet hữu ích và xem xét một loạt các loại thiết bị và kịch bản triển khai. Bởi vì phạm vi triển khai rộng của các kịch bản, cho nên các yêu cầu tối thiểu được chỉ định trong tiêu chuẩn này có thể không đủ cho tất cả các kịch bản triển khai. Việc các hồ sơ khác xác định các yêu cầu bổ sung hoặc nghiêm ngặt hơn phù hợp với môi trường sử dụng và triển khai cụ thể là điều hoàn toàn hợp lý (và thực sự được mong đợi). Ví dụ, tiêu chuẩn này không bắt buộc tất cả các máy khách hỗ trợ DHCP, nhưng một số kịch bản triển khai có thể được coi đó yêu cầu như vậy là phù hợp. Theo một ví dụ khác, NIST đã xác định hồ sơ cho các yêu cầu chuyên biệt đối với IPv6 trong môi trường mục tiêu ([USGv6]).

...

...

...

Mô tả các nút IPv6: Từ tài liệu "Đặc tả Giao thức Internet, Phiên bản 6 (IPv6)" [RFC8200], chúng ta có các định nghĩa sau:

- Nút IPv6 - một thiết bị triển khai IPv6.

- Bộ định tuyến IPv6 - một nút chuyển tiếp các gói tin IPv6 không được gửi trực tiếp cho nó.

- Máy chủ IPv6 - bất kỳ nút IPv6 nào không phải là bộ định tuyến.

6  Lớp IP con

Một nút IPv6 CẦN hỗ trợ một hoặc nhiều thông số kỹ thuật về lớp liên kết IPv6. Việc triển khai các thông số kỹ thuật của lớp liên kết nào sẽ phụ thuộc vào các lớp liên kết mà phần cứng có sẵn trên hệ thống có thể hỗ trợ. Một nút IPv6 phù hợp có thể hỗ trợ IPv6 trên một số giao diện của nó mà không hỗ trợ trên các giao diện khác.

Khi IPv6 được triển khai trên các công nghệ Lớp 2 mới, dự kiến các thông số kỹ thuật mới sẽ được ban hành. Sau đây liệt kê một số công nghệ Lớp 2 mà thông số kỹ thuật IPv6 đã được phát triển. Danh sách này chỉ nhằm mục đích cung cấp thông tin và có thể không đầy đủ.

- Truyền gói tin IPv6 qua mạng Ethernet [RFC2464].

- Truyền gói tin IPv6 qua đặc tả mạng chuyển tiếp khung (Frame Relay Networks) [RFC2590].

...

...

...

- Truyền gói tin IPv6, IPv4 và gói giao thức phân giải địa chỉ (ARP) qua kênh sợi quang [RFC4338].

- Truyền gói tin IPv6 qua mạng IEEE 802.15.4 [RFC4944].

- Truyền IPv6 qua Lớp con hội tụ IPv6 trên Mạng IEEE 802.16 [RFC5121].

- IP phiên bản 6 trên PPP [RFC5072].

Ngoài các lớp liên kết vật lý truyền thống, cũng có thể tạo đường hầm IPv6 qua các giao thức khác. Các ví dụ bao gồm:

- Teredo: Đường hầm IPv6 trên UDP thông qua dịch địa chỉ mạng (NAT) [RFC4380].

- Các cơ chế chuyển tiếp cơ bản cho máy chủ và bộ định tuyến IPv6 (xem Điều 3 của [RFC4213]).

7  Lớp IP

7.1  Giao thức Internet phiên bản 6 - RFC 8200

...

...

...

Thiết bị nút CẦN tuân theo các quy tắc truyền gói tin trong RFC 8200.

Tất cả các triển khai IPv6 tuân thủ CẦN có khả năng gửi và nhận gói tin IPv6; chức năng chuyển tiếp CÓ THỂ được hỗ trợ. Các nút CẦN luôn có khả năng gửi, nhận và xử lý các tiêu đề phân mảnh.

Nút IPv6 KHÔNG ĐƯỢC tạo các phân mảnh chồng lấp. Ngoài ra, khi tập hợp lại một gói dữ liệu IPv6, nếu phát hiện một hoặc nhiều phân mảnh cấu thành của nó được xác định là phân mảnh chồng lắp, thì toàn bộ gói dữ liệu (và bất kỳ phân mảnh nào khác) CẦN bị loại bỏ một cách lặng lẽ. Xem [RFC5722] để biết thêm thông tin.

Theo khuyến nghị trong [RFC8021], các thiết bị nút KHÔNG ĐƯỢC tạo ra các phân mảnh nguyên tử, tức là, khi phân mảnh là toàn bộ gói dữ liệu. Theo [RFC6946], nếu một nút nhận đang lắp ráp lại một gói dữ liệu gặp phải một phân mảnh nguyên tử, thì nó sẽ được xử lý như một gói tin được lắp ráp lại hoàn chỉnh, và bất kỳ phân mảnh nào khác phù hợp với gói tin này sẽ được xử lý độc lập.

Để giảm thiểu một loạt các cuộc tấn công tiềm tàng, các nút NÊN tránh sử dụng các giá trị định danh phân mảnh có thể dự đoán được trong các tiêu đề phân mảnh, như được thảo luận trong [RFC7739].

Tất cả các thiết bị nút NÊN hỗ trợ thiết lập và sử dụng trường nhãn luồng IPv6 như được định nghĩa trong thông số kỹ thuật nhãn luồng IPv6 [RFC6437]. Các nút chuyển tiếp như bộ định tuyến và bộ phân phối tải KHÔNG CẦN chỉ phụ thuộc vào các giá trị nhãn luồng được phân phối đồng đều. KHUYẾN NGHỊ rằng các máy chủ nguồn hỗ trợ nhãn luồng bằng cách đặt trường nhãn luồng cho tất cả các gói tin của một luồng nhất định thành cùng một giá trị được chọn từ một giá trị gần đúng đến một phân phối đồng nhất rời rạc.

7.2  Hỗ trợ tiêu đề mở rộng IPv6

RFC 8200 quy định các tiêu đề mở rộng và cách xử lý các tiêu đề này.

Các tiêu đề mở rộng (ngoại trừ tiêu đề tùy chọn chặng tới chặng) không được xử lý, chèn hoặc xóa bởi bất kỳ nút nào dọc theo đường truyền của gói tin, cho đến khi gói tin đến nút (hoặc mỗi nút trong tập hợp các nút, trong trường hợp đa hướng) được xác định trong trường địa chỉ đích của tiêu đề IPv6.

...

...

...

Một thiết bị nút IPv6 CẦN có khả năng xử lý các tiêu đề mở rộng này. Ngoại trừ là tiêu đề định tuyến loại 0 (RH0), đã bị loại bỏ bởi [RFC5095] do liên quan đến bảo mật và CẦN được coi là một loại định tuyến không được công nhận.

Ngoài ra, [RFC7045] bổ sung các yêu cầu cụ thể cho việc xử lý các tiêu đề mở rộng, đặc biệt là bất kỳ nút chuyển tiếp nào dọc theo đường truyền của gói tin IPv6, nếu chuyển tiếp gói tin vì bất kỳ lý do gì, NÊN làm như vậy bất kể có sự hiện diện của bất kỳ tiêu đề mở rộng nào.

Theo RFC 8200, khi một nút phân mảnh một gói dữ liệu IPv6, nó CẦN bao gồm toàn bộ chuỗi tiêu đề IPv6 trong phân mảnh đầu tiên. Các tiêu đề mỗi phân mảnh CẦN bao gồm tiêu đề IPv6 cùng với bất kỳ tiêu đề mở rộng nào CẦN được xử lý bởi các nút trên đường đến đích, tức là, tất cả các tiêu đề ở trên và bao gồm cả tiêu đề định tuyến nếu có, nếu không có tiêu đề tùy chọn từng chặng, thì không có tiêu đề mở rộng. Khi lắp ráp lại, nếu phân mảnh đầu tiên không bao gồm tất cả các tiêu đề thông qua một tiêu đề lớp trên, thì phân mảnh đó NÊN bị loại bỏ và một vấn đề tham số ICMP, Mã 3, bản tin NÊN được gửi đến nguồn của phân mảnh đó, với trường con trỏ được đặt thành không. Xem [RFC7112] để biết thêm thông tin về lý do tại sao nên tránh mở rộng quá khổ các chuỗi tiêu đề IPv6.

Không khuyến nghị định nghĩa tiêu đề mở rộng IPv6 mới, trừ khi không có tiêu đề mở rộng IPv6 hiện có nào có thể được sử dụng bằng cách quy định một tùy chọn mới cho tiêu đề mở rộng IPv6 đó. Một đề xuất để quy định một tiêu đề mở rộng IPv6 mới CẦN bao gồm một giải thích kỹ thuật chi tiết về lý do tại sao một tiêu đề mở rộng IPv6 hiện có không thể được sử dụng cho chức năng mới mong muốn, và trong những trường hợp như vậy, cần tuân theo định dạng được mô tả trong Điều 8 của RFC 8200 để biết thêm thông tin cơ bản về chủ đề này, xem [RFC6564].

7.3  Bảo vệ nút khỏi các tùy chọn tiêu đề mở rộng quá mức

Theo RFC 8200, các máy chủ đầu cuối được mong đợi sẽ xử lý tất cả các tiêu đề mở rộng, tùy chọn đích và tùy chọn từng chặng trong một gói tin. Do giới hạn duy nhất về số lượng và kích thước của các tiêu đề mở rộng là MTU, nên việc xử lý các gói tin nhận được có thể khá lớn. Ngoài ra, cũng có thể hình dung rằng một chuỗi dài các tiêu đề mở rộng có thể được sử dụng như một hình thức tấn công từ chối dịch vụ. Theo đó, một máy chủ có thể đặt giới hạn về số lượng và kích thước của các tiêu đề mở rộng và các tùy chọn mà nó sẵn sàng xử lý.

Một máy chủ CÓ THỂ giới hạn số lượng tùy chọn PAD1 liên tiếp trong các tùy chọn đích hoặc các tùy chọn từng chặng là 7. Trong trường hợp này, nếu có nhiều hơn 7 tùy chọn PAD1 liên tiếp, thì gói tin CÓ THỂ bị loại bỏ lặng lẽ. Lý do là nếu yêu cầu có đệm từ 8 bytes trở lên, thì tùy chọn PADN NÊN được sử dụng.

Một máy chủ CÓ THỂ giới hạn số byte trong tùy chọn một PADN nhỏ hơn 8. Trong trường hợp như vậy, nếu có một tùy chọn PADN có độ dài lớn hơn 7, thì gói tin NÊN bị loại bỏ lặng lẽ. Cơ sở lý luận của hướng dẫn này đó là mục đích của phần đệm để căn chỉnh và byte 8 là căn chỉnh tối đa được sử dụng trong IPv6.

Một máy chủ CÓ THỂ không cho phép các tùy chọn không được nhận dạng trong các tùy chọn đích hoặc các tùy chọn từng chặng. Điều này NÊN được cấu hình, với mặc định là chấp nhận các tùy chọn không được nhận dạng và xử lý chúng theo [RFC8200]. Nếu một gói tin có các tùy chọn không được nhận dạng và máy chủ được cấu hình để không cho phép chúng, thì gói tin NÊN bị loại bỏ lặng lẽ.

...

...

...

Một máy chủ CÓ THỂ áp đặt giới hạn về độ dài tối đa của các tiêu đề mở rộng tùy chọn đích hoặc tùy chọn từng chặng. Giá trị này NÊN có thể cấu hình, và mặc định là chấp nhận các tùy chọn với bất kỳ độ dài nào. Nếu một gói được thu nhận và độ dài của tiêu đề mở rộng tùy chọn đích hoặc từng chặng vượt quá giới hạn độ dài, thì gói NÊN bị loại bỏ lặng lẽ.

7.4  Khám phá nút mạng lân cận cho IPv6 - RFC 4861

Khám phá nút mạng lân cận được định nghĩa trong [RFC4861]; định nghĩa này đã được cập nhật bởi [RFC5942]. Khám phá nút mạng lân cận CẦN được hỗ trợ với các ngoại lệ được lưu ý dưới đây. RFC 4861 nêu rõ:

- Trừ khi được quy định khác (trong một tài liệu bao gồm việc vận hành IP trên một loại liên kết cụ thể), tiêu chuẩn này áp dụng cho tất cả các loại liên kết. Tuy nhiên, bởi vì ND sử dụng tầng liên kết đa hướng cho một số dịch vụ của nó, cho nên có thể trên một số loại liên kết (ví dụ: các liên kết đa truy nhập không phát quảng bá (NBMA)), các giao thức hoặc cơ chế thay thế để triển khai các dịch vụ đó sẽ được quy định (trong tài liệu phù hợp đề cập đến việc vận hành IP trên một loại liên kết cụ thể). Các dịch vụ được mô tả trong tiêu chuẩn này không phụ thuộc trực tiếp vào truyền phát đa hướng, chẳng hạn như chuyển hướng, xác định chặng tiếp theo, khám phá không thể kết nối đến nút mạng lân cận, v.v..., dự kiến sẽ được cung cấp như quy định trong tiêu chuẩn này. Chi tiết về cách sử dụng ND trên các liên kết NBMA được đề cập trong [RFC2491].

Một số phân tích chi tiết của khám phá nút mạng lân cận như sau:

- Khám phá bộ định tuyến là cách các máy chủ định vị các bộ định tuyến nằm trên một liên kết đã kết nối. Các máy chủ CẦN hỗ trợ chức năng khám phá bộ định tuyến.

- Khám phá tiền tố là cách các máy chủ khám phá tập hợp các tiền tố địa chỉ để xác định đích đến nào nằm trên cùng một liên kết đã kết nối. Máy chủ CẦN hỗ trợ khám phá tiền tố.

- Các máy chủ cũng CẦN thực hiện khám phá không thể kết nối đến nút mạng lân cận (NUD) cho tất cả các đường dẫn giữa máy chủ và các nút lân cận. NUD không yêu cầu bắt buộc đối với đường dẫn giữa các bộ định tuyến. Tuy nhiên, tất cả các nút CẦN phản hồi các bản tin yêu cầu lân cận (NS) đơn hướng.

- [RFC7048] thảo luận về NUD, trong những trường hợp đặc biệt khi nó ứng xử quá nôn nóng. Nó quy định rằng nếu một nút truyền nhiều hơn một số gói tin nhất định, thì nó NÊN sử dụng bộ định thời truyền lại theo hàm mũ, lên đến một điểm ngưỡng nhất định.

...

...

...

[RFC7559] thảo luận về khả năng phục hồi mất gói tin đối với các yêu cầu định tuyến và yêu cầu rằng các nút CẦN sử dụng thuật toán lùi lại theo hàm mũ cụ thể để truyền lại các yêu cầu định tuyến.

Tất cả các nút CẦN hỗ trợ gửi và nhận các bản tin yêu cầu lân cận (NS) và phát quảng bá lân cận (NA). Các bản tin NS và NA được yêu cầu để phát hiện địa chỉ trùng lặp (DAD).

Các máy chủ NÊN hỗ trợ việc xử lý chức năng chuyển hướng. Các bộ định tuyến CẦN hỗ trợ gửi các chuyển hướng, mặc dù không nhất thiết cho từng gói tin riêng lẻ (ví dụ: do giới hạn tốc độ). Chuyển hướng chỉ hữu ích trên các mạng hỗ trợ máy chủ. Trong các mạng lõi chủ yếu là định tuyến, chuyển hướng thường bị vô hiệu hóa. Việc gửi chuyển hướng NÊN bị vô hiệu hóa theo mặc định trên các bộ định tuyến dự định triển khai trên các mạng lõi. Chúng CÓ THỂ được bật mặc định trên các bộ định tuyến nhằm hỗ trợ máy chủ trên các mạng biên.

Như được quy định trong [RFC6980], các nút KHÔNG ĐƯỢC sử dụng phân mảnh IPv6 để gửi bất kỳ bản tin khám phán lân cận và khám phán lân cận an toàn nào sau đây: Yêu cầu lân cận, phát quảng bá lân cận, yêu cầu định tuyến, phát quảng bá định tuyến, chuyển hướng, hoặc xác nhận yêu cầu tuyến kết nối. Các nút CẦN im lặng bỏ qua bất kỳ bản tin nào trong số này khi nhận được nếu bị phân mảnh. Xem RFC 6980 để biết chi tiết và thúc đẩy.

"Chia sẻ tải từ máy chủ đến bộ định tuyến IPv6" [RFC4311] bao gồm các khuyến nghị bổ sung về cách lựa chọn từ một tập hợp các bộ định tuyến có sẵn. [RFC4311] NÊN được hỗ trợ.

7.5  Khám phá lân cận an toàn/Khám phán nút mạng lân cận an toàn (SEND) - RFC 3971

SEND [RFC3971] và địa chỉ sinh mã hóa (CGA) [RFC3972] cung cấp một phương thức bảo mật trao đổi bản tin khám phá lân cận. SEND có khả năng giải quyết một số loại tấn công giả mạo nhất định, nhưng nó không cung cấp biện pháp bảo vệ cụ thể đối với các mối đe dọa từ những kẻ tấn công ngoài liên kết.

Đã có rất ít triển khai SEND trong các hệ điều hành và nền tảng thông dụng kể từ khi nó được công bố năm 2005; do đó, cho đến nay kinh nghiệm triển khai vẫn còn rất hạn chế.

Hiện tại, hỗ trợ SEND được coi là tùy chọn. Do sự phức tạp triển khai SEND và sự nặng nề trong cung cấp, nên việc triển khai nó chỉ có thể được xem xét khi các nút đang hoạt động trong một môi trường bảo mật đặc biệt nghiêm ngặt.

...

...

...

Các quảng bá định tuyến bao gồm một trường 8-bit cờ quảng bá định tuyến một-bit. Tùy chọn cờ quảng bá định tuyến mở rộng số bit cờ có sẵn lên thêm 48 bit. Tại thời điểm công bố tiêu chuẩn này, 6 trong số 8 cờ bit đơn ban đầu đã được gán, trong khi 2 cờ vẫn còn sẵn sàng cho việc gán trong tương lai. Hiện tại chưa có cờ nào được định nghĩa để sử dụng tùy chọn mới; do đó, nói một cách chính xác, không có yêu cầu nào cần triển khai tùy chọn này hiện nay. Tuy nhiên, các triển khai có khả năng truyền các tùy chọn không được công nhận cho một thực thể cấp cao hơn để có thể hiểu được chúng (ví dụ: quy trình cấp người dùng sử dụng cơ sở "ổ cắm thô") CÓ THỂ thực hiện các bước để xử lý tùy chọn này nhằm chuẩn bị cho việc sử dụng trong tương lai.

7.7  Khám phá MTU hướng/tuyến kết nối (Path MTU) và kích cỡ gói

7.7.1  Khám phá MTU hướng/tuyến kết nối - RFC 8201

"Khám phá MTU hướng/tuyến kết nối đối với IP phiên bản 6" [RFC8201] NÊN được hỗ trợ. Theo [RFC8200]:

- Khuyến nghị rằng các nút IPv6 nên triển khai phát hiện MTU hướng/tuyến kết nối [RFC8201], để khám phá và tận dụng các MTU hướng/tuyến kết nối lớn hơn 1280 octet. Tuy nhiên, việc triển khai IPv6 tối thiểu (ví dụ: trong một ROM khởi động) có thể chỉ đơn giản là gửi các gói tin không lớn hơn 1280 octet và bỏ qua việc triển khai khám phá MTU hướng/tuyến kết nối.

Các quy tắc trong [RFC8200] và [RFC5722] CẦN được tuân thủ cho việc phân mảnh và lắp ráp lại gói tin.

Như được mô tả trong RFC 8201, các nút triển khai khám phá MTU hướng/tuyến kết nối và gửi các gói tin lớn hơn MTU liên kết tối thiểu IPv6 có thể gặp phải sự cố kết nối nếu các bản tin ICMPv6 bị chặn hoặc không được truyền. Ví dụ: điều này sẽ dẫn đến kết nối hoàn thành quá trình bắt tay ba bước TCP một cách chính xác nhưng sau đó bị treo khi dữ liệu được truyền. Trạng thái này được gọi là kết nối lỗ đen [RFC2923]. Khám phá MTU hướng/tuyến kết nối dựa trên gói tin quá lớn (PTB) ICMPv6 để xác định MTU hướng/tuyến kết nối (và do đó các thông báo này KHÔNG được lọc, theo khuyến nghị trong [RFC4890]).

Một phương pháp thay thế cho khám phá MTU hướng/tuyến kết nối được định nghĩa trong RFC 8201 có thể được tìm thấy trong [RFC4821], phương pháp này định nghĩa một phương thức khám phá MTU hướng/tuyến kết nối lớp đóng gói (PLPMTUD) được thiết kế để sử dụng trên các đường dẫn nơi mà việc phân phối bản tin ICMPv6 tới máy chủ không được đảm bảo.

7.7.2  Xem xét MTU tối thiểu

...

...

...

7.8  ICMP cho giao thức Internet phiên bản 6 (IPv6) - RFC 4443

ICMPv6 [RFC4443] CẦN được hỗ trợ. "ICMP được mở rộng để hỗ trợ bản tin nhiều phần" [RFC4884] CÓ THỂ được hỗ trợ.

7.9  Ưu tiên bộ định tuyến mặc định và các bộ định tuyến đặc trưng hơn - RFC 4191

"Ưu tiên bộ định tuyến mặc định và các bộ định tuyến đặc trưng hơn" [RFC4191] cung cấp hỗ trợ cho các nút kết nối với nhiều mạng (khác nhau), mỗi mạng cung cấp các bộ định tuyến tự quảng bá như là bộ định tuyến mặc định thông qua quảng bá định tuyến. Trong một số trường hợp, một bộ định tuyến có thể cung cấp kết nối đến các đích mà bộ định tuyến khác không thể, và việc lựa chọn bộ định tuyến mặc định "sai" có thể dẫn đến thất bại trong khả năng tiếp cận. Để giải quyết tình huống này, các nút IPv6 CẦN triển khai [RFC4191] và NÊN triển khai vai trò máy chủ loại C được định nghĩa trong RFC 4191.

7.10  Lựa chọn bộ định tuyến chặng đầu tiên - RFC 8028

Trong các kịch bản đa mạng, nơi một máy chủ có nhiều hơn một tiền tố, mỗi tiền tố được cấp phân bởi một mạng luồng lên được giả định triển khai lọc xâm nhập BCP 38, máy chủ có thể có nhiều bộ định tuyến để lựa chọn.

Các máy chủ có thể được triển khai trong môi trường đa mạng như vậy NÊN tuân theo hướng dẫn được đưa ra trong [RFC8028].

7.11  Khám phá lắng nghe phát đa hướng (MLD) cho IPv6 - RFC 3810

Các nút cần tham gia nhóm phát đa hướng CẦN hỗ trợ MLDv2 [RFC3810]. MLD là cần thiết cho bất kỳ nút nào dự kiến sẽ nhận và xử lý lưu lượng phát đa hướng; đặc biệt, MLDv2 được yêu cầu để hỗ trợ cho phát đa hướng theo nguồn cụ thể (SSM) theo [RFC4607].

...

...

...

Lưu ý rằng khám phá lân cận (được sử dụng trên hầu hết các loại liên kết - xem 7.4) tùy thuộc vào phát đa hướng và yêu cầu các nút tham gia vào nút được yêu cầu địa chỉ phát đa hướng.

7.12 Thông báo tình trạng tắc nghẽn (ECN) - RFC 3168

Một bộ định tuyến nhận biết ECN đặt một nhãn trong tiêu đề IP để báo hiệu tắc nghẽn sắp xảy ra, thay vì bỏ qua một gói tin. Nút thu gói tin sẽ phản hồi lại thông báo tình trạng tắc nghẽn tới nút gửi, sau đó có thể giảm tốc độ truyền của nó như thể nó đã phát hiện ra một gói tin bị rớt.

Các nút NÊN hỗ trợ ECN [RFC3168] bằng cách triển khai một giao diện cho lớp trên truy cập và bằng cách đặt các bit ECN trong tiêu đề IP. Các lợi ích của việc sử dụng ECN được ghi nhận trong [RFC8087].

8  Định địa chỉ và cấu hình địa chỉ

8.1  Kiến trúc định địa chỉ IP phiên bản 6 - RFC 4291

Kiến trúc định địa chỉ IPv6 [RFC4291] CẦN được hỗ trợ.

Kiến trúc địa chỉ IPv6 hiện tại dựa trên giới hạn 64 bits cho các tiền tố mạng con. Lý do cho quyết định này được giải thích trong [RFC7421].

Việc triển khai cũng CẦN hỗ trợ các cập nhật cờ phát đa hướng được ghi lại trong [RFC7371].

...

...

...

Các máy chủ có thể được cấu hình địa chỉ thông qua nhiều phương pháp khác nhau, bao gồm tự động cấu hình địa chỉ phi trạng thái (SLAAC), DHCPv6, hoặc cấu hình thủ công.

[RFC7934] khuyến nghị rằng các mạng cung cấp các máy chủ đầu cuối có mục đích chung nhiều địa chỉ IPv6 toàn cầu khi chúng kết nối, và nó mô tả các lợi ích cũng như các tùy chọn để thực hiện điều này. Bộ định tuyến NÊN hỗ trợ [RFC7934] để gán nhiều địa chỉ cho một máy chủ. Một máy chủ NÊN hỗ trợ gán nhiều địa chỉ như được mô tả trong [RFC7934].

Các thiết bị nút NÊN hỗ trợ khả năng được gán một tiền tố cho mỗi máy chủ như được ghi nhận trong [RFC8273]. Phương pháp này có thể cải thiện khả năng cách ly máy chủ và nâng cao quản lý thuê bao trên các phân đoạn mạng được chia sẻ.

8.3  Tự động cấu hình địa chỉ phi trạng thái IPv6 - RFC 4862

Các máy chủ CẦN hỗ trợ tự động cấu hình địa chỉ phi trạng thái IPv6. Điều đó được KHUYẾN NGHỊ như được mô tả trong [RFC8064], trừ khi có một yêu cầu cụ thể cho việc nhúng địa chỉ kiểm soát truy cập phương tiện (MAC) vào trong một định danh giao diện (IID), các nút sẽ tuân theo quy trình trong [RFC7217] để tạo địa chỉ dựa trên SLAAC, thay vì sử dụng [RFC4862]. Địa chỉ được tạo ra theo phương pháp mô tả trong [RFC7217] sẽ giống nhau mỗi khi một thiết bị nhất định xuất hiện (xuất hiện lại) trên cùng một mạng con (với một tiền tố IPv6 cụ thể), nhưng IID sẽ thay đổi trên mỗi mạng con tạm trú.

Các nút là bộ định tuyến CẦN có khả năng tạo địa chỉ liên kết cục bộ như được mô tả trong [RFC4862].

Từ RFC 4862: Quá trình tự động định cấu hình được quy định trong tiêu chuẩn này chỉ áp dụng cho các máy chủ chứ không cần áp dụng cho các bộ định tuyến. Vì tự động cấu hình máy chủ sử dụng thông tin được quảng bá bởi các bộ định tuyến, nên các bộ định tuyến sẽ cần được cấu hình bằng một số phương tiện khác. Tuy nhiên, kỳ vọng rằng các bộ định tuyến sẽ tạo ra địa chỉ liên kết cục bộ bằng cách sử dụng cơ chế được mô tả trong tiêu chuẩn này. Ngoài ra, các bộ định tuyến cũng được mong đợi sẽ thành công thông qua quy trình phát hiện địa chỉ trùng lặp được mô tả trong tiêu chuẩn này cho tất cả các địa chỉ trước khi gán chúng vào một giao diện.

Tất cả các nút CẦN triển khai phát hiện địa chỉ trùng lặp. Trích dẫn từ Điều 5.4 của RFC 4862:

- Phát hiện địa chỉ trùng lặp CẦN được thực hiện trên tất cả các địa chỉ phát đơn hướng trước khi gán chúng vào một giao diện, bất kể chúng được lấy qua tự động cấu hình phi trạng thái, DHCPv6, hay cấu hình thủ công, với một số ngoại lệ sau [được lưu ý trong đó].

...

...

...

[RFC7527] thảo luận về DAD nâng cao và mô tả một thuật toán tự động hóa phát hiện các bản tin ND IPv6 lặp lại được sử dụng bởi DAD. Các nút NÊN thực hiện hành vi này tại những nơi phát hiện như vậy là có lợi.

8.4  Mở rộng quyền riêng tư cho cấu hình địa chỉ trong IPv6 - RFC 4941

Một nút sử dụng tự động cấu hình địa chỉ phi trạng thái [RFC4862] để tạo địa chỉ IPv6 toàn cầu duy nhất ở đó sử dụng địa chỉ MAC của nó để tạo ra IID sẽ thấy rằng IID vẫn giữ nguyên trên bất kỳ mạng tạm trú nào, ngay cả khi phần tiền tố mạng của thay đổi. Do đó, có thể xảy ra một thiết bị của bên thứ ba có thể theo dõi hoạt động của thiết bị nút mà chúng giao tiếp với nhau, khi nút đó di chuyển xung quanh mạng. Mở rộng quyền riêng tư cho tự động cấu hình địa chỉ phi trạng thái [RFC4941] giải quyết mối lo ngại này bằng cách cho phép các nút cấu hình bổ sung địa chỉ tạm thời, nơi IID được tạo ra ngẫu nhiên một cách hiệu quả. Địa chỉ riêng tư sau đó được sử dụng làm địa chỉ nguồn cho các giao tiếp mới do thiết bị nút khởi tạo.

Các vấn đề chung liên quan đến quyền riêng tư đối với địa chỉ IPv6 được thảo luận trong [RFC7721].

RFC 4941 NÊN được hỗ trợ. Trong một số trường hợp, chẳng hạn như máy chủ chuyên dụng trong một trung tâm dữ liệu, nó cung cấp lợi ích hạn chế hoặc không có lợi ích, hoặc nó có thể gây phức tạp cho quản lý mạng. Do đó, các thiết bị thực thi thông số kỹ thuật này CẦN cung cấp cách thức rõ ràng cho người dùng cuối để có thể được phép hoặc không được phép sử dụng các địa chỉ tạm thời này.

Lưu ý rằng RFC 4941 có thể được sử dụng độc lập với SLAAC truyền thống hoặc sự độc lập của SLAAC dựa trên RFC 7217.

Những triển khai RFC 4941 nên biết rằng các địa chỉ nhất định đã được dành riêng trước và không nên được lựa chọn để sử dụng làm địa chỉ tạm thời. Tham khảo "Các nhận dạng giao diện IPv6 dành riêng" [RFC5453] để biết thêm chi tiết.

8.5  Tự động định cấu hình địa chỉ trạng thái (DHCPv6) - RFC 3315

DHCPv6 [RFC3315] có thể được sử dụng để lấy và cấu hình địa chỉ. Nói chung, một mạng có thể cung cấp cấu hình địa chỉ thông qua SLAAC, DHCPv6 hoặc cả hai. Sẽ có nhiều mô hình triển khai IPv6 và các yêu cầu khác nhau về gán địa chỉ, một số trong đó có thể yêu cầu DHCPv6 để gán địa chỉ trạng thái. Do đó, tất cả các máy chủ NÊN thực hiện cấu hình địa chỉ thông qua DHCPv6.

...

...

...

Ở những nơi thiết bị có khả năng được người dùng mang theo và được gắn vào nhiều mạng tạm trú, các hồ sơ ẩn danh máy khách DHCPv6 NÊN được hỗ trợ như mô tả trong [RFC7844] để giảm thiểu việc tiết lộ thông tin nhận dạng. Điều 5 của RFC 7844 mô tả các cân nhắc hoạt động khi sử dụng các hồ sơ ẩn danh như vậy.

8.6  Lựa chọn địa chỉ mặc định cho IPv6 - RFC 6724

Các nút IPv6 sẽ luôn có nhiều địa chỉ được cấu hình đồng thời và do đó cần lựa chọn địa chỉ nào để sử dụng cho các giao tiếp nào. Các quy tắc được quy định trong lựa chọn địa chỉ mặc định cho tài liệu IPv6 [RFC6724] CẦN được thực hiện. [RFC8028] cập nhật quy tắc 5.5 từ [RFC6724]; các triển khai NÊN thực hiện quy tắc này.

9  Hệ thống tên miền (DNS)

DNS được mô tả trong [RFC1034], [RFC1035], [RFC3363] và [RFC3596]. Không phải tất cả các nút) đều cần phân giải tên miền; những nút đó không bao giờ cần phân giải tên miền DNS, không cần thực hiện chức năng phân giải. Tuy nhiên, khả năng phân giải tên miền là một chức năng của cơ sở hạ tầng cơ bản mà các ứng dụng dựa vào, và hầu hết các nút đều cần hỗ trợ cung cấp. Tất cả các nút NÊN triển khai chức năng [RFC1034] phân giải tạm thời, như trong Điều 5.3.1 của [RFC1034], với sự hỗ trợ cho:

- Bản ghi tài nguyên loại AAAA [RFC3596];

- Định địa chỉ ngược trong ip6.arpa bằng cách sử dụng bản ghi PTR [RFC3596]; và

- Cơ chế mở rộng cho DNS (EDNS (0)) [RFC6891] để cho phép kích cỡ gói DNS lớn hơn 512 octet.

Các nút đó được KHUYẾN NGHỊ hỗ trợ các phần mở rộng bảo mật DNS [RFC4033] [RFC4034] [RFC4035].

...

...

...

10  Định cấu hình không có địa chỉ thông tin

10.1  DHCP cho thông tin cấu hình khác

DHCP [RFC3315] quy định một cơ chế để các nút IPv6 lấy thông tin cấu hình địa chỉ (xem 8.5) và để lấy thêm các cấu hình khác (không địa chỉ). Nếu một máy chủ triển khai hỗ trợ các ứng dụng hoặc giao thức khác yêu cầu cấu hình chỉ khả dụng qua DHCP, thì các máy chủ NÊN triển khai DHCP. Đối với các thiết bị chuyên dụng không cần cấu hình như vậy, DHCP có thể là không cần thiết.

Một nút IPv6 có thể sử dụng tập hợp con của DHCP (được mô tả trong [RFC3736]) để lấy thông tin cấu hình khác.

Nếu một nút IPv6 triển khai DHCP, nó CẦN triển khai các tùy chọn DNS [RFC3646] vì hầu hết các triển khai sẽ mong muốn rằng các tùy chọn này là khả dụng.

10.2  Phát quảng bá định tuyến và cổng mặc định

Không có tùy chọn cổng DHCPv6 nào được xác định.

Các nút sử dụng giao thức cấu hình máy chủ động cho IPv6 (DHCPv6) được mong đợi sẽ xác định thông tin định tuyến mặc định và thông tin tiền tố trên liên kết từ các phát quảng bá định tuyến nhận được.

10.3  Tùy chọn phát quảng bá định tuyến IPv6 cho cấu hình DNS - RFC 8106

...

...

...

Các triển khai CẦN bao gồm hỗ trợ cho tùy chọn RA DNS [RFC8106].

10.4 Các tùy chọn DHCP so với tùy chọn phát quảng bá định tuyến cho cấu hình máy chủ

Trong IPv6, có hai cơ chế giao thức chính để truyền thông tin cấu hình đến máy chủ: các RA và DHCP. Các tùy chọn RA đã bị giới hạn với những tùy chọn được coi là cần thiết cho chức năng mạng cơ bản và tất cả các nút được cấu hình với thông tin giống hệt nhau. Ví dụ bao gồm các tùy chọn thông tin tiền tố, tùy chọn MTU, v.v... Mặt khác, DHCP thường được ưu tiên để cấu hình các tham số chung hơn và cho các tham số có thể là cụ thể cho máy khách. Tuy nhiên, nói chung, đã mong muốn xác định một cơ chế để cấu hình tùy chọn nhất định, thay vì xác định nhiều cách (khác nhau) để cấu hình thông tin như nhau.

Một vấn đề với việc có nhiều cách để cấu hình thông tin như nhau đó là tính tương tác giữa các hệ thống sẽ giảm nếu một máy chủ lựa chọn một cơ chế nhưng nhà khai thác mạng lại chọn một cơ chế khác. Đối với môi trường "đóng", nơi nhà khai thác mạng có ảnh hưởng đáng kể đến những thiết bị nào kết nối với mạng và do đó cơ chế cấu hình nào được hỗ trợ, nhà khai thác có thể đảm bảo rằng một cơ chế cụ thể được hỗ trợ bởi tất cả các máy chủ kết nối. Tuy nhiên, trong các môi trường mở hơn, nơi các thiết bị tùy chọn có thể kết nối (ví dụ: điểm phát sóng Wi-Fi), có thể phát sinh các vấn đề. Để tối đa hóa tính tương tác trong môi trường như vậy, máy chủ sẽ cần triển khai nhiều cơ chế cấu hình để đảm bảo khả năng tương tác.

11  Các giao thức phát hiện dịch vụ

DNS truyền phát đa hướng (mDNS) và phát hiện dịch vụ dựa trên DNS (DNS-SD) được mô tả tương ứng trong [RFC6762] và [RFC6763]. Các giao thức này, thường được gọi chung là giao thức 'Lời chào' sau khi được Apple đặt tên cho chúng, cung cấp phương tiện để các thiết bị để phát hiện các dịch vụ trong một liên kết cục bộ, và trong trường hợp không có dịch vụ DNS truyền phát đơn hướng, để trao đổi thông tin tên miền.

Trường hợp các thiết bị được triển khai trong các mạng mà việc phát hiện dịch vụ sẽ có lợi, mDNS và DNS-SD NÊN được hỗ trợ, ví dụ: đối với những người dùng tìm cách phát hiện máy in hoặc thiết bị hiển thị.

12  Hỗ trợ và chuyển đổi IPv4

Các nút IPv6 CÓ THỂ hỗ trợ IPv4.

...

...

...

Cơ chế chuyển đổi cơ bản cho các máy chủ và bộ định tuyến IPv6 - RFC 4213

Nếu một nút IPv6 triển khai cả hai ngăn xếp và đường hầm, thì [RFC4213] CẦN được hỗ trợ.

13  Hỗ trợ ứng dụng

13.1  Thể hiện dạng văn bản địa chỉ IPv6 - RFC 5952

Phần mềm cho phép người dùng và nhà vận hành nhập vào địa chỉ IPv6 dưới dạng văn bản NÊN hỗ trợ "Khuyến nghị cho thể hiện dưới dạng văn bản địa chỉ IPv6" [RFC5952].

13.2  Giao diện lập trình ứng dụng (API)

Có một số các API liên quan đến IPv6. Tiêu chuẩn này không bắt buộc sử dụng bất kỳ API nào, bởi vì lựa chọn API không liên quan trực tiếp đến hành vi trực tuyến của các giao thức. Tuy nhiên, các nhà triển khai được khuyên nên xem xét cung cấp một API chung hoặc xem xét các API hiện có cho loại chức năng mà chúng cung cấp cho các ứng dụng.

- "Phần mở rộng giao diện socket (khe cắm) cơ bản cho IPv6" [RFC3493] cung cấp chức năng IPv6 được sử dụng bởi các ứng dụng điển hình. Người triển khai cần lưu ý rằng RFC 3493 đã được quyền lựa chọn và chuẩn hóa thêm nữa bởi giao diện hệ điều hành di động (POSIX) [POSIX].

- "Giao diện chương trình ứng dụng (API) socket nâng cao cho IPv6" [RFC3542] cung cấp quyền truy cập vào các tính năng IPv6 nâng cao cần thiết cho ứng dụng chẩn đoán và các ứng dụng chuyên biệt khác.

...

...

...

- "Phần mở rộng giao diện socket cho bộ lọc nguồn phát đa hướng" [RFC3678] cung cấp hỗ trợ để thể hiện bộ lọc nguồn trên tư cách thành viên nhóm phát đa hướng.

- "Phần mở rộng với các API socket cho IPv6 di động" [RFC4584] cung cấp hỗ trợ ứng dụng để truy cập và kích hoạt các tính năng IPv6 di động [RFC6275].

14  Tính di động

IPv6 di động [RFC6275] và các thông số kỹ thuật liên quan [RFC3776] [RFC4877] cho phép một nút thay đổi điểm kết nối của nó trong mạng Internet, trong khi vẫn duy trì (và sử dụng) một địa chỉ cố định. Tất cả giao tiếp sử dụng địa chỉ cố định tiếp tục diễn ra như mong đợi ngay cả khi nút di chuyển vòng quanh. Định nghĩa IP di động bao gồm các yêu cầu cho các loại nút sau:

- Các nút di động.

- Các nút tương ứng có hỗ trợ tối ưu hóa tuyến đường.

- Các máy khách thường trú.

- Tất cả các bộ định tuyến IPv6.

Tại thời điểm hiện tại, IP di động chỉ được triển khai hạn chế và không có triển khai đáng kể, một phần vì ban đầu nó được giả định là môi trường chỉ có IPv6 chứ không phải là mạng Internet hỗn hợp IPv4/IPv6. Hoạt động bổ sung đã được thực hiện để hỗ trợ tính di động trong các mạng IPv4 và IPv6 ở chế độ hỗn hợp [RFC5555].

...

...

...

IPv6 cho 3GPP [RFC7066] liệt kê ảnh chụp nhanh các chức năng IPv6 yêu cầu tại thời điểm tiêu chuẩn được xuất bản sẽ cần được triển khai, vượt ra ngoài các khuyến nghị trong tiêu chuẩn này. Ngoài ra, một máy chủ IPv6 3GPP CÓ THỂ triển khai [RFC7278] để phân phối tiền tố IPv6 trên liên kết LAN.

15  Bảo mật

Phần này mô tả thông số kỹ thuật bảo mật cho các nút IPv6.

Để đạt được bảo mật trong thực tế là một công việc phức tạp. Các quy trình hoạt động, giao thức, cơ chế phân phối khóa, phương pháp quản lý chứng chỉ, v.v..., đều là các thành phần tác động đến mức độ bảo mật thực sự đạt được trong thực tế. Quan trọng hơn, sự thiếu sót hoặc không phù hợp trong bất kỳ thành phần riêng lẻ nào có thể làm giảm đáng kể hiệu quả tổng thể của một phương pháp bảo mật cụ thể.

IPsec có thể cung cấp hoặc là bảo mật từ đầu đến cuối giữa các nút hoặc là bảo mật kênh (ví dụ: qua VPN IPsec điểm tới điểm), giúp nó có thể cung cấp truyền thông báo mật cho tất cả (hoặc một tập hợp con) của luồng giao tiếp ở tầng IP giữa các cặp nút Internet trở nên khả thi. IPsec có hai chế độ hoạt động tiêu chuẩn: Chế độ đường hầm và chế độ truyền tải. Trong chế độ đường hầm, IPsec cung cấp bảo mật tầng mạng và bảo vệ toàn bộ gói tin IP bằng cách đóng gói gói tin IP gốc và sau đó thêm tiêu đề IP mới. Trong chế độ truyền tải, IPsec cung cấp bảo mật cho tàng truyền tải (ở trên) bằng cách chỉ đóng gói phần lớp truyền tải (ở trên) của gói IP (tức là không thêm tiêu đề IP thứ hai).

Mặc dù IPsec có thể được sử dụng với khóa thủ công trong một số trường hợp, nhưng việc sử dụng như vậy có khả năng ứng dụng hạn chế và không được khuyến khích.

Ngày nay, một loạt các công nghệ và phương pháp tiếp cận bảo mật ngày càng phát triển (ví dụ: IPsec, Bảo mật tầng truyền tải (TLS), bảo mật SHell (SSH), TLS VPNS, v.v...). Không có phương pháp đơn lẻ nào nổi lên như một công nghệ lý tưởng cho mọi nhu cầu và môi trường. Hơn nữa, IPsec không được xem là công nghệ bảo mật lý tưởng trong mọi trường hợp và không có khả năng thay thế các công nghệ khác.

Trước đây, IPv6 bắt buộc triển khai IPsec và khuyến nghị phương pháp quản lý khóa của IKE. RFC 6434 đã cập nhật khuyến nghị đó bằng cách hỗ trợ kiến trúc IPsec [RFC4301] NÊN cho tất cả các nút IPv6 và tiêu chuẩn này vẫn giữ nguyên đề xuất đó. Lưu ý rằng Kiến trúc IPsec yêu cầu triển khai cả quản lý khóa thủ công và tự động (ví dụ: Điều 4.5 của RFC 4301). Hiện tại, giao thức quản lý khóa tự động được khuyến nghị triển khai là IKEv2 [RFC7296].

Tiêu chuẩn này thừa nhận rằng tồn tại một loạt các loại thiết bị và môi trường mà các phương pháp tiếp cận bảo mật khác ngoài IPsec có thể được biện minh. Ví dụ, các thiết bị dành cho mục đích đặc biệt có thể chỉ hỗ trợ một số ít hoặc loại ứng dụng rất hạn chế và một phương pháp bảo mật cụ thể cho ứng dụng có thể đủ cho quản lý hoặc cấu hình hạn chế. Ngoài ra, một số thiết bị có thể chạy trên phần cứng cực kỳ hạn chế (ví dụ: cảm biến) nơi mà việc triển khai Kiến trúc IPsec đầy đủ không được biện minh.

...

...

...

15.1  Các yêu cầu

"Kiến trúc bảo mật cho giao thức Internet" [RFC4301] NÊN được hỗ trợ bởi tất cả các nút IPv6. Lưu ý rằng kiến trúc IPsec yêu cầu triển khai cả quản lý khóa thủ công và tự động (ví dụ: Điều 4.5 của [RFC4301]). Hiện tại, giao thức quản lý khóa tự động mặc định được triển khai là IKEv2. Theo yêu cầu trong [RFC4301], các nút IPv6 triển khai Kiến trúc IPsec CẦN triển khai ESP [RFC4303] và CÓ THỂ triển khai AH [RFC4302].

15.2  Biến đổi và thuật toán

Tập hợp các thuật toán cần triển khai hiện tại cho Kiến trúc IPsec được định nghĩa trong yêu cầu triển khai thuật toán mật mã cho ESP và AH [RFC8221]. Các nút IPv6 triển khai kiến trúc IPsec CẦN tuân thủ các yêu cầu trong [RFC8221]. Các thuật toán mật mã được ưu tiên thường thay đổi thường xuyên hơn các giao thức bảo mật. Do đó, việc triển khai CẦN cho phép chuyển sang các thuật toán mới, khi RFC 8221 được thay thế hoặc cập nhật trong tương lai.

Tập hợp hiện tại của các thuật toán cần triển khai cho IKEv2 được định nghĩa trong yêu cầu triển khai thuật toán mật mã hóa cho ESP và AH [RFC8247]. Các nút IPv6 triển khai IKEv2 CẦN tuân thủ các yêu cầu trong [RFC8247] và/hoặc bất kỳ cập nhật hoặc thay thế nào trong tương lai cho [RFC8247].

16  Chức năng định tuyến cụ thể

Phần này xác định các yêu cầu máy chủ chung cho các nút IPv6 hoạt động như những bộ định tuyến. Hiện tại, phần này không đề cập đến các yêu cầu chi tiết định tuyến. Đối với trường hợp của bộ định tuyến tại nhà điển hình, [RFC7084] xác định các yêu cầu cơ bản cho các bộ định tuyến tại phía khách hàng.

16.1  Tùy chọn cảnh báo định tuyến IPv6 - RFC 2711

Tùy chọn cảnh báo định tuyến IPv6 [RFC2711] là một tiêu đề từng chặng IPv6 tùy chọn, ở đó được sử dụng cùng với một số giao thức (ví dụ: RSVP [RFC2205] hoặc phát hiện lắng nghe phát đa hướng (MLDv2) [RFC3810]). Tùy chọn cảnh báo định tuyến sẽ cần được triển khai bất cứ khi nào các giao thức cần sử dụng nó. Xem Điều 7.11.

...

...

...

Việc gửi quảng bá định tuyến và xử lý các yêu cầu định tuyến CẦN được hỗ trợ.

Điều 7 của [RFC6275] bao gồm một số phần mở rộng tính di động cụ thể để phát hiện lân cận. Các bộ định tuyến NÊN triển khai các Điều 7.3 và 7.5, ngay cả khi chúng không triển khai chức năng tác nhân tại nhà.

16.3  Tự động định cấu hình địa chỉ trạng thái (DHCPv6) - RFC 3315

Một máy chủ DHCP đơn lẻ ([RFC3315] hoặc [RFC4862]) có thể cung cấp thông tin cấu hình cho các thiết bị được kết nối trực tiếp với một liên kết đã chia sẻ, cũng như cho các thiết bị nằm ở nơi khác trong một vị trí. Truyền thông giữa máy khách và máy chủ DHCP nằm trên các liên kết khác nhau yêu cầu sử dụng các tác nhân chuyển tiếp DHCP trên bộ định tuyến.

Trong các triển khai đơn giảm, bao gồm một bộ định tuyến và một mạng LAN đơn lẻ hoặc nhiều mạng LAN được kết nối với một bộ định tuyến duy nhất đó, cùng với kết nối WAN, một máy chủ DHCP được nhúng trong bộ định tuyến là một trong những kịch bản triển khai phổ biến (ví dụ: [RFC7084]). Không cần các tác nhân chuyển tiếp trong các kịch bản như vậy.

Trong các kịch bản triển khai phức tạp hơn, chẳng hạn như trong các mạng doanh nghiệp hoặc mạng nhà cung cấp dịch vụ, việc sử dụng DHCP yêu cầu một số mức cấu hình, để định cấu hình tác nhân chuyển tiếp, các máy chủ DHCP, v.v... Trong những môi trường như vậy, máy chủ DHCP thậm chí có thể được chạy trên một máy chủ truyền thống, thay vì là một phần của bộ định tuyến.

Do có nhiều kịch bản triển khai, hỗ trợ cho chức năng máy chủ DHCP trên bộ định tuyến là tùy chọn. Tuy nhiên, các bộ định tuyến được nhắm mục tiêu để triển khai trong các kịch bản phức tạp hơn (như mô tả ở trên) NÊN hỗ trợ chức năng tác nhân chuyển tiếp. Lưu ý rằng "Yêu cầu cơ bản đối với bộ định tuyến phía khách hàng IPv6" [RFC7084] yêu cầu triển khai chức năng máy chủ DHCPv6 trong bộ định tuyển phía khách hàng (CE) IPv6.

16.4  Khuyến nghị độ dài tiền tố IPv6 cho chuyển tiếp - BCP 198

Các nút chuyển tiếp CẦN tuân thủ BCP 198 [RFC7608]; do đó, các nút triển khai IPv6 có thể chuyển tiếp các gói tin CẦN tuân thủ các quy tắc được thủ trong Điều 5.1 của [RFC4632].

...

...

...

Trọng tâm của tiêu chuẩn này là các nút IPv6 chung. Trong phần này, thảo luận ngắn gọn về các cân nhắc đối với các thiết bị bị hạn chế.

Trong trường hợp các nút bị hạn chế, với CPU, bộ nhớ, băng thông hoặc nguồn điện bị hạn chế, việc hỗ trợ cho một số chức năng IPv6 nhất định có thể cần được xem xét do những hạn chế đó. Trong khi các yêu cầu của tiêu chuẩn này được KHUYẾN CÁO cho tất cả các nút, bao gồm cả các nút bị hạn chế, các thỏa hiệp có thể cần thực hiện trong một số trường hợp nhất định. Khi thực hiện các thỏa hiệp như vậy, khả năng tương tác của các thiết bị cần được cân nhắc kỹ lưỡng, đặc biệt là khi điều này có thể ảnh hưởng đến các nút khác trên cùng một liên kết, ví dụ: chỉ hỗ trợ MLDv1 sẽ ảnh hưởng đến các nút khác.

IETF 6LowPAN (IPv6 qua mạng khu vực cá nhân không dây công suất thấp) WG tạo ra sáu RFC, bao gồm tổng quan chung và tuyên bố vấn đề [RFC4919] (nghĩa là các gói tin IPv6 được truyền qua mạng IEEE 802.15.4 [RFC4944] và tối ưu hóa ND cho phương tiện đó [RFC6775]). Các nút IPv6 được cấp nguồn bằng pin NÊN triển khai các khuyến nghị trong [RFC7772].

18  Quản lý nút IPv6

Quản lý mạng CÓ THỂ được hỗ trợ bởi các nút IPv6. Tuy nhiên, đối với các nút IPv6 là thiết bị nhúng, quản lý mạng có thể là cách duy nhất để có thể kiểm soát các nút này.

Các giao thức quản lý mạng hiện có bao gồm SNMP [RFC3411], NETCONF [RFC6241] và RESTCONF [RFC8040].

18.1  Các mô đun cơ sở thông tin quản lý (MIB)

Trạng thái bị che khuất của các mô-đun MIB IPv6 cụ thể khác nhau được làm rõ trong [RFC8096].

Hai mô-đun MIB sau đây NÊN được hỗ trợ bởi các nút có hỗ trợ tác nhân SNMP.

...

...

...

Bảng MIB chuyển tiếp IP [RFC4292] NÊN được hỗ trợ bởi các nút có hỗ trợ tác nhân SNMP.

18.1.2  Cơ sở thông tin quản lý cho giao thức Internet (IP)

MIB IP [RFC4293] NÊN được hỗ trợ bởi các nút có hỗ trợ tác nhân SNMP.

18.1.3  Giao diện MIB

Giao diện MIB [RFC2863] NÊN được hỗ trợ bởi các nút có hỗ trợ tác nhân SNMP.

18.2  Các mô hình dữ liệu YANG

Các mô hình dữ liệu YANG sau đây NÊN được hỗ trợ bởi các nút có hỗ trợ tác nhân NETCONF hoặc RESTCONF.

18.2.1  Mô hình YANG quản lý IP

Mô hình YANG quản lý IP [RFC8344] NÊN được hỗ trợ bởi các nút có hỗ trợ NETCONF hoặc RESTCONF.

...

...

...

Mô hình YANG quản lý giao diện [RFC8343] NÊN được hỗ trợ bởi các nút có hỗ trợ NETCONF hoặc RESTCONF.

19  Các cân nhắc bảo mật

Tiêu chuẩn này không ảnh hưởng trực tiếp đến bảo mật của Internet, ngoài những cân nhắc bảo mật liên quan đến các giao thức riêng lẻ.

Bảo mật cũng đã được thảo luận trong Điều 15 ở trên.

20  Các cân nhắc IANA

Tiêu chuẩn này không có hành động IANA.

Phụ lục A

(Tham khảo)

...

...

...

Đã có nhiều điều chỉnh biên tập cũng như bổ sung và cập nhật quan trọng. Mặc dù phần này nêu bật một số thay đổi, nhưng người đọc không nên dựa vào phần này để liệt kê toàn bộ những thay đổi.

1. Cấu trúc lại các phần.

2. Thêm 6LoWPAN vào các lớp liên kết vì nó đã có một số triển khai.

3. Đã xóa hồ sơ IPv6 luồng hướng xuống theo yêu cầu (DoD) vì nó chưa được cập nhật.

4. Hỗ trợ cập nhật MLDv2 thành BẮT BUỘC (MUST) vì các nút sẽ bị hạn chế nếu nếu sử dụng MLDv1.

5. Tùy chọn RA DNS được yêu cầu vì chỉ các thiết bị SLAAC có thể nhận được DNS; RFC 8106 là CẦN.

6. Tùy chọn DNS RFC 3646 được yêu cầu để triển khai DHCPv6.

7. Thêm RESTCONF và NETCONF như là các tùy chọn khả thi cho quản lý mạng.

8. Đã thêm một phần trên các thiết bị hạn chế.

...

...

...

10. Thêm nội dung trên RFC 7844 cho các hồ sơ ẩn danh dành cho các máy khách DHCPv6.

11. Thêm mDNS và DNS-SD dưới dạng phát hiện dịch vụ đã cập nhật.

12. Thêm RFC 8028 như một phương pháp NÊN để giải quyết mạng đa tiền tố.

13. Thêm ECN RFC 3168 như là NÊN.

14. Thêm tham chiếu đến RFC 7123 để bảo mật trên các mạng chỉ sử dụng IPv4.

15. Xóa bỏ Jumbograms (RFC 2675) vì chúng không được triển khai.

16. Cập nhật các RFC đã lỗi thời lên phiên bản mới của RFC, bao gồm RFC 2460, 1981, 7321 và 4307.

17. Thêm RFC 7772 để xem xét tiêu thụ điện năng.

18. Thêm lý do cho ranh giới /64 để chi tiết hơn - RFC 7421.

...

...

...

20. RFC 7066 được làm rõ dưới dạng một kết xuất nhanh cho 3GPP.

21. Cập nhật RFC 4191 dưới dạng CẦN và máy chủ Loại C là NÊN vì chúng giúp giải quyết các vấn đề về mạng đa tiền tố.

22. Xóa bỏ IPv6 trên ATM vì không còn triển khai nhiều.

23. Thêm ghi chú trong Điều 6.6 cho Quy tắc 5.5 từ RFC 6724.

24. Thêm CẦN cho BCP 198 để chuyển tiếp các gói IPv6.

25. Thêm tham chiếu đến RFC 8064 để tạo địa chỉ ổn định.

26. Thêm nội dung về bảo vệ khỏi các tùy chọn tiêu đề mở rộng quá mức.

27. Thêm nội dung về nguy cơ của 1280 MTU UDP, đặc biệt liên quan đến lưu lượng DNS.

28. Thêm nội dung để làm rõ hành vi RFC 8200 đối với các tiêu đề mở rộng không được công nhận hoặc ULP không được công nhận.

...

...

...

Phụ lục B

(Tham khảo)

Các thay đổi từ RFC 4294 tới RFC 6434

Đã có nhiều điều chỉnh biên tập cũng như các bổ sung và cập nhật quan trọng. Mặc dù phần này nêu bật một số những thay đổi, nhưng người đọc không nên dựa vào phần này để có danh sách toàn diện về tất cả các thay đổi.

1. Cập nhật phần giới thiệu để chỉ ra rằng tiêu chuẩn này là một tuyên bố về tính ứng dụng và nhắm đến các nút chung.

2. Cập nhật đáng kể phần về giao thức di động; đã thêm các tham chiếu và hạ cấp các NÊN trước đó thành CÓ THỂ.

3. Thay đổi phần lớp IP phụ để chỉ liệt kê các RFC có liên quan và thêm một số RFC khác.

4. Thêm một phần về SEND (đó là CÓ THỂ).

...

...

...

6. Hoàn toàn sửa đổi phần IPsec/IKEv2, hạ cấp khuyến nghị tổng thể thành NÊN.

7. Khuyến nghị nâng cấp DHCPv6 thành NÊN.

8. Thêm phần nền tảng về tùy chọn DHCP so với RA, thêm khuyến nghị NÊN cho cấu hình DNS thông qua RA (RFC 6106) và dọn dẹp các khuyến nghị DHCP.

9. Thêm khuyến nghị rằng các bộ định tuyến thực hiện các Điều 7.3 và 7.5 của [RFC6275].

10. Thêm một chỉ dẫn đến tài liệu làm rõ mạng con [RFC5942].

11. Thêm nội dung "Chia sẻ tải giữa máy chủ với bộ định tuyến IPv6" [RFC4311] NÊN được triển khai.

12. Thêm tham chiếu đến [RFC5722] (các phân đoạn chồng lấn) và làm cho nó CẦN triển khai.

13. NÊN quy định "Khuyến nghị về cách biểu diễn nội dung địa chỉ IPv6" [RFC5952].

14. Xóa bỏ đề cập đến tên ủy quyền (DNAME) khỏi phần thảo luận về [RFC3363].

...

...

...

16. Xóa bỏ thảo luận về các cờ "Được quản lý" và "Khác" trong RA. Hiện tại không có sự đồng thuận về cách xử lý các cờ này, và thảo luận về ngữ nghĩa của chúng đã bị xóa bỏ trong bản cập nhật gần đây nhất của tự động cấu hình địa chỉ phi trạng thái [RFC4862].

17. Thêm nhiều tham chiếu hơn vào các tài liệu IPv6 tùy chọn.

Thêm nhiều tham chiếu đến các tài liệu tùy chọn về IPv6.

18. NÊN quy định "Khuyến nghị về cách biểu diễn nội dung địa chỉ IPv6" [RFC5952].

19. Cập nhật phần MLD để bao gồm tham chiếu đến MLD tải trọng nhẹ [RFC5790].

20. Thêm khuyến nghị NÊN cho "Tham chiếu bộ định tuyến mặc định và các tuyến cụ thể hơn" [RFC4191].

21. NÊN quy định " Đặc tả kỹ thuật nhãn luồng IPv6" [RFC6437].

Thư mục tài liệu tham khảo

...

...

...

[2] RFC 8504 (2019) “IPv6 Node Requirements”.

[3] [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981.

[4] [RFC2205] Braden, R., Ed., Zhang, L, Berson, S., Herzog, S., and S. Jamin, "Resource Reservation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997).

[5] [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998).

[6] [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, DOI 10.17487/RFC2491, January 1999.

[7] [RFC2590] Conta, A., Mails, A., and M. Mueller, "Transmission of IPv6 Packets over Frame Relay Networks Specification", RFC 2590, DOI 10.17487/RFC2590, May 1999.

[8] [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, DOI 10.17487/RFC2874, July 2000.

[9] [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, DOI 10.17487/RFC2923, September 2000.

[10] [RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets over IEEE 1394 Networks", RFC 3146, DOI 10.17487/RFC3146, October 2001.

...

...

...

[12] [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, DOI 10.17487/RFC3493, February 2003.

[13] [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003.

[14] [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003.

[15] [RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, DOI 10.17487/RFC3678, January 2004.

[16] [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, DOI 10.17487/RFC3776, June 2004.

[17] [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005.

[18] [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005.

[19] [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005.

[20] [RFC4294] Loughney, J., Ed., "IPv6 Node Requirements”, RFC 4294, DOI 10.17487/RFC4294, April 2006.

...

...

...

[22] [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel", RFC 4338, DOI 10.17487/RFC4338, January 2006.

[23] [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006.

[24] [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006.

[25] [RFC4584] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for Mobile IPv6", RFC 4584, DOI 10.17487/RFC4584, July 2006.

[26] [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007.

[27] [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, DOI 10.17487/RFC4877, April 2007.

[28] [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages”, RFC 4884, DOI 10.17487/RFC4884, April 2007.

[29] [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, DOI 10.17487/RFC4890, May 2007.

[30] [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007.

...

...

...

[32] [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, DOI 10.17487/RFC5014, September 2007.

[33] [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007.

[34] [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, DOI 10.17487/RFC5121, February 2008.

[35] [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, DOI 10.17487/RFC5555, June 2009.

[36] [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011.

[37] [RFC6563] Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to Historic Status", RFC 6563, DOI 10.17487/RFC6563, March 2012.

[38] [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery", RFC 6980, DOI 10.17487/RFC6980, August 2013.

[39] [RFC7066] Korhonen, J., Ed., Arkko, J., Ed., Savolainen, T., and S. Krishnan, "IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts", RFC 7066, DOI 10.17487/RFC7066, November 2013.

[40] [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013.

...

...

...

[42] [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link", RFC 7278, DOI 10.17487/RFC7278, June 2014.

[43] [RFC7371] Boucadair, M. and S. Venaas, "Updates to the IPv6 Multicast Addressing Architecture", RFC 7371, DOI 10.17487/RFC7371, September 2014.

[44] [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary in IPv6 Addressing", RFC 7421, DOI 10.17487/RFC7421, January 2015.

[45] [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016.

[46] [RFC7739] Gont, F., "Security Implications of Predictable Fragment Identification Values", RFC 7739, DOI 10.17487/RFC7739, February 2016.

[47] [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy Consumption of Router Advertisements", BCP 202, RFC 7772, DOI 10.17487/RFC7772, February 2016.

[48] [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016.

[49] [RFC7934] Colitti, L, Cerf, V., Cheshire, S., and D. Schinazi, "Host Address Availability Recommendations", BCP 204, RFC 7934, DOI 10.17487/RFC7934, July 2016.

[50] [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using Explicit Congestion Notification (ECN)", RFC 8087, DOI 10.17487/RFC8087, March 2017.

...

...

...

[52] [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017.

[53] [POSIX] IEEE, "Information Technology - Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7", IEEE std 1003.1-2017, DOI: 10.1109/IEEESTD.2018.8277153, January 2018.

[54] [USGv6] National Institute of Standards and Technology, "A Profile for IPv6 in the U.S. Government - Version 1.0", NIST SP500-267, July 2008.

MỤC LỤC

1  Phạm vi áp dụng

2  Tài liệu viện dẫn

3  Thuật ngữ và định nghĩa

4  Các từ viết tắt sử dụng trong tiêu chuẩn

...

...

...

6  Lớp IP con

7  Lớp IP

7.1  Giao thức Internet phiên bản 6 - RFC 8200

7.2  Hỗ trợ tiêu đề mở rộng IPv6

7.3  Bảo vệ nút khỏi các tùy chọn tiêu đề mở rộng quá mức

7.4  Khám phá nút mạng lân cận cho IPv6 - RFC 4861

7.5  Khám phá lân cận an toàn/Khám phán nút mạng lân cận an toàn (SEND) - RFC 3971

7.6  Tùy chọn cờ quảng bá định tuyến IPv6 - RFC 5175

7.7  Khám phá MTU hướng/tuyến kết nối (Path MTU) và kích cỡ gói

...

...

...

7.9  Ưu tiên bộ định tuyến mặc định và các bộ định tuyến đặc trưng hơn - RFC 4191

7.10  Lựa chọn bộ định tuyến chặng đầu tiên - RFC 8028

7.11  Khám phá lắng nghe phát đa hướng (MLD) cho IPv6 - RFC 3810

7.12  Thông báo tình trạng tắc nghẽn (ECN) - RFC 3168

8  Định địa chỉ và cấu hình địa chỉ

8.1  Kiến trúc định địa chỉ IP phiên bản 6 - RFC 4291

8.2  Khuyến nghị tính khả dụng của địa chỉ máy chủ

8.3  Tự động cấu hình địa chỉ phi trạng thái IPv6 - RFC 4862

8.4  Mở rộng quyền riêng tư cho cấu hình địa chỉ trong IPv6 - RFC 4941

...

...

...

8.6  Lựa chọn địa chỉ mặc định cho IPv6 - RFC 6724

9  Hệ thống tên miền (DNS)

10  Định cấu hình không có địa chỉ thông tin

10.1  DHCP cho thông tin cấu hình khác

10.2  Phát quảng bá định tuyến và cổng mặc định

10.3  Tùy chọn phát quảng bá định tuyến IPv6 cho cấu hình DNS - RFC 8106

10.4  Các tùy chọn DHCP so với tùy chọn phát quảng bá định tuyến cho cấu hình máy chủ

11  Các giao thức phát hiện dịch vụ

12  Hỗ trợ và chuyển đổi IPv4

...

...

...

13.1  Thể hiện dạng văn bản địa chỉ IPv6 - RFC 5952

13.2  Giao diện lập trình ứng dụng (API)

14  Tính di động

15  Bảo mật

15.1  Các yêu cầu

15.2  Biến đổi và thuật toán

16  Chức năng định tuyến cụ thể

16.1  Tùy chọn cảnh báo định tuyến IPv6 - RFC 2711

16.2  Phát hiện nút mạng lân cận cho IPv6 - RFC 4861

...

...

...

16.4  Khuyến nghị độ dài tiền tố IPv6 cho chuyển tiếp - BCP 198

17  Thiết bị bị hạn chế

18  Quản lý nút IPv6

18.1  Các mô đun cơ sở thông tin quản lý (MIB)

18.2  Các mô hình dữ liệu YANG

19  Các cân nhắc bảo mật

20  Các cân nhắc IANA

Phụ lục A (Tham khảo) Các thay đổi so với RFC 6434

Phụ lục B (Tham khảo) Các thay đổi từ RFC 4294 tới RFC 6434

...

...

...