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

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

Hi Ted,



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

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


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

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


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

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