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


  • 112 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

PowerPoint Slideshow about 'IPv6 Minimum Host Requirement for Small Devices' - tory


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
ipv6 minimum host requirement for small devices

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

motivation 1 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

motivation 2 2
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

objectives
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

history status
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

framework
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

resources of small devices
Resources of Small Devices

Nobuo_Okabe@yokogawa.co.jp

assumption of the ipv6 min host
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

out of our discussion 1 3
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

out of our discusson 2 3
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

out of our discussion 3 3
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

our scope of discussion 1 2
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

our scope of discussion 2 2
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

snapshot of our discussion rfc2460 1 4
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

snapshot of our discussion rfc2460 2 4
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

snapshot of our discussion rfc2460 3 4
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

snapshot of our discussion rfc2460 4 4
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

snapshot of our discussion rfc2461 2463
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

snapshot of our discussion dns
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

snapshot of our discussion ipsec 1 3
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

snapshot of our discussion ipsec 2 3
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

snapshot of our discussion ipsec 3 3
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

current status
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

related works
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

future works
Future works
  • Discussing more about our idea:
    • Security
    • Node profile
    • etc...
  • Designing/implementing test suite.

Nobuo_Okabe@yokogawa.co.jp