Low-Power Wireless Personal

Area Networks
 IPv4 versus IPv6
IPv4 IPv6
Developed IETF 1974 IEF 1998
Length (bits) 32 128
No. of Addresses 2^32 2^128
Notation Dotted Decimal Hexadecimal
Dynamic Allocation of DHCP SLAAC/ DHCPv6
addresses
IPSec Optional Compulsory
 IPv4 versus IPv6
IPv4 IPv6
Header Size Variable Fixed
Header Checksum Yes No
Header Options Yes No
Broadcast Addresses Yes No
Multicast Address No Yes
IPv4 Header Format
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
Ver IHL Type of Service Total Length

Identification Flags Fragment Offset

Time to Live Protocol Header Checksum
Source Address (32 bit)
Destination Address (32 bit)
Options Padding
 IPv4
✓ The IPv4 emphasizes more on reliable transmission, as is
evident by fields such as type of service, total length, id,
offset, TTL, checksum fields.
IPv6 Header Format
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
Ver Traffic Class Flow Label
Payload Length Next Header Hop Limit

Source Address (128 bit)

Destination Length (128 bit)

 IPv6
✓ The IPv6 header structure is more simpler as it mainly focuses
on the addressing part of the source and destination.
✓ It is concerned more with addressing than with reliability of
data delivery.
LoWPAN Architecture
The 6LoWPAN Format
The 6LoWPAN Format
• 6LoWPAN is an adaptation header format
• Enables the use of IPv6 over low-power wireless links
• IPv6 header compression
• UDP header compression
• Format initially defined in RFC4944 updated by RFC6282
The 6LoWPAN Format
• 6LoWPAN makes use of IPv6 address compression
• RFC4944 Features:
• Basic LoWPAN header format
• HC1 (IPv6 header) and HC2 (UDP header) compression formats
• Fragmentation & reassembly
• Mesh header feature (depreciation planned)
• Multicast mapping to 16-bit address space

• RFC6282 Features:
• New HC (IPv6 header) and NHC (Next-header) compression
• Support for global address compression (with contexts)
• Support for IPv6 extension header compression
• Support for UDP
• Support for compact multicast address compression
 [RFC2373]
IPv6 Addressing
• 128-bit IPv6 address Interface ID (IID)
64-bit prefix + 64-bit
• The 64-bit prefix is hierarchical
• Identifies the network you are on and where it is globally
• The 64-bit IID identifies the network interface
• Must be unique for that network
• Typically is formed statelessly from the interface MAC address
• Called Stateless Address Autoconfiguration (RFC4862)
• There are different kinds of IPv6 addresses
• Loopback (0::1) and Unspecified (0::0)
• Unicast with global (e.g. 2001::) or link-local (FE80::) scope
• Multicast addresses (starts with FF::)
• Anycast addresses (special-purpose unicast address)
6LoWPAN Addressing
• IPv6 addresses are compressed in 6LoWPAN
• A LoWPAN works on the principle of
• flat address spaces (wireless network is one IPv6 subnet)
• with unique MAC addresses (e.g. 64-bit or 16-bit)
• 6LoWPAN compresses IPv6 addresses by
• Eliding the IPv6 prefix
• Global prefix known by all nodes in network
• Link-local prefix indicated by header compression format
• Compressing the IID
• Elided for link-local communication
• Compressed for multihop dst/src addresses
• Compressing with a well-known “context”
• Multicast addresses are compressed
6LoWPAN Addressing
• Forming addresses out of 16-bit short addresses
• Pseudo 48-bit address is formed in two steps:
(1) 16_bit_PAN:16_zero_bits

(2) 32_bits_as_specified_previously:16_bit_short_address

• The interface identifier is formed from this 48-bit

address
6LoWPAN Addressing
IPv6 Link Local Address

The IPv6 link-local address [RFC4291] for an IEEE 802.15.4 interface

is formed by appending the Interface Identifier, as defined above, to
the prefix FE80::/64.

10 bits 54 bits 64 bits

+----------+-----------------------+----------------------------+
|1111111010|00 (zeros) 00| Interface Identifier |
+----------+-----------------------+----------------------------+
F E 8 0
Addressing Example
 6LoWPAN
Header compression
Header compression
• Large IPv6 datagram needs to be transmitted
• How to compress the header to save resources?
• Integrate Layer 2 and Layer 3 compression
UDP/IPv6 Headers
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
|
| Payload Length | Next Header | Hop Limit |
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ +
+
| |
+ Source Address +
| |
IPv6 + +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 48 Bytes
|

|
+

+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|
+
+ Destinatio Address +
UDP |
+
Source Port
n
| Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| |
+ +
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| |
Payload
+
| UDP Payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
Encoding of IPv6 Header Fields [RFC4944]

• Encode different combinations with “HC1 encoding”

1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HC1 encoding | Non-Compressed fields follow...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LOWPAN_HC1 (common compressed header encoding)

The address fields encoded by "HC1 encoding" are interpreted as

follows: PI: Prefix carried in-line
PC: Prefix compressed (link-local prefix assumed)
II: Interface identifier carried in-line
IC: Interface identifier elided -> derivable from link-layer
address
 [RFC4944]
Encoding of IPv6 Header Fields
• Encode different combinations with “HC1 encoding”
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S A|D A|T|N H|H| Non-Compressed fields follow...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SA Source address (bits 0 and 1)

DA Destination address (bits 2 and 3)
T Traffic class and Flow Label (bit 4)
NH Next header (bits 5 and 6)
H HC2 encoding (bit 7)
LoWPAN Adaptation Layer and
Frame Format
These examples show typical header stacks that may be used in a LoWPAN network.

A LoWPAN encapsulated IPv6 datagram:

+---------------+-------------+---------+
| IPv6 Dispatch | IPv6 Header | Payload |
+---------------+-------------+---------+

A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram:

+--------------+------------+---------+
| HC1 Dispatch | HC1 Header | Payload |
+--------------+------------+---------+

A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires mesh

addressing:
+-----------+-------------+--------------+------------+---------+
| Mesh Type | Mesh Header | HC1 Dispatch | HC1 Header | Payload |
+-----------+-------------+--------------+------------+---------+

A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires

fragmentation:
+-----------+-------------+--------------+------------+---------+
| Frag Type | Frag Header | HC1 Dispatch | HC1 Header | Payload |
+-----------+-------------+--------------+------------+---------+
LoWPAN Adaptation Layer and
Frame Format
A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires both
mesh addressing and fragmentation:

+-------+-------+-------+-------+---------+---------+---------+
| M Typ | M Hdr | F Typ | F Hdr | HC1 Dsp | HC1 Hdr | Payload |
+-------+-------+-------+-------+---------+---------+---------+

A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires both

mesh addressing and a broadcast header to support mesh broadcast/multicast:

+-------+-------+-------+-------+---------+---------+---------+
| M Typ | M Hdr | B Dsp | B Hdr | HC1 Dsp | HC1 Hdr | Payload |
+-------+-------+-------+-------+---------+---------+---------+
Dispatch Type and Header
The dispatch type is defined by a zero bit as the first bit and a one bit as the second bit.
The dispatch type and header are shown here:

1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1| Dispatch | type-specific header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Dispatch 6-bit selector: Identifies the type of header immediately

following the Dispatch Header.

type-specific header: A header determined by the Dispatch Header.

The dispatch value may be treated as an unstructured namespace. Only a few symbols are
required to represent current LoWPAN functionality. Although some additional savings could
be achieved by encoding additional functionality into the dispatch byte, these measures
would tend to constrain the ability to address future alternatives.
Dispatch Value Bit Pattern
Pattern Header Type
+------------+-----------------------------------------------+
| 00 xxxxxx | NALP - Not a LoWPAN frame |
| 01 000001 | IPv6 - Uncompressed IPv6 Addresses |
| 01 000010 | LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6 |
| 01 000011 | reserved - Reserved for future use |
| ... | reserved - Reserved for future use |
| 01 | reserved - Reserved for future use |
| 01 010000
00111 | LOWPAN_BC0 - LOWPAN_BC0 broadcast |
1 01 010001 | reserved
| - Reserved for future use |
| ... | reserved - Reserved for future use |
| 01 | reserved - Reserved for future use |
11111
0
| 01 111111 | ESC - Additional Dispatch byte follows |
| 10 xxxxxx | MESH - Mesh Header |
| 11 000xxx | FRAG1 - Fragmentation Header (first) |
| 11 001000 | reserved - Reserved for future use |
| 11 ... reserved
100xxx | FRAGN Reserved for future
- Fragmentation Header use
(subsequent)||
| 11 101000 || reserved
reserved - Reserved for future use |
| ... 01111 | reserved - Reserved for future use |
1 11 111111 | reserved
| - Reserved for future use |
+------------+-----------------------------------------------+
Header Comparison
LoWPAN dispatch
 [RFC6282]
LoWPAN UDP/IPv6 Headers

LoWPAN IPv6 UDP

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dispatch with LOWPAN_IPHC | LOWPAN_NHC | Src | Dst |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Checksum | UDP Payload ...
6 Bytes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Payload
 [RFC6282]
IP Header Compression (IPHC)
LOWPAN_IPHC Header

+-------------------------------------+----------------------------
| Dispatch + LOWPAN_IPHC (2-3 octets) | In-line IPv6 Header Fields
+-------------------------------------+----------------------------

• In the best case, the LOWPAN_IPHC can compress the IPv6

header down to two octets
• the dispatch octet and
• the LOWPAN_IPHC encoding with link-local communication
• When routing over multiple IP hops, LOWPAN_IPHC can
compress the IPv6 header down to 7 octets
• 1 octet dispatch
• 1 octet LOWPAN_IPHC
• 1 octet Hop Limit
• 2 octet Source Address
• 2 octet Destination Address
 [RFC6282]
IP Header Compression (IPHC)
LOWPAN_IPHC Encoding

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

TF = Traffic Class, Flow Label

NH = Next Header Flag
HLIM = Hop Limit
CID = Context Identifier Extension
SAC = Source Address Compression
SAM = Source Address Mode
M = Multicast Compression
DAC = Destination Address Compression
DAM = Destination Address Mode
IP Header Compression (IPHC)
IPv6 Extension Header Encoding

0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 0 | EID |NH |
+---+---+---+---+---+---+---+---+

EID: IPv6 Extension Header ID

NH: Next Header
 [RFC6282]
UDP Header Compression
NHC Format

+----------------+---------------------------
| var-len NHC ID | compressed next header...
+----------------+---------------------------

UDP NHC Encoding

0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 1 | 0 | C | P |
+---+---+---+---+---+---+---+---+

C = Checksum Compression
P = UDP Port Compression
 6LoWPAN
Fragmentation
Fragmentation
• IPv6 requires underlying links to support Minimum
Transmission Units (MTUs) of at least 1280 bytes
• IEEE 802.15.4 leaves approximately 80-100 bytes of
payload!
• RFC4944 defines fragmentation and reassembly of IPv6
• The performance of large IPv6 packets fragmented over
low-power wireless mesh networks is poor!
• Lost fragments cause whole packet to be retransmitted
• Low-bandwidth and delay of the wireless channel
• 6LoWPAN application protocols should avoid fragmentation
• Compression should be used on existing IP application protocols
when used over 6LoWPAN if possible
Fragmentation
• Impact of fragmentation in LoWPANs
• Assumptions
• p Uncorrelated packet loss probability
• n Number of fragments
• Probability of datagram loss: 1-(1-p)n
Fragmentation
Encodes the size of the entire IP packet
Initial Fragment before link-layer fragmentation

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 0| datagram_size | datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Identification of fragments of the same

Following Fragments IPv6 datagram

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 0| datagram_size | datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|datagram_offset|
+-+-+-+-+-+-+-+-+
Bootstrapping
6LoWPAN Setup & Operation
• Autoconfiguration is important in embedded
networks

• In order for a 6LoWPAN network to start

functioning:
1. Link-layer connectivity between nodes (commissioning)
2. Network layer address configuration, discovery of
neighbors, registrations (bootstrapping)
3. Routing algorithm sets up paths (route initialization)
4. Continuous maintenance of 1-3
Link-layer Commissioning
• In order for nodes to communicate with each other, they
need to have compatible physical and link-layer settings.

• Example IEEE 802.15.4 settings:

• Channel, modulation, data-rate (Channels 11-26 at 2.4 GHz)
• Usually a default channel is used, and channels are scanned to find a
router for use by Neighbor Discovery
• Addressing mode (64-bit or 16-bit)
• Typically 64-bit is a default and 16-bit used if address available
• MAC mode (beaconless or super-frame)
• Beaconless mode is easiest for commissioning (no settings needed)
• Security (on or off, encryption key)
• In order to perform secure commissioning a default key should already
be installed in the nodes
6LoWPAN Neighbor Discovery
• Standard ND for IPv6 is not appropriate for 6LoWPAN:
• Assumption of a single link for an IPv6 subnet prefix
• Assumption that nodes are always on
• Heavy use of multicast traffic (broadcast/flood in 6LoWPAN)
• No efficient multihop support over e.g. 802.15.4
• 6LoWPAN Neighbor Discovery provides:
• An appropriate link and subnet model for low-power wireless
• Minimized node-initiated control traffic
• Node Registration (NR) and Confirmation (NC)
• Duplicate Address Detection (DAD) and recovery
• Support for extended Edge Router infrastructures
• ND for 6LoWPAN has been specified in RFC6775
Architecture
Prefix Dissemination
• In normal IPv6 networks RAs are sent to a link based on
the information (prefix etc.) configured for that router
interface
• In ND for 6LoWPAN RAs are also used to automatically
disseminate router information across multiple hops
Node Registration
• 6LoWPAN-ND Optimizes only the host-router interface
• RFC4861 = signaling between all neighbors (distributed)
• Nodes register with their neighboring routers
• Exchange of NR/NC messages
• Binding table of registered nodes kept by the router
• Node registration exchange enables
• Host/router unreachability detection
• Address resolution (a priori)
• Duplicate address detection
• Registrations are soft bindings
• Periodically refreshed with a new NR message
NR/NC Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
| Type (NR)/(NC)| Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
| TID | Status |P| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
| |
| Binding Lifetime | Advertising Interval |
+ Owner Interface Identifier +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|
+ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
| Owner Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
| Registration option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Typical 6LoWPAN-ND Exchange
The Whiteboard
• The whiteboard is used in the LoWPAN for:
• Duplicate address detection for the LoWPAN (= prefix)
• Dealing with mobility (Extended LoWPANs)
• Short address generation
• Locating nodes
Extended LoWPANs
• Extended LoWPANs consist of two or more LoWPANs:
• Which share the same IPv6 prefix
• Which are connected together by a backbone link
• Whiteboards are synchronized over the backbone link
Security
Security for 6LoWPAN
• Security is important in wireless embedded networks
• Wireless radios are easily overheard
• Autonomous devices with limited processing power
• A system usually has three main security goals
• Confidentiality
• Integrity
• Availability
• See the threat model for Internet security in RFC3552

L5 Mechanisms

L3 Mechanisms

L2 Mechanisms
Layer-2 Mechanisms
• Internet security is usually thought of as end-to-end
• In wireless networks the channel itself is very vulnerable
• The channel is easy to overhear
• Nodes and packets are easy to spoof
• The goals of security at the data-link layer
• Protect the wireless network against attackers
• Increase robustness against attacks
• IEEE 802.15.4 provides built-in encryption
• Based on the 128-bit Advanced Encryption Standard (AES)
• Counter with CBC-MAC mode (CCM)
• Provides both encryption and an integrity check
• Most chips include an AES-128 hardware engine
Layer-3 Mechanisms
• End-to-end security can be provided by IP
• Protects the entire path between two end-points
• The IPsec standard [RFC4301] defined IP security
• Two packet formats are defined:
• Authentication Header (AH) in [RFC4302]
• Integrity protection and authentication only
• Encapsulating Security Payload (ESP) [RFC4303]
• Also encrypts for confidentiality

• ESP is most widely used

• A mode of ESP defines using AES/CCM [RFC4309]
• Suitable for use with 6LoWPAN nodes
• The same L2 IEEE 802.15.4 hardware engine can be applied!
Literature
Literature
[RFC4919] “IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals”, N. Kushalnagar, G.
Montenegro, C. Schumacher
[RFC4944] “Transmission of IPv6 Packets over IEEE 802.15.4 Networks”, G.
Montenegro, N. Kushalnagar, J. Hui, D. Culler
[RFC6282] “Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based
Networks”, J. Hui, P. Thubert, September 2011
[RFC6775] “Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)”, Z. Shelby, S. Chakrabarti, E. Nordmark,
C. Bormann, November 2012
[RFC4861] “Neighbor Discovery for IP version 6 (IPv6)” T. Narten, E. Nordmark,
W. Simpson, H. Soliman
[RFC2463] “Internet Control Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification”, A. Conta, S. Deering
[RFC793] “Transmission Control Protocol”, J. Postel
[RFC768] “User Datagram Protocol” J. Postel
[RFC3819] “Advice for Internet Subnetwork Designers”, P. Karn, C. Bormann, G.
Fairhurst, D. Grossman, R. Ludwig, J. Mahdavi, G. Montenegro, J. Touch, L.
Wood
[RFC4443] “Internet Control Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification”, A. Conta, S. Deering, M. Gupta, March 2006
[RFC2373] “IP Version 6 Addressing Architecture”, R. Hinden, S. Deering, July
1998