1 / 29

Masataka Ohta Tokyo Institute of Technology mohta@necom830.hpcl.titech.ac.jp

TCP and UDP with Port Length Enhancement (TUPLE) -- A Scribbled Slate Approach for Internet Addressing and Routing --. Masataka Ohta Tokyo Institute of Technology mohta@necom830.hpcl.titech.ac.jp. IPv6 Deployment Failed!. No plausible transition plan exist Dual stack abandoned long ago

walden
Download Presentation

Masataka Ohta Tokyo Institute of Technology mohta@necom830.hpcl.titech.ac.jp

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. TCP and UDP with Port Length Enhancement (TUPLE)-- A Scribbled Slate Approach for Internet Addressing and Routing -- Masataka Ohta Tokyo Institute of Technology mohta@necom830.hpcl.titech.ac.jp

  2. IPv6 Deployment Failed! • No plausible transition plan exist • Dual stack abandoned long ago • NAT between IPv4 and IPv6 inevitable • If NAT is acceptable, why should we deploy IPv6? • Can we pay operation cost for both IPv4 and IPv6 during the transition? • Can we replace IPv4-only boxes such as residential broadband routers?

  3. Why Did We Need IPv6? • IPv6 was a clean slate approach for: • larger address space • despite RFC1715, 8B address is long enough to prevent digital divide • 100 times more space than IPv4 may be enough at least for the time being • better aggregated routes • as RFC2073 abandoned, IPv6 is as bad as IPv4 • the end to end transparency • as dual stack abandoned, NAT is inevitable during transition

  4. Port Restricted IP • PR-IP is a scribbled slate approach for • larger address space • an IP address is shared by multiple hosts and destination port numbers are used for packet routing • 100 or 1000 times more effective address space than IPv4 • better aggregated routes? • no worse than IPv4 unless port number based routing is used at the backbone • the end to end transparency • transport layer addresses are identical to those of IPv4 • fully compatible with the rest of the IPv4 Internet

  5. IP Header & Port Numbersof PR-IP IP Header Source Address Used for routing with PR-IP Destination Address Source Port Destination Port Remaining Transport Header & Payload

  6. How PR-IP Works • PR-IP hosts are assigned a globally unique IP address and port numbers they may use • the port numbers are unique between hosts sharing a same IP address • Packets are delivered from PR-IP GW to PR-IP hosts based on port numbers • variations on actual delivery mechanisms • A+P, E2ENAT, PE-ARP

  7. IPv4 Backbone PR-IP Host PR-IP Host port dependent packet delivery PR-IP GW PR-IP Host PR-IP Host PR-IP (Port Restricted IP)

  8. point to point links IPv4 Backbone PR-IP Host PR-IP Host PR-IP GW PR-IP Host PR-IP Host Delivery is over P2P links chosen by PR-IP GW PR-IP with A+P (Address+Port) P2P link is chosen depending on port numbers

  9. IPv4 Backbone PrivateIPv4Network PR-IP Host PR-IP Host PR-IP GW PR-IP Host PR-IP Host Delivery is by private IP addresses translated by PR-IP GW PR-IP with End to End NAT no port translations nor transport checksum recalculations private address is chosen depending on port numbers translated addresses are translated back by PR-IP hosts

  10. a link segment withenhanced ARP IPv4 Backbone PR-IP Host PR-IP Host PR-IP GW PR-IP Host PR-IP Host Delivery is by MAC address returned by PR-IP host through PE-ARP PR-IP with Port Enhanced ARP ARP request include port numbers reply ARP with port numbers of PR-IP host

  11. How the End to End Transparencyis Preserved with PR-IP • The End to End Argument • The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. • PR-IP host (the end) have knowledge • on its global IP address and port numbers • PR-IP host (the end) helps • by not using source port number not assigned to it • no port conflicts of outgoing packets • no port translation of outgoing packets necessary • port numbers carried by applications do not need translations

  12. IPv4 Backbone PrivateIPv4Network Usual Host Usual Host Legacy NAT GW Usual Host Usual Host Port Number Translationby Legacy NAT source port numbers of outgoing packets may collide translation of source port numbers of outgoing packets required destroying the end to end transparency source port numbers are chosen independently

  13. Layering Structure ofthe End to End NAT Information on NAT Application Relays DHC S DHC C Applications Transport Transport UDP UDP Public IP Public IP Public IP Private IP (transport checksum not verified) Address translation for incoming packets Address translation for incoming packets back to public source addresses NAT GW DHC Server End System : The Global Internet : Private IP Network

  14. ICMP and PR-IP • ICMP error packets contain IP headers and following 8B of original packets causing errors • ICMP error packets should be delivered by PR-IP GW depending on the source port number contained in the 8B • ICMP information request packets can be delivered by identifier field • ICMP information reply packets can be delivered by sequence number field

  15. ICMP Error Packet Format IP Header ICMP Header IP Header of Original IP Packet Causing Error First 8B of Payload of Original IP Packet Causing Error source port number is usually contained in the first 2B but may be located other part of the first 8B

  16. IP Header Type Code Checksum Identifier Sequence Number Data (variable length) Packet Format of ICMPInformation Request & Reply “Identifier” and “Sequence Nnumber” fields can act as source and destination port numbers for PR-IP. The fields are copied from request to reply as is. Request and reply are distinguished by “Type” field.

  17. sequence number of request contains client port number ICMPecho Client request deliveryby identifier IPv4Backbone PR-IPGW PR-IPGW reply delivery bysequence number ICMPecho Server sequence number of request is copied to sequence number of reply Delivery ofICMP Request and Reply

  18. Deployment Strategy of PR-IP • PR-IP is fully compatible with the current IPv4 Internet • Only PR-IP GW and PR-IP hosts needs upgrading, which is purely local • All the applications, including FTP with PORT command, work as is • unless they insist on using a fixed port number • Port numbers for applications may be specified by URL

  19. A Possible Problems of PR-IP • To make PR-IP for • larger address space • effective address space may not be large enough • better aggregated routes • PI addresses for multihoming can not be aggregated • If a multihomed host have PA addresses and its peer can dynamically choose the most appropriate address, PI addresses are not necessary for multihoming

  20. TUPLE(TCP and UDP with Port Length Enhancement )-- A Scribbled Slate Approach for Internet Addressing and Routing -- • TCP and UDP with 6B port numbers • and extended transport option field • length of “Data Offset” field of TCP is extended • unused UDP “Length” field is used as “Data Offset” • the option field may contain alternative source addresses for better aggregation • Named after TUBA (was an IPng candidate) • “TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing” (RFC1347) • Port numbers of other protocols may also be enhanced

  21. SRC port DST port Sequence Number Acknowledgment Number DataOffset Flags & Reserved bits Window Checksum Urgent Pointer Options & Padding (at most 40B long) Header Format of the Current TCP

  22. SRC port H DST port H SRC port M DST port M SRC port L DST port L Sequence Number Acknowledgment Number DataOffset Flags & Reserved Window Checksum Urgent Pointer Options & Padding (at most 972B long) Header Format of TUPLE TCP

  23. SRC port DST port Length Checksum Header Format of the Current UDP Not necessary

  24. SRC port H DST port H SRC port M DST port M SRC port L DST port L DataOffset Reserved Checksum Options & Padding (at most 1004B long) Header Format of TUPLE UDP

  25. IP Header Type Code Checksum Identifier Sequence Number Data (variable length) Packet Format of the Current ICMP ECHO Request & Reply

  26. IP Header Type (8) Code Checksum SRC port H DST port H SRC port M DST port M SRC port L DST port L Remaining Data (variable length) Packet Format of TUPLEICMP ECHO Request

  27. IP Header Type (0) Code Checksum DST port H SRC port H DST port M SRC port M DST port L SRC port L Remaining Data (variable length) Packet Format of TUPLEICMP ECHO Reply

  28. Deployment Strategy of TUPLE • No change is necessary at the IPv4 backbone where packets are routed by IP addresses only • TUPLE requires upgrading of host transport stack at both sides • All the applications also needs upgrading • We have much time if PR-IP is deployed

  29. Conclusions • PR-IP and TUPLE are scribbled slate approach for the Internet with a larger address space • PR-IP to use port numbers for packet delivery is fully compatible to the current IPv4 Internet with end to end transparency and can be deployed immediately • TUPLE to enhance port number from 2B to 6B can be a long term solution • We don’t need IPv6

More Related