Subject: DAD on tunnels

From: Stephen Suryaputra <[email-masked]>
Date: Wed, 16 Feb 2022 17:01:35 -0500

Hello,

Are there RFCs or drafts that have requirements on DAD for point-to-point
interfaces such as GRE tunnels? Linux for example does not seem to
support it.

Thank you,

Stephen.

---

From: Mark Smith <[email-masked]>
Date: Thu, 17 Feb 2022 10:04:44 +1100

On Thu, 17 Feb 2022, 09:04 Stephen Suryaputra, <[email-masked]> wrote:

> interfaces such as GRE tunnels?

Tunnels are taught, thought and talked about like they're some sort of
magic.

In reality, to the IPv6 layer above them, they're just a layer 2 link. The
upper layer doesn't need to know the framing below happens to also be the
same or similar technology - IPv6 (or IPv4).

So if DAD is required on layer 2 links (and it is) then DAD is required on
layer 2 link tunnels too.

Linux for example does not seem to
> support it.

There's a number of things the Linux IPv6 implementation doesn't do that it
should.

Regards,
Mark.

> Thank you,
>
> Stephen.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Feb 2022 14:13:56 +1300

Just to be clear, RFC4862 says (and RFC8504 repeats):

"5.4.  Duplicate Address Detection

    Duplicate Address Detection MUST be performed on all unicast
    addresses prior to assigning them to an interface, regardless of
    whether they are obtained through stateless autoconfiguration,
    DHCPv6, or manual configuration, with the following exceptions:..."

None of the exceptions would apply to a tunnel interface (unless the tunnel
interface has DupAddrDetectTransmits set to zero).

So, if Linux doesn't do this, Linux is broken.

Regards
    Brian Carpenter

On 17-Feb-22 12:04, Mark Smith wrote:
> 
> 
> On Thu, 17 Feb 2022, 09:04 Stephen Suryaputra, <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hello,
> 
> Tunnels are taught, thought and talked about like they're some sort of magic.
> 
> In reality, to the IPv6 layer above them, they're just a layer 2 link. The upper layer doesn't need to know the framing below happens to also be the same or similar technology - IPv6 (or IPv4).
> 
> So if DAD is required on layer 2 links (and it is) then DAD is required on layer 2 link tunnels too.
> 
> 
> 
> There's a number of things the Linux IPv6 implementation doesn't do that it should.
> 
> 
> Regards,
> Mark.
> 
> 
> 
>     Thank you,
> 
>     Stephen.
> 
>     [email-masked] <mailto:[email-masked]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Ole Troan <[email-masked]>
Date: Thu, 17 Feb 2022 08:33:27 +0100

Thanks Brian.
The only tangential exception I know of is PPP, where DAD is redundant in some cases where the interface identifier is already negotiated as part of IPV6CP. 

Regarding other ND functions, I believe some implementations do “address resolution” on P2P links and some do not. And I am not aware of any IETF consensus one way or the other. 

Che
Ole

> On 17 Feb 2022, at 02:14, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Mark Smith <[email-masked]>
Date: Thu, 17 Feb 2022 19:36:29 +1100

Hi Ole,

On Thu, 17 Feb 2022, 18:33 Ole Troan, <[email-masked]> wrote:

> Thanks Brian.
> The only tangential exception I know of is PPP, where DAD is redundant in
> some cases where the interface identifier is already negotiated as part of
> IPV6CP.

PPP negotiating IIDs was deprecated in RFC8064 as it could mean that all
IPv6 addresses from all prefixes on the link would have the same IID.

As an operator, I want DAD for all addresses regardless of the link type,
including tunnels, because I've spent quite a lot of time troubleshooting
the same IPv4 address being duplicated 5 times on a link before IPv4 DAD
existed (and before DHCPv4) after the software devs decided to copy the
network client software and therefore settings across all their
workstations for some reason.

Silent errors are painful and time consuming to troubleshoot. Fortunately
I''ve never had to do it, however I don't envy those who've had to
troubleshoot ethernet MAC address duplicates.

>
> Regarding other ND functions, I believe some implementations do “address
> resolution” on P2P links and some do not. And I am not aware of any IETF
> consensus one way or the other.

The ping-pong problem that /127s somewhat mitigate* would never have
existed if address resolution was performed on point to point links.

Address resolution/discovery of neighbours is really doing two things -
resolving an IPv6 address into a layer 2 address (on links that need that)
and testing and proving the existence of the address being resolved.

The ping-pong problem occurs because the existence of the address at the
other link is assumed, not proven.

*as long as you make sure you configure both addresses from within the
prefix on both ends of the link - not an IPv6 (or IPv4) requirement, so no
fatal errors, and IPv6 and IPv4 will work fine in many cases. IPv4 and IPv6
don't require or check that all nodes attached to a link have addresses
from all link prefixes.

Regards,
Mark.

> >> In reality, to the IPv6 layer above them, they're just a layer 2 link.
> The upper layer doesn't need to know the framing below happens to also be
> the same or similar technology - IPv6 (or IPv4).
> <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: [email-masked]
Date: Thu, 17 Feb 2022 10:00:20 +0100

> As an operator, I want DAD for all addresses regardless of the link type, including tunnels, because I've spent quite a lot of time troubleshooting the same IPv4 address being duplicated 5 times on a link before IPv4 DAD existed (and before DHCPv4) after the software devs decided to copy the network client software and therefore settings across all their workstations for some reason.
> 
> Silent errors are painful and time consuming to troubleshoot. Fortunately I''ve never had to do it, however I don't envy those who've had to troubleshoot ethernet MAC address duplicates.
> 

Any work improving on DAD reliability would be appreciated.

Ole

---

From: Stephen Suryaputra <[email-masked]>
Date: Thu, 17 Feb 2022 10:43:55 -0500

> Regarding other ND functions, I believe some implementations do “address resolution” on P2P links and some do not. And I am not aware of any IETF consensus one way or the other. 

Thank you all for the responses.

This is exactly my doubts. After experimenting a bit more, DAD works on
GRE Linux implementation but I had to turn on address resolution on the
interface. The interface by default is marked as a type with no address
resolution.  With the turning on the resolution, or more precisely
neighbor discovery, it doesn't do anything on GRE interface, i.e. there
isn't any neighbor resolution protocol being sent on the tunnel which
makes sense to me; but DAD works, i.e. NA and NS are sent when the addr
is configured.

> >> So if DAD is required on layer 2 links (and it is) then DAD is required on layer 2 link tunnels too.

It does act as an L2 link but in the case for GRE there is no link-level
address. Hence part of my confusion on whether DAD, which relies on
neighbor discovery protocols, must be performed or not.

---

From: Mark Smith <[email-masked]>
Date: Fri, 18 Feb 2022 04:53:09 +1100

On Fri, 18 Feb 2022, 02:44 Stephen Suryaputra, <[email-masked]> wrote:

> > The only tangential exception I know of is PPP, where DAD is redundant
> in some cases where the interface identifier is already negotiated as part
> of IPV6CP.
> >
> interface.

So there is the compliance failure.

DAD is to be enabled on all IPv6 enabled interfaces.

The interface by default is marked as a type with no address
> > >> In reality, to the IPv6 layer above them, they're just a layer 2
> link. The upper layer doesn't need to know the framing below happens to
> also be the same or similar technology - IPv6 (or IPv4).

---

From: Tom Herbert <[email-masked]>
Date: Thu, 17 Feb 2022 10:08:07 -0800

On Thu, Feb 17, 2022, 9:54 AM Mark Smith <[email-masked]> wrote:

>> > Regarding other ND functions, I believe some implementations do
>> “address resolution” on P2P links and some do not. And I am not aware of
>> any IETF consensus one way or the other.
>> >
>>

In that case, I suggest posting about this on Linux Netdev list.

Tom

---

From: Mark Smith <[email-masked]>
Date: Fri, 18 Feb 2022 05:08:57 +1100

> GRE Linux implementation but I had to turn on address resolution on the

So there is the lack of compliance. You had to do something for DAD to be
performed, contrary to the specs Brian quoted.

The Linux IPv6 implementation is derived from the IPv4 implementation, so
IPv4 behaviours have been carried over.

For example, you see special case interface/link type handling when the
IPv6 approach is to simplify by avoiding that as much as possible.

Regards,
Mark.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 17 Feb 2022 19:29:57 +0100

> address resolution on P2P links and some do not. And I am not aware
> of any IETF consensus one way or the other.

My experience is that many nodes on links that do not need to do any L2
resolution tend to drop NS packets. Obviously, you can still do DAD if
the other side drops NS packets, but it is a bit pointless (though there is
the loopback condition that can be detected).

---

From: Jared Mauch <[email-masked]>
Date: Thu, 17 Feb 2022 14:32:34 -0500

> On Feb 17, 2022, at 12:53 PM, Mark Smith <[email-masked]> wrote:
> 

And implementors MUST have a way to clear DAD for the operator without flapping the interface or deconfiguring IP on the interface.

(Ugh, been burned by that before)

- Jared

---

From: Ole Troan <[email-masked]>
Date: Thu, 17 Feb 2022 21:02:11 +0100

> On 17 Feb 2022, at 20:33, Jared Mauch <[email-masked]> wrote:
> 
> 
> 

Indeed, DAD is a grand way of taking out an interface. Or if it is in looped mode for while coming up. 

Cheers 
Ole