Geopriv WG James Polk Internet-Draft Marc Linsner Expires: October 23, 2009 Allan Thomson Intended Status: Standards Track (PS) Cisco Systems Updates: RFC 3825 (if published) April 23, 2009 An Update to the Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information draft-polk-geopriv-3825-update-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 23, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document updates RFC 3825 (Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information) to allow versioning, and proposes changes that enable the ability to express confidence and uncertainty values as an alternative to expressing bits of resolution. Polk, et al. Expires October 23, 2009 [Page 1] Internet-Draft DHCP Geo Option Update April 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Versioning in DHCP Option . . . . . . . . . . . . . . . . . . 3 3. Replacing Resolution Fields with Confidence and Uncertainty . 4 4. What to do with RFC 3825's Appendix . . . . . . . . . . . . . 5 5. Security considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 5 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. 1. Introduction Rough consensus from the community has motivated this document to propose an update RFC 3825 (Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information) to account for versioning. The reason for this is the feeling that the resolution bits are better served expressing other data, such as confidence and uncertainty. The DHCP Option (123) in RFC 3825 [RFC3825] is only 17 bytes in length, and there are no reserved bits to assign, therefore anything added needs to take bits - or entire fields - from something already assigned in the existing Option. This proposal borrows an idea from [ID-3825bis] of reassigning the resolution fields into confidence and uncertainty fields. The most obvious place to steal bits from outside of the resolution bits is from the 8 bit datum field. Currently, there are 3 datums IANA registered. It is foreseen that few others will be necessary. Therefore, this appears to be a logical place to steal bits. At issue is the number of bits to be used for this purpose. In an effort to accommodate other specifications that utilize the Option defined by RFC3825, these additions do not force changes to those specifications. Specifically, IEEE 802.11k and 802.11y refer to RFC3825. To ensure compatibility with those specifications and the original RFC3825, we have to look for what can accommodate each specification. Polk, et al. Expires October 23, 2009 [Page 2] Internet-Draft DHCP Geo Option Update April 2009 While 802.11k has not changed the datum field from that in RFC 3825, 802.11y has. 802.11y, in 2008, reduced the number of datum bits from 8 to 3 bits [IEEE.11y], shown here: 0 7 0 3 4 5 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | Datum | ---> |Datum|1|2|3|res| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ Datum field in Five new fields in .11y RFC 3825 from that in RFC 3825 802.11y have additionally assigned the middle 3 bits as individual flags, and have left the 2 most significant bits (MSB) as "reserved". In an effort to provide harmony, this proposal specifically does not make use of the bits reassigned in the IEEE specification. Future revisions of this specification may be in conflict with the IEEE specification and will be re-evaluated at that time. So, supporting the IEEE, this specification utilizes the 2 MSB to declare a version value. This leaves 4 possible versions, where version 1 is defined by RFC 3825. Version 2 is defined here. Section 2 of this document discusses versioning in more detail. Section 3 discusses how the resolution bits are reassigned into confidence and uncertainty fields in version 2 (RFC 3825 is to be considered version 1). Section 4 discusses what to do with RFC 3825's appendix in this and subsequent versions of Option 123. 2. Versioning in DHCP Option 123 This proposal concludes the best bits to steal are from the existing 8 bit datum field, the described in RFC 3825 Option format. This document proposes the IETF adopt conformance with the IEEE in this case by only having the ability to have 4 versions of Option 123, from the 2 MSB (on the left). This would look like this: 0 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | Datum | ---> |Datum| res |ver| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ Datum field in field split into 3 RFC 3825 separate field in This preserves compliance with existing .11y implementations and definitions, and yields the DHCP the ability to have 4 versions of this Option. The middle 3 bits (specifically bits 3, 4 and 5) are proposed to be newly classified as "reserved". This aligns with 802.11y, and allows Polk, et al. Expires October 23, 2009 [Page 3] Internet-Draft DHCP Geo Option Update April 2009 the IETF and IEEE to work out how to encroach into this space in the future for, perhaps, more datum space, or more versioning space, or something entirely different. [Editor's note: These 3 reserved bits are not set as mandatory within this proposal.] 2.1 Backwards Compatibility with Option 123 Version 1 Version 2 and later implementations will remain backwards compatible as long as they use each field assigned in RFC 3825 as is described in that document. If a version 1 client uses a datum not defined within RFC 3825, it will not parse the content properly. To date, no new datums have been assigned to the IANA registry for this datum field, therefore this has always been the case. This likely will cause an error by the client. Version 1 implementations that receive a version 2 Option, for example with WGS84 as the datum, will not receive the expected field value of 1, shown here: 0 7 +-+-+-+-+-+-+-+-+ |1 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+ Version 1 but that of 65, shown here: 0 7 +-+-+-+-+-+-+-+-+ |1 0 0 0 0 0 1 0| +-+-+-+-+-+-+-+-+ Version 2 3. Replacing Resolution Fields with Confidence and Uncertainty It is best at this point to merely review what is written in [ID-3825bis] for the specifics on what could go here. [Editor's note: we authors do not have permission, based on RFC 5378, to copy the text from [ID-3825bis] at this time. That text is probably the best available to suit this section, and we want to avoid attempting to rewrite that text.] 4. What to do with RFC 3825's Appendix In version 2 and later of Option 123, readers SHOULD simply ignore Polk, et al. Expires October 23, 2009 [Page 4] Internet-Draft DHCP Geo Option Update April 2009 the appendix from RFC 3825. Without the resolution fields, that appendix serves no purpose. 5. Security considerations There are no additional security considerations outside those written in RFC 3825. 6. IANA considerations This document does not have any IANA actions (at this time). 7. Acknowledgments Your name here... or if you contribute a fair amount of text, you can be a co-author. 8. References 8.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004 [ID-3825bis] M. Thomson, J. Winterbottom, "Dynamic Host Configuration Protocol Option for Geodetic Location Information", "work in progress", Jan 2009 [IEEE.11y] IEEE Std 802.11y, March 2008 8.2. Informative References none Authors' Addresses James Polk 3913 Treemont Circle Colleyville, Texas, USA +1.817.271.3552 mailto: jmpolk@cisco.com Polk, et al. Expires October 23, 2009 [Page 5] Internet-Draft DHCP Geo Option Update April 2009 Allan Thomson Cisco Systems, Inc. San Jose, California, USA Email: althomso@cisco.com Marc Linsner Cisco Systems, Inc. Marco Island, Florida, USA Email: mlinsner@cisco.com Polk, et al. Expires October 23, 2009 [Page 6]