DHCPv6 relay with PD

[Ole Troan]

Nick,

>> It shouldn't be the IETF's job to tell people how to run their networks.
>> The IETF provides the building blocks.
> 
> Take a DHCP server, an ISP access router and a CPE.
> 
> The CPE connects to the ISP access router and issues a dhcp request.
> This is relayed by the access device to the dhcp server which replies to
> access device with a PD reply.  The access router relays this reply to
> the CPE.
> 
> At this point, the state is that both the CPE and the dhcp server know
> the delegated prefix, but the access router does not.  The result is
> that the customer's prefix is not routed to the CPE.
> 
> The question is: how do we make this work so that PD is a viable
> mechanism for handling customer ipv6 requirements?
> 
> The ISP operator cannot listen to the CPE if it's running a routing
> protocol because the access router has no way of determining whether any
> announcement it receives from the CPE is a legitimate announcement,
> because it has no knowledge of what is or isn't assigned to a particular
> customer.
> 
> Installing static routes on the access router is non-scalable and
> constrains the network architecture in a way which isn't feasible.
> 
> It might work if the access router implements dhcpv6 snooping, but the
> isp operator has little or no control over this.
> 
> I know you're not trying to be unhelpful here, but brushing this off as
> someone-else's-problem is not going to make the problem go away.  Nor is
> claiming that this is a problem with how the network is run, because
> this isn't a problem that operators can feasibly fix because it's a
> problem that vendors need to solve, potentially helped with some
> guidelines from the ietf.

oh absolutely agree, I didn't mean to imply that this was a problem caused by operators.
I was more trying to say: "unfortunately snooping is the best we've got, and that's pretty obvious how to do, since vendors have done it for IPv4 for decades". I can't imagine vendors aren't supporting it for the reason that they don't understand how to implement it.
given how butt ugly snooping is though, it's probably a mechanism that the IETF wouldn't be too keen on specifying.

there are a lot of problems with snooping. inferring state as a man in the middle isn't easy. which is why RFC3633 only species PD for a client directly connected to a server. in the first implementation I worked on, we would then do a RADIUS lookup to get the prefix and install route. that's a lot easier to do acting as a server.

how do you want it to work?

cheers,
Ole
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20160608/6d6af926/attachment.sig>