[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

        Internet Draft                                               T. Hain
        Document: draft-hain-ipv6-geo-addr-00.txt                      Cisco
        Expires: July 2008                                      January 2008

                                 An IPv6 Geographic
                            Global Unicast Address Format

     Status of this Memo

        By submitting this Internet-Draft, each author represents that any
        applicable patent or other IPR claims of which he or she is aware
        have been or will be disclosed, and any of which he or she becomes
        aware will be disclosed, in accordance with Section 6 of 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-

        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

        The list of Internet-Draft Shadow Directories can be accessed at

        This Internet-Draft will expire on July 15, 2008.


        This document defines an IPv6 Geographic global unicast address
        format for use in the Internet.  The address format defined in this
        document is consistent with the IPv6 Protocol [1] and the "IPv6
        Addressing Architecture" [2].  It is designed to facilitate scalable
        Internet routing when sites attach to multiple service providers, by
        using a prefix based on a geographic reference to the site. A
        natural byproduct of this address allocation mechanism is that all
        addresses are fixed allowing sites to change providers at will
        without requiring their network to renumber.

     Conventions used in this document

        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        this document are to be interpreted as described in RFC-2119 [3].

     Hain                      Expires July 2008                         1

                      An IPv6 Provider-Independent Global      January 2008
                             Unicast Address Format

     Status of this Memo................................................... 1
     Abstract.............................................................. 1
     Conventions used in this document..................................... 1
     Introduction.......................................................... 2
     Overview of the IPv6 Address.......................................... 4
     IPv6 Geographic Global Unicast Address Format......................... 5
     Examples.............................................................. 6
      Extended resolution ................................................. 7
      Interleave process detail: .......................................... 9
      Interleave examples: ................................................ 9
      Airport location examples: ......................................... 10
      U.S. postal examples: .............................................. 10
       Locations within a 600km square - New York area (~Zone)::/12
                                                                    ...... 10
       Locations within a 150km square - Miami area (~Region)::/16
                                                                   ....... 10
       Locations within a 40km square - Chicago area (~Metro)::/20
                                                                   ....... 11
       Examples of existing exchange points & potential prefixes:
                                                                  ........ 11
     A Provider Independent Multicast address format:..................... 11
     Subnet Identifier.................................................... 12
     Technical Motivation................................................. 12
     General Considerations............................................... 12
     IANA Considerations.................................................. 13
     RFC Editor Considerations............................................ 13
     Security Considerations.............................................. 13
     Appendix A:.......................................................... 13
     References........................................................... 16
     Acknowledgments...................................................... 18
     Author's Addresses................................................... 18


        This document defines a Geographic global unicast address format for
        IPv6 address allocation. The mechanism defined here breaks down the
        geographic location of the site into prefix lengths that map well
        into existing routing protocols. It is not proposing that routers
        know about geography, but that a prefix that routers know how to
        deal with be constructed out of something readily available which
        uniquely identifies a site such as the physical-media (layer-1)
        demarcation point between the public Internet and the site.

        There have been numerous diatribes about how addressing has to map
        to topology, often noting that existing topology does not map
        cleanly to geographic structure. The fundamental point being
        overlooked in these cases is that the existing topology was deployed
        to minimize the local costs at the time, yet those cost factors are
        not static so topology evolves over time. In particular, the costs
        associated with a bloated routing system are not factored into the
        historical topology.

     Hain                      Expires July 2008                         2

                      An IPv6 Provider-Independent Global      January 2008
                             Unicast Address Format

        Another assumption that is widespread is that there has to be a
        single global 'default-free-zone' (DFZ). Measured differences in BGP
        updates show this to be a fallacy, even when it is the assumed
        operating mode for the global transit providers. There are also VPN
        overlays in many BGP environments with explicitly different
        aggregate sets. In any case, while a provider aggregate (PA)
        addressing architecture should have a single global DFZ, other
        aggregate sets already co-exist so adding another will not directly
        impact the existing ones. As such the format described here is not
        about replacing the PA architecture, rather it is an additional tool
        to deal with situations that would bloat PA beyond utility.

        Specifically, this format is targeted at situations where smaller
        organizations are looking for regional multi-homing, or other
        reasons for a provider independent address block. It is assumed that
        large organizations will continue to use the same approaches they
        have to establish explicit entries in the PA DFZ, just due to their
        commercial value to the service providers. While these approaches
        are manageable for a small number of large organizations, applying
        them to a large number of small organizations will effectively
        disable the global transit routing system.

        The Geographic format described here explicitly isolates a multi-
        homed site's address prefix from the set of providers it is
        connected to. As a concession to operational simplicity, the format
        optimizes the operational issue of identifying the demarcation point
        as a direct trade-off against the known consumption of address space
        assigned to uninhabited regions of the planet. The overall goal is
        to allow efficient routing aggregation for single sites that connect
        directly to multiple providers or to metropolitan scale exchanges.
        Sites will have the choice to connect to either or both types of
        service. The details about specific site topology will be limited to
        the service providers that are making the direct connections, and
        traffic will follow the shortest path from the perspective of the
        current source.

        This format is expected to work well for organizations with multiple
        sites distributed geographically when used concurrently with address
        selection rules [4]. As each end system will select from its
        available source set the address that has the longest match with any
        particular destination, response packets from Geographic destination
        sites will naturally find the source network demarcation point with
        the public Internet that is closest to the destination site. While
        this does not assure symmetry, it does help localize any

        The basic mechanism is an Earth surface location defined by WGS-84
        [5] latitude and longitude which represents the lower left corner of
        a nominal square ~6.4m on a side (equatorial). WGS-84 was selected
        because low-cost hand-held devices with the necessary level of
        accuracy on a global scale are readily available. For the purposes
        of this document, the term square and size of the area covered are

     Hain                      Expires July 2008                         3

                      An IPv6 Provider-Independent Global      January 2008
                             Unicast Address Format

        used as an approximation to describe the concept. Therefore the
        difference in longitude vs. latitude circumference (flattening)
        resulting in a difference of the latitudinal sides will be ignored
        in the description, but accounted for in the measurement and
        allocation process. Interleaving is used to create a 44-bit
        reference value from a 2-bit section id plus the 21-bit values
        corresponding to each side of the grid. The number of subnets
        supported by this address format should be sufficient for a variety
        of uses.

        Addresses defined with the Geographic format prefix xxxx (see IANA
        considerations) are portable between providers. At the same time
        since they are defined by a fixed geographic location, by definition
        these prefixes are NOT-PORTABLE when a network attachment point
        changes geographic locations. Entities that expect reference values
        to be portable across physical location moves MUST use alternatives
        such as Provider-Aggregatable addresses or DNS names. Multi-site
        organizations SHOULD be using an appropriate set of the available
        prefixes (see companion document [Error! Bookmark not defined.] for
        usage discussions), allowing movement of any specific facility
        without impacting all communications.

        While this format is based on geographic location, it does not
        necessarily require renumbering devices as they move around within
        the boundaries of a specific network. The only time a renumbering
        event may be required is when the demarcation point to the public
        Internet changes. If the local jurisdiction remains the same (ie:
        the demarcation point is simply moving between buildings occupied by
        the same company) the prefix is may be left unchanged.

        One proposed use of this format is for use by mobile routers that do
        happen to be aware of their geographic position. Using this format
        allows these routers to construct an ad-hoc network where the
        prefixes naturally aggregate for prefixes far away. At the same time
        it is clear to all nodes within the geographic region what their
        prefix should be, which can further be leveraged to reduce the
        number of unsolicited RA messages that would unnecessarily consume
        battery power.

     Overview of the IPv6 Address

        IPv6 addresses are 128-bit identifiers for interfaces and sets of
        interfaces. There are three types of addresses: Unicast, Anycast,
        and Multicast. This document defines a specific type of Unicast
        address prefix. In conjunction with RFC 3306 [6], these Unicast
        prefixes define a specific capability for Multicast groups to target
        group members in a geographic region.

     Hain                      Expires July 2008                         4

                      An IPv6 Provider-Independent Global      January 2008
                             Unicast Address Format

        In this document, fields in addresses are given specific names, for
        example "subnet". When this name is used with the term "ID" (for
        "identifier") after the name (e.g., "subnet ID"), it refers to the
        contents of the named field. When it is used with the term "prefix"
        (e.g. "subnet prefix") it refers to all of the addressing bits to
        the left of and including this field.

        IPv6 unicast addresses are designed assuming that the Internet
        routing system makes forwarding decisions based on a "longest prefix
        match" algorithm on arbitrary bit boundaries and does not have any
        knowledge of the internal structure of IPv6 addresses. The structure
        in IPv6 addresses is for assignment and allocation. Due to the
        relationship between physical location of routers, geography, and
        human readability there may be a tendency to manage the routers so
        that they make forwarding decisions on nibble boundaries, but there
        is nothing in the format requiring that. Each router will need to be
        configured to forward based on a prefix length appropriate for the
        context of the specific local topology.

        The specific type of an IPv6 address is indicated by the leading
        bits in the address.  The variable-length field comprising these
        leading bits is called the Format Prefix (FP). This document defines
        an address format for the xxxx (binary) (see IANA considerations)
        Format Prefix for Geographic reference global unicast addresses. The
        same address format could be used with other Format Prefixes, as
        long as these Format Prefixes also identify IPv6 unicast addresses.
        For example, different FPs could be used to distinguish between
        resolution boundaries for three dimensional applications (see
        Extended Resolution on page 7). Only the xxxx Format Prefix is
        defined here.

     IPv6 Geographic Global Unicast Address Format

        Geographic address prefixes use a geographic reference derived from
        a bit interleave of the WGS-84 based latitude and longitude of the
        demarcation point of a site. The resulting 44-bit field provides a
        resolution grid of approximately 6.4 meters (equatorial) on a side.
        While the prefix MAY be defined and routed on any bit boundary
        length, the requirement for all service providers announcing a
        specific prefix to be capable of delivering traffic to all others,
        will have a tendency to naturally limit the operational choices.

        | 3 |     45 bits         |  16 bits  |       64 bits              |
        |001|global routing prefix| subnet ID |       interface ID         |

        Creating the Geographic address prefix is accomplished by
        establishing 4 major geographic sections. Three sections are in the
        band between +/- 60 degrees latitude, with the fourth split between
        the poles. Using section 00 as an example, the origin is established

     Hain                      Expires July 2008                         5

                      An IPv6 Provider-Independent Global      January 2008
                             Unicast Address Format

        at WGS-84 latitude and longitude 90e 60s. Locations covering 120
        degrees east and north (measured to 5 places right of the decimal
        ie: deg.xxxxx) are normalized to this origin, then those values are
        divided by the incremental angle. For latitudes between +/- 60
        degrees the incremental angle is 0.00005722045898437500

        The specific sequence for address formation is:

        1. demarcation WGS-84 value in degrees rounded to 5 decimal places
           follow steps for appropriate section
              00 -  90e 60s to 209.99999e 59.99999n
              01 - 210e 60s to 329.99999e 59.99999n
              10 - 330e 60s to  89.99999e 59.99999n
             110 -  90e 90s to  89.99999e 59.99999s
             111 -  90e 60n to  89.99999e 90n

        --- equatorial band
        2. normalize for origin of the section
          sec 0
            a) for east subtract 90 from the value
            b) for west subtract the value from 270
            c) for north add 60 to the value
            d) for south subtract the value from 60
        3. divide resulting values by 0.00005722045898437500  (120/2^21)
        4. convert each of the integers to 21-digit binary
        5. bit interleave latitude, longitude into 42-bit result
        6. prepend the 2-bit section number
        7. prepend the 4-bit FP xxxx to form 48-bit prefix

        --- polar sections
        2. normalize for origin of the section
           sec 3 - > 60 n/s
            a) for east subtract 90
             .1) if less than 0, add 360
            b) for west subtract from 270
             .1) if less than 0, add 360
            c) for north subtract 60
            d) for south subtract from 90
        3. divide resulting values by 0.00017166137695312500  (360/2^21)
        4. convert each of the integers to 21-digit binary
        5. adjust latitude value for north / south section
             a) for north set bit A(21)
             b) for south clear bit A(21)
        6. bit interleave latitude, longitude into 42-bit result
        7. prepend the 2-bit section number
        8. prepend the 4-bit FP xxxx to form 48-bit prefix


     Hain                      Expires July 2008                         6

                      An IPv6 Provider-Independent Global      January 2008
                             Unicast Address Format

        The examples in the tables below highlight the difficulty of
        aligning technical details of bit patterns with human meaningful
        text strings. One of the explicit goals of the first table is to
        identify the very large scopes devoid of geo-political context,
        while recognizing the need to provide something that an operator can
        relate to as the resolution becomes finer grained. In any case these
        are only descriptive examples, and actual implementations would be
        based on engineering requirements.

        The Reference field in the prefix MUST be calculated for a site at
        44-bits, but MAY be used in routing calculations on any bit boundary
        appropriate for the topology. For human reference the approximate
        surface area covered by each value of the grid is provided in the
        table below. The size in meters is based on rounded values for the
        equatorial circumference and should only be used as a conceptual

        bits    degrees              equatorial sq   scope           sites
          2 -> 120.00000            13358 km        section
          4 -> 60.00000              6679 km        expanse
          8  -> 15.00000              1669 km        frame
         12  -> 3.75                   417 km        zone
         16  -> 0.9375                 104 km        region
         20  -> 0.234375                26 km        metro          16777216
         24  -> 0.05859375             6.5 km        city            1048576
         28  -> 0.0146484375           1.6 km        locality          65536
         32  -> 0.003662109375         407  m        neighborhood       4096
         36  -> 0.00091552734375       102  m        block               256
         40  -> 0.0002288818359375      25  m        lot                  16
         44  -> 0.000057220458984375   6.4  m        site                  1

        The location addressed as x000:0000:0000::/48 covers an area in the
        Indian Ocean ~ 6.4 m on a side, north and east of the point 60
        degrees south - 90 degrees east. Specifically the WGS84 values
        between, 60s to 59.99994s and 90e to 90.00005e.

     Extended resolution

        The basic mechanism provides allocation of /48's in a two
        dimensional grid. At the same time there has been interest in finer
        grained resolution, as well as the ability to express altitude. The
        optional extended resolution provides three dimensional cube
        resolution allocations. It is expected that allocations using this
        extension will continue to be aggregated such that the prefix
        announcement into the public routing table is no longer than a /48.

        Options for encoding the bits beyond the lat-long grid as altitude
        result in various depths when the goal is a cube.

     Hain                      Expires July 2008                         7

                      An IPv6 Provider-Independent Global      January 2008
                             Unicast Address Format

        44 bit lat-long grid + 16 bit altitude
        44   -> 0.000057220458984375   6.4  m        site
        ~6.4 m cube to 419 km (260 mi) depth

        46 bit lat-long grid + 14 bit altitude
        46   -> 0.0000286102294921875  3.2  m        room
        ~3.2 m cube to 52 km (172,000 ft) depth

        48 bit lat-long grid + 12 bit altitude
        48   -> 0.0000143051147460937  1.6  m        desk
        ~1.6 m cube to 6.5 km (21,000 ft) depth

        50 bit lat-long grid + 10 bit altitude
        50   -> 0.0000071525573730468  0.8  m        chair
        ~.8 m cube to 815 m (2,600 ft) depth

        *** the following text about 3 dimensional support is broken and
        needs to be reworked. It inadvertently assumes the terrain map is
        always the surface of the WGS 84 ellipsoid. It may be appropriate to
        consider the altitude axis on a logarithmic scale, though that would
        cause resolution differences between identical buildings where one
        is at sea level while the other sits on a mountain top.  ***

        At this time, the tallest buildings are about 500m, so 50 bit
        lat/long + 10 bit altitude would appear to provide the best fit for
        a 3D use. This requires a WGS84 measurement resolution of 7 decimal
        places (beyond the capabilities of current consumer devices). If
        there is a strong interest in addressing mobile objects at higher
        altitudes, the grid would need to remain somewhat coarse to allow
        for the desired height. Also, until more accurate measurement
        equipment is readily available in handheld form to be carried by
        every L1 installer, there will be little ability to take advantage
        of the finer grid.

        There has also been some interest expressed in negative altitude
        values. While the opportunity exists for networks to exist below the
        surface of the WGS-84 ellipsoid, the likelihood of wide-scale use is
        very small. Coupling that with the already insufficient number of
        bits to encode the potentially interesting positive values above the
        surface at high granularity; makes it very unlikely that there will
        be broad community support for below the surface allocations. If on
        the other hand there were substantial interest in below the surface
        use, and equipment accuracy remains just 5 decimal places, it would
        make sense to use the 44 bit lat/long and 16 bit altitude approach.
        In this case, the most significant bit of 0 would designate above
        the surface, while 1 designates below. This would result in one
        subnet per ~6.4 m cube, to an approximate depth of + or - 210 km.

     Hain                      Expires July 2008                         8

                      An IPv6 Provider-Independent Global      January 2008
                             Unicast Address Format

     Interleave process detail:
        A bit interleave is used to allow aggregation on arbitrary
        granularities. From the left after the 4-bit format prefix, bits 123
        & 122 will identify the section using the table:
             00  –  90e 60s through 209.99999e 59.99999n
             01  – 210e 60s through 329.99999e 59.99999n
             10  - 330e 60s through  89.99999e 59.99999n
             110 –  90e 90s through  89.99999e 59.99999s
             111 –  90e 60n through  89.99999e 90n

        Mont Orohena, Tahiti   17.62000 s  149.48000 w

        This location is in section 01, where the coordinates normalize to:
        A - 42.38    ;       O - 0.52

        dividing those values by 120/2^21 returns:
        A - 740644   ;       O - 9087

        converting those to hex results in:
        A - B4D24    ;       O - 237F

        with binary equivalent from which the bits are interleaved:

        A – 0 1011 0100 1101 0010 0100 ; O – 0 0000 0010 0011 0111 1111
          A(21)---------------------(0);   O(21)---------------------(0)

        A(21)O(21)  A(20)O(20)A(19)O(19)  A(18)O(18)... A(1)O(1)A(0)O(0)

          00  1000  1010  0010  0100  1010 0111  0001  1101  0111  0101

        The 6 bits of FP and section ID are prepended with the final result:

     Interleave examples:
        Region            section lat section long   bit interleave
        W. Europe (west)     1C0000  :  000000  ->   xAA0:0000:0000::
        W. Europe (east)     1C0000  :  080000  ->   xAE0:0000:0000::
        S. Africa            070000  :  080000  ->   x86A:0000:0000::
        NE Africa            148000  :  0C8000  ->   xA70:0000:0000::
        E. Europe            1C0000  :  110000  ->   xBA1:0000:0000::
        C. Asia              148000  :  000000  ->   x220:8000:0000::
        E. Asia              190000  :  0C0000  ->   x2D2:0000:0000::
        Australia            070000  :  0C0000  ->   x07A:0000:0000::
        Alaska               020000  :  0A0000  ->   xE4C:0000:0000::
        NW US                1C0000  :  088000  ->   x6E0:4000:0000::
        Central America      148000  :  0D0000  ->   x671:8000:0000::
        SE US                190000  :  100000  ->   x782:0000:0000::
        South America        070000  :  100000  ->   x52A:0000:0000::
        NW Africa            100000  :  038000  ->   xA05:4000:0000::

     Hain                      Expires July 2008                         9

                      An IPv6 Provider-Independent Global      January 2008
                             Unicast Address Format

        S Pole – 90.00000 s     90.00000 e   xC00:0000:0000::
        N Pole – 90.00000 n     90.00000 e   xF5D:DDDD:DDDD::

     Airport location examples:

        MIA –    25.78000 n    80.28000 w    x72C:E3BF:E8D9::
        ATL –    33.63000 n    84.42000 w    x781:BF7A:F4F9::
        IAD –    38.93000 n    77.45000 w    x78D:3942:C7FF::
        JFK –    40.63000 n    73.77000 w    x798:B327:DDB5::
        ORD –    41.97000 n    87.90000 w    x78A:4A57:1978::
        DEN –    39.85000 n   104.70000 w    x6D8:8910:3DE6::
        SFO –    37.62000 n   122.37000 w    x69D:11D4:0F13::
        LAX –    33.93000 n   118.40000 w    x6C2:14F1:25C6::
        SAN –    32.73000 n   117.18000 w    x6C0:DA88:62AD::
        ANC –    61.16000 n   150.00000 w    xE44:46CC:6C66::
        SYD –    33.97000 s   151.17000 e    x128:BA55:FBDF::
        NRT –    35.75000 n   140.37000 e    x2D3:94D4:C195::
        DEL –    28.55000 n    77.01000 e    xB7A:C2E3:051F::
        CAI –    30.10000 n    31.40000 e    xB80:117D:E30E::
        CPT –    33.95000 s    18.60000 e    x878:FF19:7284::
        CDG –    49.00000 n     2.53000 e    xAE2:4652:4716::
        LHR –    51.47000 n    0.350000 w    xAB7:DEC2:89EF::
        GIG –    22.80000 s    42.23000 w    x5D2:EDDB:8163::
        SCL –    33.38000 s    70.78000 w    x53B:0682:2119::
        MEX –    19.43000 n    99.07000 w    x673:49B8:798E::

     U.S. postal examples:

      Locations within a 600km square - New York area (~Zone)::/12
        Danvers,      MA – 42.56940 n  70.94246 w   x79B:2398:575C::
        Cambridge,    MA – 42.37704 n  71.12561 w   x79B:20E0:BF51::
        Boston,       MA – 42.21300 n  71.03300 w   x79B:2056:DBA2::
        Providence,   RI – 41.49260 n  71.24400 w   x79B:0200:94EA::
        Bridgeport,   CT – 41.10010 n  73.12100 w   x798:EA22:B031::
        Upton,        NY – 40.52100 n  72.53100 w   x798:E4E8:4ADA::
        New York,     NY – 40.42510 n  74.00200 w   x798:B03A:8CAB::
        Newark,       NJ – 40.44080 n  74.10200 w   x798:A5D1:B059::
        Cherry  Hill, NJ – 39.93080 n  75.01754 w   x78D:DD76:FA53::
        Baltimore,    MD – 39.17250 n  76.36400 w   x78D:6E0C:5CA6::
        TysonsCorner, VA – 38.55070 n  77.13500 w   x78D:347E:9A88::
        Reston,       VA – 38.93501 n  77.35144 w   x78D:3957:BF69::
        Chantilly,    VA – 38.88413 n  77.43544 w   x78D:33E9:6FF3::

      Locations within a 150km square - Miami area (~Region)::/16
        Boca Raton,   FL – 26.34460 n  80.21094 w   x72E:4178:3A32::
        DeerfiledBeachFl – 26.30956 n  80.09917 w   x72E:4425:5611::
        CoralSprings, FL – 26.27140 n  80.25558 w   x72E:4143:2F68::

     Hain                      Expires July 2008                        10

                      An IPv6 Provider-Independent Global      January 2008
                             Unicast Address Format

        PompanoBeach, FL – 26.23153 n  80.12346 w   x72C:EEAC:8FF3::
        FtLauderdale, FL – 26.12156 n  80.12878 w   x72C:EE2B:5E8A::
        PembrokePines,FL – 26.02427 n  80.24018 w   x72C:EB44:923B::
        South Miami,  FL – 25.70025 n  80.30141 w   x72C:E39C:2B95::
        Key Biscayne, FL – 25.69210 n  80.16248 w   x72C:E3D7:E98D::
        Homestead,    FL – 25.47664 n  80.48385 w   x72C:E0CB:4E24::

      Locations within a 40km square - Chicago area (~Metro)::/20
        Skokie,       IL – 42.03617 n  87.73283 w   x78A:4B66:D89B::
        Schaumburg,   IL – 42.05807 n  88.04819 w   x78A:4A3B:0DDC::
        Chicago,      IL – 41.88585 n  87.61812 w   x78A:4C8E:69C4::
        Oak Brook,    IL – 41.78910 n  87.94009 w   x78A:4870:E1F7::
        DownersGrove, IL – 41.80343 n  88.01375 w   x78A:4837:E16A::
        Orland Park,  IL – 41.61938 n  87.84225 w   x78A:4387:1A7B::

      Examples of existing exchange points & potential prefixes:
        LINX, London     – 51.50717 n   0.00117 w   xAB7::/12
        AMS-IX, Amsterdam – 52.3025 n   4.93533 e   xAE3::/12
        NYIIX, NY        - 40.70350 n  74.00783 w   x798::/16
        STARTAP, Chicago – 41.87650 n  87.63467 w   x78A::/16
        LAIIX, LA        - 34.04233 n 118.24383 w   x6C2:171F::/20
        PAIX, Palo Alto  - 37.44083 n 122.15683 w   x697:BEDA::/20
        SIX, Seattle     - 47.61321 n 122.33799 w   x6B5:9E08::/20
        NSPIXP6, Tokyo   - 35.62500 n 139.90750 e   x2D3::/16
        SII, Shanghai    - 31.30200 n 121.49167 e   x2C0::/16

     A Geographic Multicast address format:

        A public service or network administrator may wish to notify all
        nodes within a given geographic area without requiring those clients
        to figure out all the appropriate groups to join. Using the all-
        nodes group ID 0000:0001, with RFC 3306, the PI prefix provides a
        means to identify the region for the target multicast.

        |   8    |  4 |  4 |   8    |    8   |       64       |    32    |
        |11111111|flgs|scop|reserved|  plen  | network prefix | group ID |

        Using this mechanism a weather warning or other public alert could
        be sent to participants in an area without the alerting service
        needing to individually contact the subscribers PA addresses, or the
        subscribers needing to know which specific groups to join (ie:
        connect me to all alerts within a 100km radius). Nodes participating
        in such a service would be listening to the all-nodes group
        hierarchy for the geographic range they are interested in.

     Hain                      Expires July 2008                        11

                      An IPv6 Provider-Independent Global      January 2008
                             Unicast Address Format

     Subnet Identifier
        (see RFC Editor considerations)

        With a 0001 FP, this document modifies both RFC 3513 & 3587 to
        extend the 64 bit Interface ID field size, and 16 bit Subnet ID
        field into the upper half of the Format Prefix 000 space.

        The Subnet ID field is used by an individual organization to create
        its own local addressing hierarchy and to identify subnets.  This is
        analogous to subnets in IPv4 except that most organizations have a
        much greater number of subnets.  The 16-bit Subnet ID field supports
        65,535 individual subnets.

           |    16      |              64 bits                |
           |   Subnet   |            Interface ID             |

     Technical Motivation

        The design choice for the size of the fields in the Geographic
        address format was based on the need to separate the address
        allocation from the service provider (specifically to address the
        scaling problems that mechanism creates when sites connect to
        multiple providers), the need to preserve the subnet structure
        defined in [7], and the resolution of readily available handheld GPS

     General Considerations

        The operational considerations : of human readability in the routing
        prefix lengths versus the topology realities used by the routing
        system are network dependent and outside the scope of this document.

        The technical considerations : the accuracy of the WGS-84 location
        reading versus the margin of error for a 21-bit resolution. When
        available, 5 places of significance right of decimal in lat/long
        readings results in 1 meter increment, or well within rounding error
        of 21 bit resolution : while between +/- 15 degrees latitude, using
        only 4 places of significance results in 11.1 meter increments which
        is considerably longer than the side ~ 6.4 m of the area being
        identified. (At this time, readily available consumer-grade GPS
        receivers are generally accurate to 3 meters, while commercial grade
        receivers have augmentation for sub-1 meter accuracy.)

        Alignment of the site boundary supporting SLA with the [7] format
        allows sites to use a consistent subnet structure.

     Hain                      Expires July 2008                        12

                      An IPv6 Provider-Independent Global      January 2008
                             Unicast Address Format

     IANA Considerations

        A 4-bit format prefix for PI address use needs to be assigned. The
        format prefix 0001 is recommended to avoid breaking up any of the
        unassigned 3-bit spaces.

     RFC Editor Considerations

        The format prefix binary value in the xxxx examples needs to be
        replaced by the value assigned by IANA.

        The format prefix hex value in the xhhh: examples needs to be
        replaced by the value assigned by IANA.

        The Subnet Identifier section, and the matching comment in the
        references section should be removed if the IANA assigned prefix is
        not in 000/3. It should be replaced with a pointer to (ARCH) for
        global scope allocations.

     Security Considerations

        While there may be concerns about location privacy raised by this
        scheme, there is nothing inherent in this address format that would
        raise any more security considerations than any other global
        addressing format. If location privacy were an issue it would be
        wise to avoid this mechanism in favor of location independent
        mechanisms such as Provider-Aggregatable [7] allocations.

     Appendix A:

        # This is a derivative of a script by mcr@sandelman.ca.
        #  http://www.sandelman.ottawa.on.ca/SSW/ietf/geo-pi/
        # The primary modification was to adjust for the change
        # to sections and origin. This version also adds an
        # option for decimal degree input format.
        # alh-ietf@tndh.net  2002/12/31

        print "Please select format  1) dd.mm.ss  or  2) dd.ddddd: ";

        print "Use minus (-) for south or west values. \n";
        print "Please enter your lattitude: ";

     Hain                      Expires July 2008                        13

                      An IPv6 Provider-Independent Global      January 2008
                             Unicast Address Format

        print "Please enter your longitude: ";

        if($fmt == 1) {
           ($longdeg, $longmin, $longsec) = split(/ /, $long);
           ($latdeg, $latmin, $latsec) = split(/ /, $lat);

           if($longdeg < 0) {
             $longdeg = 360 + $longdeg;
           if($latdeg < 0) {
              $latdeg = -$latdeg;
              $south = 1;
           $wgs84long = $longdeg + ($longmin / 60) + ($longsec / 360);
           $wgs84lat  = $latdeg +  ($latmin / 60)  + ($latsec / 360);

           if($south == 1) {
              $wgs84lat = -$wgs84lat;
        } else {
           if ($long < 0) {
              $wgs84long = 360 + $long;
           } else {
           $wgs84long = $long;
        $wgs84lat = 90 + $lat;

        # Origin is now south pole @ 0 degrees

        if ($wgs84lat >= 30) {
           if ($wgs84lat < 150) {
              $seclat = $wgs84lat - 30;
              if ($wgs84long >= 90) {
                 if ($wgs84long < 210) {
                    $section = 0;
                    $seclong = $wgs84long - 90;
                 } elsif ($wgs84long < 330) {
                    $section = 1;
                    $seclong = $wgs84long - 210;
                 } else {
                    $section = 2;
                    $seclong = $wgs84long - 330;
              } else {
                 $section = 2;
                 $seclong = $wgs84long + 30;
           } else {
              $section = 7;
              $seclat = $wgs84lat - 150;

     Hain                      Expires July 2008                        14

                      An IPv6 Provider-Independent Global      January 2008
                             Unicast Address Format

              $seclong = $wgs84long - 90;
        } else {
           $section = 6;
           $seclat = $wgs84lat;
           $seclong = $wgs84long - 90;
        if ($seclong < 0) {
           $seclong = 360 + $seclong;

        # Origin is now normalized to section
        print ("Sec Lat: $seclat \n");
        print ("Sec Long: $seclong \n");

        if($section < 3) {
           $seclong = int($seclong / 0.000057220458984375);
           $seclat  = int($seclat  / 0.000057220458984375);
        } else {
           $seclong = int($seclong / 0.00017166137695312500);
           $seclat  = int($seclat  / 0.00017166137695312500);

        # convert to binary
        @lat  = &convert_to_binary($seclat);
        @long = &convert_to_binary($seclong);
        @secbin = &convert_to_binary($section);

        print "Raw sec:",join('', @secbin),"\n";
        print "Raw lat: ",join('', @lat),"\n";
        print "Raw long:",join('', @long),"\n";

        # clean off excess leading 0's
        foreach $i (1..11) {
        foreach $i (1..29) {

        # interleave bits
           if ($section > 3) {
              foreach $i (1..3) {
                 $secid = shift(@secbin);
                 push(@geopi, $secid);
           } else {
              foreach $i (1..2) {
                 $secid = shift(@secbin);

     Hain                      Expires July 2008                        15

                      An IPv6 Provider-Independent Global      January 2008
                             Unicast Address Format

                 push(@geopi, $secid);
           foreach $i (1..21) {
              $o = shift(@long);
              $a = shift(@lat);
              if ($section > 3 && $i == 1) {
        #  skip this bit in polar sections
              } else {
              push(@geopi, $a);
              push(@geopi, $o);

        print "Digits ",join('', @geopi),"\n";
        print "Lat: $lat Long: $long  -> x";

        foreach $i (0..10) {
          @nibble = @geopi[($i*4)..($i*4+3)];
          $nibble = $nibble[0]*8 + $nibble[1]*4 + $nibble[2]*2 + $nibble[3];
          print sprintf("%x", $nibble);
          if($i==2 || $i==6) {
            print ":";
        print "\n";


        sub convert_to_binary {
          local($i, @digits);

          foreach $i (1..32) {
            if($num & 1) {
              unshift(@digits, 1);
            } else {
              unshift(@digits, 0);
            $num = $num >> 1;
          return @digits;


        The Overview of the IPv6 Address, Site Level Aggregator, and
        Interface ID portions of this text are directly copied from RFC 3587
        for consistency.

     Hain                      Expires July 2008                        16

                      An IPv6 Provider-Independent Global      January 2008
                             Unicast Address Format

        1  RFC-2460  Deering, S., Hinden, B. "Internet Protocol, Version 6
           (IPv6) Specification", RFC 2460, December 1998.

        2  RFC-4291  Hinden, B., Deering, S. "Internet Protocol Version 6
           (IPv6) Addressing Architecture", RFC 4291, February 2006.

        3  RFC-2119  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997

        4  RFC-3484, Draves, R., "Default Address Selection for Internet
           Protocol version 6 (IPv6)", RFC 3484, February 2003.

        5  http://en.wikipedia.org/wiki/WGS84

        6  RFC-3306, B. Haberman, D. Thaler., "Unicast-Prefix-based IPv6
           Multicast Addresses", RFC 3306, August 2002

        7  RFC-3587,  Hinden, B., Nordmark, E., Deering, S., IPv6 Global
           Unicast Address Format", RFC 3587, August 2003.

     Hain                      Expires July 2008                        17

   Early feedback was provided by Iljitsch van Beijnum, Brian
   Carpenter, Sean Doran, Geoff Huston, Andrew Main, Brian Haberman,
   Michael H. Lambert and Michel Py. Thanks to Michael Richardson for
   providing the initial Perl script. Calvin Newport's research efforts
   at MIT provided the innovative use case in MANET networks.

Author's Addresses

   Tony Hain
   Cisco Systems
   500 108th Ave. N.E. Suite 500
   Bellevue, Wa. 98004
   Email: alh-ietf@tndh.net

Copyright Notice

      Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights."

Disclaimer of Validity

   This document and the information contained herein are provided on

Hain                      Expires July 2008                        18

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/