Subject: [homenet] Prefix Delegation, routing on the last hop ISP router, and draft-stenberg-v6ops-pd-route-maintenance-00

From: Ray Hunter <[email-masked]>
Date: Mon, 02 Mar 2015 17:47:44 +0100

Following question may strictly speaking be out of scope for Homenet, as 
it is about the WAN side interface and interaction with the upstream ISP 
router.

Whilst setting up my own HNCP testbed, I was attempting to configure my 
own "last-hop ISP router" assuming a customer-owned Homenet router 
connected to my last-hop ISP router via Ethernet.
[also so I could do weird things/perform tests/interrupt/monitor DHCP PD]

Was there any further work done on 
draft-stenberg-v6ops-pd-route-maintenance-00?

Or is the Best Current Practice for non-point-to-point links still 
described in draft-stenberg-v6ops-pd-route-maintenance-00?

I was planning on using ISC DHCP 4.3.1 together with an external script 
as described in https://github.com/mpalmer/isc-dhcp contrib, to detect 
the next hop address of my homenet router and install the relevant route 
for the delegated prefix on the last-hop ISP router (a Linux box).

thanks

-- 
Regards,
RayH

---

From: Ole Troan <[email-masked]>
Date: Mon, 2 Mar 2015 19:08:11 +0100

> Following question may strictly speaking be out of scope for Homenet, as it is about the WAN side interface and interaction with the upstream ISP router.
> 
> Whilst setting up my own HNCP testbed, I was attempting to configure my own "last-hop ISP router" assuming a customer-owned Homenet router connected to my last-hop ISP router via Ethernet.
> Was there any further work done on draft-stenberg-v6ops-pd-route-maintenance-00?
> 
> Or is the Best Current Practice for non-point-to-point links still described in draft-stenberg-v6ops-pd-route-maintenance-00?
> 
> I was planning on using ISC DHCP 4.3.1 together with an external script as described in https://github.com/mpalmer/isc-dhcp contrib, to detect the next hop address of my homenet router and install the relevant route for the delegated prefix on the last-hop ISP router (a Linux box).

typically the ISP router snoops DHCPv6 messages and does route injection based on that, or the DHCPv6 server runs on the ISP router and does route injection based on binding state.

cheers,
Ole

---

From: Steven Barth <[email-masked]>
Date: Mon, 02 Mar 2015 19:15:43 +0100

> typically the ISP router snoops DHCPv6 messages and does route injection based on that, or the DHCPv6 server runs on the ISP router and does route injection based on binding state.
I'm doing the latter at home since I don't have any native IPv6 here so 
I have a router doing 6in4 to he.net on the wan-side and it serves 
prefixes using DHCPv6-PD to the lan side. I regularly connect homenet 
routers to it or bridge a VM with homenet to the wired side for testing.

OpenWrt's DHCPv6-server does that automatically if you assign a prefix 
larger than /64 to an interface (first /64 is assigned via RA/DHCPv6 to 
clients on-link, rest is avaialble via PD, routes are set up based on 
binding).

Btw. HNCP specifies optional downstream PD from a homenet to legacy / 
stub-routers and our reference implementation should support that as 
well so its not all too offtopic for homenet I suppose.

Cheers,

Steven

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 3 Mar 2015 17:57:39 +0100 (CET)

On Mon, 2 Mar 2015, Ole Troan wrote:

> typically the ISP router snoops DHCPv6 messages and does route injection 
> based on that, or the DHCPv6 server runs on the ISP router and does 
> route injection based on binding state.

So this is a plausible way of doing intra-home mobility of prefixes. 
Unfortunately it relies on IA_NA which not all devices will use.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Mar 2015 13:41:23 -0500

Ole Troan <[email-masked]> wrote:
> > as described in https://github.com/mpalmer/isc-dhcp contrib, to detect the
> > next hop address of my homenet router and install the relevant route for
> > the delegated prefix on the last-hop ISP router (a Linux box). 

> based on that, or the DHCPv6 server runs on the ISP router and does route
> injection based on binding state. 

The IPv6 support in ServPOET's PPPoE BMS (which I wrote last year) runs a
DHCPv6 daemon on the router itself, and simply adds a route via the PPP link
when the DHCPv6-PD occurs.

The selection of prefix comes from radius during the PPP
negotiation/authentication, and is passed "laterally" from the PPP process to
the DHCPv6 process (which is called rfc6204d, because 7208 wasn't quite out
at the time).

The amount of DHCPv6 processing required for a PPP link is remarkably small,
and I worry that I may have done too little.  Of the three CPEs that I've
tested with, one is OpenWRT BB (thanks to Stephen and Markus and the rest of
the crew) and worked great, a second locked up tight when given an IPv6 PD,
a third proclaimed "IPv6 suport" on the box, but had nothing inside.  I have
two more devices to test with: one of which requires translation from
chinese, and the fifth I got last week, and I haven't powered on yet. (Thanks Hui!)

I've been talking on and off with Tim Winters of the UNH interop lab, and at
this point it seems that they just aren't equipped with IPv6 capable CPEs
that do PPP such that visiting there makes sense.  There are some there that
do cable/ethernet-WAN, but not PPPoE WAN.

(also [email-masked] two days/week)
-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Mar 2015 16:45:03 +0100

Le 03/03/2015 19:41, Michael Richardson a écrit :
>>> I was planning on using ISC DHCP 4.3.1 together with an external
>>> script as described in https://github.com/mpalmer/isc-dhcp
>>> contrib, to detect the next hop address of my homenet router and
>>> install the relevant route for the delegated prefix on the
>>> last-hop ISP router (a Linux box).
>
>> typically the ISP router snoops DHCPv6 messages and does route
>> injection based on that, or the DHCPv6 server runs on the ISP
>> router and does route injection based on binding state.
>
> The IPv6 support in ServPOET's PPPoE BMS (which I wrote last year)
> runs a DHCPv6 daemon on the router itself, and simply adds a route
> via the PPP link when the DHCPv6-PD occurs.

If you had to do this, and if other implementations dont and break, it's
  because something has to be specified about DHCP-PD Router and Relay.
A spec must tell implementor to do it, otherwise it wont work and break.

(we wrote earlier a draft about this DHCP-PD problem that we'll be glad
to resurrect, or we'll be glad to read other drafts on same topic)

https://tools.ietf.org/html/draft-petrescu-relay-route-pd-problem-00

Alex

> negotiation/authentication, and is passed "laterally" from the PPP
> process to the DHCPv6 process (which is called rfc6204d, because 7208
> wasn't quite out at the time).
>
> The amount of DHCPv6 processing required for a PPP link is remarkably
> small, and I worry that I may have done too little.  Of the three
> CPEs that I've tested with, one is OpenWRT BB (thanks to Stephen and
> Markus and the rest of the crew) and worked great, a second locked up
> tight when given an IPv6 PD, a third proclaimed "IPv6 suport" on the
> box, but had nothing inside.  I have two more devices to test with:
> one of which requires translation from chinese, and the fifth I got
> last week, and I haven't powered on yet. (Thanks Hui!)
>
> I've been talking on and off with Tim Winters of the UNH interop lab,
> and at this point it seems that they just aren't equipped with IPv6
> capable CPEs that do PPP such that visiting there makes sense.  There
> are some there that do cable/ethernet-WAN, but not PPPoE WAN.
>
> _______________________________________________ homenet mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/homenet
>