Are we going down the path of defining a generic solution to signalling at the network layer with implications to upper layers of the stack? We have ICMP for signalling, yes, but it sounds like we want to define some properties for this signalling protocol which go beyond the wire-protocol details of an ICMP type/code?
Perhaps such a solution would be useful to the internet at large? From Yari's email, WIreless network operators want it. We've heard that fixed network operators want it. And clearly wireless access point operators want it. Are we doing the signalling solution a disservice by considering it only from the perspective of a standard coffee shop/hotel/airport captive portal? Should we instead be thinking about a larger picture? That is, do we need to define a more generic protocol, one of whose uses is signalling a closed/pending closure captive portal? If we need to define a generic protocol like this, is capport the proper working group? On Wed, May 30, 2018 at 5:01 PM David Bird <dbird= [email protected]> wrote: > Some important questions asked... > > FWIW, using ICMP for notification would work for LTE just like WiFi. The > PCEF enforcing the walled garden (e.g. Dropping packets) is in a good > position to respond with the appropriate ICMP (which it may or may not > already be doing; responding with regular Dest-Unreach/Filtered). > Configuring the Portal URL, on the other hand, needs defining in the > absence of DHCP -- for which we could require the IPv6/RA approach. > > I hope we don't go down the road of thinking UEs should be connecting > directly to PCRF like policy engines... > > > On Wed, May 30, 2018 at 1:34 PM Martin Thomson <[email protected]> > wrote: > >> Hi Folks, >> >> Jari has been pretty heavily involved in the 5G effort, and provided >> the IAB this summary of the captive portal situation in 5G (and >> predecessors). I thought that it might be useful input to the work >> here. And maybe another reminder that it's not just WiFi we have to >> think about. >> >> ---------- Forwarded message --------- >> From: Jari Arkko <[email protected]> >> Date: Thu, May 31, 2018 at 5:20 AM >> Subject: Re: [IAB] user notification from the network/captive portals >> To: Martin Thomson <[email protected]> >> Cc: Internet Architecture Board <[email protected]> >> >> >> Slightly edited. Feel free to forward. >> >> ————— >> >> At the IAB retreat we talked about various challenges around the >> Internet protocol stack and architecture, including, for instance, >> path signals from end points to devices on the path, and notifications >> from the network to users. Network notifications often show up to end >> users as annoying captive web portal actions, although had they been >> designed better, such notifications might offer benefits in terms of >> advising users about what connections work well or cost least. I was >> asked to discuss the state of user notifications in mobile networks. >> The question was whether we see changes in the mobile network space >> that would either demand or enable the creation of versatile >> notifications from the network, beyond the WLAN-style captive web >> portals. >> >> Here’s the situation as I see it. >> >> While captive portals are occasionally used in mobile networks, they >> are less common and used in different ways than in wireless LANs. In >> wireless LANs captive portals are used as an authentication scheme or >> as acceptable usage policy/agreement mechanism. These are not commonly >> needed in mobile networks. Given mobile network authentication >> mechanisms, there is no need for repeated use of a captive portal >> every time the user arrives in the network. >> >> In mobile networks, network notifications typically focus on either >> initial account configuration, depletion of prepaid usage, warnings >> related to usage limits, or cost and roaming related notifications. >> Much of this is handled as SMSes, some of it is handled in special >> applications, but there are cases (particularly with depleted prepaid >> SIM cards) that lead to turning a captive portal on. >> >> A large fraction of the mobile network usage is provisioned as >> subscriptions rather than pre-paid usage, which reduces the need for >> configuration and top-up acftions. In addition, over time, both >> subscription-based and prepaid SIM cards have become more readily >> usable without any user action, reducing the need for initial >> configuration step. >> >> While the issues with captive portals are not as severe in wireless >> LANs, there certainly are issues. SMS-based mechanisms are often >> unreliable in roaming situations, and some devices (such as Apple >> iPads) are incapable of handling them. SMS is also only usable for >> notification, not for rectification of any issues. Just like in >> wireless LANs, captive portal solutions are often imperfectly >> implemented and have issues on different types of equipment and >> browsers. Applications other than browsers generally cannot recognise >> what to do with captive portals. Although in recent years operating >> systems have become better in recognising when network connectivity is >> actually available, so while applications may not be too confused >> about the situation, they will still be unable to get any >> connectivity. Similarly, devices other than those managed by a human >> (or a human paying attention) will be unable to deal with these >> conditions at all. Imagine a sensor device trying to reload more money >> to an account or accepting the new GDPR privacy rules presented in a >> web page. >> >> Part of the problem stems from architecture of access network stacks >> across several types of networks. There’s rarely a concept for >> powerful communication between the parties, beyond setting up the >> technical details of a connection. And where such communication >> mechanisms have been designed, they have not been present from day one >> in those networks, so it is difficult to rely on their existence. >> >> Does 5G change something with respects to mobile networks and captive >> portals or user notifications? While 5G is a re-design of many aspects >> of mobile networks, the changes to the user equipment - network >> signalling interface are relatively conservative, and have more to do >> with changes to the radio interfaces than fundamental redesign of the >> capabilities. Other parts of the 5G system have been redesigned in >> more significant manner. For instance, the Diameter-based 4G core >> network signalling has been replaced by web-based APIs in 5G core. The >> goal of this change is to enable a more service-based, flexible design >> that employs technologies used broadly in the IT world. >> >> With 3GPP nearing the completion of the first specification release >> for the entire 5G system, in my opinion significant further changes in >> the user equipment - network interface or new user notification >> functionality are unlikely. However, the same motivations that drove >> the redesign of the 5G core signalling mechanisms could also drive >> flexible/service-based interfaces elsewhere in the system. It is >> possible that future generations will introduce flexibility in the >> user equipment - network or user - network interface, and as a part of >> that, additional user notification functionality is one possible >> development area. >> >> Jari >> >> _______________________________________________ >> Captive-portals mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/captive-portals >> > _______________________________________________ > Captive-portals mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/captive-portals >
_______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
