Internet DRAFT - draft-barth-homenet-wifi-roaming
draft-barth-homenet-wifi-roaming
Homenet Working Group S. Barth
Internet-Draft Independent
Intended status: Experimental October 16, 2015
Expires: April 18, 2016
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.
Barth Expires April 18, 2016 [Page 1]
Internet-Draft Homenet WiFi Roaming October 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Stateless Duplicate Address Detection (DAD) Proxy . . . . . . 3
3.1. Receipt of DAD Messages and forwarding to routers . . . . 3
3.2. Distributing DAD Messages received from other routers . . 4
4. Maintaining Host Routes . . . . . . . . . . . . . . . . . . . 4
5. Roaming Interface Configuration . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative references . . . . . . . . . . . . . . . . . . 5
8.2. Informative references . . . . . . . . . . . . . . . . . 6
Appendix A. Discussion Points [RFC Editor: please remove] . . . 6
Appendix B. Changelog [RFC Editor: please remove] . . . . . . . 6
Appendix C. Draft Source [RFC Editor: please remove] . . . . . . 6
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
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.
Barth Expires April 18, 2016 [Page 2]
Internet-Draft Homenet WiFi Roaming October 2015
2. Terminology
ESSID IEEE 802.11 Extended Service Set Identifier
host route an IPv6 route with a prefix length of 128 intended
to track a host on a roaming interface
roaming interface a network interface (typically IEEE 802.11) which
shares an address prefix with other similar
interfaces to allow seamless client roaming
roaming interface the set of roaming interfaces which share a
set particular address prefix
roaming prefix an IPv6 address prefix shared between all
interfaces in a roaming interface set
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.
Barth Expires April 18, 2016 [Page 3]
Internet-Draft Homenet WiFi Roaming October 2015
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
Barth Expires April 18, 2016 [Page 4]
Internet-Draft Homenet WiFi Roaming October 2015
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Barth Expires April 18, 2016 [Page 5]
Internet-Draft Homenet WiFi Roaming October 2015
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[I-D.ietf-v6ops-reducing-ra-energy-consumption]
Yourtchenko, A. and L. Colitti, "Reducing energy
consumption of Router Advertisements", draft-ietf-v6ops-
reducing-ra-energy-consumption-02 (work in progress),
October 2015.
8.2. Informative references
[I-D.ietf-homenet-hncp]
Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", draft-ietf-homenet-hncp-09 (work in
progress), August 2015.
Appendix A. Discussion Points [RFC Editor: please remove]
o 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.
o 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:
o 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!
Barth Expires April 18, 2016 [Page 6]
Internet-Draft Homenet WiFi Roaming October 2015
Appendix D. Acknowledgements
Thanks to Markus Stenberg for comments and feedback on the draft.
Author's Address
Steven Barth
Independent
Halle 06114
Germany
Email: cyrus@openwrt.org
Barth Expires April 18, 2016 [Page 7]
