IPv6 Header Format: Structure, Fields, and Extension Headers

Why IPv6 Changed the Header#

IPv4's header grew organically over decades. Options were added, fields were repurposed, and by the end you had a variable-length header with 14 different fields (some optional) and a complex structure that routers had to parse carefully at every hop.

IPv6 took a different approach: fixed-length, simplified, and optimized for fast forwarding. The base header is always exactly 40 bytes, with 8 well-defined fields. No variable-length options, no header checksum, no fragmentation fields in the main header.

The result is a header that routers can process faster, that's easier to implement in hardware, and that supports extension without breaking backward compatibility. Understanding the IPv6 header means understanding why it's built this way and what trade-offs the designers made.

The 40-Byte Base Header#

Every IPv6 packet starts with exactly 40 bytes in this 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fixed size. No options in the base header. Every router knows exactly where each field is without parsing.

The Eight Fields#

Let's examine each field in the order routers typically process them.

1. Version (4 bits)#

Always 6 for IPv6 packets. Always 4 for IPv4 packets. This is how devices distinguish IPv6 from IPv4 on the wire.

Practical implication: Dual-stack systems look at these 4 bits first to determine how to parse the rest of the packet.

Version = 6 (binary: 0110)

Simple, unchanging, and critical for protocol identification.

2. Traffic Class (8 bits)#

Formerly called "Priority" in early IPv6 specs, this field marks packets for Quality of Service (QoS) treatment. It serves the same purpose as IPv4's Type of Service (ToS) or Differentiated Services Code Point (DSCP).

Structure:

• Bits 0-5: DSCP (Differentiated Services Code Point)
• Bits 6-7: ECN (Explicit Congestion Notification)

Common DSCP values:

ECN allows routers to signal congestion without dropping packets. It's used by modern TCP implementations for better congestion control.

Example:

Traffic Class = 46 (EF) = 0b10111000
  DSCP = 46 (Expedited Forwarding)
  ECN = 0 (Not ECN-capable)

Routers that support QoS examine this field to prioritize packets. VoIP gets higher priority than file downloads. Real-time video gets better treatment than email.

3. Flow Label (20 bits)#

One of IPv6's most interesting but underutilized features. The Flow Label identifies packets that belong to the same flow and should receive identical routing treatment.

Purpose:

• Allow routers to identify related packets without examining upper-layer headers
• Support fast-path forwarding for known flows
• Provide a handle for per-flow QoS

Specification (RFC 6437):

• Value 0: Packet not part of a flow
• Value 1-0xFFFFF: Flow identifier (randomly chosen by source)
• Must be consistent for all packets in a flow
• Should be pseudo-random to allow router hashing

What constitutes a flow:

• Source + Destination + Flow Label uniquely identifies it
• All packets in a TCP connection might use the same Flow Label
• Or each video stream might get a unique label

Practical usage:

Many implementations set Flow Label to 0 because:

• Hardware needed to hash/forward based on Flow Label isn't universal
• Application support is limited
• It's optional, and zero works fine

But when used correctly, Flow Label enables:

• Load balancing across ECMP (Equal Cost Multi-Path) routes
• Per-flow traffic engineering
• Hardware fast-path forwarding

Example of setting Flow Label (Linux):

# Enable automatic flow labels
sysctl -w net.ipv6.auto_flowlabels=1

This enables automatic flow label generation based on connection parameters.

Linux generates flow labels automatically for TCP connections when enabled, using a hash of source/destination address and ports.

4. Payload Length (16 bits)#

Length of the packet payload in bytes, excluding the 40-byte base header.

Range: 0 to 65,535 bytes

Important details:

• Includes extension headers (if any) plus upper-layer data
• Does NOT include the base 40-byte IPv6 header
• Maximum value 65,535 means maximum packet size is 65,575 bytes (65,535 + 40)

Special case: Jumbograms

For packets larger than 65,535 bytes, Payload Length is set to 0 and a Hop-by-Hop extension header with the Jumbogram option carries the actual length (up to 4,294,967,295 bytes).

Jumbograms are rare. They're used on specialized high-performance networks with jumbo frame support, typically over 10 Gbps+ links.

Example:

Payload Length = 1440 bytes
  40-byte IPv6 header (not counted)
  1440-byte payload (TCP header + data)
  Total packet = 1480 bytes

5. Next Header (8 bits)#

Identifies the type of header immediately following the IPv6 header. This is how extension headers and upper-layer protocols are specified.

Common values:

How chaining works:

Each extension header contains its own Next Header field, forming a chain:

IPv6 Header (Next Header = 0)
  -> Hop-by-Hop Options (Next Header = 43)
    -> Routing Header (Next Header = 6)
      -> TCP Header
        -> Data

The receiving host processes headers in order until it reaches the transport protocol (TCP/UDP) or data.

Example without extension headers:

Next Header = 6 (TCP)

The IPv6 header is directly followed by the TCP header and data.

Example with extension headers:

Next Header = 44 (Fragment)

The IPv6 header is followed by a Fragment header (which has Next Header = 6), then the TCP header follows the Fragment header.

6. Hop Limit (8 bits)#

The number of router hops remaining before the packet is discarded. Each router decrements this by 1. When it reaches 0, the router drops the packet and sends an ICMPv6 Time Exceeded message.

Range: 0-255

This is IPv6's equivalent of IPv4's TTL (Time To Live) field, but the name is more accurate—it counts hops, not time.

Common initial values:

Why different values matter for fingerprinting:

You can guess the source OS by looking at the Hop Limit in received packets:

Received Hop Limit: 56
  56 + 8 hops = 64 (likely Linux/BSD)
 
Received Hop Limit: 117
  117 + 11 hops = 128 (likely Windows)

Traceroute uses Hop Limit:

Traceroute maps network paths by sending packets with incrementing Hop Limit values. Each router along the path responds when the limit reaches zero, revealing the route topology.

Security consideration:

Some attacks use low Hop Limits to make packets expire before reaching IDS/IPS systems. Firewalls sometimes enforce minimum Hop Limit values for inbound traffic.

Example:

Hop Limit = 64
  Router 1 receives, decrements to 63, forwards
  Router 2 receives, decrements to 62, forwards
  ...
  Router 64 receives, decrements to 0, drops and sends ICMPv6 Type 3

7. Source Address (128 bits)#

The IPv6 address of the packet's sender. Always 128 bits, no exceptions.

Format: Standard IPv6 address notation

2001:db8:1234:5678:9abc:def0:1234:5678

Special considerations:

Unspecified address (::) is valid only in specific cases:

• Duplicate Address Detection (DAD)
• DHCP requests before address assignment
• Certain ICMPv6 messages

Link-local addresses (fe80::/10) are valid source addresses but only on the local link. Routers don't forward packets with link-local sources.

Multicast addresses are never valid source addresses. A packet with a multicast source should be dropped immediately.

Practical issue: Source address selection

When a host has multiple IPv6 addresses (common with SLAAC, DHCPv6, and privacy extensions), it must choose which to use as the source. RFC 6724 defines the selection algorithm, preferring:

1. Same address scope as destination
2. Addresses with longer matching prefix
3. Non-deprecated addresses
4. Addresses with higher preference

8. Destination Address (128 bits)#

The IPv6 address of the packet's intended recipient. Like Source Address, always 128 bits.

Format: Standard IPv6 address notation

2001:4860:4860::8888

Routing decision:

Routers examine this field to determine where to forward the packet. Unlike IPv4 where NAT might rewrite addresses, IPv6 destination addresses typically remain unchanged end-to-end.

Special addresses:

Loopback (::1) must never appear in a packet on the wire. Packets to ::1 are handled internally.

Multicast addresses (ff00::/8) indicate the packet should be delivered to multiple recipients:

• ff02::1 - All nodes on local link
• ff02::2 - All routers on local link
• ff02::1:ff00:0/104 - Solicited-node multicast (for Neighbor Discovery)

Routing header modification:

When a Routing extension header is present, intermediate nodes might process the destination address differently, but this is uncommon in modern networks due to security concerns.

IPv6 vs IPv4 Header Comparison#

Understanding what changed helps appreciate the design decisions.

What Was Removed and Why#

Header checksum: IPv4 routers recompute the checksum at every hop because TTL changes. This adds processing overhead. IPv6 eliminates it because:

• Link layer (Ethernet) has its own checksum
• Transport layer (TCP/UDP) has its own checksum
• Routers don't need to verify packet integrity—endpoints do

Header Length field: IPv4 needs this because options make the header variable-length. IPv6's fixed 40-byte header makes this field unnecessary.

Fragmentation fields: IPv4 allows any router to fragment packets. IPv6 requires the source to perform fragmentation using Path MTU Discovery. This moves complexity to the endpoints and improves router performance.

Options: IPv4 options are rarely used but force routers to parse variable-length headers. IPv6 moves options to extension headers, keeping the base header simple.

Extension Headers Explained#

Extension headers are IPv6's way of adding functionality without complicating the base header. They appear between the IPv6 header and the transport layer (TCP/UDP), forming a chain.

How Extension Headers Work#

Each extension header contains a Next Header field that points to the next header in the chain:

+--------+-------+--------+-------+--------+-------+-----+
| IPv6   | NH=0  | Hop-by | NH=43 | Routing| NH=6  | TCP |
| Header |       | -Hop   |       | Header |       |     |
+--------+-------+--------+-------+--------+-------+-----+

Hosts process extension headers in order. Routers typically only process Hop-by-Hop Options; other headers are examined only by the destination.

Standard Extension Headers#

RFC 8200 defines the recommended order when multiple extension headers are present:

1. Hop-by-Hop Options (0)
2. Destination Options (for intermediate destinations when Routing header is present)
3. Routing (43)
4. Fragment (44)
5. Authentication Header (51)
6. Encapsulating Security Payload (50)
7. Destination Options (60) (for final destination)
8. Upper Layer (TCP=6, UDP=17, ICMPv6=58)

Hop-by-Hop Options Header (Type 0)#

Carries options that must be examined by every router along the path.

Format:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
.                         Options                               .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Common options:

Pad1 and PadN: Padding for alignment

Router Alert (Type 5): Tells routers to examine the packet more closely. Used by protocols like MLD (Multicast Listener Discovery).

Jumbogram (Type 194): For packets larger than 65,535 bytes.

Must be first: If present, Hop-by-Hop Options must immediately follow the IPv6 header. RFC 8200 requires this strict ordering.

Security concern: Many routers drop packets with Hop-by-Hop headers they don't recognize, or rate-limit them heavily. In practice, this extension header is uncommon outside specific protocols (MLD, jumbograms).

Routing Header (Type 43)#

Specifies intermediate nodes the packet should visit before reaching its final destination.

Format:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  | Routing Type  | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                     Type-specific data                        .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Routing Types:

Type 0 (Deprecated): Original loose source routing. Deprecated by RFC 5095 due to security issues (amplification attacks).

Type 2: Used by Mobile IPv6 for routing to mobile nodes. Limited use case.

Type 3: Segment Routing Header (SRH) for SRv6. Modern use case for traffic engineering and service chaining in carrier networks.

Security: Type 0 Routing Headers allowed attackers to route packets through arbitrary nodes, creating amplification attacks. Most networks drop Type 0. Type 3 (SRv6) is designed more carefully but still raises security concerns on public Internet.

Fragment Header (Type 44)#

Used when the source fragments a packet that's too large for the path MTU.

Format:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Identification                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fields:

• Next Header: Protocol of the fragmented data (TCP, UDP, etc.)
• Fragment Offset: Offset of this fragment in the original packet (in 8-byte units)
• M flag: More Fragments (1 = more coming, 0 = last fragment)
• Identification: Unique ID for reassembly (same for all fragments of one packet)

How fragmentation works:

1. Source tries to send large packet
2. Receives ICMPv6 Packet Too Big message
3. Fragments packet into smaller pieces
4. Adds Fragment header to each piece
5. Destination reassembles based on Identification field

Example:

Original 2000-byte packet, MTU 1280:

Fragment 1:
  IPv6 Header (40 bytes)
  Fragment Header (8 bytes) [M=1, Offset=0, ID=12345]
  Data (1232 bytes)
  Total: 1280 bytes
 
Fragment 2:
  IPv6 Header (40 bytes)
  Fragment Header (8 bytes) [M=0, Offset=154, ID=12345]
  Data (768 bytes)
  Total: 816 bytes

Minimum MTU: IPv6 requires all links to support at least 1280 bytes. Sources can send 1280-byte packets without fragmentation on any compliant IPv6 network.

Security concerns: Fragmentation enables attacks:

• Overlapping fragments (obfuscate payload from IDS)
• Fragment floods (exhaust reassembly resources)
• Tiny fragments (waste processing time)

Many firewalls drop fragmented packets or reassemble them before inspection.

Destination Options Header (Type 60)#

Carries options for the destination node only. Intermediate routers don't process it.

Format: Same as Hop-by-Hop Options, but examined only at destination.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
.                         Options                               .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Use cases:

• Padding for alignment
• Application-specific options
• Future extensions without changing base header

Can appear twice in the header chain:

1. Before Routing header (processed by intermediate destinations)
2. After ESP/AH headers (processed by final destination)

Authentication Header (Type 51) and ESP (Type 50)#

IPsec headers providing authentication and encryption.

AH (51): Provides authentication and integrity but not confidentiality. Rarely used because ESP can do the same plus encryption.

ESP (50): Provides confidentiality, authentication, and integrity. Standard for VPNs and encrypted communication.

IPsec is a large topic beyond header structure. Key point: these headers are part of IPv6's design from the start, unlike IPv4 where IPsec was bolted on later.

Processing Extension Headers#

Hosts must:

• Process all extension headers in order
• Support all standard extension headers
• Handle unknown headers according to Next Header value

Routers typically:

• Only examine Hop-by-Hop Options
• Forward other extension headers without processing
• May rate-limit or drop packets with certain headers for security

Firewall considerations:

Extension headers complicate firewalls because:

• Transport header (TCP/UDP) might be deep in the packet
• Must parse entire chain to find ports for filtering
• Attackers can obfuscate payloads with complex header chains

Best practices:

• Limit extension header chain length
• Drop packets with deprecated headers (Type 0 Routing)
• Reassemble fragments before inspection
• Rate-limit packets with Hop-by-Hop options

Why No Checksum?#

IPv4 includes a header checksum that routers must recompute at every hop (because TTL changes). IPv6 deliberately omits this.

Reasoning:

1. Link layer already checksums: Ethernet has CRC32. Wi-Fi has checksums. Modern link layers are reliable.

2. Transport layer checksums: TCP and UDP include checksums covering data and headers. End-to-end verification happens anyway.

3. Router performance: Recomputing checksums at every hop wastes CPU cycles. High-speed routers forward billions of packets per second—eliminating checksum calculation helps.

4. Errors are rare: Modern networks have low bit error rates. Checksums catch fewer errors than in the 1980s when IPv4 was designed.

What about corruption?

If a bit flips in an IPv6 header:

• Wrong destination address: Packet goes to wrong place or gets dropped, TCP retransmits
• Wrong hop limit: Packet might die early or late, marginal impact
• Wrong next header: Destination can't parse it, TCP detects missing data and retransmits

The end-to-end principle says endpoints should detect and handle errors. Intermediate routers just forward packets fast.

Practical Implications#

For Network Engineers#

Firewall configuration:

• Must parse extension header chains to find transport headers
• Should limit chain depth to prevent abuse
• Drop deprecated headers (Type 0 Routing)

Performance tuning:

• No header checksum means faster forwarding in hardware
• Fixed header size enables better pipelining in routers
• Extension headers might trigger slow-path processing

Troubleshooting:

• tcpdump shows all headers: tcpdump -i eth0 -vv ip6
• Wireshark parses extension headers clearly
• Check for unexpected extension headers causing drops

For Developers#

Socket programming:

• IPv6 sockets can receive extension headers via ancillary data
• Applications rarely need to construct extension headers manually
• OS handles fragmentation automatically

Packet construction:

• Set Traffic Class for QoS-sensitive applications (VoIP, video)
• Enable automatic Flow Label generation for better ECMP load balancing
• Don't assume you can fragment—use PMTUD properly

Security:

• Validate source addresses (reject multicast sources, etc.)
• Handle fragmented packets carefully or reject them
• Be aware that middleboxes might drop extension headers

For System Administrators#

MTU configuration:

• Ensure MTU is at least 1280 bytes on all links
• Larger MTUs improve performance (1500 standard, 9000 for jumbo frames)
• Allow ICMPv6 Packet Too Big through firewalls

QoS setup:

• Configure routers to honor Traffic Class markings
• Map application traffic to appropriate DSCP values
• Monitor that QoS policies work correctly

IPsec/VPN:

• AH and ESP are extension headers—firewalls must allow them
• IPsec adds overhead—account for this in MTU calculations
• Consider transport mode vs tunnel mode impact on headers

Examining Headers with Tools#

tcpdump#

Capture and display IPv6 headers:

# Basic IPv6 packet capture
sudo tcpdump -i eth0 -n ip6

This captures all IPv6 traffic on the eth0 interface.

# Verbose output showing all header fields
sudo tcpdump -i eth0 -vv ip6

The verbose mode displays detailed header information including all 8 fields.

# Show only packets with extension headers
sudo tcpdump -i eth0 -vv 'ip6 and ip6[6] != 6 and ip6[6] != 17 and ip6[6] != 58'

This filters for packets where the Next Header field is not TCP (6), UDP (17), or ICMPv6 (58), revealing extension headers.

# Capture fragmented packets
sudo tcpdump -i eth0 -n 'ip6 and ip6[6] = 44'

This specifically captures packets with Fragment extension headers (type 44).

Example output:

12:34:56.789012 IP6 2001:db8::10 > 2001:db8::20: DSTOPT (TCP)
  2001:db8::10.54321 > 2001:db8::20.80: Flags [S], seq 123456789, win 65535
 
Analysis:
- Source: 2001:db8::10, port 54321
- Destination: 2001:db8::20, port 80
- Extension header: Destination Options (DSTOPT)
- Transport: TCP SYN

Wireshark#

Wireshark provides detailed header analysis:

Filters:

# All IPv6 traffic
ipv6
 
# Packets with specific extension headers
ipv6.nxt == 0    # Hop-by-Hop
ipv6.nxt == 43   # Routing
ipv6.nxt == 44   # Fragment
ipv6.nxt == 60   # Destination Options
 
# Fragmented packets
ipv6.fragment
 
# Specific Traffic Class
ipv6.tclass == 46  # Expedited Forwarding

Header inspection:

1. Expand "Internet Protocol Version 6" in packet details
2. See all 8 fields clearly labeled
3. Extension headers appear as separate layers
4. Right-click fields for filtering

Scapy (Python)#

Build and analyze IPv6 packets programmatically:

from scapy.all import *
 
# Create IPv6 packet
pkt = IPv6(src="2001:db8::10", dst="2001:db8::20", tc=46, fl=12345)
pkt = pkt/TCP(sport=54321, dport=80, flags="S")
 
# Show packet structure
pkt.show()
 
# Output:
# ###[ IPv6 ]###
#   version= 6
#   tc= 46
#   fl= 12345
#   plen= None
#   nh= TCP
#   hlim= 64
#   src= 2001:db8::10
#   dst= 2001:db8::20
# ###[ TCP ]###
#   sport= 54321
#   dport= http
 
# Add extension header
pkt = IPv6(dst="2001:db8::20")/IPv6ExtHdrDestOpt()/TCP(dport=80)
pkt.show()

Common Misconfigurations#

Blocking Extension Headers Entirely#

Problem: Firewall drops all packets with extension headers.

Impact:

• Fragmentation doesn't work (type 44 blocked)
• IPsec VPNs fail (types 50/51 blocked)
• Some legitimate traffic drops

Solution: Allow necessary headers (Fragment, AH, ESP), block deprecated ones (Type 0 Routing).

# iptables: Allow fragments, drop Type 0 routing
ip6tables -A FORWARD -m rt --rt-type 0 -j DROP
ip6tables -A FORWARD -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT

Ignoring Traffic Class#

Problem: Routers configured without QoS, all packets get best-effort treatment.

Impact:

• VoIP quality suffers
• Video streams buffer
• Time-sensitive traffic competes with bulk transfers

Solution: Configure QoS policies based on Traffic Class/DSCP.

! Cisco IOS example
class-map match-any VOICE
  match dscp ef
!
policy-map WAN-QOS
  class VOICE
    priority percent 20
  class class-default
    fair-queue
!
interface GigabitEthernet0/1
  service-policy output WAN-QOS

MTU Mismatches#

Problem: Links with MTU < 1280 or firewalls blocking ICMPv6 Packet Too Big.

Impact:

• Connections hang
• Large transfers fail
• PMTUD doesn't work

Solution: Ensure minimum 1280 MTU everywhere, allow ICMPv6 type 2.

# Set MTU
ip link set dev eth0 mtu 1500
 
# Verify
ip -6 link show eth0
 
# Allow Packet Too Big
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT

Related Articles#

• IPv6 Fundamentals - Understand basic IPv6 addressing and concepts before diving into headers.
• ICMPv6 Explained - Learn about ICMPv6, which uses Next Header value 58 and is critical for IPv6.
• IPv6 Firewall Configuration - Configure firewalls to handle IPv6 headers and extension headers correctly.

Frequently Asked Questions#