Talk:WikiJournal of Science/A Survey on Internet Protocol version 4 (IPv4)
Add topic
WikiJournal of Science
Open access • Publication charge free • Public peer review • Wikipedia-integrated
Previous
Volume 1(1)
Volume 1(2)
Volume 2(1)
Volume 3(1)
Volume 4(1)
Volume 5(1)
Volume 6(1)
This article has been through public peer review.
Post-publication review comments or direct edits can be left at the version as it appears on Wikipedia.First submitted:
Accepted:
Article text
PDF: Download
DOI: 10.15347/WJS/2022.002
QID: Q104661268
XML: Download
Share article
Email
| 
Facebook
| 
Twitter
| 
LinkedIn
| 
Mendeley
| 
ResearchGate
Suggested citation format:
Michel Bakni; Sandra Hanbo (9 December 2022). "A Survey on Internet Protocol version 4 (IPv4)". WikiJournal of Science. doi:10.15347/WJS/2022.002. Wikidata Q104661268. ISSN 2470-6345. OCLC 9708517136. https://upload.wikimedia.org/wikiversity/en/d/db/A_Survey_on_Internet_Protocol_version_4_%28IPv4%29.pdf.
Citation metrics
AltMetrics
Page views on Wikipedia
Wikipedia: Content from this work is used in the following Wikipedia article: Internet Protocol version 4.
License: 
This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction, provided the original author and source are credited.
Emanuele Natale 
contact
Damien Saucez
Igor Dias Da Silva
Article information
Peer review 1
Review by Damien Saucez 
, Inria
These assessment comments were submitted on , and refer to this previous version of the article
Summary: This document proposes a description of the IPv4 protocol and its main features.
Pros:
- most features of IPv4 described in one place => good reference for people that need information rapidly
- neutral description of the protocol but... (see cons)
Cons:
- ... the document is purely descriptive and doesn't provide the rationals of the different choices made in IPv4
- the document targets readers already familiar with networking, key concepts are not explained. The document is thus not accessible to general audience.
- lack of discussion about implementations, routing, and management that are of paramount importance in the IP world
- too much importance is given to classful addressing
Recommendation: Major revision
Discussion: The idea of proposing a reference document about IPv4 is excellent however the way the document is written is probably not the correct one. In its current form, the document is a collection of descriptions, a succession of bullets, a set of information. As a consequence, the added value of the document is limited. People could just go to Wikipedia and have a look at the different RFCs to get global and precise information or read the various books about IP that have been written during the last 20-30 years. If authors (and the journal) want to have impact and be read by many (among others student starting their studies in networking), the document should be written in a more tutorial way. Definitely authors have experience in the IP world and this experience should appear in the text.
A possible structure could be to start with a problem statement sections that describes what are communications and why it was needed to move to something like IP (The historical background tries this but is very limited and remains within the datagrams concept). Probably the most important (and often not understood) concept that changed the world (for ever?) is the move to packet switching from typical circuit switching. Then it would be great that people understand why it was needed to move to the notion of datagram and what it fundamentally changes for communications (e.g., multiplexing, routing, multi path, resource sharing…). Once the concept is understood then it could be explained why IP won over its competitors (both from technical and political viewpoints).
Once the context is understood then we can move to the protocol itself. But first it is essential to explain its position in the whole communication stack. Often people refer to the OSI model but it is not mandatory to use it as it is kind of outdated and not always relevant nowadays. It could be described in a top-down (service to user -> transmission of bits) or a bottom-up approach (from transmission of bits to service to users). Having a layered approach help understanding why IP needs the features it has.
A good share of the document should be related to implementation details of IP (32 bits and 8 bits words have not been chosen randomly!). This could explain why classful was proposed first (easy to implement with the basic devices we had back in the early days of IP) then why CIDR became possible, but at the cost of complex data structures. It should be shown how lookups are performed for classful and classless addresses.
Btw, way too much time is spent explaining clasful adresses. AFAIK virtually all IPv4 implementations are classless since at least a decade. CF is definitely just part history but essential to understand as some CLIs (e.g., Cisco’s) still use the concept when no information about the network is provided (for backward compatibility).
Coming to the addressing part of the document, it should be rewritten. It is essential to first define the notion of network (all hosts within a network can be reached directly without the need of any L3 gateway without outside the network a layer 3 gateway is needed). This would make the concept of subnet and mask cristal clear. Also it would be great to explain how masks are actually used and implemented and remember the user that with CIDR the prefix is not carried in the IP packet and is just an arbitrary selector at the host/gateway level (e..g, introduce the concept of aggregation for scalability). Probably that showing bitwise operations on addresses and mask would greatly clarify the concept of host and network.
IP also relies on a plethora of side protocols and OAM procedures (Operations, Administration, and Maintenance), among other ARP and the IANA stuff presented in the document. Why not making a chapter on how to operate IP networks and explain that a large part is related to making sure that addresses are not duplicated and in linking IP addresses to lower (e.g., ARP) or higher (e.g., DNS) layer protocols. NAT should be discussed in more details and linked with the concept of private internets (RFC1918).
Routing is missing in this document. Ok, it is not part of IPv4 per se, but without the concept of routing there is no inter-connection of networks.
Another part missing in this document is the usage of IP outside of Internet, e.g., enterprises, data-centres…
All addresses and names presented in the document should follow RFC 5737 and RFC 6761 recommendations.
IPv4 is officially a legacy protocol at the IETF that is still maintained but not mandatory any more (see I.D.-draft-schoen-intarea-ietf-maintaining-ipv4 for details), this must be discussed in the document.
Thank you for reviewing the article we wrote, I will consider the notes you added. Please find my reply to the points you raised.
I hope you consider that this is not a leading paper in the domain. Instead, it is a survey on what had been already created regarding IPv4. Thus, there is no additional value, this was intentional from the beginning. From the same perspective, we think that we should not start showing the problem of the research, instead, we choose to start showing the historical predictive. Clearly, there is no problem addressed in this paper.
Done I will add details on the packet switching part following your advice.
Regarding the use of the stack layer model, we did not use OSI model, instead, our work is based on TCP/IP model. Based on the scientific literature we reviewed (mainly RFC 791 & RFC 1180), we believe that this is the better approach to address the protocol.
Done Explain the idea behind using classful addressing and the size of the network
Done Restructuring classless and classful addressing section.
Done Introduction of the route aggregation in the CIDR section.
Done Expand ARP & NAT Sections to include more details + Interducing the DNS address->name and name->address operations.
Regarding routing, we do believe that addressing routing with IP is confusing and not proper. Although it is heavily relying on the addressing mechanism. Routing is not part IPv4. Not including it in the paper is completely a conscience decision. and we still believe that including it will be confusing, and prefer not to address it in this paper. Done We were able to shortly address routing process in the application section. We did insist that it is not a part of IPv4.
Done Add an application section at the end of the paper.
Done follow RFC 5737 and RFC 6761 recommendations.
Done Include "I.D.-draft-schoen-intarea-ietf-maintaining-ipv4" in the document, I.D.-draft-schoen-intarea-ietf-maintaining-ipv4.
Thank you again for taking time to review the paper and to add these accurate notes to enhance it.--Michel Bakni (discuss • contribs) 19:09, 9 October 2022 (UTC)
Peer review 2
Review by Igor Dias da Silva , Inria
These assessment comments were submitted on , and refer to this previous version of the article
Recommendation: accept
Discussion
The paper is well written and well structured. I did not find any mistakes and the work covers all the major points of IPV4. I only have two minor suggestions:
1. In section 5.2 the authors briefly mention the IPV4 functionalities. It should be mentioned that these functionalities will be better detailed in section 7 otherwise the readers will be caught off guard by the lack of information in this subsection.
2. The authors should mention the problem of having mobility in the network that mainly arises from how the internet was structured considering fixed hosts. I understand that the solutions for this problem are not in the scope of this work. However, part of the problem of handling mobility comes from IP addressing. Mentioning it in section 8 would be interesting.
Thank you lot for taking the time to review our paper, I will consider the two points you have raised:
Done Create a clear link between the functionalities section and section 5.2.
Done Include mobile IP in the paper.
--Michel Bakni (discuss • contribs) 19:12, 9 October 2022 (UTC)
Timeline
Dear @Natematic:,
I need, at least, until mid-November to integrate the updates in a proper way.. This time is needed so I can do my research.
I will keep you updated.--Michel Bakni (discuss • contribs) 19:16, 9 October 2022 (UTC)
- Dear @Natematic:, all notes were included, we finished revising the article.--Michel Bakni (discuss • contribs) 18:44, 12 November 2022 (UTC)