1 / 25

IPv6 Minimum Host Requirement for Small Devices

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:

tory
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. 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. 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-ＷＧ ＷＩＤＥ Project ・ Others ACCESS Yokogawa (Matushita) ・ Open to the public ＴＡＨＩ Project Feedbacks The University of Tokyo Yokogawa TestSuit-ＷＧ 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

More Related