Subject: RA extension review requested for draft-wkumari-dhc-capport

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Mar 2015 12:29:43 -0500

This document proposes adding a new RA extension to support indication of the presence of a captive portal to nodes using a particular advertised router.   Review would be appreciated.

http://datatracker.ietf.org/doc/draft-wkumari-dhc-capport/

Thanks!

---

From: Bob Hinden <[email-masked]>
Date: Wed, 4 Mar 2015 13:04:37 -0800

Ted,

I read the draft and it seems reasonable to me.  It is clearly written and the RA option itself seems straightforward.  I too have been stuck behind captive portals that didn’t work.

I encourage the 6man w.g. to review it and speak up if you have comments (pro and con).

Bob

> On Mar 4, 2015, at 9:29 AM, Ted Lemon <[email-masked]> wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 5 Mar 2015 00:58:43 +0000 (UTC)

Hi,

I understand the problem, and have implemented a captive portal myself in the past at a broadband ISP (via allocating private addresses and wildcard DNS views for queries with those source addresses), however it still feels like a hack for the sorts of reasons mentioned on the draft.

A few initial thoughts:

- I think it is relying on a few unstated assumptions:

o that the receiving device is single homed, downstream of the IPv6 router/DHCPv6 server supplying the Captive Portal option
o the protocol being used for the reachability status and Captive Portal is HTTP (hence supplying a URI)
o that the receiving device provides a quite capable interactive user interface where text/numbers can be entered (e.g., computer screen/a web browser). 

Regarding single homing, what happens if the host is multi-homed, with one connection captive and the other not (e.g., Smartphone with Wifi captive and 3G not)? It seems to me that the user might have two alternative choices - they either choose not to use not to use the CP limited Wifi, continuing to use their 3G connection for Internet access, or they may choose to validate/authenticate to the Wifi because Wifi access is cheaper/better. In the first case, the Wifi interface being 'trapped' in a captive portal should not interfere with the use of the 3G connection, which means that the presence of a CP option received over the Wifi interface should not be blindly obeyed by the device's web browser, preventing the use of the 3G connection.

Hmm, thinking about this further, limited reachability is really an attribute of a device's interface, rather than an attribute of a 'whole of device' application such as web browser. A web browser is probably a good way to provide a UI to resolve the issue of an interface having limited reachability because it is common, however I don't think the general use of the web browser should be constrained by the limited reachability of one of the host's interfaces.

It might also be worth considering/discussing multi-pathing e.g. MPTCP. Apple IOS 7 supports it and uses it for Siri, I understand it is now supported in OS X, and a while back Facebook were hiring Linux kernel hackers with MPTCP being one of the skills they were looking for (I thought it would be Google who'd do MPTCP first - 
http://www.users.on.net/~markachy/The_Rapid_Rise_of_the_MMHH.pdf). Perhaps in the future MPTCP will also be used for web browsing.

Regarding use of HTTP and a interactive user interface, I think there are going to be more and more devices that might receive this option that either don't need to speak HTTP, don't want to use a web browser to display the limited connectivity (e.g., a bottom screen network interface status icon), don't have a capable enough user interface to present the chosen Captive Portal interface at the provided URI (e.g., a few coloured LEDs, a small single line alphanumeric display, or don't have a user interface at all (an IoT device)).

So I think there are really two problems to be solved:

- indicating to a host that there is limited reachability over one of its interfaces

- indicating to the host's operator that limited reachability over one of its interfaces in a way that is appropriate to the capabilities of the receiving device

To solve the first problem, it is probably enough to have a simple DHCPv6 or RA option that indicates limited reachability. 

The receiving device could then use its protocol/method of choice suitable to its capabilities to attempt to access a status service at a IANA defined well known IPv6 address, or perhaps at an address provided in the DHCPv6 or RA option.

For example, if a web browser is providing the UI to deal with the issue, it issues a GET / to that address, displaying the result (e.g., the captive portal user interface). A device with a much more limited UI might use a different protocol to get status information e.g., a protocol just to determine if an status LED should be set to green or red, or to get the single line of short text to display. More broadly, I think this means that dealing with the limited connectivity problem is device implementation and capability dependent, although there could be some ways specified for how to do it for common protocols e.g., HTTP.

Since RAs are required for off-link connectivity, perhaps the way to achieve the above would be to initially send RAs to the captive device with a 0 value Router Lifetime (RFC4861, "A Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default router list."), and a RFC4191 Route Information Option with a /128 for the status IPv6 address (which could be a link-local if the status service/Captive Portal is on-link). If the device authenticates/validates successfully (e.g., via a HTTP and a Captive Portal at the RIO supplied /128), a new RA is sent to the device with a non-0 Lifetime and the RIO removed. Using this method, I think a DHCPv6 option might not be necessary, or perhaps DHCPv6 options might be used to provide protocol specific information e.g., the Captive Portal URI to use if the reachability test protocol is HTTP (e.g. instruction to use HTTPS instead of HTTP, and a client specific URI rather than the generic "GET /").

RA RIOs might be a bit too generic, as multiple can appear in an RA, so perhaps a RA "Limited Reachability" Option that can appear only once in an RA might be better.

Regards,

Mark.

----- Original Message -----
From: Bob Hinden <[email-masked]>
To: Ted Lemon <[email-masked]>
Cc: IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
Sent: Thursday, 5 March 2015, 8:04
Subject: Re: RA extension review requested for draft-wkumari-dhc-capport

Ted,

Bob

---

From: Ted Lemon <[email-masked]>
Date: Thu, 5 Mar 2015 08:08:08 -0500

> o that the receiving device is single homed, downstream of the IPv6 router/DHCPv6 server supplying the Captive Portal option

I raised the same issue with multiple interfaces in my doc shepherd review, and the new version addresses that point; I'd be curious to know if you have additional text to suggest, or if you are satisfied with the changes.

> o the protocol being used for the reachability status and Captive Portal is HTTP (hence supplying a URI)

URIs are not http-only, although I tend to agree that http is the likely transport.

> o that the receiving device provides a quite capable interactive user interface where text/numbers can be entered (e.g., computer screen/a web browser). 

I think the answer here is that the receiving device will likely only be able to authenticate to the captive portal if it has a UI or else if some new mechanism is provided that supports automatic authentication.   However, the target for this particular document is devices with user interfaces, not IoT devices, so I think within that realm we are okay.   Perhaps the document should be clearer on this point.

I think that the amount of work that would be required to define a mechanism for automatic authentication is really substantial, and would have limited value: we don't even know if captive portal folks will implement this very simple mechanism.   So I think that should be out of scope for this document.   The presence of the URI option already indicates that a captive portal is present, so IoT devices that recognize this option can avoid using the captive interface.

I think the discussion of multipath and other mechanisms is also out of scope, and is more appropriate in the context of multiple provisioning domains.   If you are interested in that topic, it's being worked on in the MIF working group.   The latest version of Android has a preliminary implementation of what is described in the MPvD architecture document (http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/).

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 17 Mar 2015 00:41:04 +0000 (UTC)

Hi Ted,

Sorry not to get back to you sooner.
----- Original Message -----
From: Ted Lemon <[email-masked]>
To: Mark ZZZ Smith <[email-masked]>
Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Sent: Friday, 6 March 2015, 0:08
Subject: Re: RA extension review requested for draft-wkumari-dhc-capport

/ That wasn't obvious to me, and I find that the abstract and introduction, which set the context for the rest of the document, implied to me that the device was single homed by using the term "behind" (I'd even interpret that a multihomed device being described as "behind" a captive portal means that all of its interfaces are downstream of the captive portal).

/ My first concern was that encoding URIs in RAs means that this option could be pretty large.

/ I'm also of the view that RAs should only contain subnet specific network layer configuration information, as I described in section 2, "Internet Transparency and Application Configuration" of "IPv6 CE Device DHCPv6 Option Transparency" (https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2). I think describing a limited network reachability prefix via RA options to a host, and then letting the host decide what to do with that information is consistent with using RAs to describe subnet specific network layer configuration information.

/ More basically, I think encoding application or application class parameters in RAs is a layer violation.
/ I think DHCPv6 is a better place for larger options that are application specific or application-class specific (i.e., layer 4+ options), such as URIs.

/ It seems to me that solutions to problems should be made as general as possible. In this case, I think there are really two problems (a) indicating to a device that one of its interfaces has limited reachability (which may be its only external interface) and (b) indicating to the device operator that their is limited reachability and possibly providing methods of resolving that if desired. They seem to me to be separate problems that are occurring at different layers in the stack.

I think the discussion of multipath and other mechanisms is also out of scope, and is more appropriate in the context of multiple provisioning domains.   If you are interested in that topic, it's being worked on in the MIF working group.   The latest version of Android has a preliminary implementation of what is described in the MPvD architecture document (http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/
).

/ I haven't really had time to look at the MIF work although it interests me. One perspective is that a single interface host could be considered to be a special case of a multiple interface  host (although if you include loopback, most if not all hosts are multihomed), so if MIF solve this problem for multiple interface hosts then the solution would also be applicable to single interface hosts.

Regards,
Mark.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Mar 2015 21:51:43 -0400

> / That wasn't obvious to me, and I find that the abstract and introduction, which set the context for the rest of the document, implied to me that the device was single homed by using the term "beh…

Can you suggest a clarification that makes sense to you?

> / My first concern was that encoding URIs in RAs means that this option could be pretty large.

OK.   The RA I'm getting from Comcast at the moment is 96 bytes, so I think there's enough headroom to accommodate a short captive portal URI.   Maybe you could explain how this is going to be a problem in practice?   Remember that we're talking specifically about the captive portal use case, so it's not the case that this is going to be a network with a large number of prefixes or that is going to offer a long domain name search list.

> / I think DHCPv6 is a better place for larger options that are application specific or application-class specific (i.e., layer 4+ options), such as URIs.

I don't think you are making a meaningful distinction.   Both DHCP and ND are layer 7 protocols, and ND provides configuration information such as DNS server IP addresses and domain name search lists, to which your objection would also apply.   So we are not treading new ground here, as far as I can tell.   And the information being provided is specific to the link to which the host is attached.

> / It seems to me that solutions to problems should be made as general as possible. In this case, I think there are really two problems (a) indicating to a device that one of its interfaces has limi…

I think that if you want to propose a solution to the larger problem, that's great, but you haven't proposed a competing solution.   The problem this document addresses causes serious operational issues that have nothing to do with, e.g., IoT devices.   E.g., my mom is in a nursing home undergoing rehab for a knee operation right now, and every time she has to authenticate to their captive portal, she has to click through several warnings in her browser because the captive portal has to lie to capture her browser.   This proposal eliminates that problem.   This is a big deal.

So while you certainly have a point that there is a larger problem to solve here, given that no proposal to solve it has, as yet, surfaced, I don't think you've actually given a reason why we shouldn't proceed with address the more restricted use case that we actually can address.

So the main action item I'm taking away from this review, with respect specifically to Warren's document, is that we should tweak the abstract to be more clear.   If you have text to suggest that would be great.   Otherwise I'll confer with Warren and see if we can come up with something.   Thanks very much for the thorough review!

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 18 Mar 2015 04:28:18 +0000 (UTC)

Hi Ted,

----- Original Message -----
From: Ted Lemon <[email-masked]>
To: Mark ZZZ Smith <[email-masked]>
Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Sent: Tuesday, 17 March 2015, 12:51
Subject: Re: RA extension review requested for draft-wkumari-dhc-capport

/ I think it is more structural than just a clarification, meaning that the topic of multihomed/multi-interface hosts needs to be specifically dealt with. Think smartphones to make the problem less abstract, as at least here in Australia, they've recently become the most commonly used Internet access device.

> / My first concern was that encoding URIs in RAs means that this option could be pretty large.

OK.   The RA I'm getting from Comcast at the moment is 96 bytes, so I think there's enough headroom to accommodate a short captive portal URI.   Maybe you could explain how this is going to be a problem in practice?

   Remember that we're talking specifically about the captive portal use case, so it's not the case that this is going to be a network with a large number of prefixes or that is going to offer a long domain name search list.

/ So if we assume this is the first of likely to be many RA options that are encoding application level parameters 
(arguably it would be the second, because DNS IP addresses too are greater than layer 3 parameters), then many RA options with possible large payloads could be a problem. 

/ It seems there is confusion between what is supposed to into RAs and what is supposed to go into DHCPv6 options, and the way people are addressing this confusion is to try to put it in both. In this scenario, if the local router is supposed to provide the captive portal URI, then I would think it should be being provided by a local state or stateless DHCPv6 server on the router.

> / I think DHCPv6 is a better place for larger options that are application specific or application-class specific (i.e., layer 4+ options), such as URIs.

I don't think you are making a meaningful distinction.   Both DHCP and ND are layer 7 protocols, and ND provides configuration information such as DNS server IP addresses and domain name search lists, to which your objection would also apply.

/ I don't agree that ND is a layer 7 protocol, as it's reachability is limited to a single link. It cannot traverse multiple links, and therefore isn't end-to-end. DHCP can be made to traverse multiple links via DHCP relays that are DHCP option transparent, so DHCP is close to an end-to-end layer 7 protocol.

/ At the risk of telling you about something you already know about, I think that the most valuable property of the Internet architecture is that the network is application transparent or agnostic. The network doesn't (or shouldn't) create barriers to deploying new applications. Applications are deployed on the end-points only, "on" or "over" the network, but not "in" the network. The network, or specifically, the routers, don't need to be upgraded to support new applications because they're oblivious to them, as they just forward packets regardless of the packets' payloads (with encryption of packet payloads forcing this transparency model).

/ To operate applications, you usually need to configure them. Manual per-host configuration is not scalable, hence application configuration automation via protocols such as DHCPv6.

/ If your network isn't automated application configuration protocol transparent, then it also isn't application transparent. The network stops you from easily configuring the application and therefore stops you from being able to easily operate the application (unless you resort to per-host manual configuration). In other words, I think the property of "application transparency" needs to include and imply automated application configuration transparency.

/ To deploy new RA options requires upgrading the routers that are to issue them. If RA options are used to convey application configuration parameters, then router upgrades are required to deploy new applications. The network is not "application transparent" any more because it isn't application configuration transparent in its current state. Successfully deploying new applications is tightly coupled to the RA options the local router implementation supports.

/ That is why I think the DNS server and domain name search RA options you mentioned are a mistake, and should not be used as an example of what are acceptable in RAs. They encourage a model of a host's ability of being able to run applications being coupled to and constrained by what options the upstream router supports in it's RAs, unless we accept pre-1980s practices (i.e., pre-Appleltalk, Novel Netware etc.) of per-host manual application configuration. 

   So we are not treading new ground here, as far as I can tell.   And the information being provided is specific to the link to which the host is attached.

/ However it also means that it wouldn't be possible to direct different clients to different captive portals based on individual client attributes. I'd think that would be a useful and probably an important capability for this sort of scenario (actually I pretty much know it is - one of the purposes of the captive portal I've put in place in the past was to suspend service to customer who's bill was overdue - presenting a client specific "pay now" button is far more user friendly that making them login via a generic web page).

> / It seems to me that solutions to problems should be made as general as possible. In this case, I think there are really two problems (a) indicating to a device that one of its interfaces has limi…

I think that if you want to propose a solution to the larger problem, that's great, but you haven't proposed a competing solution. 

/ I think I did in my first response. Use RAs to convey nothing more than limited reachability information (which probably falls under the domain of the MIF WG, and they may have already solved it), and is an attribute that would be common to all hosts receiving the RA, and may be specific to the individual router issuing the RA.

/ Make the way that information is presented to the device user up to the device implementation, best suited to the device's user interface capabilities (which may include an external log 'user interface'). Provide hints or parameters for certain UI applications via DHCPv6, such as the URI, overriding a default value or if a default value is not possible. These could be client specific if necessary or useful, matching on DUIDs or other DHCPv6 client supplied option values.

 The problem this document addresses causes serious operational issues that have nothing to do with, e.g., IoT devices.   E.g., my mom is in a nursing home undergoing rehab for a knee operation right now, and every time she has to authenticate to their captive portal, she has to click through several warnings in her browser because the captive portal has to lie to capture her browser.   This proposal eliminates that problem.   This is a big deal.

/ My motivation for writing the above draft was exactly user friendliness. I don't expect your or my mother to have to upgrade a router to be able to have automated configuration of a new application work so that they can run a new application. I've worked at residential ISPs where CPE were BYO, and there is next to no chance of router firmware being upgraded happening when getting customers to both pick good and be able to change service authentication passwords successfully is basically impossible.

/ We need to avoid as much as possible any changes to protocols that require router upgrades, like new RA options, because router upgrades are relatively hard compared to per-host incremental upgrades, usually disruptive to many hosts, and for a portion of their "operators", basically impossible.

/ DHCPv6 options are better because a router operating as a DHCPv6 relay is DHCPv6 option transparent. New DHCPv6 options can be deployed without having to upgrade routers, unless the router itself is also operating as (a host operating as) a DHCPv6 server.

/ My fundamental concern here is really about the use of RAs to convey any more than link specific IPv6 layer 3 parameters. IPv6 has given us back the possibility of network application transparency that IPv4 NAT took away. I don't want to see that application transparency taken away again by using RAs to configure applications, because of how tightly it couples application configuration to local router capabilities. That is what I think DHCPv6 is for.

/ The above probably doesn't provide what you're after, however I hope it provides some food for thought. 

Regards,
Mark.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Mar 2015 18:35:53 +0100

Hello,

Here are some comments.

I think this document is a good step in the right direction.

> In many environments, users need to connect to a captive portal
> device and agree to an acceptable use policy and / or provide
> billing information before they can access the Internet.

When describing the use-case, a notion of time could be added.  Not only
user is required to fill in and check, but sometimes s/he should do so
periodically.

> (such as coffee shops)

and onboard commercial flights and passenger trains.  All airborne and 
train WiFi deployments use captive portals.  (whereas some coffee shops 
WiFi deployments use no portal, although yes, they are more known to 
more people).

>    This document neither condones nor condemns the use of captive
>    portals; instead, it recognises that their apparent necessity, and
>    attempts to improve the user experience.

To 'condone'?  In all cases, it cites shortcomings of portals, which 
read as if some portal techniques are bad whereas other good.  E.g. it 
says "This technique has issues similar to the HTTP solution, but may 
also break other protocols, and may expose more of the user's private 
information."

If we are to describe how some portal techniques are better than others 
then I have a suggestion to avoid using URL IP addresses of the form 
2.2.2.2 for the logout button - they dont work when 
VPN-back-to-corporate is used.  Also, should use IPv6 addresses, not 
IPv4 addresses.  But I dont think the goal of the document is to 
describe how some portal techniques are better than others.

> 4.  The Captive-Portal IPv6 RA Option
>
>    This section describes the Captive-Portal Router Advertisement
>    option.
>
>     0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |     Length    |              URI              .
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               .
>       .                                                               .
>       .                                                               .
>       .                                                               .
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                Figure 2: Captive-Portal RA Option Format

Rarely I see textual ASCII in RA messages (URI is a text string,
right?). Besides, it would be limited to that 2^8 length field. Would
consider setting an IPv6 address instead, and reserve a port number? Or
other technique which sets on text in an RA.

Finally, I want to add that this option is something very useful towards
automation of connecting to a hotspot. This automation is needed by e.g.
end users in vehicles which dont have time to fill in forms while
driving through a new hotspot area.

Administratively, portal owners may be less interested in letting
through automated devices w/o splashing first the advertisement of the
day and place. On another hand, more traffic may attract more clients to
that business' other-than-wifi product. This could be grounds of service
remuneration via novel subscription plans which dont require cumbersome
form filling.

There are some software tools for end user to automate through _some_ of 
the well-known deployed WiFi portals, and they will be grately helped by 
the presence of this option.

Alex

Le 04/03/2015 18:29, Ted Lemon a écrit :
> This document proposes adding a new RA extension to support
> indication of the presence of a captive portal to nodes using a
> particular advertised router.   Review would be appreciated.
>
>  IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Dan Lüdtke <[email-masked]>
Date: Tue, 24 Mar 2015 22:54:09 +0100

Hi,

I think this option is a long waited for necessity. Not that I like captive portals. But we have been ignoring them for too long, so that we now have broken DNS, non-validating DNSSEC and strange URLs like http://1.1.1.1/index.html :/

> other technique which sets on text in an RA.

I would object using a reserved port number. I would also object using an IPv6 address instead of a URI. We most likely want to see https there, and I can not even imagine how hotels will succeed in signing IPv6 addresses as common names. They have a hard time getting their stuff right with human readable hostnames already.

If you want to play around with the option, here is the code[1]. I integrated it as an experimental option in ratools[2]. There is a blog post explaining[3] how to start.

[1] https://github.com/danrl/ratools/commit/417215bf662a5e2459cc6e9f6a5ce4e3c85ebfe9
[2] https://gthub.com/danrl/ratools
[3] https://www.danrl.de/posts/icmpv6-captive-portal-uri-option.html

Cheers!

Dan

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Mar 2015 17:47:54 -0500

Le 24/03/2015 16:54, Dan Lüdtke a écrit :
> I would object using a reserved port number.

A port number together with an IP address is a possibility, maybe not 
the best one.

It's the first thing coming to moind instead of an URI.

Have you already seen text in RAs?

> I would also object using an IPv6 address instead of a URI. We most
> likely want to see https there, and I can not even imagine how hotels
> will succeed in signing IPv6 addresses as common names. They have a
> hard time getting their stuff right with human readable hostnames
> already.

I can agree to that aspect.

But I dont understand why the RA should contain a pointer (URI or https 
address).

It could be just a bit indicating a portal is present.  Then, the client 
could search for it, using a portal discovery protocol.  Or the client 
would prefer to another network whose RA does not have that bit set.

Another possibility could be the Router Lifetime value.  If it's 0 then 
that's not a default router leading to the Internet.  This could be a 
suggestion that there is a portal, so client should discover it.  Once 
the portal is open that Router Lifetime could change to a non-0 value 
meaning it leads to the Internet and is a default router.

Another possibility is to set a prefix in the RA that says 
"2001:db8:dead:e0d::/65".  In this way no client could self configure an 
address because of that 65, so it should first discover a portal.  Once 
the portal is open the prefix would change to a /64.

I mean there could be some alternatives to setting text in RA.

> If you want to play around with the option, here is the code[1]. I
integrated it as an experimental option in ratools[2]. There is a blog
post explaining[3] how to start.
> [3] https://www.danrl.de/posts/icmpv6-captive-portal-uri-option.html

Excellent!  It looks as you control these ratools to your needs.

Alex

---

From: Dan Lüdtke <[email-masked]>
Date: Thu, 26 Mar 2015 09:51:24 +0100

Hi Alexandru,

> A port number together with an IP address is a possibility, maybe not the best one.
> 

Agreed, but then we lock in on a protocol and a port. IP:PORT alone does not make a human-usable captive portal. With a URI, we are safe for whatever comes after HTTP.

> Have you already seen text in RAs?

Sure, RFC 6106 Section 5.2.  DNS Search List Option for example.

> But I dont understand why the RA should contain a pointer (URI or https address).
> 
> It could be just a bit indicating a portal is present.  Then, the client could search for it, using a portal discovery protocol.  Or the client would prefer to another network whose RA does not have that bit set.

This is, indeed, are very interesting option. In general, with the “other managed configuration” flag we can already outsource the captive portal details do DHCPv6. I prefer networks to be able to get connectivity without DHCP at all. Not that I don’t find it useful, it is just that it violates the purism of a network protocol. If we _require_ DHCP to get connectivity in such environments, then we may end up with a IPv6-DHCPv6 protocol suite one day.

From my perspective, having a captive portal is a similar basic network characteristic as “link up/link down” or 802.1x. Both have great influence of whether or not we can get connectivity on a link. This is also why I believe that RDNSS information is best placed inside a RA. We can not call it connectivity if we can not resolve names. 

> 
> Another possibility could be the Router Lifetime value.  If it's 0 then that's not a default router leading to the Internet.  This could be a suggestion that there is a portal, so client should discover it.  Once the portal is open that Router Lifetime could change to a non-0 value meaning it leads to the Internet and is a default router.
> 
> Another possibility is to set a prefix in the RA that says "2001:db8:dead:e0d::/65".  In this way no client could self configure an address because of that 65, so it should first discover a portal.  Once the portal is open the prefix would change to a /64.
> 

This sounds like a hack to me. Furthermore, I would strongly object it because that forces the RA sending entity to keep state of  clients AND to emit different RAs to different clients.

Cheers

Dan

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 26 Mar 2015 08:33:07 -0500

On Thu, Mar 26, 2015 at 3:51 AM, Dan Lüdtke <[email-masked]> wrote:

> This is, indeed, are very interesting option. In general, with the “other
> managed configuration” flag we can already outsource the captive portal
> details do DHCPv6. I prefer networks to be able to get connectivity without
> DHCP at all. Not that I don’t find it useful, it is just that it violates
> the purism of a network protocol. If we _require_ DHCP to get connectivity
> in such environments, then we may end up with a IPv6-DHCPv6 protocol suite
> one day.
>

Also, there may be multiple routers on link, some of which provide access
via captive portal and some which don't. In that case, DHCPv6 won't be able
to provide the full picture.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Mar 2015 17:19:18 -0500

Le 26/03/2015 03:51, Dan Lüdtke a écrit :
> Agreed, but then we lock in on a protocol and a port. IP:PORT alone
> does not make a human-usable captive portal. With a URI, we are safe
> for whatever comes after HTTP.

I tend to agree.  I would question whether an URIv2 exists, but I agree
with your argument above about IP:PORT.

> Sure, RFC 6106 Section 5.2.  DNS Search List Option for example.

Ok, I forgot that.  I actually never seen it in practice.  I think it
does exist in radvd.

Currently my preferred operator is thinking a lot about how to give me
the DNS name without using DHCP, and without 464xlat.  Maybe there is a
problem there.

>>> I would also object using an IPv6 address instead of a URI. We
>>> most likely want to see https there, and I can not even imagine
>>> how hotels will succeed in signing IPv6 addresses as common
>>> names. They have a hard time getting their stuff right with
>>> human readable hostnames already.
>>
>> It could be just a bit indicating a portal is present.  Then, the
>> client could search for it, using a portal discovery protocol.  Or
>> the client would prefer to another network whose RA does not have
>> that bit set.
>
> This is, indeed, are very interesting option. In general, with the
> “other managed configuration” flag we can already outsource the
> captive portal details do DHCPv6. I prefer networks to be able to
> get connectivity without DHCP at all. Not that I don’t find it
> useful, it is just that it violates the purism of a network protocol.
> If we _require_ DHCP to get connectivity in such environments, then
> we may end up with a IPv6-DHCPv6 protocol suite one day.

As network puritanism one may also think that DNS searchlist information
(app layer) should not be present in an Internet Control Message
Protocol (net layer).  Then one may question the puritanism.

But currently we can limit to just signalling the fact that a portal is
present.  Let's see.

>> From my perspective, having a captive portal is a similar basic
>> network characteristic as “link up/link down” or 802.1x. Both have
>> great influence of whether or not we can get connectivity on a
>> link. This is also why I believe that RDNSS information is best
>> placed inside a RA. We can not call it connectivity if we can not
>> resolve names.
>
>
>>
>> Another possibility could be the Router Lifetime value.  If it's 0
>> then that's not a default router leading to the Internet.  This
>> could be a suggestion that there is a portal, so client should
>> discover it.  Once the portal is open that Router Lifetime could
>> change to a non-0 value meaning it leads to the Internet and is a
>> default router.
>>
>> "2001:db8:dead:e0d::/65".  In this way no client could self
>> configure an address because of that 65, so it should first
>> discover a portal.  Once the portal is open the prefix would
>> change to a /64.
>>
>
> This sounds like a hack to me. Furthermore, I would strongly object
> it because that forces the RA sending entity to keep state of clients
> AND to emit different RAs to different clients.

Right, it seems so.

Maybe other means?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Mar 2015 17:58:39 -0500

Le 26/03/2015 08:33, Lorenzo Colitti a écrit :
> On Thu, Mar 26, 2015 at 3:51 AM, Dan Lüdtke <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     useful, it is just that it violates the purism of a network
>     protocol. If we _require_ DHCP to get connectivity in such
>     environments, then we may end up with a IPv6-DHCPv6 protocol suite
>     one day.
>
>
> Also, there may be multiple routers on link, some of which provide
> access via captive portal and some which don't. In that case, DHCPv6
> won't be able to provide the full picture.

I agree in a sense in that a DHCPv6 server co-located with a router will
not know what the other router is doing.

On another hand, DHCP Relays in each router all connected to one DHCP
Server will be able to provide the full picture.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Mar 2015 22:50:54 -0500

> Server will be able to provide the full picture.

That's not how DHCP works!

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Mar 2015 07:57:49 -0500

> That's not how DHCP works!

Sorry - what do you mean?

You mean there wouldn't be two DHCP Relays on the same Client subnet?

Why would there be two routers on the same Client subnet in the first place?

Alex

---

From: Dan Lüdtke <[email-masked]>
Date: Fri, 27 Mar 2015 14:00:15 +0100

> Why would there be two routers on the same Client subnet in the first place?

So the clients can be multi-homed.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Mar 2015 08:08:10 -0500

> So the clients can be multi-homed.

Ok, so each router would advertise a different prefix.

In a similar way, two DHCP Relays (software present in each Router) 
would be in charge of two different prefixes, distinction visible in 
DHCP Server's conf file.

I wonder if something is wrong with it.

Alex

---

From: Dan Lüdtke <[email-masked]>
Date: Fri, 27 Mar 2015 14:12:28 +0100

> In a similar way, two DHCP Relays (software present in each Router) would be in charge of two different prefixes, distinction visible in DHCP Server's conf file.
> 

Only if both routers are from the same provider or administrative domain, right? Not sure what the direction is you want to got there, but I remember it was about “the full picture”.

Dan

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Mar 2015 08:43:07 -0500

Le 27/03/2015 08:12, Dan Lüdtke a écrit :
>> would be in charge of two different prefixes, distinction visible
>> in DHCP Server's conf file.
>>
>
> Only if both routers are from the same provider or administrative
> domain, right?

Right.

I think two non-DHCP-Relay Routers too will need to be from the same
provider or same administrative domain in order to advertise two
different prefixes on the same link.  The reason of that necessity is
that they must make sure only one of them claims (RA) to be a default
router, otherwise they will fool the Client with two default routes (a
Client uses only one default route).  That can be achieved only if they
are administered by a single entity, be that an ISP or a sysadmin.

> Not sure what the direction is you want to got there, but I remember
> it was about “the full picture”.

I am trying to say that the full picture of a network can easily include
a DHCP server(s), as much as a well-administered set of Routers sending RAs.

This full picture would be needed when conceiving how the portal
notification should be given to a client.

Suggesting not to set DHCP out of it.

Alex

---

From: Warren Kumari <[email-masked]>
Date: Fri, 27 Mar 2015 14:55:24 -0500

Hi all,

Just quickly wanted to say thanks for the comments --  I haven't done
anything useful with them yet, but will address them after the meeting
is all done, I've gotten home, etc...

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf