> -----Original Message----- > From: mif-boun...@ietf.org [mailto:mif-boun...@ietf.org] On Behalf Of > Ted Lemon > Sent: Monday, February 04, 2013 9:35 PM > To: GangChen > Cc: mif; draft-ietf-mif-happy-eyeballs-extension > Subject: Re: [mif] DNS selection with HE-MIF > > On Feb 4, 2013, at 11:02 PM, GangChen <phdg...@gmail.com> wrote: > > I can't comment on benefits of "doing DNS queries within one > > provisioning domain, and then using the results in the other > > provisioning domain." But HE-MIF has to do in some cases, because that > > maybe a normal node behavior, like stated in RFC6418 "A node usually > > has a node-scoped routing table". This issue may retrospect to basic > > Internet host design in RFC1122. Changing the model would go beyond > > HE-MIF scope. > > Okay, so your point is that we can't do connections within a > provisioning domain, because we don't have control over how a connection > is routed. > > I agree that this is a problem, but it is explicitly within the scope of > the MIF charter to consider this problem and document it. It is quite > likely the case that solving the problem is outside of the current MIF > charter, and that such work, if attempted, ought not to occur in MIF. > > However, if in fact the HE-MIF document can't work correctly without > solving this problem, then it is certainly within the scope of the > current charter for the MIF working group to draw that conclusion. > > For my part, what I am saying is that HE-MIF can't really be very useful > without solving this problem. It is not in fact the case that a MIF > node can have a single node-scoped routing table and still succeed in > communicating on the network in the face of, for example, an interface > that's connected to a captive portal but providing a default route, as > such captive portals typically do.
The technique used by both Apple and Microsoft is, when joining a new network, to attempt to retrieve a certain URI. Microsoft's procedure is described in http://technet.microsoft.com/en-us/library/cc766017%28v=ws.10%29.aspx, which queries www.msftncsi.com and needs to see 131.107.255.255 as the answer, and then does an HTTP GET. If anything is abnormal, it assumes there is a proxy on the path. Apple does something similar by attempting to retrieve https://www.apple.com/library/test/success.html. Unfortunately, this seems the best technique available to detect such DNS interception and HTTP interception proxies that force a login or force a click-through. For MIF -- not just HE-MIF, but all of MIF -- we should not declare an interface "up" until such a validation succeeds. It is unfortunate this is not solved at layer 2, where it arguably belongs. -d _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
