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

[Mark ZZZ Smith <[e-mail]>]

Hi Ted,


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

On Mar 16, 2015, at 8:41 PM, Mark ZZZ Smith <[e-mail]> wrote:
> 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.
> 
> 
> / 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).

Can you suggest a clarification that makes sense to you?


/ 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.

> 
>> 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.
> 
> / 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'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.

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).

>> 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.
> 
> / 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 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.

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.

/ 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.


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!

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

Regards,
Mark.