1 / 6

Page 1 /6

IPv4 Residual Deployments a Stateless Solution (4rd) draft-ietf-softwire-4rd IETF 85 Softwire WG November 06, 2012 Sheng Jiang (speaker) Rémi Després Reinaldo Penno Yiu Lee Gang Chen Maoke Chen. Page 1 /6 . Changes since IETF 84. Change Intended Status to be Experimental Editorship change

leandra-buchanan
Télécharger la présentation

Page 1 /6

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. IPv4 Residual Deploymentsa Stateless Solution (4rd)draft-ietf-softwire-4rdIETF 85 Softwire WGNovember 06, 2012Sheng Jiang (speaker)Rémi Després Reinaldo Penno Yiu Lee Gang Chen Maoke Chen Page 1/6

  2. Changes since IETF 84 • Change Intended Status to be Experimental • Editorship change • Thanks Rémi Després • Deletion of Rule IPv6 suffixes • Addition of the DHCPv6 container to avoid multiple option requests • A few minor description improvements from implementation • Move R1 into Section 4 “Protocol specification” – all Requirement in section 4 now • Add summary requirement lists that CE and BR should respectively obey for better readability

  3. 4rd logical functions (CE) Code size: 2300 lines, including NAT44 with port restriction Compiled ko file: 20 k

  4. 4rd logical functions (BR) • Code size: 2000 lines, code is reused from CE code • BR = CE – NAT44 – addr calculation from delegated IPv6 prefix • Compiled ko file: 18 k

  5. Implementation Conclusion • 4rd doesn’t change any IP protocol standards, no conflict with any existing RFCs. In our implementation, the fragment header did not bother Linux forwarding at all. 4rd can be incremental deployed among current IP routers. • 4rd packet translation is lightweight • No need to deal with transport-layer checksum. CNP works effectively, the translated packets can pass the TCP/UDP checksum validation • No need to process each protocol (TCP/UDP/ICMP) respectively • No need to deal with ICMPv4/v6 semantic mapping. ICMPv4 can traverse the 4rd domain transparently

  6. Comments are welcomed! Thank You!

More Related