idnits 2.17.1
draft-xie-6man-bier-encapsulation-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (September 6, 2018) is 2057 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'RFC3032' is mentioned on line 222, but not defined
== Missing Reference: 'RFC6744' is mentioned on line 226, but not defined
== Missing Reference: 'RFC2780' is mentioned on line 333, but not defined
== Missing Reference: 'SL' is mentioned on line 371, but not defined
-- Looks like a reference, but probably isn't: '0' on line 372
== Outdated reference: A later version (-07) exists of
draft-filsfils-spring-srv6-network-programming-05
== Outdated reference: A later version (-26) exists of
draft-ietf-6man-segment-routing-header-14
Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Xie
3 Internet-Draft Huawei Technologies
4 Intended status: Standards Track L. Geng
5 Expires: March 10, 2019 L. Wang
6 China Mobile
7 G. Yan
8 M. McBride
9 Y. Xia
10 Huawei
11 September 6, 2018
13 Encapsulation for BIER in Non-MPLS IPv6 Networks
14 draft-xie-6man-bier-encapsulation-02
16 Abstract
18 Bit Index Explicit Replication (BIER) introduces a new multicast-
19 specific BIER Header. Currently BIER has two types of encapsulation
20 formats: one is MPLS encapsulation, the other is Ethernet
21 encapsulation. This document proposes a BIER IPv6 encapsulation for
22 Non-MPLS IPv6 Networks using an IPv6 Destination Option extension
23 header.
25 Requirements Language
27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
29 document are to be interpreted as described in [RFC2119].
31 Status of This Memo
33 This Internet-Draft is submitted in full conformance with the
34 provisions of BCP 78 and BCP 79.
36 Internet-Drafts are working documents of the Internet Engineering
37 Task Force (IETF). Note that other groups may also distribute
38 working documents as Internet-Drafts. The list of current Internet-
39 Drafts is at https://datatracker.ietf.org/drafts/current/.
41 Internet-Drafts are draft documents valid for a maximum of six months
42 and may be updated, replaced, or obsoleted by other documents at any
43 time. It is inappropriate to use Internet-Drafts as reference
44 material or to cite them other than as "work in progress."
46 This Internet-Draft will expire on March 10, 2019.
48 Copyright Notice
50 Copyright (c) 2018 IETF Trust and the persons identified as the
51 document authors. All rights reserved.
53 This document is subject to BCP 78 and the IETF Trust's Legal
54 Provisions Relating to IETF Documents
55 (https://trustee.ietf.org/license-info) in effect on the date of
56 publication of this document. Please review these documents
57 carefully, as they describe your rights and restrictions with respect
58 to this document. Code Components extracted from this document must
59 include Simplified BSD License text as described in Section 4.e of
60 the Trust Legal Provisions and are provided without warranty as
61 described in the Simplified BSD License.
63 Table of Contents
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
67 3. Problem Statement and Requirements . . . . . . . . . . . . . 3
68 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
69 3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
70 4. IPv6 BIER Encapsulation . . . . . . . . . . . . . . . . . . . 4
71 4.1. Considerations . . . . . . . . . . . . . . . . . . . . . 4
72 4.2. IPv6 BIER Destination Option . . . . . . . . . . . . . . 4
73 4.3. The whole IPv6 header for BIER packets . . . . . . . . . 5
74 5. IPv6 BIER Forwarding . . . . . . . . . . . . . . . . . . . . 6
75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
78 9. Appendix A - BIER over IPv6 SRH Tunnel . . . . . . . . . . . 8
79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
80 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
81 10.2. Informative References . . . . . . . . . . . . . . . . . 10
82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
84 1. Introduction
86 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture
87 that provides optimal multicast forwarding without requiring
88 intermediate routers to maintain any per-flow state by using a
89 multicast-specific BIER header. [RFC8296] defines two types of BIER
90 encapsulation to run on physical links: one is BIER MPLS
91 encapsulation to run on various physical links that support MPLS, the
92 other is BIER Ethernet encapsulation to run on ethernet links, with
93 an ethertype 0xAB37. This document proposes a BIER IPv6
94 encapsulation for Non-MPLS IPv6 Networks using an IPv6 Destination
95 Option extension header.
97 2. Terminology
99 Readers of this document are assumed to be familiar with the
100 terminology and concepts of the documents listed as Normative
101 References.
103 3. Problem Statement and Requirements
105 3.1. Problem Statement
107 MPLS is a very popular and successful encapsulation. With MPLS
108 encapsulation, packets forwarding can not only run on various
109 physical links hop-by-hop, but also leverage the MPLS bypass tunnel
110 to gain the "fast reroute" capability.
112 This same label benefit is also available for BIER by using an MPLS
113 encapsulation. For example, an MPLS-encapsulated BIER packet can be
114 forwarding on various physical links hop-by-hop, as well as on any
115 MPLS bypass tunnels to support "fast reroute".
117 With a BIER Ethernet encapsulation, however, a packet can not be
118 forwarded on any other type of links except for ethernet links in
119 hop-by-hop case. It can not run on an MPLS bypass tunnel to support
120 "fast reroute" either.
122 In an IPv6 network, there are considerations of using a non-MPLS
123 encapsulation for unicast as the data-plane, such as SRH defined in
124 [I-D.ietf-6man-segment-routing-header], where the function of a
125 bypass tunnel uses an SRH header, with one or many Segments (or
126 SIDs), instead of MPLS Labels. In such case, it is expected to have
127 a BIER IPv6 encapsulation, which can run on IPv6 to be compliant with
128 various kind of physical link in hop-by-hop case, as well as on SRH
129 tunnel to have the significant benefit of "fast reroute" and so on.
131 3.2. Requirements
133 This chapter lists the BIER IPv6 encapsulation requirements needed to
134 make the deployment of BIER on IPv6 network with SRH data-plane the
135 same as on IPv4/IPv6 network with MPLS data-plane. These BIER IPv6
136 encapsulation requirements should provide similar benefits to MPLS
137 encapsulation such as "fast reroute" or "run on any link or
138 interface".
140 1. The listed requirements MUST be supported with any L1/L2 over
141 which BIER layer can be realized.
143 2. It SHOULD support a hop-by-hop replication to multiple
144 destinations in a BIER Domain.
146 3. It SHOULD support BIER on an "SRH tunnel".
148 4. It SHOULD align with the recommendations of the 6MAN working
149 group.
151 4. IPv6 BIER Encapsulation
153 4.1. Considerations
155 BIER is generally a hop-by-hop and one-to-many architecture, and thus
156 the IPv6 Destination Address (DA) being a Multicast Address is a
157 proper approach for both the two diagrams in BIER IPv6 encapsulation.
158 It is also required for a BIER IPv6 encapsulation to include the BIER
159 Header ([RFC8296]) as an IPv6 Extension Header, to pilot the hop-by-
160 hop BIER replication.
162 According to [RFC8200], [RFC6564], and [RFC7045], a new defined IPv6
163 extention header is not recommended, and an IPv6 Destination Option
164 extension header is suitable and recommended for such a well-known
165 BIER header as its Option.
167 4.2. IPv6 BIER Destination Option
169 The IPv6 BIER Destination Option is carried by the IPv6 Destination
170 Option Header (indicated by a Next Header value 60). It is
171 initialized in a packet sent by an IPv6 BFIR router to inform the
172 following BFR routers in an IPv6 BIER domain to replicate to
173 destination BFER routers hop-by-hop.
175 The IPv6 BIER Destination Option is encoded in type-length-value
176 (TLV) format as follows:
178 0 1 2 3
179 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
181 | Next Header | Hdr Ext Len | Option Type | Option Length |
182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
183 | |
184 ~ Non-MPLS BIER Header (defined in RFC8296) ~
185 | |
186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
188 Figure 1: IPv6 BIER Destination Option
190 Next Header 8-bit selector. Identifies the type of header
191 immediately following the Destination Options header.
193 Hdr Ext Len 8-bit unsigned integer. Length of the Destination
194 Options header in 8-octet units, not including the first 8 octets.
196 Option Type TBD. Need to be allocated by IANA.
198 Option Length 8-bit unsigned integer. Length of the option, in
199 octets, excluding the Option Type and Option Length fields.
201 Non-MPLS BIER Header The Non-MPLS BIER Header defined in RFC8296,
202 including the BIFT-id. The function of TTL field is replaced by
203 the Hop Limit field in IPv6 header and MUST be set to a non-zero
204 value. The function of Entropy field is replaced by the Flow
205 Label field in IPv6 header and MUST be set to zero value.
207 4.3. The whole IPv6 header for BIER packets
209 [RFC8200] specifies that the Destination Option Header can be located
210 either before the Routing Header or after the Routing Header.
211 However, this document requires that the Destination Option Header
212 with a BIER Destination Option TLV is always located after the
213 Routing Header if the Routing Header is present.
215 This is because the BIER header is always handled after the tunnels
216 (or bypass tunnels) have been handled. BIER MPLS encapsulation has
217 the same behavior. To quote [RFC8296]:
219 o It is crucial to understand that in an MPLS network the first four
220 octets of the BIER encapsulation header are also the last four
221 octets of the MPLS header. Therefore, any prior MPLS label stack
222 entries MUST have the S bit (see [RFC3032]) clear (i.e., the S bit
223 must be 0).
225 Other IPv6 extension headers are not commonly used in the current
226 Internet. For Example, [RFC6744] says that "IPv6 Destination Options
227 headers, and the options carried by such headers, are extremely
228 uncommon in the deployed Internet". [RFC6564] says that "Extension
229 headers, with the exception of the Hop-by-Hop Options header, are not
230 usually processed on intermediate nodes", and that "Reports from the
231 field indicate that some IP routers deployed within the global
232 Internet are configured either to ignore the presence of headers with
233 hop-by-hop behavior or to drop packets containing headers with hop-
234 by-hop behavior."
236 Such IPv6 extension headers will even be more uncommon when a BIER
237 encapsulation is used in data-plane forwarding. The entire IPv6
238 header, with BIER encapsulation and Routing Header, is expected to
239 look like this:
241 IPv6 header [Multicast Address in DA]
243 Hop-by-Hop Options header [No use]
245 Destination Options header [No use]
247 Routing header [SRH Header may be used, Appendix A]
249 Fragment header [No use ]
251 Authentication header [No use]
253 Encapsulating Security Payload header [No use]
255 Destination Options header [BIER header in BIER Option TLV]
257 Upper-layer header [BIER payload]
259 In a hop-by-hop BIER IPv6 replication scenario, there is only an IPv6
260 header with DA being a "BIER specific" Multicast address, and an IPv6
261 Destination Option header with a BIER destination option TLV.
263 BIER header has a 'proto' field to identify the type of BIER packet
264 payload, and the IANA has created a registry called "BIER Next
265 Protocol Identifiers" to assign the value. That means the 'Upper-
266 layer header' of a BIER packet have already been identified by the
267 'proto' field of the BIER header in the Destination Option Header.
268 Thus the 'Next Header' in the Destination Option Header is not need
269 to identify the 'Upper-layer header' any more, and is recommended to
270 be set to 'No Next Header (value 59)'.
272 Procedures for encapsulating a BIER IPv6 packet in SRH tunnel are
273 outside the scope of this document.
275 Procedures for encapsulating a BIER IPv6 packet in other types of
276 tunnels are outside the scope of this document.
278 5. IPv6 BIER Forwarding
280 In an IPv6 BIER domain, the Multicast Address of the IPv6 DA in an
281 incoming BIER IPv6 packet indicates the BIER information of this
282 'host', and the packet will be forwarded according to the BIER Header
283 in the BIER Destination Option TLV in the IPv6 Destination Option
284 extension header. A router is required to ignore the IPv6 BIER
285 Destination Option if the IPv6 Destination Address of a packet is not
286 a multicast address, or is a multicast adddress without indicating
287 the BIER information of this 'host'.
289 Below is the procedure that a BFR uses for forwarding a BIER IPv6
290 encapsulated packet.
292 1. Read the IPv6 header, get the the IPv6 DA, and get the indication
293 of the multicast address if the IPv6 DA is a multicast address.
294 The case when IPv6 DA not being a multicast address is outside
295 the scope of this document.
297 2. If the multicast address is interested by this router, and the
298 'Next Header' of the IPv6 header indicates a IPv6 Destination
299 Option Header, then read the IPv6 Destination Option Header, and
300 get the BIER Option (BIER Header). The case when the multicast
301 address not being interested by this router is outside the scope
302 of this document.
304 3. The following steps are the same as step 1 to 9 described in
305 chapter 6.5 in [RFC8279]. One difference need to point out is
306 that, the copied packet includes a IPv6 header, a IPv6
307 Destination Header and its BIER Destination Option Type and
308 Option Length before the BIER Header. If the copied packet is
309 forwarded to a BFR-NBR, the 'Hop Limit' field of the IPv6 header
310 MUST be decremented, whereas the TTL in the BIER header MUST be
311 unchanged.
313 Procedures for forwarding a BIER IPv6 packet in SRH tunnel, and hand-
314 off to a hop-by-hop replication, can refer to Appendix A.
316 Procedures for forwarding a BIER IPv6 packet in other types of
317 tunnels, and hand-off to a hop-by-hop replication, are outside the
318 scope of this document.
320 6. Security Considerations
322 An IPv6 BIER Destination Option with Multicast Address Destination
323 would be used only when an IPv6 BIER state with the specific
324 Multicast Address Destination has been built by the control-plane.
325 Otherwise the packet with an IPv6 BIER Destination Option will be
326 discarded.
328 7. IANA Considerations
330 Allocation is expected from IANA for a BIER Destination Option Type
331 codepoint from the "Destination Options and Hop-by-Hop Options" sub-
332 registry of the "Internet Protocol Version 6 (IPv6) Parameters"
333 registry [RFC2780] at .
336 Allocation is expected from IANA for a BIER Multicast Address from
337 the "Variable Scope Multicast Addresses" sub-registry of the "IPv6
338 Multicast Address Space Registry" registry at
339 .
341 8. Acknowledgements
343 TBD.
345 9. Appendix A - BIER over IPv6 SRH Tunnel
347 In a Non-MPLS IPv6 Network, BIER may be deployed in a hop-by-hop
348 manner, or possibly be deployed through an SRH tunnel either for
349 "bypassing Non-capable BIER routers" or "fast rerouting". Here is an
350 example where a packet is firstly forwarded through an SRH tunnel and
351 then through a hop-by-hop BIER domain.
353 When a router along the Segment Routing path receives an IPv6 BIER
354 packet with an SRH header, and if the IPv6 destination address is not
355 one of the router's address, then the packet is forwarded by an IPv6
356 FIB lookup of the destination address and none of the IPv6 extension
357 headers will be checked. If the IPv6 Destination Address is one of
358 the router's address, and also one of the router's Segment (or SID)
359 of some type, then the router will do a specific function indicated
360 by the Segment, as defined in
361 [I-D.filsfils-spring-srv6-network-programming]. If the IPv6
362 Destination Address is a specific type of Segment, called BIER
363 Segment or BIER SID, then the according function is called Endpoint
364 BIER function or 'End.BF' function for short.
366 When router receives a packet destined to X and X is a local End.BF
367 SID, the router does:
369 1. IF SL > 0
370 2. decrement SL
371 3. update IPv6 DA with SRH[SL]
372 4. IF SL = 0 & STATE(SRH[0]) = BIER
373 5. update IPv6 header NH with SRH NH
374 6. pop the SRH
375 7. forward the updated packet
376 8. ELSE
377 9. drop the packet
378 10. ELSE
379 11. drop the packet
381 Figure 2: End.BF Function
383 The End.BF function is used for the SRH tunnel destination router to
384 terminate the source-routing SRH forwarding and begin the hop-by-hop
385 BIER IPv6 forwarding. After the SRH header is popped, the multicast
386 address in the updated IPv6 Destination Address indicates the BIER
387 information of this 'host', and the packet will be forwarded
388 according to the BIER Header in the BIER Destination Option TLV in
389 the IPv6 Destination Option extension header of this 'host'.
391 In the following hop-by-hop forwarding procedure, the IPv6
392 Destination Address in an incoming packet indicates the BIER
393 information of this 'host', and the packet will be forwarded
394 according to the BIER Header in the BIER Destination Option TLV in
395 the IPv6 Destination Option extension header. A router is required
396 to ignore the IPv6 BIER Destination Option if the IPv6 Destination
397 Address of a packet is not a multicast address, or is a multicast
398 adddress without indicating the BIER information of this 'host'.
400 10. References
402 10.1. Normative References
404 [I-D.filsfils-spring-srv6-network-programming]
405 Filsfils, C., Camarillo, P., Leddy, J.,
406 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
407 Network Programming", draft-filsfils-spring-srv6-network-
408 programming-05 (work in progress), July 2018.
410 [I-D.ietf-6man-segment-routing-header]
411 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
412 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
413 (SRH)", draft-ietf-6man-segment-routing-header-14 (work in
414 progress), June 2018.
416 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
417 M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
418 RFC 6564, DOI 10.17487/RFC6564, April 2012,
419 .
421 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
422 of IPv6 Extension Headers", RFC 7045,
423 DOI 10.17487/RFC7045, December 2013,
424 .
426 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
427 (IPv6) Specification", STD 86, RFC 8200,
428 DOI 10.17487/RFC8200, July 2017,
429 .
431 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
432 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
433 Explicit Replication (BIER)", RFC 8279,
434 DOI 10.17487/RFC8279, November 2017,
435 .
437 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
438 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
439 for Bit Index Explicit Replication (BIER) in MPLS and Non-
440 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
441 2018, .
443 10.2. Informative References
445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
446 Requirement Levels", BCP 14, RFC 2119,
447 DOI 10.17487/RFC2119, March 1997,
448 .
450 Authors' Addresses
452 Jingrong Xie
453 Huawei Technologies
455 Email: xiejingrong@huawei.com
457 Liang Geng
458 China Mobile
459 Beijing 10053
461 Email: gengliang@chinamobile.com
463 Lei Wang
464 China Mobile
465 Beijing 10053
467 Email: wangleiyjy@chinamobile.com
469 Gang Yan
470 Huawei
472 Email: yangang@huawei.com
473 Mike McBride
474 Huawei
476 Email: mmcbride7@gmail.com
478 Yang Xia
479 Huawei
481 Email: yolanda.xia@huawei.com