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
signature.asc
Description: Message signed with OpenPGP using GPGMail
