draft-ietf-dime-4over6-provisioning-05.txt   draft-ietf-dime-4over6-provisioning-06.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Intended status: Standards Track T. Taylor Intended status: Standards Track T. Taylor
Expires: February 7, 2016 PT Taylor Consulting Expires: February 7, 2016 PT Taylor Consulting
Q. Sun Q. Sun
China Telecom China Telecom
M. Boucadair M. Boucadair
France Telecom France Telecom
August 6, 2015 August 6, 2015
Attribute-Value Pairs For Provisioning Customer Equipment Supporting Attribute-Value Pairs For Provisioning Customer Equipment Supporting
IPv4-Over-IPv6 Transitional Solutions IPv4-Over-IPv6 Transitional Solutions
draft-ietf-dime-4over6-provisioning-05 draft-ietf-dime-4over6-provisioning-06
Abstract Abstract
During the transition from IPv4 to IPv6, customer equipment may have During the transition from IPv4 to IPv6, customer equipment may have
to support one of the various transition methods that have been to support one of the various transition methods that have been
defined for carrying IPv4 packets over IPv6. This document defined for carrying IPv4 packets over IPv6. This document
enumerates the information that needs to be provisioned on a customer enumerates the information that needs to be provisioned on a customer
edge router to support a list of transition techniques based on edge router to support a list of transition techniques based on
tunneling IPv4 in IPv6, with a view to defining reusable components tunneling IPv4 in IPv6, with a view to defining reusable components
for a reasonable transition path between these techniques. To the for a reasonable transition path between these techniques. To the
skipping to change at page 2, line 39 skipping to change at page 2, line 39
2.4. Mapping of Address and Port with Encapsulation (MAP-E) . 6 2.4. Mapping of Address and Port with Encapsulation (MAP-E) . 6
2.5. Parameters For Multicast . . . . . . . . . . . . . . . . 7 2.5. Parameters For Multicast . . . . . . . . . . . . . . . . 7
2.6. Summary and Discussion . . . . . . . . . . . . . . . . . 8 2.6. Summary and Discussion . . . . . . . . . . . . . . . . . 8
3. Attribute-Value Pair Definitions . . . . . . . . . . . . . . 8 3. Attribute-Value Pair Definitions . . . . . . . . . . . . . . 8
3.1. IP-Prefix-Length AVP . . . . . . . . . . . . . . . . . . 8 3.1. IP-Prefix-Length AVP . . . . . . . . . . . . . . . . . . 8
3.2. Border-Router-Name AVP . . . . . . . . . . . . . . . . . 9 3.2. Border-Router-Name AVP . . . . . . . . . . . . . . . . . 9
3.3. 64-Multicast-Attributes AVP . . . . . . . . . . . . . . . 9 3.3. 64-Multicast-Attributes AVP . . . . . . . . . . . . . . . 9
3.3.1. ASM-mPrefix64 AVP . . . . . . . . . . . . . . . . . . 9 3.3.1. ASM-mPrefix64 AVP . . . . . . . . . . . . . . . . . . 9
3.3.2. SSM-mPrefix64 AVP . . . . . . . . . . . . . . . . . . 10 3.3.2. SSM-mPrefix64 AVP . . . . . . . . . . . . . . . . . . 10
3.3.3. Delegated-IPv6-Prefix AVP As uPrefix64 . . . . . . . 10 3.3.3. Delegated-IPv6-Prefix AVP As uPrefix64 . . . . . . . 10
3.4. Tunnel-Source-Pref-Or-Addr AVP . . . . . . . . . . . . . 10 3.4. Tunnel-Source-Pref-Or-Addr AVP . . . . . . . . . . . . . 11
3.4.1. Delegated-IPv6-Prefix As the IPv6 Binding Prefix . . 11 3.4.1. Delegated-IPv6-Prefix As the IPv6 Binding Prefix . . 11
3.4.2. Tunnel-Source-IPv6-Address AVP . . . . . . . . . . . 11 3.4.2. Tunnel-Source-IPv6-Address AVP . . . . . . . . . . . 11
3.5. Port-Set-Identifier . . . . . . . . . . . . . . . . . . . 11 3.5. Port-Set-Identifier . . . . . . . . . . . . . . . . . . . 11
3.6. Lw4o6-Binding AVP . . . . . . . . . . . . . . . . . . . . 12 3.6. Lw4o6-Binding AVP . . . . . . . . . . . . . . . . . . . . 12
3.6.1. Lw4o6-External-IPv4-Addr AVP . . . . . . . . . . . . 12 3.6.1. Lw4o6-External-IPv4-Addr AVP . . . . . . . . . . . . 13
3.7. MAP-E-Attributes . . . . . . . . . . . . . . . . . . . . 13 3.7. MAP-E-Attributes . . . . . . . . . . . . . . . . . . . . 13
3.8. MAP-Mesh-Mode . . . . . . . . . . . . . . . . . . . . . . 14 3.8. MAP-Mesh-Mode . . . . . . . . . . . . . . . . . . . . . . 14
3.9. MAP-Mapping-Rule . . . . . . . . . . . . . . . . . . . . 14 3.9. MAP-Mapping-Rule . . . . . . . . . . . . . . . . . . . . 14
3.9.1. Rule-IPv4-Addr-Or-Prefix AVP . . . . . . . . . . . . 14 3.9.1. Rule-IPv4-Addr-Or-Prefix AVP . . . . . . . . . . . . 15
3.9.2. Rule-IPv6-Prefix AVP . . . . . . . . . . . . . . . . 15 3.9.2. Rule-IPv6-Prefix AVP . . . . . . . . . . . . . . . . 15
3.9.3. EA-Field-Length AVP . . . . . . . . . . . . . . . . . 16 3.9.3. EA-Field-Length AVP . . . . . . . . . . . . . . . . . 16
4. Attribute Value Pair Flag Rules . . . . . . . . . . . . . . . 16 4. Attribute Value Pair Flag Rules . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6.1. Man-In-The-Middle (MITM) Attacks . . . . . . . . . . . . 18 6.1. Man-In-The-Middle (MITM) Attacks . . . . . . . . . . . . 18
6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . 19
skipping to change at page 9, line 15 skipping to change at page 9, line 15
NOTE: The IP-Prefix-Length AVP is only relevant when associated NOTE: The IP-Prefix-Length AVP is only relevant when associated
with an IP-Address AVP in a Grouped AVP. with an IP-Address AVP in a Grouped AVP.
3.2. Border-Router-Name AVP 3.2. Border-Router-Name AVP
Following on the precedent set by [RFC6334] and [RFC6519], this Following on the precedent set by [RFC6334] and [RFC6519], this
document identifies a border router using an FQDN rather than an document identifies a border router using an FQDN rather than an
address. The Border-Router-Name AVP (AVP Code TBD01) is of type address. The Border-Router-Name AVP (AVP Code TBD01) is of type
OctetString. The FQDN encoding MUST follow the Name Syntax defined OctetString. The FQDN encoding MUST follow the Name Syntax defined
in [RFC1035][RFC1123][RFC2181] and are represented in ASCII form. in [RFC1035][RFC1123][RFC2181] and are represented in ASCII form.
Note, if Internationalized Domain Names (IDNs) are used, A-labels
defined in [RFC5891] must be used (see Appendix D of [RFC6733]).
3.3. 64-Multicast-Attributes AVP 3.3. 64-Multicast-Attributes AVP
The 64-Multicast-Attributes AVP (AVP Code TBD02) is of type Grouped. The 64-Multicast-Attributes AVP (AVP Code TBD02) is of type Grouped.
It contains the multicast-related IPv6 prefixes needed for providing It contains the multicast-related IPv6 prefixes needed for providing
IPv4 multicast over IPv6 using DS-Lite, MAP-E, or lw4o6, as mentioned IPv4 multicast over IPv6 using DS-Lite, MAP-E, or lw4o6, as mentioned
in Section 2.5. in Section 2.5.
The syntax is shown in Figure 1. The syntax is shown in Figure 1.
skipping to change at page 18, line 38 skipping to change at page 18, line 38
| TBD15 | EA-Field-Length | This document | | TBD15 | EA-Field-Length | This document |
+-------+----------------------------+---------------+ +-------+----------------------------+---------------+
Table 1 Table 1
6. Security Considerations 6. Security Considerations
6.1. Man-In-The-Middle (MITM) Attacks 6.1. Man-In-The-Middle (MITM) Attacks
The AVPs defined in this document face two threats, both dependent on The AVPs defined in this document face two threats, both dependent on
man-in-the-middle (MITM) attacks on the Diameter delivery path. The man-in-the-middle (MITM) attacks on the Diameter delivery path.
first threat is denial-of-service (DoS) through modification of the
AVP contents leading to misconfiguration (e.g., a subscriber may fail
to access its connectivity service if an invalid IP address was
configured, the subscriber's traffic can be intercepted by a
misbehaving node if a fake Border Node has been configured, etc.).
The second one is related to privacy (see Section 6.2).
Diameter security is currently provided on a hop-by-hop basis (see The first threat is denial-of-service (DoS) through modification of
Section 2.2 of [RFC6733]). The Diameter end-to-end security problem the AVP contents leading to misconfiguration, e.g., a subscriber may
has not been solved, so MITM attacks by Diameter peers along the path fail to access its connectivity service if an invalid IP address was
are possible. The present document does not propose to solve that configured, the subscriber's traffic can be intercepted by a
general problem, but simply warn that it exists. misbehaving node if a fake Border Node has been configured, etc.
Diameter-related security considerations are discussed in Section 13 The second threat is that Diameter security is currently provided on
of [RFC6733]. a hop-by-hop basis (see Section 2.2 of [RFC6733]). At the time of
writing, the Diameter end-to-end security problem has not been
solved, so MITM attacks by Diameter peers along the path are
possible. Diameter-related security considerations are discussed in
Section 13 of [RFC6733].
6.2. Privacy 6.2. Privacy
The AVPs defined in this document reveal privacy-related information Given that the AVPs defined in this document reveal privacy-related
(e.g., subscriber addresses) that can be used for tracking proposes. information (e.g., subscriber addresses) that can be used for
All these AVPs are considered to be security-sensitive. tracking proposes, all these AVPs are considered to be security-
Considerations discussed in Section 13.3 of [RFC6733] MUST be sensitive. Therefore the considerations discussed in Section 13.3 of
followed for Diameter messages containing these AVPs. [RFC6733] MUST be followed for Diameter messages containing these
AVPs.
7. Acknowledgements 7. Acknowledgements
Huawei Technologies funded Tom Taylor's work on earlier versions of Huawei Technologies funded Tom Taylor's work on earlier versions of
this document. this document.
Special thanks to Lionel Morand for the detailed review. Special thanks to Lionel Morand for the detailed review.
Many thanks to Russ Housley, Tim Chown, Spencer Dawkins, and Ben Many thanks to Russ Housley, Tim Chown, Spencer Dawkins, and Ben
Campbell for the review and comments. Campbell for the review and comments.
skipping to change at page 20, line 11 skipping to change at page 20, line 11
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", RFC 4818, DOI 10.17487/RFC4818, April 2007, Attribute", RFC 4818, DOI 10.17487/RFC4818, April 2007,
<http://www.rfc-editor.org/info/rfc4818>. <http://www.rfc-editor.org/info/rfc4818>.
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
Ed., and A. Lior, "Traffic Classification and Quality of Ed., and A. Lior, "Traffic Classification and Quality of
Service (QoS) Attributes for Diameter", RFC 5777, Service (QoS) Attributes for Diameter", RFC 5777,
DOI 10.17487/RFC5777, February 2010, DOI 10.17487/RFC5777, February 2010,
<http://www.rfc-editor.org/info/rfc5777>. <http://www.rfc-editor.org/info/rfc5777>.
[RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010,
<http://www.rfc-editor.org/info/rfc5891>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4 Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
<http://www.rfc-editor.org/info/rfc6333>. <http://www.rfc-editor.org/info/rfc6333>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733, Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012, DOI 10.17487/RFC6733, October 2012,
<http://www.rfc-editor.org/info/rfc6733>. <http://www.rfc-editor.org/info/rfc6733>.
 End of changes. 10 change blocks. 
23 lines changed or deleted 29 lines changed or added

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