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

Versions: 00 01

IPv6 maintenance Working Group (6man)                            F. Gont
Internet-Draft                                    SI6 Networks / UTN-FRH
Updates: RFC4941 (if approved)                                C. Huitema
Intended status: Standards Track                    Private Octopus Inc.
Expires: September 14, 2017                                      G. Gont
                                                            SI6 Networks
                                                         M. Garcia Corbo
                                                                 SITRANS
                                                          March 13, 2017


         Recommendation on Temporary IPv6 Interface Identifiers
                   draft-gont-6man-non-stable-iids-01

Abstract

   This document clarifies the stability requirements for IPv6
   addresses, and provides recommendations regarding the generation of
   Temporary addresses.  Finally, it formally updates RFC4941 such that
   nodes are allowed to configure only temporary addresses.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on September 14, 2017.

Copyright Notice

   Copyright (c) 2017 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Gont, et al.           Expires September 14, 2017               [Page 1]


Internet-Draft           Temporary Interface-IDs              March 2017


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Problem statement . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Generation of Temporary IPv6 Addresses  . . . . . . . . . . .   6
   5.  Update to existing RFCs . . . . . . . . . . . . . . . . . . .   8
   6.  Future Work . . . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   IPv6 StateLess Address AutoConfiguration (SLAAC) [RFC4862] has
   traditionally resulted in stable addresses, since the Interface
   Identifier (IID) has been generated by embedding a stable layer-2
   numeric identifier (e.g., a MAC address).  [RFC4941] implies,
   throughout the specification, that temporary addresses are generated
   and employed along with temporary addresses.

   While the use of stable addresses (only) or mixed stable and
   temporary addresses can be desirable in a number of scenarios, there
   are other scenarios in which, for security and privacy reasons, a
   node may want to use only Temporary address (e.g., a temporary
   address).

   This document clarifies the requirements for stability of IPv6
   addresses, such that nodes are not required to configure stable
   addresses.  It also specifies a set of requirements for the
   generation of Temporary addresses, and also specifies some sample
   algorithms that may be employed to generate temporary addresses that
   comply with the aforementioned requirements.  Finally, it formally
   updates [RFC4941] such that temporary addresses can be employed
   without the need to configure a stable address along side.

2.  Terminology

   This document employs the terms defined in [RFC7721].





Gont, et al.           Expires September 14, 2017               [Page 2]


Internet-Draft           Temporary Interface-IDs              March 2017


   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 [RFC2119].

3.  Problem statement

   When [RFC4941] was written, its authors wanted to prevent privacy and
   security attacks enabled by addresses that contain "an embedded
   interface identifier, which remains constant over time".  They
   observed that "Anytime a fixed identifier is used in multiple
   contexts, it becomes possible to correlate seemingly unrelated
   activity using this identifier."  They were concerned with both on-
   path attackers who would observe the IP addresses of packets observed
   in transit, and attackers that would have access to the logs of
   servers.

   Since the publication of [RFC4941] in September 2007, our
   understanding of threats and mitigations has evolved.  The IETF is
   now officially concerned with Pervasive Monitoring [RFC7258], as well
   as the wide spread collection of information for advertising and
   other purposes, for example through the Real Time Bidding protocol
   used for advertising auctions [RTB25].

3.1.  Privacy requirements

   The widespread deployment of encryption advocated in [RFC7624] is a
   response to Pervasive Monitoring.  Encryption of communication
   reduces the amount of information that can be collected by monitoring
   data links, but does not prevent monitoring of IPv6 addresses
   embedded in clear text packet headers.  Stable IPv6 addresses enable
   the correlation of such data over time.

   MAC Address Randomization [IETFMACRandom] is another response to
   pervasive monitoring.  In conjunction with DHCP Anonymity [RFC7844],
   it ensures that devices cannot be tracked by their MAC Address or
   their DHCP identifiers when they connect to "hot spots".  However,
   the privacy effects of MAC Address Randomization would be nullified
   if a device kept using the same IPv6 address before and after a MAC-
   address randomization event.

   Many Web Browsers have options enabling browsing "in private".
   However, if the web connections during the private mode use the same
   IPv6 address as those in the public mode, web tracking systems
   similar to [RTB25] will quickly find the correlation between the
   public personna of the user and the supposedly private connection.
   Similarly, many web browsers have options to "delete history",
   including deleting "cookies" and other persistent data.  Again, if
   the same IPv6 address is used before and after the deletion of



Gont, et al.           Expires September 14, 2017               [Page 3]


Internet-Draft           Temporary Interface-IDs              March 2017


   cookies, web tracking systems will easily correlate the new activity
   with the prior data collection.

   Using temporary address alone may not be sufficient to prevent all
   forms of tracking.  It is however quite clear that some usage of
   temporary addresses is necessary to provide user privacy.  It is also
   clear that the usage of temporary addresses needs to be synchronized
   with other privacy defining event such as moving to a new network,
   performing MAC Address Randomization, or changing the privacy posture
   of a node.

3.2.  Stability Requirements for IPv6 Addresses

   Nodes are not required to generate addresses with any specific
   stability properties.  That is, the generation of stable addresses is
   OPTIONAL.  This means that a node may end up configuring only stable
   addresses, only Temporary, or both stable and temporary addresses.

3.3.  Requirements for Temporary IPv6 Addresses

   The requirements for temporary IPv6 addresses are as follows:

   1.  Temporary addresses MUST have a limited lifetime, which should be
       different for different addresses.  The lifetime of an address
       essentially limits the extent to which network activity
       correlation can be performed based on such address.

   2.  The lifetime of an address MUST be further reduced when privacy-
       meaningful events (such as a node attaching to a new network)
       takes place.

   3.  The resulting Interface Identifiers MUST be different when
       addresses are configured for different prefixes.  That is, if
       different autoconfiguration prefixes are used to configure
       addresses for the same network interface card, the resulting
       Interface Identifiers must be (statistically) different.  This
       means that, given two addresses that employ different prefixes,
       it must be difficult for an outside entity to tell whether the
       addresses correspond to the same network interface or even
       whether they have been generated by the same host.

   4.  The resulting interface identifiers MUST NOT embed layer-2
       identifiers (e.g.  MAC addresses).

   5.  It must be difficult for an outside entity to predict the
       Interface Identifiers that will be generated by the algorithm,
       even with knowledge of the Interface Identifiers generated for
       configuring other addresses.



Gont, et al.           Expires September 14, 2017               [Page 4]


Internet-Draft           Temporary Interface-IDs              March 2017


   6.  The resulting Interface Identifiers MUST be semantically opaque
       [RFC7136] and MUST NOT follow any specific patterns.

   By definition, temporary addresses have a limited lifetime.  This is
   in contrast with e.g. stable addresses [RFC7217], that do not have
   have a limited lifetime.  Having a variable maximum lifetime prevents
   an observer from synchronizing with the temporary address
   regeneration; that is, from being able to expect when address will be
   regenerated, and thus infer that one newly observed addresses is the
   result of regenerating a previously observed one.

   The lifetime of an address should be further reduced by privacy-
   meaningful events.  For example, a host should not employ the same
   address across network attachment events.  That is, a host that de-
   attaches from a network and subsequently re-attaches to a (possibly
   different) network should regenerate all of its temporary addresses.
   Similarly, a host that implements MAC address randomization should
   regenerate all of its temporary addresses.  Other events, such as
   those discussed in Section 3.1 should also trigger the regeneration
   of all temporary addresses.

   The IIDs of addresses configured for different autoconfiguration
   prefixes must be different, such that traffic for those addresses
   cannot be correlated.

   The reuse of identifiers that have their own semantics or properties
   across different contexts or scopes can be detrimental for security
   and privacy [I-D.gont-predictable-numeric-ids] [RFC6973] [RFC4941].
   For example, if two different layer-3 protocols generate their
   addresses by embedding a layer-2 identifier (e.g., a MAC address),
   then the traffic for such protocols could be correlated (irrespective
   of whether the aforementioned layer-2 identifier has been randomized
   or not).  Besides, a node that generates an IPv6 address by embedding
   a link-layer address in the IPv6 address will, when configuring
   addresses for different prefixes, result in the same IID being used
   for such prefixes, thus allowing the corresponding traffic to be
   correlated.

   For security and privacy reasons, the IIDs generated for temporary
   addresses must not be predictable.  Otherwise, the node may be
   subject to many (if not all) of the security and privacy issues that
   are meant to be mitigated (please see [RFC7721].

   Any semantics or patterns in an IID might be leveraged by an attacker
   to e.g.  reduce the search space when performing address-scanning
   attacks, infer the identity of the node, etc.





Gont, et al.           Expires September 14, 2017               [Page 5]


Internet-Draft           Temporary Interface-IDs              March 2017


4.  Generation of Temporary IPv6 Addresses

   The following subsections specify algorithms that may be employed to
   generate temporary addresses that comply with the requirements
   specified in Section 3.3.

4.1.  RFC 4941

   One possible algorithm for generating temporary IPv6 addresses is
   that specified in [RFC4941].

   We note that, since the publication of [RFC4941], a number of issues
   have been found in common implementations of such algorithm
   [RAID2015].

      TODO: It remains an open question what to do with respect to
      RFC4941.  If this draft was to obsolete RFC4941, instead of merely
      update it, we would need to include here the actual specification
      of the address generation algorithm.

4.2.  Randomized IIDs

   Another possible approach would be to select a random IID when
   performing SLAAC.  A node employing this algorithm should generate
   IIDs as follows:

   1.  Obtain a random number (see [RFC4086] for randomness requirements
       for security)

   2.  The Interface Identifier is obtained by taking as many bits from
       the aforementioned random number (obtained in the previous step)
       as necessary.

          We note that [RFC4291] requires that the Interface IDs of all
          unicast addresses (except those that start with the binary
          value 000) be 64 bits long.  However, the method discussed in
          this document could be employed for generating Interface IDs
          of any arbitrary length, albeit at the expense of reduced
          entropy (when employing Interface IDs smaller than 64 bits).

       The resulting Interface Identifier SHOULD be compared against the
       reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]
       and against those Interface Identifiers already employed in an
       address of the same network interface and the same network
       prefix.  In the event that an unacceptable identifier has been
       generated, this situation SHOULD be handled in the same way as
       the case of duplicate addresses.




Gont, et al.           Expires September 14, 2017               [Page 6]


Internet-Draft           Temporary Interface-IDs              March 2017


   A node that disconnects from the network and subsequently reconnects
   would employ a (statistically different) IID for the same prefix.
   Similarly, a different (random) IID should be employed for each
   autoconfiguration prefix.  In the event of Duplicate Address
   Detection (DAD) [RFC4862] failures, another random number should be
   selected to recover from the DAD failure.

4.3.  Hash-based generation of temporary address generation

   The algorithm in [RFC7217] can be augmented for the generation of
   temporary addresses.  The benefit of this would be that a node could
   employ a single algorithm for generating stable and temporary
   addresses, by employing appropriate parameters.

   Nodes would employ the following algorithm for generating the
   temporary IID:

   1.  Compute a random identifier with the expression:

       RID = F(Prefix, MAC_Address, Network_ID, Time, DAD_Counter,
       secret_key)

       Where:

       RID:
          Random Identifier

       F():
          A pseudorandom function (PRF) that MUST NOT be computable from
          the outside (without knowledge of the secret key).  F() MUST
          also be difficult to reverse, such that it resists attempts to
          obtain the secret_key, even when given samples of the output
          of F() and knowledge or control of the other input parameters.
          F() SHOULD produce an output of at least 64 bits.  F() could
          be implemented as a cryptographic hash of the concatenation of
          each of the function parameters.  SHA-1 [FIPS-SHS] and SHA-256
          are two possible options for F().  Note: MD5 [RFC1321] is
          considered unacceptable for F() [RFC6151].

       Prefix:
          The prefix to be used for SLAAC, as learned from an ICMPv6
          Router Advertisement message, or the link-local IPv6 unicast
          prefix [RFC4291].

       MAC_Address:
          The MAC address corresponding to the underlying network
          interface card.  Employing the MAC address in this expression
          (in replacement of the Net_Iface parameter of the expression



Gont, et al.           Expires September 14, 2017               [Page 7]


Internet-Draft           Temporary Interface-IDs              March 2017


          in RFC7217) means that the re-generation of a randomized MAC
          address will result in a different temporary address.

       Network_ID:
          Some network-specific data that identifies the subnet to which
          this interface is attached -- for example, the IEEE 802.11
          Service Set Identifier (SSID) corresponding to the network to
          which this interface is associated.  Additionally, Simple DNA
          [RFC6059] describes ideas that could be leveraged to generate
          a Network_ID parameter.  This parameter is SHOULD be employed
          if some form of "Network_ID" is available.

       Time:
          An implementation-dependent representation of time.  One
          possible example is the representation in UNIX-like systems
          [OPEN-GROUP], that measure time in terms of the number of
          seconds elapsed since the Epoch (00:00:00 Coordinated
          Universal Time (UTC), 1 January 1970).

       DAD_Counter:
          A counter that is employed to resolve Duplicate Address
          Detection (DAD) conflicts.

       secret_key:
          A secret key that is not known by the attacker.  The secret
          key SHOULD be of at least 128 bits.  It MUST be initialized to
          a pseudo-random number (see [RFC4086] for randomness
          requirements for security) when the operating system is
          installed or when the IPv6 protocol stack is "bootstrapped"
          for the first time.

   2.  The Interface Identifier is finally obtained by taking as many
       bits from the RID value (computed in the previous step) as
       necessary, starting from the least significant bit.  The
       resulting Interface Identifier SHOULD be compared against the
       reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]
       and against those Interface Identifiers already employed in an
       address of the same network interface and the same network
       prefix.  In the event that an unacceptable identifier has been
       generated, this situation SHOULD be handled in the same way as
       the case of duplicate addresses.

5.  Update to existing RFCs

   The following subsections clarify how each of the RFCs affected by
   this document are updated.





Gont, et al.           Expires September 14, 2017               [Page 8]


Internet-Draft           Temporary Interface-IDs              March 2017


5.1.  Update to RFC4941

   The temporary addresses specified in [RFC4941] MAY be used in
   replacement of the stable addresses [RFC8064].  That is, a node MAY
   configure temporary addresses only, without configuring any stable
   addresses.

6.  Future Work

   This document clarifies the requirements for stability requirements
   for IPv6 addresses, and specifies requirements for temporary
   addresses.  A separate document
   ([I-D.gont-6man-address-usage-recommendations]) discusses the
   tradeoffs involved when considering different stability properties of
   IPv6 addresses, and and the different configuration setups such as:
   stable addresses only, temporary addresses only, or mixed stable and
   temporary addresses.

7.  IANA Considerations

   There are no IANA registries within this document.  The RFC-Editor
   can remove this section before publication of this document as an
   RFC.

8.  Security Considerations

   This document clarifies the stability requirements for IPv6
   addresses, and specifies requirements for the generation of temporary
   addresses.  Additionally, it formally updates [RFC4941] such that
   stable addresses are not required to be configured along with the
   temporary addresses.

   The security and privacy properties of IPv6 addresses have been
   discussed in detail in [RFC7721] and [RFC7707].

9.  Acknowledgements

   The authors would like to thank (in alphabetical order) Brian
   Carpenter and Lorenzo Colitti for providing valuable feedback on
   earlier versions of this document.

10.  References

10.1.  Normative References







Gont, et al.           Expires September 14, 2017               [Page 9]


Internet-Draft           Temporary Interface-IDs              March 2017


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <http://www.rfc-editor.org/info/rfc4086>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <http://www.rfc-editor.org/info/rfc4291>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <http://www.rfc-editor.org/info/rfc4862>.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
              <http://www.rfc-editor.org/info/rfc4941>.

   [RFC5453]  Krishnan, S., "Reserved IPv6 Interface Identifiers",
              RFC 5453, DOI 10.17487/RFC5453, February 2009,
              <http://www.rfc-editor.org/info/rfc5453>.

   [RFC7136]  Carpenter, B. and S. Jiang, "Significance of IPv6
              Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
              February 2014, <http://www.rfc-editor.org/info/rfc7136>.

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <http://www.rfc-editor.org/info/rfc7217>.

   [RFC8064]  Gont, F., Cooper, A., Thaler, D., and W. Liu,
              "Recommendation on Stable IPv6 Interface Identifiers",
              RFC 8064, DOI 10.17487/RFC8064, February 2017,
              <http://www.rfc-editor.org/info/rfc8064>.

10.2.  Informative References







Gont, et al.           Expires September 14, 2017              [Page 10]


Internet-Draft           Temporary Interface-IDs              March 2017


   [FIPS-SHS]
              NIST, "Secure Hash Standard (SHS)", FIPS
              Publication 180-4, March 2012,
              <http://csrc.nist.gov/publications/fips/fips180-4/
              fips-180-4.pdf>.

   [I-D.gont-6man-address-usage-recommendations]
              Gont, F., Gont, G., and M. Corbo, "IPv6 Address Usage
              Recommendations", draft-gont-6man-address-usage-
              recommendations-01 (work in progress), February 2017.

   [I-D.gont-predictable-numeric-ids]
              Gont, F. and I. Arce, "Security and Privacy Implications
              of Numeric Identifiers Employed in Network Protocols",
              draft-gont-predictable-numeric-ids-00 (work in progress),
              February 2016.

   [IANA-RESERVED-IID]
              IANA, "Reserved IPv6 Interface Identifiers",
              <http://www.iana.org/assignments/ipv6-interface-ids>.

   [IETFMACRandom]
              Zuniga, JC., "MAC Privacy", November 2014,
              <http://www.ietf.org/blog/2014/11/mac-privacy/>.

   [OPEN-GROUP]
              The Open Group, "The Open Group Base Specifications Issue
              7 / IEEE Std 1003.1-2008, 2016 Edition",
              Section 4.16 Seconds Since the Epoch, 2016,
              <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
              contents.html>.

   [RAID2015]
              Ullrich, J. and E. Weippl, "Privacy is Not an Option:
              Attacking the IPv6 Privacy Extension",  International
              Symposium on Recent Advances in Intrusion Detection
              (RAID), 2015, <https://www.sba-research.org/wp-
              content/uploads/publications/Ullrich2015Privacy.pdf>.

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              DOI 10.17487/RFC1321, April 1992,
              <http://www.rfc-editor.org/info/rfc1321>.

   [RFC6059]  Krishnan, S. and G. Daley, "Simple Procedures for
              Detecting Network Attachment in IPv6", RFC 6059,
              DOI 10.17487/RFC6059, November 2010,
              <http://www.rfc-editor.org/info/rfc6059>.




Gont, et al.           Expires September 14, 2017              [Page 11]


Internet-Draft           Temporary Interface-IDs              March 2017


   [RFC6151]  Turner, S. and L. Chen, "Updated Security Considerations
              for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
              RFC 6151, DOI 10.17487/RFC6151, March 2011,
              <http://www.rfc-editor.org/info/rfc6151>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <http://www.rfc-editor.org/info/rfc6973>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <http://www.rfc-editor.org/info/rfc7258>.

   [RFC7624]  Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
              Trammell, B., Huitema, C., and D. Borkmann,
              "Confidentiality in the Face of Pervasive Surveillance: A
              Threat Model and Problem Statement", RFC 7624,
              DOI 10.17487/RFC7624, August 2015,
              <http://www.rfc-editor.org/info/rfc7624>.

   [RFC7707]  Gont, F. and T. Chown, "Network Reconnaissance in IPv6
              Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
              <http://www.rfc-editor.org/info/rfc7707>.

   [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
              Considerations for IPv6 Address Generation Mechanisms",
              RFC 7721, DOI 10.17487/RFC7721, March 2016,
              <http://www.rfc-editor.org/info/rfc7721>.

   [RFC7844]  Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
              Profiles for DHCP Clients", RFC 7844,
              DOI 10.17487/RFC7844, May 2016,
              <http://www.rfc-editor.org/info/rfc7844>.

   [RTB25]    Interactive Advertising Bureau (IAB), "Real Time Bidding
              (RTB) project, OpenRTB API Specification Version 2.5",
              December 2016, <http://www.iab.com/wp-
              content/uploads/2016/03/
              OpenRTB-API-Specification-Version-2-5-FINAL.pdf>.

Authors' Addresses








Gont, et al.           Expires September 14, 2017              [Page 12]


Internet-Draft           Temporary Interface-IDs              March 2017


   Fernando Gont
   SI6 Networks / UTN-FRH
   Evaristo Carriego 2644
   Haedo, Provincia de Buenos Aires  1706
   Argentina

   Phone: +54 11 4650 8472
   Email: fgont@si6networks.com
   URI:   http://www.si6networks.com


   Christian Huitema
   Private Octopus Inc.
   Friday Harbor, WA  98250
   U.S.A.

   Email: huitema@huitema.net
   URI:   http://privateoctopus.com/


   Guillermo Gont
   SI6 Networks
   Evaristo Carriego 2644
   Haedo, Provincia de Buenos Aires  1706
   Argentina

   Phone: +54 11 4650 8472
   Email: ggont@si6networks.com
   URI:   https://www.si6networks.com


   Madeleine Garcia Corbo
   Servicios de Informacion del Transporte
   Neptuno 358
   Havana City  10400
   Cuba

   Email: madelen.garcia16@gmail.com













Gont, et al.           Expires September 14, 2017              [Page 13]


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