Reflections on the REST Architectural Style and “Principled Design of the Modern Web Architecture” | Fielding, Taylor, Erenkrantz, Gorlick, Whitehead, Khare, Oreizy

Roy T. Fielding, Richard N. Taylor, Justin Erenkrantz, Michael M. Gorlick, E. James Whitehead, Rohit Khare, Peyman Oreizy; Reflections on the REST Architectural Style and “Principled Design of the Modern Web Architecture; In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2017); 2017; pages 4-11 (8 pages); landing.

Performed

Reflections on REST; keynote address; performed at the 2017 11th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2017); by one of Roy Fielding, Richard Taylor, Rohit Khare (expect: Rohit Khare); video; 0:47:41; slides (42 slides).

Abstract

Seventeen years after its initial publication at ICSE 2000, the Representational State Transfer (REST) architectural style continues to hold significance as both a guide for understanding how the World Wide Web is designed to work and an example of how principled design, through the application of architectural styles, can impact the development and understanding of large-scale software architecture. However, REST has also become an industry buzzword: frequently abused to suit a particular argument, confused with the general notion of using HTTP, and denigrated for not being more like a programming methodology or implementation framework. In this paper, we chart the history, evolution, and shortcomings of REST, as well as several related architectural styles that it inspired, from the perspective of a chain of doctoral dissertations produced by the University of California’s Institute for Software Research at UC Irvine. These successive theses share a common theme: extending the insights of REST to new domains and, in their own way, exploring the boundary of software engineering as it applies to decentralized software architectures and architectural design. We conclude with discussion of the circumstances, environment, and organizational characteristics that gave rise to this body of work.

Mentions

  • REpresentational State Transfer (REST)
  • Computational REpresentational State Transfer (CREST)
    Computational REST (CREST)
  • Capability Uniform Resource Locator (CURL)
    Capability URL (CURL)
  • COmputAtional State Transfer (COAST)
  • Computing Resource Exchange with Security (COAST)
  • ARRESTED
  • Application Programming Interface (API)
  • Distributed Hash Table (DHT)
  • SIENA (Scalable Internet Event Notification Architectures)
  • XML
  • DHT
  • HTTP
  • REST
  • bit.ly
  • Persistsent Uniform Resource Locator (PURL)
    Persistsent URL (PURL)
  • Notifications
    • e.g. on page transitions
    • HTML ping
    • DOM, onClick, onLoad, onAnything
    • M. Thomson, E. Damaggio, B Raymor. Generic Event Delivery Using HTTP Push. RFC 8030. Internet Engineering Task Force (IETF). 2016.
  • Google Analytics
  • Google Docs
  • Google Sheets
  • AJAX
  • JavaScript
  • HTTP
    • LINK
    • UNLINK
  • Peer-to-Peer (P2P)
  • Decentralized Applications (DAPPs, dApps)
  • Client/Server
  • Web Distributed Authoring and Versioning (WebDAV, WEBDAV)
    • lock-based concurrency control
    • An RPC-based client-server centralized ile system with remote access “over HTTP”
  • Limitations of REST
    • one-shot
    • one-to-one
    • one-way
  • execution engine
  • binding environment
  • COAST
    • Capabilities
      • Services
      • Messaging
      • Interpretation
    • Claims
      • Secure remote code execution (RCE)
      • Live update
      • Novel
      • Monitoring & Traceability
      • Something about refactoring:
        Server abdication, client redelegation, server re-offering (fewer services), client reprogramming of the server.
      • Dynamic Reconfiguration
  • Group Consensus and Simultaneous Agreement (GCSA)
  • WebRTC,
  • Websockets
  • Webhooks
  • HTTP/2
  • Internet of Things (IoT)
  • Content Distrubtion Network (CDN)
  • TrueTime
  • GlobalClock
  • Apache Kafka
  • Amazon Kinesis,
  • Google Cloud Pub/Sub
  • Amazon Lambda,
  • IFTTT
  • ‘assistants’, a natural language conversational product concept, within the buzzy AI business culture. Think: Eliza, that you built in high school.
  • Cassandra
  • NoSQL
  • Federated Learning
  • Merkle Hash Trees (not MHT)
  • Bitcoin
  • <buzz>blockchain</buzz>
  • Git
    • is a decentralized in concept.
    • is not decentrlaized in practice, c.f. GitHub
  • Software-as-a-Service (SaaS)
  • Computational REpresentational State Transfer (CREST)
  • Aura
  • Nikander
  • Trickles
  • network continuations
  • Hypertext Transport Protocol (HTTP)
    • HTTP/1.1
    • HTTP/2
  • DARPA
  • NSF
  • ISR (Irvine Software Rationalization?)
  • Arcadia

Behavior, Asynchrony, State, Execution (BASE)

Concept

Adapability requires the design-time  actions…

LP1
making the parts that are subject to change identifiable, discrete and manipulable.
LP2
providing mechanisms for controlling interactions between the parts subject to change.
LP3
providing techniques for managing state.

Elaborated

  • Peyman Oreizy, Nenad Medvidovic, Richard N. Taylor. Runtime Software Adaptation: Framework, Approaches, and Styles. In Companion of 30th International Conference on Software Engineering (ICSE Companion). 2008. ACM. pages 899–910.
  • Richard N. Taylor, Nenad Medvidovic, Peyman Oreizy. Architectural Styles for Runtime Software Adaptation. In Proceedings of the Eighth Joint Working IEEE/IFIP Conference on Software Architecture and Third European Conference on Software Architecture. IEEE Computer Society, 171–180. 2009.

Exemplars

  • C2
  • CREST
  • MapReduce
  • Pipe-and-Filter
  • Event Notifications
  • “and others.”

Disambiguation

  1. within the transaction formalization of Database Theory
    • Basically Available, Soft state, Eventual consistency (BASE)
      not as used herein.
    • a consistency model wherein everything almost works
      riposte: “eventually we are all dead.”
    • Contra
      • Always Computing In Denial (ACID)
      • Atomicity Consistency Isolation Durability (ACID)
  2. within the Dynamic Software Architectures Theory, page 9.
    • Behavior
    • Asynchrony
    • State
    • Execution
  3. within the ARRESTED Theory, page 10.
    the “mindset” of a node in a distributed network.
    Best-Effort
    Others are making their best effort, as are you.
    Approximate
    There is only approximate knowledge of the state of The Other; your theory of mind is limited & foggy, slacky-latent.
    Self-centered
    Others are self-centered, as are you.
    Efficient
    Make efficient use of the only global resource: communication bandwidth to others; i.e. time is the only finite resource.

Asynchronous, Routed, REpresentational State Transfer with Estimation & Delgation (A+R+REST+E+D, ARRESTED)

  • Polling (and its inverse Asynchrony)
  • Asynchrony (and its inverse Polling)
  • Routing
  • Delegation
  • Estimation

Concept

Theory
REST+P
REST with Polling.
REST+E
REST with Estimation.
A+REST
REST with Asynchrony (callbacks).
R+REST
REST with Routing (packets).
REST+D
REST with Delegation (proxies, gateways).
ARREST
Asynchronous, Routed, REST.
ARREST+E
Asynchronous, Routed, REST, with Estimation.
ARREST+D
Asynchronous, Routed, REST, with Delgation.
ARREST+D
Asynchronous, Routed, REST, with Estimation & Delgation.
ARRESTED
A synonym for slow, yes?
Topology

The metaphor.

Poles
North
Centralized Systems
East
Estimated Systems
South
Decentralized Systems
West
Distributed Systems
Boundaries
now horizon
  • Master-Slave Styles
  • Peer-to-Peer Styles
agency boundary
  • Consensus-Based Styles
  • Consensus-Free Styles

Elaborated

Techniques

  • Bitcoin
  • and other distributed ledger schemes.

Computational REpresentational State Transfer (CREST)

Is just like functional programming.

  • The Poetry
    • mashups of Web culture are “the same as” continuations in programming language theory & culture. c.f. Scheme & SML
    • 300-series redirects are continuations

Principles

CP1
The key abstraction of computation is a resource, named by an URL.
CP2
The representation of a resource is a program, a closure, a continuation, or a binding environment plus metadata to describe the program, closure, continuation, or binding environment.
CP3
All computations are context-free.
CP4
Only a few primitive operations are always available, but additional per-resource operations are also encouraged.
CP5
The presence of intermediaries is promoted.

Concept

  • Ship code+data as a package to evaluate off-box (over there, on their box).
  • Receive code+data as a package to evaluate on-box (here on our box).
  • What could go possibly wrong here? [over there?]

Elaborations

  • Justin R. Erenkrantz. Computational REST: A New Model for Decentralized, Internet-Scale Applications. Ph.D. Dissertation. University of California, Irvine, Irvine, California, USA. 2009.
  • Justin R. Erenkrantz, Michael Gorlick, Girish Suryanarayana, Richard N. Taylor. Harmonizing Architectural Dissonance in REST-based Architectures. Technical Report UCI-ISR-06-18. Institute for Software Research, University of California, Irvine. 2006.
  • Justin R. Erenkrantz, Michael M. Gorlick, Girish Suryanarayana, Richard N. Taylor. From Representations to Computations: The Evolution of Web Architectures. In ACM SIGSOFT Symposium on The Foundations of Software Engineering (FSE). 2007. pages 255–264.
  • Roy T. Fielding. Maintaining distributed hypertext infostructures: Welcome to MOMspider’s Web. In Computer Networks and ISDN Systems, 27, 2. 1994. pages 193–204. doi:10.1016/0169-7552(94)90133-3. Series title? Selected Papers of the First World-Wide Web Conference.

Techniques

  • web mashups
  • session management
  • cookies in client/server interactions
    <quote>, and the (misplaced) role of cookies in client/server interactions</quote>
  • time-dependent resources; e.g. weather forecasts.
  • time-series responses; e.g. stock tickers.

<editorial>Why aren’t cookies necessary again? They uniquely number the consumer base. They are used to develop Measurement, Targeting, Retargeting & Profiling which are the explicit and probably only renumerative use case of the (online) media business model. Oh, right, and paywalls. And, um, public televison-type “membership drive” tip jars.</editorial>

References

There are 59 references.

Abstracted

  • Roy T. Fielding, Richard N. Taylor. Principled Design of the Modern Web Architecture. In Proceedings of the 22nd International Conference on Software Engineering (ICSE). 2000. pages 407–416. IEEE, Limerick, Ireland.

Dissertated

  • Justin R. Erenkrantz. Computational REST: A New Model for Decentralized, Internet-Scale Applications. Ph.D. Dissertation. University of California, Irvine, Irvine, California, USA. 2009.
  • Roy T. Fielding. Architectural Styles and the Design of Network-based Software Architectures. Ph.D. Dissertation. University of California, Irvine, California, USA. 2000.
  • Michael Martin Gorlick. Computational State Transfer: An Architectural Style for Decentralized Systems. Ph.D. Dissertation. Technical Report UCI-ISR-16-3. University of California, Irvine, Irvine, California, USA. 2016.
  • David Alan Halls. Applying Mobile Code to Distributed Systems. Ph.D. Dissertation. University of Cambridge, Cambridge, UK. 1997.
  • Michael Hicks. Dynamic Software Updating. Ph.D. Dissertation. Computer and Information Science, University of Pennsylvania, Philadelphia, Pennsylvania, USA. 2001.
  • Rohit Khare. Extending the REpresentational State Transfer (REST) Architectural Style for Decentralized Systems. Ph.D. Dissertation. University of California, Irvine, California, USA. 2003.
  • Mark Samuel Miller. Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. Ph.D. Dissertation. Johns Hopkins University, Baltimore, Maryland, USA. 2006.
  • Peyman Oreizy. Open architecture software: a flexible approach to decentralized software evolution. Ph.D. Dissertation. University of California, Irvine, Irvine, California, USA.
  • Emmet James Whitehead, Jr. An Analysis of the Hypertext Versioning Domain. Ph.D. Dissertation. Univ. of California, Irvine, Irvine, California, USA. 2000.

Complete

  1. T. Aura, P. Niklander. Stateless Connections. In Proceedings of the First International Conference on Information and Communication Security (Lecture Notes In Computer Science), Y. Han, T. Okamoto, S. Qing (editors), Vol. 1334. Springer-Verlag, 1997. pages 87–97.
  2. Tim Berners-Lee, Robert Cailliau, Ari Luotonen, Henrik Frystyk Nielsen, Arthur Secret. The World-Wide Web. In Communications of the ACM, 37, 8. 1994-08. pages 76–82. doi:10.1145/179606.179671.
  3. Tim Berners-Lee, Roy T. Fielding, Larry Masinter. Uniform Resource Identifier (URI): Generic Syntax. RFC 3986. Internet Engineering Task Force (IETF). 2005-01. doi:10.17487/RFC3986.
  4. Tim Berners-Lee, Roy T. Fielding, Henrik Frystyk Nielsen. Hypertext Transfer Protocol – HTTP/1.0. RFC 1945. Internet Engineering Task Force (IETF). 1996-05. doi:10.17487/RFC1945.
  5. Tim Berners-Lee, Jean-Francois Groff. The World Wide Web (a.k.a. WWW). In SIGBIO Newsletter, 12, 3. 1992-09. pages 37–40. doi:10.1145/147126.147133.
  6. Keith Bonawitz, Vladimir Ivanov, Ben Kreuter, Antonio Marcedone, H. Brendan McMahan, Sarvar Patel, Daniel Ramage, Aaron Segal, Karn Seth. Practical Secure Aggregation for Federated Learning on User-Held Data. In Proceedings of the NIPS Workshop on Private Multi-Party Machine Learning. 2016. landing.
  7. Antonio Carzaniga, David S. Rosenblum, Alexander L. Wolf. Design and Evaluation of a Wide-Area Event Notification Service. In ACM Transactions on Computer Systems, 19, 3. 2001-08. pages 332–383. paywall.
  8. James C. Corbett, Jeffrey Dean et. al. Spanner: Google’s Globally-distributed Database. In Proceedings of the 10th USENIX Conference on Operating Systems Design and Implementation (OSDI). 2012. pages 251–264. paywall, landing. slides: pptx, event: session.
  9. Chris Dixon. Crypto Tokens: A Breakthrough in Open Network Design. In His Blog, centrally hosted on Medium. 2017-06.
  10. L. Dusseault. HTTP Extensions for Web Distributed Authoring and Versioning (WEBDAV). RFC 4918. Internet Engineering Task Force (IETF). 2007.
  11. Justin R. Erenkrantz. Computational REST: A New Model for Decentralized, Internet-Scale Applications. Ph.D. Dissertation. University of California, Irvine, Irvine, California, USA. 2009.
  12. Justin R. Erenkrantz, Michael Gorlick, Girish Suryanarayana, Richard N. Taylor. Harmonizing Architectural Dissonance in REST-based Architectures. Technical Report UCI-ISR-06-18. Institute for Software Research, University of California, Irvine. 2006.
  13. Justin R. Erenkrantz, Michael M. Gorlick, Girish Suryanarayana, Richard N. Taylor. From Representations to Computations: The Evolution of Web Architectures. In ACM SIGSOFT Symposium on The Foundations of Software Engineering (FSE). 2007. pages 255–264.
  14. Roy T. Fielding. Maintaining distributed hypertext infostructures: Welcome to MOMspider’s Web. In Computer Networks and ISDN Systems, 27, 2. 1994. pages 193–204. doi:10.1016/0169-7552(94)90133-3. Series title? Selected Papers of the First World-Wide Web Conference.
  15. Roy T. Fielding. Relative Uniform Resource Locators. RFC 1808. Internet Engineering Task Force (IETF). 1995-06. doi:10.17487/RFC1808.
  16. Roy T. Fielding. Architectural Styles and the Design of Network-based Software Architectures. Ph.D. Dissertation. University of California, Irvine, California, USA. 2000.
  17. Roy T. Fielding, Gail Kaiser. The Apache HTTP Server Project. In IEEE Internet Computing. 1, 4. 1997-07. pages 88–90. doi:10.1109/4236.612229
  18. Roy T. Fielding, Henrik Frystyk Nielsen, Jeffrey Mogul, Jim Gettys, Tim Berners-Lee. Hypertext Transfer Protocol – HTTP/1.1. RFC 2068. 1997-01. doi:10.17487/RFC2068
  19. Roy T. Fielding, Julian Reschke. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. RFC 7231. Internet Engineering Task Force (IETF). 2014-06. doi:10.17487/RFC7231.
  20. Roy T. Fielding, Richard N. Taylor. Principled Design of the Modern Web Architecture. In Proceedings of the 22nd International Conference on Software Engineering. 2000. pages 407–416. IEEE, Limerick, Ireland.
  21. Roy T. Fielding, Richard N. Taylor. Principled Design of the Modern Web Architecture. In ACM Transactions on Internet Technology, 2, 2. 2002-05. pages 115–150.
  22. Roy T. Fielding, E. James Whitehead, Jr., Kenneth M. Anderson, Gregory A. Bolcer, Peyman Oreizy, Richard N. Taylor. Web-Based Development of Complex Information Products. In Communications of the ACM, 41, 8. 1998-08. pages 84–92.
  23. Matias Giorgio, Richard N. Taylor. Accountability Through Architecture for Decentralized Systems: A Preliminary Assessment. Technical Report UCI-ISR-15-2. Institute for Software Research, University of California, Irvine. 2015.
  24. Cristiano Giuffrida, Anton Kuijsten, Andrew S. Tanenbaum. 2013. Safe and Automatic Live Update for Operating Systems. In Proceedings of the Eighteenth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS’13). ACM, New York City, New York, USA, 279–292.
  25. Y. Goland, E. Whitehead, A. Faizi, S. Carter, D. Jensen. HTTP Extensions for Distributed Authoring – WEBDAV. RFC 2518. Internet Engineering Task Force. 1999.
  26. Michael Martin Gorlick. Computational State Transfer: An Architectural Style for Decentralized Systems. Ph.D. Dissertation. Technical Report UCI-ISR-16-3. University of California, Irvine, Irvine, California, USA. 2016.
  27. Michael M. Gorlick, Kyle Strasser, Richard N. Taylor. COAST: An Architectural Style for Decentralized On-Demand Tailored Services. In Proceedings of 2012 Joint Working Conference on Software Architecture & 6th European Conference on Software Architecture (WICSA/ECSA). 2012. pages 71–80.
  28. David Alan Halls. Applying Mobile Code to Distributed Systems. Ph.D. Dissertation. University of Cambridge, Cambridge, UK. 1997.
  29. Michael Hicks. Dynamic Software Updating. Ph.D. Dissertation. Computer and Information Science, University of Pennsylvania, Philadelphia, Pennsylvania, USA. 2001.
  30. Irvine Research Unit in Software (IRUS). The Workshop on Internet-Scale Technology (TWIST). A series, 1998-2000.
  31. R. Kadia. Issues Encountered in Building a Flexible Software Development Environment: Lessons from the Arcadia Project. In Proceedings of the Fifth ACM SIGSOFT Symposium on Software Development Environments (SDE). 1992. ACM, New York, NY, USA. pages 169–180. doi:10.1145/142868.143768.
  32. Rohit Khare. Extending the REpresentational State Transfer (REST) Architectural Style for Decentralized Systems. Ph.D. Dissertation. University of California, Irvine, California, USA. 2003.
  33. Rohit Khare, Richard N. Taylor. Extending the REpresentational State Transfer Architectural Style for Decentralized Systems. In Proceedings of the 26th International Conference on Software Engineering (ICSE). 2004. IEEE Computer Society, Edinburgh, Scotland, UK. pages 428–437.
  34. Avinash Lakshman, Prashant Malik. Cassandra: A Decentralized Structured Storage System. In SIGOPS Operating Systems Review, 44, 2. 2010-04. pages 35–40.
  35. David Mazieres. The stellar consensus protocol: A federated model for internet-level consensus. Stellar Development Foundation. 2015.
  36. Mark Samuel Miller. Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. Ph.D. Dissertation. Johns Hopkins University, Baltimore, Maryland, USA. 2006.
  37. Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008.
  38. Peyman Oreizy. Open architecture software: a flexible approach to decentralized software evolution. Ph.D. Dissertation. University of California, Irvine, Irvine, California, USA.
  39. Peyman Oreizy, Michael M. Gorlick, Richard N. Taylor, Dennis Heimbigner, Gregory Johnson, Nenad Medvidovic, Alex Quilici, David Rosenblum. An Architecture-based Approach to Self-Adaptive Software. In IEEE Intelligent Systems, 14, 3. 1999-05 (May-June). pages 54–62.
  40. Peyman Oreizy, Nenad Medvidovic, Richard N. Taylor. Architecture-Based Runtime Software Evolution. In Proceedings of the 20th International Conference on Software Engineering (ICSE). 1998. pages 177–186.
  41. Peyman Oreizy, Nenad Medvidovic, Richard N. Taylor. Runtime Software Adaptation: Framework, Approaches, and Styles. In Companion of 30th International Conference on Software Engineering (ICSE Companion). 2008. ACM. pages 899–910.
  42. Peyman Oreizy, Richard N. Taylor. 1998. On the role of software architectures in runtime system reconfiguration. In IEE Proceedings-Software, 145, 5. 1998. pages 137–145.
  43. Dewayne E. Perry, Alexander L. Wolf. 1992. Foundations for the Study of Software Architecture. In SIGSOFT Software Engineering Notes, 17, 4. 1992-10. pages 40–52. doi:10.1145/141874.141884.
  44. Sean Rhea, Brighten Godfrey, Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, Harlan Yu. OpenDHT: A Public DHT Service and Its Uses. In SIGCOMM Computing Communication Review, 35, 4. 2005-08. pages 73–84.
  45. Alan Shieh, Andrew C. Myers, Emin G. Sirer. Trickles: A Stateless Network Stack for Improved Scalability, Resilience, and Flexibility. In Proceedings of Symposium on Networked Systems Design and Implementation,/em> (NSDI), Vol. 2. USENIX Association. 2005. pages 175–188.
  46. Alan Shieh, Andrew C. Myers, Emin Gün Sirer. A Stateless Approach to Connection-Oriented Protocols. In ACM Transactions on Computer Systems, 26, 3. 2008-09. pages 8:1–8:50.
  47. James W. Stamos, David K. Gifford. Implementing Remote Evaluation. In IEEE Transactions on Software Engineering, 16, 7. 1990-07. pages 710–722.
  48. James W. Stamos, David K. Gifford. Remote Evaluation. In ACM Transactions on Programming Languages and Systems (TOPLAS), 12, 4. 1990-10. pages 537–564.
  49. Chengzheng Sun, Xiaohua Jia, Yanchun Zhang, Yun Yang, David Chen. Achieving Convergence, Causality Preservation, and Intention Preservation in Real-time Cooperative Editing Systems. In ACM Transactions on Complicating Human Interactions (HCI), 5, 1. 1998-03. pages 63–108.
  50. Richard N. Taylor, Nenad Medvidovic, et al. A Component- and Message- Based Architectural Style for GUI Software. In Transactions on Software Engineering. 1996-06. pages 390–406.
  51. Richard N. Taylor, Nenad Medvidovic, Eric M. Dashofy. Software Architecture: Foundations, Theory, and Practice. John Wiley & Sons. 2010. ASIN:B012AQ8M42: Kindle: no, paper: $151-$600.
  52. Richard N. Taylor, Nenad Medvidovic, Peyman Oreizy. Architectural Styles for Runtime Software Adaptation. In Proceedings of the Eighth Joint Working IEEE/IFIP Conference on Software Architecture and Third European Conference on Software Architecture. IEEE Computer Society, 171–180. 2009.
  53. R.D. Tennant. 1976. The Denotational Semantics of Programming Languages. In Communications of the ACM 19, 8. 1976-08. pages 437–453.
  54. M. Thomson, E. Damaggio, B Raymor. Generic Event Delivery Using HTTP Push. RFC 8030. Internet Engineering Task Force (IETF). 2016.
  55. Emmet James Whitehead, Jr. An Analysis of the Hypertext Versioning Domain. Ph.D. Dissertation. Univ. of California, Irvine, Irvine, California, USA. 2000.
  56. Emmet James Whitehead, Jr., Yaron Goland. The WebDAV Property Design. In Software, Practice and Experience 34 2004, 135–161.
  57. Wikipedia. 2017. Representational state transfer,/a>. In Wikipedia. 2017.
  58. Scott Wolchok, J Alex Halderman. Crawling BitTorrent DHTs for Fun and Profit. In Proceedings of the Fourth USENIX Workshop on Offensive Technologies (WOOT10). 2010.
  59. Gavin Wood. 2014. Ethereum: A secure decentralised generalised transaction ledger. Paper 151. Ethereum Project Yellow Papers 2014.

Previously filled.

Fedora 25, installation notes & experiences

Issues

  • IPv6 addresses come up with RFC7217 privacy mode enabled
    As such, the local radvd does not tag the machine with a “known” address.
    Remediation: turn off IPV6_ADDR_GEN_MODE=stable-privacy or set IPV6_ADDR_GEN_MODE=eui64 in the relevant /etc/sysconfig/network-scripts/enp1s0.

Reminder

Fedora Live Workstation…

  • … does not enable sshd. The firewall is configured to allow it, but the service is not enabled or started after the build.
  • … builds to graphical.target.  To back down to the non-graphical mode, systemctl set-default multi-user.target.  See the guidance in the (legacy) /etc/inittab commentary.
  • … uses firewalld to manage the iptables.  If you need to install a custom iptables setup, e.g. with xtables-addons xt_geoip rules then you need iptable-services.

Actualities

sudo dnf install -y xtables-addons

See the separate recipe for bringing down firewalld and bringing up the separable iptables services

systemctl get-default
sudo systemctl set-default multi-user.target
sudo systemctl enable sshd
sudo systemctl start sshd
nmcli reload
nmcli modify enp1s0 ipv5.addr-gen-mode eui64
nmcli con down enp1s0
nmcli con up enp1s0
$ cat /etc/sysconfig/network-scripts/ifcfg-enp1s0
HWADDR=00:EC:AC:CD:E6:12
TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
#IPV6_ADDR_GEN_MODE=stable-privacy
NAME=enp1s0
UUID=6c463f92-11d2-30ba-8273-d86bb3c58859
ONBOOT=yes
AUTOCONNECT_PRIORITY=-999
PEERDNS=yes
PEERROUTES=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes

References

Standards

RFC 7217
A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)
F. Gont (SI6 Networks & UTN-FRH); IETF; 2014-04.
Abstract: This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses).
RFC 4941
Privacy Extensions for Stateless Address Autoconfiguration in IPv6
Narten (IBM), Draves (Microsoft) Krishnan (Ericsson); IETF; 2007-09.
Abstract: Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node.

RFC 6844 – DNS Certification Authority Authorization (CAA) Resource Record

RFC 5844DNS Certification Authority Authorization (CAA) Resource Record; IETF; P. Hallam-Baker (Comodo), R. Stradling (Comodo); 2013-01.

Example

$ORIGIN example.com
 .       CAA 0 issue "ca.example.net; account=230123
 .       CAA 0 iodef "mailto:security@example.com"
 .       CAA 0 iodef "http://iodef.example.com/"
$ORIGIN example.com
.       CAA 0 issue "ca.example.net; policy=ev"
.       CAA 128 tbs "Unknown"

Note the value 128 is the bit zero as the order of the bits is big endian.

Flags

Issuer Critical
If set to ’1′, indicates that the corresponding property tag MUST be understood if the semantics of the CAA record are to be correctly interpreted by an issuer. Issuers MUST NOT issue certificates for a domain if the relevant CAA Resource Record set contains unknown property tags that have the Critical bit set.

Property Tags

issue Issuer Domain Name [; name=value ]*
The issue property entry authorizes the holder of the domain name <Issuer Domain Name> or a party acting under the explicit authority of the holder of that domain name to issue certificates for the domain in which the property is published.
issuewild Issuer Domain Name [; name=value ]*
The issuewild property entry authorizes the holder of the domain name Issuer Domain Name or a party acting under the explicit authority of the holder of that domain name to issue wildcard certificates for the domain in which the property is published.
iodef URL
Specifies a URL to which an issuer MAY report certificate issue requests that are inconsistent with the issuer’s Certification Practices or Certificate Policy, or that a Certificate Evaluator may use to report observation of a possible policy violation. The Incident Object Description Exchange Format (IODEF) format is used [RFC5070].

Notes

Note that according to the conventions set out in [RFC1035], bit 0 is the Most Significant Bit and bit 7 is the Least Significant Bit. Thus, the Flags value 1 means that bit 7 is set while a value of 128 means that bit 0 is set according to this convention.

Referenced

RFC5070
The Incident Object Description Exchange Format (IODEF)

Sender Policy Framework (SPF)

Standards

  • RFC 7372Email Authentication Status Codes; M Kucherawy; IETF; 2014-09.
  • RFC 7208Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1; Kitterman (Kitterman); IETF; 2014-04.
  • RFC 4408Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1; M. Wong, W. Schilitt; IETF; 2006-04

Argot

  • ADministrative Management Domain (ADMD)
  • Sender Policy Framework (SPF)

WebRTC and STUN for intra-LAN exploration & end-user tracking

WebRTC

  • WebRTC, promotional site
  • Availabilities
    all the browsers that matter

    • Android
    • Chrome (Linux, Android, Windows)
    • Firefox
    • Opera
    • Safari (iOS)

STUN

Related

Standards

  • RFC 7350Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN); Petit-Huguenin, Salgueiro; IETF; 2014-08.
  • RFC 7064URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol; Nandakumar, Salgueiro, Jones, Petit-Huguenin; IETF; 2013-11.
  • RFC 5928Traversal Using Relays around NAT (TURN) Resolution Mechanism; Petit-Huguenin; IETF; 2010-08.
  • RFC 5389Session Traversal Utilities for NAT (STUN); Rosenberg, Mahy, Matthews, Wing; IETF; 2008-10.
    (obsoleted)

    • RFC 3489STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs); Rosenberg, Weinberger, Huitema, Mahy; 2003-03.

In Jimi Wales’ Wiki.

Implementation

Tracking

In archaeological order

Leaking


665909webrtc WebRCT Tracking; In Bugzilla of Mozilla; 2011-06-21 →2016-01-11; Closed as INVALID


Some droid using the self-asserted identity token cchen; How to Stop WebRTC Local IP Address Leaks on Google Chrome and Mozilla Firefox While Using Private IPs; In Privacy Online Forums; 2015-01→2015-03.

Mentions

  • Availability
    of the problem (not of WebRTC in general)

    • Chrome of Google
      • Windows
    • Firefox of Mozilla
      • Unclear, perhaps Windows only
    • Internet Explorer of Microsoft
      WebRTC is not available at all.
    • Opera of Mozilla
      • Unclear
    • Safari of Apple
      WebRTC is not available except through a plugin
    • Unavailable
      • Chrome of Google
        • OS/X
        • Android
      • Linux at all
        not clear; not mentioned at all.
  • Blocking
    • Chrome of Google
    • Firefox of Mozilla
      • Production
        • about:config
        • media.peerconnection.enabled set to true (default true)
      • Development
        same

        • Canary
        • Nightly
        • Bowser
    • Opera of Opera
  • API Directory
    • voice calls
    • video chats
    • p2p file sharing

Configuration

  • Chrome
    default is available and active
  • Firefox
    • about:config
    • media.peerconnection.enabled set to true (default true)
  • Opera
    only when configured, with a plugin, to run Google Chrome extensions

Demonstration

webrtc-ips, a STUN & WebRTC test rig

  • diafygi/webrtc-ips
  • via on-page JavaScript, makes latent requests to certain STUN servers.
  • Firefox 34 → Does. Not. Work.
  • Fails with
    Error: RTCPeerConnection constructor passed invalid RTCConfiguration - missing url webrtc-ips:58

Argot

  • Private Internet Access (PIA)
  • Real-Time-Communication (RTC)
  • Virtual Private Network (VPN)
  • WebRTC

Previously

In Privacy Online Forums:

Referenced

  • 2013
  •  Since WebRTC uses javascript requests to get your IP address, users of NoScript or similar services will not leak their IP addresses.

Via: backfill.


Firefox

  • about:config
  • media.peerconnection.enabled set to true (default true)

Automatic Empty Zones (including RFC 1918 prefixes) transition between BIND v9.8 and BIND v9.9

References

Standards

  • RFC 1918Address Allocation for Private Internets, 1996-02.
  • RFC 4193Unique Local IPv6 Unicast Addresses, 2005-11.
  • RFC 5737IPv4 Address Blocks Reserved for Documentation, 2010-01.
  • RFC 6598IANA-Reserved IPv4 Prefix for Shared Address Space, 2012-04.

Interesting

The two zones pertaining to the unknown address and the localhost address of IPv6 are each considered individually and separately as a zone:

0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA

To amplify, there is not a containing zone that is expected to hold both of these names

0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA

 Exhibitions

As of BIND v9.9, the following empty zones may be produced:

10.IN-ADDR.ARPA
16.172.IN-ADDR.ARPA
17.172.IN-ADDR.ARPA
18.172.IN-ADDR.ARPA
19.172.IN-ADDR.ARPA
20.172.IN-ADDR.ARPA
21.172.IN-ADDR.ARPA
22.172.IN-ADDR.ARPA
23.172.IN-ADDR.ARPA
24.172.IN-ADDR.ARPA
25.172.IN-ADDR.ARPA
26.172.IN-ADDR.ARPA
27.172.IN-ADDR.ARPA
28.172.IN-ADDR.ARPA
29.172.IN-ADDR.ARPA
30.172.IN-ADDR.ARPA
31.172.IN-ADDR.ARPA
168.192.IN-ADDR.ARPA
100.51.198.IN-ADDR.ARPA
113.0.203.IN-ADDR.ARPA
8.B.D.0.1.0.0.2.IP6.ARPA

Earlier versions produced empty zones for the following:

0.IN-ADDR.ARPA
127.IN-ADDR.ARPA
254.169.IN-ADDR.ARPA
2.0.192.IN-ADDR.ARPA
100.51.198.IN-ADDR.ARPA
113.0.203.IN-ADDR.ARPA
255.255.255.255.IN-ADDR.ARPA
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
8.B.D.0.1.0.0.2.IP6.ARPA
D.F.IP6.ARPA
8.E.F.IP6.ARPA
9.E.F.IP6.ARPA
A.E.F.IP6.ARPA
B.E.F.IP6.ARPA

sendmail, still, intermittently, gives “host map: lookup ($domain): deferred”

Previously

sendmail gives “host map: lookup ($domain): deferred”, 2015-03-04.

Continuing

And yet it continues to happen intermittently

  • Has something to do with IPv6 vs IPv4
  • Once sendmail is in that state, it never recovers
    i.e.

    • the queue never clears
    • its growth is unbounded
  • the only remedies are manual intervention
    • sendmail -q (manually)
    • systemctl restart sendmail (manually)

Debug

$ sendmail -v -d8.32 -qIMessageID

Actualities

$ sudo sendmail -v -d8.32 -qIt85HF6hG025984
Running /var/spool/mqueue/t85HF6hG025984 (sequence 1 of 1)
dns_getcanonname(sender.example.com, trymx=1)
dns_getcanonname: trying sender.example.com. (AAAA)
	NO: errno=0, h_errno=4
dns_getcanonname: trying sender.example.com. (A)
	YES
dns_getcanonname: sender.example.com
dns_getcanonname(emerson.baker.org, trymx=1)
dns_getcanonname: trying emerson.baker.org. (AAAA)
	NO: errno=0, h_errno=4
dns_getcanonname: trying emerson.baker.org. (A)
	NO: errno=0, h_errno=4
dns_getcanonname: trying emerson.baker.org. (MX)
	YES
dns_getcanonname: emerson.baker.org
getmxrr(smart.mail.example.emerson.baker.org, droplocalhost=1)
getmxrr: res_search(smart.mail.example.emerson.baker.org) failed (errno=0, h_errno=4)
dns_getcanonname(smart.mail.example.emerson.baker.org, trymx=0)
dns_getcanonname: trying smart.mail.example.emerson.baker.org. (AAAA)
	NO: errno=0, h_errno=4
dns_getcanonname: trying smart.mail.example.emerson.baker.org. (A)
	YES
dns_getcanonname: smart.mail.example.emerson.baker.org
... Connecting to smart.mail.example.emerson.baker.org. via relay...
220 mta.emerson.baker.org ESMTP Sendmail 8.14.5/8.14.5; Thu, 10 Sep 2015 10:17:26 -0700
>>> EHLO sender.example.com
250-mta.emerson.baker.org Hello sender.example.emerson.baker.org [192.0.2.19], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-STARTTLS
250-DELIVERBY
250 HELP
>>> STARTTLS
220 2.0.0 Ready to start TLS
>>> EHLO sender.example.com
250-mta.emerson.baker.org Hello sender.example.emerson.baker.org [192.0.2.19], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH LOGIN PLAIN
250-DELIVERBY
250 HELP
>>> MAIL From: SIZE=845
250 2.1.0 ... Sender ok
>>> RCPT To:
>>> DATA
250 2.1.5 ... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 t8AHHQ0v004865 Message accepted for delivery
... Sent (t8AHHQ0v004865 Message accepted for delivery)
Closing connection to smart.mail.example.emerson.baker.org.
>>> QUIT
221 2.0.0 mta.emerson.baker.org closing connection

UNSOLVED: sendmail gives “host map: lookup ($domain): deferred”

tl;dr → ensure the AAAA, A and MX records are visilble and are compatible with host connectivity.

i.e. don’t publish AAAA (only) for an IPv4-connected host.

Diagnostic

$ mailq
/var/spool/mqueue (1 request)
-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient-----------
t22GuSUb006467 72 Mon Mar 2 08:56
(host map: lookup (SOMEHOST.emerson.baker.org): deferred)

Total requests: 1
$ host -t aaaa SOMEHOST.emerson.baker.org
SOMEHOST.emerson.baker.org has IPv6 address 2001:db8::99:1
SOMEHOST.emerson.baker.org has IPv6 address 2001:db8::88:1

Debug

sendmail -v -d8.32 -qImessageID

Background

<quote>Starting with Sendmail 8.12, Sendmail queries the following 3 DNS resource records in order:

  • AAAA
  • A
  • MX

Failures earlier in the series are treated as more serious than those later, as documented. In particular, it is unreasonable to have a host with only AAAA records published, but which is only connected via IPv4.

References

Via: backfill.

draft-ietf-homenet-arch-12 | IPv6 Home Networking Architecture Principles

draft-ietf-homenet-arch-12 IPv6 Home Networking Architecture Principles; IETF; Editor: T. Chown (U. Southampton); J. Arkko (Ericsson), A. Brandt (Sigma Designs), O. Troan (Cisco), J. Weil (Time Warner Cable); 2014-02-14; expires 2014-08-18; 104 pages.

Abstract

This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed, and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network.

Mentioned

Referenced

selected

[I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]
Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. Wing, “IPv6 Multihoming without Network Address Translation”, draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06 (work in progress), February 2014.

Via: backfill

What does “RFC 1918 response from Internet for 0.0.0.10.IN-ADDR.ARPA” mean? | ISC Knowledge Base

What does “RFC 1918 response from Internet for 0.0.0.10.IN-ADDR.ARPA” mean?; ISC Knowledge Base; 2011-03-18, updated 2012-09-27; Top, Software Products, BIND9, FAQs

IPv4 per RFC 1918

  • 10.0.0.0/8
  • 169.254.0.0/16
  • 172.16.0.0/12
  • 192.168.0.0/16

IPv6 per RFC 4193

  • fc00::/7
    • fc00::/8 (unused)
    • fd00::/8 (locally assigned)

Mentioned

The Internet: Looking Forward | Vint Cerf (Google)

Vint Cerf (Google); “The Internet: Looking Forward”; In The Internet Protocol Journal, Volume 16, Number 2, 2013-06; page 14; 3700 words.

Mentions

  • Domain Name System (DNS)
  • Internet Service Providers (ISPs)
  • Internet of Things
  • Network Address Translation (NAT)
  • Carrier-Grade NAT
  • IPv6
  • OpenFlow
  • William Stallings; Software-Defined Networks and OpenFlow;  In The Internet Protocol Journal; Volume 16, No. 1, 2013-03.
  • Border Gateway Protocol (BGP)
  • Mark Weiser
  • Ubiquitous Computing
  • Global Positioning System (GPS)
  • Massive, Open, OnLine Classe (MOOC)
  • Natural Language Processing, methods
    • (general) statistical methods
    • Hierarchical Hidden Markov Models
    • Formal Grammars
    • Bayesian techniques
  • Big Data (bzzzzz!)
  • Cloud Computing
  • American Sign Language (ASL)
  • Large Hadron Collider (LHC)
  • “bit rot” (digital preservation)
  • Basic Input/Output System (BIOS)
  • Internet Governance
  • Cyberfires (machines under attack)
  • Cyber Fire Department (fixing that)

Via: backfill

Are you ready for IPv6 insecurities? | George Kargiotakis

George Kargiotakis; Are you ready for IPv6 insecurities?; At Ath.Con; 2012-03-05; 60 slides.

Referenced

People

Mentions

  • Stateful DHCPv6
    • IA_TA
    • IA_NA
    • IA_PD
  • Stateless DHCPv6
    • SLAAC+OtherConfig Flag = 1
  • Handwringing
    • IPv6 Security Hype
    • Common Local Attacks & mitigation
    • Remote Network Scanning
    • Local Network Scanning
    • IDS/Firewalling
      • OS Support
      • IPv6 Migration
      • Security
    • Scanning IPv6 Internet
    • Tools
    • Food for thought – IPv6 Security Overview
  • Attacks
    • Address Resolution
    • Redirect
    • Duplicate Address Detection DoS
    • First-Hop Router Attack
    • Address configuration DoS
    • DHCPv6 Spoofing
  • Mitigations
    • RFC 6105 IPv6 Router Advertisement Guard; IETF; E. Levy-Abegnoli, Van de Velde (Cisco), C. Popoviciu (Technodyne), J. Mohacsi (NIIF/Hungarnet); 2011-02.
      • RA-Guard
      • L2 Protection
      • SEcure Neighbor Discovery (SEND)
    • RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls; IETF; E. Davis (self), J. Mohacsi (NIIF,  HUNGARNET); 2007-03.
    • RFC 3971 SEcure Neighbor Discovery (SEND); IETF; Editor: J. Arkko (Ericsson); J. Kempf (DoCoMo USA), B. Zill (Microsoft), P. Nikander (Ericsson); 2005-03.
  • Network Scanning
    • Tools of the trade
      • nmap
      • thc-ipv6: dnsrevenum6 (not included in v1.8)
      • ip6-arpa-scan.py
      • dns-ip6-arpa-scan.nse
    • mDNS
  • Best Practices
    • Block unused transition techniques
      • protocol 41
      • 192.88.99.0/24 (6to4 tunnels)
    • Deny UDP 3544 (Teredo)
    • Deny TCP & UDP 3653 (Tunnel Setup Protocol, TSP)
  • Tunnel Setup Protocol
    • Jimi Wales’ Wiki
    • RFC 5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP); IETF; M. Blanchet (Viagenie), F. Parent (Beon Solutions); 2010-02.
  • Not Covered
    • Mobile IPv6
    • IPv6 over 3G (telecom)
  • Tools
    • THC-IPv6
    • scapy
    • ndisc6
    • tcpdump, wireshark
    • nmap (-6) + NSE scripts
    • nc6/socat
    • 6tunnel
    • ndpmon

Via: backfill

Defining an IPv6-Ready CPE

Mentions

  • Address types
    • Link-Local (LL)
    • Unique Local Address (ULA)
    • Global
  • NAT
  • Dual Stack
  • Multicast Proxy Daemon
  • ICMPv6 Multicast
  • Recursive DNS Server (RDNSS)
    • RFC 6106 IPv6 Router Advertisement Options for DNS Configuration; IETF; J. Jeong (Brocade, ETRI), S. Park (Samsung), L. Beloeil (France Telecom), S. Madanapalli (iRam); 2010-11.
  • Privacy Extensions
  • EUI-64
  • Stateless Address Auto-Configuration (SLAAC)
  • DHCPv6
    • Stateful
    • Stateless
    • Prefix Delegation
  • Zeroconf (IPv4)
  • Point-to-Point Protocol (PPP)
    • Assigns /64
    • Assign /127 (/128)
    • Link Control Protocol (LCP)
    • Network Control Protocol (NCP)
    • IP6CP (IPv6CP) of Point-to-Point Protocol (PPP)
      • RFC 5172 Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol; IETF; Editor: S. Varada (Transwitch); 2008-03.
      • RFC 5072 IP Version 6 over PPP; IETF; Editor: S. Varada (Transwitch); D. Haskins, E. Allen; 2007-09; Obsoletes: RFC 2472.
  • Identity Association (IA)
    • Identity Association for Non-temporary Addresses (IA_NA)
      • RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6); IETF; Editor: R. Droms (Cisco), J. Bound (HP), B. Volz (Ericsson), T. Lemon (Nominum), C. Perkins (Nokia), M. Carney (Sun); 2003-07.
    • Identity Association for Temporary Addresses (IA_TA)
      • RFC 3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6; IETF; T. Narten (IBM), R. Draves (Microsoft); 2001-01.
  • Addressing LAN Clients
    • TR-101, Issue 1, Migration to Ethernet-Based DSL Aggregation; 2006-04; 101 pages.
      See TR-101 notes, backfill.
    • Claim: Prefix is at least /56 → 72 bits per TR-177.
  • Firewall
    • Statefull
    • User (Customer) managed
  • RFC 6106 IPv6 Router Advertisement Options for DNS Configuration; J. Jeong (Brocade, ETRI), S. Park, (Samsung), L. Beloeil (France Telecom), S. Madanapalli (iRam); 2010-11; Obsoletes: RFC 5006.
  • TR-069 Issue 1, Amendment 4, CPE Wan Management Protocol, Protocol Version v1.3; 2011-07; 190 pages.
  • Access
    • 6to4
    • 6rd
    • 6in4
      • Tunnelbroker.net
      • Hexago
      • Sixxs.net
    • A+P (Address plus Port)
    • NAT64
    • Dual-Stack Lite
    • 4rd

References

Broadband Forum

  • TR-187, Issue 1, IPv6 for PPP Broadband Access
  • TR-181, Amendment 2, TR-069 Data model extension for IPv6
  • TR-177, Issue 1, IPv6 in the context of TR-101
  • TR-124 Issue 2, Functional Requirements for Broadband Residential Gateway Device

IETF

  • RFC 6555 Happy Eyeballs: Success with Dual-Stack Hosts; IETF; D. Wing, A. Yourtchenko (Cisco); 2012-04.
  • RFC 6434 IPv6 Node Requirements; IETF; E. Jankiewicz (SRI), J. Loughney (Nokia), T. Narten (IBM); 2011-12.
  • RFC 6204 Basic Requirements for IPv6 Customer Edge Routers
  • RFC 6144 Framework for IPv4/IPv6 Translation
  • RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service

Source

George Kargiotakis (GENNET Broadband Solutions); Defining an IPv6-Ready CPE; In Some Conference; 2011-05; 16 slides.
Via backfill

Broadband Forum’s Technical Reports on IPv6

Technical Reports of the Broadband Forum
Selected reports … in archaeological order

  • TR-254, Issue 1, Functionality Tests for Ethernet Based Access Nodes; 2012-06; 58 pages.
  • TR-242, Issue 1, IPv6 Transition Mechanisms for Broadband Networks; 2012-08; 64 pages.
  • TR-187, Issue 2, IPv6 for PPP Broadband Access; 2013-02; 32 pages.
    • TR-187, Issue 1; 2010-05; 32 pages.
  • TR-177, Issue 1, IPv6 in the context of TR-101; 2010-11; 64 pages.
  • TR-146, Issue 1, Subscriber Sessions; 2013-05; 46 pages.
  • TR-101, Issue 1, Migration to Ethernet-Based DSL Aggregation; 2006-04; 101 pages.

Promotions


Chris Van Fossen (Hurricane Electric); Webcast 41; On YouTube; 2010-12-28; 2:04.

radvd and NetworkManager for RFC 6106 (IPv6 Router Advertisement Options for DNS Configuration)

Configuration

  • dhcpd (ISC’s DHCPv6)
    • stateless mode is a dhclient-side activity
    • remove the ia (ask for address) statements from the interface stanzas
    • Example:
      iface eth0 {
      ...
      ia
      option domain
      option time-zone
      ... }
  • radvd
    • AdvManagedFlag off;
    • AdvOtherConfigFlag on;
    • RDNSS address list {
      ...
      AdvRDNSSPreference 8;
      AdvRDNSSLifetime 3600;
      ... }
  • NetworkManager
    • nmcli connection
  • rdnssd
    • obsolete, incorporated into NetworkManager

Commentary & Tutorial

  • Jeremy Visser; Is an IPv6-only Network Feasible?; In His Blog; 2012-06-13.
    Mentions

    • <quote>Ubuntu 12.04 this works out-of-the-box with NetworkManager. On older versions of Ubuntu, you need to change IPv6 from “Ignore” to “Automatic” in NetworkManager.</quote>

Commitments & Comparisons

Fedora, Scoping & Project Documentation

Fedora 12

Comparison of IPv6 support in operating systems; In Jimi Wales’ Wiki

  • Fedora 13 => OK
  • RHEL6 => OK
  • Ubuntu 11.04 (Natty Narwal) => OK
  • Android => NO (Neither: DHCP6, ND RDNSS)
    1. Issue 32621: Support for DHCPv6 (RFC 3315)
    2. Issue 32629: Support for Recursive DNS Server Option in ICMPv6 Router Advertisements (RFC 6106)

Concepts

Standards

  • RFC 6106 IPv6 Router Advertisement Options for DNS Configuration; J. Jeong (Brocade), S. Park (Samsung), L. Beloeil (France Telecom), S. Madanapalli (iRam); 2010-11.
  • RFC 4861 Neighbor Discovery for IP version 6 (IPv6); T. Narten (IBM), E. Nordmark (Sun), W. Simpson (Daydreamer), H. Soliman (Elevate); 2007-09.
  • RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6; R. Droms (Cisco); 2004-04
  • RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6); Editor: R. Droms (Cisco); J. Bound (HP), B. Volz (Ericsson), T. Lemon (Nominum), C. Perkins (Nokia), M. Carney (Sun); 2003-07.

Via backfill

Special Classes & Special-Use Addresses in IPv4 & IPv6

Reserved Addresses & Ranges in IPv4

Address Block Present Use Reference Assigned
0.0.0.0/8 “This” Network RFC 1122, Section 3.2.1.3 1981-09
10.0.0.0/8 Private-Use Networks RFC 1918 1996-02
100.64.0.0/10 Shared Address Space
Carrier-Grade NAT (CGN)
RFC 6598, Section 7 2012-04
127.0.0.0/8 Loopback RFC 1122, Section 3.2.1.3 1981-09
169.254.0.0/16 Link Local RFC 3927 2005-05
172.16.0.0/12 Private-Use Networks RFC 1918 1996-02
192.0.0.0/24 IETF Protocol Assignments RFC 5736 2010-01
192.0.0.0/29 DS-Lite RFC 6333 2011-06
192.0.2.0/24 Documentation (TEST-NET-1) RFC 5737 2010-01
192.88.99.0/24 6to4 Relay Anycast RFC 3068 2001-06
192.168.0.0/16 Private-Use Networks RFC 1918 1996-02
198.18.0.0/15 Network Interconnect Device Benchmark Testing RFC 2544 1999-03
198.51.100.0/24 Documentation (TEST-NET-2) RFC 5737 2010-01
203.0.113.0/24 Documentation (TEST-NET-3) RFC 5737 2010-01
224.0.0.0/4 Multicast RFC 3171 1999-08
240.0.0.0/4 Reserved for Future Use RFC 1112, Section 4 1989-08
255.255.255.255/32 Limited Broadcast RFC 919, Section 7
RFC 922, Section 7
1984-10

Reserved Address & Ranges in IPv6

Address Block Present Use Reference Assigned
::1/128 Loopback Addresss RFC 4291 2006-02
64:ff9b::/96 IPv4-IPv6 Translation RFC 6052 2010-10
::ffff:0:0/96 IPv4-mapped Address RFC 4291 2006-02
100::/64 Discard-Only Address Block RFC 6666 2012-06
2001::/23 IETF Protocol Assignments RFC 2928 2000-09
2001::/32 TEREDO RFC 4380 2006-01
2001:2::/32 Benchmarking RFC 5180 2008-04
2001:10::/28 ORCHID RFC 5180 2007-03 (ex-2014-03)
2001:db8::/32 Documentation RFC 3849 2004-07
2002:::/16 6to4 RFC 3056 2001-02
fc00::/7 Unique-Local RFC 4193 2005-10
fe80::/10 Linked-Scoped Unicast RFC 4291 2006-02
ff00::/8 Multicast Address Space RFC 4291 (node),
RFC 3307 (link)
Registry

References

IPv6 Transition Schemes: tunnels, 6over4, 6to4, 6rd

6rd

  • RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) — Protocol Specification; IETF; ISSN: 2070-1721; W. Townsley, O. Troan (Cisco); 2010-08.
  • RFC 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd); IETF; ISSN: 2070-1721; R. Despres (RD-IPtech); 2010-01.

Scheme

  • Protocol 41
  • 6rd is modified 6to4
  • CPE
    • IPv6 => address as prefix:V4ADDR::/64 (with prefix padded to /32)
    • IPv4 => tunnel endpoint is ISP link-level routable; e.g. public or RFC 1918
  • ISP
    • IPv6 => prefix is /32-or smaller and ISP-specific
      i.e. not 2002::/16 as that is shared by all ISPs
    • IPv4 => tunnel endpoint is anycast 192.88.99.0/24
      e.g. 192.88.99.201, but not 192.88.99.1 of 6to4

6to4

  • RFC 3964 Security Considerations for 6to4; IETF; P. Savola (CSC/FUNET), C. Patel (All Play, No Work); 2004-12.
  • RFC 3068 An Anycast Prefix for 6to4 Relay Routers; IETF; C. Huitema; 2001-06.
  • RFC 3056 Connection of IPv6 Domains via IPv4 Clouds; IETF; B. Carpenter, K. Moore; 2001-02.

Scheme

  • Protocol 41
  • CPE
    • IPv6 => addressed as 2002:CPEv4ADDR::/48
    • IPv4 => CPEv4ADDR (however that is assigned).
  • ISP
    • IPv6 => prefix is 2002::/16
      • unicast => 2002:ISPv4ADDR::/48 for configured ISPv4ADDR
      • anycast => 2002:c058:6301::/48
    • IPv4 => tunnel endpoint is a unicast or anycast address
      • unicast => any link-level routable address, as seen from the CPE
      • anycast => in 192.88.99.0/24, but 192.88.99.1

6over4 – General Transition Mechanisms

  • RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers; R. Gillian (FreeGate), E. Nordmark (Sun); 2000-08.
  • RFC 2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels, B. Carpenter (IBM), C. Jung (3Com); 1999-03.
  • RFC 1933 Transition Mechanisms for IPv6 Hosts and Routers; R. Gilligan, E. Nordmark (Sun); 1999-04; obsoleted by RFC 2893

Scheme

  • Protocol 41
  • Scope <quote snip=”true”>
    • Dual IP layer (also known as Dual Stack): complete support for IPv4 and IPv6 at hosts & routers.
    • Configured tunneling of IPv6 over IPv4: Point-to-point tunnels made by encapsulating IPv6 packets within IPv4 headers to carry them over IPv4 routing infrastructures.
    • IPv4-compatible IPv6 addresses: An IPv6 address format embedding embedded IPv4 addresses.
    • Automatic tunneling of IPv6 over IPv4: IPv4-compatible addresses to automatically tunnel IPv6 packets over IPv4 networks.</quote>
  • IPv4 address embedded in IPv6 at 0::/96
    • IPv4 => IPv4ADDR/32
    • IPv6 => 0::IPv4ADDR/128
  • Node Classes
    • IPv4-only node
    • IPv4/IPv6 node (also considered an IPv6 node)
    • IPv6 node
  • Address Cases
    • IPv4-compatible IPv6 address (i.e. within. 0::/96)
    • IPv6-native address
  • Tunnels
  • Rules with IPv4 address space embedded into IPv6 at 0::/96
    • routing
    • DNS
    • DHCP
    • BOOTP
    • RARP
    • ICMP
  • “regular” IPv6 address assignment
  • IPv4 is a link-level transport
  • “regular” link routing & gateway management

Publish Subscribe, Persistent Messaging, Real-Tme Low-Latency Filters

Aggregations & Synthesis

Promotions

RFC 2526: Reserved IPv6 Subnet Anycast Addresses

RFC 2526: Reserved IPv6 Subnet Anycast Addresses; IETF; D. Johnson (CMU), S. Deering (Cisco); 1999-03.

<quote>Specifically, for IPv6 address types required to have to have 64-bit interface identifiers in EUI-64 format, these reserved subnet anycast addresses are constructed as follows:

|              64 bits            |      57 bits     |   7 bits   |
+---------------------------------+------------------+------------+
|           subnet prefix         | 1111110111...111 | anycast ID |
+---------------------------------+------------------+------------+
                                  |   interface identifier field  |

For other IPv6 address types (that is, with format prefixes other than those listed above), the interface identifier is not in EUI-64 format and may be other than 64 bits in length; these reserved subnet anycast addresses for such address types are constructed as follows:

|              n bits             |    121-n bits    |   7 bits   |
+---------------------------------+------------------+------------+
|           subnet prefix         | 1111111...111111 | anycast ID |
+---------------------------------+------------------+------------+
                                  |   interface identifier field  |