ipv6 minimum host requirement for small devices n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
IPv6 Minimum Host Requirement for Small Devices PowerPoint Presentation
Download Presentation
IPv6 Minimum Host Requirement for Small Devices

Loading in 2 Seconds...

play fullscreen
1 / 25

IPv6 Minimum Host Requirement for Small Devices - PowerPoint PPT Presentation


  • 125 Views
  • Uploaded on

IPv6 Minimum Host Requirement for Small Devices. Yokogawa Electric Corp. Nobuo Okabe Nobuo_Okabe@yokogawa.co.jp or nov@i-node.co.jp. Motivation (1/2). (I had to implement IPv6 on the small device.) IPv6 enables small devices to connect the Internet. IPv6 spec. is too large for the device:

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

IPv6 Minimum Host Requirement for Small Devices


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
    Presentation Transcript
    1. IPv6 Minimum Host Requirement for Small Devices Yokogawa Electric Corp. Nobuo Okabe Nobuo_Okabe@yokogawa.co.jpor nov@i-node.co.jp Nobuo_Okabe@yokogawa.co.jp

    2. Motivation (1/2) • (I had to implement IPv6 on the small device.) • IPv6 enables small devices to connect the Internet. • IPv6 spec. is too large for the device: • Specific purposed, CPU performance, memory size, etc... • There is no guideline for shrinking IPv6 spec. • Harmless for other nodes • Reasonable for future of the Internet Nobuo_Okabe@yokogawa.co.jp

    3. Motivation (2/2) Current IPv6 Specs. can’t be implemented on a very small device. IPv6 Core ND ICMPv6 Addr .Autoconf. Addr. Arch. IPv6 Core Routing Protocol DHCPv6 Mobile IPv6 DNS IPv6 Security IPv6 Security IPSECframework Limitations: ・Usage ・CPU Performance ・Memory Size ・etc… AH HMAC-MD5 HMAC-SHA1 ESP DES-CBC Rinjeal-CBC null IPv6 Key Mgmt. IPv6 Key Mgmt IKE Pre-shared key RSA-auth Diffie-Hellman Certificate Main mode Aggressive mode IPv6 Min. Host Requirement Nobuo_Okabe@yokogawa.co.jp Current IPv6 Specifications

    4. Objectives • Sharing our experience with other implementers of small devices • Making IPv6 guidelines for the devices: • IPv6 core, Security, Key management • Developing test suites for public use Nobuo_Okabe@yokogawa.co.jp

    5. History/Status • The project was started with WIDE & TAHI (2000/11) • Commited Organizations/People: • ACCESS: Osajima, Noguchi • Toshiba: Inoue, Ishiyama • Yokogawa: Miyata, Okabe, Sajiki, Sakane • InternetNode: Okabe • Implementers are also committed: • ACCESS Co. Ltd. (http://www.access.co.jp/) • InternetNode Inc., (http://www.i-node.co.jp/) Nobuo_Okabe@yokogawa.co.jp

    6. Framework Toshiba Spec-WG WIDE Project ・ Others ACCESS Yokogawa (Matushita) ・ Open to the public TAHI Project Feedbacks The University of Tokyo Yokogawa TestSuit-WG Yokogawa Nobuo_Okabe@yokogawa.co.jp

    7. Resources of Small Devices Nobuo_Okabe@yokogawa.co.jp

    8. Assumption of the IPv6 Min. Host • A node is NOT a router, but a host. • No need to send a packet w/ ext. header(s) • However, we have to discussing about MIP6. • having a single network i/f • to simplify source address selection. • not to use routing information. • to minimize ND related cache entries. • Neighbor Cache Entries, The Default Router List,The prefix List Nobuo_Okabe@yokogawa.co.jp

    9. Out of Our Discussion (1/3) • IPv6 Address Assignment • Jumbogram • Multicast, anycast • MIB, Header Compression • Any L2 except PPP/Ethernet • Transition Technology (IPv4 <==> IPv6) • to simplify problems to solve. • especially IPsec vs. {NAT or Translator}. We may discuss some part of the above in the future. Nobuo_Okabe@yokogawa.co.jp

    10. Out of Our Discusson (2/3) • RFC1981 (Path MTU Discovery) • RFC2147 RFC2675 (Jumbograms) • RFC2375 (Multicast Address Assignments) • RFC2710 (MLD) • RFC1888 (OSI NSAPs) • RFC2292 (Advanced Sockets API) • RFC2553 (Basic Socket Interface Ext.) • RFC2473, RFC2529 (Tunneling) Nobuo_Okabe@yokogawa.co.jp

    11. Out of Our Discussion (3/3) • RFC2507 (IP Header Compression) • RFC2526 (Anycast) • RFC2452, RFC2454, RFC2465, RFC2466 (SNMP/MIB) • RFC2467 (FDDI) • RFC2470 (Token Ring Networks) • RFC2497 (ARCnet Networks) • RFC2711 (Router Alert Option) Nobuo_Okabe@yokogawa.co.jp

    12. Our Scope of Discussion (1/2) • RFC 2460 (Basic Spec.) • RFC 2461 (Neighbor Discovery) • RFC 2462 (Address Autoconfiguration) • RFC 2463 (ICMPv6) • RFC 2373 (Addressing Architecture) • RFC 1886 (DNS Extensions) • RFC 2464 (Ethernet) Nobuo_Okabe@yokogawa.co.jp

    13. Our Scope of Discussion (2/2) • RFC 2472 (PPP) • draft-ietf-ipngwg-icmp-name-lookups-05 IPv6 Node Information Queries • draft-ietf-ipngwg-scoping-arch-02.txt IPv6 Scoped Address Architecture • RFC 2401, RFC2402, RFC2406 (IPsec) • RFC 2407 (ISAKMP) • RFC 2409 (IKE) Nobuo_Okabe@yokogawa.co.jp

    14. Snapshot of Our DiscussionRFC2460 (1/4) • Parsing Ext. Headers • Sending ICMP Param. Problem if a host encounters unknown header. • Following option type if a host encounters unknown option. • It is not necessary to check ext. headers order if a host does not need ext. header functionality. Nobuo_Okabe@yokogawa.co.jp

    15. Snapshot of Our DiscussionRFC2460 (2/4) • Hop-by-Hop Option Header • Recv side: Pad1, PadN option (at least) • Send side: No need to send HHOH • Routing Header • Recv side: RH w/ segment left==0 (at least) • Send side: RH if a host needs MIP6 binding update • Destination Header • Recv side: Pad1, PadN option (at least) • Send side: Home Address option if a host needs MIP6 binding update Nobuo_Okabe@yokogawa.co.jp

    16. Snapshot of Our DiscussionRFC2460 (3/4) • Fragment Header • Fragmenting/Reassembling are not mandate under limited memory size. • Recv side: • Treat FH as unknown ext. header • Force a peer to send a packet whose size < 1280. • TCP: Never open my MSS more then 1000 (for example) • UDP: ????? Is there any UDP application whose size i>512 ? NFS? Nobuo_Okabe@yokogawa.co.jp

    17. Snapshot of Our DiscussionRFC2460 (4/4) • Fragment Header (Continued) • Send side: • Never send a packet whose size > 1280. • Ignore ICMP Packet Too Big Message. • (No need to have the Destination Cache.) Nobuo_Okabe@yokogawa.co.jp

    18. Snapshot of Our DiscussionRFC2461 – 2463 • RFC2461 • No need for any router functionality:Sending RAs, Receiving RSs • Ignoring Redirect Messages if a host does not have both routing table and the Destination Cache • RFC2462 • DAD should be implemented. • RFC2463 • No need for any router related ICMP error message. Nobuo_Okabe@yokogawa.co.jp

    19. Snapshot of Our DiscussionDNS • AAAA is mandatory. • Keep watching IPNG discussion • A6:Makes resolver too complicated for the small devices. • DNS Server Discovery:Must be necessary Nobuo_Okabe@yokogawa.co.jp

    20. Snapshot of Our DiscussionIPsec (1/3) • A host is neither a router nor a security gateway. • A host can speak with a peer securely • Without security gateway. • Without Specific security infrastructures (i.e. CA) • Without unfixed functionality • Multicast, IPsec MIB, IPsec specific ICMP Nobuo_Okabe@yokogawa.co.jp

    21. Snapshot of Our DiscussionIPsec (2/3) • ESP is mandate. • NULL algorithm is also important • AH is not mandate. • SA parameters (at least) • Src/Dst IPv6 addr., SPI, Protocol, ESP(alg, key, IV), HMAC(alg, key), seq counter, replay protection • Algorithm (Mandate) • AES(12b bits) • HMAC-SHA2-256 Nobuo_Okabe@yokogawa.co.jp

    22. Snapshot of Our DiscussionIPsec (3/3) • Key Management • Manual keying is mandate. • IKE is no fit for the small devices: • Very complicated • Assuming fixed IP address • Light weight key exchange model is needed. Nobuo_Okabe@yokogawa.co.jp

    23. Current Status • Summarizing our discussion on a draft • http://www.tahi.org/tiny/ • You can see this PPT on the same URL. • Feedback is welcome. Nobuo_Okabe@yokogawa.co.jp

    24. Related works • Minimum IPv6 Functionality for a Cellular Host <draft-manyfolks-ipv6-cellular-host-00.txt>Jari Arkko (Ericsson), John Loughney(Nokia), et al. • We are interested in your work. • Is there any possibility to work with us? • Is it good idea to have a meeting at next IETF? Nobuo_Okabe@yokogawa.co.jp

    25. Future works • Discussing more about our idea: • Security • Node profile • etc... • Designing/implementing test suite. Nobuo_Okabe@yokogawa.co.jp