IPv6 Minimum Host Requirement for
Small Devices
Yokogawa Electric Corp.
Nobuo Okabe
Nobuo_Okabe@yokogawa.co.jp
or nov@i-node.co.jp
2001/8/3
Nobuo_Okabe@yokogawa.co.jp
1
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.


2001/8/3
Harmless for other nodes
Reasonable for future of the Internet
Nobuo_Okabe@yokogawa.co.jp
2
Motivation (2/2)
IPv6 Core
ND
Addr .Autoconf.
ICMPv6
Addr. Arch.
Routing Protocol
DNS
IPv6 Security
IPSEC framework
HMAC-MD5
ESP
DES-CBC
IPv6 Key Mgmt
RSA-auth
Main mode
HMAC-SHA1
Rinjeal-CBC
IKE
IPv6
Core
DHCPv6
Mobile IPv6
AH
Current IPv6 Specs. can’t be
implemented on a very small
device.
null
Pre-shared key
Diffie-Hellman
Aggressive mode
Certificate
Limitations:
・Usage
・CPU
Performance
・Memory Size
・etc…
Current
IPv6 SpecificationsNobuo_Okabe@yokogawa.co.jp
2001/8/3
IPv6
Security
IPv6
Key
Mgmt.
IPv6 Min. Host
Requirement
3
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
2001/8/3
Nobuo_Okabe@yokogawa.co.jp
4
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:


2001/8/3
ACCESS Co. Ltd. (http://www.access.co.jp/)
InternetNode Inc., (http://www.i-node.co.jp/)
Nobuo_Okabe@yokogawa.co.jp
5
Framework
Toshiba
ＷＩＤＥ Project
Spec-ＷＧ
(Matushita) ACCESS Yokogawa
・
・
Others
Open to the public
ＴＡＨＩ
Project
Feedbacks
TestSuit-ＷＧ
The University
of Tokyo
Yokogawa
Yokogawa
2001/8/3
Nobuo_Okabe@yokogawa.co.jp
6
Resources of Small Devices
Memory
ＰＣ
２５６ＭＢ
CPU Performance
Ｐｅｎｔｉｕｍ６４ｂｉｔ
（１ＧＨｚ）
ＡＶ
５１２ＫＢ／ＲＯＭ ＲＩＳＣ３２ｂｉｔ
２０～６４ＫＢ／ＲＡＭ （２０ＭＨｚ）
ＰＤＡ
２～８ＭＢ
ＲＩＳＣ３２ｂｉｔ
（５０ＭＨｚ）
Sensor ～512KB ROM
CISC ８～１６ｂｉｔ
～512KB RAM
（４０ＭＨｚ）
Home
５１２ＫＢ／ＲＯＭ CISC ８～１６ｂｉｔ
Appliance １６～３２ＫＢ／ＲＡＭ （４０ＭＨｚ）
2001/8/3
ＯＳ
Windows
Protocol Stack
Protocol
Security
IPv4 & ＩＰｖ６ ＩＰｓｅｃ
Enbeded ＯＳ
N/A
N/A
ＣＥ／Ｖｘｗｏｒｋｓ
ＰａｌｍＯＳ
Homemade OS
or Monitor
Homemade OS
or Monitor
ＩＰｖ４ Only
N/A
N/A
N/A
N/A
N/A
Nobuo_Okabe@yokogawa.co.jp
7
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.

2001/8/3
Neighbor Cache Entries, The Default Router List,
The prefix List
Nobuo_Okabe@yokogawa.co.jp
8
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.

2001/8/3
Nobuo_Okabe@yokogawa.co.jp
9
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)
2001/8/3
Nobuo_Okabe@yokogawa.co.jp
10
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)
2001/8/3
Nobuo_Okabe@yokogawa.co.jp
11
Our Scope of Discussion (1/2)







RFC
RFC
RFC
RFC
RFC
RFC
RFC
2001/8/3
2460
2461
2462
2463
2373
1886
2464
(Basic Spec.)
(Neighbor Discovery)
(Address Autoconfiguration)
(ICMPv6)
(Addressing Architecture)
(DNS Extensions)
(Ethernet)
Nobuo_Okabe@yokogawa.co.jp
12
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)
2001/8/3
Nobuo_Okabe@yokogawa.co.jp
13
Snapshot of Our Discussion
RFC2460 (1/4)

Parsing Ext. Headers



2001/8/3
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
14
Snapshot of Our Discussion
RFC2460 (2/4)

Hop-by-Hop Option Header



Routing Header



Recv side: Pad1, PadN option (at least)
Send side: No need to send HHOH
Recv side: RH w/ segment left==0 (at least)
Send side: RH if a host needs MIP6 binding
update
Destination Header


2001/8/3
Recv side: Pad1, PadN option (at least)
Send side: Home Address option if a host needs
MIP6 binding update
Nobuo_Okabe@yokogawa.co.jp
15
Snapshot of Our Discussion
RFC2460 (3/4)

Fragment Header


Fragmenting/Reassembling are not mandate under
limited memory size.
Recv side:




2001/8/3
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
16
Snapshot of Our Discussion
RFC2460 (4/4)

Fragment Header (Continued)

Send side:



2001/8/3
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
17
Snapshot of Our Discussion
RFC2461 – 2463

RFC2461



RFC2462


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
DAD should be implemented.
RFC2463

2001/8/3
No need for any router related ICMP error
message.
Nobuo_Okabe@yokogawa.co.jp
18
Snapshot of Our Discussion
DNS


AAAA is mandatory.
Keep watching IPNG discussion


2001/8/3
A6:
Makes resolver too complicated for the
small devices.
DNS Server Discovery:
Must be necessary
Nobuo_Okabe@yokogawa.co.jp
19
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

2001/8/3
Multicast, IPsec MIB, IPsec specific ICMP
Nobuo_Okabe@yokogawa.co.jp
20
Snapshot of Our Discussion
IPsec (2/3)

ESP is mandate.



SA parameters (at least)


NULL algorithm is also important
AH is not mandate.
Src/Dst IPv6 addr., SPI, Protocol, ESP(alg, key, IV),
HMAC(alg, key), seq counter, replay protection
Algorithm (Mandate)


2001/8/3
AES(12b bits)
HMAC-SHA2-256
Nobuo_Okabe@yokogawa.co.jp
21
Snapshot of Our Discussion
IPsec (3/3)

Key Management


Manual keying is mandate.
IKE is no fit for the small devices:



2001/8/3
Very complicated
Assuming fixed IP address
Light weight key exchange model is
needed.
Nobuo_Okabe@yokogawa.co.jp
22
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.
2001/8/3
Nobuo_Okabe@yokogawa.co.jp
23
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?
2001/8/3
Nobuo_Okabe@yokogawa.co.jp
24
Future works

Discussing more about our idea:




Security
Node profile
etc...
Designing/implementing test suite.
2001/8/3
Nobuo_Okabe@yokogawa.co.jp
25