-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-hinden-6man-ipv6-edge-subnet.xml
301 lines (264 loc) · 9.44 KB
/
draft-hinden-6man-ipv6-edge-subnet.xml
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
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<!-- Expand crefs and put them inline -->
<?rfc comments='yes' ?>
<?rfc inline='yes' ?>
<rfc category="std"
docName="draft-hinden-6man-ipv6-edge-subnet-00.txt"
ipr="trust200902">
<!-- saw your edit, Bob, but we really need 00, not 01 -->
<front>
<title abbrev="Simple CLAT in Edge">
Simple CLAT Deployment in IPv6 Edge Subnets
</title>
<author fullname="Robert M. Hinden" initials="R." surname="Hinden">
<organization>Check Point Software</organization>
<address>
<postal>
<street>959 Skyway Road</street>
<city>San Carlos</city>
<code>94070</code>
<region>CA</region>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Christian Huitema" initials="C." surname="Huitema">
<organization>Private Octopus Inc.</organization>
<address>
<postal>
<street> </street>
<city>Friday Harbor</city>
<code>98250</code>
<region>WA</region>
<country>U.S.A.</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date year="2017" />
<abstract>
<t>
The 464XLAT strategy for ensuring IPv4 connectivity through IPv6 only provider
networks relies on deployment of CLAT functions in edge networks. These
functions requires assignment of a specific IPv6 prefix. We propose
a simple way to deploy the CLAT function in edge networks while only
requiring a single /64 prefix for the IPv6 edge network. The CLAT prefix
will be self-assigned from this prefix, without requiring explicit
provisioning by the network provider.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro" >
<t>
The 464XLAT strategy is defined in <xref target="RFC6877"/>. It ensures
ensuring IPv4 connectivity through IPv6 only provider
networks by deployment of IPv4 to IPv6 CLAT functions in edge networks,
and IPv6 to IPv4 PLAT functions in provider networks. Each CLAT deployment
requires assignment of a specific IPv6 prefix.
</t>
<t>
The standard practice in edge networks is to use the prefix delegation mechanism
and obtain a single /64 network prefix from the network service provider. The
CLAT deployment would in theory require an additional prefix for each network.
This increases the number of prefixes required for network operation, and
generally introduces friction in the deployment of CLAT functions.
</t>
<t>
In this document, we propose an alternative in which the CLAT functions
self assign a /96 prefix inside the /64 prefix assigned to the home network.
</t>
<section title="Terminology" anchor="terminology">
<t>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 <xref target="RFC2119"/>.</t>
</section>
</section> <!-- end of introduction -->
<section title="464XLAT and CLAT deployment" anchor="problem" >
<t>
The 464XLAT transition mechanism define in <xref target="RFC6877"/>
relies on two successive translations:
<list style="numbers">
<t>
The packet originates in an edge network as IPv4, and is routed to the default
IPv4 router for the network, which implements a CLAT function.
</t>
<t>
The CLAT translates the packet from IPv4 to IPv6 according to <xref target="RFC6145"/>
The source IPv4 address
is obtained by combining the original IPv4 source address with the local
CLAT prefix. The destination IPv6 address is obtained by combining
the original IPv4 source address with the PLAT prefix.
</t>
<t>
The packet is routed over IPv6 to the PLAT.
</t>
<t>
The PLAT translates the packet from IPv6 to IPv4 according to <xref target="RFC6146"/>.
</t>
<t>
The packet is routed to the IPv4 destination.
</t>
</list>
The reverse translations are performed in the opposite direction.
</t>
<t>
The construction of the prefixes for IPv6/IPv4 address translators is specified in
<xref target="RFC6052"/>, which allows multiple prefix sizes. In what follows,
we will assume that the CLAT prefix is a /96.
</t>
<t>
The simple deployment makes a set of assumptions:
<list style="symbols">
<t>
The edge network advertises a /64 prefix for
IPv6 Stateless Address Autoconfiguration according to
<xref target="RFC4862"/>.
</t>
<t>
The CLAT function is configured with the
prefix of the preferred PLAT. In the absence of explicit configuration,
the PLAT prefix may be configured using the process defined in <xref target="RFC7050"/>.
</t>
<t>
The CLAT function includes an IPv4 DHCP server, which is in charge of
assigning addresses in a selected IPv4 prefix. That prefix MUST be one of
the prefixes reserved in <xref target="RFC1918" />.
</t>
</list>
</t>
</section>
<section title="Self assigned subnet" >
<t>
The first step is configuration of the CLAT is the configuration of an IPv6 /96 CLAT
prefix. The prefix MUST BE configured by concatenating:
<list style="symbols">
<t>
The /64 prefix of the local network.
</t>
<t>
A random 16 bit CLAT subnet number.
</t>
<t>
A 16 bit number chosen so that the /96 prefix is "checksum neutral" according
to <xref target="RFC6145"/>.
</t>
</list>
The prefix is only valid as long as the /64 prefix of the local network is valid.
Similarly to what is explained in <xref target="RFC4862"/>, the /96 bit
prefix MUST NOT be used if the /64 bit prefix is no longer valid.
</t>
</section> <!-- end of Self assigned subnet -->
<section title="Defending the IPv4 addresses with DAD" anchor="dodad" >
<t>
The nodes in the local subnets are not explicitly aware that a specific /96 prefix
has been self-assigned by the local CLAT function. There is a small probability
that nodes using SLAAC configure addresses in the selected prefix.
If nodes configure addresses according to <xref target="RFC3972"/>,
<xref target="RFC4941"/> or <xref target="RFC7217"/>, they will pick
Interface Identifiers that are randomly distributed 64 bit numbers. The
most significant 32 bits of these numbers may end up colliding with the
lest significant 32 bits of the self configured CLAT prefix. If nothing was done,
the procedures described in <xref target="routing"/> will results in
packets sometimes routed to the CLAT and sometimes to the node, and that
would be bad.
</t>
<t>
We may remark that such collisions will occur rarely. The probability of
assigning an Interface Identifier with the "wrong" high level 32 bits is
less 1/2^32, or maybe 1/2^30 if randomly chosen identifiers are constrained
to use the U and G bit values reserved in the EUI64 specification and
refered to in <xref target="RFC3972"/> and <xref target="RFC4941"/>. However,
there are billions of hosts in the Internet, so collisions are likely to
occur at least a few times.
</t>
<t>
The basic defense against such collisions is to perform
Duplicate Address Detection (DAD).
If we assume that the CLAT includes an IPv4 DHCP function, DAD
MUST be performed prior to allocating an IPv4 address to a DHCP client,
as indicated in the following sequence:
<list style="numbers">
<t>
DHCP component of CLAT receives a request to allocate a new IPv4 address.
</t>
<t>
DHCP component of CLAT selects a tentative IPv4 address.
</t>
<t>
DHCP component of CLAT composes the corresponding IPv6 address.
</t>
<t>
CLAT MUST perform DAD for this IPv6 address,
as specified in <xref target="RFC4862" />.
</t>
<t>
If DAD fails, the CLAT must pick another tentative IPv4 address, and
repeat the procedure from step 2.
</t>
<t>
If DAD succeeds, the IPv4 address is validated and SHOULD be assigned
via DHCP to the soliciting host.
</t>
</list>
This procedure will ensure that the IPv4 addresses assigned to local
IPv4 hosts do not map to IPv6 addresses already configured by local IPv6
hosts. To avoid collisions with IPv6 addresses configured after the
IPv4 address assignment, the CLAT MUST defend the assigned address
using DAD.
</t>
</section> <!-- end of DAD -->
<section title="Routing considerations" anchor="routing">
<t>
TODO: general solution using ND proxy.
</t>
<t>
TODO: what about multicast.
</t>
<t>
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.
</t>
</section> <!-- end of routing -->
<section title="Security Considerations" anchor="securityCons" >
<t>
Yeah, right.
</t>
</section> <!-- end of security -->
<section title="IANA Considerations" anchor="iana">
<t>
This draft does not require any IANA action.
</t>
</section> <!-- end of iana -->
<section title="Acknowledgments">
<t>
We would like to thank the 6MAN working member for the long and constructive discussion that motivated this draft.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.6877" ?>
<?rfc include="reference.RFC.6145" ?>
<?rfc include="reference.RFC.6146" ?>
<?rfc include="reference.RFC.6052" ?>
<?rfc include="reference.RFC.4862" ?>
<?rfc include="reference.RFC.7050" ?>
<?rfc include="reference.RFC.1918" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3972" ?>
<?rfc include="reference.RFC.4941" ?>
<?rfc include="reference.RFC.7217" ?>
</references>
</back>
</rfc>