Home Network WiFi Roaming
draft-barth-homenet-wifi-roaming-00

Abstract

This document describes a mechanism to manage host routes and statelessly proxy IPv6 Duplicate Address Detection messages between multiple WiFi links to allow client roaming.

Status of This Memo

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

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

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

This Internet-Draft will expire on April 18, 2016.

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
• 2. Terminology
• 2.1. Requirements Language
• 3. Stateless Duplicate Address Detection (DAD) Proxy
• 3.1. Receipt of DAD Messages and forwarding to routers
• 3.2. Distributing DAD Messages received from other routers
• 4. Maintaining Host Routes
• 5. Roaming Interface Configuration
• 6. Security Considerations
• 7. IANA Considerations
• 8. References
• 8.1. Normative references
• 8.2. Informative references
• Appendix A. Discussion Points [RFC Editor: please remove]
• Appendix B. Changelog [RFC Editor: please remove]
• Appendix C. Draft Source [RFC Editor: please remove]
• Appendix D. Acknowledgements
• Author's Address

1. Introduction

In a multi router home network it can be desirable to have a WiFi network accessible in different physical locations. Synchronization of configuration parameters like ESSID and authentication allows clients to seamlessly roam the network. However, a client switching from one WiFi AP to another might suffer from service disruption if each AP uses a different IP address prefix. To mitigate this issue, all AP links could be bridged on layer 2, which would lead to increased traffic on the home network backbone. This draft offers an alternative solutions based on host routing and proxying of Duplicate Address Detection for IPv6.

In order to minimize additional complexity on routers, this draft either relies on existing state in the form the neighbor cache entries used for host routing or introduces only lightweight, stateless mechanism to distribute Duplicate Address Detection messages.

However, an additional mechanism is needed to identify and share information about which routers have roaming interfaces, to which roaming interface set they belong, under which addresses these routers are reachable and which specific roaming prefixes are assigned. The specific mechanism is out of scope for this draft, however a solution based on [I-D.ietf-homenet-hncp] is conceivable.

2. Terminology

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

3. Stateless Duplicate Address Detection (DAD) Proxy

Sharing a roaming prefix across multiple separate interfaces might lead to address collisions between hosts on different interfaces of the same set. Therefore, it needs to be ensured that DAD messages are shared across interfaces. The typical DAD process involves the querying host sending one or more Neighbor Solicitations using the unspecified address as a source and any colliding host replying to the all-nodes address as specified in [RFC4862] and [RFC4861]. Since the source addresses of the DAD solicitations and the destination addresses of the DAD advertisements are fixed, the whole process can happen statelessly.

3.1. Receipt of DAD Messages and forwarding to routers

The following requirements apply for receiving DAD traffic from hosts on roaming interfaces and forwarding them to other DAD proxy routers:

• A router MUST listen for all Neighbor Solicitations with a target addresses from an assigned roaming prefix having the unspecified address as the source address. Similarly it MUST listen for all Neighbor Advertisements with a target address from an assigned roaming prefix and having the all-nodes multicast address as the destination address.
• A router MUST forward all such messages via global unicast to all other routers having roaming interfaces sharing the roaming prefixes the target address of the respective message belongs to.

3.2. Distributing DAD Messages received from other routers

The following requirements apply for distributing DAD traffic, forwarded by other routers, to clients on roaming interfaces:

• A router MUST listen for Neighbor Solicitations and Advertisements sent via global unicast from other routers having roaming interfaces with the same roaming prefix.
• Upon reception of such a Neighbor Solicitation, the router MUST forward the message to all roaming interfaces having prefixes matching the target address. It MUST use the unspecified address as source and the respective solicited node multicast-address as destination address.
• Upon reception of such a Neighbor Advertisement, the router MUST forward the message to all roaming interfaces having prefixes matching the target address. It MUST use the all-nodes multicast-address as destination address.

4. Maintaining Host Routes

Host routes are necessary in order to unambiguously forward packets to potentially roaming WiFi clients. This draft ties the announcement of host routes to the presence of Neighbor Cache [RFC4861] entries for addresses of roaming prefixes. The following requirements apply:

• A router MUST announce a host route for an IPv6 address belonging to a roaming prefix whenever there is a corresponding entry for it in the roaming interface's neighbor cache with the states REACHABLE, STALE, DELAY or PROBE.
• A router MUST retract any host route for an IPv6 address immediately when a neighbor lookup for it has finally failed on the roaming interface OR when a physical disconnect of the respective client (e.g., a WiFi disassociation) has been noticed.
• A router SHOULD be able to manage and publish host routes for at least two IPv6 addresses for every connected host and IPv6 roaming prefix announced on a roaming interface.
• The router SHOULD NOT flush neighbor cache entries in STALE state and respective host routes. Instead it SHOULD try to promote STALE entries to REACHABLE and only upon failure remove the cache entry and route. This ensures that the address is actually not used anymore and the host does not happen to be merely temporarily inactive and potentially waiting for incoming packets.

5. Roaming Interface Configuration

The following requirements are suggested for interfaces intended to use the roaming features described in this draft:

• Router Advertisements SHOULD only include Prefix Information Options for one more IPv6 roaming prefixes. Such Prefix Information Options MUST have the A-Bit set and the L-Bit cleared.
• The IPv6 address fe80::1 SHOULD be used as fixed link-local address exclusively by the router on roaming interfaces. This is to ensure that the IPv6 default route for clients stays the same across roaming interfaces. Furthermore the address SHOULD be announced as recursive DNS server address should the router provide such a service.
• Router Advertisements SHOULD be sent as described in [I-D.ietf-v6ops-reducing-ra-energy-consumption].
• Stateful DHCPv6 MUST NOT be used to avoid the need to synchronize lease information and relay DHCPv6 packets. Similarly Router Advertisements MUST be sent with the M-Bit cleared.
• NAT64 and DNS64 SHOULD be used if IPv4 connectivity is desired, alternatively different and disjoint native IPv4 prefixes MAY be used on each individual roaming interface.

6. Security Considerations

TBD

7. IANA Considerations

No action needed.

8. References

8.1. Normative references

8.2. Informative references

Appendix A. Discussion Points [RFC Editor: please remove]

• It is debatable which kind of transport could be used for the proxied DAD messages. Plain ICMPv6 could be possibly but might be dropped by certain hosts. Similarly UDP or DTLS encapsulation could be used easily if a port was allocated or exchanged.
• Is additional reliability useful and if so what kind? Normally hosts only send a single DAD solicitation, so the probability of a total packet loss increases with each forwarding hop. Trivially one could simply duplicate all proxied DAD messages or use TCP framing or SCTP. However the announced Retrans Timer value in the RA and retransmission parameters of the transport need to be adjusted, so that any resend and matching replies happen before the host considers the DAD process to have resulted in no collisions.

Appendix B. Changelog [RFC Editor: please remove]

draft-barth-homenet-wifi-roaming-00:

• Initial version.

Appendix C. Draft Source [RFC Editor: please remove]

As usual, this draft is available at https://github.com/fingon/ietf-drafts/ in source format (with nice Makefile too). Feel free to send comments and/or pull requests if and when you have changes to it!

Appendix D. Acknowledgements

Thanks to Markus Stenberg for comments and feedback on the draft.

Author's Address