Validateur IPv4
Valider les adresses IPv4 au format décimal pointé strict
Input IP Addresses
Validation Results
Validation results will appear here
Le validateur IPv4 effectue une validation stricte des adresses IPv4 en notation décimale pointée, en vérifiant les valeurs des octets, les erreurs de formatage, les zéros non significatifs et les caractères invalides. Saisissez une adresse comme 192.168.1.1 ou 10.01.1.256 et obtenez un résultat immédiat valide/invalide avec la raison spécifique de l'erreur et la classification du type d'adresse (privée, publique, loopback, multicast ou link-local).
Comprendre la validation des adresses IPv4
Une adresse IPv4 semble simple -- quatre nombres séparés par des points -- mais il y a plus de façons de se tromper qu'on ne le pense. Un seul chiffre hors limites, un espace parasite ou un zéro non significatif peut transformer une adresse valide en une adresse qui soit échoue complètement, soit, pire encore, est interprétée différemment selon les systèmes. Quand cette adresse se retrouve dans une règle de pare-feu, un enregistrement DNS ou une réservation DHCP, les conséquences vont d'un service bloqué à une faille de sécurité que personne ne remarque jusqu'au prochain audit.
Les zéros non significatifs sont l'exemple classique de l'importance d'une validation stricte. L'adresse 192.168.01.010 semble anodine pour la plupart des gens, mais certains langages de programmation et systèmes d'exploitation interprètent les octets avec des zéros non significatifs comme des nombres octaux. Dans ces systèmes, 010 ne signifie pas le décimal 10 ; il signifie le décimal 8 (car 010 en base 8 vaut 8 en base 10). La même chaîne d'adresse est interprétée comme 192.168.1.8 sur un système et 192.168.1.10 sur un autre. Si votre pare-feu interprète l'adresse d'une façon et votre application d'une autre, vous avez une incohérence extrêmement difficile à traquer.
Ce validateur applique les règles les plus strictes raisonnables pour détecter ces problèmes avant qu'ils n'atteignent la production. Il rejette entièrement les zéros non significatifs, exige exactement quatre octets décimaux entre 0 et 255, et signale tout espace, caractère spécial ou contenu non numérique. Pour les adresses qui passent la validation, il les classifie également par type -- privée RFC 1918, loopback, link-local, multicast ou publique -- afin que vous puissiez vérifier que l'adresse est appropriée pour l'usage prévu.
Comment valider une adresse IPv4
- Saisissez une ou plusieurs adresses IPv4 en format décimal pointé (par ex.
192.168.1.1) - Cliquez sur Validate pour vérifier chaque adresse selon des règles de formatage strictes
- Consultez les résultats indiquant le statut valide/invalide et l'erreur de validation spécifique pour les adresses rejetées
- Pour les adresses valides, visualisez la classification du type d'adresse et la référence RFC
Exemples de validation IPv4
| Entrée | Valide | Raison |
|---|---|---|
192.168.1.1 | Oui | Adresse privée valide (RFC 1918) |
8.8.8.8 | Oui | Adresse publique valide |
127.0.0.1 | Oui | Adresse loopback valide (RFC 1122) |
192.168.1.256 | Non | Le quatrième octet dépasse 255 |
10.01.1.1 | Non | Zéro non significatif dans le deuxième octet (interprétation octale ambiguë) |
192.168.1 | Non | Seulement 3 octets (exactement 4 requis) |
192.168.1.1.1 | Non | 5 octets (exactement 4 requis) |
192.168.1.-1 | Non | Valeur négative non autorisée |
192.168.1.1 | Non | Espace en fin de chaîne |
abc.def.ghi.jkl | Non | Valeurs d'octets non numériques |
0.0.0.0 | Oui | Adresse non spécifiée valide |
255.255.255.255 | Oui | Adresse de broadcast valide |
169.254.1.1 | Oui | Adresse link-local valide (RFC 3927) |
224.0.0.1 | Oui | Adresse multicast valide (RFC 5771) |
Classification des types d'adresses IPv4
Le validateur identifie le type et l'utilisation prévue de chaque adresse valide :
| Plage d'adresses | Type | RFC | Utilisation |
|---|---|---|---|
10.0.0.0/8 | Privée | RFC 1918 | Réseaux internes, NAT |
172.16.0.0/12 | Privée | RFC 1918 | Réseaux internes, NAT |
192.168.0.0/16 | Privée | RFC 1918 | Réseaux domestiques et petits bureaux |
127.0.0.0/8 | Loopback | RFC 1122 | Tests sur la machine locale |
169.254.0.0/16 | Link-Local | RFC 3927 | Auto-configuration (APIPA) |
224.0.0.0/4 | Multicast | RFC 5771 | Communication de groupe |
240.0.0.0/4 | Réservée | RFC 1112 | Usage futur (historiquement) |
100.64.0.0/10 | Partagée | RFC 6598 | NAT de niveau opérateur (CGNAT) |
| Toutes les autres | Publique | -- | Routable sur Internet |
Quand utiliser le validateur IPv4
- Vérification des entrées de règles de pare-feu -- valider les adresses avant de les ajouter aux ACL ou aux règles de groupes de sécurité pour prévenir les erreurs de configuration causées par des fautes de frappe
- Configuration DHCP et DNS -- s'assurer que les adresses dans les réservations DHCP statiques et les enregistrements DNS de type A sont correctement formatées avant d'appliquer les modifications
- Analyse de journaux et nettoyage de données -- filtrer les adresses IPv4 valides parmi des listes importées, des feuilles de calcul ou des extraits de fichiers journaux pouvant contenir des entrées malformées
- Validation de saisie dans les formulaires -- vérifier les adresses IP soumises par les utilisateurs dans les applications web ou les outils de gestion de configuration
- Audit de conformité -- confirmer que les adresses dans la documentation et les fichiers de configuration sont syntaxiquement correctes et appropriées pour leur usage déclaré
- Vérification d'entrées de scripts et d'automatisation -- valider les adresses passées en paramètres aux scripts de déploiement ou aux workflows d'automatisation avant leur exécution
Fonctionnement de la validation stricte IPv4
Les quatre règles de validation
- Exactement quatre octets séparés par des points : l'adresse doit contenir exactement trois points créant quatre groupes
- Octets numériques uniquement : chaque groupe doit être un entier décimal sans lettres, espaces ni caractères spéciaux
- Plage 0-255 : chaque octet doit être compris entre
0et255inclus, car chaque octet représente 8 bits - Pas de zéros non significatifs : les octets comme
01,007ou00sont rejetés car certains systèmes les interprètent en notation octale (par ex.010pourrait signifier le décimal 8 en octal)
Pourquoi les zéros non significatifs sont importants
La règle sur les zéros non significatifs prévient l'ambiguïté. Dans certains langages de programmation et systèmes d'exploitation, 192.168.01.010 est interprété comme 192.168.1.8 (analyse octale), tandis que dans d'autres il est lu comme 192.168.1.10 (décimal). La validation stricte rejette entièrement les zéros non significatifs pour éviter cette catégorie de bugs.
Input: 192.168.01.010
System A (decimal): 192.168.1.10
System B (octal): 192.168.1.8
These are different addresses! Strict validation rejects
the input to prevent this ambiguity.
Conseils pratiques pour la validation IPv4
Lorsque vous construisez des outils ou des scripts qui acceptent des adresses IP en entrée, validez toujours avant de traiter. Il est tentant de sauter la validation quand l'entrée provient d'une source « de confiance » comme un tableur interne ou une base de données de gestion de configuration, mais ces sources ne sont fiables que dans la mesure où la dernière personne qui les a modifiées l'était aussi. Un seul chiffre transposé ou une erreur de copier-coller peut se propager dans votre automatisation et causer des problèmes en production. La validation est peu coûteuse ; déboguer une règle de pare-feu mal configurée à 2 heures du matin ne l'est pas.
Soyez réfléchi quant à ce que vous acceptez et ce que vous rejetez. La validation stricte telle qu'implémentée ici est appropriée pour les contextes de configuration où la précision compte -- règles de pare-feu, enregistrements DNS, réservations DHCP. Mais dans les contextes d'analyse de journaux ou de supervision, vous pouvez vouloir une approche plus souple qui accepte les zéros non significatifs et les normalise, car rejeter l'entrée complète du journal pour un problème de formatage signifie que vous perdez des données. Décidez du niveau de strictesse approprié pour chaque cas d'usage et documentez votre choix.
La classification du type d'adresse n'est pas seulement informative -- utilisez-la pour appliquer des politiques. Si quelqu'un soumet une adresse loopback (127.x.x.x) comme cible d'un enregistrement DNS, c'est presque certainement une erreur. Si une règle de pare-feu référence une adresse privée RFC 1918 sur une interface tournée vers l'Internet public, quelque chose ne va pas. Validez non seulement la syntaxe mais aussi la sémantique : cette adresse est-elle appropriée pour le contexte dans lequel elle est utilisée ?
Questions fréquentes
0.0.0.0 est-elle une adresse IPv4 valide ?
Oui, 0.0.0.0 est syntaxiquement valide. Elle représente l'adresse « non spécifiée » (RFC 1122) et est couramment utilisée dans les tables de routage pour désigner la route par défaut, ou par les clients DHCP avant de recevoir une attribution d'adresse. Elle ne devrait jamais être attribuée à une interface hôte.
Quelle est la différence entre validation et accessibilité ?
La validation confirme qu'une adresse est syntaxiquement correcte et respecte les règles de format décimal pointé. Elle ne vérifie pas si l'adresse est effectivement accessible, attribuée ou en cours d'utilisation sur un réseau. Une adresse valide comme 198.51.100.1 (plage de documentation RFC 5737) passe la validation mais n'est pas routable sur l'Internet public.
Dois-je autoriser 255.255.255.255 dans mon application ?
Cela dépend du contexte. 255.255.255.255 est une adresse de broadcast limitée valide utilisée pour les diffusions sur le réseau local. Elle ne devrait pas être attribuée à un hôte ni utilisée comme destination dans les réseaux routés, mais elle a des usages légitimes dans le DHCP et les protocoles de découverte réseau.
Pourquoi 10.01.1.1 échoue-t-elle à la validation ?
Le zéro non significatif dans le deuxième octet (01) rend l'adresse ambiguë. Certains systèmes traitent 01 comme le décimal 1, tandis que d'autres le traitent comme l'octal 1 (aussi décimal 1 dans ce cas, mais 010 vaudrait le décimal 8). La validation stricte rejette tout zéro non significatif pour éliminer cette catégorie d'ambiguïté. Écrivez l'adresse 10.1.1.1 à la place.
Comment valider une adresse IPv4 avec un préfixe CIDR comme 192.168.1.0/24 ?
Cet outil valide les adresses IPv4 nues sans notation de préfixe. Pour valider une adresse avec un préfixe CIDR, utilisez le calculateur de sous-réseau IPv4 qui accepte la notation CIDR et valide à la fois l'adresse et la longueur du préfixe.
Outils associés
- IPv6 Validator - Valider les adresses IPv6 (formats complet et compressé)
- IPv4 ↔ Integer Converter - Convertir les adresses IPv4 vers/depuis les entiers 32 bits
- IPv4 ↔ Binary Converter - Convertir les adresses IPv4 vers/depuis la notation binaire
- IPv4 Private/Public Detector - Détecter si une adresse IPv4 est privée, publique ou spéciale
- Address Family Detector - Détecter si une adresse est IPv4, IPv6 ou invalide