text:
The story of my Ph.D. is a story of bitter compromises. A story of compromising research for paid work. A story of abandoning promising research to be able to finish. Probably not that different than any other Ph.D.
Since memories are subjective and malleable, it may not be a completely accurate story. All departures from the true events are solely my faults. Moreover, I am not trying to convey any lessons learnt just yet. I just want to tell the story of my Ph.D. I guess it all makes some sense in retrospect, as if the future was a product of the past.
While I could retrace ever so tenuous links way back, the story of my Ph.D. really began in November 2010 in Cologne, Germany. I was there for the Semantic Web in Bibliotheken (SWIB) conference as a co-author of one of the accepted papers. At the conference I met Sören Auer, there to promote the PUBLINK programme of the LOD2 project. While we talked over a coffee break I suggested that the Czech National Library of Technology, where I worked at the time, could use the consulting from linked open data experts offered in the PUBLINK programme. We exchanged business cards and parted our ways. It was the last time I had business cards. They were colourful and sloppy, manually cut from a thin paper. Still, they helped me to forge one of the most impactful connections for my Ph.D.
Weeks later I received an email from Sören, who concluded that we are qualified enough not to need help from the LOD2 project, and instead asked if we would consider joining the project as partners to represent the "Eastern Europe". Well, Czechs like to think they are a part of the "Central Europe", but I gladly seized this opportunity.
After some discussion it became clear that the National Library of Technology did not have the workforce required to join the LOD2 project. I turned to my next closest institution: the University of Economics in Prague, where I already worked on bibliographic linked data that paid for my November trip to Cologne. There was a small team, led by Vojtěch Svátek, already involved in semantic web research for a number of years. To make this team stronger, we formed a strategic alliance with the group of Martin Nečaský from the Faculty of Mathematics and Physics at the Charles University in Prague, thereby transgressing the traditional organizational boundaries. This union later proved successful and lasted through many research projects we worked on together. It perhaps contributed to our affiliations blending in the minds of our foreign project partners to a nebulous concept of the "University of Prague".
Having secured a team, we needed a challenge it could work on. I started writing down a proposal that later turned into a part of the LOD2 project applying linked open data for running a distributed marketplace of public sector contracts. I based it on a suspicion that linked open data can serve as a better infrastructure for online markets. In such infrastructure, I surmised, we could operate matchmakers to link relevant demands and offers.
No idea is truly novel, and this one was no different. Its key inspiration came from Michael Hausenblas, whom I met at the Linked Data Research Centre at DERI (now Insight Centre for Data Analytics) in Galway, Ireland, where I worked as an intern in 2010. Michael had similar thoughts earlier and came up with Call for Anything, a lightweight vocabulary for machine-readable descriptions of demands on the Web, and prototyped an application matching developers to businesses using the vocabulary. There already was a well-known vocabulary for describing offers on the Web: GoodRelations by Martin Hepp. Call for Anything and GoodRelations clicked into place and I exchanged emails with Michael and Martin, thinking through an example application of matchmaking, which informed what later became our contribution to the LOD2 project.
What we lacked was a market in which data on both supply and demand is available. Earlier in 2010, when forming the nascent Czech open data initiative, we picked public contracts as a high-value dataset to screen-scrape and release as machine-readable linked open data. Public procurement market seemed to be a great setting for our work, since public contracts are demands explicitly represented as data as public procurement notices thanks to their proactive disclosure mandated by law.
We thought these poorly formed ideas through, enveloped them in profound academese, and eventually submitted them as an extension proposal for the LOD2 project.
The proposal was successful and in September 2011 we joined the LOD2 project, getting us three years of funding. It would be a perfect time for a Ph.D. if only I had already completed my Masters. I faced a dilemma later prominent in my Ph.D.: compromising paid work for educational progress. Moreover, back then I still worked part-time at the National Library of Technology. Nevertheless, I decided to fit everything in my limited waking hours and joined the University of Economics as an external researcher working on the LOD2 project.
By the end of 2011 it was clear to me that splitting my time between work and education leads to hardly any progress in either of them. As my former position was no longer tenable, in February 2012 I quit the National Library of Technology to focus on finishing my master's thesis.
In the following months I started running up into the limits of part-time contracts at the University of Economics. The only reasonable way for me to work more on the LOD2 project was to enroll in the university's Ph.D. programme in applied computer science. There were no research ambitions at the beginning of my Ph.D. What made me apply for it was a practical concern to be able to continue in work that I found interesting. I applied for the Ph.D. and successfully completed the admission exams in May 2012. When in June 2012 I graduated from the Charles University with a master's degree in new media studies, I was set to pursue the Ph.D. However, even back then I was asking myself: Is there life after Ph.D.?
I officially began my Ph.D. on September 20, 2012. I started it believing the widespread myth that Ph.D. is the only opportunity in life to focus on a single thing and explore it in depth. I quickly realized how far detached from the reality this myth is.
Besides researching your Ph.D. topic many other duties compete for your attention. First and foremost, as a Ph.D. student I was required to teach. A cynical view has it that Ph.D. students are little more than a cheap resource to provision teaching. I was fortunate enough to be assigned with courses at least tangentially related to my Ph.D., including labs in an XML course and several lectures and labs in a course on linked data. The less lucky ones ended up teaching things like the basic Microsoft Office skills.
While teaching can be satisfying and meaningful at times, it also takes a huge amount of time to do it right, especially when you start a new course. The effort spent on teaching has sporadic returns. Rarely you hear any positive feedback, and given that one of the university's primary goals is to produce the most graduates, you often experience frustration with disinterested and unmotivated students who expect their graduation to be simply a matter of time. Under this impression, after a year, I decided to forfeit the Ph.D. stipend in order not to be required to teach.
Compared to teaching, other Ph.D. duties were relatively minor and infrequent. Once in a while I had to supervise bachelor's or master's theses and oversee admission exams of new students. I enjoyed the apprenticeship of supervising theses more than teaching, although few students invested more than required for a minimum viable thesis. Then there were academic duties that went without explicit acknowledgement, such as peer review, contributing to the bulk of unpaid labour that an obedient member of academia delivers.
The courses I was required to attend were largely irrelevant to the pursuit of my Ph.D. While I endured a course in IT management, I wondered why the courses on statistics or programming were left out of the curriculum. In retrospect, probably the most relevant was the introductory course on basic scientific methods, though it was definitely rudimentary.
Let's talk money. My Ph.D. stipend amounted to 5400 CZK per month, which was 216 EUR, or 75.8 % of the minimal net wage at the time in the Czech Republic. Back then it was roughly what you would pay for renting a room in a shared apartment in Prague. Since the stipend could not cover the cost of living, I had to find other sources of income, most notable ones being research projects, typically involving uncertain part-time and fixed-term work. I was decidedly a part of the Ph.D. precariat, always compromising my research for paid work.
The habit of following interesting work led me astray from my Ph.D. from time to time. For instance, between January 2013 and May 2014 I followed an opportunity to work with friends from new media studies at the Charles University on a project using semantic web technologies for the long tail of the job market. Also in January 2013 I achieved a minor impact of my Ph.D. outside of academia. I was invited as a (charmingly called) "ad-hoc expert" to the European Commission's Public Sector Information group, where I talked on the dire present and the bright futures of public procurement data.
Contrary to my expectations, my actual contributions to the LOD2 project were rarely related to my Ph.D. More often than not I ended up doing the grunt work of data preparation or was swamped in the project admin and the ever-present "dissemination". LOD2 project also allowed me to take the inverse role of what I asked for in 2010 at SWIB. It was the National Library of Israel to which I served as a linked open data expert in the PUBLINK programme. As a result, when the LOD2 project successfully concluded in September 2014 most of my Ph.D. work was still left to be done.
When the LOD2 project ended my future funding was unclear. By that time our proposal for a follow-up Horizon 2020 project called OpenBudgets.eu was rejected.
I used the gap in funding to do a Ph.D. internship at Politecnico di Bari, Italy, joining the research group of Tommaso di Noia between October and December 2014. It was an easy choice. When I surveyed the research literature on matchmaking (the topic of my Ph.D. thesis), I found many links pointing to Bari. In a fortunate turn of affairs, I managed to obtain my university's internal funding just in time for this internship. Working through a tight series of deadlines I completed my last required Ph.D. courses and re-enrolled as a full-time student in order to be eligible for the internship stipend. This internship was in fact the only period when I could be entirely dedicated to my Ph.D. It was essential in building the fundamental parts of what later became my thesis. I can heartily recommend going abroad for a few months to do such an internship.
Immediately after my Bari gig, in January 2015, I followed with a one-month internship at the University of Göttingen, Germany, working with library data on old prints. Here again, I returned back to my roots in libraries. Also, I received a decent funding that sorted out my financial situation for another month and filled in some gaps from the previous period that the university's stipend failed to cover.
Since the research project funding at the University of Economics dried out, I arranged a part-time job for EEA from February to September 2015 working on the COMSODE project. There, I assumed a role of data janitor, tirelessly ETL-ing many government datasets. It gave me a novel perspective on the well-known setting of EU research projects. Working for a commercial project partner meant two things improved significantly: management and funding.
A peculiar turn of events took place in spring 2015. While it previously came short, the OpenBudgets.eu project was eventually funded and we were expected to start working on it as soon as possible, despite any plans we made in the meantime. I reluctantly accepted a part-time involvement on the project, starting in May 2015. With mixed feelings, I asked for a break from my Ph.D., lasting till September 2015 when my contract with EEA ended. Due to the workload I imposed on myself, I was simply unable to fit the Ph.D. in.
In order to maintain my sanity during my long Ph.D. journey I occasionally worked on things whimsical. One of these "extra-curricular" efforts was DB-quiz, a Wikipedia-based knowledge game imitating a well-known Czech TV show. I found these activities fulfilling, perhaps because they helped me establish a sense in my Ph.D. in opposition to a clear nonsense. Obviously, I could not settle for anything halfway, so I followed through with the joke to the very end and turned DB-quiz into an academic paper, later winning a prize for the best Ph.D. publication at the University of Economics.
At the end of 2015 I found myself with barely any progress in my Ph.D. It started to dawn on me that, if I am to finish at all, I need to live off my savings for a while instead of always hunting piecemeal income. Consequently, since 2016 I started carefully reducing paid work to make room for research. Since then my savings followed a decidedly declining slope.
I dedicated most of January to preparation for the doctoral state exam required after 3 years of Ph.D. The next month I passed the exam, albeit with a barely satisfying performance, and ticked off another Ph.D. duty: submitted a paper to my university's Ph.D. symposium. With these tasks out of the way there was only one thing left to do: my thesis.
September 2016 marked the start of the final year-long grind on my thesis. In fall of 2016 I thoroughly redone the entire data preparation, meticulously documenting its every step and improving my crude data processing tools on the way.
In December 2016, while entirely immersed in ETL of public procurement data, I realized that I forgot about the deadline for the preliminary thesis defense. By the end of the fourth year every Ph.D. student at my university is obliged to defend an 80% ready thesis. I started hastily piecing up my notes and former publications to meet my deadline coming up in February.
My thesis had meagre 60 pages when I submitted it to the preliminary defense. Yet I managed to conditionally pass the defense thanks to otherwise outstanding results, judged by the modest standards of my university. The stipulated condition was that the thesis would be reviewed once more before the final defense.
Amidst the continued demise of my savings I was running out of options. I was piecing my income by context-switching between several part-time projects at my university. I needed another financial boost, one final kick before I was done with the Ph.D. The strategic alliance with Martin Nečaský came in handy again. Via this link I became a part-time open data expert at the Ministry of Interior of the Czech Republic, working on linked open data in statistics. During the summer of 2017 I pooled my time between this job, my thesis, and OpenBudgets.eu.
The problem with Ph.D. is that it grows without bounds. There is no way of telling that a Ph.D. is done, except the (arbitrary and untimely) end you set for yourself. When by the end of June I signed up as a full-time (linked) data engineer in pharmaceutical industry starting in October, I knew I had exactly 3 months left to finish my thesis. After that point I assumed there would simply be no time to work on the thesis anymore.
With a self-imposed deadline in sight I accepted the need for a bitter compromise. Compared with the original ambitions I left out many interesting experiments to be tried out. By the end of September I was mostly done, given my reduced work scope. Consequently, I passed the additional thesis pre-defense with no problems, giving me a green light to submit the final version of my thesis.
Unfortunately, despite my careful planning I did not manage to hand in my thesis before starting a full-time job. Due to an illness the thesis writing spilt by some weeks into October, with me working the evenings on final editing. I submitted my Ph.D. thesis on October 18. I was done. In relief, I tweeted:
Submitting your Ph.D. thesis feels like a large open wound you've been bleeding from for years finally started healing. A nice feeling.
Apart from my turning in the thesis there were several other supplements I had to provide, the most puzzling one being a 20-page summary of the thesis. Frankly, who reads a 20-page summary? I thought people read either the abstract or the whole damn thing. Reservations aside, I bit the bullet once again and played by the rules.
On January 25, 2018, I passed my Ph.D. viva, with all committee votes unequivocally supporting my graduation. Finishing the Ph.D. was, first and foremost, a testament to my stubbornness, not to my research prowess. It took me 5 years, 4 months, and 5 days. It takes a lot of patience and grit to persist that long.
People are ridiculously bad at answering "what if" questions. Nevertheless, I believe I would not sit idly had I not enrolled in the Ph.D. I believe I would be doing something just as interesting. Hence, my overall evaluation of the Ph.D. is exactly neutral.
However, I could not disregard the Ph.D.'s negative externalities. The Ph.D. levied a toll on my relationships with others. Oftentimes I grew cold, moody, and unresponsive, as I was churning through the flexible working hours for a precarious income. I definitely was not the cheeriest lad around.
While I explicitly avoid any lessons for others here, there were lessons I learnt. I have grown ever so cynical. I have learnt not to care much for deadlines, adopting the attitude of Douglas Adams: "I love deadlines. I like the whooshing sound they make as they fly by." Finally, I have learnt to understand that "adversity and existence are one and the same."


text:
Internet Engineering Task Force (IETF) B. Carpenter, Ed. Request for Comments: 7421 Univ. of Auckland Category: Informational T. Chown ISSN: 2070-1721 Univ. of Southampton F. Gont SI6 Networks / UTN-FRH S. Jiang Huawei Technologies Co., Ltd A. Petrescu CEA, LIST A. Yourtchenko Cisco January 2015 Analysis of the 64-bit Boundary in IPv6 Addressing Abstract The IPv6 unicast addressing format includes a separation between the prefix used to route packets to a subnet and the interface identifier used to specify a given interface connected to that subnet. Currently, the interface identifier is defined as 64 bits long for almost every case, leaving 64 bits for the subnet prefix. This document describes the advantages of this fixed boundary and analyzes the issues that would be involved in treating it as a variable boundary. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7421. Carpenter, et al. Informational [Page 1]
RFC 7421 Why 64 January 2015 Copyright Notice Copyright (c) 2015 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Advantages of a Fixed Identifier Length . . . . . . . . . . . 4 3. Arguments for Shorter Identifier Lengths . . . . . . . . . . 5 3.1. Insufficient Address Space Delegated . . . . . . . . . . 5 3.2. Hierarchical Addressing . . . . . . . . . . . . . . . . . 6 3.3. Audit Requirement . . . . . . . . . . . . . . . . . . . . 7 3.4. Concerns over ND Cache Exhaustion . . . . . . . . . . . . 7 4. Effects of Varying the Interface Identifier Length . . . . . 8 4.1. Interaction with IPv6 Specifications . . . . . . . . . . 8 4.2. Possible Failure Modes . . . . . . . . . . . . . . . . . 10 4.3. Experimental Observations . . . . . . . . . . . . . . . . 12 4.3.1. Survey of the processing of Neighbor Discovery Options with Prefixes Other than /64 . . . . . . . . 12 4.3.2. Other Observations . . . . . . . . . . . . . . . . . 14 4.4. Implementation and Deployment Issues . . . . . . . . . . 14 4.5. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Normative References . . . . . . . . . . . . . . . . . . 17 6.2. Informative References . . . . . . . . . . . . . . . . . 21 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Carpenter, et al. Informational [Page 2]
RFC 7421 Why 64 January 2015 1. Introduction Rather than simply overcoming the IPv4 address shortage by doubling the address size to 64 bits, IPv6 addresses were originally chosen to be 128 bits long to provide flexibility and new possibilities. In particular, the notion of a well-defined interface identifier was added to the IP addressing model. The IPv6 addressing architecture [RFC4291] specifies that a unicast address is divided into n bits of subnet prefix followed by (128-n) bits of interface identifier (IID). The bits in the IID may have significance only in the process of deriving the IID; once it is derived, the entire identifier should be treated as an opaque value [RFC7136]. Also, since IPv6 routing is entirely based on variable length prefixes (also known as variable length subnet masks), there is no basic architectural assumption that n has any particular fixed value. All IPv6 routing protocols support prefixes of any length up to /128. The IID is of basic importance in the IPv6 stateless address autoconfiguration (SLAAC) process [RFC4862]. However, it is important to understand that its length is a parameter in the SLAAC process, and it is determined in a separate link-type specific document (see the definition of "interface identifier" in Section 2 of RFC 4862). The SLAAC protocol does not define its length or assume any particular length. Similarly, DHCPv6 [RFC3315] does not include a prefix length in its address assignment. The notion of a /64 boundary in the address was introduced after the initial design of IPv6, following a period when it was expected to be at /80. There were two motivations for setting it at /64. One was the original "8+8" proposal [ODELL] that eventually led to the Identifier-Locator Network Protocol (ILNP) [RFC6741], which required a fixed point for the split between local and wide-area parts of the address. The other was the expectation that 64-bit Extended Unique Identifier (EUI-64) Media Access Control (MAC) addresses would become widespread in place of 48-bit addresses, coupled with the plan at that time that auto-configured addresses would normally be based on interface identifiers derived from MAC addresses. As a result, RFC 4291 describes a method of forming interface identifiers from IEEE EUI-64 hardware addresses [IEEE802], and this specifies that such interface identifiers are 64 bits long. Various other methods of forming interface identifiers also specify a length of 64 bits. The addressing architecture, as modified by [RFC7136], states that: Carpenter, et al. Informational [Page 3]
RFC 7421 Why 64 January 2015 For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. If derived from an IEEE MAC-layer address, they must be constructed in Modified EUI-64 format. The de facto length of almost all IPv6 interface identifiers is therefore 64 bits. The only documented exception is in [RFC6164], which standardizes 127-bit prefixes for point-to-point links between routers, among other things, to avoid a loop condition known as the ping-pong problem. With that exception, and despite the comments above about the routing architecture and the design of SLAAC, using an IID shorter than 64 bits and a subnet prefix longer than 64 bits is outside the current IPv6 specifications, so results may vary. The question is often asked why the subnet prefix boundary is set rigidly at /64. The first purpose of this document is to explain the advantages of the fixed IID length. Its second purpose is to analyze, in some detail, the effects of hypothetically varying the IID length. The fixed-length limits the practical length of a routing prefix to 64 bits, whereas architecturally, and from the point of view of routing protocols, it could be any value up to /128, as in the case of host routes. Whatever the length of the IID, the longest match is done on the concatenation of prefix and IID. Here, we mainly discuss the question of a shorter IID, which would allow a longer subnet prefix. The document makes no proposal for a change to the IID length. The following three sections describe, in turn, the advantages of the fixed-length IID, some arguments for shorter lengths, and the expected effects of varying the length. 2. Advantages of a Fixed Identifier Length As mentioned in Section 1, the existence of an IID of a given length is a necessary part of IPv6 stateless address autoconfiguration (SLAAC) [RFC4862]. This length is normally the same for all nodes on a given link that is running SLAAC. Even though this length is a parameter for SLAAC, determined separately for the link-layer media type of each interface, a globally fixed IID length for all link- layer media is the simplest solution and is consistent with the principles of Internet host configuration described in [RFC5505]. An interface identifier of significant length, clearly separated from the subnet prefix, makes it possible to limit the traceability of a host computer by varying the identifier. This is discussed further in Section 4.5. Carpenter, et al. Informational [Page 4]
RFC 7421 Why 64 January 2015 An interface identifier of significant length guarantees that there are always enough addresses in any subnet to add one or more real or virtual interfaces. There might be other limits, but IP addressing will never get in the way. The addressing architecture [RFC4291] [RFC7136] sets the IID length at 64 bits for all unicast addresses and therefore for all media supporting SLAAC. An immediate effect of fixing the IID length at 64 bits is, of course, that it fixes the subnet prefix length also at 64 bits, regardless of the aggregate prefix assigned to the site concerned, which in accordance with [RFC6177] should be /56 or shorter. This situation has various specific advantages: o Everything is the same. Compared to IPv4, there is no more calculating leaf subnet sizes, no more juggling between subnets, and fewer consequent errors. Network design is therefore simpler and much more straightforward. This is of importance for all types of networks -- enterprise, campus, small office, or home networks -- and for all types of operator, from professional to consumer. o Adding a subnet is easy -- just take another /64 from the pool. No estimates, calculations, consideration, or judgement is needed. o Router configurations are homogeneous and easier to understand. o Documentation is easier to write and easier to read; training is easier. The remainder of this document describes arguments that have been made against the current fixed IID length and analyzes the effects of a possible change. However, the consensus of the IETF is that the benefits of keeping the length fixed at 64 bits and the practical difficulties of changing it outweigh the arguments for change. 3. Arguments for Shorter Identifier Lengths In this section, we describe arguments for scenarios where shorter IIDs, implying prefixes longer than /64, have been used or proposed. 3.1. Insufficient Address Space Delegated A site may not be delegated a sufficiently generous prefix from which to allocate a /64 prefix to all of its internal subnets. In this case, the site may either determine that it does not have enough address space to number all its network elements and thus, at the very best, be only partially operational, or it may choose to use Carpenter, et al. Informational [Page 5]
RFC 7421 Why 64 January 2015 internal prefixes longer than /64 to allow multiple subnets and the hosts within them to be configured with addresses. In this case, the site might choose, for example, to use a /80 per subnet in combination with hosts using either manually configured addressing or DHCPv6 [RFC3315]. Scenarios that have been suggested where an insufficient prefix might be delegated include home or small office networks, vehicles, building services, and transportation services (e.g., road signs). It should be noted that the homenet architecture text [RFC7368] states that Customer Premises Equipment (CPE) should consider the lack of sufficient address space to be an error condition, rather than using prefixes longer than /64 internally. Another scenario occasionally suggested is one where the Internet address registries actually begin to run out of IPv6 prefix space, such that operators can no longer assign reasonable prefixes to users in accordance with [RFC6177]. It is sometimes suggested that assigning a prefix such as /48 or /56 to every user site (including the smallest) as recommended by [RFC6177] is wasteful. In fact, the currently released unicast address space, 2000::/3, contains 35 trillion /48 prefixes ((2**45 = 35,184,372,088,832), of which only a small fraction have been allocated. Allowing for a conservative estimate of allocation efficiency, i.e., an HD-ratio of 0.94 [RFC4692], approximately 5 trillion /48 prefixes can be allocated. Even with a relaxed HD-ratio of 0.89, approximately one trillion /48 prefixes can be allocated. Furthermore, with only 2000::/3 currently committed for unicast addressing, we still have approximately 85% of the address space in reserve. Thus, there is no objective risk of prefix depletion by assigning /48 or /56 prefixes even to the smallest sites. 3.2. Hierarchical Addressing Some operators have argued that more prefix bits are needed to allow an aggregated hierarchical addressing scheme within a campus or corporate network. However, if a campus or enterprise gets a /48 prefix (or shorter), then that already provides 16 bits for hierarchical allocation. In any case, flat IGP routing is widely and successfully used within rather large networks, with hundreds of routers and thousands of end systems. Therefore, there is no objective need for additional prefix bits to support hierarchy and aggregation within enterprises. Carpenter, et al. Informational [Page 6]
RFC 7421 Why 64 January 2015 3.3. Audit Requirement Some network operators wish to know and audit nodes that are active on a network, especially those that are allowed to communicate off- link or off-site. They may also wish to limit the total number of active addresses and sessions that can be sourced from a particular host, LAN, or site, in order to prevent potential resource-depletion attacks or other problems spreading beyond a certain scope of control. It has been argued that this type of control would be easier if only long network prefixes with relatively small numbers of possible hosts per network were used, reducing the discovery problem. However, such sites most typically operate using DHCPv6, which means that all legitimate hosts are automatically known to the DHCPv6 servers, which is sufficient for audit purposes. Such hosts could, if desired, be limited to a small range of IID values without changing the /64 subnet length. Any hosts inadvertently obtaining addresses via SLAAC can be audited through Neighbor Discovery (ND) logs. 3.4. Concerns over ND Cache Exhaustion A site may be concerned that it is open to ND cache exhaustion attacks [RFC3756], whereby an attacker sends a large number of messages in rapid succession to a series of (most likely inactive) host addresses within a specific subnet. Such an attack attempts to fill a router's ND cache with ND requests pending completion, which results in denying correct operation to active devices on the network. One potential way to mitigate this attack would be to consider using a /120 prefix, thus limiting the number of addresses in the subnet to be similar to an IPv4 /24 prefix, which should not cause any concerns for ND cache exhaustion. Note that the prefix does need to be quite long for this scenario to be valid. The number of theoretically possible ND cache slots on the segment needs to be of the same order of magnitude as the actual number of hosts. Thus, small increases from the /64 prefix length do not have a noticeable impact; even 2^32 potential entries, a factor of two billion decrease compared to 2^64, is still more than enough to exhaust the memory on current routers. Given that most link-layer mappings cause SLAAC to assume a 64-bit network boundary, in such an approach hosts would likely need to use DHCPv6 or be manually configured with addresses. It should be noted that several other mitigations of the ND cache attack are described in [RFC6583], and that limiting the size of the cache and the number of incomplete entries allowed would also defeat the attack. For the specific case of a point-to-point link between routers, this attack is indeed mitigated by a /127 prefix [RFC6164]. Carpenter, et al. Informational [Page 7]
RFC 7421 Why 64 January 2015 4. Effects of Varying the Interface Identifier Length This section of the document analyzes the impact and effects of varying the length of an IPv6 unicast IID by reducing it to less than 64 bits. 4.1. Interaction with IPv6 Specifications The precise 64-bit length of the IID is widely mentioned in numerous RFCs describing various aspects of IPv6. It is not straightforward to distinguish cases where this has normative impact or affects interoperability. This section aims to identify specifications that contain an explicit reference to the 64-bit length. Regardless of implementation issues, the RFCs themselves would all need to be updated if the 64-bit rule was changed, even if the updates were small, which would involve considerable time and effort. First and foremost, the RFCs describing the architectural aspects of IPv6 addressing explicitly state, refer, and repeat this apparently immutable value: Addressing Architecture [RFC4291], IPv6 Address Assignment to End Sites [RFC6177], Reserved IIDs [RFC5453], and ILNP Node Identifiers [RFC6741]. Customer edge routers impose /64 for their interfaces [RFC7084]. The IPv6 Subnet Model [RFC5942] points out that the assumption of a /64 prefix length is a potential implementation error. Numerous IPv6-over-foo documents make mandatory statements with respect to the 64-bit length of the IID to be used during the Stateless Autoconfiguration. These documents include [RFC2464] (Ethernet), [RFC2467] (Fiber Distributed Data Interface (FDDI)), [RFC2470] (Token Ring), [RFC2492] (ATM), [RFC2497] (ARCnet), [RFC2590] (Frame Relay), [RFC3146] (IEEE 1394), [RFC4338] (Fibre Channel), [RFC4944] (IEEE 802.15.4), [RFC5072] (PPP), [RFC5121] [RFC5692] (IEEE 802.16), [RFC2529] (6over4), [RFC5214] (Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)), [AERO-TRANS] (Asymmetric Extended Route Optimization (AERO)), [BLUETOOTH-LE] (BLUETOOTH Low Energy), [IPv6-TRANS] (IPv6 over MS/TP), and [IPv6-G9959] (IPv6 packets over ITU-T G.9959). To a lesser extent, the address configuration RFCs themselves may in some ways assume the 64-bit length of an IID (e.g, RFC 4862 for the link-local addresses, DHCPv6 for the potentially assigned EUI- 64-based IP addresses, and Optimistic Duplicate Address Detection [RFC4429] that computes 64-bit-based collision probabilities). The Multicast Listener Discovery Version 1 (MLDv1) [RFC2710] and MLDv2 [RFC3810] protocols mandate that all queries be sent with a link-local source address, with the exception of MLD messages sent Carpenter, et al. Informational [Page 8]
RFC 7421 Why 64 January 2015 using the unspecified address when the link-local address is tentative [RFC3590]. At the time of publication of RFC 2710, the IPv6 addressing architecture specified link-local addresses with 64-bit interface identifiers. MLDv2 explicitly specifies the use of the fe80::/64 link-local prefix and bases the querier election algorithm on the link-local subnet prefix of length /64. The "IPv6 Flow Label Specification" [RFC6437] gives an example of a 20-bit hash function generation, which relies on splitting an IPv6 address in two equally sized, 64-bit-length parts. The basic transition mechanisms [RFC4213] refer to IIDs of length 64 for link-local addresses; other transition mechanisms such as Teredo [RFC4380] assume the use of IIDs of length 64. Similar assumptions are found in 6to4 [RFC3056] and 6rd [RFC5969]. Translation-based transition mechanisms such as NAT64 and NPTv6 have some dependency on prefix length, discussed below. The proposed method [RFC7278] of extending an assigned /64 prefix from a smartphone's cellular interface to its WiFi link relies on prefix length, and implicitly on the length of the IID, to be valued at 64. The Cryptographically Generated Addresses (CGA) and Hash-Based Addresses (HBA) specifications rely on the 64-bit identifier length (see below), as do the Privacy extensions [RFC4941] and some examples in "Internet Key Exchange Version 2 (IKEv2)" [RFC7296]. 464XLAT [RFC6877] explicitly mentions acquiring /64 prefixes. However, it also discusses the possibility of using the interface address on the device as the end point for the traffic, thus potentially removing this dependency. [RFC2526] reserves a number of subnet anycast addresses by reserving some anycast IIDs. An anycast IID so reserved cannot be less than 7 bits long. This means that a subnet prefix length longer than /121 is not possible, and a subnet of exactly /121 would be useless since all its identifiers are reserved. It also means that half of a /120 is reserved for anycast. This could of course be fixed in the way described for /127 in [RFC6164], i.e., avoiding the use of anycast within a /120 subnet. Note that support for "on-link anycast" is a standard IPv6 neighbor discovery capability [RFC4861] [RFC7094]; therefore, applications and their developers would expect it to be available. The Mobile IP home network models [RFC4887] rely heavily on the /64 subnet length and assume a 64-bit IID. Carpenter, et al. Informational [Page 9]
RFC 7421 Why 64 January 2015 While preparing this document, it was noted that many other IPv6 specifications refer to mandatory alignment on 64-bit boundaries, 64-bit data structures, 64-bit counters in MIBs, 64-bit sequence numbers and cookies in security, etc. Finally, the number "64" may be considered "magic" in some RFCs, e.g., 64k limits in DNS and Base64 encodings in MIME. None of this has any influence on the length of the IID but might confuse a careless reader. 4.2. Possible Failure Modes This section discusses several specific aspects of IPv6 where we can expect operational failures with subnet prefixes other than /64. o Router implementations: Router implementors might interpret IETF specifications such as [RFC6164] and [RFC7136] as indicating that prefixes between /65 and /126 (inclusive) for unicast packets on- the-wire are invalid and that operational practices that utilize prefix lengths in this range may fail on some devices, as discussed in Section 4.3.2. o Multicast: [RFC3306] defines a method for generating IPv6 multicast group addresses based on unicast prefixes. This method assumes a longest prefix of 64 bits. If a longer prefix is used, there is no way to generate a specific multicast group address using this method. In such cases, the administrator would need to use an "artificial" prefix from within their allocation (a /64 or shorter) from which to generate the group address. This prefix would not correspond to a real subnet. Similarly, [RFC3956], which specifies the Embedded Rendezvous Point (RP)) allowing IPv6 multicast rendezvous point addresses to be embedded in the multicast group address, would also fail, as the scheme assumes a maximum prefix length of 64 bits. o CGA: The Cryptographically Generated Address format [RFC3972] is heavily based on a /64 interface identifier. [RFC3972] has defined a detailed algorithm showing how to generate a 64-bit interface identifier from a public key and a 64-bit subnet prefix. Changing the /64 boundary would certainly invalidate the current CGA definition. However, the CGA might benefit in a redefined version if more bits are used for interface identifiers (which means shorter prefix length). For now, 59 bits are used for cryptographic purposes. The more bits are available, the stronger CGA could be. Conversely, longer prefixes would weaken CGA. o NAT64: Both stateless NAT64 [RFC6052] and stateful NAT64 [RFC6146] are flexible for the prefix length. [RFC6052] has defined multiple address formats for NAT64. In Section 2 of Carpenter, et al. Informational [Page 10]
RFC 7421 Why 64 January 2015 "IPv4-Embedded IPv6 Address Prefix and Format" [RFC6052], the network-specific prefix could be one of /32, /40, /48, /56, /64, and /96. The remaining part of the IPv6 address is constructed by a 32-bit IPv4 address, an 8-bit u byte and a variable length suffix (there is no u byte and suffix in the case of the 96-bit Well-Known Prefix). NAT64 is therefore OK with a subnet boundary out to /96 but not longer. o NPTv6: IPv6-to-IPv6 Network Prefix Translation [RFC6296] is also bound to /64 boundary. NPTv6 maps a /64 prefix to another /64 prefix. When the NPTv6 Translator is configured with a /48 or shorter prefix, the 64-bit interface identifier is kept unmodified during translation. However, the /64 boundary might be changed as long as the "inside" and "outside" prefixes have the same length. o ILNP: Identifier-Locator Network Protocol (ILNP) [RFC6741] is designed around the /64 boundary, since it relies on locally unique 64-bit node identifiers (in the interface identifier field). While a redesign to use longer prefixes is not inconceivable, this would need major changes to the existing specification for the IPv6 version of ILNP. o Shim6: The Multihoming Shim Protocol for IPv6 (Shim6) [RFC5533] in its insecure form treats IPv6 addresses as opaque 128-bit objects. However, to secure the protocol against spoofing, it is essential to either use CGAs (see above) or HBAs [RFC5535]. Like CGAs, HBAs are generated using a procedure that assumes a 64-bit identifier. Therefore, in effect, secure shim6 is affected by the /64 boundary exactly like CGAs. o Duplicate address risk: If SLAAC was modified to work with shorter IIDs, the statistical risk of hosts choosing the same pseudo- random identifier [RFC7217] would increase correspondingly. The practical impact of this would range from slight to dramatic, depending on how much the IID length was reduced. In particular, a /120 prefix would imply an 8-bit IID and address collisions would be highly probable. o The link-local prefix: While RFC 4862 is careful not to define any specific length of link-local prefix within fe80::/10, the addressing architecture [RFC4291] does define the link-local IID length to be 64 bits. If different hosts on a link used IIDs of different lengths to form a link-local address, there is potential for confusion and unpredictable results. Typically today the choice of 64 bits for the link-local IID length is hard-coded per interface, in accordance with the relevant IPv6-over-foo specification, and systems behave as if the link-local prefix was actually fe80::/64. There might be no way to change this except Carpenter, et al. Informational [Page 11]
RFC 7421 Why 64 January 2015 conceivably by manual configuration, which will be impossible if the host concerned has no local user interface. It goes without saying that if prefixes longer than /64 are to be used, all hosts must be capable of generating IIDs shorter than 64 bits, in order to follow the auto-configuration procedure correctly [RFC4862]. 4.3. Experimental Observations 4.3.1. Survey of the processing of Neighbor Discovery Options with Prefixes Other than /64 This section provides a survey of the processing of Neighbor Discovery options that include prefixes that are different than /64. The behavior of nodes was assessed with respect to the following options: o PIO-A: Prefix Information Option (PIO) [RFC4861] with the A bit set. o PIO-L: Prefix Information Option (PIO) [RFC4861] with the L bit set. o PIO-AL: Prefix Information Option (PIO) [RFC4861] with both the A and L bits set. o RIO: Route Information Option (RIO) [RFC4191]. In the tables below, the following notation is used: NOT-SUP: This option is not supported (i.e., it is ignored no matter the prefix length used). LOCAL: The corresponding prefix is considered "on-link". ROUTE: The corresponding route is added to the IPv6 routing table. NOT-DEF: The default configuration is NOT-SUP, but there is an option to enable ROUTE. IGNORE: The option is ignored as an error. Carpenter, et al. Informational [Page 12]
RFC 7421 Why 64 January 2015 +--------------------+--------+-------+--------+---------+ | Operating System | PIO-A | PIO-L | PIO-AL | RIO | +--------------------+--------+-------+--------+---------+ | FreeBSD 9.0 | IGNORE | LOCAL | LOCAL | NOT-SUP | +--------------------+--------+-------+--------+---------+ | Linux 3.0.0-15 | IGNORE | LOCAL | LOCAL | NOT-DEF | +--------------------+--------+-------+--------+---------+ | Linux-current | IGNORE | LOCAL | LOCAL | NOT-DEF | +--------------------+--------+-------+--------+---------+ | NetBSD 5.1 | IGNORE | LOCAL | LOCAL | NOT-SUP | +--------------------+--------+-------+--------+---------+ | OpenBSD-current | IGNORE | LOCAL | LOCAL | NOT-SUP | +--------------------+--------+-------+--------+---------+ | Win XP SP2 | IGNORE | LOCAL | LOCAL | ROUTE | +--------------------+--------+-------+--------+---------+ | Win 7 Home Premium | IGNORE | LOCAL | LOCAL | ROUTE | +--------------------+--------+-------+--------+---------+ Table 1: Processing of ND options with prefixes longer than /64 +--------------------+--------+-------+--------+---------+ | Operating System | PIO-A | PIO-L | PIO-AL | RIO | +--------------------+--------+-------+--------+---------+ | FreeBSD 9.0 | IGNORE | LOCAL | LOCAL | NOT-SUP | +--------------------+--------+-------+--------+---------+ | Linux 3.0.0-15 | IGNORE | LOCAL | LOCAL | NOT-DEF | +--------------------+--------+-------+--------+---------+ | Linux-current | IGNORE | LOCAL | LOCAL | NOT-DEF | +--------------------+--------+-------+--------+---------+ | NetBSD 5.1 | IGNORE | LOCAL | LOCAL | NOT-SUP | +--------------------+--------+-------+--------+---------+ | OpenBSD-current | IGNORE | LOCAL | LOCAL | NOT-SUP | +--------------------+--------+-------+--------+---------+ | Win XP SP2 | IGNORE | LOCAL | LOCAL | ROUTE | +--------------------+--------+-------+--------+---------+ | Win 7 Home Premium | IGNORE | LOCAL | LOCAL | ROUTE | +--------------------+--------+-------+--------+---------+ Table 2: Processing of ND options with prefixes shorter than /64 The results obtained can be summarized as follows: o The "A" bit in the Prefix Information Options is honored only if the prefix length is 64. This is consistent with [RFC4862], at least for the case where the IID length is defined to be 64 bits in the corresponding link-type-specific document, which is the Carpenter, et al. Informational [Page 13]
RFC 7421 Why 64 January 2015 case for all currently published such documents. [RFC4862] defines the case where the sum of the advertised prefix length and the IID length does not equal 128 as an error condition. o The "L" bit in the Prefix Information Options is honored for any arbitrary prefix length (whether shorter or longer than /64). o Nodes that support the Route Information Option allow such routes to be specified with prefixes of any arbitrary length (whether shorter or longer than /64) 4.3.2. Other Observations Participants in the V6OPS working group have indicated that some forwarding devices have been shown to work correctly with long prefixes such as /80 or /96. Indeed, it is to be expected that forwarding based on the longest prefix match will work for any prefix length, and no reports of this completely failing have been noted. Also, DHCPv6 is in widespread use without any dependency on the /64 boundary. Reportedly, there are deployments of /120 subnets configured using DHCPv6. There have been definite reports that some routers have a performance drop-off or even resource exhaustion for prefixes longer than /64 due to design issues. In particular, some routing chip designs allocate much less space for longer prefixes than for prefixes up to /64 for the sake of savings in memory, power, and lookup latency. Some devices need special-case code to handle point-to-point links according to [RFC6164]. It has been reported that at least one type of switch has a content- addressable memory limited to 144 bits, which is indeed a typical value for commodity components [TCAM]. This means that packet filters or access control lists cannot be defined based on 128-bit addresses and two 16-bit port numbers; the longest prefix that could be used in such a filter is a /112. 4.4. Implementation and Deployment Issues From an early stage, implementations and deployments of IPv6 assumed the /64 subnet length, even though routing was based on prefixes of any length. As shown above, this became anchored in many specifications (Section 4.1) and in important aspects of implementations commonly used in local area networks (Section 4.3). In fact, a programmer might be lulled into assuming a comfortable rule of thumb that subnet prefixes are always /64 and an IID is always of length 64. Apart from the limited evidence in Section 4.3.1, we cannot tell without code inspections or tests Carpenter, et al. Informational [Page 14]
RFC 7421 Why 64 January 2015 whether existing stacks are able to handle a flexible IID length or whether they would require modification to do so. A conforming implementation of an IPv6-over-foo that specifies a 64 bit IID for foo links will of course only support 64. But in a well designed stack, the IP layer itself will treat that 64 as a parameter, so changing the IID length in the IPv6-over-foo code should be all that is necessary. The main practical consequence of the existing specifications is that deployments in which longer subnet prefixes are used cannot make use of SLAAC-configured addresses and require either manually configured addresses or DHCPv6. To reverse this argument, if it was considered desirable to allow auto-configured addresses with subnet prefixes longer than /64, all of the specifications identified above as depending on /64 would have to be modified with due regard to interoperability with unmodified stacks. In fact, [RFC7217] allows for this possibility. Then, modified stacks would have to be developed and deployed. It might be the case that some stacks contain dependencies on the /64 boundary that are not directly implied by the specifications, and any such hidden dependencies would also need to be found and removed. At least one DHCPv6 client unconditionally installs a /64 prefix as on-link when it configures an interface with an address, although some specific operating system vendors seem to change this default behavior by tweaking a client-side script. This is in clear violation of the IPv6 subnet model [RFC5942]. The motivation for this choice is that if there is no router on the link, the hosts would fail to communicate with each other using the configured addresses because the "on-link assumption" was removed in [RFC4861]. This is not really about the magic number of 64, but an implementation may sometimes pick an arbitrary value of prefix length due to the removal of the on-link assumption, and the value chosen will most likely be 64. Typical IP Address Management (IPAM) tools treat /64 as the default subnet length but allow users to specify longer subnet prefixes if desired. Clearly, all IPAM tools and network management systems would need to be checked in detail. Finally, IPv6 is already deployed at many sites, with a large number of staff trained on the basis of the existing standards, supported by documentation and tools based on those standards. Numerous existing middlebox devices are also based on those standards. These people, documents, tools, and devices represent a very large investment that would be seriously impacted by a change in the /64 boundary. Carpenter, et al. Informational [Page 15]
RFC 7421 Why 64 January 2015 4.5. Privacy Issues The length of the interface identifier has implications for privacy [ADDRESS-PRIVACY]. In any case in which the value of the identifier is intended to be hard to guess, whether or not it is cryptographically generated, it is apparent that more bits are better. For example, if there are only 20 bits to be guessed, then at most just over a million guesses are needed, which is well within the capacity of a low-cost attack mechanism. It is hard to state in general how many bits are enough to protect privacy, since this depends on the resources available to the attacker, but it seems clear that a privacy solution needs to resist an attack requiring billions rather than millions of guesses. Trillions would be better, suggesting that at least 40 bits should be available. Thus, we can argue that subnet prefixes longer than say /80 might raise privacy concerns by making the IID guessable. A prefix long enough to limit the number of addresses comparably to an IPv4 subnet, such as /120, would create exactly the same situation for privacy as IPv4 except for the absence of NAT. In particular, a host would be forced to pick a new IID when roaming to a new network to avoid collisions. As mentioned earlier, it is likely that SLAAC will not be used on such a subnet. 5. Security Considerations In addition to the privacy issues mentioned in Section 4.5 and the issues mentioned with CGAs and HBAs in Section 4.2, the length of the subnet prefix affects the matter of defense against scanning attacks [HOST-SCANNING]. Assuming the attacker has discovered or guessed the prefix length, a longer prefix reduces the space that the attacker needs to scan, e.g., to only 256 addresses if the prefix is /120. On the other hand, if the attacker has not discovered the prefix length and assumes it to be /64, routers can trivially discard attack packets that do not fall within an actual subnet. However, assume that an attacker finds one valid address "A" and assumes that it is within a long prefix such as a /120. The attacker then starts a scanning attack by scanning "outwards" from A, by trying A+1, A-1, A+2, A-2, etc. This attacker will easily find all hosts in any subnet with a long prefix, because they will have addresses close to A. We therefore conclude that any prefix containing densely packed valid addresses is vulnerable to a scanning attack, without the attacker needing to guess the prefix length. Therefore, to preserve IPv6's advantage over IPv4 in resisting scanning attacks, it is important that subnet prefixes are short enough to allow sparse allocation of identifiers within each subnet. The considerations are similar to those for privacy, and we can again Carpenter, et al. Informational [Page 16]
RFC 7421 Why 64 January 2015 argue that prefixes longer than say /80 might significantly increase vulnerability. Ironically, this argument is exactly converse to the argument for longer prefixes to resist an ND cache attack, as described in Section 3.4. Denial-of-service attacks related to Neighbor Discovery are discussed in Section 3.4 and in [RFC6583]. One of the mitigations suggested by that document is "sizing subnets to reflect the number of addresses actually in use", but the fact that this greatly simplifies scanning attacks is not noted. For further discussion of scanning attacks, see [HOST-SCANNING]. Note that, although not known at the time of writing, there might be other resource exhaustion attacks available, similar in nature to the ND cache attack. We cannot exclude that such attacks might be exacerbated by sparsely populated subnets such as a /64. It should also be noted that this analysis assumes a conventional deployment model with a significant number of end-systems located in a single LAN broadcast domain. Other deployment models might lead to different conclusions. 6. References 6.1. Normative References [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998, <http://www.rfc-editor.org/info/rfc2464>. [RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, December 1998, <http://www.rfc-editor.org/info/rfc2467>. [RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of IPv6 Packets over Token Ring Networks", RFC 2470, December 1998, <http://www.rfc-editor.org/info/rfc2470>. [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM Networks", RFC 2492, January 1999, <http://www.rfc-editor.org/info/rfc2492>. [RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet Networks", RFC 2497, January 1999, <http://www.rfc-editor.org/info/rfc2497>. [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999, <http://www.rfc-editor.org/info/rfc2526>. Carpenter, et al. Informational [Page 17]
RFC 7421 Why 64 January 2015 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999, <http://www.rfc-editor.org/info/rfc2529>. [RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of IPv6 Packets over Frame Relay Networks Specification", RFC 2590, May 1999, <http://www.rfc-editor.org/info/rfc2590>. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999, <http://www.rfc-editor.org/info/rfc2710>. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001, <http://www.rfc-editor.org/info/rfc3056>. [RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets over IEEE 1394 Networks", RFC 3146, October 2001, <http://www.rfc-editor.org/info/rfc3146>. [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002, <http://www.rfc-editor.org/info/rfc3306>. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>. [RFC3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, September 2003, <http://www.rfc-editor.org/info/rfc3590>. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004, <http://www.rfc-editor.org/info/rfc3810>. [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004, <http://www.rfc-editor.org/info/rfc3956>. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005, <http://www.rfc-editor.org/info/rfc3972>. Carpenter, et al. Informational [Page 18]
RFC 7421 Why 64 January 2015 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005, <http://www.rfc-editor.org/info/rfc4191>. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005, <http://www.rfc-editor.org/info/rfc4213>. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>. [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel", RFC 4338, January 2006, <http://www.rfc-editor.org/info/rfc4338>. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006, <http://www.rfc-editor.org/info/rfc4380>. [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006, <http://www.rfc-editor.org/info/rfc4429>. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, 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, September 2007, <http://www.rfc-editor.org/info/rfc4941>. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>. [RFC5072] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007, <http://www.rfc-editor.org/info/rfc5072>. Carpenter, et al. Informational [Page 19]
RFC 7421 Why 64 January 2015 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008, <http://www.rfc-editor.org/info/rfc5121>. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008, <http://www.rfc-editor.org/info/rfc5214>. [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 5453, February 2009, <http://www.rfc-editor.org/info/rfc5453>. [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009, <http://www.rfc-editor.org/info/rfc5533>. [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 2009, <http://www.rfc-editor.org/info/rfc5535>. [RFC5692] Jeon, H., Jeong, S., and M. Riegel, "Transmission of IP over Ethernet over IEEE 802.16 Networks", RFC 5692, October 2009, <http://www.rfc-editor.org/info/rfc5692>. [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942, July 2010, <http://www.rfc-editor.org/info/rfc5942>. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010, <http://www.rfc-editor.org/info/rfc5969>. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011, <http://rfc-editor.org/info/rfc6146>. [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- Router Links", RFC 6164, April 2011, <http://www.rfc-editor.org/info/rfc6164>. Carpenter, et al. Informational [Page 20]
RFC 7421 Why 64 January 2015 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, March 2011, <http://www.rfc-editor.org/info/rfc6177>. [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011, <http://www.rfc-editor.org/info/rfc6296>. [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, November 2011, <http://www.rfc-editor.org/info/rfc6437>. [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, November 2013, <http://www.rfc-editor.org/info/rfc7084>. [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, February 2014, <http://www.rfc-editor.org/info/rfc7136>. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>. 6.2. Informative References [ADDRESS-PRIVACY] Cooper, A., Gont, F., and D. Thaler, "Privacy Considerations for IPv6 Address Generation Mechanisms", Work in Progress, draft-ietf-6man-ipv6-address-generation- privacy-02, October 2014. [AERO-TRANS] Templin, F., "Transmission of IP Packets over AERO Links", Work in Progress, draft-templin-aerolink-46, October 2014. [BLUETOOTH-LE] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets over BLUETOOTH Low Energy", Work in Progress, draft-ietf- 6lowpan-btle-12, February 2013. [HOST-SCANNING] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", Work in Progress, draft-ietf-opsec-ipv6-host- scanning-04, June 2014. Carpenter, et al. Informational [Page 21]
RFC 7421 Why 64 January 2015 [IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE Std 802-2001 (R2007), 2007. [IPv6-G9959] Brandt, A. and J. Buron, "Transmission of IPv6 packets over ITU-T G.9959 Networks", Work in Progress, draft-ietf- 6lo-lowpanz-08, October 2014. [IPv6-TRANS] Lynn, K., Ed., Martocci, J., Neilson, C., and S. Donaldson, "Transmission of IPv6 over MS/TP Networks", Work in Progress, draft-ietf-6lo-6lobac-00, July 2014. [ODELL] O'Dell, M., "8+8 - An Alternate Addressing Architecture for IPv6", Work in Progress, draft-odell-8+8-00, October 1996. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999, <http://www.rfc-editor.org/info/rfc2629>. [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004, <http://www.rfc-editor.org/info/rfc3756>. [RFC4692] Huston, G., "Considerations on the IPv6 Host Density Metric", RFC 4692, October 2006, <http://www.rfc-editor.org/info/rfc4692>. [RFC4887] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network Mobility Home Network Models", RFC 4887, July 2007, <http://www.rfc-editor.org/info/rfc4887>. [RFC5505] Aboba, B., Thaler, D., Andersson, L., and S. Cheshire, "Principles of Internet Host Configuration", RFC 5505, May 2009, <http://www.rfc-editor.org/info/rfc5505>. [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, March 2012, <http://rfc-editor.org/info/rfc6583>. [RFC6741] Atkinson,, RJ., "Identifier-Locator Network Protocol (ILNP) Engineering Considerations", RFC 6741, November 2012, <http://www.rfc-editor.org/info/rfc6741>. Carpenter, et al. Informational [Page 22]
RFC 7421 Why 64 January 2015 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013, <http://www.rfc-editor.org/info/rfc6877>. [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, January 2014, <http://www.rfc-editor.org/info/rfc7094>. [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, April 2014, <http://www.rfc-editor.org/info/rfc7217>. [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link", RFC 7278, June 2014, <http://www.rfc-editor.org/info/rfc7278>. [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", RFC, 7368, October 2014. [TCAM] Meiners, C., Liu, A., and E. Torng, "Algorithmic Approaches to Redesigning TCAM-Based Systems", ACM SIGMETRICS'08 467-468, 2008. Acknowledgements This document was inspired by a vigorous discussion on the V6OPS working group mailing list with at least 20 participants. Later, valuable comments were received from Ran Atkinson, Fred Baker, Steven Blake, Lorenzo Colitti, David Farmer, Bill Fenner, Ray Hunter, Paraskevi Iliadou, Jen Linkova, Philip Matthews, Matthew Petach, Scott Schmit, Tatuya Jinmei, Fred Templin, Ole Troan, Stig Venaas, and numerous other participants in the 6MAN working group. An extremely detailed review by Mark Smith was especially helpful. This document was originally produced using the xml2rfc tool [RFC2629]. Carpenter, et al. Informational [Page 23]
RFC 7421 Why 64 January 2015 Authors' Addresses Brian Carpenter (editor) Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand EMail: email@example.com Tim Chown University of Southampton Southampton, Hampshire SO17 1BJ United Kingdom EMail: email@example.com Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina EMail: firstname.lastname@example.com Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China EMail: firstname.lastname@example.com Alexandru Petrescu CEA, LIST CEA Saclay Gif-sur-Yvette, Ile-de-France 91190 France EMail: firstname.lastname@example.com Andrew Yourtchenko Cisco 7a de Kleetlaan Diegem 1830 Belgium EMail: firstname.lastname@example.com Carpenter, et al. Informational [Page 24]

subset: commoncrawl


text:
home > en > the taming of the shrew > synopsis
Baptista, a rich Paduan merchant, announces that his fair young daughter, Bianca, will remain unwed until her older sister, Katharina, a hellish shrew, has wed. Lucentio, a student and the son of a wealthy Pisan merchant, has fallen in love with Bianca. He poses as a tutor of music and poetry to gain entrance to the Baptista household and to be near Bianca. Meanwhile, Petruchio, a fortune-hunting scoundrel from Verona, arrives in Padua, hoping to capture a wealthy wife. Hortensio, another suitor of Bianca, directs Petruchio's attention to Katharina. When Hortensio warns him about Katharina's scolding tongue and fiery temper, Petruchio is challenged and resolves to capture her love. Hortensio and another suitor of Bianca, Gremio, agree to cover Petruchio's costs as he pursues Katharina.
Please give your input here.
Wachtwoord vergeten?


text:
The personal information you provide to the Cohen Immigration Law Firm is secure and is collected for the purpose of assessing your potential for immigration to Canada. You may consult our Privacy Policy for complete details.
Please contact us by email if you experience any technical difficulties while using this form.


text:
To speak about professions, you need the appopriate vocabulary. Part 2
Coach - someone whose job is to teach people to improve at a sport, skill, or school subject;
Cobbler - someone whose job is to make or repair shoes;
Confectioner - a company or person that makes or sells sweets or chocolate;
Chef - someone who is the main cook (= person who cooks) in a hotel or a restaurant;
Dentist - someone who examines and repairs teeth;
Doctor - a person whose job is to treat people who have an illness or injury;
Electrician - someone whose job is to put in, check, or repair electrical wires and equipment;
Engineer - someone whose job is to design, build, or repair machines, engines, roads, bridges, etc;
Explorer - someone who travels to places where no one has ever been in order to find out what is there;
Farmer - someone who owns or looks after a farm;
Model - someone whose job is to wear fashionable clothes, be in photographs, etc in order to advertise things;
Firefighter - someone whose job is to stop fires burning;
Florist - someone who sells and arranges flowers in a shop;
Gardener - someone who works in a garden, growing plants and making it look attractive;
Glazier - a person who sells glass or fits it into windows;
Greengrocer - someone who sells fruit and vegetables;
Grocer - someone who owns or works in a grocer's
Hairdresser - someone whose job is to wash, cut, colour, etc people's hair.
I've got an appointment at the dentist's (= where the dentist works) tomorrow.
She is a great gardener. There are many flowers near her house.
Mary was a wonderful model.


text:
Why should you read this document?
During the course of dealing with us, we will ask you to provide us with detailed personal information relating to your existing circumstances, your financial situation and, in some cases, your health and family health history (Your Personal Data). This document is important as it allows us to explain to you what we will need to do with Your Personal Data, and the various rights you have in relation to Your Personal Data.
What do we mean by "Your Personal Data"?
Your Personal Data means any information that describes or relates to your personal circumstances. Your Personal Data may identify you directly, for example your name, address, date or birth, National Insurance number. Your Personal Data may also identify you indirectly, for example, your employment situation, your physical and mental health history, or any other information that could be associated with your cultural or social identity.
In the context of providing you with assistance in relation to your Investment/Mortgage and/or Insurance requirements Your Personal Data may include:
- Title, names, date of birth, gender, nationality, civil/marital status, contact details, addresses and documents that are necessary to verify your identity
- Employment and remuneration information, (including salary/bonus schemes/overtime/sick pay/other benefits), employment history
- Bank account details, tax information, loans and credit commitments, personal credit history, sources of income and expenditure, family circumstances and details of dependents
- Health status and history, details of treatment and prognosis, medical reports (further details are provided below specifically with regard to the processing we may undertake in relation to this type of information)
- Any pre-existing investment/mortgage and/or insurance products and the terms and conditions relating to these
The basis upon which our Firm will deal with Your Personal Data
When we speak with you about your investment/mortgage and/or insurance requirements we do so on the basis that both parties are entering a contract for the supply of services.
In order to perform that contract, and to arrange the products you require, we have the right to use Your Personal Data for the purposes detailed below.
Alternatively, either in the course of initial discussions with you or when the contract between us has come to an end for whatever reason, we have the right to use Your Personal Data provided it is in our legitimate business interest to do so and your rights are not affected. For example, we may need to respond to requests from mortgage lenders, insurance providers and our Compliance Service Provider relating to the advice we have given to you, or to make contact with you to seek feedback on the service you received.
On occasion, we will use Your Personal data for contractual responsibilities we may owe our regulator The Financial Conduct Authority, or for wider compliance with any legal or regulatory obligation to which we might be subject. In such circumstances, we would be processing Your Personal Data in order to meet a legal, compliance or other regulatory obligation to which we are subject.
The basis upon which we will process certain parts of Your Personal Data
Where you ask us to assist you with for example your insurance needs, in particular life insurance and insurance that may assist you in the event of an accident or illness, we will ask you information about your ethnic origin, your health and medical history (Your Special Data). We will record and use Your Special Data in order to make enquiries of insurance providers in relation to insurance products that may meet your needs and to provide you with advice/guidance regarding the suitability of any product that may be available to you.
If you have parental responsibility for children under the age of 13, it is also very likely that we will record information on our systems that relates to those children and potentially, to their Special Data.
The arrangement of certain types of insurance may involve disclosure by you to us of information relating to historic or current criminal convictions or offences (together "Criminal Disclosures"). This is relevant to insurance related activities such as underwriting, claims and fraud management.
We will use special Data and any Criminal Disclosures in the same way as Your Personal Data generally, as set out in this Privacy Notice.
Information on Special Category Data and Criminal Disclosures must be capable of being exchanged freely between insurance intermediaries such as our Firm, and insurance providers, to enable customers to secure the important insurance protection that their needs require.
How do we collect Your Personal Data?
We will collect and record Your Personal Data from a variety of sources, but mainly directly from you. You will usually provide information during the course of our initial meetings or conversations with you to establish your circumstances and needs and preferences in relation to investment/mortgages and insurance. You will provide information to us verbally and in writing, including email.
We may also obtain some information from third parties, for example, credit checks, information from your employer, and searches of information in the public domain such as the voters roll. If we use technology solutions to assist in the collection of Your Personal Data for example software that is able to verify your credit status. We will only do this if we have consent from you for us or our nominated processor to access your information in this manner. With regards to electronic ID checks we would not require your consent but will inform you of how such software operates and the purpose for which it is used.
What happens to Your Personal Data when it is disclosed to us?
In the course of handling Your Personal Data, we will:
- Record and store Your Personal Data in our paper files, mobile devices and on our computer systems (websites, email, hard drives, and cloud facilities). This information can only be accessed by employees and consultants within our Firm and only when it is necessary to provide our service to you and to perform any administration tasks associated with or incidental to that service
- Submit Your Personal Data to Product Providers/Mortgage Lenders/Commercial Lenders and/or Insurance Product providers, both in paper form and on-line via a secure portal. The provision of this information to a third party is essential in allowing us to progress any enquiry or application made on your behalf and to deal with any additional questions or administrative issues that lenders and providers may raise.
- Use Your Personal Data for the purposes of responding to any queries you may have in relation to any investment/mortgage product or insurance policy you may take out, or to inform you of any developments in relation to those products and/or polices of which we might become aware
Sharing Your Personal Data
From time to time Your Personal Data will be shared with:
- Investment Providers/Mortgage lenders and insurance providers.
- Third parties who we believe will be able to assist us with your enquiry or application, or who are able to support your needs as identified. These third parties will include but may not be limited to, our Compliance Advisers, Product specialists, estate agents, providers of legal services such as estate planners, conveyancing, surveyors and valuers (in each case where we believe this to be required due to your particular circumstances).
In each case, your Personal Data will only be shared for the purposes set out in this customer privacy notice, i.e. to progress your investment/mortgage and/or insurance enquiry and to provide you with our professional services.
Please note that this sharing of Your Personal Data does not entitle such third parties to send you marketing or promotional messages: it is shared to ensure we can adequately fulfil our responsibilities to you, and as otherwise set out in this Customer Privacy Notice.
We do not envisage that the performance by us of our service will involve Your Personal Data being transferred outside of the European Economic Area.
Security and retention of Your Personal Data
Your privacy is important to us and we will keep Your Personal Data secure in accordance with our legal responsibilities. We will take reasonable steps to safeguard Your Personal Data against it being accessed unlawfully or maliciously by a third party.
We also expect you to take reasonable steps to safeguard your own privacy when transferring information to us, such as not sending confidential information over unprotected email, ensuring email attachments are password protected or encrypted and only using secure methods of postage when original documentation is being sent to us.
Your Personal Data will be retained by us either electronically or in paper format for a minimum of six years, or in instances whereby we have legal right to such information we will retain records indefinitely.
Your rights in relation to Your Personal Data
You can:
- request copies of Your Personal Data that is under our control
- ask us to further explain how we use Your Personal Data
- ask us to correct, delete or require us to restrict or stop using Your Personal Data (details as to the extent to which we can do this will be provided at the time of any such request)
- ask us to send an electronic copy of Your Personal Data to another organisation should you wish
- change the basis of any consent you may have provided to enable us to market to you in the future (including withdrawing any consent in its entirety)
How to make contact with our Firm in relation to the use of Your Personal Data
If you have any questions or comments about this document, or wish to make contact in order to exercise any of your rights set out within it please contact:
Richard Smith. email@example.com
If we feel we have a legal right not to deal with your request, or to action, it in different way to how you have requested, we will inform you of this at the time.
You should also make contact with us as soon as possible on you becoming aware of any unauthorised disclosure of Your Personal Data, so that we may investigate and fulfil our own regulatory obligations.
If you have any concerns or complaints as to how we have handled Your Personal Data you may lodge a complaint with the UK's data protection regulator, the ICO, who can be contacted through their website at https://ico.org.uk/global/contact-us/ or by writing to Information Commissioner's Office, Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF.


text:
The Wall Street Journal this week documented several, though not all, of the types of market abuse and manipulation that the current outmoded reporting rules permit and facilitate. The existing rules give activists an over-long 10-day period before they are required to report crossing the 5% ownership threshold in publicly traded companies. According to The Wall Street Journal, during the 10-day reporting window, activist hedge funds are "tipping" each other regarding their plans as they coordinate wolf-pack attacks, while ordinary investors and the targeted companies are left in the dark. When finally made, the 13(d) reports are often market-moving. This delivers outsized returns to the activist and those they tip, while injuring investors who are deprived of the same knowledge.
In an era of high frequency trading, the 10-day reporting window adopted by the Williams Act in 1968 simply makes no sense. It is time for the SEC to act on our petition to shorten the reporting window to one day, to adopt a "cooling-off period" of two business days following the public filing of an initial Schedule 13D, during which acquirers would be prohibited from acquiring additional beneficial ownership, and to modernize the definition of "beneficial ownership" under the Section 13 reporting rules to prevent activists from acquiring significant influence and control using a variety of stealth techniques and derivative instruments to evade Section 13D reporting requirements.
The ten day window maybe made sense back in the old days when one filed everything on paper. But in these days of electronic filing, when the SEC has accelerated filing of a host of disclosures, it makes no sense to let 5% holders have 10 days of secrecy. (Assuming you buy the case for any disclosure by 5% holders, of course.)


text:
Student Advisory Board
The Dean's Student Advisory Board is composed of the presidents of the student professional organizations in the Jennings A. Jones College of Business. The Student Advisory Board meets with the Dean for lunch at least once each semester. Issues of concern and importance to students are discussed and solutions to problems are developed.
Student professional organizations are an integral part of the Jennings A. Jones College of Business experience. Students are encouraged to actively participate in one or more of these organizations to help build a network of professional contracts and to expand their real-world knowledge through programs sponsored by the organizations.


text:
§30-7-15c. Form of prescriptions; termination of authority; renewal; notification of termination of authority.
(a) Prescriptions authorized by an advanced practice registered nurse must comply with all applicable state and federal laws; must be signed by the prescriber with the initials "A.P.R.N." or the designated certification title of the prescriber; and must include the prescriber's identification number assigned by the board or the prescriber's national provider identifier assigned by the National Provider System pursuant to 45 C. F. R. §162.408.
(b) Prescriptive authorization shall be terminated if the advanced practice registered nurse has:
(1) Not maintained current authorization as an advanced practice registered nurse; or
(2) Prescribed outside the advanced practice registered nurse's scope of practice or has prescribed drugs for other than therapeutic purposes; or
(3) Has not filed verification of a collaborative agreement with the board if such an agreement is required.
(c) Prescriptive authority for an advanced practice registered nurse must be renewed biennially. Documentation of eight contact hours of pharmacology during the previous two years must be submitted at the time of renewal.
(d) The board shall notify the Board of Pharmacy within twenty-four hours after termination of, or change in, an advanced practice registered nurse's prescriptive authority.


text:
Where there is a new system, there is a new Warriors game waiting in the wings. Tecmo Koei has gotten in early this time, ready for the 3DS' launch with Samurai Warriors Chronicles, yet another button-bashing foray into the world of medieval Japan.
Maybe Tecmo Koei rushed in a little too early this time.
Samurai Warriors Chronicles (3DS)
Developer: Omega Force
Publisher: Tecmo Koei
Released: March 27, 2011
Samurai Warriors Chronicles dispenses with the usual character story modes in favor of something a little more personal. This time around, the likes of Nobunaga Oda and Yukimura Sanada are supporting characters to the real star of the show — the player.
After answering a short quiz, a profile is created for an all-new quasi-silent protagonist, supposed to represent the player as they journey through Sengoku-era Japan and make a name for themselves. Although later on you get to unlock new clothing and armor, there's no real customization, with the player only able to select a male or female character model. Thus begins a running theme with this title — missed opportunities.
The game's story is rather forgettable, despite efforts made to have the player character interact and form bonds with the rest of the cast. Despite the bland narrative, the game forces you to watch it all, with reams of exposition that only become skippable after a stage has been completed or failed once. There's about three or so sequences of unskippable story between each battle, and it becomes quite frustrating when all you want to do is get into the action. On a portable format where battery life is an issue and people often expect instant gameplay action, it's puzzling that so much pointless dialog is forced on the player.
Once the action gets started, things are more pleasant. The action of previous Samurai Warriors games is more or less kept intact, as you hack n' slash your way through expansive maps and cut down the enemy troops, making sure to complete bonus objectives for new weapons and items. There is a wealth of increasingly powerful weapons and combat-boosting equipment to find, so magpie gamers will have plenty to discover,
A new addition to Chronicles is the use of four playable characters per stage. In addition to the main hero, three regular Samurai Warriors officers will be present on the map and can be controlled at any time by touching their portrait on the bottom screen. While it requires a little extra attention (and sometimes babysitting), being able to pick the closest officer to an objective rather than personally traipsing across a map makes for more efficient battles, and it's far easier to complete timed objectives or rescue allies that are close to defeat. You can also order your characters to attack enemies or cover ground while you're not directly controlling them, which is a welcome touch.
It's worth noting that Chronicles is also one of the trickier Warriors games out there. Enemy AI seems to be more aggressive, and your attacks are frequently broken by peons who'll stab you in the back. While the extra difficulty is welcome, it can get very frustrating when you're fighting multiple officers who won't let you get in a shot and take turns juggling your defenseless general.
The challenge doesn't do much to hide the fact that battles, while still pretty good at delivering mindless fun, feel flat and flavorless when compared to the console titles, not to mention superior PSP offerings such as Warriors Orochi. Enemies aren't quite so prevalent, and the environments are more simplistic and bland than ever. Furthermore, the battle is frequently interrupted by objective notifications, which pause the game until you manually exit them. Gameplay is interrupted enough times to qualify as utterly absurd.
There's a distinct lack of personality with Chronicles, and that's not helped by the fact that Tecmo Koei didn't bother to localize the voice acting, leaving us with a Japanese track. While some fans may welcome this, I don't need to sift through text while I'm trying to play the game. As such, a lot of character dialog goes unheard, and battle progress is hard to keep up with. It's a shame, because the game is fully voiced, and that could have been an impressive feat. Instead, it goes barely noticed.
The lack of voice localization typifies the problem with Chronicles — it feels rushed out of the gate in order to be a launch title. From the scaled-down battles to the half-assed localization, Chronicles could have done with a lot more effort put into it before hitting store shelves.
The game's 3D effects work pretty well, although I get a sense that the graphics could have been better than they are. Character models look somewhat jaggy, and enemies regularly pop in and out of view, randomly becoming invisible even if quite nearby. Despite the simplistic visuals, the special moves look particularly flashy in 3D, and there are a number of really cool cutscenes that show off the 3DS' visual gimmickry superbly, even if they do make one feel a little cross-eyed sometimes.
The game is still quite enjoyable, and fans of hack n' slash combat will find enough to keep them occupied, especially given the relatively disappointing selection of 3DS games available right now. However, only the most dedicated of Warriors fans will find the experience compelling enough to keep playing, and even then, there are better portable Warriors games to play. I can't say I dislike the title, because it's a decent enough waste of time. However, it feels like it did enough to get a passing grade, without going the distance and achieving something more substantial.
There's little doubt Omega Force will be back later with a deeper, more robust Warriors title on the 3DS. As far as this one goes, it feels more like a stopgap that's worth borrowing or renting, but can't justify a full cash price.


text:
From: | FROM THE DESK OF THE DIRECTOR INTERNATIONAL PRIZE AWARD DEPT |
Subject: | [dev-serveez] CONGRATULATION!!!!! |
Date: | Thu, 23 Feb 2006 09:14:23 +0300 |
FROM THE DESK OF THE DIRECTOR INTERNATIONAL PRIZE AWARD DEPT Attn Lucky Winner, WINNING NOTIFICATION FOR CATEGORY "A" WINNER ONLY We are pleased to inform you of the result of the last final annual draw of our Lottery International Programs. The online cyber lotto draws was conducted from an exclusive list of 25,000,000 e-mail addresses of individual and corporate bodies picked by an advanced automated random computer search from the internet. No tickets were sold. CONGRATULATIONS!!! After this automated computer ballot, your e-mail address emerged as a winner in the category "A" with the following numbers attached Ref Number: PW 9590 ES 9414,Batch Number: 573881545-NL/2005 and Ticket Number: PP 3502 /8707-01 You are therefore to receive a cash prize of $1,500,000.00. (One Million Five Hundred Thousand United States Dollars) from the total payout CONGRATULATIONS!!!. Your prize award has been insured with your e-mail address and will be transferred to you upon meeting our requirements, statutory obligations, verifications, validations and satisfactory report. To file in for the processing of your prize winnings, you are advised to contact our Certified and Accredited claims agent for category "A" winners with the information below: ************************************* Name: Palmer Chris Phone: +31 645 533 149 Email: address@hidden Email:address@hidden ************************************* You are advice to provide him with the following information: Names: Telephone/Fax number: Nationality: Age: NOTE: All winnings must be claimed not later than 14 days, thereafter unclaimed funds would be included in the next stake. Remember to quote your reference information in all correspondence. You are to keep all lotto information confidential, especially your reference and ticket numbers. (This is important as a case of double claims will not be entertained).Members of the affiliate agencies are automatically not allowed to participate in this program. Furthermore, should there be any change of address do inform our agent as soon as possible. Congratulations once more from our members of staff and thank you for being part of our promotional program. Yours Faithfully, Walter Jones. Lottery Coordinator. Thank you and congratulations!!! This email may contain information which is confidential and/or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents is prohibited. If you have received this electronic transmission in error,please notify the sender by telephone or return email and delete the material from your computer.
[Prev in Thread] | Current Thread | [Next in Thread] |


text:
Hip Replacement
Hip replacement is a surgery performed to replace parts of a diseased hip joint with a prosthesis. The goal of hip replacement is to eliminate pain and enable you to return to your normal activities. You can help in the recovery and improve the outcomes of the procedure by following certain precautions and changing the way you carry out your daily activities.
After the Surgery
You will be discharged from the hospital once you have sufficient pain control and are able to perform basic activities on your own, such as getting in and out of bed, going to the bathroom and walking with an assistive device such as crutches or a walker. If you are unable to perform these activities, you will be transferred to a skilled nursing or rehabilitation center.
At home, have a family member or caregiver to assist you with your activities for a few weeks. Ensure that furniture is rearranged so as not to interfere with your movement and cause falls. To avoid bending or reaching out, items that you use frequently can be placed within easy reach. Try to sit on a high chair so that your knees are not lifted above the level of your hip. Do not cross your legs or lean forward while sitting. A shower chair or gripping bar may be helpful in the bathroom. Make use of long shoehorns, long-handled sponges, and other devices that can help you reach objects without bending. Try to sleep with a pillow between your legs. Your doctor will advise you on correct sleeping positions.
Keep the wound clean and dry. Your doctor will let you know when you can shower or bathe. Swelling may be present for 3 to 6 months following hip replacement and can be controlled with ice and by elevating your legs slightly. You may be asked to bear only partial weight on the leg for a while. Follow your physical therapy program for at least 2 months. Walking, stationary bicycling and swimming are good exercises but ensure that your wound is completely healed.
You must be aware of the signs of infection or blood clot formation and quickly return to the hospital should you develop more than normal pain, swelling, redness, fever, chills or drainage from the wound.
Your doctor will decide when you can engage in your regular activities, resume work, start driving and return to sexual activity depending on your condition and progress with therapy.