Network Working Group R. Hinden
Internet-Draft Check Point Software
Updates: 5175 (if approved) B. Carpenter
Intended status: Standards Track Univ. of Auckland
Expires: May 20, 2018 November 16, 2017

IPv6 Router Advertisement IPv4 Availability Flag
draft-hinden-ipv4flag-00

Abstract

This document specifies a Router Advertisement Flag to indicate that there is no IPv4 service on the advertising router. This document updates RFC5175.

Status of This Memo

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

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

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on May 20, 2018.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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

This document specifies a Router Advertisement Flag to indicate that there is no IPv4 service on the advertising router.

Hosts that support IPv4 and IPv6, usually called dual stack hosts, need to work on IPv6 only networks. That is, a link where there are no IPv4 routers and/or IPv4 services. Monitoring of IPv6-only networks, for example at the IETF 100 meeting in Singapore, shows that current dual stack hosts will create local auto-configured IPv4 addresses and attempt to reach IPv4 services. A mechanism is needed to inform hosts that there is no IPv4 support and that they should turn off IPv4.

Because there is no IPv4 support on these links, the only way to notify the dual stack hosts on the link is to use an IPv6 mechanism. An active notification will be much more robust than attempting to deduce this state by the lack of IPv4 responses or traffic.

IPv4-only hosts, and dual-stack hosts that do not recognize the new flag, will continue to attempt IPv4 operations, in particular IPv4 discovery protocols typically sent as link-layer broadcasts. This legacy traffic cannot be prevented by any IPv6 mechanism. The value of the new flag is limited to dual-stack hosts that recognize it.

This document specifies an new flag for IPv6 Neighbor Discovery [RFC4861] Router Advertisement Flag [RFC5175]. It updates [RFC5175].

2. IPv4 Availability Flag

RFC5175 currently defines the flags in the NDP Router Advertisement message. This currently contains the following one-bit flags defined in published RFCs:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |M|O|H|Prf|P|R|R|
   +-+-+-+-+-+-+-+-+

This document defines bit 6 to be the IPv4 Available Flag:

This flag has two values. These are:

RFC 5175 requires that unused flag bits be set to zero. Therefore, a router that does not support the new flag will not appear to assert that IPv4 is unsupported.

If there are multiple IPv6 routers on a network, they might send different values of the flag. A host that receives only RAs with the flag set to 1 should not attempt IPv4 operations, unless it subsequently receives at least one RA with the flag set to zero.

3. IANA Considerations

IANA is requested to assign the new Router Advertisement flag defined in Section 2 of this document. Bit 6 is the next available bit in this registry, IANA is requested to use this bit unless there is a reason not to use this bit.

IANA should also register this new flag bit in IANA IPv6 ND Router Advertisement flags Registry [IANA-RF].

4. Security Considerations

This document shares the security issues with other parts of IPv6 Neighbor Discovery. General techniques to protect Router Advertisement traffic such as Router Guard [RFC6105] are useful in protecting these vulnerabilities.

A bad actor could use this mechanism to attempt turn off IPv4 service on a network that is using IPv4. In that case, as long as there are routers sending Router Advertisements with this Flag set to 0, this would override this attack given the mechanism in Section 2. Specifically a host would only turn off IPv4 service if it wasn't hearing any Router Advertisement with the Flag set to 0.

5. Acknowledgments

[Your name here]

6. References

6.1. Normative References

[IANA-RF] "IPv6 ND Router Advertisement flags"
[RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007.
[RFC5175] Haberman, B. and R. Hinden, "IPv6 Router Advertisement Flags Option", RFC 5175, DOI 10.17487/RFC5175, March 2008.

6.2. Informative References

[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C. and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 10.17487/RFC6105, February 2011.

Authors' Addresses

Robert M. Hinden Check Point Software 959 Skyway Road San Carlos, CA 94070 USA EMail: bob.hinden@gmail.com
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand EMail: brian.e.carpenter@gmail.com