IPv6 — ঠিকানা, header, SLAAC আর রূপান্তর

১ · কেন IPv6 — ঠিকানা ফুরিয়ে যাওয়ার গল্প

পর্ব ১৬-এ (ipv4-addressing.html) দেখেছেন, একটি IPv4 ঠিকানা ৩২ বিট। মোট ঠিকানা ২^৩২ = ৪,২৯,৪৯,৬৭,২৯৬ — প্রায় ৪৩০ কোটি। ১৯৮০-এর দশকে, যখন ইন্টারনেটে কয়েক হাজার কম্পিউটার, তখন সংখ্যাটি অফুরন্ত মনে হয়েছিল। আজ পৃথিবীর মানুষই প্রায় ৮০০ কোটি, আর একেকজনের হাতে ফোন, ল্যাপটপ, স্মার্ট টিভি, অফিসে আরও কয়েকটি যন্ত্র।

ঠিকানা ফুরোনোর ঘটনাটি ধাপে ধাপে ঘটেছে। ২০১১ সালের ফেব্রুয়ারিতে বিশ্বব্যাপী ঠিকানার ভান্ডার রাখা প্রতিষ্ঠান IANA তার শেষ IPv4 ব্লকগুলো পাঁচটি আঞ্চলিক রেজিস্ট্রির (RIR) মধ্যে ভাগ করে দেয়। বাংলাদেশ যে অঞ্চলের রেজিস্ট্রির আওতায়, সেই APNIC একই বছরের এপ্রিলে শেষ ব্লকের কড়া রেশনিংয়ে চলে যায়; ইউরোপ, আমেরিকা আর অন্য অঞ্চলের রেজিস্ট্রিও পরের কয়েক বছরে একই অবস্থায় পৌঁছায়। এখন নতুন প্রতিষ্ঠানকে IPv4 ঠিকানা সাধারণত অন্যের কাছ থেকে কিনতে বা ভাড়া নিতে হয়।

IPv6 শুধু “বেশি ঠিকানা” নয়। নকশাকারীরা তিনটি লক্ষ্য রেখেছিলেন:

• End-to-end আবার ফেরানো: প্রতিটি যন্ত্রের নিজস্ব global ঠিকানা থাকলে দুটি যন্ত্র সরাসরি কথা বলতে পারে — NAT-এর পেছনে লুকিয়ে থাকা আর port বদলের ঝামেলা লাগে না (end-to-end principle, পর্ব ৩)। ভিডিও কল, অনলাইন গেম আর peer-to-peer অ্যাপে এর সুবিধা সবচেয়ে বেশি।
• সরল, দ্রুত header: নির্দিষ্ট ৪০ বাইটের header, checksum নেই, পথে packet ভাঙা নেই — router-এর কাজ কম।
• নিজে নিজে কনফিগার: যন্ত্র নেটওয়ার্কে যুক্ত হয়েই router-এর ঘোষণা শুনে নিজের ঠিকানা বানাতে পারে; DHCP সার্ভার বাধ্যতামূলক নয়।

তাহলে এত ধীরে ছড়াচ্ছে কেন?

IPv6 আর IPv4 সরাসরি একে অপরের সাথে কথা বলতে পারে না — এটি নতুন একটি protocol, পুরোনোটির “আপডেট” নয়। তাই প্রতিটি router, firewall, সার্ভার, অ্যাপ আর কর্মীর প্রশিক্ষণ — সব জায়গায় খরচ। অন্যদিকে NAT আর ISP-র বড় আকারের NAT (CGNAT) দিয়ে IPv4 জোড়াতালি দিয়ে চলছে, তাই অনেক প্রতিষ্ঠান তাড়া অনুভব করেনি। ফল: কিছু দেশে আর বড় মোবাইল নেটওয়ার্কে IPv6 এখন ট্রাফিকের বড় অংশ বহন করে, আবার কোথাও খুবই কম।

২ · ১২৮ বিটের ঠিকানা — লেখা, ছোট করা আর আবার বড় করা

১২৮ বিট মানে ১৬ বাইট। IPv4-এর মতো দশমিকে লিখলে ১৬টি সংখ্যা হতো — অসহনীয়। তাই IPv6 লেখা হয় hexadecimal-এ (০–৯ আর a–f): প্রতি ১৬ বিট একটি ঘর, ৪টি hex অঙ্ক, মোট ৮টি ঘর, মাঝে কোলন।

2001:0db8:acad:0001:0000:0000:0000:0010
└─┬┘ └─┬┘ └─┬┘ └─┬┘ └─┬┘ └─┬┘ └─┬┘ └─┬┘
  16   16   16   16   16   16   16   16  bits = 128 bits

মোট ঠিকানা ২^১২৮ ≈ ৩.৪ × ১০^৩৮. এই সংখ্যাটা কত বড়, তা কল্পনা করাই কঠিন — শুধু একটি /64 নেটওয়ার্কেই (পরের অংশ) ঠিকানা আছে ২^৬৪ = ১,৮৪,৪৬,৭৪,৪০,৭৩,৭০,৯৫,৫১,৬১৬টি, যা পুরো IPv4 ইন্টারনেটের চার বিলিয়ন গুণেরও বেশি।

ছোট করার তিন নিয়ম

1. শুরুর শূন্য বাদ: প্রতিটি ঘরের বাঁয়ের শূন্যগুলো বাদ দেওয়া যায় — 0db8 → db8, 0010 → 10, 0000 → 0. ডানের শূন্য কখনো নয়: ab00 যা ছিল তাই থাকে।
2. শূন্যের টানা সারি একবার ::: পরপর এক বা একাধিক শূন্য-ঘরকে :: দিয়ে বদলানো যায় — কিন্তু পুরো ঠিকানায় মাত্র একবার. দুবার দিলে পড়ার সময় বোঝা যাবে না কোন ফাঁকে কতগুলো শূন্য ছিল।
3. Canonical রূপ (RFC 5952, ২০১০): একই ঠিকানার অনেক বৈধ লেখা হতে পারে, তাই একটি “আদর্শ” রূপ ঠিক করা হয়েছে — (ক) শুরুর শূন্য অবশ্যই বাদ, (খ) :: বসবে সবচেয়ে লম্বা শূন্য-সারিতে, সমান হলে প্রথমটিতে, (গ) মাত্র একটি শূন্য-ঘরকে :: করা চলবে না, (ঘ) hex অক্ষর ছোট হাতের।

নিচের ধাপগুলো পরীক্ষার সবচেয়ে প্রচলিত অনুশীলনটি দেখায় — দুটি সমান লম্বা শূন্য-সারিসহ একটি ঠিকানা। “পরে” চাপুন:

2001:0DB8:0000:0000:0001:0000:0000:00AB
  1    2    3    4    5    6    7    8   ← ঘর নম্বর

2001:0db8:0000:0000:0001:0000:0000:00ab

2001:db8:0:0:1:0:0:ab

2001:db8:0:0:1:0:0:ab
         └A┘     └B┘
সারি A = ঘর ৩–৪ (২টি)   সারি B = ঘর ৬–৭ (২টি)
সমান লম্বা → প্রথমটি (A) পাবে ::

2001:db8::1:0:0:ab

2001:db8::1::ab      ✗ দুটি :: — অবৈধ
2001:db8:0:0:1::ab   ✓ বৈধ, কিন্তু canonical নয়
2001:db8::1:0:0:ab   ✓ canonical

বড় করা: আছে ৬টি ঘর → :: = ৮ − ৬ = ২টি শূন্য-ঘর
2001:0db8:0000:0000:0001:0000:0000:00ab

এবার কয়েকটি ঠিকানা একসাথে। নিচের ছোট টুলটি প্রতিটি ঠিকানাকে পুরো ৮ ঘরে বড় করে, তারপর ঠিক উপরের নিয়মে canonical রূপে ছোট করে, ধরন চিনে বলে, আর /64 ধরে prefix আর interface ID আলাদা করে। Run চাপুন:

// IPv6 address tool: expand, compress (RFC 5952), classify, split a /64.
function expand(s) {
  const a = s.toLowerCase(), [head, tail] = a.includes("::") ? a.split("::") : [a, null];
  const h = head ? head.split(":") : [], t = tail ? tail.split(":") : [];
  const fill = tail === null ? [] : Array(8 - h.length - t.length).fill("0");
  return [...h, ...fill, ...t].map(g => g.padStart(4, "0"));
}
function compress(full) {
  const g = full.map(x => x.replace(/^0+(?=.)/, ""));   // rule 1: drop leading zeros
  let best = -1, len = 1;                               // rule 2: longest zero run, length >= 2
  for (let i = 0; i < 8; i++) {
    let j = i; while (j < 8 && g[j] === "0") j++;
    if (j - i > len) { best = i; len = j - i; }          // ">" keeps the FIRST of equal runs
  }
  return best < 0 ? g.join(":") : g.slice(0, best).join(":") + "::" + g.slice(best + len).join(":");
}
function kind(f) {
  const n = parseInt(f[0], 16), z = f.slice(0, 7).every(x => x === "0000");
  if (z && f[7] === "0000") return "unspecified (::)";
  if (z && f[7] === "0001") return "loopback (::1)";
  if ((n & 0xff00) === 0xff00) return `multicast, scope ${f[0][3]} (${{1: "interface", 2: "link", 5: "site", e: "global"}[f[0][3]] ?? "?"})`;
  if ((n & 0xffc0) === 0xfe80) return "link-local unicast (fe80::/10)";
  if ((n & 0xfe00) === 0xfc00) return "unique local unicast (fc00::/7)";
  if (f[0] === "2001" && f[1] === "0db8") return "global unicast range, DOCUMENTATION 2001:db8::/32";
  if ((n & 0xe000) === 0x2000) return "global unicast (2000::/3)";
  return "other / reserved";
}
["2001:0DB8:0000:0000:0008:0800:200C:417A", "2001:db8:acad:1:0:0:0:10", "2001:db8:0:0:1:0:0:1",
 "2001:db8:0:1:1:1:1:1", "FE80:0000:0000:0000:0200:5EFF:FE00:5301", "fd12:3456:789a:1::1",
 "ff02:0:0:0:0:1:ff00:5301", "0:0:0:0:0:0:0:1", "::"].forEach(a => {
  const f = expand(a);
  console.log(`${a}\n  full : ${f.join(":")}\n  short: ${compress(f)}  -> ${kind(f)}`);
  if (!kind(f).includes("multicast") && f.slice(0, 7).some(x => x !== "0000"))
    console.log(`  /64  : prefix ${compress([...f.slice(0, 4), "0", "0", "0", "0"])}/64  IID ${f.slice(4).join(":")}`);
});

2001:0DB8:0000:0000:0008:0800:200C:417A
  full : 2001:0db8:0000:0000:0008:0800:200c:417a
  short: 2001:db8::8:800:200c:417a  -> global unicast range, DOCUMENTATION 2001:db8::/32
  /64  : prefix 2001:db8::/64  IID 0008:0800:200c:417a
2001:db8:acad:1:0:0:0:10
  full : 2001:0db8:acad:0001:0000:0000:0000:0010
  short: 2001:db8:acad:1::10  -> global unicast range, DOCUMENTATION 2001:db8::/32
  /64  : prefix 2001:db8:acad:1::/64  IID 0000:0000:0000:0010
2001:db8:0:0:1:0:0:1
  full : 2001:0db8:0000:0000:0001:0000:0000:0001
  short: 2001:db8::1:0:0:1  -> global unicast range, DOCUMENTATION 2001:db8::/32
  /64  : prefix 2001:db8::/64  IID 0001:0000:0000:0001
2001:db8:0:1:1:1:1:1
  full : 2001:0db8:0000:0001:0001:0001:0001:0001
  short: 2001:db8:0:1:1:1:1:1  -> global unicast range, DOCUMENTATION 2001:db8::/32
  /64  : prefix 2001:db8:0:1::/64  IID 0001:0001:0001:0001
FE80:0000:0000:0000:0200:5EFF:FE00:5301
  full : fe80:0000:0000:0000:0200:5eff:fe00:5301
  short: fe80::200:5eff:fe00:5301  -> link-local unicast (fe80::/10)
  /64  : prefix fe80::/64  IID 0200:5eff:fe00:5301
fd12:3456:789a:1::1
  full : fd12:3456:789a:0001:0000:0000:0000:0001
  short: fd12:3456:789a:1::1  -> unique local unicast (fc00::/7)
  /64  : prefix fd12:3456:789a:1::/64  IID 0000:0000:0000:0001
ff02:0:0:0:0:1:ff00:5301
  full : ff02:0000:0000:0000:0000:0001:ff00:5301
  short: ff02::1:ff00:5301  -> multicast, scope 2 (link)
0:0:0:0:0:0:0:1
  full : 0000:0000:0000:0000:0000:0000:0000:0001
  short: ::1  -> loopback (::1)
::
  full : 0000:0000:0000:0000:0000:0000:0000:0000
  short: ::  -> unspecified (::)

Operating system নিজেও ঠিক এই কাজ করে: C-এর inet_pton লেখা ঠিকানাকে ১৬ বাইটে বদলায় (“presentation to network”), আর inet_ntop ১৬ বাইট থেকে canonical লেখা বানায়। নিচের প্রোগ্রাম আটটি লেখা ঠিকানা দিয়ে round trip করে, তারপর loopback ::1-এর ওপর একটি UDP বার্তা পাঠিয়ে নিজেই গ্রহণ করে (Linux container-এ চলে; বাইরের ইন্টারনেট লাগে না):

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>

int main(void) {
    const char *in[] = { "2001:0DB8:0000:0000:0008:0800:200C:417A", "2001:db8:0:0:1:0:0:1",
                         "2001:db8:0:1:1:1:1:1", "2001:db8::0:1", "fe80:0:0:0:0200:5eff:fe00:5301",
                         "0:0:0:0:0:0:0:1", "::ffff:192.0.2.33", "2001:db8::1::2" };
    for (size_t i = 0; i < sizeof in / sizeof in[0]; i++) {
        struct in6_addr a; char out[INET6_ADDRSTRLEN];
        if (inet_pton(AF_INET6, in[i], &a) != 1) { printf("%-40s -> invalid\n", in[i]); continue; }
        inet_ntop(AF_INET6, &a, out, sizeof out);
        printf("%-40s -> %s\n", in[i], out);
    }
    int s = socket(AF_INET6, SOCK_DGRAM, 0), c = socket(AF_INET6, SOCK_DGRAM, 0);
    if (s < 0 || c < 0) { perror("socket(AF_INET6)"); return 0; }
    struct sockaddr_in6 sa; memset(&sa, 0, sizeof sa);
    sa.sin6_family = AF_INET6; sa.sin6_addr = in6addr_loopback;   /* ::1, port 0 = any */
    socklen_t len = sizeof sa;
    if (bind(s, (struct sockaddr *)&sa, len) < 0) { printf("bind to ::1 failed: no IPv6 loopback here\n"); return 0; }
    getsockname(s, (struct sockaddr *)&sa, &len);
    sendto(c, "hello over IPv6", 15, 0, (struct sockaddr *)&sa, sizeof sa);
    char buf[64], who[INET6_ADDRSTRLEN]; struct sockaddr_in6 from; socklen_t fl = sizeof from;
    ssize_t n = recvfrom(s, buf, sizeof buf - 1, 0, (struct sockaddr *)&from, &fl);
    if (n < 0) { perror("recvfrom"); return 0; }
    buf[n] = '\0';
    inet_ntop(AF_INET6, &from.sin6_addr, who, sizeof who);
    printf("UDP on [::1]: got \"%s\" (%zd bytes) from [%s]\n", buf, n, who);
    close(s); close(c);
    return 0;
}

2001:0DB8:0000:0000:0008:0800:200C:417A  -> 2001:db8::8:800:200c:417a
2001:db8:0:0:1:0:0:1                     -> 2001:db8::1:0:0:1
2001:db8:0:1:1:1:1:1                     -> 2001:db8:0:1:1:1:1:1
2001:db8::0:1                            -> 2001:db8::1
fe80:0:0:0:0200:5eff:fe00:5301           -> fe80::200:5eff:fe00:5301
0:0:0:0:0:0:0:1                          -> ::1
::ffff:192.0.2.33                        -> ::ffff:192.0.2.33
2001:db8::1::2                           -> invalid
UDP on [::1]: got "hello over IPv6" (15 bytes) from [::1]

৩ · Prefix, /48 আর /64 — ঠিকানার ভেতরের মানচিত্র

IPv4-এর মতো IPv6-এও prefix length লেখা হয় / দিয়ে: 2001:db8:acad::/48 মানে সামনের ৪৮ বিট নেটওয়ার্কের পরিচয়। তবে IPv6-এ subnet mask (255.255.…) লেখার চল নেই, আর একটি সাধারণ LAN প্রায় সবসময় /64. একটি global unicast ঠিকানার সাধারণ গঠন:

│◄─────── 48 bits ────────►│◄─16─►│◄─────────── 64 bits ────────────►│
┌──────────────────────────┬──────┬──────────────────────────────────┐
│  global routing prefix   │subnet│           interface ID           │
│ (from the ISP: the site) │  ID  │    (the host inside the LAN)     │
└──────────────────────────┴──────┴──────────────────────────────────┘
       2001:0db8:acad        0001         0200:5eff:fe00:5301

• Global routing prefix: ISP বা রেজিস্ট্রি থেকে পাওয়া অংশ — ইন্টারনেটের router-রা শুধু এটুকু দেখে প্রতিষ্ঠান পর্যন্ত পৌঁছে দেয়।
• Subnet ID: প্রতিষ্ঠান নিজে ঠিক করে কোন LAN কোন নম্বর পাবে। /48 পেলে subnet ID ১৬ বিট — ২^১৬ = ৬৫,৫৩৬টি /64 LAN.
• Interface ID: শেষ ৬৪ বিট, LAN-এর ভেতরে একটি interface-এর পরিচয়। SLAAC ঠিক ৬৪ বিটের interface ID ধরে কাজ করে, তাই /64-এর চেয়ে ছোট LAN বানালে SLAAC চলে না।

কে কত বড় ব্লক পায়, তা ISP-র নীতিনির্ভর: প্রতিষ্ঠান প্রায়ই /48, বাসার সংযোগ প্রায়ই /56 (২৫৬টি LAN) বা /60, মোবাইল ফোন সাধারণত একটি /64. RFC 6177 নির্দিষ্ট মাপ চাপায় না, তবে একাধিক LAN-এর জায়গা দিতে বলে।

একটি subnet পরিকল্পনা — হাতে করা উদাহরণ

ধরুন একটি পোশাক কোম্পানি ISP থেকে 2001:db8:acad::/48 পেয়েছে। তাদের ঢাকায় প্রধান অফিস, গাজীপুরে কারখানা আর চট্টগ্রামে গুদাম। IPv4-এর মতো (পর্ব ১৭, subnetting.html) “কোন subnet-এ কয়টি host” হিসাব করতে হয় না — প্রতিটি LAN-ই /64. কাজটা শুধু ১৬ বিটের subnet ID-কে বোধগম্যভাবে সাজানো। Hex-এর প্রতিটি অঙ্ক ৪ বিট (একটি nibble), তাই অঙ্ক ধরে অর্থ দিলে পড়া সহজ হয়:

subnet ID (16 bits) = S F V V
                      │ │ └─┴── VV = VLAN বা তলা: 00–ff
                      │ └────── F = কাজ: 0 অবকাঠামো, 1 কর্মী, 2 অতিথি Wi-Fi, 3 সার্ভার
                      └──────── S = সাইট: 1 ঢাকা, 2 গাজীপুর, 3 চট্টগ্রাম

নিয়মটা দেখুন: prefix ৪ বিট করে বাড়লে (/48 → /52 → /56 → /60 → /64) ঠিকানায় একটি করে hex অঙ্ক “স্থির” হয়, আর প্রতি ধাপে ভাগ হয় ১৬টি করে। তাই সাইট-ভিত্তিক /52 ব্লক থাকলে ঢাকার router বাইরে মাত্র একটি route ঘোষণা করলেই চলে — route aggregation, যার হিসাব পর্ব ১৭-এ আর routing-এ যার ব্যবহার পর্ব ২২-এ। দুই router-এর মাঝের point-to-point link-এ অনেকে /127 ব্যবহার করেন (RFC 6164), আর router-এর loopback-এ /128.

৪ · ঠিকানার ধরন — broadcast নেই, multicast সবখানে

IPv6-এ ঠিকানা তিন জাতের: unicast (একজনের জন্য), multicast (একটি দলের জন্য) আর anycast (একই ঠিকানা কয়েক জায়গায়, packet যায় সবচেয়ে কাছেরটিতে)। আর broadcast নেই — “সবাইকে” পাঠানোর কাজ করে একটি multicast দল, যাতে সব যন্ত্র থাকে। প্রথম কয়েকটি বিট দেখেই ধরন চেনা যায়:

ULA-তে fd-এর পরের ৪০ বিট (Global ID) RFC 4193 অনুযায়ী random হওয়ার কথা, যাতে দুটি নেটওয়ার্ক VPN-এ জুড়লে ঠিকানা না মেলে (ছোট ল্যাব বা container-এ অবশ্য fd00::/64 দেখা যায় — অংশ ৭)।

Multicast — চেনা দলগুলো

Multicast ঠিকানার ff-এর পরের দুটি hex অঙ্কের দ্বিতীয়টি scope: 1 = interface-এর ভেতরে, 2 = link, 5 = site, 8 = প্রতিষ্ঠান, e = global. প্রতিদিনের কাজে সবচেয়ে বেশি আসে link-scope দলগুলো:

• ff02::1 — link-এর সব node (IPv4-এর broadcast-এর সবচেয়ে কাছের জিনিস)
• ff02::2 — link-এর সব router
• ff02::1:2 — সব DHCPv6 সার্ভার ও relay
• ff02::1:ffXX:XXXX — solicited-node দল: ঠিকানার শেষ ২৪ বিট বসিয়ে বানানো

Solicited-node দলটিই ARP-এর broadcast-এর বুদ্ধিমান বিকল্প। ARP-এ (পর্ব ১৮, dhcp-arp.html) “192.168.1.20 কার?” প্রশ্ন LAN-এর সব যন্ত্রের CPU-কে থামিয়ে পড়তে বাধ্য করে। IPv6-এ প্রশ্নটি যায় শুধু সেই দলে, যার সদস্য কেবল যাদের ঠিকানার শেষ ২৪ বিট মেলে — বাস্তবে প্রায় সবসময় একজনই।

Ethernet-এ multicast পৌঁছায় একটি বিশেষ MAC-এ: 33:33-এর পরে IPv6 multicast ঠিকানার শেষ ৩২ বিট (RFC 2464). তাই ff02::1 যায় 33:33:00:00:00:01-এ, আর ff02::1:ff00:5301 যায় 33:33:ff:00:53:01-এ। পর্ব ১২-এ (ethernet-switching.html) দেখেছেন, 0x33-এর I/G বিট ১ — তাই NIC এটাকে group ঠিকানা হিসেবে চেনে, আর যে দলে যোগ দেয়নি সেই দলের frame hardware-এই ফেলে দেয়, CPU পর্যন্ত যায় না। কোন port-এ কোন দলের সদস্য, তা switch জানতে পারে MLD বার্তা শুনে (MLD snooping); বিস্তারিত পর্ব ২৬-এ।

Anycast-এর আলাদা কোনো prefix নেই — একটি সাধারণ unicast ঠিকানাই কয়েকটি জায়গা থেকে ঘোষণা করা হয়, আর routing নিজে থেকে কাছেরটিতে পাঠায়। বড় DNS সার্ভার আর CDN এভাবে কাজ করে (পর্ব ২৫)। একটি নির্দিষ্ট anycast ঠিকানা IPv6 নিজেই সংরক্ষণ করেছে: প্রতিটি subnet-এর interface ID সব-শূন্য ঠিকানাটি (যেমন 2001:db8:acad:1::) — Subnet-Router anycast, অর্থাৎ ওই subnet-এর যেকোনো router.

৫ · Interface ID — EUI-64 থেকে গোপনীয়তার ঠিকানা

শেষ ৬৪ বিট কোথা থেকে আসে? চারটি পথ: হাতে বসানো (সার্ভার আর router-এ, যেমন ::1, ::10), DHCPv6 সার্ভার, অথবা যন্ত্র নিজে বানায় — MAC থেকে (EUI-64) বা random. পুরোনো এবং পরীক্ষায় সবচেয়ে প্রচলিত পদ্ধতি modified EUI-64: ৪৮ বিটের MAC-কে ৬৪ বিট বানানো। পর্ব ১২-এর U/L বিট এখানে আবার কাজে আসে।

00:00:5e : 00:53:01
└──┬───┘   └──┬───┘
 OUI (নির্মাতা)  কার্ডের নিজস্ব অংশ
প্রথম বাইট 0x00 = 0000 0000   U/L বিট = 0 (universal)

00:00:5e:ff:fe:00:53:01

0x00 = 0000 0000
             ↓ উল্টে
0x02 = 0000 0010
02:00:5e:ff:fe:00:53:01

0200:5eff:fe00:5301
→ 200:5eff:fe00:5301

fe80::/64            → fe80::200:5eff:fe00:5301
2001:db8:acad:1::/64 → 2001:db8:acad:1:200:5eff:fe00:5301

ঠিকানার শেষ ২৪ বিট: …fe00:5301  →  00 53 01
solicited-node:  ff02::1:ff00:5301
Ethernet MAC:    33:33 + শেষ ৩২ বিট = 33:33:ff:00:53:01

EUI-64-এর সমস্যা: আপনাকে চেনা যায়

MAC থেকে বানানো interface ID কখনো বদলায় না। আপনি বাসার Wi-Fi, অফিস, ক্যাফে — যেখানেই যান, prefix বদলায়, কিন্তু শেষ ৬৪ বিট একই। ফলে যেকোনো ওয়েবসাইট বা বিজ্ঞাপন নেটওয়ার্ক শুধু ঠিকানা দেখেই বুঝতে পারে “এই সেই যন্ত্র” — আর নির্মাতার OUI দেখে যন্ত্রের ব্র্যান্ডও। এই গোপনীয়তার সমস্যার দুটি সমাধান এসেছে:

বাস্তবে একটি ল্যাপটপে প্রায়ই একসাথে কয়েকটি IPv6 ঠিকানা দেখবেন — একটি link-local, একটি stable global, আর এক বা একাধিক temporary global. এটা ভুল নয়, নকশাই এমন। কোন OS কোন পদ্ধতি ডিফল্ট রাখে, তা সংস্করণ আর সেটিং অনুযায়ী বদলায় (Linux-এ addr_gen_mode আর use_tempaddr, অংশ ৭) — নিজের যন্ত্রে দেখে নিন।

৬ · IPv6 header — ৪০ বাইট, extension header আর ১২৮০-র নিয়ম

পর্ব ১৬-এ IPv4 header দেখেছেন: ২০ থেকে ৬০ বাইট, ১৩টির মতো ঘর, options, checksum আর fragmentation-এর ঘর। IPv6-এর নকশাকারীরা সেখান থেকে যা খুব কম লাগে বা প্রতিটি router-কে ধীর করে, তা সরিয়ে দিয়েছেন। ফল — সবসময় ঠিক ৪০ বাইট, মাত্র ৮টি ঘর:

 0       4               12
┌───────┬───────────────┬───────────────────────────────────────┐
│  Ver  │ Traffic Class │               Flow Label              │
│  (4)  │      (8)      │                  (20)                 │
├───────┴───────────────┴───────┬───────────────┬───────────────┤
│      Payload Length (16)      │  Next Header  │   Hop Limit   │
│                               │      (8)      │      (8)      │
├───────────────────────────────┴───────────────┴───────────────┤
│                                                               │
│                   Source Address (128 bits)                   │
│                                                               │
├───────────────────────────────────────────────────────────────┤
│                                                               │
│                 Destination Address (128 bits)                │
│                                                               │
└───────────────────────────────────────────────────────────────┘

• Version (৪ বিট): সবসময় ৬. (Ethernet-এ IPv6 চেনা যায় EtherType 0x86DD দেখে।)
• Traffic Class (৮ বিট): IPv4-এর ToS-এর মতো — ৬ বিট DSCP (অগ্রাধিকার, পর্ব ২৬) আর ২ বিট ECN (যানজটের সংকেত)।
• Flow Label (২০ বিট): একই “প্রবাহ”-এর (যেমন একটি ভিডিও কলের) সব packet-কে একই লেবেল দেওয়া যায়, যাতে router বা load balancer পুরো header ঘেঁটে না দেখেও সেগুলোকে একই পথে রাখতে পারে (RFC 6437). অনেক যন্ত্র এখনো এটি শূন্য রাখে বা উপেক্ষা করে।
• Payload Length (১৬ বিট): header-এর পরের বাইটের সংখ্যা (extension header সহ) — IPv4-এর মতো মোট দৈর্ঘ্য নয়। তাই সর্বোচ্চ ৬৫,৫৩৫; এর চেয়ে বড় “jumbogram”-এর জন্য আলাদা ব্যবস্থা আছে।
• Next Header (৮ বিট): এর পরে কী আসছে — TCP (6), UDP (17), ICMPv6 (58), নাকি কোনো extension header. IPv4-এর Protocol ঘরের জায়গা নিয়েছে।
• Hop Limit (৮ বিট): IPv4-এর TTL-এর সৎ নাম — প্রতিটি router ১ কমায়, ০ হলে ফেলে দিয়ে ICMPv6 Time Exceeded পাঠায় (traceroute এভাবেই কাজ করে, পর্ব ২০, icmp.html).
• উৎস আর গন্তব্য ঠিকানা: ১৬ + ১৬ = ৩২ বাইট — header-এর ৮০%.

হিসাব মিলিয়ে নিন: ৪ + ৮ + ২০ + ১৬ + ৮ + ৮ = ৬৪ বিট = ৮ বাইট, সাথে ৩২ বাইট ঠিকানা — মোট ৪০ বাইট।

Extension header — Next Header-এর শিকল

IPv4-এর options-এর জায়গায় IPv6-এ আছে আলাদা extension header: প্রতিটির ভেতরে আবার একটি Next Header ঘর, যা পরেরটির দিকে আঙুল তোলে — ঠিক একটি শিকলের মতো। শেষ কড়িতে থাকে TCP বা UDP. একটি ভাঙা (fragmented) TCP packet-এর উদাহরণ:

┌──────────────────┐   ┌──────────────────────┐   ┌──────────────────┐
│ IPv6 header      │   │ Fragment header      │   │ TCP segment      │
│ Next Header = 44 ├──►│ Next Header = 6      ├──►│ (data)           │
└──────────────────┘   └──────────────────────┘   └──────────────────┘
   0 = Hop-by-Hop   43 = Routing   44 = Fragment   50 = ESP   51 = AH
  60 = Destination Options   58 = ICMPv6   59 = আর কিছু নেই   6 = TCP   17 = UDP

নিয়ম অনুযায়ী পথের router শুধু Hop-by-Hop Options header দেখতে পারে; বাকিগুলো গন্তব্যের জন্য। এতে সাধারণ packet দ্রুত যায়। তবে বাস্তবে একটি দাম আছে: অনেক firewall আর router অচেনা বা লম্বা extension header-এর শিকল পেলে packet ফেলে দেয় (RFC 7872-এ এর পরিমাপ আছে), তাই নতুন protocol সাধারণত এর ওপর ভরসা করে না।

MTU ১২৮০ আর Path MTU Discovery

পথের কোনো link-এর MTU যদি packet-এর চেয়ে ছোট হয়, IPv4 router তখন packet ভেঙে পাঠাতে পারে। IPv6 router কখনো ভাঙে না — packet ফেলে দেয়, আর উৎসকে একটি ICMPv6 Packet Too Big বার্তা পাঠায়, যাতে লেখা থাকে “এই link-এর MTU এত”। উৎস তখন ছোট packet পাঠায়, প্রয়োজনে নিজে Fragment header দিয়ে ভাঙে। এই পদ্ধতির নাম Path MTU Discovery (IPv6-এর জন্য RFC 8201). আর সবাই যাতে নিশ্চিন্তে শুরু করতে পারে, তাই নিয়ম: IPv6 চলে এমন প্রতিটি link কমপক্ষে ১২৮০ বাইটের packet বহন করবে (RFC 8200). এর চেয়ে ছোট MTU-র link-কে নিচের স্তরে নিজেই টুকরো করে আবার জুড়তে হবে।

৭ · ICMPv6, Neighbor Discovery আর SLAAC

IPv4-এ ICMP ছিল “সহকারী” — ping আর ত্রুটির খবর। ICMPv6 (RFC 4443) তার চেয়ে অনেক বড় দায়িত্ব নিয়েছে: ARP, ঠিকানা কনফিগারেশন আর router খোঁজার কাজ এখন ICMPv6-এর একটি অংশ — Neighbor Discovery Protocol (NDP, RFC 4861). পাঁচটি বার্তা মনে রাখলেই চলে:

একটি সুন্দর নিরাপত্তা-কৌশল: সব NDP বার্তা পাঠানো হয় Hop Limit = ২৫৫ দিয়ে, আর গ্রহণকারী ২৫৫ না পেলে বার্তাটি ফেলে দেয়। কোনো router পার হলে মান কমে যেত — তাই ২৫৫ মানে বার্তাটি নিশ্চয়ই একই link থেকে এসেছে; দূরের কেউ ইন্টারনেট দিয়ে নকল RA পাঠাতে পারে না। (একই link-এর ভেতরের নকল RA-র কথা অংশ ৯-এ।)

DAD — ঠিকানা নেওয়ার আগে “এটা কি কারও?”

কোনো unicast ঠিকানা ব্যবহারের আগে host সেটিকে tentative (পরীক্ষাধীন) রাখে আর Duplicate Address Detection চালায়: উৎস :: (কারণ এখনো তার কোনো ঠিকানা নেই) দিয়ে ঠিকানাটির solicited-node দলে একটি NS পাঠায় — “fe80::… কি কারও?” ডিফল্টভাবে একবার পাঠায় আর প্রায় ১ সেকেন্ড অপেক্ষা করে। কেউ NA দিয়ে বললে “আমার” — ঠিকানাটি duplicate, ব্যবহার হবে না (Linux-এ dadfailed চিহ্ন পড়ে)। উত্তর না এলে ঠিকানাটি ব্যবহারযোগ্য হয়।

SLAAC — বুট থেকে global ঠিকানা

SLAAC (Stateless Address Autoconfiguration, RFC 4862)-এ কোনো সার্ভার কাউকে ঠিকানা “দেয়” না, কোনো তালিকাও রাখে না — router শুধু prefix ঘোষণা করে, আর প্রতিটি host নিজে ঠিকানা বানায়। এজন্যই নাম “stateless”. ধরুন PC2 (MAC 00:00:5e:00:53:02) একটি LAN-এ যুক্ত হলো, যেখানে router R (fe80::1) আছে:

interface ID = 200:5eff:fe00:5302      (অংশ ৫-এর নিয়মে)
tentative    = fe80::200:5eff:fe00:5302
যোগ দিল দলে: ff02::1 (সবাই), ff02::1:ff00:5302 (solicited-node)

Ethernet  dst 33:33:ff:00:53:02   src 00:00:5e:00:53:02
IPv6      src ::   dst ff02::1:ff00:5302
ICMPv6    NS target = fe80::200:5eff:fe00:5302
→ ~১ সেকেন্ড অপেক্ষা

fe80::200:5eff:fe00:5302  tentative → preferred
এখন এই ঠিকানা দিয়ে link-এ কথা বলা যায়

Ethernet  dst 33:33:00:00:00:02
IPv6      src fe80::200:5eff:fe00:5302   dst ff02::2 (সব router)
ICMPv6    RS, option: source MAC 00:00:5e:00:53:02

IPv6      src fe80::1   dst ff02::1 (সবাই)
ICMPv6    RA  cur hop limit 64   M=0  O=1   router lifetime 1800 s
  prefix  2001:db8:acad:1::/64  L=1 A=1
          valid 2592000 s (৩০ দিন)  preferred 604800 s (৭ দিন)
  MTU     1500      source MAC 00:00:5e:00:53:fe

2001:db8:acad:1::/64 + 200:5eff:fe00:5302
= 2001:db8:acad:1:200:5eff:fe00:5302  (tentative)
DAD: NS src :: → ff02::1:ff00:5302 … উত্তর নেই → preferred

default route: ::/0 via fe80::1 dev eth0
O=1 → DHCPv6 Information-Request → ff02::1:2  (DNS সার্ভার কে?)
(অথবা RA-র ভেতরের RDNSS option থেকেই DNS — RFC 8106)

M আর O পতাকা, DHCPv6 আর prefix delegation

দুটি বাস্তব সূক্ষ্মতা। এক, DHCPv6 (এখন RFC 8415) default router জানায় না — সেটি সবসময় RA থেকেই আসে; তাই “শুধু DHCPv6, RA বন্ধ” নেটওয়ার্ক কাজ করে না। দুই, সব OS stateful DHCPv6 সমর্থন করে না — Android stateful DHCPv6 দিয়ে ঠিকানা নেয় না বলে বহুল জানা; তাই মিশ্র যন্ত্রের নেটওয়ার্কে SLAAC সাধারণত রাখতেই হয়। আর ISP-র দিকে DHCPv6-এর আরেকটি বড় কাজ prefix delegation: বাসার router ISP-র কাছে একটি পুরো prefix (ধরুন /56) চেয়ে নেয়, তারপর নিজের প্রতিটি LAN-এ তা থেকে একটি /64 ঘোষণা করে।

Simulator: SLAAC, DAD-এর সংঘাত আর প্রতিবেশী খোঁজা

নিচের simulator প্রথমে তিনটি ডকুমেন্টেশন-MAC থেকে EUI-64, solicited-node দল আর তার 33:33 MAC হিসাব করে। তারপর একটি LAN-এ PC2-কে দুবার চালু করে — প্রথমবার এটি একটি clone করা virtual machine, যার MAC ভুলবশত PC1-এর সাথে এক (বাস্তবে VM কপি করার সাধারণ ভুল); দ্বিতীয়বার নতুন MAC দিয়ে। শেষে PC2 প্রতিবেশী PC1-এর MAC খোঁজে:

// EUI-64, solicited-node and a SLAAC + Neighbor Discovery run on one link (deterministic).
const hx = n => n.toString(16);
function eui64(mac) {                                   // modified EUI-64 interface ID
  const b = mac.split(":").map(x => parseInt(x, 16));
  b.splice(3, 0, 0xff, 0xfe); b[0] ^= 0x02;              // insert ff:fe, flip the U/L bit
  return [0, 2, 4, 6].map(i => hx(b[i] * 256 + b[i + 1])).join(":");
}
function snm(iid) {                                     // solicited-node group + its 33:33 MAC
  const g = iid.split(":").map(x => x.padStart(4, "0")), t = g[2].slice(2) + g[3];
  return [`ff02::1:ff${t.slice(0, 2)}:${hx(parseInt(t.slice(2), 16))}`,
          `33:33:ff:${t.slice(0, 2)}:${t.slice(2, 4)}:${t.slice(4)}`];
}
for (const m of ["00:00:5e:00:53:01", "00:00:5e:00:53:02", "02:00:5e:00:53:aa"])
  console.log(`MAC ${m} -> IID ${eui64(m)} -> ${snm(eui64(m)).join("  ")}`);
const P = "2001:db8:acad:1:", PC1 = "00:00:5e:00:53:01", owner = { "fe80::1": "00:00:5e:00:53:fe" }; // router R ...
owner["fe80::" + eui64(PC1)] = owner[P + eui64(PC1)] = PC1;   // ... and PC1 are already on the link
function dad(addr) {
  const [g, m] = snm(addr.split(":").slice(-4).join(":"));
  console.log(`  DAD: NS src=:: dst=${g} (${m}) target=${addr}`);
  if (owner[addr]) { console.log(`  NA to ff02::1 from ${owner[addr]} -> DUPLICATE, stop`); return false; }
  console.log("  no NA within 1 s -> address is unique"); return true;
}
function boot(name, mac) {
  const iid = eui64(mac), ll = "fe80::" + iid, ga = P + iid;
  console.log(`\n${name} up, MAC ${mac}, tentative ${ll}`);
  if (!dad(ll)) return; owner[ll] = mac;
  console.log(`  RS: src=${ll} dst=ff02::2 (33:33:00:00:00:02)\n  RA: src=fe80::1 dst=ff02::1 M=0 O=1, prefix ${P}:/64 A=1, router life 1800 s`);
  if (!dad(ga)) return; owner[ga] = mac;
  console.log(`  ready: ${ga}/64, default router fe80::1`);
}
boot("PC2 (cloned VM, same MAC as PC1)", PC1);
boot("PC2 (after giving it a new MAC)", "00:00:5e:00:53:02");
const [g, m] = snm(eui64(PC1)), dst = P + eui64(PC1);
console.log(`\nPC2 -> ${dst}: neighbour cache miss`);
console.log(`  NS: src=${P + eui64("00:00:5e:00:53:02")} dst=${g} (${m})\n  NA: from ${owner[dst]} S=1 O=1 -> cache ${dst} = ${owner[dst]} REACHABLE`);

MAC 00:00:5e:00:53:01 -> IID 200:5eff:fe00:5301 -> ff02::1:ff00:5301  33:33:ff:00:53:01
MAC 00:00:5e:00:53:02 -> IID 200:5eff:fe00:5302 -> ff02::1:ff00:5302  33:33:ff:00:53:02
MAC 02:00:5e:00:53:aa -> IID 0:5eff:fe00:53aa -> ff02::1:ff00:53aa  33:33:ff:00:53:aa

PC2 (cloned VM, same MAC as PC1) up, MAC 00:00:5e:00:53:01, tentative fe80::200:5eff:fe00:5301
  DAD: NS src=:: dst=ff02::1:ff00:5301 (33:33:ff:00:53:01) target=fe80::200:5eff:fe00:5301
  NA to ff02::1 from 00:00:5e:00:53:01 -> DUPLICATE, stop

PC2 (after giving it a new MAC) up, MAC 00:00:5e:00:53:02, tentative fe80::200:5eff:fe00:5302
  DAD: NS src=:: dst=ff02::1:ff00:5302 (33:33:ff:00:53:02) target=fe80::200:5eff:fe00:5302
  no NA within 1 s -> address is unique
  RS: src=fe80::200:5eff:fe00:5302 dst=ff02::2 (33:33:00:00:00:02)
  RA: src=fe80::1 dst=ff02::1 M=0 O=1, prefix 2001:db8:acad:1::/64 A=1, router life 1800 s
  DAD: NS src=:: dst=ff02::1:ff00:5302 (33:33:ff:00:53:02) target=2001:db8:acad:1:200:5eff:fe00:5302
  no NA within 1 s -> address is unique
  ready: 2001:db8:acad:1:200:5eff:fe00:5302/64, default router fe80::1

PC2 -> 2001:db8:acad:1:200:5eff:fe00:5301: neighbour cache miss
  NS: src=2001:db8:acad:1:200:5eff:fe00:5302 dst=ff02::1:ff00:5301 (33:33:ff:00:53:01)
  NA: from 00:00:5e:00:53:01 S=1 O=1 -> cache 2001:db8:acad:1:200:5eff:fe00:5301 = 00:00:5e:00:53:01 REACHABLE

এবার একটি আসল Linux যন্ত্র দেখি। এই পাতার bash কোড যে container-এ চলে, সেখানে IPv6 আছে কি না জানা ছিল না — তাই স্ক্রিপ্টটি আগে ip আছে কি না দেখে, তারপর kernel-এর কাঁচা তালিকা /proc/net/if_inet6 পড়ে নিজেই ঘরগুলো ব্যাখ্যা করে। কিছুই বদলায় না, শুধু পড়ে:

# IPv6 on this Linux container: addresses, routes, and the kernel's raw address table.
if command -v ip >/dev/null; then
  echo "== ip -6 addr";  ip -6 addr
  echo "== ip -6 route"; ip -6 route
else
  echo "ip command not found - falling back to /proc"
fi
f=/proc/net/if_inet6
[ -r "$f" ] || { echo "$f missing: IPv6 is disabled or not available here"; exit 0; }
echo "== $f decoded (columns: address ifindex prefixlen scope flags device)"
while read -r addr idx plen scope flags dev; do
  full=$(echo "$addr" | sed 's/..../&:/g; s/:$//')
  case $scope in 00) sc=global;; 10) sc=host;; 20) sc=link;; *) sc="0x$scope";; esac
  fl=""
  (( 16#$flags & 0x80 )) && fl+="permanent "
  (( 16#$flags & 0x40 )) && fl+="tentative "
  (( 16#$flags & 0x20 )) && fl+="deprecated "
  (( 16#$flags & 0x08 )) && fl+="dadfailed "
  (( 16#$flags & 0x01 )) && fl+="temporary "
  echo "$dev  $full/$((16#$plen))  ifindex=$((16#$idx))  scope=$sc  flags=0x$flags ${fl:-(none: has lifetimes)}"
done < "$f"
echo "== per-interface settings"
for d in /proc/sys/net/ipv6/conf/*/; do
  n=$(basename "$d")
  echo "$n: addr_gen_mode=$(cat "$d/addr_gen_mode" 2>/dev/null || echo ?)  use_tempaddr=$(cat "$d/use_tempaddr" 2>/dev/null || echo ?)  mtu=$(cat "$d/mtu" 2>/dev/null || echo ?)"
done

== ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: tap0: <BROADCAST,UP,LOWER_UP> mtu 65520 state UNKNOWN qlen 1000
    inet6 fd00::40e7:54ff:fefc:234a/64 scope global dynamic mngtmpaddr 
       valid_lft 86400sec preferred_lft 14400sec
    inet6 fe80::40e7:54ff:fefc:234a/64 scope link 
       valid_lft forever preferred_lft forever
== ip -6 route
fd00::/64 dev tap0 proto kernel metric 256 expires 86399sec pref medium
fe80::/64 dev tap0 proto kernel metric 256 pref medium
default via fe80::2 dev tap0 proto ra metric 1024 expires 1799sec hoplimit 64 pref medium
== /proc/net/if_inet6 decoded (columns: address ifindex prefixlen scope flags device)
lo  0000:0000:0000:0000:0000:0000:0000:0001/128  ifindex=1  scope=host  flags=0x80 permanent 
tap0  fd00:0000:0000:0000:40e7:54ff:fefc:234a/64  ifindex=2  scope=global  flags=0x00 (none: has lifetimes)
tap0  fe80:0000:0000:0000:40e7:54ff:fefc:234a/64  ifindex=2  scope=link  flags=0x80 permanent 
== per-interface settings
all: addr_gen_mode=0  use_tempaddr=0  mtu=1280
default: addr_gen_mode=0  use_tempaddr=0  mtu=1280
lo: addr_gen_mode=0  use_tempaddr=-1  mtu=65536
tap0: addr_gen_mode=0  use_tempaddr=0  mtu=65520

৮ · IPv4 থেকে IPv6 — dual stack, tunnel আর অনুবাদ

পুরো ইন্টারনেট এক রাতে বদলানো অসম্ভব, তাই বহু বছর ধরে দুই protocol পাশাপাশি চলবে। সহাবস্থানের তিনটি মূল কৌশল:

Tunnel-এর ইতিহাস — যা এখন প্রায় অতীত

6to4 (RFC 3056) একটি public IPv4 ঠিকানা থেকে 2002::/16-এর একটি prefix বানাত; কিন্তু সর্বজনীন relay-গুলো অনির্ভরযোগ্য হওয়ায় সমস্যা বাড়ে, আর ২০১৫ সালে RFC 7526 এর relay ব্যবস্থাকে অপ্রচলিত ঘোষণা করে। Teredo (RFC 4380) NAT-এর পেছন থেকে UDP-র ভেতরে IPv6 নিত; Windows-এ বহু বছর ছিল, পরে ধীরে ধীরে বাদ পড়েছে বলে জানা যায়। আজ tunnel মূলত হাতে কনফিগার করা 6in4 (RFC 4213) বা tunnel broker-এর সেবা, আর ISP-র ভেতরে 6rd-এর মতো কৌশল। নিরাপত্তার দিক: tunnel-এর ভেতরের IPv6 শুধু-IPv4 firewall-এর চোখ এড়াতে পারে, তাই সীমানায় অপ্রত্যাশিত tunnel নজরে রাখা হয়।

NAT64 আর DNS64 — শুধু-IPv6 মোবাইল নেটওয়ার্কের রহস্য

অনেক বড় মোবাইল অপারেটর এখন ফোনকে শুধু IPv6 ঠিকানা দেয় — লাখ লাখ গ্রাহকের জন্য IPv4 ঠিকানা আর নেই। তাহলে শুধু-IPv4 একটি ওয়েবসাইট খোলে কীভাবে? দুই সহকারী মিলে:

1. DNS64: ফোন নামের IPv6 ঠিকানা (AAAA record, পর্ব ৩৫) চাইল। সাইটের আছে শুধু IPv4 (ধরুন 192.0.2.33). DNS64 তখন একটি “বানানো” IPv6 ঠিকানা ফেরত দেয়: well-known prefix 64:ff9b::/96-এর পেছনে IPv4-এর ৩২ বিট — 64:ff9b::c000:221 (লেখা যায় 64:ff9b::192.0.2.33).
2. NAT64: ফোন সেই ঠিকানায় packet পাঠায়। অপারেটরের NAT64 যন্ত্র prefix দেখে চেনে, শেষ ৩২ বিট থেকে IPv4 গন্তব্য বের করে, নিজের IPv4 ঠিকানা দিয়ে header অনুবাদ করে পাঠায় — উত্তর ফেরার পথে উল্টো অনুবাদ (NAT-এর টেবিলের মতো, পর্ব ১৯)।

সমস্যা থাকে সেই অ্যাপের, যেগুলো DNS ছাড়াই সরাসরি IPv4 ঠিকানা লেখে (কিছু পুরোনো গেম, VoIP). তাদের জন্য 464XLAT (RFC 6877): ফোনের ভেতরে একটি ছোট অনুবাদক (CLAT) অ্যাপকে একটি নকল IPv4 ঠিকানা দেয়, IPv4 packet-কে IPv6-এ অনুবাদ করে পাঠায়, আর অপারেটরের NAT64 আবার IPv4-এ ফেরায় — ৪ → ৬ → ৪. অনেক মোবাইল নেটওয়ার্কে এই সমাধান প্রচলিত বলে জানা যায়, আর Android-এ CLAT অন্তর্ভুক্ত আছে।

Happy Eyeballs — দুই পথে একসাথে চেষ্টা

Dual stack-এর একটি পুরোনো বিড়ম্বনা: সাইটের AAAA record আছে, কিন্তু কোথাও IPv6 পথ ভাঙা। ব্রাউজার আগে IPv6 চেষ্টা করে timeout-এর জন্য অনেক সেকেন্ড বসে থাকলে ব্যবহারকারী ভাবেন “ইন্টারনেট ধীর”। Happy Eyeballs (RFC 6555, পরে RFC 8305) সমাধান দেয়: প্রথমে IPv6 দিয়ে চেষ্টা, কিন্তু খুব অল্প সময়ে (RFC 8305 ২৫০ মিলিসেকেন্ড সুপারিশ করে) উত্তর না এলে সমান্তরালে IPv4-এর চেষ্টাও শুরু — যেটি আগে জোড়া লাগে, সেটিই থাকে। ঢাকার দুটি বাস রুটের মতো: পছন্দের রুটের বাস এক মুহূর্তে না এলে অন্য রুটের বাসেও হাত তোলা। আধুনিক ব্রাউজার আর OS-এ এটি ভেতরে ভেতরে চালু থাকে।

৯ · নিরাপত্তা — NAT নেই, firewall আছে

IPv4-এর যুগে অনেকেই ধরে নিয়েছিলেন NAT-ই নিরাপত্তা, কারণ বাইরে থেকে ভেতরের যন্ত্রে সরাসরি সংযোগ শুরু করা যেত না। IPv6-এ প্রতিটি যন্ত্রের global ঠিকানা আছে, তাই সেই “অঘোষিত দেয়াল” নেই। প্রকৃত সুরক্ষা সবসময় এসেছে stateful firewall থেকে: ভেতর থেকে শুরু হওয়া সংযোগের উত্তর আসতে দেওয়া, আর বাইরে থেকে শুরু হওয়া নতুন সংযোগ ডিফল্টভাবে আটকানো। বাসার router-এর জন্য RFC 6092 ঠিক এটাই সুপারিশ করে। কয়েকটি প্রতিরক্ষার নিয়ম:

• Firewall-এ IPv6 নিয়ম আলাদা করে দেখুন: শুধু IPv4-এর নিয়ম লিখে IPv6-কে খোলা রাখা একটি পরিচিত ভুল — অনেক OS-এ IPv6 ডিফল্টভাবে চালু থাকে, আপনি ব্যবহার না করলেও। Linux-এ nftables-এর inet family দুটিকে একসাথে ধরে (পর্ব ৪৯)।
• ICMPv6 পুরোপুরি বন্ধ নয়: NDP আর Packet Too Big ছাড়া IPv6 চলে না (অংশ ৬); RFC 4890-এর তালিকা মেনে বেছে বেছে সীমিত করুন।
• RA Guard: একই LAN-এর কোনো যন্ত্র ভুলে (ধরুন কেউ Windows-এ internet sharing চালু করলেন) বা উদ্দেশ্যমূলকভাবে নিজেকে router ঘোষণা করলে সবার traffic তার দিকে যেতে পারে। Managed switch-এ RA Guard (RFC 6105) শুধু router-এর port থেকে RA আসতে দেয় — IPv4-এর DHCP snooping-এর সমতুল্য।
• বড় subnet, বড় neighbour cache: একটি /64-এ ২^৬৪ ঠিকানা; বাইরে থেকে কেউ অস্তিত্বহীন অসংখ্য ঠিকানায় packet পাঠালে router প্রতিটির জন্য NS পাঠিয়ে cache ভরে ফেলতে পারে। প্রতিরক্ষা: router-এ NDP rate limit আর cache-এর সীমা।
• গোপনীয়তা: Client যন্ত্রে temporary বা stable privacy ঠিকানা রাখুন (অংশ ৫); সার্ভারে সহজে চেনা স্থির ঠিকানা স্বাভাবিক। Temporary ঠিকানা বদলায় বলে log তদন্তে /64 ধরে খোঁজা প্রায়ই কার্যকর।

১০ · AI-এর যুগে IPv6

IPv6-এর ধারণা ব্যাখ্যায় AI ভালো, কিন্তু ঠিকানা ছোট করা, EUI-64-এর বিট আর ঠিকানার ধরনে সে আত্মবিশ্বাসের সাথে ভুল করে, আর সমস্যায় প্রায়ই “IPv6 বন্ধ করে দিন” বলে কারণটাই লুকিয়ে ফেলে। পরিচিত ভুলগুলো:

AI-এর দেওয়া IPv6-উত্তর মানার আগে — চেকলিস্ট

• প্রতিটি ঠিকানা নিজে বড় করে ৮ ঘর গুনেছি, আর canonical রূপ একটি টুলে মিলিয়েছি
• EUI-64 বা solicited-node হিসাব binary-তে নিজে আবার করেছি
• “broadcast”, “ARP” বা /64-এর চেয়ে ছোট client LAN-এর কথা থাকলে প্রশ্ন তুলেছি
• কমান্ডগুলো আমার OS-এর কি না man page বা অফিশিয়াল ডকুমেন্টেশনে মিলিয়েছি (ip, ss; পুরোনো ifconfig/netstat নয়)
• Firewall পরামর্শে ICMPv6 পুরো বন্ধ বা সব খুলে দেওয়ার কথা থাকলে বাদ দিয়েছি; RFC 4890 দেখেছি
• RFC নম্বর আর পরিসংখ্যান মূল উৎসে খুঁজে পেয়েছি; বাস্তবে বদলের আগে ল্যাব বা VM-এ চালিয়ে packet capture করে দেখেছি