Subject: [v6ops] draft-patterson-intarea-ipoe-health

From: Ron Bonica <[email-masked]>
Date: Mon, 1 Oct 2018 17:07:18 +0000

Folks,

Each week between now and IETF 103, we will review and discuss one draft.

This week, please review and comment on draft-patterson-intarea-ipoe-health.

                                        Fred and Ron

---

From: Richard Patterson <[email-masked]>
Date: Mon, 1 Oct 2018 18:34:34 +0100

Hi Ron et al.

I've actually been sitting on a new version that attempts to simplify
things somewhat, after the feedback from IETF102.
Revision -05 is up now:
https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-05

Changes include:

  - Consolidated the multiple behaviours down to one.
  - Added a Release flag instead of a distinct behaviour.
  - Added custom IPoE Health Check Probe definition.
  - Removed ARP/ND and Passive checks.
  - Removed alternative target address parameter.
  - Removed IANA registry request for Behaviour values.

-Richard
On Mon, 1 Oct 2018 at 18:08, Ron Bonica <[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ole Troan <[email-masked]>
Date: Mon, 1 Oct 2018 19:59:55 +0200

Richard,

Nice work. Thanks for writing this up!

A couple of comments.

Not being particularly clued up on BFD, does BFD echo require a session?
Regardless you could just point to section 4 in RFC5881 for the sending rules.
And perhaps emphasize the BCP 38 considerations.

Also, how much would you really lose if you left out the DHCP options. Does this mechanism really have to be configured?

Best regards,
Ole

> On 1 Oct 2018, at 19:34, Richard Patterson <[email-masked]> wrote:
> 
> Hi Ron et al.
>

---

From: Mark Smith <[email-masked]>
Date: Tue, 2 Oct 2018 06:09:46 +1000

Hi,

I may be missing something, but why can't Neighbor Unreachability
Detection be used for this?

CE's, because they're IPv6 nodes, would have NUD already built in and
being performed because they perform RFC4861 Neighbor Discovery.

The Reachable Time and Retrans Timer parameters, measured in
milliseconds and set in RAs sent to the CEs, can be used to specify
the CE's ND/NUD parameters.

Regards,
Mark.

---

From: Ole Troan <[email-masked]>
Date: Mon, 1 Oct 2018 22:14:24 +0200

Mark,

No, NUD doesn’t prove that the first hop router can forward to the delegated prefix. 

Ole

> On 1 Oct 2018, at 22:09, Mark Smith <[email-masked]> wrote:
> 
> Hi,
>

---

From: Richard Patterson <[email-masked]>
Date: Mon, 1 Oct 2018 21:17:27 +0100

Hi Ole,

Actually your two questions are related.  The use of BFD echo does
indeed require a BFD session to be established between peers. Even
though the BFD echo mechanism itself is relatively lightweight, it is
for this reason that we don't see widespread use of BFD echo on
residential broadband with consumer CPEs.
The use of a DHCP option to communicate parameters to the client, also
assists in signalling intent to the client. I.e., that health checks
can be expected to pass on this network.  This is one of the reasons
why BFD requires the session establishment.

We expect our "IPoE Health Check Probe" to look identical to that
specified in Section 4 of RFC5881, save for the destination port.
Perhaps it can be an informative reference?  Or did you mean we should
reference 5881 in our §3.3 BFD Echo?

Good call on the BCP 38 consideration, I was meaning to include
something about that and networks with strict uRPF that may impede the
use of these "loopback"-style packets after Barbara mentioned it
previously. I'll add a section for that.

-Richard

---

From: Richard Patterson <[email-masked]>
Date: Mon, 1 Oct 2018 21:36:45 +0100

Hi Mark,

We removed both the passive and active NUD checks from this revision
to hopefully simplify the draft and make it more adoptable.
NUD doesn't give us visibility of the DHCP lease validity or
necessarily the subscriber session state.  ND packets also tend to
have to be processed by the remote peer/BNG, where as a UDP/IP
loopback packet can simply be forwarded back to the CPE in hardware,
allowing for the more aggressive tuning of timers.

Whilst I envision this to be adopted by the individual DHCP clients,
it'd be nice if it was the same process for both DHCPv4 and DHCPv6.

-Richard

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Mon, 1 Oct 2018 20:52:18 +0000

Hi Richard,

" any indirect upstream network changes are
   not visible to the IPoE client."

   "The destination MAC address MUST be address of the upstream router."

The scope is only to the first hop router. Can you add an extension for handling the uplink failures to ISPs (https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-07#section-5.3.2)?

   "If a particular prefix should not be used as a source for
   any destinations, then the router needs to send RA with Preferred
   Lifetime field for that prefix set to 0."

This event can also trigger the recovery to alternate DHCP server. Please provide the topology where another DHCP server would be.

Thanks,
Dusan.

> -----Original Message-----
> From: v6ops <[email-masked]> On Behalf Of Richard Patterson
> Sent: Monday, October 01, 2018 1:35 PM
> To: [email-masked]
> Cc: [email-masked] list <[email-masked]>
> Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health
> 
> Hi Ron et al.
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dpatterson-2Dintarea-2Dipoe-2Dhealth-
> 2D05&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIo
> UWB8YLZU23029sMQGQ2kY&m=pIhtq5PQ_R8j4fKL9D0Jwdd-_ZBzYdJEx_3b-
> dBQQX0&s=Dl_OzZQQbBP_tJdv9RwheV4B4H_MQwxT0kR5Hz9UhXs&e=
> 
> Changes include:
> 
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwICAg&c=BFpWQw8bsuKpl
> 1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=pIht
> q5PQ_R8j4fKL9D0Jwdd-_ZBzYdJEx_3b-
> dBQQX0&s=XUiVxCO7DnWDBjoU6rdj6LpLueSvU-FBXjJL1FVjcEc&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwICAg&c=BFpWQw8bsuKpl
> 1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=pIht
> q5PQ_R8j4fKL9D0Jwdd-_ZBzYdJEx_3b-
> dBQQX0&s=XUiVxCO7DnWDBjoU6rdj6LpLueSvU-FBXjJL1FVjcEc&e=

---

From: Mark Smith <[email-masked]>
Date: Tue, 2 Oct 2018 07:14:41 +1000

Hi Ole,

> No, NUD doesn’t prove that the first hop router can forward to the delegated prefix.

The ID's Abstract and Introduction is saying that the problem it is
solving is the lack of a PPP keepalives equivalent in an IPoE
environment, and PPP keepalives don't solve that problem either*.

I'd expect if delegated prefix forwarding validation that was the
focus of the ID, a simple text search for "delegated" or "PD" across
the whole draft should find something, but neither do.

If that's the problem being solved, then it isn't very clear from the
current text. It seems to be more focusing on direct CE to BNG
liveness testing.

Regards,
Mark.

*Technically there is, the Ethernet II spec. specified an Ethernet
Configuration Testing Protocol, which all Ethernet nodes were supposed
to implement (and traditional Cisco IOS does - type 9000 frames).

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 2 Oct 2018 13:35:56 +0000

Hi Richard,

" 
   Similar in format to a BFD Echo packet, the IPoE Health Check probe
   is a simple UDP/IP packet with a destination IP address from the
   lease being checked, and a destination MAC address of the upstream
   router.  "

DHCP lease assigns IP to DHCP client. Is the probe's destination IP, the IP of the client? What is the path that is tested for the health check? Can it be explicitly defined in the draft, to make it clear where packets are flowing? Is it a path between DHCP client and a first hop router? Is it a path between DHCP client and DHCP server? Is it something else? 

How will detection of the failure on that path (between the DHCP client and X?) help finding out the connectivity to DHCP server failed, and that a client needs to find another DHCP server to get a new lease?

If the client is doing the connectivity health check to the DHCP server, and the connectivity is lost, there is no need to first RENEW the lease with the original server.

Thanks,
Dusan.

> From: v6ops <[email-masked]> On Behalf Of Mudric, Dusan (Dusan)
> Sent: Monday, October 01, 2018 4:52 PM
> To: Richard Patterson <[email-masked]>; [email-masked]
> The scope is only to the first hop router. Can you add an extension for
> handling the uplink failures to ISPs
> (https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dietf-2Drtgwg-2Denterprise-2Dpa-
> 2Dmultihoming-2D07-23section-2D5.3.2-29-
> 3F&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoU
> WB8YLZU23029sMQGQ2kY&m=I4vSdejJKILLCcpAkcoiBWR7SlBOUfqtOJy6BD
> Mtk2A&s=zsgu8ktOzHLwsq9IdTBx1KsxkZNbQ1wM6JfDEYuc7ys&e=
> 
> This event can also trigger the recovery to alternate DHCP server. Please
> provide the topology where another DHCP server would be.
> 
> Thanks,
> Dusan.
> 
> 1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=I4vS
> dejJKILLCcpAkcoiBWR7SlBOUfqtOJy6BDMtk2A&s=JYKQ1twmrDppoJk72XJBTL
> AVEy9X-EezcH9c6_vsQGY&e=

---

From: Richard Patterson <[email-masked]>
Date: Wed, 3 Oct 2018 10:08:33 +0100

Hi Dusan,

Not sure if I understand this correctly, however I believe it should
already be covered?
The upstream router in your example is the delegating router
downstream, instead of multi-hop health checks, each router would be
responsible for checking the validity of their own lease.

In the case where the DHCP server is not colocated on the upstream
router, is it safe to assume the upstream router would be performing
some form of DHCP snooping and access restriction?  Also, if the
original DHCP server dies, it doesn't necessarily follow that the
L2/L3 path has failed.  In that example, regular DHCP lease timers
will be sufficient to hit an alternate DHCP server.

-Rich

---

From: Richard Patterson <[email-masked]>
Date: Wed, 3 Oct 2018 10:20:18 +0100

> current text. It seems to be more focusing on direct CE to BNG

You're right, CE to BNG liveness was the primary objective,
simultaneously validating the lease was a secondary benefit.
This is why the original revisions of the draft had multiple health
check methods, and multiple behaviour options.  We've attempted to
consolidate things down in to a more unified approach.

-Rich

---

From: Richard Patterson <[email-masked]>
Date: Wed, 3 Oct 2018 11:03:37 +0100

Hi Dusan,

There're a lot of questions all packed in there, I'll try to answer them all.

The probe's destination IP should be the IP from within the lease.
When testing a PD lease, it could be any address from within that
prefix. When testing an NA lease, it should be of that specific
address, however sending packets destined to a locally bound address
may have issues on certain operating systems as Barbara mentioned.
Agreed this needs more detail written in to the draft after some more
investigation.

Packets should flow between the client and the first layer 3 hop, not
the DHCP server, although the first layer 3 hop may or may not have
the DHCP server colocated with it.  Agreed, this behaviour could be
described better in the draft.

As mentioned to Mark, the primary purpose of this draft is to test the
layer 2 & 3 path, and in fact I'll expand on that a bit to say that
the primary object is actually to check subscriber session state.
The problem is that we're trying to infer subscriber session state
with a combination of L2/3/DHCP lease checks.  L2 checks alone are not
sufficient to prove subscriber session state, nor are L3 checks to the
delegating DHCP server.

-Rich

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 3 Oct 2018 12:52:34 +0200 (CEST)

On Wed, 3 Oct 2018, Richard Patterson wrote:

> layer 2 & 3 path, and in fact I'll expand on that a bit to say that the 
> primary object is actually to check subscriber session state. The 
> problem is that we're trying to infer subscriber session state with a 
> combination of L2/3/DHCP lease checks.  L2 checks alone are not 

Let me provide a concrete example:

BNG <-L2-> <WAN---CE---LAN>

BNG somehow delegates a PD /56 to CE, which allocates this (for example) 
as ::1/64 out of that PD onto its LAN.

Now, on CE WAN, I can run scapy:

sendp(Ether(src="CE-WAN-ETH",dst="BNG-WAN-ETH")/IPv6(src="LAN::2",dst="LAN::1")/UDP(sport=10000,dport=10000)/Raw(load="test\n"),iface="WAN")

This will yield the following packet send towards the BNG:

12:44:23.416601 CE-WAN-ETH > BNG-WAN-ETH, ethertype IPv6 (0x86dd), length 67: LAN::2.10000 > LAN::1.10000: UDP, length 5

Now, because the BNG has a /56 routed towards the CE, the following packet 
will come back:

12:44:23.417526 BNG-WAN-ETH > CE-WAN-ETH, ethertype IPv6 (0x86dd), length 67: LAN::2.10000 > LAN::1.10000: UDP, length 5

(only difference is the swap between SRC/DST MAC addresses and TTL 
decrease after the packet was run through the forwarding engine of the 
BNG)

If I use the LAN::1 address as source of the packet, the Linux kernel will 
drop the packet and it's not delivered to the application on CE, so we're 
going to have to use a non-interface address as source. This is fine as 
long as it's within the PD.

If the PD isn't valid, the BNG will not have that /56 route and we won't 
see the packet coming back to us and delivered to the userspace 
application, which in my example above was "ncat -u -l LAN::1 10000" 
running on CE. That's when we want to kick the DHCPv6 machinery to do all 
the DHCPv6 things that it normally does, to try to renew the lease or 
expire it and ask for a new one.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 3 Oct 2018 16:23:43 +0000

Hi Mikael,

Please see inlined.

Thanks,
Dusan.

> From: Mikael Abrahamsson <[email-masked]>
> Sent: Wednesday, October 03, 2018 6:53 AM
> To: Richard Patterson <[email-masked]>
> Cc: Mudric, Dusan (Dusan) <[email-masked]>; [email-masked] list
> <[email-masked]>
> sendp(Ether(src="CE-WAN-ETH",dst="BNG-WAN-
> ETH")/IPv6(src="LAN::2",dst="LAN::1")/UDP(sport=10000,dport=10000)/Raw
> (load="test\n"),iface="WAN")
[[Dusan]] 
Thanks. This kind of description should be in the problem statement.

>From the comments and the draft, we have several definitions the destination IP. I think dest. IP needs to be more clearly defined. The problem statement like this will help the definition.

" a destination IP address from the lease being checked"
" The probe's destination IP should be the IP from within the lease.
When testing a PD lease, it could be any address from within that
prefix. When testing an NA lease, it should be of that specific
address, however sending packets destined to a locally bound address
may have issues on certain operating systems as Barbara mentioned."

My understanding is that this kind of check needs to be done to determine that DHCP server is not reachable from CE and to start a lease renewal or a new solicitation. Please correct as needed.
1) The CE probe needs to be delivered to an application (which one?) on BNG, in order to check there is IP connectivity between CE and DHCP server (on or behind BNG) delegating the lease (i.e. PD). Need to position DHCP server in the figure to show that if this connectivity check (between CE and BNG) fails, there is no DHCP connection between CE and DHCP server. That triggers the lease renewal or DHCP server discovery on CE.
2) The destination, and the first hop, is BNG. The probe reaches the destination using BNG MAC address .  
3) Should the destination IP be on BNG? Saying that the destination IP can be any address from PD /56 can get the IP from some of PD /64 destinations on the LAN side. Can you double check this definition and make it more clear please?

> 12:44:23.416601 CE-WAN-ETH > BNG-WAN-ETH, ethertype IPv6 (0x86dd),
> length 67: LAN::2.10000 > LAN::1.10000: UDP, length 5
> 
> 12:44:23.417526 BNG-WAN-ETH > CE-WAN-ETH, ethertype IPv6 (0x86dd),
> length 67: LAN::2.10000 > LAN::1.10000: UDP, length 5
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 3 Oct 2018 22:52:04 +0200 (CEST)

On Wed, 3 Oct 2018, Mudric, Dusan (Dusan) wrote:

> My understanding is that this kind of check needs to be done to 
> determine that DHCP server is not reachable from CE and to start a lease 
> renewal or a new solicitation. Please correct as needed.

The check doesn't do anything with the DHCP server. It checks the 
forwarding state of the BNG (routing table). This L3 forwarding table is 
populated based on DHCPv6 state. If this state is deemed to not exist 
(there is no /56 PD route pointed towards the CE), then we kick in the 
DHCP "machinery" to try to "fix" this state.

> 1) The CE probe needs to be delivered to an application (which one?) on 
> BNG, in order to check there is IP connectivity between CE and DHCP 
> server (on or behind BNG) delegating the lease (i.e. PD). Need to 
> position DHCP server in the figure to show that if this connectivity 
> check (between CE and BNG) fails, there is no DHCP connection between CE 
> and DHCP server. That triggers the lease renewal or DHCP server 
> discovery on CE.

The probe is just the CE sending a packet to itself via the BNG. It just 
uses the forwarding plane of the BNG, nothing else. No "application" on 
the BNG. Just standard L3 routing.

If this send-packet-to-myself-via-BNG fails, then we just do the normal 
DHCP renew/solicit that we would do in case WAN port on CE actually went 
down and came back up again. This should then restore the BNG to the 
correct state.