Auteur Sujet: Orange DHCP conformité protocolaire 2023 - lire depuis le début du sujet (Lu 302920 fois)

Mastah · « **Réponse #1224 le:** 20 janvier 2025 à 16:12:32 »

Citation de: levieuxatorange le 20 janvier 2025 à 14:20:19

Bonjour

Je confirme, sans action, on garde un DualStack Full.
Donc ceux qui n'ont pas de Boxe, sans action spécifique, pas de changement

LeVieux

Top merci !

renaud07 · « **Réponse #1225 le:** 20 janvier 2025 à 17:28:54 »

Nickel, ça fait du travail en moins

Citation de: Asushen le 20 janvier 2025 à 09:09:43

d'ici là , la téléphonie fonctionnera en IPV6

Et pour l'instant pas de trace d'ipv6 sur les proxy SIP.

EDIT : De ce que j'ai lu, le DS-lite classique grossit assez mal vu que tout est réalisé dans l'AFTR. Il y aura une forte régionalisation je suppose pour répartir la charge ? À moins que ça ne soit plus d'actualité avec le matos actuel ? C'est quel équipement qui va réaliser la fonction d'ailleurs ? ba0bab ou un autre ?

simon · « **Réponse #1226 le:** 20 janvier 2025 à 17:56:58 »

Si je ne m'abuse, ba0bab est le BSR (ou son équivalent chez Orange), donc il est dans le réseau d'accès.
Si c'est bien le cas, ca aurait peu de sens de déployer DS-Lite uniquement sur la partie Livebox<>GPON<>OLT<>BSR. À mon sens, l'AFTR sera porté par un équipement à la maille de la grosse région, voire plus.

renaud07 · « **Réponse #1227 le:** 20 janvier 2025 à 18:57:31 »

Sans doute.

Après je ne sais pas combien de NRO gère un BNG, donc ça ne serait pas impossible.

levieuxatorange · « **Réponse #1228 le:** 21 janvier 2025 à 09:10:22 »

Citation de: renaud07 le 20 janvier 2025 à 17:28:54

EDIT : De ce que j'ai lu, le DS-lite classique grossit assez mal vu que tout est réalisé dans l'AFTR. Il y aura une forte régionalisation je suppose pour répartir la charge ? À moins que ça ne soit plus d'actualité avec le matos actuel ? C'est quel équipement qui va réaliser la fonction d'ailleurs ? ba0bab ou un autre ?

Plusieurs choses :
- c'est pas BOBAB qui bosse sur la fonction AFTR
- l'AFTR grossit mal verticalement (un seul plus gros AFTR) car effectivement il fait quand même beaucoup de chose
- par contre y'a aucune difficulté à faire une croissance horizontale
- et y'a aucune difficulté à faire une répartition dynamique entre les clients et les AFTR. Cela peut même se faire à chaque reco en IPv6 si la conf du CPE est suffisamment bien faite.
- et séparer la fonction AFTR des BNG permet de prévoir une répartition optimale: optimiser le placement des AFTR avec l'archi réseau et l'acheminement. En déployer plus. Les résorber quand cela sera le moment.

Remarque : tout ce que j'écris là peut très bien se faire avec d'autre techno (MAP, ...) mais je n'en n'ai aucune idée jamais regardé.

Pour ceux qui veulent tenter le DS-LITE, y'a des truc à base de 100% Linux et des espaces de nommage et routage du noyau. C'est même une assez bonne implémentation de référence je trouve.
Y'a 60 lignes de conf shell pour mettre cela en place d'un client Ipv6 Only en DSLITE, l'AFTR et le répondeur

LeVieux

basilix · « **Réponse #1229 le:** 21 janvier 2025 à 11:11:26 »

Je n'ai pas beaucoup de connaissances en réseautique.

Le réseau local peut-il fonctionner en « IPv6-mostly » avec du Dual-Stack Lite ?

Selon la section « Dual-Stack Lite » de Wikipédia, les stations communiquent sur l'Internet v4 par l'intermédiaire d'une IPv4 privée.
Donc, pour avoir un réseau local « IPv6-mostly », il me semble qu'il faudrait plutôt une solution basée sur NAT64 dans le routeur CPE.

simon · « **Réponse #1230 le:** 21 janvier 2025 à 12:09:46 »

Citation de: basilix le 21 janvier 2025 à 11:11:26

Le réseau local peut-il fonctionner en « IPv6-mostly » avec du Dual-Stack Lite ?

Il peut, mais c'est plus compliqué : il faut que le routeur (CPE/box) embarque un NAT64 et une interface DS-Lite.

levieuxatorange · « **Réponse #1231 le:** 21 janvier 2025 à 12:56:54 »

Citation de: simon le 21 janvier 2025 à 12:09:46

Il peut, mais c'est plus compliqué : il faut que le routeur (CPE/box) embarque un NAT64 et une interface DS-Lite.

L'idée c'est plutot d'avoir un vrai DualStack dans le LAN, sur le réseau local.
Avec une préférence très nette de CHAQUE DEVICE (et c'est bien là la difficulté ...) pour IPv6. Avec dans ce cas strictement aucune manip de paquet IPv6.

Et si utilisation de IPv4 pour aller vers l'extérieur (en local du LAN, aucun paquet n'est modifié et rien ne change) là dans ce cas le NAT au lieu d'être fait en local de la box est fait 'plus loin" dans le CGN.
Avec un partage de NAT des IPv4 sortantes entre plusieurs clients.

Sur le WAN opérateur, l'avantage c'est que tu fais que de l'IPv6, donc dans l'optimisation des flux tu n'as qu'un seul protocole à équilibre / trimbaler / surveiller.

Le CGN suivant où tu le fait, tu peux limiter ton IPv4 "à la bordure". Mais cela c'est une vision de dans 10 ans, quand tout sera dans ce type de fonctionnement

En attendant le coeur reste DualStack

LeVieux

basilix · « **Réponse #1232 le:** 21 janvier 2025 à 13:57:17 »

Citation de: levieuxatorange

L'idée c'est plutôt d'avoir un vrai Dual Stack dans le LAN, sur le réseau local.

Citation de: levieuxatorange

Sur le WAN opérateur, l'avantage c'est que tu fais que de l'IPv6, donc dans l'optimisation des flux tu n'as qu'un seul protocole à équilibre / trimbaler / surveiller.

C'est compréhensible pour un FAI.

Cela semble donc à l'inverse de ce que je souhaite, placer IPv4 en bordure de mon réseau.

Citation de: simon

Il peut, mais c'est plus compliqué : il faut que le routeur (CPE/box) embarque un NAT64 et une interface DS-Lite.

Je ne vais pas me rendre les choses plus difficiles et faire encore plus compliqué. Autant rester en double pile : IPv4 + IPv6 sur le CPE.

levieuxatorange · « **Réponse #1233 le:** 21 janvier 2025 à 14:22:37 »

Citation de: basilix le 21 janvier 2025 à 13:57:17

Je ne vais pas me rendre les choses plus difficiles et faire encore plus compliqué. Autant rester en double pile : IPv4 + IPv6 sur le CPE.

Coté LAN, effectivement je te conseille.
Y'a PLEIN de truc qui supporterons pas le MonoStack IPv6.

Après, dans 10ans, j'espère que cela sera possible, mais moi perso, mon Poele, c'est IPv4 only ....... ainsi que tout un tas de points de contrôle de mes automatisme.
Sans parler d'une de mes imprimantes (de marque pourtant) avec un stack IPv6 tellement pourris que je l'ai désactivé ...

Matter, c'est beau, mais c'est pas encore ça ...

LeVieux

renaud07 · « **Réponse #1234 le:** 21 janvier 2025 à 21:31:03 »

Citation de: levieuxatorange le 21 janvier 2025 à 09:10:22

Plusieurs choses :
- c'est pas BOBAB qui bosse sur la fonction AFTR
- l'AFTR grossit mal verticalement (un seul plus gros AFTR) car effectivement il fait quand même beaucoup de chose
- par contre y'a aucune difficulté à faire une croissance horizontale
- et y'a aucune difficulté à faire une répartition dynamique entre les clients et les AFTR. Cela peut même se faire à chaque reco en IPv6 si la conf du CPE est suffisamment bien faite.
- et séparer la fonction AFTR des BNG permet de prévoir une répartition optimale: optimiser le placement des AFTR avec l'archi réseau et l'acheminement. En déployer plus. Les résorber quand cela sera le moment.

Remarque : tout ce que j'écris là peut très bien se faire avec d'autre techno (MAP, ...) mais je n'en n'ai aucune idée jamais regardé.

Pour ceux qui veulent tenter le DS-LITE, y'a des truc à base de 100% Linux et des espaces de nommage et routage du noyau. C'est même une assez bonne implémentation de référence je trouve.
Y'a 60 lignes de conf shell pour mettre cela en place d'un client Ipv6 Only en DSLITE, l'AFTR et le répondeur

LeVieux

Merci pour toute ces précisions. Je me doutais au fond que ça ne serait pas ba0bab qui ferait AFTR. Effectivement, les tunnels semblent plus simple à bouger d'un AFTR à l'autre vu que tout est dynamique, ce qui est moins le cas du MAP où tout est statique ou presque avec la règle unique de partage des ports par ip publique, mais en contrepartie, moins de charge sur les BR/lwAFTR.

Pour ce qui est de l'implémentation Linux, j'essaye de le faire fonctionner justement. J'ai trouvé cet article de blog : https://timstallard.me.uk/blog/2018-04-17-ds-lite/ à base de ip et d'iptables avec du mangle pour marquer les paquets. Cependant, je remarque que si je ne désactive pas le forwarding ipv6, les paquets ne sont même pas désencapsulés et balancés tel quel en sortie.

J'ai ensuite trouvé cet un autre script qui semblait plus propre : https://github.com/jeduardo/dslite-server Sauf qu'avec celui-ci, seul les paquets en provenance du B4 sont natés, ceux provenant du LAN sortent tel-quel... J'ai à tout hasard fait un mélange des deux et cette fois tout semble marcher (à reconfirmer) il faut utiliser le script github + les règles mangle de l'article et là je peux avoir le forwarding ipv6 actif, ça fonctionne.

Si tu as un script plus propre à proposer, je prends avec plaisir. Ou si tu as expérimenté sur VPP (j'essaie aussi de faire fonctionner, sans succès pour le moment...)

Côté positif, c'est beaucoup plus simple à mettre en place (quand ça veut),même si ce n'est sans doute pas dans les règles de l'art part rapport à une implémentation constructeur, alors qu'avec MAP-E/T, ça demande pas mal de code en plus (jool, VPP...)

renaud07 · « **Réponse #1235 le:** 22 janvier 2025 à 17:50:43 »

Pour ceux qui veulent bidouiller, voici le script que j'ai un peu paufiné pour l'AFTR, qui se base donc sur celui-ci : https://github.com/jeduardo/dslite-server avec les compléments de https://timstallard.me.uk/blog/2018-04-17-ds-lite/ pour marquer les paquets.

Après avoir fait un

Code: [Sélectionner]

echo "1 dslite1" >> /etc/iproute2/rt_tables ça devrait marcher.

Code: [Sélectionner]

#!/bin/bash

set -o nounset  # Exit if trying to use an uninitialized variable
set -o errexit  # Exit on any command failure

# Source the configuration file
CONFIG_FILE="/etc/default/dslite-server"
if [ -f "$CONFIG_FILE" ]; then
    source "$CONFIG_FILE"
else
    echo "Configuration file $CONFIG_FILE not found. Exiting."
    exit 1
fi

# Apply default values if variables are empty
LOCAL_HOST="${LOCAL_HOST:-aftr.example}"
REMOTE_HOST="${REMOTE_HOST:-remote.example}"
TUN_IP4="${TUN_IP4:-192.0.0.1/29}"
TUN_NET="${TUN_NET:-192.0.0.0/29}"
TUN_IFACE="${TUN_IFACE:-ip4tun0}"
WAN_IFACE="${WAN_IFACE:-eth0}"
# Using same MTU as OpenWrt
#MTU="${MTU:-1280}"
MTU=1460

# MSS is MTU - IP Header size - TCP header size
MSS=$(($MTU - 20 - 20))

get_ipv6() {
    host "$1" | grep -i ipv6 | rev | cut -d ' '  -f 1 | rev
}

LOCAL_ADDR=$(get_ipv6 "$LOCAL_HOST")

# Only perform REMOTE_ADDR lookup if not set in the configuration file
REMOTE_ADDR="${REMOTE_ADDR:-$(get_ipv6 "$REMOTE_HOST")}"

echo "IP for $LOCAL_HOST is $LOCAL_ADDR"
echo "IP for $REMOTE_HOST is $REMOTE_ADDR"
echo "WAN interface is $WAN_IFACE, tunnel interface is $TUN_IFACE"

iptables_rule() {
    local action="$1"
    local rule_suffix="$2"

    # Allowing NAT
    eval iptables -t nat "$action" POSTROUTING ! -d "$TUN_NET" -o "$WAN_IFACE" -j MASQUERADE $rule_suffix
    # Allowing forwarding between interfaces
    eval iptables "$action" FORWARD -i "$TUN_IFACE" -o "$WAN_IFACE" -j ACCEPT $rule_suffix
    eval iptables "$action" FORWARD -i "$WAN_IFACE" -o "$TUN_IFACE" -m state --state ESTABLISHED,RELATED -j ACCEPT $rule_suffix
    eval iptables "$action" FORWARD -i "$WAN_IFACE" -o "$WAN_IFACE" -d "$TUN_NET" -j ACCEPT $rule_suffix
    # Allowing inbound traffic
    eval iptables "$action" INPUT -i lo -s "$TUN_NET" -d "$TUN_NET" -j ACCEPT $rule_suffix
    eval iptables "$action" INPUT -i "$TUN_IFACE" -s "$TUN_NET" -d "$TUN_NET" -j ACCEPT $rule_suffix
    # Applying clamping
    #eval iptables "$action" FORWARD -o "$TUN_INET" -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss "$(($MSS + 1)):65535" -j TCPMSS --set-mss "$MSS"
    #eval iptables -t nat "$action" PREROUTING -i "$TUN_INET" -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m tcpmss --mss "$(($MSS + 1)):65535" -j TCPMSS --set-mss "$MSS"
    # Allowing receiving packets from the public endpoint
    eval ip6tables "$action" INPUT -s "$REMOTE_ADDR" -j ACCEPT $rule_suffix

# Enable LAN packets marking
eval iptables -t mangle "$action" PREROUTING -i "$TUN_IFACE" -j MARK --set-mark 1
eval iptables -t mangle "$action" POSTROUTING -j CONNMARK --save-mark
eval iptables -t mangle "$action" PREROUTING -j CONNMARK --restore-mark

}

start_tunnel() {
    # Without this there is no forwarding
    sysctl -w net.ipv4.ip_forward=1

    ip -6 tun add "$TUN_IFACE" mode ipip6 local "$LOCAL_ADDR" remote "$REMOTE_ADDR"
    ip link set dev "$TUN_IFACE" up
    ip link set dev "$TUN_IFACE" mtu $MTU
    ip a add "$TUN_IP4" dev "$TUN_IFACE"

    iptables_rule "-I" ""
ip route add default dev "$TUN_IFACE" table dslite1
ip rule add fwmark 1 iif "$WAN_IFACE" table dslite1
    echo "ds-lite server is up"
}

stop_tunnel() {
    ip link del "$TUN_IFACE" || true
    iptables_rule "-D" "|| true"
    rmmod ip6_tunnel || true
ip route del default dev "$TUN_IFACE" table dslite1
ip rule del fwmark 1 iif "$WAN_IFACE" table dslite1


    echo "ds-lite server is down"
}

case "$1" in
    start)
        start_tunnel
        ;;
    stop)
        stop_tunnel
        ;;
    *)
        echo "Usage: $0 {start|stop}"
        exit 1
        ;;
esac

Le script se base sur la résolution des noms pour les endpoints, il faut donc le renseigner dans le DNS. Au pire virez simplement cette section et mettre directement les IP dans les variables.

De l'autre côté openwrt en guise de B4 et c'est tout. Par contre il semble y avoir quelques soucis de MTU (impossible d'aller au delà de 1400 pour le tunnel), du moins dans ma machine virtuelle. Idem pour la MTU à 1540 côté AFTR, ma debian n'est pas contente.