[dhcwg] Proposed resolution to DNA Issue 10: Strong vs. Weak hints

[Bernard Aboba <[e-mail]>]

The DNA issues list is available at:
http://www.drizzle.com/~aboba/DNA/dnaissues.html

The text of DNA issue 10 is enclosed below.  The proposed resolution is as
follows:

Change Appendix A to the following:

"Appendix A - Hints

   In order to assist in IPv4 network attachment detection, information
   associated with each network may be retained by the host.  Based on
   IP and link-layer information, the host may be able to make an
   educated guess as to whether it has moved between subnets, or
   remained on the same subnet.  If the host is likely to have moved
   between subnets, it may be possible to make an educated guess as to
   which subnet it has moved to.  Since an educated guess is not the
   same as certainty, prior to concluding that the host remains on the
   same subnet, a reachability test MUST always be performed.

   IPv4 ICMP Router Discovery messages [RFC1256] provide information
   relating to prefix(es) available on the link.  A host may use this
   information to conclude that an advertised prefix is available;
   however it cannot conclude the converse -- that prefixes not
   advertised are unavailable.

   For networks running over PPP [RFC1661], IP parameters negotiated in
   IPCP provide direct information on whether a previously obtained
   address remains valid on the link.

   On IEEE 802 [IEEE802] wired networks, hints include link-layer
   discovery traffic as well as information exchanged as part of IEEE
   802.1X authentication [IEEE8021X].

   Link-layer discovery traffic includes Link Layer Discovery Protocol
   (LLDP) [IEEE8021AB] traffic as well as network identification
   information passed in the EAP-Request/Identity or within an EAP
   method exchange, as defined in EAP [RFC2284bis].

   For example, LLDP advertisements can provide information on VLANs
   supported by the device.  When used with IEEE 802.1X authentication
   [IEEE8021X], the EAP-Request/Identity exchange may contain the name
   of the authenticator, also providing information on the potential
   network.  Similarly, during the EAP method exchange the authenticator
   may supply information that may be helpful in identifying the network
   to which the device is attached.   However, as noted in [RFC3580], it
   is possible for the VLANID defined in [IEEE8021Q] to be assigned
   dynamically, so this static information may not prove definitive.

   In IEEE 802.11 [IEEE80211] stations provide information in Beacon
   and/or Probe Response messages, such as the SSID, BSSID, and
   capabilities, as well as information on whether the station is
   operating in Infrastructure or Adhoc mode.  As described in
   [RFC3580], it is possible to assign a Station to a VLAN dynamically,
   based on the results of IEEE 802.1X [IEEE8021X] authentication.  This
   implies that a single SSID may offer access to multiple VLANs, and in
   practice most large WLAN deployments offer access to multiple
   subnets.

   Thus, associating to the same SSID is a necessary, but not
   necessarily a sufficient condition, for remaining within the same
   subnet: while a Station associating to the same SSID may not
   necessarily remain within the same subnet, a Station associating to a
   different SSID is likely to have changed subnets.

   Since the SSID is a non-unique identifier, and SSIDs such as
   "default", "linksys" and "tsunami" are advertised by default in
   various products, detection of these "default SSIDs" is not
   sufficient for a host to conclude that it has remained on the same
   subnet.  It is recommended that before detecting a match to a
   "default SSID" that the BSSID also be checked before concluding that
   the host remains on the same subnet.

   In order to provide additional guidance on the subnets to which a
   given AP offers access, additional subnet-related Information
   Elements (IEs) have been proposed for addition to the IEEE 802.11
   Beacon and Probe Response messages.  As noted earlier, VLANs may be
   determined dynamically so that these information elements may not be
   reliable."

-----------------------------------------------------------------
Issue 10: Strong vs. Weak hints
Submitter: Bernard Aboba
Submitter email address: [e-mail]
Date first submitted: November 10, 2003
Reference:
Document: DNAv4-04
Comment type: T
Priority: S
Section: Appendix A
Rationale/Explanation of issue:

The distinction between "strong" and "weak" hints is not entirely
clear to me. I think that the distinction does not affect protocol
operation -- it's just affects the likelihood of success.

For example, if there is any chance that a hint is not definitive, then
the host needs to do a check anyway (such as a reachability test or
a DHCPREQUEST). So behavior doesn't really change based on hint
strength.

The specification should say this. It's unclear now.



_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg