RIPE opposes China and Huawei's "New IP" internet upgrade plan

Réseaux IP Européens French for "European IP Networks" or in short RIPE is a forum with an interest in the technical development of the Internet. RIPE is opposing a proposal to remodel core internet protocols, a proposal backed by the Chinese government, Chinese telecoms, and Chinese networking equipment vendor Huawei.

From the report: "Named "New IP," this proposal consists of a revamped version of the TCP/IP standards to accommodate new technologies, a "shutoff protocol" to cut off misbehaving parts of the internet, and a new "top-to-bottom" governance model that decentralizes the internet and puts it into the hands of a few crucial node operators. The New IP proposal was submitted last year to the International Telecommunication Union (ITU) and brought to the public's attention following a Financial Times report last month. The proposal received immediate criticism from the general public and privacy advocates due to its obvious attempt to hide internet censorship features behind a technical redesign of the TCP/IP protocol stack.

The New IP proposal was described as the Chinese government's attempt to export and impose its autocratic views onto the rest of the internet and its infrastructure. Millions of eyebrows were raised when authoritarian countries like Iran, Russia, and Saudi Arabia expressed support for the proposal. In a blog post this week, RIPE NCC, the regional Internet registry for Europe, West Asia, and the former USSR, formally expressed a public opinion against China New IP proposal. "Do we need New IP? I don't think we do," said Marco Hogewoning, the current acting Manager Public Policy, and Internet Governance at the RIPE NCC. "Although certain technical challenges exist with the current Internet model, I do not believe that we need a whole new architecture to address them."

+++++++++++++++++++++++++++
Advertise on this Space/Blog!
For more information contact us at
ads@digitalelectronics.co.in
+++++++++++++++++++++++++++

Developing Silicon IP with Open Source Tools

The electronic design automation (EDA) tool industry is big business, and commercial licenses are extremely expensive. Open standards have driven many proprietary EDA technologies to be publicly released as free/libre open source software (F/LOSS) and some have become IEEE standards. In this article, author Arthur Low reviews the history of key advances in ICs and EDA tools. The common theme presented in this article for the driver of technology innovation is the requirement to develop the most advanced microprocessor possible. Today, a low-cost, high-value-added business model can efficiently serve the market for IC subsystems licensed as intellectual property (silicon IP) in the form of compilable source code. Alternatively, for larger SoC designs, engineering budgets can be shifted from the purchase of a relatively small number of high-cost EDA tool licenses to open source EDA technologies that can be run on massive compute-server farms. The two business models are not theoretical, but realistic. The author explains how his company (Crack Semiconductor) developed commercially successful cryptographic silicon IP using entirely open source EDA technologies and how another company (SiCortex) pushed the limits of IC design and open source EDA tools by simulating and verifying a massively parallel supercomputer.

SuperSpeed Your SoCs with USB 3.0 IP

Since the introduction of the original USB standard in 1996, the USB interface has become one of the most successful connectivity standards. In today's highly connected world, USB connections are found in the computing, consumer, mobile, industrial and automotive segments. With the trend of increasing data storage requirements driven by applications, such as high-definition video, combined with the desire to move this data quickly between host, storage, and portable devices, it was only a matter of time before there was a need to make this well-known standard even faster. This heralds the third-generation of this ubiquitous standard—the arrival of SuperSpeed USB 3.0. This white paper provides a comparison between USB 3.0 and USB 2.0, highlighting the new capabilities and advancements that have been made with this next-generation technology.

Application Specific IP

One of the major barriers for Semiconductor IP commercialization is to provide evidence for an IP's quality. A common approach by IP vendors is to prove the quality of their IP in a test chip. Usually the Die contains the IP block separated from the System-on-a-Chip (SoC). It is, though, uncertain how the block will function in ASSP and ASIC products, potentially damaging its perceived commercial value. In Rosetta's methodology, the IP Core is a block within a subsystem, integrated to enable the subsystem functionality and targeted for a specific market and application. By analyzing the specific requirements of the market and application, and by providing an IP package targeted at those requirements, we solve and mitigate the IP quality

IP Fragmentation Q&A

1. What is meant by IP fragmentation?
   
The breaking up of a single IP datagram into two or more IP datagrams of smaller size is called IP fragmentation.
2. Why is an IP datagram fragmented?
   
Every transmission medium has a limit on the maximum size of a frame (MTU) it can transmit. As IP datagrams are encapsulated in frames, the size of IP datagram is also restricted. If the size of An IP datagram is greater than this limit, then it must be fragmented.
3. Which RFCs discuss IP fragmentation?
   
RFC 791 & RFC 815 discusses about IP datagrams, fragmentation and reassembly.
4. Is it possible to select an IP datagram size to always avoid fragmentation?
   
It is not possible to select a particular IP datagram size to always avoid fragmentation, as the MTU for different transmission It is possible, though, for a given path to choose a size that will not lead to fragmentation. This is called Path MTU Discovery and is discussed in the RFC 1191. The TCP transport protocol tries to avoid fragmentation using the Maximum Segment Size (MSS) option.
5. Where an IP datagram may get fragmented?
   
An IP datagram may get fragmented either at the sending host or at one of the intermediate routers.
6. Where are the IP datagram fragments reassembled?
   
The IP fragments are reassembled only at the destination host.
7. How to prevent an IP datagram from being fragmented?
   
A IP datagram can be prevented from fragmentation, by setting the "don't fragment" flag in the IP header.
8. What happens when a datagram must be fragmented to traverse a network, but the "don't fragment" flag in the datagram is set?
   
The datagram whose "don't fragment" flag is set is discarded, if it must be fragmented to traverse a network. Also, a ICMP error message is sent back to the sender of the datagram.
9. Will all the fragments of a datagram reach the destination using the same path?
   
The different fragments of the same IP datagram can travel in either in the same path or in different paths to the destination.
10. Will all the fragments of a datagram arrive at the destination system in the correct order?
    
The different fragments of a single IP datagram can arrive in any order to the destination system.
11. What happens to the original IP datagram when one or more fragments are lost?
    
When one or more fragments of an IP datagram are lost, then the entire IP datagram is discarded after a timeout period.
12. What is the minimum size of an IP fragment?
    
The minimum size of an IP fragment is the minimum size of an IP header plus eight data bytes. Most firewall-type devices will drop an initial IP fragment (offset 0) that does not contain enough data to hold the transport headers. In other words, the IP fragment normally need 20 octets of data in addition to the IP header in order to get through a firewall if offset is 0.
13. What are the limitations on the size of a fragment?
    
The size of an IP datagram fragment is limited by
1. The amount of remaining data in the original IP datagram
2. The MTU of the network and
3. Must be a multiple of 8, except for the final fragment.
14. How is an IP datagram fragment differentiated from a non-fragmented IP datagram?
    
A complete IP datagram is differentiated from an IP fragment using the offset field and the "more fragments" flags. For a non-fragmented IP datagram, the fragment offset will be zero and the "more fragments" flag will be set to zero.
15. How are the fragments of a single IP datagram identified?
    
The "identification" field in the IP header is used to identify the fragments of a single IP datagram. The value of this field is set by the originating system. It is unique for that source-destination pair and protocol for the duration in which the datagram will be active.
16. How is the last fragment of an IP datagram identified?
    
The last fragment of an IP datagram is identified using the "more fragments" flag. The "more fragment" flag is set to zero for the last fragment.
17. How is the length of a complete IP datagram calculated from the received IP fragments?
    
Using the fragment offset field and the length of the last fragment, the length of a complete IP datagram is calculated.
18. How is an IP datagram fragmented?
    
In the following example, an IP datagram is fragmented into two. This same algorithm can be used to fragment the datagram into 'n' fragments.
1. The IP layer creates two new IP datagrams, whose length satisfies the requirements of the network in which the original datagram is going to be sent.
2. The IP header from the original IP datagram is copied to the two new datagrams.
3. The data in the original IP datagram is divided into two on an 8 byte boundary. The number of 8 byte blocks in the first portion is called Number of Fragment Blocks (NFB).
4. The first portion of the data is placed in the first new IP datagram.
5. The length field in the first new IP datagram is set to the length of the first datagram.
6. The fragment offset field in the first IP datagram is set to the value of that field in the original datagram.
7. The "more fragments" field in the first IP datagram is set to one.
8. The second portion of the data is placed in the second new IP datagram.
9. The length field in the second new IP datagram is set to the length of the second datagram.
10. The "more fragments" field in the second IP datagram is set to the same value as the original IP datagram.
11. The fragment offset field in the second IP datagram is set to the value of that field in the original datagram plus NFB.
19. How a destination system reassembles the fragments of an IP datagram?
    
1. When a host receives an IP fragment, it stores the fragment in a reassembly buffer based on its fragment offset field.
2. Once all the fragments of the original IP datagram are received, the datagram is processed.
3. Upon receiving the first fragment, a reassembly timer is started.
4. If the reassembly timer expires before all the fragments are received, the datagram is discarded.
20. What fields are changed in an IP header due to fragmentation?
    
The following IP header fields are changed due to IP fragmentation:
1. Total Length
2. Header Length
3. More Fragments Flag
4. Fragment Offset
5. Header Checksum
6. Options
21. What happens to the IP options field when an IP datagram is fragmented?
    
Depending on the option, either it is copied to all the fragments or to only the first fragment.
22. Which IP options are copied to all the fragments of an IP datagram?
    
If the most significant bit in the option type is set (i.e. value one), then that option is copied to all the fragments. If it is not set (i.e. value zero), it is copied only to the first fragment.

IP Addressing Q&A

IP Q&A

1. What is IP?
   
Internet Protocol (IP) is an unreliable, best effort delivery, connection-less protocol used for transmitting and receiving data between hosts in a TCP/IP network.
2. To which OSI layer does IP belong?
   
IP belongs to the Network Layer (layer 3) in the OSI model.
3. Which RFC discusses IP?
   
RFC 791 discusses about the IP protocol version 4.
4. Which version of IP is discussed in this document?
   
IP version 4 (IPv4) is discussed in this document.
5. What do you mean by IP is an unreliable protocol?
   
IP is a unreliable protocol because it does not guarantee the delivery of a datagram to its destination. The reliability must be provided by the upper layer protocols like TCP. IP does not support flow control, retransmission, acknowledgement and error recovery.
6. What do you mean by IP is a best-effort protocol?
   
IP is a best-effort protocol, because it will make every effort to always transmit a datagram and also datagrams will not be just discarded. However, the delivery of the datagram to the destination is not guaranteed.
7. What do you mean by IP is a connection-less protocol?
   
IP is a connection-less protocol because it does not maintain state information about the connection to a destination host. Each datagram is handled independent of other datagrams and also each datagram may reach the destination through different network routes.
8. What is the role of IP in the TCP/IP protocol suite?
   
IP is used for
1. Transmitting data from higher-level protocols like TCP, UDP in IP datagrams, from one host to another host in the network.
2. Identifying individual hosts in a network using an IP address.
3. Routing datagrams through gateways and
4. Fragmenting and reassembling datagrams based on the MTU of the underlying network.
9. What is an IP Datagram?
   
An IP datagram is a basic unit of information used by the IP layer to exchange data between two hosts. A IP datagram consists of an IP header and data.
10. How higher-level data is carried by IP to a destination host?
    
The data from higher-level protocols like TCP, UDP is encapsulated in an IP datagram and transmitted to the destination host. IP will not modify the higher-level data.
11. What is the minimum and maximum size of an IP datagram?
    
The minimum size of an IP datagram is 576 bytes and the maximum size is 65535 bytes.
12. What is the minimum and maximum size of an IP datagram header?
    
The minimum size of an IP datagram header is 20 bytes. The maximum IP datagram header size is 60 bytes.
13. Is there a limitation on the minimum size of a IP datagram a network can handle?
    
Yes. All IP networks must be able to handle datagrams of at least 576 bytes in length.
14. What are the fields in an IP datagram header?
    
The various fields in an IP datagram header and their size in bits are shown below:

    +-------------+
    Version      4 bits
   +-------------+
    IP Header    4 bits
    Length     
   +-------------+
    Type of      8 bits
    Service    
   +-------------+
    Size of the  16 bits
    Datagram   
   +-------------+
    Datagram ID  16 bits
   +-------------+
    Control      3 bits
    Flags      
   +-------------+
    Fragment     13 bits
    Offset     
   +-------------+
    Time to      8 bits
    Live       
   +-------------+
    Protocol     8 bits
   +-------------+
    Header       16 bits
    Checksum   
   +-------------+
    Source IP    32 bits
    Address    
   +-------------+
    Destination  32 bits
    IP Address 
   +-------------+
    Options      Variable Length
   +-------------+

The various fields are explained below:

    +-----------+-----------------------------------------------------+
    Version    IP protocol version.  For IPv4, this value is 4.   
   +-----------+-----------------------------------------------------+
    IP Header  Length of the IP header in multiples of            
    Length     32-bit words.                                      
   +-----------+-----------------------------------------------------+
    Type of    Quality of Service(QOS) requested for this datagram.
    Service                                                       
    (TOS)                                                         
   +-----------+-----------------------------------------------------+
    Datagram   Length of the entire datagram in bytes, including  
    Size       the header and the payload.                        
   +-----------+-----------------------------------------------------+
    Datagram   Current datagram identifier.                       
    ID                                                            
   +-----------+-----------------------------------------------------+
    Control    Bit 0: Reserved                                    
    Flags      Bit 1: 0 - Allow fragment, 1 - Don't fragment.     
               Bit 2: 0 - Last fragment, 1 - More fragments.      
   +-----------+-----------------------------------------------------+
    Fragment   Specifies the offset in the original IP datagram,  
    Offset     where this fragment begins.  This is a multiple of 
               32 bit words.                                      
   +-----------+-----------------------------------------------------+
    Time to    The time upto which this datagram can live in the  
    Live       network.                                           
    (TTL)                                                         
   +-----------+-----------------------------------------------------+
    Protocol   Indicates to which upper-layer protocol layer this 
               datagram should be delivered. e.g. TCP, UDP        
   +-----------+-----------------------------------------------------+
    Header     IP header checksum.                                
    Checksum                                                      
   +-----------+-----------------------------------------------------+
    Source IP  IP address of the source host sending this IP      
    Address    datagram.                                          
   +-----------+-----------------------------------------------------+
    Target IP  IP address of the destination host to which this   
    Address    IP datagram must be delivered.                     
   +-----------+-----------------------------------------------------+
    Options    Used for timestamps, security, source routing, etc.
   +-----------+-----------------------------------------------------+

15. What is the byte order used for transmitting datagram headers in the TCP/IP protocol suite?
    
All the datagram headers in the TCP/IP protocol suite are transmitted in the "big endian" byte order. i.e. The most significant byte is transmitted first. This is also called as "network byte order".
16. Why there are two length fields (IP header length, IP datagram length) in the IP header?
    
The size of the IP header is not fixed. Depending on the IP options present, the size of the IP header will vary. A separate field for the IP header length is added, so that the destination system can separate the IP datagram header from the payload.
17. How is the value for datagram identifier calculated?
    
The IP datagram identifier is just a sequence number assigned by the transmitting host. The algorithm for assigning value to this field is not specified by the IP protocol.
18. What is the use of datagram identifier field?
    
The IP datagram identifier field is used to uniquely identify and assemble the different fragments of an IP datagram.
19. Is the datagram identifier field unique for each IP datagram?
    
Yes. The IP datagram identifier field is different for each IP datagram transmitted. The fragments of an IP datagram will have the same identifier value.
20. What is the use of Type Of Service field in the IP header?
    
The Type Of Service (TOS) field is used TCP to describe the desired quality of service for an IP datagram by upper layer protocols like TCP. This field can be used to specify the nature and priority of a IP datagram (like Network Control, Immediate, Critical, etc) and the criteria for selecting a path for forwarding a datagram by a gateway.
21. What are the different types of criteria can be specified using the TOS field?
    
The different types of criteria that can be specified by the TOS field in an IP datagram are:
1. Minimize delay,
2. Maximize throughput
3. Maximize reliability
4. Minimize cost and
5. Normal service.
22. Which RFC discusses the Type Of Service (TOS) field?
    
RFC 1349 discusses the Type Of Service (TOS) field.
23. What is the use of the Time To Live (TTL) field in the IP header?
    
The TTL field is used to limit the lifetime of a IP datagram and to prevent indefinite looping of IP datagrams.
24. How is the TTL field used to prevent indefinite looping of IP datagrams?
    
The TTL field contains a counter value set by the source host. Each gateway that processes this datagram, decreases the TTL value by one. When the TTL value reaches zero, the datagram is discarded.
25. What is the typical value for the TTL field?
    
The typical value for a TTL field is 32 or 64.
26. When is a datagram considered undeliverable?
    
If a datagram cannot be delivered to the destination host due to some reason, it is considered an undeliverable datagram.
27. How a datagram becomes an undeliverable datagram?
    
A datagram may become undeliverable, if
1. The destination host is down.
2. The route for the destination host is not found.
3. A network in the route to the destination host is down.
4. The Time To Live (TTL) value of the datagram becomes zero.
28. What happens to an undeliverable datagram?
    
An undeliverable datagram is discarded and an ICMP error message is sent to the source host.
29. Is it possible for an IP datagram to be duplicated?
    
Yes. A host may receive the same copy of an IP datagram twice. It is upto the higher layer protocols to discard the duplicate copy of the datagram.
30. Which part of the IP datagram is used for calculating the checksum?
    
The checksum field in the IP header covers only the IP header. The payload data is not used for calculating this checksum.