IPv6

• Does One Need DHCP(v6)?
• Is RFC 6939 Support Finally Here – Checking the Implementation of the “Client Link Layer Address Option” in DHCPv6

• USGv6-Revision-1 to define the specification
• USGv6 Tested Registry

NAT exists in IPv6:

• IPv6-to-IPv6 Network Prefix Translation exists (RFC 6296, June 2011).

NATing between IPv6 and IPv4:

• Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (RFC 6146, April 2011)
• Mapping of Address and Port using Translation (MAP-T) (RFC 7599, July 2015)

Delivering a virtual IPv4 link over IPv6:

• Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion (RFC 6333, August 2011)
• 464XLAT: Combination of Stateful and Stateless Translation (RFC 6877, April 2013)
• Mapping of Address and Port with Encapsulation (MAP-E) (RFC 7597, July 2015)

As for firewalls see:

• Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service (RFC 6092, January 2011)
• Thousands of ISP’s are using these RFCs to deliver working IPv4 and IPv6 to their customers today. Often the customer doesn’t even know they are using them.

If you don’t want to do a forklift upgrade deploy routers which support these RFCs as the old ones die and slowly migrate to a IPv6-only IPV4AAS model. Nobody has ever said that forklift upgrades where required.

Seen 2021/09/14 mailing list

From a mailing list:

One way to avoid knowing or typing the specific LL address is to ping the all-nodes link scoped multicast address, and looking for the address you're after in the response.

E.g. under Linux, the following command will show all IPv6 link local addresses on the link (assuming they reply to an ICMPv6 echo request) that respond within 1 second:

# ping -w 1 -I wlp6s0 ff02::1
ping6: Warning: source address might be selected on device other than wlp6s0.
PING ff02::1(ff02::1) from :: wlp6s0: 56 data bytes
64 bytes from fe80::e54:15ff:fe66:3b9a%wlp6s0: icmp_seq=1 ttl=64 time=0.074 ms
64 bytes from fe80::aca7:4aff:fed2:a7dd%wlp6s0: icmp_seq=1 ttl=64 time=3.47 ms (DUP!)
64 bytes from fe80::400:55ff:fe40:5%wlp6s0: icmp_seq=1 ttl=64 time=3.51 ms (DUP!)
64 bytes from fe80::9e8e:cdff:fe0e:6709%wlp6s0: icmp_seq=1 ttl=64 time=216 ms (DUP!)
64 bytes from fe80::9e8e:cdff:fe0e:66ff%wlp6s0: icmp_seq=1 ttl=64 time=221 ms (DUP!)
64 bytes from fe80::fe90:d8d2:7ec5:3c8%wlp6s0: icmp_seq=1 ttl=64 time=221 ms (DUP!)
64 bytes from fe80::a65d:36ff:fe40:e31c%wlp6s0: icmp_seq=1 ttl=64 time=250 ms (DUP!)

--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +6 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.074/130.707/249.971/111.633 ms

Comment:

Can you write the code which tells you when you have the no IPv4 “thing” without trying the IPv4 thing on a network which by definition should not have the IPv4 thing where you want people not to try the IPv4 thing?

Response:

We've been here before - I don't think there is any way to write an algorithm that can differentiate between "I can see IPv4 chatter and I should join in because this network is completely IPv6 only yet" and "I can see IPv4 chatter and I shouldn't join in because this network is supposed to be IPv6 only but some other nodes don't understand that". If a key part of the algorithm is "there aren't other IPv4 nodes chattering" then you only need one device on the network to prevent everything else shutting down IPv4.

IPv6 Transition and Coexistence IPv6 - only and IPv4 as - a - Service

You can use Jool for both 464XLAT and just NAT64.

Question:

Thanks... that is what I don't understand: Why is NAT64 such a difficult concept to put into routers and firewalls? We already do NAT with IPv4 just fine.

I feel like IPv6 adoption would be much faster if there was a transition mechanism other than dual stacking.

Think: Corporate offices. Rather than renumbering everything inside, they just turn on NAT64 and now they can begin a slow and controlled transition.

Answer:

This document, which is already in the IESG review, may answer your question: draft-ietf-v6ops-transition-ipv4aas

Also take a look into this one: draft-ietf-v6ops-nat64-deployment.

Remember that if your enterprise network has apps that use literals, or they don't support IPv6, you still need dual-stack in the LANs, but access IPv6-only is just fine.

Other comments:

It’s not s difficult concept but you need to remember NAT44 breaks stuff and NAT64/NAT46 breaks more stuff.

Dual stacking is SIMPLE. REALLY. Turn on IPv6 with the M bit set and configure the DHCPv6 server. If you don’t need that level of control of address assignments leave the M bit off. 99.99% of your machines will just add a second address to the interface without you having to do anything more.

Getting to IPv6 resources from IPv4 address is a *much* harder problem that getting to IPv4 resources from IPv6 which is what you are describing here with the “no renumber everything as they already have a IPv4 address” requirement. NAT64 allows IPv6 devices to get to legacy IPv4 servers. To allow IPv4 devices to get to IPv6 servers you need to map the IPv6 addresses you want to talk to in to a pool of IPv4 addresses and push that mapping to a NAT46 (not NAT64) device.

Go dual stack then, once IPv6 is stable, turn off IPv4 if you want to be single stacked. You are then no longer dependent on the services you want want to access continuing to be offered over IPv4. 464XLAT will only work as a stop gap for IPv4 clients while services are offered over IPv4. After ~20 years of IPv6 being available (Windows XP had IPv6 support and it was not the first major OS to have it) just turn on IPv6.

• Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to choose
• draft-palet-v6ops-p2p-from-customer-prefix-01: Using /64 from Customer Prefix for the Inter-Router Link
• Jool: an Open Source SIIT and NAT64 for Linux
• Understanding IPv6 – 7 Part Series - from Networking with FISH - "This has been a very popular series for people completely new to IPv6 and still working to wrap their head around it all. I wrote this blog series I wish had been out there when I was new to IPv6. I hope you enjoy it tons."
• Small / Home Office network IPv6 wish list - n this post, I’d like to focus on efforts to bring greater IPv6 support to Small Office / Home Office (SOHO) routers, which differ from standard home routers as they need to accommodate broader functionality. My hope is that router manufacturers will incorporate these features to improve IPv6 support.

I write as co-chair of v6ops, under our charter element "comment to other working groups when it seems appropriate".

One outcome from at least v6ops and I think a couple of other WGs and RGs this week - may I suggest a change to Node Requirements and a corresponding change to the IPv6 Ready Logo?

General Category: "Good grief, it's 2017 for goodness' sake!"

Something that would be helpful in IPv6 deployment would be to turn IPv6 on by default in residential routers. Note that this is not the general case. I can think of routers, whose vendors have C's and J's, and probably H's, in their names, whose default configuration is as an Internet Host. The following would apply to devices that are configured by default as an IP router with routing enabled.

Please add a requirement of the general form:

• "If IPv4 router operation is enabled by default, enable IPv6 router operation by default."

Note that this is not as simple as it might sound. There are at least three configurations that must be allowed for upstream: bridging the ISP downstream and CPE downstream LANs, Address allocation via DHCP IA_NA, and address allocation via SLAAC, and on the CPE downstream LAN(s), address allocation via DHCP IA_NA and SLAAC. BBF TR-124 gives a flowchart for this or RFC 7084 defines the algorithms. The implementation is going to have to enable all three, see which works, and act accordingly.

There may also be considerations for PPPOE: if IPv4 is configured for PPPOE, turn it on for IPv6.

Good Grief. This is 2017 for goodness' sake, and there are implementations that turn IPv6 on by default and work. Do it. Just do it.

-- Fred Baker

With a caveat:

As a separate issue, from an operational point of view, implicit enabling of functionality in one area when it's explicitly enabled in another is something that needs to be handled carefully because otherwise you can end up violating the principal of least astonishment.

-- Nick Hilliard

And some miscellaneous links:

• IPv6 Neighbour Discovery Protocol

From the ipv6 mailing list:

Can anyone tell how will a DHCPv6 subscriber learn about the default gateway it has to contact for the subscriber traffic?

A DHCPv6 subscriber is supposed to learn about default gateway from Router Advertisement.

You need to read RFC4861 to understand the relevant details of RA.

Also, can you point me to the document where it is mentioned that a DHCPv6 subscriber has to use RS-RA for resolving gateway address?

Section 7.2.2 of RFC6434 explains this (but the wording could be clearer, perhaps). The basic point is that RFC4861 is effectively mandatory and DHCPv6 is optional.

This draft from the IETF based upon work from Cisco, Juniper, and Google is titled Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution.

Quoting from the lead in section:

Connecting an enterprise site to multiple ISPs using provider- assigned addresses is difficult without the use of some form of Network Address Translation (NAT). Much has been written on this topic over the last 10 to 15 years, but it still remains a problem without a clearly defined or widely implemented solution. Any multihoming solution without NAT requires hosts at the site to have addresses from each ISP and to select the egress ISP by selecting a source address for outgoing packets. It also requires routers at the site to take into account those source addresses when forwarding packets out towards the ISPs.

This document attempts to define a complete solution to this problem. It covers the behavior of routers to forward traffic taking into account source address, and it covers the behavior of host to select appropriate source addresses. It also covers any possible role that routers might play in providing information to hosts to help them select appropriate source addresses. In the process of exploring potential solutions, this documents also makes explicit requirements for how the solution would be expected to behave from the perspective of an enterprise site network administrator.

Some interesting quotes:

"It is not reasonable to expect an enterprise network operator to change the routing topology of the site in order to deploy IPv6."

"Mechanisms have been proposed to allow hosts to choose the source address for packets in a fine grained manner. We will discuss these proposals in Section 4. However, interacting with host operating systems in some manner to ensure a particular source address is chosen for a particular destination prefix is not what an enterprise network administrator would expect to have to do to implement this routing policy."

"With IPv4, this problem is commonly solved by using [RFC1918] private address space within the multi-homed site and Network Address Translation (NAT) or Network Address/Port Translation (NAPT) on the uplinks to the ISPs. However, one of the goals of IPv6 is to eliminate the need for and the use of NAT or NAPT. Therefore, requiring the use of NAT or NAPT for an enterprise site to multihome with provider-assigned addresses is not an attractive solution."

Most everyone knows how to write an IPv4 ip address, and is easy and simple to understand.

As the world migrates to a new internet addressing system, which is known as IPv6, writing out the address becomes difficult. The difficulty is that there are multiple ways of writing an IPv6 address. As a consequence, when people need to perform text searches, no matches may result because the way in which it was searched doesn't match the way in which it was written.

A new document has been authored entitled A Recommendation for IPv6 Address Text Representation which helps to standardize the process of writing an IPv6 address.

In a nutshell, the recommendation is:

• Leading zeros MUST be suppressed. For example 2001:0db8::0001 is not acceptable and must be represented as 2001:db8::1. A single 16 bit 0000 field MUST be represented as 0.
• The use of symbol "::" MUST be used to its maximum capability. For example, 2001:db8::0:1 is not acceptable, because the symbol "::" could have been used to produce a shorter representation 2001:db8::1.
• The symbol "::" MUST NOT be used to shorten just one 16 bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct.
• When there is an alternative choice in the placement of a "::", the longest run of consecutive 16 bit 0 fields MUST be shortened (i.e. the sequence with three consecutive zero fields is shortened in 2001: 0:0:1:0:0:0:1). When the length of the consecutive 16 bit 0 fields are equal (i.e. 2001:db8:0:0:1:0:0:1), the first sequence of zero bits MUST be shortened. For example 2001:db8::1:0:0:1 is correct representation.
• The characters "a", "b", "c", "d", "e", "f" in an IPv6 address MUST be represented in lower case.
• When writing port numbers with an IPv6 address, the [] style as expressed in [RFC3986] SHOULD be employed, and is the default unless otherwise specified -- [2001:db8::1]:80