Google Cloud הרחיבה ב־6 בנובמבר 2026 את התמיכה ב־IPv6 בחזית מערך האיזון שלה לזמינות כללית (GA). המשמעות היא שארגונים יכולים לקבל תעבורה נכנסת מלקוחות IPv6 בשישה סוגים נוספים של Load Balancer אזורי ובין־אזורי, בלי להמיר את כל שכבת היישום וה־backends ביום אחד.
אילו שירותים קיבלו תמיכה כללית?
לפי הודעת השחרור הרשמית, חזית IPv6 זמינה כעת ב־Regional external Application Load Balancer, ב־Regional external proxy Network Load Balancer, ב־Regional internal Application Load Balancer, ב־Regional internal proxy Network Load Balancer, וכן בגרסאות ה־cross-region הפנימיות של Application ו־proxy Network Load Balancer.
בפועל, לקוח יכול להתחבר לכתובת IPv6 של ה־Load Balancer, ושירות האיזון מסיים את חיבור ה־IPv6 ומעביר את הבקשה ל־backend באמצעות IPv4 או IPv6 — בהתאם להגדרת ה־backend וליכולת שלו. כך ניתן להוסיף שכבת גישה מודרנית בלי לכפות מעבר מיידי של כל השרתים.
ההחלטה החשובה: proxy-only subnet
בתצורות המבוססות על proxy-only subnet, סוג ה־stack קובע מה יקרה מאחורי ה־Load Balancer. תת־רשת מסוג IPV4_ONLY יכולה לשרת חזית IPv6, אבל החיבור אל ה־backend יישאר IPv4. תת־רשת מסוג IPV4_IPV6 מאפשרת ל־proxies לבחור גם חיבור IPv6 אל ה־backends התומכים בכך.
זו נקודת תכנון מהותית: חזית IPv6 אינה שוות ערך אוטומטית ליישום end-to-end IPv6. היא כן מאפשרת מעבר הדרגתי — קודם קבלת תעבורה מלקוחות IPv6, ובהמשך שדרוג ה־backends והתשתית הפנימית.
מה צריך לבדוק לפני ההפעלה?
- DNS: הוסיפו רשומת AAAA רק אחרי שה־forwarding rule וה־health checks פעילים, כדי להימנע מנתיב שבור ללקוחות IPv6.
- כתובות ותתי־רשתות: בתצורות אזוריות מסוימות נדרשת רשת VPC במצב custom ותת־רשת forwarding מתאימה. בהקצאות פנימיות Google משתמשת בטווחי /96.
- חומות אש: ודאו שחוקי ingress ו־health checks מכסים את טווחי ה־proxy וה־backend הרלוונטיים; הוספת IPv6 אינה מחליפה את כללי ה־IPv4 הקיימים.
- תמיכת backend: לא כל סוג backend תומך ב־dual stack. לפי התיעוד, התמיכה מתמקדת ב־VM instance groups וב־zonal
GCE_VM_IP_PORTNEGs. - מגבלות דור קודם: Load Balancers קלאסיים אינם מקבלים אוטומטית backend דו־מחסנית, ולכן יש לבדוק את סוג המשאב ולא רק את שמו.
שדרוג תצורה קיימת דורש תכנון
מי שכבר מפעיל proxy-only subnet חד־מחסנית לא תמיד יכול לשנות אותה ישירות ל־dual stack. במקרים המתועדים נדרש ליצור subnet חלופי, לקדם אותו לתפקיד הפעיל ורק אחר כך להשלים את המעבר. לכן כדאי לתכנן חלון שינוי, לבדוק capacity ולוודא שיש דרך חזרה.
המהלך החדש מפחית חסם משמעותי בדרך לאימוץ IPv6, במיוחד בארגונים שרוצים לתת שירות ללקוחות סלולריים, רשתות ענן וספקים שעוברים בהדרגה ל־IPv6 — אך הוא אינו מבטל את הצורך בבדיקות אבטחה, DNS, ניטור ו־observability לכל stack בנפרד.
מקורות
- Google Cloud Load Balancing release notes
- תיעוד IPv6 ל־Cloud Load Balancing
- תיעוד proxy-only subnets
תמונה: Nick Fewings, דרך Unsplash. רישיון Unsplash מתיר שימוש חופשי מסחרי ולא־מסחרי, לרבות באתר וברשתות חברתיות, ללא צורך באישור נוסף; אין למכור את הקובץ כפי שהוא או ליצור באמצעותו שירות תמונות מתחרה. התמונה היא המחשה מטפורית לניתוב תעבורה ואינה צילום מוצר של Google.
