> > The separation of "configuration" and "notification" is by design.
> That might be a design error. Notification is done by the provider, but configuration (how to react
> on e.g. icmp unreachable) is up to the enduser. The provider cannot (and will not) configure
> any customer's client device. Maybe the CPE can be (pre-)configured (cable-modem/dsl-router) but
> not the home-PC. How do I tell the home-PC to open up a specific URL when capport
> detection gets activated (if it would exist)?
The url is not included in the icmp payload as it would introduce a ddos security risk.
Good point. In the home-network realm, advertising the url using dhcp would also require the CPE to propagate this url to the home network. I agree this would be challenging.
Maybe we can learn/inspire from the “Proposals to discover Provisioning Domains” draft that was shared with this wg earlier this year (https://tools.ietf.org/html/draft-bruneau-pvd-00 ; note it has been replaced). This draft tackles a similar problem, discovery of the configuration url. In this draft the authors define in chapter 3, they could retrieve what they required by using the “Fully Qualified Domain Name which belongs to the network operator” (chapter 3). And later (4.2) they specify a fixed location where this information can be fetched. Maybe we can use a similar approach. If the UE doesn’t have the url as it would have been advertised in the dhcp, retrieve some config from a fixed url based on the fqdn that belongs to the operator?
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature