1. 2001/8/3Nobuo_Okabe@yokogawa.co.jp1 IPv6 Minimum Host Requirement for Small Devices Yokogawa Electric Corp. Nobuo Okabe Nobuo_Okabe@yokogawa.co.jp Nobuo_Okabe@yokogawa.co.jp or nov@i-node.co.jpnov@i-node.co.jp

2. 2001/8/3Nobuo_Okabe@yokogawa.co.jp2 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

3. 2001/8/3Nobuo_Okabe@yokogawa.co.jp3 Limitations: ・ Usage ・ CPU Performance ・ Memory Size ・ etc… IPv6 Min. Host Requirement IPv6 Core IPv6 Key Mgmt. IPv6 Security IPv6 Core ND Addr.Autoconf. IPSEC framework Addr. Arch. ICMPv6 DHCPv6 Mobile IPv6 Routing Protocol DNS Current IPv6 Specifications IPv6 Security ESP AHHMAC-MD5 Pre-shared keyIKE HMAC-SHA1 DES-CBCRinjeal-CBCnull IPv6 Key Mgmt RSA-authDiffie-Hellman Main modeAggressive mode Certificate Motivation (2/2) Current IPv6 Specs. can’t be implemented on a very small device.

4. 2001/8/3Nobuo_Okabe@yokogawa.co.jp4 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

5. 2001/8/3Nobuo_Okabe@yokogawa.co.jp5 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/)http://www.access.co.jp/ InternetNode Inc., (http://www.i-node.co.jp/)http://www.i-node.co.jp/

6. 2001/8/3Nobuo_Okabe@yokogawa.co.jp6 Toshiba Others ＷＩＤＥ Project ＴＡＨＩ Project Spec- ＷＧ TestSuit- ＷＧ ・ ・ Feedbacks Open to the public (Matushita) ACCESS The University of Tokyo Yokogawa Framework

7. 2001/8/3Nobuo_Okabe@yokogawa.co.jp7 Resources of Small Devices

8. 2001/8/3Nobuo_Okabe@yokogawa.co.jp8 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

9. 2001/8/3Nobuo_Okabe@yokogawa.co.jp9 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.

10. 2001/8/3Nobuo_Okabe@yokogawa.co.jp10 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)

11. 2001/8/3Nobuo_Okabe@yokogawa.co.jp11 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)

12. 2001/8/3Nobuo_Okabe@yokogawa.co.jp12 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)

13. 2001/8/3Nobuo_Okabe@yokogawa.co.jp13 Our Scope of Discussion (2/2) RFC 2472 (PPP) draft-ietf-ipngwg-icmp-name-lookups- 05IPv6 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)

14. 2001/8/3Nobuo_Okabe@yokogawa.co.jp14 Snapshot of Our Discussion RFC2460 (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.

15. 2001/8/3Nobuo_Okabe@yokogawa.co.jp15 Snapshot of Our Discussion RFC2460 (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

16. 2001/8/3Nobuo_Okabe@yokogawa.co.jp16 Snapshot of Our Discussion RFC2460 (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?

17. 2001/8/3Nobuo_Okabe@yokogawa.co.jp17 Snapshot of Our Discussion RFC2460 (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.)

18. 2001/8/3Nobuo_Okabe@yokogawa.co.jp18 Snapshot of Our Discussion RFC2461 – 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.

19. 2001/8/3Nobuo_Okabe@yokogawa.co.jp19 Snapshot of Our Discussion DNS AAAA is mandatory. Keep watching IPNG discussion A6: Makes resolver too complicated for the small devices. DNS Server Discovery: Must be necessary

20. 2001/8/3Nobuo_Okabe@yokogawa.co.jp20 Snapshot of Our Discussion IPsec (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

21. 2001/8/3Nobuo_Okabe@yokogawa.co.jp21 Snapshot of Our Discussion IPsec (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

22. 2001/8/3Nobuo_Okabe@yokogawa.co.jp22 Snapshot of Our Discussion IPsec (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.

23. 2001/8/3Nobuo_Okabe@yokogawa.co.jp23 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.

24. 2001/8/3Nobuo_Okabe@yokogawa.co.jp24 Related works Minimum IPv6 Functionality for a Cellular Host 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?

25. 2001/8/3Nobuo_Okabe@yokogawa.co.jp25 Future works Discussing more about our idea: Security Node profile etc... Designing/implementing test suite.