Enterprise IPv6 Deployment Guidelines

Kuarsingh, Victor; Lee, Howard; Vyncke, Eric; Chown, Tim; Chittimaneni, Kiran Kumar; Pouffary, Yanick

doi:10.17487/rfc7381

Cited by 7 publications

(8 citation statements)

References 27 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Given a set of hosts, our strategy is to use DNS names as the basic connective tissue between hostnames, IPv4 addresses, and IPv6 addresses. One reason for this approach is that "DNS is one of the main anchors in an enterprise [IPv6] deployment, since most end hosts decide whether or not to use IPv6 depending on the presence of IPv6 AAAA records..." [14]. Each host H x in our dataset contains three sets of labels that represent H x : H x N is the set of names, H x 4 is a set of IPv4 addresses and H x 6 is a set of IPv6 addresses.…”

Section: A Developing Target Listsmentioning

confidence: 99%

“…Standards and deployment guides (e.g., [14], [23], [26], [32]) have been urging operators to apply firewall rules and access control lists for IPv6 in parity with IPv4 as part of their deployment of IPv6. Unfortunately, security researchers as well as RFC authors have lamented that in practice: "networks tend to overlook IPv6 security controls: [often] there is no parity in the security controls [between] IPv6 and IPv4" [5], and "in new IPv6 deployments it has been common to see IPv6 traffic enabled but none of the typical access control mechanisms enabled for IPv6" [15].…”

Section: Related Workmentioning

confidence: 99%

“…Part of the problem for vendors and operators alike is that there are nontrivial technical hurdles to fully supporting IPv6, especially in policy devices, such as firewalls and IDSes. For instance, due to the flexibility of IPv6 header chains and issues related to fragmentation, simple stateless firewalls, which may have sufficed for IPv4, are not appropriate in IPv6 [14], [19]. While this issue was addressed in a standards document that requires the first fragment to contain the transport headers [27], it will likely take time for compatible hardware and practices to permeate the network.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Don’t Forget to Lock the Back Door! A Characterization of IPv6 Network Security Policy

Czyz¹,

Luckie²,

Allman³

et al. 2016

Proceedings 2016 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

There is growing operational awareness of the challenges in securely operating IPv6 networks. Through a measurement study of 520,000 dual-stack servers and 25,000 dual-stack routers, we examine the extent to which security policy codified in IPv4 has also been deployed in IPv6. We find several high-value target applications with a comparatively open security policy in IPv6 including: (i) SSH, Telnet, SNMP, are more than twice as open on routers in IPv6 as they are in IPv4; (ii) nearly half of routers with BGP open were only open in IPv6; and (iii) in the server dataset, SNMP was twice as open in IPv6 as in IPv4. We conduct a detailed study of where port blocking policy is being applied and find that protocol openness discrepancies are consistent within network boundaries, suggesting a systemic failure in organizations to deploy consistent security policy. We successfully communicate our findings with twelve network operators and all twelve confirm that the relative openness was unintentional. Ten of the twelve immediately moved to deploy a congruent IPv6 security policy, reflecting real operational concern. Finally, we revisit the belief that the security impact of this comparative openness in IPv6 is mitigated by the infeasibility of IPv6 network-wide scanning-we find that, for both of our datasets, host addressing practices make discovering these high-value hosts feasible by scanning alone. To help operators accurately measure their own IPv6 security posture, we make our probing system publicly available. Permission to freely reproduce all or part of this paper for noncommercial purposes is granted provided that copies bear this notice and the full citation on the first page. Reproduction for commercial purposes is strictly prohibited without the prior written consent of the Internet Society, the first-named author (for reproduction of an entire paper only), and the author's employer if the paper was prepared within the scope of employment.

show abstract

Section: A Developing Target Listsmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Don’t Forget to Lock the Back Door! A Characterization of IPv6 Network Security Policy

Czyz¹,

Luckie²,

Allman³

et al. 2016

Proceedings 2016 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

show abstract

“…Second, we do not have ground-truth in order to determine whether the periphery we discover is indeed the last hop before a destination endhost. While various, and at times conflicting, guidance exists regarding the size of delegated prefixes [10,19,25] discovery of unique /64s is strongly indicative of discovering the periphery. Additionally, the periphery addresses we find are frequently formed using EUI-64 addresses where we can infer the device type based on the encoded MAC address (see §4.5).…”

Section: Limitationsmentioning

confidence: 99%

Discovering the IPv6 Network Periphery

Rye

Beverly

2020

Lecture Notes in Computer Science

View full text Add to dashboard Cite

We consider the problem of discovering the IPv6 network periphery, i.e., the last hop router connecting endhosts in the IPv6 Internet. Finding the IPv6 periphery using active probing is challenging due to the IPv6 address space size, wide variety of provider addressing and subnetting schemes, and incomplete topology traces. As such, existing topology mapping systems can miss the large footprint of the IPv6 periphery, disadvantaging applications ranging from IPv6 census studies to geolocation and network resilience. We introduce "edgy, " an approach to explicitly discover the IPv6 network periphery, and use it to find > 64M IPv6 periphery router addresses and > 87M links to these last hops -several orders of magnitude more than in currently available IPv6 topologies. Further, only 0.2% of edgy's discovered addresses are known to existing IPv6 hitlists.

show abstract

“…Such operational insight is interesting with respect to published best common operating practice guidelines, 11,[17][18][19] which recommend the following, for instance: dedicating the first or last /48 per region to number infrastructure, numbering point-to-point interfaces out of /64 prefixes, not subnetting on non-nibble boundaries, and creating subnet prefixes of equal size. We find distinct evidence in practice of both adherences to, and deviations from, these recommendations.…”

Section: Introductionmentioning

confidence: 99%