-
Notifications
You must be signed in to change notification settings - Fork 0
/
current-draft.txt
280 lines (171 loc) · 9.59 KB
/
current-draft.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
Network Working Group R. Hinden
Internet-Draft Check Point Software
Intended status: Standards Track C. Huitema
Expires: February 17, 2018 Private Octopus Inc.
August 16, 2017
Self Assigned IPv6 Edge Subnets
draft-hinden-6man-ipv6-edge-subnet-00.txt
Abstract
This document present a simple strategy for setting up special
purpose subnets in edge networks without requiring additional prefix
assignments from the network service provider, and also without
breaking the current practice of assigning a single /64 prefix to an
edge network.
TODO: explain what we actually propose.
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 February 17, 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
(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
Hinden & Huitema Expires February 17, 2018 [Page 1]
Internet-Draft IPv6 Edge Subnets August 2017
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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement and Requirements . . . . . . . . . . . . . 3
2.1. Segment isolation . . . . . . . . . . . . . . . . . . . . 4
2.2. CLAT . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Self assigned subnet . . . . . . . . . . . . . . . . . . . . 4
3.1. Defending a subnet claim with DAD . . . . . . . . . . . . 4
3.2. Routing considerations . . . . . . . . . . . . . . . . . 4
4. CLAT using self assigned subnet . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
The current IPv6 address assignment strategy works very well for edge
networks, as long as these networks include a single subnet. But as
soon as a network requires more than one subnet, we observe a tension
between two possible solutions.
The standard practice in home networks is to use the prefix
delegation mechanism and obtain a network prefix from the network
service provider. An obvious solution for multiple subnets is to use
the same prefix delegation mechanism to obtain additional prefixes,
and assign them to the additional networks. While this solution is
technically sound, it requires cooperation from the network service
provider. There are fears that the network service provider might
charge an additional fee for these additional network prefixes.
These fears may or may not be grounded in facts, but in any case the
network provider will need to expand more resource to manage several
prefixes than to manage a single one.
Another plausible solution is to allow edge devices to derive from
the prefix allocated by the network service provider a set of longer
prefixes, which could then be assigned to different subnets. That
solution may very well work, but it would requires all hosts to
support address configuration with variable length subnet prefixes.
A number of currently fielded devices do not have that capability.
Their IPv6 stack assumes that the subnet prefix is 64 bit long. A
large fraction of these hosts will not be updated in the near future.
Hinden & Huitema Expires February 17, 2018 [Page 2]
Internet-Draft IPv6 Edge Subnets August 2017
If we ignore this issue and assume that all host will be updated to
handle variable length subnets, there is a fear that some network
providers will handle by default very long subnet prefixes, forcing
complex edge networks to pay extra for shorter prefixes that could be
subnetted.
Yet another solution would be to use a form of local addressing
combined with IPv6 to IPv6 NAT. Each subnet in the home would get a
/64 prefix using Unique Local Address (ULA), and some stateful NAT
would do the translation to the IPS assigned prefix. This solution
is despised by many IPv6 experts, because it would import to IPv6 the
various problems caused by NAT in IPv4. However, in the absence of
alternative, this solution relieves the price pressure linked to the
acquisition of long prefixes or multiple prefixes.
In this document, we propose an alternative to multiple prefixes or
generalized support of variable length subnets. We assume that the
current practice of assigning a /64 prefix to a "customer" network
will continue, and we assume that most hosts will continue directly
connecting to this /64 subnet. Special purpose networks, on the
other hand, will "self assign" a subnet of that /64 prefix. We do
not expect that these networks will use SLAAC.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Problem Statement and Requirements
Today, most home networks use a simple architecture consistent with
the IEEE 802 series of standards. Multiple segments may use
different transport mechanisms such as 802.3 or 802.11, but these
segments can be bridged according to 802.1. In this architecture,
the entire edge network appears to IPv6 hosts as a single subnet.
Most IPv6 devices just work.
There are scaling issues with this bridged network architecture,
mostly caused by the N-square effects of multicast based
transmission. However, we expect that these scaling issues will be
solved by adequate support of IPv6 in the bridges. There are known
examples of such networks scaling up to several ten thousands hosts,
which is somewhat larger than the expected size of most home
networks.
There are however other issues than scaling that may require
subnetting. One potential issue is the need to isolate a fraction of
Hinden & Huitema Expires February 17, 2018 [Page 3]
Internet-Draft IPv6 Edge Subnets August 2017
the network for security reasons. Another plausible issue is the
deployment of special purpose subnets, such as CLAT.
2.1. Segment isolation
TODO.
2.2. CLAT
TODO.
3. Self assigned subnet
TODO: general idea, a box assigns itself a subnet.
TODO: maybe a beautiful diagram with a /64 and two /96
3.1. Defending a subnet claim with DAD
TO DO: how to use DAD to claim a /80 or a /96.
TO DO: probabilies of SLAAC collision with a self assigned subnet.
Show that this is typically not very large.
3.2. Routing considerations
TODO: general solution using ND proxy.
TODO: what about multicast.
TODO: special case of same box colocation. The home router also
manages the special purpose network. Example are dedicated Wi-Fi
network with special password, or CLAT managed by edge router.
4. CLAT using self assigned subnet
TODO, if we really care. Or maybe this is a different draft.
5. Security Considerations
Yeah, right.
6. IANA Considerations
This draft does not require any IANA action.
Hinden & Huitema Expires February 17, 2018 [Page 4]
Internet-Draft IPv6 Edge Subnets August 2017
7. Acknowledgments
We would like to thank the 6MAN working member for the long and
constructive discussion that motivated this draft.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
Authors' Addresses
Robert M. Hinden
Check Point Software
959 Skyway Road
San Carlos, CA 94070
USA
Email: [email protected]
Christian Huitema
Private Octopus Inc.
Friday Harbor, WA 98250
U.S.A.
Email: [email protected]
Hinden & Huitema Expires February 17, 2018 [Page 5]