Subject: [v6ops] Operational Headache: Upstream liveness

From: Fred Baker <[email-masked]>
Date: Fri, 29 Mar 2019 06:38:05 +0100

https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastream/, slide 9

What do we want to say on this issue? Mikael mentions draft-patterson-intarea-ipoe-health as possibly relevant, but I also get the idea that there is more to say; in this case, I think I need to send a note to the relevant authors and chairs asking them what the prognosis is and expressing operational interest. First, is there a consensus to do that? Second, do we have additional comments to pass along? Our comments might be adequately summarized by forwarding a link to this thread, or might rise to the level that needs to be discussed in an internet draft in v6ops. Comments?
--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 29 Mar 2019 06:09:17 +0000

Why is NUD not sufficient to address the problem (WAN neighbor unreachable)? 

I hope that the HGW devices are  compliant with RFC4861 / 7048. 

Cheers,
Rajiv  

> On Mar 29, 2019, at 6:44 AM, Fred Baker <[email-masked]> wrote:
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fred Baker <[email-masked]>
Date: Fri, 29 Mar 2019 10:22:30 +0100

> I hope that the HGW devices are compliant with RFC4861 / 7048.

Well, that seems like a reasonable hope. I think that Mikael is saying that in IPOE environments they might not be compliant, or compliant implementations still have a problem. I think the key point here is to uncover what the issue might be in the context he is discussing, as opposed to simply dismissing it.

---

From: Gert Doering <[email-masked]>
Date: Fri, 29 Mar 2019 10:41:49 +0100

Hi,

On Fri, Mar 29, 2019 at 10:22:30AM +0100, Fred Baker wrote:
> Well, that seems like a reasonable hope. I think that Mikael is
> saying that in IPOE environments they might not be compliant, or
> compliant implementations still have a problem. I think the key
> point here is to uncover what the issue might be in the context he
> is discussing, as opposed to simply dismissing it.

"Time to failure detection" might be an argument as well.

What are the NUD timers in use in typical implementations?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 29 Mar 2019 10:55:38 +0100 (CET)

On Fri, 29 Mar 2019, Fred Baker wrote:

> Well, that seems like a reasonable hope. I think that Mikael is saying 
> that in IPOE environments they might not be compliant, or compliant 
> implementations still have a problem. I think the key point here is to 
> uncover what the issue might be in the context he is discussing, as 
> opposed to simply dismissing it.

RFC7084 doesn't say (afaik) to stop announcing yourself as a default 
router on LAN when your default GW LL next-hop becomes unreachable, and 
then start doing RS, throw away your DHCPv6 prefix etc, and start to go 
back into whatever you do in an WAN interface down/up situation.

This is what is unspecified. We know pretty well what to do in an WAN 
interface down/up event, but not "softer" errors such as when the RA 
sending LL next-hop goes into ND unreachable state.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Fri, 29 Mar 2019 11:30:37 +0100

>sending LL next-hop goes into ND unreachable state.

(terminology: I consider everything that gets a next hop router from RAs
to be a host)

I wonder if we should create an RFC that says that if a host marks a 
default router as unreachable in ND, it should cause a (simulated) link
down/up event.

In a virtual machine that is bridged through the host, you also lose link
events. So this may solve a larger class of problems.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 29 Mar 2019 11:35:52 +0100 (CET)

> (terminology: I consider everything that gets a next hop router from RAs 

Most things today are both routers and hosts at the same time. I find 
keeping the hard disctinction between these concepts to be not useful 
anymore.

> default router as unreachable in ND, it should cause a (simulated) link 

If you mean soft "discard all information received from that specific 
router and start over" then we're in agreement. There might be other 
things on the link so simulating a down/up event might be too much.

> events. So this may solve a larger class of problems.

Absolutely, that was my idea all the time.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 29 Mar 2019 11:52:02 +0100

>keeping the hard disctinction between these concepts to be not useful 

Core IPv6 RFCs distinguish between node, host and router behavior. It is
worth keeping in mind that an interface that gets default routers from
RAs is a host interface in the terminology of ND.

>things on the link so simulating a down/up event might be too much.

There is for example RFC-6059 (Simple Procedures for Detecting Network
Attachment in IPv6)

It is worth considering if in the context of the IPv6, simulating a 
link down/up event is possible, or if that would break things.

In some contexts, it may even be beneficial to bring the physical link
down and up because of badly behaving L2 boxes in the network.

---

From: Ole Troan <[email-masked]>
Date: Fri, 29 Mar 2019 14:43:28 +0100

> I hope that the HGW devices are  compliant with RFC4861 / 7048. 

With the typical deployment of a DHCPv6 PD snooping relay (for the purpose of route injection) it is helpful having a mechanism that also verifies the forwarding state of the first-hop router (PE). 

Cheers,
Ole

---

From: Fred Baker <[email-masked]>
Date: Fri, 29 Mar 2019 17:09:37 +0100

> On Mar 29, 2019, at 10:55 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> RFC7084 doesn't say (afaik) to stop announcing yourself as a default router on LAN when your default GW LL next-hop becomes unreachable, and then start doing RS, throw away your DHCPv6 prefix etc, and start to go back into whatever you do in an WAN interface down/up situation.

Is this for VRRP purposes, or simply as a router in an RA?

One thought in the near term would be to add that as an "erratum" to the RFC, so it gets picked up when the RFC is revised. If we were to create an updating RFC entitled "what to do when your next hop moves away", is there anything else we would want to include?

> This is what is unspecified. We know pretty well what to do in an WAN interface down/up event, but not "softer" errors such as when the RA sending LL next-hop goes into ND unreachable state.
> 
> --