2019-11-21 10:45:04 +01:00
|
|
|
title: Vendor information for IPv6 compatibility: [draft]
|
|
|
|
|
---
|
|
|
|
|
pub_date: 2019-11-21
|
|
|
|
|
---
|
|
|
|
|
author: ungleich
|
|
|
|
|
---
|
|
|
|
|
twitter_handle: ungleich
|
|
|
|
|
---
|
|
|
|
|
_hidden: no
|
|
|
|
|
---
|
|
|
|
|
_discoverable: yes
|
|
|
|
|
---
|
|
|
|
|
abstract:
|
|
|
|
|
How to make your hardware IPv6 compatible
|
|
|
|
|
---
|
|
|
|
|
body:
|
|
|
|
|
|
|
|
|
|
Here at [ungleich](https://ungleich.ch) we see many different devices
|
|
|
|
|
and software running or not running in IPv6 only networks. This
|
|
|
|
|
article summarises some features we see required in IPv6 compatible
|
|
|
|
|
devices (including software).
|
|
|
|
|
|
|
|
|
|
Devices that don't fully complain with the checklist below will be
|
|
|
|
|
removed in the near future from our infrastructure, as their
|
|
|
|
|
maintenance cost has become too high.
|
|
|
|
|
|
|
|
|
|
The wording is orientated on
|
|
|
|
|
[RFC2119](https://tools.ietf.org/html/rfc2119).
|
|
|
|
|
|
2019-11-21 10:49:21 +01:00
|
|
|
**This document is an early draft - version 0.1**.
|
|
|
|
|
If you have any comments / improvements,
|
|
|
|
|
!please help us to improve it on the [IPv6 Chat](https://IPv6.chat).
|
2019-11-21 10:45:04 +01:00
|
|
|
|
|
|
|
|
## IPv6 autoconfiguration
|
|
|
|
|
|
|
|
|
|
All devices must assign themselves an IPv6 address upon receival of a
|
|
|
|
|
router advertisement (compare
|
2019-11-21 10:48:39 +01:00
|
|
|
[RFC4861](https://tools.ietf.org/html/rfc4861)).
|
2019-11-21 10:45:04 +01:00
|
|
|
|
|
|
|
|
## IPv6 listener
|
|
|
|
|
|
|
|
|
|
If the device is providing any service, all services **must** bind to
|
2019-11-21 10:48:39 +01:00
|
|
|
IPv6 sockets (compare
|
|
|
|
|
[RFC3493](https://tools.ietf.org/html/rfc3493)). Device **may** also
|
|
|
|
|
bind to IPv4 sockets.
|
2019-11-21 10:45:04 +01:00
|
|
|
|
|
|
|
|
## Outgoing connections
|
|
|
|
|
|
|
|
|
|
All devices **must** support requesting **all** resources via IPv6
|
|
|
|
|
only connections. This does not imply that the vendor resource has to
|
|
|
|
|
be reachable by IPv6, as the network operator might provide a NAT64
|
2019-11-21 10:48:39 +01:00
|
|
|
service. Devices **may** also try connecting by IPv4.
|
2019-11-21 10:45:04 +01:00
|
|
|
|
|
|
|
|
## Support for IPv6 DNS servers via router advertisements
|
|
|
|
|
|
|
|
|
|
All devices **must** read the DNS server and and DNS search path from the
|
|
|
|
|
router advertisements and **must** configure the DNS servers and DNS
|
|
|
|
|
search path accordingly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Full NAT64/DNS64 compatibility
|
|
|
|
|
|
|
|
|
|
All devices **must** be fully compatible to reach the IPv4 Internet
|
|
|
|
|
through the means of NAT64 and DNS64. In particular all outgoing
|
|
|
|
|
connections **must** be possible by IPv6 only, even if resources in
|
|
|
|
|
the IPv4 Internet are requested.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## No hardcoded IPv4 addresses
|
|
|
|
|
|
|
|
|
|
IF your device needs to connect to a service (f.i. for updates,
|
|
|
|
|
reporting, etc.), it **must not** have any hardcoded IPv4 address.
|
|
|
|
|
|
|
|
|
|
## Updates
|
|
|
|
|
|
2019-11-21 10:48:39 +01:00
|
|
|
IF a device is receiving software updates, it **must** be able to receive
|
2019-11-21 10:45:04 +01:00
|
|
|
software updates in IPv6 only networks.
|
