סלקום 5000/1000 ציוד פרטי - בדיקת מהירות ושיהוי IPv4 לעומת IPv6

whatevernevermind · שליחה #1 04/05/2026 18:11

שלום,

לאחרונה הקמתי רשת בחיבור 5000/1000 של סלקום, תשתית IBC, מתאם סיב GF10C ונתב פרטי - מיקרוטיק RB5009 בתצורת router on a stick. בזכות הפורום (תודה @itfan @DanielGR) ידעתי שזה הולך לסחוב בלי בעיה את החיבור, ובאמת התוצאות היו בהתאם למה שכבר פורסם כאן - פחות מ40% עומס על מחולק שווה בין המעבדים, ומהירות מלאה מתקבלת ע"י הלקוחות, וגם תוצאות bufferbloat מעולות בעומס מלא (A+ באתר waveform).

המשכתי בהגדרות והוספתי IPv6 PD, הלקוחות קיבלו כתובת IPv6 אמיתית ויכלו לגשת לאתרים ב IPv6. באמת נתקלתי באותה בעיה שתיאר @Jabberwock לגבי אתרים שלא מבצעים PMTU discovery, כמו אתר דואר ישראל, ופתרתי את זה ע"י ההגדרה המתאימה בנתב (זו למעשה לא תקלה של סלקום שכן האחריות על PMTU discovery היא תמיד של נקודות הקצה, בהגדרה, אבל לא כל הנתבים מבצעים mss clamping כברירת מחדל).

לאחר תחילת העבודה ב-IPv6 גיליתי שה-latency ל-CDNים הקרובים צנח (מ3-4ms ל1-2ms, קצה לקצה), שזה משמעותי.

מצד שני, בבדיקת מהירות חוזרת שמתי לב שהעומס על המעבדים מתקרב ל-100%, כמובן באשמת תהליך הPPPOE. בכל זאת עדיין קיבלתי את מלוא המהירות (בבדיקה של הורדה בנפרד והעלאה בנפרד, לא בו-זמנית). מסתבר שבדיקת המהירות שביצעתי בוחרת תמיד לעבוד בIPv6 כשאפשר, בגלל ה-latency הנמוך יותר. מבחינת העומס על המעבדים, מסתבר שהסיבה לכך היא שב-IPv4 הרווחתי מהאצת חומרה משמעותית (FastTrack) שלא עובדת על IPv6. ב-IPv6 עדיין קיבלתי האצת חומרה קלה (FastPath) שאני מניח שהיא מה שאפשר לי לא להתקל בצוואר בקבוק של עיבוד.

אני חושד ש5000 עם PPPOE זה קצה גבול היכולת של RB5009 ב-IPv6 ואם הייתי מנסה העלאה והורדה בו-זמנית זה כבר לא היה סוחב. האם מישהו בדק ביצועים של RB5009 או מוצרי RouterOS אחרים בIPv6 לעומת IPv4?

והאם גם בספקיות / ציוד אחר שבשימוש חברי הפורום, יש שיפור latency מובהק בשימוש בIPv6?

DanielGR · שליחה #2 04/05/2026 19:26

עריכה:

@whatevernevermind

ערכתי מחדש את התשובה משום שהתשובה הראשונית לא היתה ממצה מספיק (במחשבה נוספת).

הערה לגבי Fasttrack: למעשה Fasttrack איננו האצת חומרה. המודל הוא כזה: אין צורך למעשה לבדוק כל Packet ולהעביר אותה דרך ה- Firewall, מספיק בעצם לבדוק את ה-Connection (=הראשונה) ואם הוא עומד בקריטריונים אז להעביר את הבאות באופן שעוקף את העיבוד. זה עבור TCP, ועבור UDP שאין שם Connection אז מדובר על "Related". באופן הזה נחסך חלק משמעותי ממשאבי העיבוד. Fasttrack הינו הכרחי על מנת להגיע לקצבים גבוהים בהרבה דגמים של Mikrotik. ב-OpenWRT עם שימוש בהאצת חומרה של MTK, לדוגמא עם Banana PI R4, גם בתעבורה בקצב מקסימלי עומס המעבד קרוב ל-0 (!) משום שרוב העיבוד מתבצע לא על ידי המעבד, כולל PPPOE.

אין ב- Mikrotik מנגנון המאיץ PPPOE שזה מאד חבל

קיימת במיקרוטיק פונקציה של L3HW - ביצוע ניתוב על ידי חומרה בדגמים מסויימים המכילים Switch Chip שתומך בזה, יש רשימת דגמים, ו-RB5009 איננו אחד מהם, ובכל מקרה אין תמיכה בהאצה של PPPOE

אני לא יודע לפרטי פרטים כיצד Dual Stack ipv4 ipv6 מיושם כאשר מדובר ב- PPPOE, אבל מה שדי ברור שאין שני Sessions של PPPOE, אחד ל-ipv4 ואחד ל- ipv6. יש אחד, ולכן העומס הנגרם כתוצאה מ- PPPOE הוא יחיד ואין תוספת כתוצאה משימוש ב- ipv6. כלומר עם קיבלת עומס של 40% עם ipv4, העומס הנוסף כתוצאה מהפעלת ipv6 איננו נובע מ- PPPOE.

מה כן? עד לא מזמן Fasttrack נתמך אך ורק ב- ipv4, וייתכן שמה שאתה רואה זה עיבוד נוסף כתוצאה מכך שתעבורת ipv6 איננה Fasttracked.

לוודא:

ואז:

קוד: בחירת הכל

/ipv6/firewall/filter
add action=fasttrack-connection chain=forward comment="fasttrack established,related,untracked" connection-state=established,related,untracked
add chain=forward action=accept connection-state=established,related

וזה יפעיל Fasttrack גם עבור ipv6. התוספת של Fasttrack עבור ipv6 היא חדשה יחסית ואמור להיות שיפור בביצועים, נשמח לפידבק.

RB5009 הוא אחד הנתבים הטובים ביותר לסגמנט שאליו הוא מיועד. תיהנה

Jabberwock · שליחה #3 05/05/2026 8:49

whatevernevermind כתב: שלום,
באמת נתקלתי באותה בעיה שתיאר [mention]Jabberwock[/mention] לגבי אתרים שלא מבצעים PMTU discovery, כמו אתר דואר ישראל, ופתרתי את זה ע"י ההגדרה המתאימה בנתב (זו למעשה לא תקלה של סלקום שכן האחריות על PMTU discovery היא תמיד של נקודות הקצה, בהגדרה, אבל לא כל הנתבים מבצעים mss clamping כברירת מחדל).
...

מעניין אותי לדעת מה בדיוק הגדרת ואיפה. אני גם ניסיתי להגדיר ב-UCG-Fiber אבל לא הצלחתי, אולי הוא לא מכבד את ההגדרה ב-IPv6 אצלי?

DanielGR · שליחה #4 05/05/2026 15:25

ההגדרה כאן:

וזה יוצר Mange rule באופן אוטומטי. לחילופין - הגדרה סטטית:

קוד: בחירת הכל

/ipv6 firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn

הפעולה היא Clamp mss to pmtu.

עם ipv6 ב-Router OS לא אמור להיות השפעה על הביצועים של Fasttrack.

להלן שירשור מעניין מהפורום של מיקרוטיק על הנושא, אי דיוק אחד שיש שם הוא ש- Fasttrack נתמך כעת ב- ipv6 מה שלא היה נכון למועד השירשור.

https://forum.mikrotik.com/t/trying-to- ... g/175749/9

whatevernevermind · שליחה #5 05/05/2026 19:54

Jabberwock כתב: מעניין אותי לדעת מה בדיוק הגדרת ואיפה. אני גם ניסיתי להגדיר ב-UCG-Fiber אבל לא הצלחתי, אולי הוא לא מכבד את ההגדרה ב-IPv6 אצלי?
...

במיקרוטיק, השתמשתי בדיוק בשורה שגם ציטט @DanielGR

קוד: בחירת הכל

/ipv6 firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn

ניסיתי גם להעלות את הMTU של ממשק הPPPOE ע"י הגדלה מלאכותית של הMTU של הממשק עליו הוא רוכב, באופן מאוד דומה למה שמופיע בשרשור שמצוטט בהודעה הקודמת, אבל זה לא עבד. למען האמת את הבדיקה הזו ביצעתי כבר לפני מספר שנים ועם ספקיות שונות ובכל המקרים לא קיבלתי יותר מ-1492, הספקיות לא תמכו. חזרתי עליה היום עם סלקום ראש העין (bgn3.rhn) וקיבלתי עדיין MTU של 1492, אבל MRU שדווקא השתנה מ-1492 ל-1500. קיוויתי שזה יספיק אבל בלי ה clamp mss עדיין אתר הדואר נתקע.

אני משוכנע שבמוצר כמו UCG Fiber ניתן להגדיר mss clamping, הוא יקר מדי בשביל שלא יהיה לו משהו כזה...

הקטנה קבועה של הMTU גם תעבוד, אבל חבל...

לגבי שדרוג RouterOS לגרסה שיש בה Fasttrack ל-IPv6 - גם אני לא שמתי לב שהכניסו את הפיצ'ר הזה. סיבה טובה לשדרג, כשאוכל להגיע לבצע את זה אדווח על התוצאות.

אשמח אם חברי הפורום יסתכלו על ההבדלים בlatency בין IPv4 ל-IPv6, בעיני זו הסיבה היחידה שבאמת שווה בשבילה להתאמץ על IPv6.

OMRIJ · שליחה #6 05/05/2026 20:39

קיים בucg-fiber

whatevernevermind · שליחה #7 06/05/2026 13:31

@DanielGR

שדרגתי את ה-RouterOS והפעלתי חוק fasttrack על IPv6, העומס על המעבדים בזמן בדיקת מהירות ב-IPv6 ירד מכמעט 100% לקצת פחות מ40%, זהה לתוצאות בIPv4. חוק הmss clamping דולק ולא נראה שזה הפריע לו להעביר את החיבורים לfasttrack. תודה!

לאחר השדרוג גם ההפרש בשיהוי נראה מעט פחות מובהק, עדיין בטיפה לטובת IPv6. אולי גם שיפרו את ה-NAT של IPv4 בין הגרסאות? כנראה יותר סביר שזה תלוי בשעות ובאתרים שנבדקו - הפעם בדקתי בשעות מאוד לא עמוסות.

וכן, RB5009 אכן מהמוצלחים, אפילו בסטנדרטים של מיקרוטיק שהם מראש מאוד מוצלחים (אולי מלבד S+RJ10 הבוער והמגמגם).

Jabberwock · שליחה #8 06/05/2026 19:22

OMRIJ כתב: קיים בucg-fiber
...

קיים, ואפילו מופעל כברירת מחדל. אבל עדיין לא פותר את הבעיה ב-IPv6. אם אני זוכר נכון - אצלך החיבור הוא של בזק ולא סלקום (ממה שרשמת בעבר).

OMRIJ · שליחה #9 06/05/2026 19:39

אצלי בזק ואין בעיה...

Jabberwock · שליחה #10 06/05/2026 19:42

אז אתה לא יכול לבדוק אם ה-MSS Clamp עובד עם ה-UCG-Fiber כי הבעיה לא קיימת בבזק.

OMRIJ · שליחה #11 07/05/2026 5:06

לא התיימרתי לבדוק... רק לציין איפה ההגדרה

Jabberwock · שליחה #12 07/05/2026 14:16

אין אפילו אפשרות לשנות את ה-MTU על ה-WAN במכשיר הזה

OMRIJ · שליחה #13 07/05/2026 17:43

אתה צריך משהו שונה מ1492?
בכל מקרה, לפי זה
https://community.ui.com/questions/b050 ... 5a6587a1a0
הMTU יהיה מה שתגדיר ידנית בMSS פלוס 40.
לא בדקתי

Jabberwock · שליחה #14 07/05/2026 18:25

רוצה לדעת מה מוגדר כרגע

OMRIJ · שליחה #15 07/05/2026 18:59

אז תכנס עם ssh ותבדוק

DanielGR · שליחה #16 07/05/2026 23:15

לצורך העניין UCG-Fiber ובכלל Unify OS מבוסס על Debian, התחביר אמור להיות זהה.

Jabberwock · שליחה #17 12/06/2026 12:57

היה לי זמן לבדוק היום. הצלחתי למצוא פתרון בעזרת קלוד.
הפתרון הוא דרך SSH:

קוד: בחירת הכל

ip6tables -t mangle -I FORWARD 1 -i ppp0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
ip6tables -t mangle -I FORWARD 1 -o ppp0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

בשביל שיעבוד גם אחרי REBOOT:

קוד: בחירת הכל

mkdir -p /data/scripts
cat > /data/scripts/ipv6-mss-clamp.sh << 'EOF'
#!/bin/sh
PATH=/usr/sbin:/usr/bin:/sbin:/bin
WAN=ppp0
for DIR in -i -o; do
  ip6tables -t mangle -C FORWARD $DIR $WAN -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu 2>/dev/null || \
  ip6tables -t mangle -I FORWARD 1 $DIR $WAN -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
done
EOF
chmod +x /data/scripts/ipv6-mss-clamp.sh
echo "* * * * * root /data/scripts/ipv6-mss-clamp.sh" > /etc/cron.d/ipv6-mss-clamp

סיכום של קלוד:

Your PPPoE link negotiates an MTU of 1492 (1500 − 8 PPPoE overhead), and UniFi's UI-based MSS clamping was working correctly for both protocols:

• IPv4: MTU 1492 → MSS clamped to 1452 (1492 − 40)
• IPv6: MTU 1492 → MSS clamped to 1432 (1492 − 60)

The actual problem: your ISP's Router Advertisement on ppp0 limits the IPv6 path MTU to 1280 (the IPv6 minimum), attached as an mtu 1280 attribute on the RA-learned route. Testing confirmed the limit is real — packets above 1280 are blackholed by the ISP without any ICMPv6 Packet Too Big response. IPv4 is unaffected and runs at the full 1492.

So IPv6 needed an MSS of 1220 (1280 − 60), not 1432. Sites like Google survived the mismatch because they honor Packet Too Big messages; Azure drops them, so its oversized packets vanished and connections hung.

The fix: two ip6tables TCPMSS rules using --clamp-mss-to-pmtu, which derive 1220 automatically from the RA route (and adapt if the ISP ever fixes it), made persistent via /data/scripts/ipv6-mss-clamp.sh run by cron every minute to survive UniFi re-provisioning.
...

DanielGR · שליחה #18 12/06/2026 18:01

הסקריפט המתואר מפצה על כך שאין ל- UCG Gateway ממשק גראפי המאפשר הוספה של Mangle rules, השימוש ב-Mangle rules בין השאר לשנות את ה- MSS, ולכן זה עובד.

חבל, משום שזו פונקציונאליות סטנדרטית של iptable בלינוקס אבל Ubiquity החליטו לא לבנות לזה מעטפת גראפית, בניגוד לצורך דוגמא ב- RouterOS ששם זה קיים - ראה הודעה למעלה עם הקוד ל- RouerOS וזה גם קיים ונתמך בממשר הגראפי. לכן המעטפת של Ubiquity לוקה בחסר, בוודאי עבור ipv6 מכיוון שאפשר לבצע mss clamping באופן אוטומטי עבור ipv4.

למרות שמערכת ההפעלה מבוססת על Debian יש שינויים, ולא בטוח שזה רעיון טוב לממש דברים מחוץ למה שמעטפת הגראפית נותנת. ישנו סיכוי שזה ישבור משהו או יהיו קונפליקטים - אינני יודע ספציפית במקרה הזה. שיקול נוסף הוא לא רק האם זה ישרוד איתחול, אלא האם זה ישרוד עידכון גרסה. בעידכון גרסה חלק מה- File system שהוא Read-only נכתב מחדש, ואילו מחיצות מסוימות המכילות את ההגדרות כמו etc נותרות כפי שהן. הסקריפט האמור כותב ל-data שאינני יודע אם הוא שורד עידכון גרסה.

מסיבה דומה - עידכונים אמורים לבצע דרך המעטפת, ולא דרך apt update && apt upgrade כפי שמבצעים בלינוקס סטנדרטי.

עריכה: לאחר בדיקה - תיקיית data נשמרת לאחר עידכון גרסה

whatevernevermind · שליחה #19 13/06/2026 9:52

Jabberwock כתב: סיכום של קלוד:
...

הסיכום של קלוד לא כ"כ נכון, אולי כי המידע שהוזן לו היה לא מדוייק.

בPPPOE מתקבל MTU של 1492 - אין דבר כזה MTU שונה ל-IPv4 ול-IPv6. שהרי MTU היא תכונה של רמה 2 שעליה רוכבים כל פרוטוקולי רמה 3 כמו IPv4 ו-IPv6.

בהתאם, ping6 בגודל payload של 1444 (שעם כל התקורה של ICMPv6 על IPv6 יוצא 1492 ברמה 2) אכן עובר. לפחות אצלי בסלקום.

הבעיה היא במעבר בין רמה 3 לבין רמה 4 - במקרה הזה TCP. פרוטוקול TCP הוא פרוטוקול רצף, מחוסר גודל - יש לו רק התחלה וסוף (ללא גודל ידוע ביניהם). אבל מכיוון שהוא עובר על פרוטוקול רמה 3 הוא חייב בכל זאת לפצל את המידע לחתיכות (בTCP הן נקראות segment). לכן TCP מנסה לכייל את עצמו לגודל סגמנט שיתו הכי הרבה מידע עם מינימום תקורה, שמספר זה מכונה MSS - maximum segment size. בTCP, כדי לזרז את תהליך ההתאמה בין גדלי השליחה של הצדדים, שני הצדדים מספרים אחד לשני בעת הקמת החיבור על הMSS שהם מאמינים שיעבוד לכיוון שלהם. זה לא בהכרח המספר הנכון שכן יש עוד נתבים באמצע; בפרט אם ה-MTU של הרכיב השולח מול הנתב שלו הוא 1500, אבל של הנתב מול האינטרנט הוא 1492 (המצב בפועל כשיש PPPOE), הניחוש ההתחלתי של MSS לא יהיה נכון והצדדים יצטרכו לעבוד קצת יותר כדי לגלות אותו.

הדרך הנאיבית לעשות את זה היא לשלוח הכי גדול שאפשר ולחכות לאיתות מהצד השני שזה הצליח לעבור. אם לא, להקטין את גודל הסגמנט ולנסות שוב. לניסוי וטעייה הזו קוראים path MTU discovery (PMTU discovery).

כדי שזה יעבוד, התקן *מחייב* את שני הצדדים לתמוך באיתותים האלה - כאשר בIPv6 הם עוברים בצורת פאקטת ICMPv6 שנקראת "Packet Too Big". שני הצדדים ב IPv6 מחוייבים על פי התקן לקבל ולשלוח איתות זה - אחרת דברים בוודאות לא יעבדו כמו שצריך.

אז מקור הבעיה כאן הוא שבסלקום, מסיבה מסויימת, האיתותים מכיוון סלקום אל שרתי Azure נחסמים - בניגוד לתקן. זה אומר שסלקום חוסמת אותם לכיוון Azure, ולא משדרת אותם מלכתחילה או שלא מעבירה אותם. לחילופין, אפשרי שהם כן נשלחים מנתבי סלקום אבל Azure מסרב לקבל אותם מסלקום, למשל כי חושבים שזה סוג של התקפת מניעת שירות. כתוצאה, Azure לא מקבלת את האיתות שאומר שמה שהיא שלחה היה גדול מדי, ושני הצדדים נשארים תקועים בלחכות למשהו מהצד השני (deadlock). כך או כך - היעדר תמיכה מלאה בICMPv6 בכל המסלול זה משהו שנוגד לתקן, ובאמת הדברים נשברים. אפשר לתכנן ניסוי שיגלה מי הצד הבעייתי (סלקום או מיקרוסופט) אבל זה לא מאוד משנה לענייננו.

התיקון של MSS clamp גורם לנתב שבאמצע להסתכל על פאקטת הקמת החיבור - זו עם דגל SYN דלוק, ולראות האם הMSS שהלקוח חושב שיש לו (שנגזר מ1500) מתאים למה שהנתב יודע על המשך המסלול (שנגזר מ1492). כאמור זו הפאקטה שבה כל צד רומז לצד השני על מה שהוא חושב שיעבוד לכיוונו. אם הלקוח חושב שיש לו יותר ממה שיש בפועל, הנתב משנה בעצמו ומגביל (clamp) את ערך ה MSS בפאקטת הקמת החיבור לפני שמעביר אותה הלאה לאינטרנט. כך הצד השני בתקווה כבר ידע על ההתחלה להחזיר חתיכות בגודל המתאים ולא יצטרכו את תהליך הניסוי והטעייה.

הפיצ'ר הזה של TCP clamp MSS to PMTU מאוד נפוץ בדיוק בגלל דברים כאלה - PPPoE או VPNים מסוגים שונים אשר מגבילים את ה MTU בהמשך הדרך מהלקוח ליעד. זהת כדי לחסוך את הניסוי וטעייה, וכאפקט צדדי גם לטפל במקרים בהם אחד הצדדים שובר את התקן ובכלל לא מאפשר ניסוי וטעייה.

במקרה של סלקום, מספיק לטפל רק בפאקטות SYN, ורק בכיוון אחד, ורק מול Azure. מה שכתבת בפתרון מטפל ביותר מקרים (שני צדדים, גם RST) שלא לצורך, אבל זה לא יגרור תקורה מורגשת מצידך. אם זה עובד לך, ממליץ לא לגעת יותר.

אז למה כן להתעקש על IPv6? עם כל הסיבוך הזה והעובדה שהתקורות ממילא גדולות יותר בIPv6 מאשר בIPv4?

התשובה היא מה שכתבתי בכותרת השרשור - לפחות אצלי קיים יתרון מהירות מורגש של עד 5ms במסלול IPv6 ליעד מסויים בהשוואה למסלול IPv4. זה יכול להגיע גם ל25% שיפור בשיהוי, שזה ממש מורגש ומשמעותי בעת פתיחת המון חיבורים/המון שאילתות DNS (כלומר - בעת גלישה באתרים).

הסיבה היא שIPv4 עובר יותר עיבוד בדרך - בפרט לפחות עוד NAT אחד שלא קיים בIPv6 בכלל. גם בהמשך המסלול, צפויים עוד NATים פנימיים, יותר deep packet inspection ועוד עיבוד במסלול IPv4 שלא מומש באותה מידה ב IPv6. בשורה התחתונה, מרכיב הprocessing delay בשיהוי הכללי הוא קטן יותר, עם אותו transmission delay ואותו propagation delay.

DanielGR · שליחה #20 13/06/2026 15:03

תודה על ההסבר הממצה.

לגבי UCG-Fiber: למעשה אותו Checkbox של MSS C Clamping וההגדרה שלו כ- Auto, למעשה יוצרת Firewall mangle rule כאשר הפעולה היא Clamp to PMTU. הנקודה היא שמכיוון שיש חוקי Firewall עבור ipv4 ו- ipv6 אז צריך לעשות את זה פעמיים, פעם אחת עבור ipv4, ופעם עבור ipv6. די דומה לקוד של RouterOS שדי מסביר את עצמו:

קוד: בחירת הכל

/ipv6 firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn

בקוד זה הפעולה היא לשנות את ה- mss, clamp to pmtu, עבור תעבורה שעוברת דרך הנתב, הפרוטוקול הוא tcp, ו- tcp flag הוא syn - באיתחול קישור ה- tcp.
האם זה ממומש ב- UCG fiber עבור ipv6? אפילו אם המנגנון ממומש בנקודות הקצה, כל התהליך מבוסס על כך ש- PMTU Discovery עובד כמו שצריך, וזה תלוי גם בהגדרות של הניתוב בדרך. מעניין יהיה לדעת.

לגבי ipv6 - היתרונות ברורים - לפחות על הנייר. אבל ישנם גם חסרונות:

* ipv6 זמינה בקנה מידה רחב הרבה יותר מעשור (תלוי איך סופרים) די הרבה זמן להבשיל ועדיין יש גליצ'ים שונים - תמיכה לא מלאה ב- ipv6
* על מנת להגיע לקצבים גבוהים צריך להשתמש ב- Flowtables או Fasttrack כפי שמכונה ב- RouterOS. התמיכה ב- Fasttrack עבור ipv6 היא די חדשה, מה בעצם המשמעות של זה?
* יש למעשה שני סטים של Firewall rules, אחד ל- ipv4, ואחד ל- ipv6. לכן צריך להגדיר ולתחזק את שניהם, די לא סביר לדעתי. לדוגמא, הרשת אצלי מאובטחת על ידי Blocklist שיורד ברמה יומית לנתב משני מקורות - Firehol Level1, ו- Spamhaus עם חוקים בהתאם לחסום תעבורה מ- ואל כתובות מסוימות. הרשימות האלו הן ipv4, ויש רשימות נפרדות ל- ipv6. אם מופעל ipv6 אז צריך גם את המקבילות של הרשימות האלו (שאין לדעת אם הן באותה רמה) וחוקים בהתאם

יותר פשוט בלי זה, ושיעבוד בצורה עקבית.