0

I am studying the possibilities of using IPv6 potentialities to design a customized IPv6 data packet that has the following features:

1. Combines many fragments of different data in one packet.

For example, we have Data 1 (video), Data 2 (image), Data 3 (audio); F11 is the 1st fragment of Data 1, F21 (1st fragment of Data 2), F31 (1st fragment of Data 3), these fragments will be kept in Packet P1 (the 1st data packet). P1 should be as follow:

| IPv6 header | TCP header |   TCP payload   |
                           +                 +
                           +                 +
                           | F11 | F21 | F31 |

2. Specifies all destinations' information (IP addresses, Ports, etc) of each fragment in packets (P1, P2, ..., Pn) so each data fragment is routed to its destination.

Data 1 (F11) --to--> Dest 1   --
Data 2 (F21) --to--> Dest 2    |--> The destinations may not be in the same network
Data 3 (F31) --to--> Dest 3   --

Update: an illustrative image added to explain more. Here, we consider that the type of all Data is video (for the sake of simplicity)

Explanation_image


I am thinking about IPv6 Jumbogram (RFC 2675) where 65,535 Bytes < the size of packet < 4 Gb , but the main challenges facing me currently, are:

  • Is it possible to add more fields for destination addresses in the header ?
  • Is it possible to put different data fragments F11, F21, F31 together in the TCP payload (of the Jumbogram), and more importantly, how can routers access/forward these fragments in the network ? ... Hop-By-Hop options header is used when there is a Jumbogram payload.

Since IPv6 basic header is fixed (40 Bytes), the IPv6 Extension headers seems to me relevant to do this customization, however, I need more orientations and advises for its feasibility.

Thank you

10
  • 1
    IPv6 extension headers are only processed by the destination, except the Hop-by-Hop, which is actually free to be ignored by routers, and will be ignored by routers on the public Internet (really only useful in your own network). "The IPv6 Hop-by-Hop Options header SHOULD be processed by intermediate forwarding nodes as described in [RFC2460]. However, it is to be expected that high-performance routers will either ignore it or assign packets containing it to a slow processing path. Designers planning to use a hop-by-hop option need to be aware of this likely behaviour."
    – Ron Maupin
    Jan 11 at 1:13
  • 1
    for the record, it is a very bad idea to (a) mix different types of multimedia payload in one packet and (b) if you are doing interactive multimedia, send such data with TCP. There is a transport protocol for multimedia payloads, called RTP, which addresses specific issues of multimedia, including especially sending separate audio and video streams and reconstructing them at the receiver (called inter-stream synchronization). There is no point of reinventing the wheal. Also, RTP specification has a concept of RTP mixers, which are application layer relays placed in the network.
    – Effie
    Jan 12 at 5:55
  • 2
    I do not know the exact details, but RTP mixers might be able to do what you are trying to achieve. Also, if you send one huge packet with parts of the packet addressed to different receivers, it will have to be sent to each receiver, which actually increases overhead to the network, not reduces it. There is usually very little point of doing this, unless like 99% of the packet content is relevant to all people. Final point - if you still want to send the same packet to several receivers this can only be done with multicast.
    – Effie
    Jan 12 at 5:58
  • 2
    Why investigate because IP does not do that, and changing it to do that will not be IP.
    – Ron Maupin
    Jan 13 at 21:30
  • 1
    ok, I don't know any standardized extension header that does this. this might(!) be possible with custom extension headers and custom routers that process these headers. but if you have to have custom devices, you can as well have an application layer gateway device (middlebox) that splits packets. And if you have to put devices in the network, then you should probably look at CDNs for video delivery, which might solve your problem (although in another way). I think RTP mixers actually do this, but they are for realtime multimedia, not TCP.
    – Effie
    Jan 16 at 6:56

2 Answers 2

3

What you are describing sounds like a tunnel with interleaved traffic. You're free to design whatever layer-4 or layer-5 protocol you want, but it's going to be between two, and only two, layer-3 addresses. (using multicast makes no sense here.) The payload within the tunnel can be whatever you can dream up.

The outer layer-3 protocol (IPv6) is rather rigidly defined, so hacking on multiple destinations is not going to happen; there's one source, and one destination, and short of rewriting every network stack, that's always how it's going to work.

Ask yourself how would you even make such an extension header? Data (in the payload) is always after ALL headers. If you take multiple packets and send their headers then all their payloads, what is that supposed to solve? (delay traffic significantly, and greatly increase processing overhead)

(Hint: this is why we have the IPv6 we have... IPv4 can't be easily "hacked" to have a larger address space through options/extensions.)

5
  • (01) You said: You're free to design whatever layer-4 or layer-5 protocol you want, but it's going to be between two, and only two, layer-3 addresses. (using multicast makes no sense here.) why multicast doesn't help here ? couldn't we follow the principles used in IGMP (Internet Group Management Protocol), PIM (Protocol-Independent Multicast), or others ?
    – Lee
    Jan 11 at 19:06
  • (02) When you talked about the word "tunnel", you remind me other keywords such as GRE (Generic Routing Encapsulation), MPLS (Multiprotocol Label Switching), SDN (Software-Defined Networking); can these standards be more useful to create/route this type of packet with multiple data fragments for multiple destinations ? (03) What you could suggest as alternatives for IPv6 that can help.
    – Lee
    Jan 11 at 19:06
  • 1
    Ask yourself why you'd want a packet with nothing of interest to you to have to be processed by you? (multicast is one-to-many, so it's not supposed to be fine grained) If it's my traffic, you send it directly to me, and only me. That's how IP works. Even the existing tunneling protocols don't blend traffic - one packet in equals one packet out.
    – Ricky
    Jan 11 at 19:33
  • Thank you @Ricky, I added an image above to explain exactly what I want. Please, I want also to know if this scenario (described through the image) is theoretically feasible in the Computer Networking domain.
    – Lee
    Jan 13 at 21:18
  • 1
    Once again: NO What you are describing is NOT IP or TCP. A "user" is identified by their IP address, not by some upstream device that can deinterleave the traffic. You also appear to think jumbo frames are something common on the internet. It isn't.
    – Ricky
    Jan 14 at 5:56
2

An IPv6 packet, fragmented or not, cannot go to multiple destination addresses nor can it carry more than one next-layer protocol payload (usually from transport layer). What you try to describe isn't IPv6.

What you describe may be possible on the application layer but protocols above the transport layer are explicitly off topic here.

Is it possible to add more fields for destination addresses in the header ?

No, that isn't possible. Simply send multiple packets.

Is it possible to put different data fragments F11, F21, F31 together in the TCP payload (of the Jumbogram)

No.

how can routers access/forward these fragments in the network ?

Packets (fragmented or whole) are forwarded by their destination IP address. End of story.

Hop-By-Hop options header is used when there is a Jumbogram payload.

Jumbograms are just huge packets. They can't do what other packets can't.

1
  • Thank you @Zac67, I added an image above to explain exactly what I want, may be you will have other suggestions / remarks to add.
    – Lee
    Jan 13 at 21:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.