< draft-ietf-softwire-mesh-multicast-24.txt   draft-ietf-softwire-mesh-multicast-25.txt >
Softwire WG M. Xu Softwire WG M. Xu
Internet-Draft Y. Cui Internet-Draft Y. Cui
Intended status: Standards Track J. Wu Intended status: Standards Track J. Wu
Expires: June 21, 2019 Tsinghua University Expires: December 10, 2019 Tsinghua University
S. Yang S. Yang
Shenzhen University Shenzhen University
C. Metz C. Metz
Cisco Systems Cisco Systems
December 18, 2018 June 8, 2019
IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Network IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Network
draft-ietf-softwire-mesh-multicast-24 draft-ietf-softwire-mesh-multicast-25
Abstract Abstract
During the transition to IPv6, there will be scenarios where a During the transition to IPv6, there will be scenarios where a
backbone network internally running one IP address family (referred backbone network internally running one IP address family (referred
to as the internal IP or I-IP family), connects client networks to as the internal IP or I-IP family), connects client networks
running another IP address family (referred to as the external IP or running another IP address family (referred to as the external IP or
E-IP family). In such cases, the I-IP backbone needs to offer both E-IP family). In such cases, the I-IP backbone needs to offer both
unicast and multicast transit services to the client E-IP networks. unicast and multicast transit services to the client E-IP networks.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 21, 2019. This Internet-Draft will expire on December 10, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 6, line 32 skipping to change at page 6, line 32
exclusively inside the I-IP core network. An I-IP core tree is used exclusively inside the I-IP core network. An I-IP core tree is used
to forward E-IP multicast packets belonging to E-IP trees across the to forward E-IP multicast packets belonging to E-IP trees across the
I-IP core. Another name for an I-IP core tree is multicast or I-IP core. Another name for an I-IP core tree is multicast or
multipoint softwire. multipoint softwire.
o E-IP client tree: A distribution tree rooted at one or more hosts o E-IP client tree: A distribution tree rooted at one or more hosts
or routers located inside a client E-IP network and branched out to or routers located inside a client E-IP network and branched out to
one or more leaf nodes located in the same or different client E-IP one or more leaf nodes located in the same or different client E-IP
networks. networks.
o uPrefix46: The /96 unicast IPv6 prefix for constructing an o uPrefix64: The /96 unicast IPv6 prefix for constructing an
IPv4-embedded IPv6 unicast address [RFC6052]. IPv4-embedded IPv6 unicast address [RFC8114].
o mPrefix46: The /96 multicast IPv6 prefix for constructing an o mPrefix64: The /96 multicast IPv6 prefix for constructing an
IPv4-embedded IPv6 multicast address. IPv4-embedded IPv6 multicast address [RFC8114].
o PIMv4, PIMv6: refer to [RFC8114]. o PIMv4, PIMv6: refer to [RFC8114].
o Inter-AFBR signaling: A mechanism used by downstream AFBRs to send o Inter-AFBR signaling: A mechanism used by downstream AFBRs to send
PIMv6 messages to the upstream AFBR. PIMv6 messages to the upstream AFBR.
4. Scope 4. Scope
This document focuses on the IPv4-over-IPv6 scenario, as shown in the This document focuses on the IPv4-over-IPv6 scenario, as shown in the
following diagram: following diagram:
skipping to change at page 8, line 36 skipping to change at page 8, line 36
5.2. Group Address Mapping 5.2. Group Address Mapping
A simple algorithmic mapping between IPv4 multicast group addresses A simple algorithmic mapping between IPv4 multicast group addresses
and IPv6 group addresses is performed. Figure 3 is provided as a and IPv6 group addresses is performed. Figure 3 is provided as a
reminder of the format: reminder of the format:
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0-------------32--40--48--56--64--72--80--88--96-----------127| | 0-------------32--40--48--56--64--72--80--88--96-----------127|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| mPrefix46 | group address | | mPrefix64 | group address |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 3: IPv4-Embedded IPv6 Multicast Address Format Figure 3: IPv4-Embedded IPv6 Multicast Address Format
An IPv6 multicast prefix (mPrefix46) is provisioned on each AFBR. An IPv6 multicast prefix (mPrefix64) is provisioned on each AFBR.
AFBRs will prepend the prefix to an IPv4 multicast group address when AFBRs will prepend the prefix to an IPv4 multicast group address when
translating it to an IPv6 multicast group address. translating it to an IPv6 multicast group address.
The construction of the mPrefix46 for Source-Specific Multicast (SSM) The construction of the mPrefix64 for Source-Specific Multicast (SSM)
is the same as the construction of the mPrefix64 described in is the same as the construction of the mPrefix64 described in
Section 5 of [RFC8114]. Section 5 of [RFC8114].
With this scheme, each IPv4 multicast address can be mapped into an With this scheme, each IPv4 multicast address can be mapped into an
IPv6 multicast address (with the assigned prefix), and each IPv6 IPv6 multicast address (with the assigned prefix), and each IPv6
multicast address with the assigned prefix can be mapped into an IPv4 multicast address with the assigned prefix can be mapped into an IPv4
multicast address. The group address translation algorithm can be multicast address. The group address translation algorithm can be
referred in Section 5.2 of [RFC8114]. referred in Section 5.2 of [RFC8114].
5.3. Source Address Mapping 5.3. Source Address Mapping
skipping to change at page 9, line 50 skipping to change at page 9, line 50
5.4. Routing Mechanism 5.4. Routing Mechanism
With mesh multicast, PIMv6 messages originating from a downstream With mesh multicast, PIMv6 messages originating from a downstream
AFBR need to be propogated to the correct upstream AFBR, and every AFBR need to be propogated to the correct upstream AFBR, and every
AFBR needs the /96 prefix in "IPv4-Embedded IPv6 Source Address AFBR needs the /96 prefix in "IPv4-Embedded IPv6 Source Address
Format" [RFC6052]. Format" [RFC6052].
To achieve this, every AFBR MUST announce the address of one of its To achieve this, every AFBR MUST announce the address of one of its
E-IPv4 interfaces in the "v4" field [RFC6052] alongside the E-IPv4 interfaces in the "v4" field [RFC6052] alongside the
corresponding uPreifx46. The announcement MUST be sent to the other corresponding uPreifx46. The announcement MUST be sent to the other
AFBRs through MBGP [RFC4760]. Every uPrefix46 that an AFBR announces AFBRs through MBGP [RFC4760]. Every uPrefix64 that an AFBR announces
MUST be unique. "uPrefix46" is an IPv6 prefix, and the distribution MUST be unique. "uPrefix64" is an IPv6 prefix, and the distribution
mechanism is the same as the traditional mesh unicast scenario. mechanism is the same as the traditional mesh unicast scenario.
As the "v4" field is an E-IP address, and BGP messages are not As the "v4" field is an E-IP address, and BGP messages are not
tunneled through softwires or any other mechanism specified in tunneled through softwires or any other mechanism specified in
[RFC5565], AFBRs MUST be able to transport and encode/decode BGP [RFC5565], AFBRs MUST be able to transport and encode/decode BGP
messages that are carried over the I-IP, and whose NLRI and NH are of messages that are carried over the I-IP, and whose NLRI and NH are of
the E-IP address family. the E-IP address family.
In this way, when a downstream AFBR receives an E-IP PIM (S,G) In this way, when a downstream AFBR receives an E-IP PIM (S,G)
message, it can translate this message into (S',G') by looking up the message, it can translate this message into (S',G') by looking up the
IP address of the corresponding AFBR's E-IP interface. Since the IP address of the corresponding AFBR's E-IP interface. Since the
uPrefix46 of S' is unique, and is known to every router in the I-IP uPrefix64 of S' is unique, and is known to every router in the I-IP
network, the translated message will be forwarded to the network, the translated message will be forwarded to the
corresponding upstream AFBR, and the upstream AFBR can translate the corresponding upstream AFBR, and the upstream AFBR can translate the
message back to (S,G). message back to (S,G).
When a downstream AFBR receives an E-IP PIM (*,G) message, S' can be When a downstream AFBR receives an E-IP PIM (*,G) message, S' can be
generated with the "source address" field set to * (wildcard value). generated with the "source address" field set to * (wildcard value).
The translated message will be forwarded to the corresponding The translated message will be forwarded to the corresponding
upstream AFBR. Since every PIM router within a PIM domain MUST be upstream AFBR. Since every PIM router within a PIM domain MUST be
able to map a particular multicast group address to the same RP when able to map a particular multicast group address to the same RP when
the source address is set to wildcard value (see Section 4.7 of the source address is set to wildcard value (see Section 4.7 of
skipping to change at page 14, line 12 skipping to change at page 14, line 12
only, the maintenance of these states is out of scope for this only, the maintenance of these states is out of scope for this
document. document.
7. Data Plane Functions of the AFBR 7. Data Plane Functions of the AFBR
7.1. Process and Forward Multicast Data 7.1. Process and Forward Multicast Data
Refer to Section 7.4 of [RFC8114]. If there is at least one outgoing Refer to Section 7.4 of [RFC8114]. If there is at least one outgoing
interface whose IP address family is different from the incoming interface whose IP address family is different from the incoming
interface, the AFBR MUST encapsulate this packet with interface, the AFBR MUST encapsulate this packet with
mPrefix46-derived and uPrefix46-derived IPv6 address to form an IPv6 mPrefix64-derived and uPrefix64-derived IPv6 address to form an IPv6
multicast packet. multicast packet.
7.2. TTL or Hop Count 7.2. TTL or Hop Count
Upon encapsulation, the TTL and hop account in the outer header Upon encapsulation, the TTL and hop account in the outer header
SHOULD be set by policy. Upon decapsulation, the TTL and hop count SHOULD be set by policy. Upon decapsulation, the TTL and hop count
in the inner header SHOULD be modified by policy, it MUST NOT be in the inner header SHOULD be modified by policy, it MUST NOT be
incremented and it MAY be decremented to reflect the cost of tunnel incremented and it MAY be decremented to reflect the cost of tunnel
forwarding. Besides, processing of TTL and hop count information in forwarding. Besides, processing of TTL and hop count information in
protocol headers depends on the tunneling technology protocol headers depends on the tunneling technology, which is out of
[I-D.ietf-intarea-tunnels], which is out of scope of this document. scope of this document.
7.3. Fragmentation 7.3. Fragmentation
The encapsulation performed by an upstream AFBR will increase the The encapsulation performed by an upstream AFBR will increase the
size of packets. As a result, the outgoing I-IP link MTU may not size of packets. As a result, the outgoing I-IP link MTU may not
accommodate the larger packet size. It is not always possible for accommodate the larger packet size. It is not always possible for
core operators to increase the MTU of every link, thus fragmentation core operators to increase the MTU of every link, thus source
after encapsulation and reassembling of encapsulated packets MUST be fragmentation after encapsulation and reassembling of encapsulated
supported by AFBRs [RFC5565]. PMTUD [RFC8201] SHOULD be enabled and packets MUST be supported by AFBRs [RFC5565]. PMTUD [RFC8201] SHOULD
that ICMPv6 packets must not be filtered in the I-IP network. Using be enabled and ICMPv6 packets MUST NOT be filtered in the I-IP
tunnel will reduce the effective MTU of the datagram. When the network. Fragmentation and tunnel configuration considerations are
original packet size exceeds the effective MTU, fragmentation MUST provided in Section 8 of [RFC5565]. The detailed procedure can be
happen after encapsulation on the upstream AFBR, and reassembly MUST referred in Section 7.2 of [RFC2473].
happen before decapsulation on the downstream AFBR. Fragmentation
and tunnel configuration considerations are provided in [RFC5565] and
[I-D.ietf-intarea-tunnels]. The detailed procedure can be referred
in Section 7.2 of [RFC2473].
8. Packet Format and Translation 8. Packet Format and Translation
Because the PIM-SM Specification is independent of the underlying Because the PIM-SM Specification is independent of the underlying
unicast routing protocol, the packet format in Section 4.9 of unicast routing protocol, the packet format in Section 4.9 of
[RFC7761] remains the same, except that the group address and source [RFC7761] remains the same, except that the group address and source
address MUST be translated when traversing an AFBR. address MUST be translated when traversing an AFBR.
For example, Figure 5 shows the register-stop message format in the For example, Figure 5 shows the register-stop message format in the
IPv4 and IPv6 address families. IPv4 and IPv6 address families.
skipping to change at page 16, line 5 skipping to change at page 16, line 5
format of the IPv6 source address described in Section 5.3. format of the IPv6 source address described in Section 5.3.
9. Softwire Mesh Multicast Encapsulation 9. Softwire Mesh Multicast Encapsulation
Softwire mesh multicast encapsulation does not require the use of any Softwire mesh multicast encapsulation does not require the use of any
one particular encapsulation mechanism. Rather, it MUST accommodate one particular encapsulation mechanism. Rather, it MUST accommodate
a variety of different encapsulation mechanisms, and allow the use of a variety of different encapsulation mechanisms, and allow the use of
encapsulation mechanisms mentioned in [RFC4925]. Additionally, all encapsulation mechanisms mentioned in [RFC4925]. Additionally, all
of the AFBRs attached to the I-IP network MUST implement the same of the AFBRs attached to the I-IP network MUST implement the same
encapsulation mechanism, and follow the requirements mentioned in encapsulation mechanism, and follow the requirements mentioned in
[I-D.ietf-intarea-tunnels]. Section 8 of [RFC5565].
10. Security Considerations 10. Security Considerations
The security concerns raised in [RFC4925] and [RFC7761] are The security concerns raised in [RFC4925] and [RFC7761] are
applicable here. applicable here.
The additional workload associated with some schemes, such as The additional workload associated with some schemes, such as
interface agents, could be exploited by an attacker to perform a DDoS interface agents, could be exploited by an attacker to perform a DDoS
attack. attack.
skipping to change at page 16, line 30 skipping to change at page 16, line 30
be carefully configured, e.g., AFBRs only accept Well-Known prefix be carefully configured, e.g., AFBRs only accept Well-Known prefix
advertisements from trusted peers. Besides, cryptographic methods advertisements from trusted peers. Besides, cryptographic methods
for authenticating BGP sessions [RFC7454] could be used. for authenticating BGP sessions [RFC7454] could be used.
11. IANA Considerations 11. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
12. Normative References 12. Normative References
[I-D.ietf-intarea-tunnels]
Touch, J. and M. Townsley, "IP Tunnels in the Internet
Architecture", draft-ietf-intarea-tunnels-09 (work in
progress), July 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>. December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
 End of changes. 17 change blocks. 
35 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/