Document Action: 'Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814 Pseudorandom Port Numbers' to Informational RFC (draft-ietf-bmwg-benchmarking-stateful-09.txt)
The IESG has approved the following document: - 'Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814 Pseudorandom Port Numbers' (draft-ietf-bmwg-benchmarking-stateful-09.txt) as Informational RFC This document is the product of the Benchmarking Methodology Working Group. The IESG contact persons are Warren Kumari and Mahesh Jethanandani. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-bmwg-benchmarking-stateful/ Technical Summary RFC 2544 has defined a benchmarking methodology for network interconnect devices. RFC 5180 addressed IPv6 specificities and it also provided a technology update but excluded IPv6 transition technologies. RFC 8219 addressed IPv6 transition technologies, including stateful NAT64. However, none of them discussed how to apply RFC 4814 pseudorandom port numbers to any stateful NATxy (NAT44, NAT64, NAT66) technologies. This document discusses why using pseudorandom port numbers with stateful NATxy gateways is a difficult problem. It recommends a solution limiting the port number ranges and using two test phases (phase 1 and phase 2). It is shown how the classic performance measurement procedures (e.g. throughput, frame loss rate, latency, etc.) can be carried out. New performance metrics and measurement procedures are also defined for measuring maximum connection establishment rate, connection tear-down rate, and connection tracking table capacity. Working Group Summary There was strong consensus, with broad agreement and no controversy. As the shepherd says: "No threats to appeal and no indications of extreme discontent. Or discontent in general." Document Quality The document is clear and easy to read. It contains a snippet of code for test results, and numerous test set up diagrams outlined in ASCII. Personnel Sarah Banks is DS. Warren "Ace" Kumari is RAD!!!1!!11! ___ IETF-Announce mailing list -- ietf-announce@ietf.org To unsubscribe send an email to ietf-announce-le...@ietf.org
Last Call: (Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814 Pseudorandom Port Numbers) to Informational RFC
The IESG has received a request from the Benchmarking Methodology WG (bmwg) to consider the following document: - 'Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814 Pseudorandom Port Numbers' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-05-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract RFC 2544 has defined a benchmarking methodology for network interconnect devices. RFC 5180 addressed IPv6 specificities and it also provided a technology update but excluded IPv6 transition technologies. RFC 8219 addressed IPv6 transition technologies, including stateful NAT64. However, none of them discussed how to apply RFC 4814 pseudorandom port numbers to any stateful NATxy (NAT44, NAT64, NAT66) technologies. This document discusses why using pseudorandom port numbers with stateful NATxy gateways is a difficult problem. It recommends a solution limiting the port number ranges and using two test phases (phase 1 and phase 2). It is shown how the classic performance measurement procedures (e.g. throughput, frame loss rate, latency, etc.) can be carried out. New performance metrics and measurement procedures are also defined for measuring maximum connection establishment rate, connection tear-down rate, and connection tracking table capacity. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bmwg-benchmarking-stateful/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list -- ietf-announce@ietf.org To unsubscribe send an email to ietf-announce-le...@ietf.org
RFC 9109 on Network Time Protocol Version 4: Port Randomization
A new Request for Comments is now available in online RFC libraries. RFC 9109 Title: Network Time Protocol Version 4: Port Randomization Author: F. Gont, G. Gont, M. Lichvar Status: Standards Track Stream: IETF Date: August 2021 Mailbox:fg...@si6networks.com, gg...@si6networks.com, mlich...@redhat.com Pages: 9 Updates:RFC 5905 I-D Tag:draft-ietf-ntp-port-randomization-08.txt URL:https://www.rfc-editor.org/info/rfc9109 DOI:10.17487/RFC9109 The Network Time Protocol (NTP) can operate in several modes. Some of these modes are based on the receipt of unsolicited packets and therefore require the use of a well-known port as the local port. However, in the case of NTP modes where the use of a well-known port is not required, employing such a well-known port unnecessarily facilitates the ability of attackers to perform blind/off-path attacks. This document formally updates RFC 5905, recommending the use of transport-protocol ephemeral port randomization for those modes where use of the NTP well-known port is not required. This document is a product of the Network Time Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Port Randomization in the Network Time Protocol Version 4' to Proposed Standard (draft-ietf-ntp-port-randomization-08.txt)
The IESG has approved the following document: - 'Port Randomization in the Network Time Protocol Version 4' (draft-ietf-ntp-port-randomization-08.txt) as Proposed Standard This document is the product of the Network Time Protocol Working Group. The IESG contact persons are Erik Kline and Éric Vyncke. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ntp-port-randomization/ Technical Summary The Network Time Protocol can operate in several modes. Some of these modes are based on the receipt of unsolicited packets, and therefore require the use of a well-known port as the local port number. However, in the case of NTP modes where the use of a well- known port is not required, employing such well-known port unnecessarily increases the ability of attackers to perform blind/ off-path attacks. This document formally updates RFC5905, recommending the use of transport-protocol ephemeral port randomization for those modes where use of the NTP well-known port is not required. Working Group Summary There was nothing particularly noteworthy in the WG process. Document Quality Many/most implementations already exhibit this behaviour. More implementation text is in Section 5. Personnel Karen O'Donoghue is the Document Shepherd. Erik Kline is the Responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Port Randomization in the Network Time Protocol Version 4) to Proposed Standard
The IESG has received a request from the Network Time Protocol WG (ntp) to consider the following document: - 'Port Randomization in the Network Time Protocol Version 4' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-02-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Network Time Protocol can operate in several modes. Some of these modes are based on the receipt of unsolicited packets, and therefore require the use of a well-known port as the local port number. However, in the case of NTP modes where the use of a well- known port is not required, employing such well-known port unnecessarily increases the ability of attackers to perform blind/ off-path attacks. This document formally updates RFC5905, recommending the use of transport-protocol ephemeral port randomization for those modes where use of the NTP well-known port is not required. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ntp-port-randomization/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 8676 on YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires
A new Request for Comments is now available in online RFC libraries. RFC 8676 Title: YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires Author: I. Farrer, Ed., M. Boucadair, Ed. Status: Standards Track Stream: IETF Date: November 2019 Mailbox:ian.far...@telekom.de, mohamed.boucad...@orange.com Pages: 46 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-softwire-yang-16.txt URL:https://www.rfc-editor.org/info/rfc8676 DOI:10.17487/RFC8676 This document defines YANG modules for the configuration and operation of IPv4-in-IPv6 softwire Border Relays and Customer Premises Equipment for the Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), and Mapping of Address and Port using Translation (MAP-T) softwire mechanisms. This document is a product of the Softwires Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 8658 on RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P)
A new Request for Comments is now available in online RFC libraries. RFC 8658 Title: RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P) Author: S. Jiang, Ed., Y. Fu, Ed., C. Xie, T. Li, M. Boucadair, Ed. Status: Standards Track Stream: IETF Date: November 2019 Mailbox:jiangsh...@huawei.com, eleven711...@foxmail.com, xiechf@chinatelecom.cn, peter416...@gmail.com, mohamed.boucad...@orange.com Pages: 34 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-softwire-map-radius-26.txt URL:https://www.rfc-editor.org/info/rfc8658 DOI:10.17487/RFC8658 IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity services over IPv6 native networks during the IPv4/IPv6 coexistence period. DHCPv6 options have been defined to configure clients for Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), Mapping of Address and Port using Translation (MAP-T) unicast softwire mechanisms, and multicast softwires. However, in many networks, configuration information is stored in an Authentication, Authorization, and Accounting (AAA) server, which utilizes the Remote Authentication Dial In User Service (RADIUS) protocol to provide centralized management for users. When a new transition mechanism is developed, new RADIUS attributes need to be defined correspondingly. This document defines new RADIUS attributes to carry softwire configuration parameters based on Address plus Port from a AAA server to a Broadband Network Gateway. Both unicast and multicast attributes are covered. This document is a product of the Softwires Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'RADIUS Attributes for Address plus Port (A+P) based Softwire Mechanisms' to Proposed Standard (draft-ietf-softwire-map-radius-26.txt)
The IESG has approved the following document: - 'RADIUS Attributes for Address plus Port (A+P) based Softwire Mechanisms' (draft-ietf-softwire-map-radius-26.txt) as Proposed Standard This document is the product of the Softwires Working Group. The IESG contact persons are Éric Vyncke and Suresh Krishnan. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/ == Technical Summary == IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity services over IPv6 native networks during the IPv4/IPv6 co-existence period. DHCPv6 options have been defined for configuring clients for Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E) and Mapping of Address and Port using Translation (MAP-T) unicast softwire mechanisms, and also multicast softwires. However, in many networks, configuration information is stored in an Authentication, Authorization, and Accounting server which utilizes the RADIUS protocol to provide centralized management for users. When a new transition mechanism is developed, new RADIUS attributes need to be defined correspondingly. This document defines new RADIUS attributes to carry Address plus Port based softwire configuration parameters from an Authentication, Authorization, and Accounting server to a Broadband Network Gateway. Both unicast and multicast attributes are covered. == Working Group Summary == No points or controversy has been raised during the authoring or review process. The author's original scope was just to define RADIUS attributes for MAP-E & MAP-T based softwire configuration, but by agreement of the WG, the document scope was extended to cover all standards track softwire mechanisms (unicast and multicast) that do not currently have RADIUS configuration defined. == Document Quality == The draft has been reviewed by Alan DeKok (RADEXT) who suggested substantial changes to make the document more readable and in line with recent RADIUS document conventions. Chongfeng Xie from China Telecom made the following statement regarding an implementation: "We have done some implementations when we carried out Lightweight4over6 trial in some provinces of China." Per AD request, there were more reviews from: - opsdir (Al Morton): ready - genart (Joel Halpern): almost ready - intdir (Bernie Volz): ready with issues - secdir (Donald Eastlake): almost ready (note: this review is not reflected yet in the data tracker but authors have issued a revised I-D addressing the review) The main editor of the document was prompt to reply, explain and revise the I-D. == Personnel == Ian Farrer (Softwire co-chair), is the Document Shepherd. Eric Vyncke is the Responsible AD. == IANA Note == IANA is requested to assign the Attribute Types defined in this document from the RADIUS namespace. IANA is requested to create a new registry called "RADIUS Softwire46 Configuration and Multicast Attributes". IANA is requested to create and maintain a new registry entitled "Option Codes Permitted in the Softwire46-Priority Attribute". Revision -24 addresses all issues raised by IANA about -23.
Last Call: (RADIUS Attributes for Address plus Port (A+P) based Softwire Mechanisms) to Proposed Standard
The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'RADIUS Attributes for Address plus Port (A+P) based Softwire Mechanisms' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-05-31. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity services over IPv6 native networks during the IPv4/IPv6 co-existence period. DHCPv6 options have been defined for configuring clients for Lightweight 4over6, Mapping of Address and Port with Encapsulation, and Mapping of Address and Port using Translation unicast softwire mechanisms, and also multicast softwires. However, in many networks, configuration information is stored in an Authentication, Authorization, and Accounting server which utilizes the RADIUS protocol to provide centralized management for users. When a new transition mechanism is developed, new RADIUS attributes need to be defined correspondingly. This document defines new RADIUS attributes to carry Address plus Port based softwire configuration parameters from an Authentication, Authorization, and Accounting server to a Broadband Network Gateway. Both unicast and multicast attributes are covered. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/ballot/ No IPR declarations have been submitted directly on this I-D.
RFC 8545 on Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP)
A new Request for Comments is now available in online RFC libraries. RFC 8545 Title: Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) Author: A. Morton, Ed., G. Mirsky, Ed. Status: Standards Track Stream: IETF Date: March 2019 Mailbox:acmor...@att.com, gregimir...@gmail.com Pages: 11 Characters: 22389 Updates:RFC 4656, RFC 5357 I-D Tag:draft-ietf-ippm-port-twamp-test-04.txt URL:https://www.rfc-editor.org/info/rfc8545 DOI:10.17487/RFC8545 This memo explains the motivation and describes the reassignment of well-known ports for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) for control and measurement. It also clarifies the meaning and composition of these Standards Track protocol names for the industry. This memo updates RFCs 4656 and 5357, in terms of the UDP well-known port assignments, and it clarifies the complete OWAMP and TWAMP protocol composition for the industry. This document is a product of the IP Performance Measurement Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Protocol Action: 'YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires' to Proposed Standard (draft-ietf-softwire-yang-16.txt)
The IESG has approved the following document: - 'YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires' (draft-ietf-softwire-yang-16.txt) as Proposed Standard This document is the product of the Softwires Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/ Technical Summary This document defines YANG modules for the configuration and operation of IPv4-in-IPv6 softwire Border Relays and Customer Premises Equipment for the Lightweight 4over6, MAP-E, and MAP-T softwire mechanisms. Working Group Summary This document was called draft-sun-softwire-yang prior to its adoption. There was unanimous support for it in favor of adoption and none against, so this document was adopted in August 2016. There was interest in this work posts since its adoption. There was never any opposition for this work. This document went through a relevant long document development period (22 months for individual document period, 23 month for WG document period). It has been reviewed well. Document Quality This document went through multiple reviews by multiple participants. So far, there is at least two existing implementations. They were exposed by the below two emails https://www.ietf.org/mail-archive/web/softwires/current/msg06924.html https://www.ietf.org/mail-archive/web/softwires/current/msg06928.html Personnel Sheng Jiang is the document shepherd. Terry Manderson is the responsible AD. IANA Note IANA is asked to registers three URIs in the IETF XML registry: URI: urn:ietf:params:xml:ns:yang:softwire-ce, URI: urn:ietf:params:xml:ns:yang:softwire-br, URI: urn:ietf:params:xml:ns:yang:softwire-common IANA is requested to registers three YANG modules in the YANG Module Names registry:ietf-softwire-ce, ietf-softwire-br, ietf-softwire-common. All the necessary information is in the IANA considerations document. It is clear enough that the IANA will be able to implement it.
RFC 8389 on Definitions of Managed Objects for Mapping of Address and Port with Encapsulation (MAP-E)
A new Request for Comments is now available in online RFC libraries. RFC 8389 Title: Definitions of Managed Objects for Mapping of Address and Port with Encapsulation (MAP-E) Author: Y. Fu, S. Jiang, B. Liu, J. Dong, Y. Chen Status: Standards Track Stream: IETF Date: December 2018 Mailbox:eleven711...@foxmail.com, jiangsh...@huawei.com, leo.liub...@huawei.com, knight.dongji...@gmail.com, flashfo...@gmail.com Pages: 16 Characters: 30534 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-softwire-map-mib-13.txt URL:https://www.rfc-editor.org/info/rfc8389 DOI:10.17487/RFC8389 This memo defines a portion of the Management Information Base (MIB) for Mapping of Address and Port with Encapsulation (MAP-E) for use with network management protocols. This document is a product of the Softwires Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Protocol Action: 'OWAMP and TWAMP Well-Known Port Assignments' to Proposed Standard (draft-ietf-ippm-port-twamp-test-04.txt)
The IESG has approved the following document: - 'OWAMP and TWAMP Well-Known Port Assignments' (draft-ietf-ippm-port-twamp-test-04.txt) as Proposed Standard This document is the product of the IP Performance Measurement Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-port-twamp-test/ Technical Summary This memo explains the motivation and describes the re-assignment of well-known ports for the OWAMP and TWAMP protocols for control and measurement, and clarifies the meaning and composition of these standards track protocol names for the industry. Working Group Summary There was reasonable discussions in the mailing list. A couple of people supported the adoption of this document. There was no objection in the mailing list when the WG chair raised the LC. Document Quality This document request an IANA action and clarifies existing RFCs. Therefore no implementation or additional reviews are needed. Personnel Tianran Zhou is the shepherd. Mirja Kühlewind is the responsible AD.
Last Call: (OWAMP and TWAMP Well-Known Port Assignments) to Proposed Standard
The IESG has received a request from the IP Performance Measurement WG (ippm) to consider the following document: - 'OWAMP and TWAMP Well-Known Port Assignments' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-11-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo explains the motivation and describes the re-assignment of well-known ports for the OWAMP and TWAMP protocols for control and measurement, and clarifies the meaning and composition of these standards track protocol names for the industry. The memo updates RFC 4656 and RFC 5357, in terms of the UDP well- known port assignments, and clarifies the complete OWAMP and TWAMP protocol composition for the industry. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ippm-port-twamp-test/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ippm-port-twamp-test/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7594: A Framework for Large-Scale Measurement of Broadband Performance (LMAP) (Informational - IETF stream)
RFC 8357 on Generalized UDP Source Port for DHCP Relay
A new Request for Comments is now available in online RFC libraries. RFC 8357 Title: Generalized UDP Source Port for DHCP Relay Author: N. Shen, E. Chen Status: Standards Track Stream: IETF Date: March 2018 Mailbox:naim...@cisco.com, enkec...@cisco.com Pages: 10 Characters: 21266 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-dhc-relay-port-10.txt URL:https://www.rfc-editor.org/info/rfc8357 DOI:10.17487/RFC8357 This document defines an extension to the DHCP protocols that allows a relay agent to use any available source port for upstream communications. The extension also allows inclusion of a DHCP option that can be used to statelessly route responses back to the appropriate source port on downstream communications. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Protocol Action: 'Generalized UDP Source Port for DHCP Relay' to Proposed Standard (draft-ietf-dhc-relay-port-10.txt)
The IESG has approved the following document: - 'Generalized UDP Source Port for DHCP Relay' (draft-ietf-dhc-relay-port-10.txt) as Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-port/ Technical Summary This document specifies an optional mechanism that lets the DHCPv4 and DHCPv6 relays to use different UDP ports than the standard ones, defined in RFC2131 and RFC3315. Working Group Summary This document has been presented in Berlin (IETF'96) and adopted in Oct. 2016. Even though the concept is very simple, there was an healthy discussion before it went through a successful WLGC. All the WGLC comments have been addressed. Document Quality The document has received multiple reviews on the dhc mailing list and has been reviewed by several DHCP experts. Personnel Tomek Mrugalski is the document shepherd. Suresh Krishnan is the responsible AD.
WG Action: Conclusion of Port Control Protocol (pcp)
The Port Control Protocol (pcp) working group in the Internet Area has successfully delivered the final deliverable in its charter. Now would be a great time to declare victory and close down the working group. I would like to express my sincere appreciation to Dave and Reinaldo for their excellent job chairing the working group to completion. I would also like to thank all the active authors, editors, contributors and reviewers who made all this work possible. The working group mailing list will be closed but the archives will continue to be available. - Suresh Krishnan, Internet Area Director
Last Call: (Generalized UDP Source Port for DHCP Relay) to Proposed Standard
The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Generalized UDP Source Port for DHCP Relay' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2017-10-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document proposes an extension to the DHCP protocols that allows a relay agent to receive packets from a server or an upstream relay agent on any UDP port, not just the default port 67 for IPv4 or default port 547 for IPv6. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-port/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-port/ballot/ No IPR declarations have been submitted directly on this I-D.
RFC 8045 on RADIUS Extensions for IP Port Configuration and Reporting
A new Request for Comments is now available in online RFC libraries. RFC 8045 Title: RADIUS Extensions for IP Port Configuration and Reporting Author: D. Cheng, J. Korhonen, M. Boucadair, S. Sivakumar Status: Standards Track Stream: IETF Date: January 2017 Mailbox:dean.ch...@huawei.com, jouni.nos...@gmail.com, mohamed.boucad...@orange.com, ssent...@cisco.com Pages: 43 Characters: 84193 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-radext-ip-port-radius-ext-17.txt URL:https://www.rfc-editor.org/info/rfc8045 DOI:10.17487/RFC8045 This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report IP transport ports as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN gateway, etc. This document defines a mapping between some RADIUS attributes and IP Flow Information Export (IPFIX) Information Element identifiers. This document is a product of the RADIUS EXTensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Protocol Action: 'RADIUS Extensions for IP Port Configuration and Reporting' to Proposed Standard (draft-ietf-radext-ip-port-radius-ext-16.txt)
The IESG has approved the following document: - 'RADIUS Extensions for IP Port Configuration and Reporting' (draft-ietf-radext-ip-port-radius-ext-16.txt) as Proposed Standard This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Benoit Claise, Kathleen Moriarty and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ Technical Summary This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc. Working Group Summary The draft has working group consensus. Document Quality The document has received a fair amount of review. Of note is that the shepherd report and document leave a decision up to IANA about the method used for allocating the TLV-Type for the sub-TLVs defined in this document. Two methods are possible and the WG leaves that decision to IANA. Personnel The document shepherd is Lionel Morand. The responsible Area Director is Kathleen Moriarty. IANA Note This document requires new code point assignments for both IPFIX Information Elements and RADIUS attributes. The specification also requests the allocation of new RADIUS TLVs.
Last Call: (RADIUS Extensions for IP Port Configuration and Reporting) to Proposed Standard
The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'RADIUS Extensions for IP Port Configuration and Reporting' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2016-08-11. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ballot/ No IPR declarations have been submitted directly on this I-D.
RFC 7843 on Port Control Protocol (PCP) Third-Party ID Option
A new Request for Comments is now available in online RFC libraries. RFC 7843 Title: Port Control Protocol (PCP) Third-Party ID Option Author: A. Ripke, R. Winter, T. Dietz, J. Quittek, R. da Silva Status: Standards Track Stream: IETF Date: May 2016 Mailbox:ri...@neclab.eu, win...@neclab.eu, di...@neclab.eu, quit...@neclab.eu, rafaelalejandro.lopezdasi...@telefonica.com Pages: 14 Characters: 30488 Updates:RFC 6887 I-D Tag:draft-ietf-pcp-third-party-id-option-08.txt URL:https://www.rfc-editor.org/info/rfc7843 DOI:http://dx.doi.org/10.17487/RFC7843 This document describes a new Port Control Protocol (PCP) option called the THIRD_PARTY_ID option. It is designed to be used together with the THIRD_PARTY option specified in RFC 6887. The THIRD_PARTY_ID option serves to identify a third party in situations where a third party's IP address contained in the THIRD_PARTY option does not provide sufficient information to create requested mappings in a PCP-controlled device. This document is a product of the Port Control Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 7767 on Application-Initiated Check-Pointing via the Port Control Protocol (PCP)
A new Request for Comments is now available in online RFC libraries. RFC 7767 Title: Application-Initiated Check-Pointing via the Port Control Protocol (PCP) Author: S. Vinapamula, S. Sivakumar, M. Boucadair, T. Reddy Status: Informational Stream: Independent Date: February 2016 Mailbox:sure...@juniper.net, ssent...@cisco.com, mohamed.boucad...@orange.com, tire...@cisco.com Pages: 12 Characters: 24178 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-vinapamula-flow-ha-14.txt URL:https://www.rfc-editor.org/info/rfc7767 DOI:http://dx.doi.org/10.17487/RFC7767 This document specifies a mechanism for a host to indicate via the Port Control Protocol (PCP) which connections should be protected against network failures. These connections will then be subject to high-availability mechanisms enabled on the network side. This approach assumes that applications and/or users have more visibility about sensitive connections than any heuristic that can be enabled on the network side to guess which connections should be check-pointed. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 7753 on Port Control Protocol (PCP) Extension for Port-Set Allocation
A new Request for Comments is now available in online RFC libraries. RFC 7753 Title: Port Control Protocol (PCP) Extension for Port-Set Allocation Author: Q. Sun, M. Boucadair, S. Sivakumar, C. Zhou, T. Tsou, S. Perreault Status: Standards Track Stream: IETF Date: February 2016 Mailbox:sunqi...@ctbri.com.cn, mohamed.boucad...@orange.com, ssent...@cisco.com, cathy.z...@huawei.com, tina.t...@philips.com, sperrea...@jive.com Pages: 19 Characters: 34550 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pcp-port-set-13.txt URL:https://www.rfc-editor.org/info/rfc7753 DOI:http://dx.doi.org/10.17487/RFC7753 In some use cases, e.g., Lightweight 4over6, the client may require not just one port, but a port set. This document defines an extension to the Port Control Protocol (PCP) that allows clients to manipulate a set of ports as a whole. This is accomplished using a new MAP option: PORT_SET. This document is a product of the Port Control Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 7768 on Port Management to Reduce Logging in Large-Scale NATs
A new Request for Comments is now available in online RFC libraries. RFC 7768 Title: Port Management to Reduce Logging in Large-Scale NATs Author: T. Tsou, W. Li, T. Taylor, J. Huang Status: Informational Stream: Independent Date: January 2016 Mailbox:tina.t...@philips.com, mweib...@gmail.com, tom.taylor.s...@gmail.com, james.hu...@huawei.com Pages: 11 Characters: 23442 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-tsou-behave-natx4-log-reduction-06.txt URL:https://www.rfc-editor.org/info/rfc7768 DOI:http://dx.doi.org/10.17487/RFC7768 Various IPv6 transition strategies require the introduction of large- scale NATs (e.g., AFTR and NAT64) to share the limited supply of IPv4 addresses available in the network until transition is complete. There has recently been debate over how to manage the sharing of ports between different subscribers sharing the same IPv4 address. One factor in the discussion is the operational requirement to log the assignment of transport addresses to subscribers. It has been argued that dynamic assignment of individual ports between subscribers requires the generation of an excessive volume of logs. This document suggests a way to achieve dynamic port sharing while keeping log volumes low. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 7723 on Port Control Protocol (PCP) Anycast Addresses
A new Request for Comments is now available in online RFC libraries. RFC 7723 Title: Port Control Protocol (PCP) Anycast Addresses Author: S. Kiesel, R. Penno Status: Standards Track Stream: IETF Date: January 2016 Mailbox:ietf-...@skiesel.de, repe...@cisco.com Pages: 9 Characters: 20663 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pcp-anycast-08.txt URL:https://www.rfc-editor.org/info/rfc7723 DOI:http://dx.doi.org/10.17487/RFC7723 The Port Control Protocol (PCP) anycast addresses enable PCP clients to transmit signaling messages to their closest PCP-aware on-path NAT, firewall, or other middlebox without having to learn the IP address of that middlebox via some external channel. This document establishes one well-known IPv4 address and one well-known IPv6 address to be used as PCP anycast addresses. This document is a product of the Port Control Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 7703 on Experience with Testing of Mapping of Address and Port Using Translation (MAP-T)
A new Request for Comments is now available in online RFC libraries. RFC 7703 Title: Experience with Testing of Mapping of Address and Port Using Translation (MAP-T) Author: E. Cordeiro, R. Carnier, A. Moreiras Status: Informational Stream: Independent Date: November 2015 Mailbox:ed...@scordeiro.net, rodrigocarn...@gmail.com, morei...@nic.br Pages: 56 Characters: 126481 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-cordeiro-experience-mapt-05.txt URL:https://www.rfc-editor.org/info/rfc7703 DOI:http://dx.doi.org/10.17487/RFC7703 This document describes the testing result of a network utilizing a Mapping of Address and Port using Translation (MAP-T) double translation solution; it provides an overview of user applications' behavior with a shared IPv4 address. The MAP-T software is from CERNET Center and the test environment is on the NIC.br network with real and virtualized machines. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Protocol Action: 'Port Control Protocol (PCP) Extension for Port Set Allocation' to Proposed Standard (draft-ietf-pcp-port-set-13.txt)
The IESG has approved the following document: - 'Port Control Protocol (PCP) Extension for Port Set Allocation' (draft-ietf-pcp-port-set-13.txt) as Proposed Standard This document is the product of the Port Control Protocol Working Group. The IESG contact persons are Brian Haberman and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-port-set/ Technical Summary This document defines an extension to the Port Control Protocol (PCP) allowing clients to manipulate sets of ports as a whole. This is accomplished by a new MAP option: PORT_SET. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? No Document Quality Are there existing implementations of the protocol? Yes, two implementations. Have a significant number of vendors indicated their plan to implement the specification? None besides the two implementations discussed during review. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? Dan Wing and Dave Thaler did a thorough review Personnel Who is the Document Shepherd? Reinaldo Penno Who is the Responsible Area Director? Brian Haberman <br...@innovationslab.net>
Protocol Action: 'Port Control Protocol (PCP) Anycast Addresses' to Proposed Standard (draft-ietf-pcp-anycast-08.txt)
The IESG has approved the following document: - 'Port Control Protocol (PCP) Anycast Addresses' (draft-ietf-pcp-anycast-08.txt) as Proposed Standard This document is the product of the Port Control Protocol Working Group. The IESG contact persons are Brian Haberman and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-anycast/ Technical Summary: The Port Control Protocol (PCP) Anycast Addresses enable PCP clients to transmit signaling messages to their closest PCP-aware on-path NAT, Firewall, or other middlebox, without having to learn the IP address of that middlebox via some external channel. This document establishes one well-known IPv4 address and one well-known IPv6 address to be used as PCP Anycast Addresses. Working Group Summary: The WG has consensus on this document, nothing particularly rough. Document Quality: Implementation status is unknown, although its existence was motivated by experience from Apple's implementation. Personnel: Who is the Document Shepherd? Dave Thaler <dtha...@microsoft.com> Who is the Responsible Area Director? Brian Haberman
RFC 7648 on Port Control Protocol (PCP) Proxy Function
A new Request for Comments is now available in online RFC libraries. RFC 7648 Title: Port Control Protocol (PCP) Proxy Function Author: S. Perreault, M. Boucadair, R. Penno, D. Wing, S. Cheshire Status: Standards Track Stream: IETF Date: September 2015 Mailbox:sperrea...@jive.com, mohamed.boucad...@orange.com, repe...@cisco.com, dw...@cisco.com, chesh...@apple.com Pages: 14 Characters: 31233 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pcp-proxy-09.txt URL:https://www.rfc-editor.org/info/rfc7648 DOI:http://dx.doi.org/10.17487/RFC7648 This document specifies a new Port Control Protocol (PCP) functional element: the PCP proxy. The PCP proxy relays PCP requests received from PCP clients to upstream PCP server(s). A typical deployment usage of this function is to help establish successful PCP communications for PCP clients that cannot be configured with the address of a PCP server located more than one hop away. This document is a product of the Port Control Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 7652 on Port Control Protocol (PCP) Authentication Mechanism
A new Request for Comments is now available in online RFC libraries. RFC 7652 Title: Port Control Protocol (PCP) Authentication Mechanism Author: M. Cullen, S. Hartman, D. Zhang, T. Reddy Status: Standards Track Stream: IETF Date: September 2015 Mailbox:marga...@painless-security.com, hartm...@painless-security.com, zhang_dach...@hotmail.com, tire...@cisco.com Pages: 34 Characters: 78237 Updates:RFC 6887 I-D Tag:draft-ietf-pcp-authentication-14.txt URL:https://www.rfc-editor.org/info/rfc7652 DOI:http://dx.doi.org/10.17487/RFC7652 An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to flexibly manage the IP address-mapping and port-mapping information on Network Address Translators (NATs) or firewalls to facilitate communication with remote hosts. However, the uncontrolled generation or deletion of IP address mappings on such network devices may cause security risks and should be avoided. In some cases, the client may need to prove that it is authorized to modify, create, or delete PCP mappings. This document describes an in-band authentication mechanism for PCP that can be used in those cases. The Extensible Authentication Protocol (EAP) is used to perform authentication between PCP devices. This document updates RFC 6887. This document is a product of the Port Control Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
BCP 165, RFC 7605 on Recommendations on Using Assigned Transport Port Numbers
A new Request for Comments is now available in online RFC libraries. BCP 165 RFC 7605 Title: Recommendations on Using Assigned Transport Port Numbers Author: J. Touch Status: Best Current Practice Stream: IETF Date: August 2015 Mailbox:to...@isi.edu Pages: 24 Characters: 58012 See Also: BCP 165 I-D Tag:draft-ietf-tsvwg-port-use-11.txt URL:https://www.rfc-editor.org/info/rfc7605 DOI:http://dx.doi.org/10.17487/RFC7605 This document provides recommendations to designers of application and service protocols on how to use the transport protocol port number space and when to request a port assignment from IANA. It provides designer guidance to requesters or users of port numbers on how to interact with IANA using the processes defined in RFC 6335; thus, this document complements (but does not update) that document. It provides guidelines for designers regarding how to interact with the IANA processes defined in RFC 6335, thus serving to complement (but not update) that document. This document is a product of the Transport Area Working Group Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 7599 on Mapping of Address and Port using Translation (MAP-T)
A new Request for Comments is now available in online RFC libraries. RFC 7599 Title: Mapping of Address and Port using Translation (MAP-T) Author: X. Li, C. Bao, W. Dec, Ed., O. Troan, S. Matsushima, T. Murakami Status: Standards Track Stream: IETF Date: July 2015 Mailbox:x...@cernet.edu.cn, congx...@cernet.edu.cn, w...@cisco.com, o...@cisco.com, satoru.matsush...@g.softbank.co.jp, tets...@ipinfusion.com Pages: 27 Characters: 55548 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-softwire-map-t-08.txt URL:https://www.rfc-editor.org/info/rfc7599 DOI:http://dx.doi.org/10.17487/RFC7599 This document specifies the solution architecture based on Mapping of Address and Port stateless IPv6-IPv4 Network Address Translation (NAT64) for providing shared or non-shared IPv4 address connectivity to and across an IPv6 network. This document is a product of the Softwires Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 7597 on Mapping of Address and Port with Encapsulation (MAP-E)
A new Request for Comments is now available in online RFC libraries. RFC 7597 Title: Mapping of Address and Port with Encapsulation (MAP-E) Author: O. Troan, Ed., W. Dec, X. Li, C. Bao, S. Matsushima, T. Murakami, T. Taylor, Ed. Status: Standards Track Stream: IETF Date: July 2015 Mailbox:o...@cisco.com, w...@cisco.com, x...@cernet.edu.cn, congx...@cernet.edu.cn, satoru.matsush...@g.softbank.co.jp, tets...@ipinfusion.com, tom.taylor.s...@gmail.com Pages: 35 Characters: 70507 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-softwire-map-13.txt URL:https://www.rfc-editor.org/info/rfc7597 DOI:http://dx.doi.org/10.17487/RFC7597 This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation. It also describes a generic mechanism for mapping between IPv6 addresses and IPv4 addresses as well as transport-layer ports. This document is a product of the Softwires Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 7598 on DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients
A new Request for Comments is now available in online RFC libraries. RFC 7598 Title: DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients Author: T. Mrugalski, O. Troan, I. Farrer, S. Perreault, W. Dec, C. Bao, L. Yeh, X. Deng Status: Standards Track Stream: IETF Date: July 2015 Mailbox:tomasz.mrugal...@gmail.com, o...@cisco.com, ian.far...@telekom.de, sperrea...@jive.com, w...@cisco.com, congx...@cernet.edu.cn, leaf.y@hotmail.com, dxhb...@gmail.com Pages: 18 Characters: 40023 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-softwire-map-dhcp-12.txt URL:https://www.rfc-editor.org/info/rfc7598 DOI:http://dx.doi.org/10.17487/RFC7598 This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices. Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address plus Port (A+P) for providing IPv4 connectivity across an IPv6 network. This document is a product of the Softwires Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Protocol Action: 'Port Control Protocol (PCP) Authentication Mechanism' to Proposed Standard (draft-ietf-pcp-authentication-13.txt)
The IESG has approved the following document: - 'Port Control Protocol (PCP) Authentication Mechanism' (draft-ietf-pcp-authentication-13.txt) as Proposed Standard This document is the product of the Port Control Protocol Working Group. The IESG contact persons are Brian Haberman and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-authentication/ Technical Summary: An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to flexibly manage the IP address and port mapping information on Network Address Translators (NATs) or firewalls, to facilitate communication with remote hosts. However, the un-controlled generation or deletion of IP address mappings on such network devices may cause security risks and should be avoided. In some cases the client may need to prove that it is authorized to modify, create or delete PCP mappings. This document describes an in-band authentication mechanism for PCP that can be used in those cases. The Extensible Authentication Protocol (EAP) is used to perform authentication between PCP devices. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There is strong consensus to use an EAP-based mechanism for security. There was, however, significant controversy about whether to use PANA. A consensus call was done on the list, and (rough) consensus was called by by the chairs in close cooperation with the responsible AD, following the advice outlined in what is now RFC 7282. The chairs reported the results at IETF 87, with slides at http://www.ietf.org/proceedings/87/slides/slides-87-pcp-11.pdf where rough consensus was declared for not using PANA. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? There is at least one implementation of this protocol, and eventually more are expected. Many individuals have reviewed various versions of this document over a long period of time. Personnel: Who is the Document Shepherd? Dave Thaler dtha...@microsoft.com Who is the Responsible Area Director? Brian Haberman br...@innovationslab.net
Protocol Action: 'Port Control Protocol (PCP) Proxy Function' to Proposed Standard (draft-ietf-pcp-proxy-09.txt)
The IESG has approved the following document: - 'Port Control Protocol (PCP) Proxy Function' (draft-ietf-pcp-proxy-09.txt) as Proposed Standard This document is the product of the Port Control Protocol Working Group. The IESG contact persons are Brian Haberman and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-proxy/ Technical Summary: This document specifies a new PCP functional element denoted as a PCP Proxy. The PCP Proxy relays PCP requests received from PCP clients to upstream PCP server(s). A typical deployment usage of this function is to help establish successful PCP communications for PCP clients that can not be configured with the address of a PCP server located more than one hop away. Working Group Summary: The WG has consensus on this document, nothing particularly rough. Document Quality: It is unknown whether there are existing implementations, although the existence of this draft was motivated by experience from Apple's implementation. Personnel: Who is the Document Shepherd? Dave Thaler dtha...@microsoft.com Who is the Responsible Area Director? Brian Haberman br...@innovationslab.net
UPDATED Protocol Action: 'Port Control Protocol (PCP) Authentication Mechanism' to Proposed Standard (draft-ietf-pcp-authentication-14.txt)
The IESG has approved the following document: - 'Port Control Protocol (PCP) Authentication Mechanism' (draft-ietf-pcp-authentication-14.txt) as Proposed Standard This document is the product of the Port Control Protocol Working Group. The IESG contact persons are Brian Haberman and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-authentication/ Technical Summary: An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to flexibly manage the IP address and port mapping information on Network Address Translators (NATs) or firewalls, to facilitate communication with remote hosts. However, the un-controlled generation or deletion of IP address mappings on such network devices may cause security risks and should be avoided. In some cases the client may need to prove that it is authorized to modify, create or delete PCP mappings. This document describes an in-band authentication mechanism for PCP that can be used in those cases. The Extensible Authentication Protocol (EAP) is used to perform authentication between PCP devices. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There is strong consensus to use an EAP-based mechanism for security. There was, however, significant controversy about whether to use PANA. A consensus call was done on the list, and (rough) consensus was called by by the chairs in close cooperation with the responsible AD, following the advice outlined in what is now RFC 7282. The chairs reported the results at IETF 87, with slides at http://www.ietf.org/proceedings/87/slides/slides-87-pcp-11.pdf where rough consensus was declared for not using PANA. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? There is at least one implementation of this protocol, and eventually more are expected. Many individuals have reviewed various versions of this document over a long period of time. Personnel: Who is the Document Shepherd? Dave Thaler dtha...@microsoft.com Who is the Responsible Area Director? Brian Haberman br...@innovationslab.net
Last Call: draft-ietf-pcp-proxy-08.txt (Port Control Protocol (PCP) Proxy Function) to Proposed Standard
The IESG has received a request from the Port Control Protocol WG (pcp) to consider the following document: - 'Port Control Protocol (PCP) Proxy Function' draft-ietf-pcp-proxy-08.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2015-06-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a new PCP functional element denoted as a PCP Proxy. The PCP Proxy relays PCP requests received from PCP clients to upstream PCP server(s). A typical deployment usage of this function is to help establish successful PCP communications for PCP clients that can not be configured with the address of a PCP server located more than one hop away. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pcp-proxy/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-pcp-proxy/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-ietf-pcp-authentication-11.txt (Port Control Protocol (PCP) Authentication Mechanism) to Proposed Standard
The IESG has received a request from the Port Control Protocol WG (pcp) to consider the following document: - 'Port Control Protocol (PCP) Authentication Mechanism' draft-ietf-pcp-authentication-11.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2015-06-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to flexibly manage the IP address and port mapping information on Network Address Translators (NATs) or firewalls, to facilitate communication with remote hosts. However, the un-controlled generation or deletion of IP address mappings on such network devices may cause security risks and should be avoided. In some cases the client may need to prove that it is authorized to modify, create or delete PCP mappings. This document describes an in-band authentication mechanism for PCP that can be used in those cases. The Extensible Authentication Protocol (EAP) is used to perform authentication between PCP devices. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pcp-authentication/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-pcp-authentication/ballot/ No IPR declarations have been submitted directly on this I-D. This document contains a normative reference to an Informational RFC (RFC 5281). This Last Call also requests the addition of RFC 5281 to the Downref registry (https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry).
Last Call: draft-ietf-pcp-anycast-06.txt (Port Control Protocol (PCP) Anycast Addresses) to Proposed Standard
The IESG has received a request from the Port Control Protocol WG (pcp) to consider the following document: - 'Port Control Protocol (PCP) Anycast Addresses' draft-ietf-pcp-anycast-06.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2015-06-11. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Port Control Protocol (PCP) Anycast Addresses enable PCP clients to transmit signaling messages to their closest PCP-aware on-path NAT, Firewall, or other middlebox, without having to learn the IP address of that middlebox via some external channel. This document establishes one well-known IPv4 address and one well-known IPv6 address to be used as PCP Anycast Addresses. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pcp-anycast/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-pcp-anycast/ballot/ No IPR declarations have been submitted directly on this I-D.
Protocol Action: 'Recommendations on Using Assigned Transport Port Numbers' to Best Current Practice (draft-ietf-tsvwg-port-use-11.txt)
The IESG has approved the following document: - 'Recommendations on Using Assigned Transport Port Numbers' (draft-ietf-tsvwg-port-use-11.txt) as Best Current Practice This document is the product of the Transport Area Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ Technical Summary This document provides recommendations to application and service designers on how to use the transport protocol port number space. It complements (but does not update) RFC 6335, which focuses on IANA process. Working Group Summary The usual collection of controversial topics was raised and discussed in the working group (for example, the need to conserve assigned ports, given the current usage rate). The document provides guidance to protocol and application designers on best current practices for requesting and using ports; BCP status clearly conveys the nature, importance and relevance of that guidance. Some reviewers have noted that this application of BCP status may not be aligned with their understanding of BCP status (RFC 2026, Section 5) and/or with current IETF usage of BCP status in practice. The responsible AD is OK with doing this document as a BCP. Document Quality After IETF Last Call, Spencer asked Martin and Wes (current and former TSV ADs, and both active port registry expert reviewers) to re-review the document, making sure it describes the way other port expert reviewers work. We did get IETF Last Call comments that asked for more clarity on the relationship between this document and RFC 6335, resulting in the RFC Editor Note below. Personnel The Document Shepherd is G Fairhurst (TSVWG Co-Chair). The Responsible Area Director is Spencer Dawkins (TSV AD). RFC Editor Note In the Abstract --- OLD This document provides recommendations to application and service designers on how to use the transport protocol port number space. It complements (but does not update) RFC6335, which focuses on IANA process. --- NEW This document provides recommendations to application and service protocol designers on how to use the transport protocol port number space and when to request a port assignment from IANA. It provides designer guidelines on how to interact with the IANA processes defined in RFC6335, thus serving to complement (but not update) that document.
RFC 7488 on Port Control Protocol (PCP) Server Selection
A new Request for Comments is now available in online RFC libraries. RFC 7488 Title: Port Control Protocol (PCP) Server Selection Author: M. Boucadair, R. Penno, D. Wing, P. Patil, T. Reddy Status: Standards Track Stream: IETF Date: March 2015 Mailbox:mohamed.boucad...@orange.com, repe...@cisco.com, dw...@cisco.com, prasp...@cisco.com, tire...@cisco.com Pages: 12 Characters: 22577 Updates:RFC 6887 I-D Tag:draft-ietf-pcp-server-selection-10.txt URL:https://www.rfc-editor.org/info/rfc7488 This document specifies the behavior to be followed by a Port Control Protocol (PCP) client to contact its PCP server(s) when one or several PCP server IP addresses are configured. This document updates RFC 6887. This document is a product of the Port Control Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Protocol Action: 'Mapping of Address and Port using Translation (MAP-T)' to Proposed Standard (draft-ietf-softwire-map-t-08.txt)
The IESG has approved the following document: - 'Mapping of Address and Port using Translation (MAP-T)' (draft-ietf-softwire-map-t-08.txt) as Proposed Standard This document is the product of the Softwires Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-softwire-map-t/ Technical Summary: The Mapping of Address and Port - Translation (MAP-T) is a double stateless NAT64 based solution. It builds on existing stateless NAT64 techniques specified in [RFC6145], along with the stateless algorithmic address transport layer port mapping scheme defined in MAP-E. The MAP-T solution differs from MAP-E in the use of IPv4-IPv6 translation, rather than encapsulation, as the form of IPv6 domain transport. The translation mode is considered advantageous in scenarios where the encapsulation overhead, or IPv6 operational practices rule out encapsulation. Working Group Summary: The working group had active discussion on the draft and the current text of the draft is representative of the consensus of the working group. Document Quality: The document has received adequate review. The Document Shepherd has no concerns about the depth or breadth of these reviews. There are several interoperable implementations of the scheme and they have been demonstrated and tested during the IETF meetings. Interoperability test results have been documented in draft-xli-softwire-map-testing-04. Experiences from MAP-T Testing have been documented in draft-cordeiro-softwire-experience-mapt-02. Some of the use cases have been documented in draft-maglione-softwire-map-t-scenarios-04. Personnel: Suresh Krishnan is the document shepherd. Ted Lemon is the responsible AD. RFC Editor Note: This document is one of a set of five softwire documents that should be published with sequential RFC numbers. The numbering should be in the following order: draft-ietf-softwire-lw4over6 draft-ietf-softwire-map draft-ietf-softwire-map-dhcp draft-ietf-softwire-map-t draft-ietf-softwire-4rd
Protocol Action: 'DHCPv6 Options for configuration of Softwire Address and Port Mapped Clients' to Proposed Standard (draft-ietf-softwire-map-dhcp-12.txt)
The IESG has approved the following document: - 'DHCPv6 Options for configuration of Softwire Address and Port Mapped Clients' (draft-ietf-softwire-map-dhcp-12.txt) as Proposed Standard This document is the product of the Softwires Working Group. The IESG contact persons are Brian Haberman and Ted Lemon. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-softwire-map-dhcp/ Technical Summary This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices. Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address+Port (A+P) for providing IPv4 connectivity across an IPv6 network. Working Group Summary The working group had active discussion on the draft and the current text of the draft is representative of the consensus of the working group. This document was a result of merging DHCPv6 options required for several softwire solutions into a single document and rationalizing them after consolidating similar options and removing duplicates. Document Quality There is an open source implementation of these options in the recently released OpenWRT software (the BARRIER BREAKER release). There are also available implementations of the mechanism specific options that got merged into this draft. Personnel Suresh Krishnan is the document shepherd. Ted Lemon is the responsible AD. RFC Editor Note This document makes frequent use of the term sub-option, which is incorrect according to RFC 7227, section 9. The correct term is encapsulated option. Please double-check that all such uses are corrected. Thanks! This document is one of a set of five softwire documents that should be published with sequential RFC numbers. The numbering should be in the following order: draft-ietf-softwire-lw4over6 draft-ietf-softwire-map draft-ietf-softwire-map-dhcp draft-ietf-softwire-map-t draft-ietf-softwire-4rd
Protocol Action: 'Mapping of Address and Port with Encapsulation (MAP)' to Proposed Standard (draft-ietf-softwire-map-13.txt)
The IESG has approved the following document: - 'Mapping of Address and Port with Encapsulation (MAP)' (draft-ietf-softwire-map-13.txt) as Proposed Standard This document is the product of the Softwires Working Group. The IESG contact persons are Brian Haberman and Ted Lemon. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-softwire-map/ Technical Summary: This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation, and a generic mechanism for mapping between IPv6 addresses and IPv4 addresses and transport layer ports.The mapping scheme described here supports encapsulation of IPv4 packets in IPv6 in both mesh and hub and spoke topologies, including address mappings with full independence between IPv6 and IPv4 addresses. This document describes delivery of IPv4 unicast service across an IPv6 infrastructure. A companion document describes the DHCPv6 options necessary for provisioning of MAP. Working Group Summary: The working group had active discussion on the draft and the current text of the draft is representative of the consensus of the working group. This document and the lightweight 4over6 document are closely related and it led to a lot of friction in the working group. MAP is capable of either providing independence between IPv6 subnet prefix and IPv4 address or, alternatively, reducing the amount of centralized state using rules to express IPv4/IPv6 address mappings. This introduces an algorithmic relationship between the IPv6 subnet and IPv4 address. This relationship also allows the option of direct, meshed connectivity between users. Lightweight 4over6, on the other hand, is a solution designed specifically for complete independence between IPv6 subnet prefix and IPv4 address with or without IPv4 address sharing. This is accomplished by maintaining state for each softwire (per-subscriber state) in the central lwAFTR and a hub-and-spoke forwarding architecture. Document Quality: The document has received adequate review. The Document Shepherd has no concerns about the depth or breadth of these reviews. There are several interoperable implementations of the scheme and they have been demonstrated and tested during the IETF meetings. Personnel: Suresh Krishnan is the document shepherd. Ted Lemon is the responsible AD. RFC Editor Note: This document is one of a set of five softwire documents that should be published with sequential RFC numbers. The numbering should be in the following order: draft-ietf-softwire-lw4over6 draft-ietf-softwire-map draft-ietf-softwire-map-dhcp draft-ietf-softwire-map-t draft-ietf-softwire-4rd
Last Call: draft-ietf-softwire-map-t-08.txt (Mapping of Address and Port using Translation (MAP-T)) to Proposed Standard
The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'Mapping of Address and Port using Translation (MAP-T)' draft-ietf-softwire-map-t-08.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2015-02-05. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This last call is being re-issued because an IPR disclosure was entered after the previous last call text was generated, and hence we do not feel confident that the IPR disclosure was considered and had consensus to proceed during last call. Abstract This document specifies the Mapping of Address and Port stateless IPv6-IPv4 Network Address Translation (NAT64) based solution architecture for providing shared or non-shared IPv4 address connectivity to and across an IPv6 network. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-map-t/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-map-t/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2501/
Last Call: draft-ietf-softwire-map-t-08.txt (Mapping of Address and Port using Translation (MAP-T)) to Experimental RFC
The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'Mapping of Address and Port using Translation (MAP-T)' draft-ietf-softwire-map-t-08.txt as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2014-12-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the Mapping of Address and Port stateless IPv6-IPv4 Network Address Translation (NAT64) based solution architecture for providing shared or non-shared IPv4 address connectivity to and across an IPv6 network. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-map-t/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-map-t/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-ietf-tsvwg-port-use-06.txt (Recommendations for Transport Port Number Uses) to Best Current Practice
The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Recommendations for Transport Port Number Uses' draft-ietf-tsvwg-port-use-06.txt as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2014-12-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides recommendations to application and service designers on how to use the transport protocol port number space. IT complements (but does not update) RFC6335, which focuses on IANA process. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ballot/ No IPR declarations have been submitted directly on this I-D.
RFC 7393 on Using the Port Control Protocol (PCP) to Update Dynamic DNS
A new Request for Comments is now available in online RFC libraries. RFC 7393 Title: Using the Port Control Protocol (PCP) to Update Dynamic DNS Author: X. Deng, M. Boucadair, Q. Zhao, J. Huang, C. Zhou Status: Informational Stream: Independent Date: November 2014 Mailbox:dxhb...@gmail.com, mohamed.boucad...@orange.com, zhaoqin.b...@gmail.com, james.hu...@huawei.com, cathy.z...@huawei.com Pages: 14 Characters: 30130 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-deng-pcp-ddns-06.txt URL:https://www.rfc-editor.org/rfc/rfc7393.txt This document focuses on the problems encountered when using dynamic DNS in address-sharing contexts (e.g., Dual-Stack Lite (DS-Lite) and Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64)) during IPv6 transition. Both issues and possible solutions are documented in this memo. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Last Call: draft-ietf-softwire-map-dhcp-08.txt (DHCPv6 Options for configuration of Softwire Address and Port Mapped Clients) to Proposed Standard
The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'DHCPv6 Options for configuration of Softwire Address and Port Mapped Clients' draft-ietf-softwire-map-dhcp-08.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2014-10-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices. Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address+Port (A+P) for providing IPv4 connectivity across an IPv6 network. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-map-dhcp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-map-dhcp/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-ietf-softwire-map-t-05.txt (Mapping of Address and Port using Translation (MAP-T)) to Experimental RFC
The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'Mapping of Address and Port using Translation (MAP-T)' draft-ietf-softwire-map-t-05.txt as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2014-10-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the Mapping of Address and Port stateless IPv6-IPv4 Network Address Translation (NAT64) based solution architecture for providing shared or non-shared IPv4 address connectivity to and across an IPv6 network. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-map-t/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-map-t/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-ietf-softwire-map-10.txt (Mapping of Address and Port with Encapsulation (MAP)) to Proposed Standard
The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'Mapping of Address and Port with Encapsulation (MAP)' draft-ietf-softwire-map-10.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2014-10-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation, and a generic mechanism for mapping between IPv6 addresses and IPv4 addresses and transport layer ports. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-map/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-map/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2049/
RFC 7291 on DHCP Options for the Port Control Protocol (PCP)
A new Request for Comments is now available in online RFC libraries. RFC 7291 Title: DHCP Options for the Port Control Protocol (PCP) Author: M. Boucadair, R. Penno, D. Wing Status: Standards Track Stream: IETF Date: July 2014 Mailbox:mohamed.boucad...@orange.com, repe...@cisco.com, dw...@cisco.com Pages: 11 Characters: 20868 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pcp-dhcp-13.txt URL:http://www.rfc-editor.org/rfc/rfc7291.txt This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) server IP addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenarios. The set of deployment scenarios to which DHCPv4 or DHCPv6 can be applied is outside the scope of this document. This document is a product of the Port Control Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Protocol Action: 'DHCP Options for the Port Control Protocol (PCP)' to Proposed Standard (draft-ietf-pcp-dhcp-13.txt)
The IESG has approved the following document: - 'DHCP Options for the Port Control Protocol (PCP)' (draft-ietf-pcp-dhcp-13.txt) as Proposed Standard This document is the product of the Port Control Protocol Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pcp-dhcp/ Technical Summary: This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) Server IP addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenario. Working Group Summary: There was controversy around the use of IP address vs hostnames vs strings passed to getaddrinfo (which could be hostname or IP literal). The WG eventually achieved rough consensus on the IP address mechanism recommended by Ted Lemon, referencing [I-D.ietf-dhc-topo-conf] informatively for discussion on how various scenarios can still be solved using that mechanism. Document Quality: One implementation is documented at http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00#section-2.9 Other implementations are expected. Ted Lemon performed DHCP review and raised issues with the previous approach (strings passed to getaddrinfo). A significant discussion ensued which resulted in Ted authoring draft-ietf-dhc-topo-conf for WGs and documents to reference. That document was presented to the PCP WG, which then got consensus on the final approach (IP addresses, and referencing that draft for discussion of operational guidance). Personnel: Dave Thaler is the Document Shepherd. Ted Lemon is the Responsible Area Director. RFC Editor Note: In section 8, please make the following change: OLD: The PCP Server option targets mainly the simple threat model (Section 18.1 of [RFC6887]). It is out of scope of this document to discuss potential implications of the use of this option in the advanced threat model (Section 18.2 of [RFC6887]). NEW: The PCP server option defined here is applicable when operating under the simple threat model (Section 18.1 of [RFC6887]). Operation under the advanced threat model (section 18.2 of [RFC6887]) may or may not be appropriate; analysis of this question is out of scope for this document.
Protocol Action: 'Learning NAT64 PREFIX64s using Port Control Protocol (PCP)' to Proposed Standard (draft-ietf-pcp-nat64-prefix64-06.txt)
The IESG has approved the following document: - 'Learning NAT64 PREFIX64s using Port Control Protocol (PCP)' (draft-ietf-pcp-nat64-prefix64-06.txt) as Proposed Standard This document is the product of the Port Control Protocol Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pcp-nat64-prefix64/ Technical Summary This document defines a new PCP extension to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses. This extension is needed for successful communications when IPv4 addresses are used in referrals. Working Group Summary The WG easily got consensus. Document Quality It is unknown whether there are existing implementations. A large number of people (named in section 8 of the doc) reviewed it and contributed to it. The individuals who provided reviews during WGLC were: Dave Thaler Teemu Savolainen Senthil Sivakumar Simon Perreault Iljitsch van Beijnum Personnel Document Shepherd: Dave Thaler dtha...@microsoft.com Responsible AD: Ted Lemon ted.le...@nominum.com
Results of IETF-conflict review for draft-hartmann-default-port-for-irc-via-tls-ssl-09
The IESG has completed a review of draft-hartmann-default-port-for-irc-via-tls-ssl-09 consistent with RFC5742. The IESG has no problem with the publication of 'Default Port for IRC via TLS/SSL' draft-hartmann-default-port-for-irc-via-tls-ssl-09.txt as an Informational RFC. The IESG has concluded that there is no conflict between this document and IETF work. The IESG would also like the RFC-Editor to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: http://datatracker.ietf.org/doc/conflict-review-hartmann-default-port-for-irc-via-tls-ssl/ A URL of the reviewed Internet Draft is: http://datatracker.ietf.org/doc/draft-hartmann-default-port-for-irc-via-tls-ssl/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary
Protocol Action: 'Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP) Interworking Function' to Proposed Standard (draft-ietf-pcp-upnp-igd-interworking-10.txt)
The IESG has approved the following document: - 'Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP) Interworking Function' (draft-ietf-pcp-upnp-igd-interworking-10.txt) as Proposed Standard This document is the product of the Port Control Protocol Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pcp-upnp-igd-interworking/ Technical Summary This document specifies the behavior of the UPnP IGD (Internet Gateway Device)/PCP Interworking Function. A UPnP IGD-PCP Interworking Function (IGD-PCP IWF) is required to be embedded in CP (Customer Premises) routers to allow for transparent NAT control in environments where UPnP IGD is used on the LAN side and PCP on the external side of the CP router. Working Group Summary Nothing unusual. Document Quality A public implementation is available at http://sourceforge.net/projects/pcpclient/?source=directory. The authors are also aware of other implementations from some CPE vendors that are not yet disclosed publically. The PCP WG has a policy to not send a document until the WG has consensus and there are at least 5 people who have reviewed and ok'ed the document. Many others were involved in reviews of earlier versions, but the WGLC oks came from: Xiaohong Deng dxhb...@gmail.com Dave Thaler dtha...@microsoft.com Reinaldo Penno repe...@cisco.com Tiru Reddy tire...@cisco.com Paul Selkirk pselk...@isc.org The above reviewers collectively represent multiple implementations or potential future implementations. Personnel Dave Thaler dtha...@microsoft.com is the document shepherd; Ted Lemon ted.le...@nominum.com is the responsible AD.
RFC 6886 on NAT Port Mapping Protocol (NAT-PMP)
A new Request for Comments is now available in online RFC libraries. RFC 6886 Title: NAT Port Mapping Protocol (NAT-PMP) Author: S. Cheshire, M. Krochmal Status: Informational Stream: Independent Date: April 2013 Mailbox:chesh...@apple.com, m...@apple.com Pages: 33 Characters: 87897 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-cheshire-nat-pmp-07.txt URL:http://www.rfc-editor.org/rfc/rfc6886.txt This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the external IPv4 address of a NAT gateway, thus allowing a client to make its external IPv4 address and port known to peers that may wish to communicate with it. From 2005 onwards, this protocol was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded by the IETF Standards Track RFC Port Control Protocol (PCP), which builds on NAT-PMP and uses a compatible packet format, but adds a number of significant enhancements. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 6887 on Port Control Protocol (PCP)
A new Request for Comments is now available in online RFC libraries. RFC 6887 Title: Port Control Protocol (PCP) Author: D. Wing, Ed., S. Cheshire, M. Boucadair, R. Penno, P. Selkirk Status: Standards Track Stream: IETF Date: April 2013 Mailbox:dw...@cisco.com, chesh...@apple.com, mohamed.boucad...@orange.com, repe...@cisco.com, pselk...@isc.org Pages: 88 Characters: 221314 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pcp-base-29.txt URL:http://www.rfc-editor.org/rfc/rfc6887.txt The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. This document is a product of the Port Control Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Last Call: draft-ietf-pcp-upnp-igd-interworking-07.txt (Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP) Interworking Function) to Proposed Standard
The IESG has received a request from the Port Control Protocol WG (pcp) to consider the following document: - 'Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP) Interworking Function' draft-ietf-pcp-upnp-igd-interworking-07.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-04-08. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the behavior of the UPnP IGD (Internet Gateway Device)/PCP Interworking Function. A UPnP IGD-PCP Interworking Function (IGD-PCP IWF) is required to be embedded in CP (Customer Premises) routers to allow for transparent NAT control in environments where UPnP IGD is used on the LAN side and PCP on the external side of the CP router. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pcp-upnp-igd-interworking/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pcp-upnp-igd-interworking/ballot/ No IPR declarations have been submitted directly on this I-D.
Protocol Action: 'Port Control Protocol (PCP)' to Proposed Standard (draft-ietf-pcp-base-29.txt)
The IESG has approved the following document: - 'Port Control Protocol (PCP)' (draft-ietf-pcp-base-29.txt) as Proposed Standard This document is the product of the Port Control Protocol Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pcp-base/ Technical Summary The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. Working Group Summary At the outset, the WG looked at many other protocols that have been proposed in the past for doing similar things, but almost none have been successful in getting real deployment. The exceptions are NAT-PMP and UPnP-IGD. Between them, the WG concluded that NAT-PMP was more closely aligned with the intended scenarios and hence used NAT-PMP as the starting point for PCP. Document Quality Several PCP implementations exist, and some interoperability testing has already been done. Margaret Wasserman did a thorough security analysis and wrote the security considerations section. Many others (beyond the authors themselves), including a number of implementers, have also done reviews and are acknowledged in the document. Personnel The Document Shepherd is Dave Thaler and the responsible Area Director is Ralph Droms.
RFC 6736 on Diameter Network Address and Port Translation Control Application
A new Request for Comments is now available in online RFC libraries. RFC 6736 Title: Diameter Network Address and Port Translation Control Application Author: F. Brockners, S. Bhandari, V. Singh, V. Fajardo Status: Standards Track Stream: IETF Date: October 2012 Mailbox:fbroc...@cisco.com, shwet...@cisco.com, vaneeta.si...@gmail.com, vf0...@gmail.com Pages: 58 Characters: 138288 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-dime-nat-control-17.txt URL:http://www.rfc-editor.org/rfc/rfc6736.txt This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per-endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4 address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device -- expanding the existing Diameter-based Authentication, Authorization, and Accounting (AAA) and policy control capabilities with a Network Address Translator and Network Address and Port Translator control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. [STANDARDS-TRACK] This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Protocol Action: 'Diameter Network Address and Port Translation Control Application' to Proposed Standard (draft-ietf-dime-nat-control-17.txt)
The IESG has approved the following document: - 'Diameter Network Address and Port Translation Control Application' (draft-ietf-dime-nat-control-17.txt) as Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Benoit Claise and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dime-nat-control/ Technical Summary This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4-address space completion. This Diameter application allows external devices to configure and manage a Network Address Translator device - expanding the existing Diameter-based AAA and policy control capabilities with a Network Address Translators and Network Address and Port Translators control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA- servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server, and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. Working Group Summary The document spent well over a year in the WG and has had an intensive review in the WG. However, the authors actively kept the document progressing and improving. The document is a result of collaborative WG work. Document Quality There is currently no publicly announced implementations of the protocol. The document itself is solid, well written and in places goes into level of details not often seen in Diameter Application describing documents. Personnel Jouni Korhonen is the Document Shepherd for this document. Dan Romascanu is the Responsible Area Director.
Re: [pcp] Last Call: draft-ietf-pcp-base-23.txt (Port Control Protocol (PCP)) to Proposed Standard
The IESG wrote: The IESG has received a request from the Port Control Protocol WG (pcp) to consider the following document: - 'Port Control Protocol (PCP)' draft-ietf-pcp-base-23.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-27. The protocol lacks transaction IDs and is fatally broken. That is, the protocol is expected to generate refresh request packets and expect response packets. However, as all the request packets are expected to be identical, it is impossible to have correspondences between request and response packets. So, if requests are sent at 0, 5, 240, 245, 480 and 485 seconds and responses with lifetime of 300 are received at 10, 250 and 490 seconds, it is impossible to know which request corresponds to the response at 490 seconds. If the response is generated against request at 485 second, remaining lifetime of the response is 295 seconds. However, if the response is generated against request at 0 second, lifetime of the response has expired 190 seconds ago. But, without transaction ID to distinguish requests and responses, the worst case must be assumed, which means the response must be interpreted that lifetime expired 190 seconds ago, which means all the subsequent responses are meaningless because their lifetime must be interpreted to have expired. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-pcp-base-23.txt (Port Control Protocol (PCP)) to Proposed Standard
The IESG has received a request from the Port Control Protocol WG (pcp) to consider the following document: - 'Port Control Protocol (PCP)' draft-ietf-pcp-base-23.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-02-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pcp-base/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pcp-base/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
CORRECTED Document Action: 'A Reliable Transport Mechanism for PIM' to Experimental RFC (draft-ietf-pim-port-09.txt)
The IESG has approved the following document: - 'A Reliable Transport Mechanism for PIM' (draft-ietf-pim-port-09.txt) as an Experimental RFC This document is the product of the Protocol Independent Multicast Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pim-port/ Technical Summary This document creates a simple incremental mechanism to provide reliable PIM message delivery in PIM version 2 for use with PIM Sparse-Mode (including Source-Specific Multicast) and Bidirectional PIM. The reliable transport mechanism will be used for Join-Prune message transmission only, and can use either TCP or SCTP as the transport protocol. Working Group Summary WG progress was smooth with a large number of comments from many people helping to form the document. Document Quality This is an Experimental document. At least one implementation exists. Personnel Mike McBride (mmcbri...@gmail.com) is the Document Shepherd. Adrian Farrel (adr...@olddog.co.uk) is the Responsible AD RFC Editor Note End of 3.1: OLD: TCP Connection ID AFI: The AFI value to describe the address-family of the address of the TCP Connection ID field. When this field is 0, a mechanism outside the scope of this document is used to obtain the addresses used to establish the TCP connection. NEW: TCP Connection ID AFI: The AFI value to describe the address-family of the address of the TCP Connection ID field. Note that this value does not need to match the address-family of the PIM Hello message that carries it. When this field is 0, a mechanism outside the scope of this document is used to obtain the addresses used to establish the TCP connection. End of 3.2: OLD: SCTP Connection ID AFI: The AFI value to describe the address- family of the address of the SCTP Connection ID field. When this field is 0, a mechanism outside the scope of this document is used to obtain the addresses used to establish the SCTP connection. NEW: SCTP Connection ID AFI: The AFI value to describe the address- family of the address of the SCTP Connection ID field. Note that this value does not need to match the address-family of the PIM Hello message that carries it. When this field is 0, a mechanism outside the scope of this document is used to obtain the addresses used to establish the SCTP connection. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6431 on Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP)
A new Request for Comments is now available in online RFC libraries. RFC 6431 Title: Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP) Author: M. Boucadair, P. Levis, G. Bajko, T. Savolainen, T. Tsou Status: Informational Stream: Independent Date: November 2011 Mailbox:mohamed.boucad...@orange.com, pierre.le...@orange.com, gabor.ba...@nokia.com, teemu.savolai...@nokia.com, tina.tsou.zout...@huawei.com Pages: 16 Characters: 33981 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-boucadair-pppext-portrange-option-09.txt URL:http://www.rfc-editor.org/rfc/rfc6431.txt This document defines two Huawei IPCP (IP Control Protocol) options used to convey a set of ports. These options can be used in the context of port range-based solutions or NAT-based solutions for port delegation and forwarding purposes. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: TSVDIR review of draft-ietf-pim-port-08.txt
On 10/18/2011 10:36 AM, Gorry Fairhurst wrote: In most cases you replied OK - so I'm assuming the draft will be updated to reflect this and my comments will have been addressed. Thanks Gorry. I've submitted 09 now which I think should address all the issues you raised. If you like, see the diff at http://tools.ietf.org/rfcdiff?url2=draft-ietf-pim-port-09 Stig You raised a few specific questions: On 11/10/2011 18:36, Stig Venaas wrote: a few retransmissions would be OK, several seems better. OK, but isn't it usually 3 or so? a few retransmissions would be OK, several seems better. OK, but isn't it usually 3 or so? GF - No it's not. The TCP RTO backs off each TO, and stops when this exceeds 64 secs. It can be a while... The issue is what IP addresses to use in the pseudo header. We could say they should be the same as the addresses for the PORT connection (but that is problematic since they may be of a different address familty), or the addresses you would have used for the native PIM message (this is better, but doesn't make much sense really). However, what do you think of saying that they should be 0 when calculating the checksum? Since the message is sent inside a TCP connection (which has its own checksum), it is almost redundant. At least I don't think including the addresses in the checksum are all that useful, since there is no danger of a single PIM message ending up at the wrong host (due to the TCP checks). I'll ask the WG about this too, but wondering if you have any concerns with just setting them to 0. GF - I think this would be fine, IMHO zeroed addresses with checksum is much better than no checksum. --- It is defined that critical option means that the entire message must be ignored if unknown. For non-critical, only the option is ignored. When defining future options the doc/RFC must specify what type it is. They would know what is the right thing to do. GF - This sounds fine, if it actually say this in the IANA section, I'd have ignored this. GF - If the IPv6-IPv4 comments have been considered and don't seem to be an issue by you after thinking this through, then I'd assume this is not an issue. Hope this helps, Gorry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [pim] Last Call: draft-ietf-pim-port-08.txt (A Reliable TransportMechanism for PIM) to Experimental RFC
On 9/27/2011 5:25 PM, Joe Touch wrote: Hi, all, The IANA considerations in this doc are in error and need updating as follows. I agree that PORT is a poor acronym choice, FWIW. Thanks Joe/Tom. I'm changing this per your suggestions. Stig Joe 11. IANA Considerations This specification makes use of a TCP port number and a SCTP port number for the use of PIM-Over-Reliable-Transport that has been allocated by IANA. It also makes use of IANA PIM Hello Options allocations that should be made permanent. The current IANA allocation is called pim-port, not PIM-Over-Reliable-Transport. The long name (description) is PIM over Reliable-Transport, but that's not the authoritative name of the service - also, IANA does assignments (as per RFC 6335); this section should read as follows. This specification makes use of a TCP port number and a SCTP port number for the use of pim-port service that has been assigned by IANA. It also makes use of IANA PIM Hello Options assignments that should be made permanent. 11.1. PORT Port Number IANA has assigned a port number that is used as a destination port for PORT TCP and SCTP transports. The assigned number is 8471. References to this document should be added to the Service Name and Transport Protocol Port Number Registry. This should read: IANA has already assigned a port number that is used as a destination port for pim-port TCP and SCTP transports. The assigned number is 8471. References to this document should be added to the Service Name and Transport Protocol Port Number Registry for pim-port. On 9/27/2011 1:46 AM, t.petch wrote: The choice of service name for this transport seems unfortunate; having a port number registry with a service in it called 'port' may be witty but seems like a source of future confusion. I notice that IANA currently have a service name of 'pim-port' which seems a better idea and one that I think that this I-D should adopt. Tom Petch - Original Message - From: The IESGiesg-secret...@ietf.org To: IETF-Announceietf-annou...@ietf.org Cc:p...@ietf.org Sent: Monday, September 26, 2011 9:40 PM Subject: Last Call:draft-ietf-pim-port-08.txt (A Reliable TransportMechanism for PIM) to Experimental RFC The IESG has received a request from the Protocol Independent Multicast WG (pim) to consider the following document: - 'A Reliable Transport Mechanism for PIM' draft-ietf-pim-port-08.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing. The reliable transport mechanism can use either TCP or SCTP as the transport protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pim-port/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pim-port/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ pim mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/pim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-pim-port-08.txt
In most cases you replied OK - so I'm assuming the draft will be updated to reflect this and my comments will have been addressed. You raised a few specific questions: On 11/10/2011 18:36, Stig Venaas wrote: a few retransmissions would be OK, several seems better. OK, but isn't it usually 3 or so? a few retransmissions would be OK, several seems better. OK, but isn't it usually 3 or so? GF - No it's not. The TCP RTO backs off each TO, and stops when this exceeds 64 secs. It can be a while... The issue is what IP addresses to use in the pseudo header. We could say they should be the same as the addresses for the PORT connection (but that is problematic since they may be of a different address familty), or the addresses you would have used for the native PIM message (this is better, but doesn't make much sense really). However, what do you think of saying that they should be 0 when calculating the checksum? Since the message is sent inside a TCP connection (which has its own checksum), it is almost redundant. At least I don't think including the addresses in the checksum are all that useful, since there is no danger of a single PIM message ending up at the wrong host (due to the TCP checks). I'll ask the WG about this too, but wondering if you have any concerns with just setting them to 0. GF - I think this would be fine, IMHO zeroed addresses with checksum is much better than no checksum. --- It is defined that critical option means that the entire message must be ignored if unknown. For non-critical, only the option is ignored. When defining future options the doc/RFC must specify what type it is. They would know what is the right thing to do. GF - This sounds fine, if it actually say this in the IANA section, I'd have ignored this. GF - If the IPv6-IPv4 comments have been considered and don't seem to be an issue by you after thinking this through, then I'd assume this is not an issue. Hope this helps, Gorry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-pim-port-08.txt
Thanks Stig - there are a few comments in-line. Note this review is really for the TSV ADs benefit, so be sure to check with them what needs to be done. However, I can clarify a few points that probably will help. Gorry On 10/10/2011 20:13, Stig Venaas wrote: Thanks for the review Gorry, please see below. On 10/7/2011 4:28 AM, Gorry Fairhurst wrote: Hi, all, I've reviewed this document as a part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. The document describes a protocol that is designed to use a TCP or SCTP transport. The use of TCP is application-limited and a negotiation mechanism is provided that helps select whether TCP or SCTP should be used. The note below includes transport issues, as well as additional comments that I hope are also useful. I hope this feedback will be useful to the authors, and will be glad to provide further assistance either on- or off-list as useful. Gorry - Overall this document seems complete and uses standard IETF transport mechanisms that support congestion control. Introduction: Recommend to specify the IANA-assigned port. Since this specifies a protocol that runs over a specific IANA-allocated port it would be good if the port number was mentioned in the Introduction. This may confirm that this is the correct document to read to find out about what happens when port 8471 is used (e.g. someone interpreting IPFIX or building a NAT, Firewall, etc). OK, can do that. I think they would typically check the IANA registry first though? Section 4 (and others, including section 7): AF for transport. I understand there is a rule to prefer SCTP over TCP when both transports are available. This seems OK. Various sections refer to the support for multiple address families (IPv4, IPv6) and I understand that the PORT information for an AF does need not to be carried over a transport connection using the same AF. What I do not yet understand is how PORT knows whether to use an IPv4 transport for IPv6 or to use an IPv6 transport for IPv6. I'd like this to be clear, so that I can understand what happens when TCP is available over Ipv4 and SCTP only over IPv6 and similar combinations. Which address family and address to use is determined by the Connection ID in the PORT Hello Option. It is up to the implementation and admin to choose which address the connection should go to. There are several implementation choices, but I think it will be common to use the primary interface address (the source address of PIM messages) as a default Connection ID, but allow the administrator to configure another address. The administrator can then choose which address and family to configure. Just to be clear, I was asking what the should happen when say IPv6/SCTP and IPv4/TCP are available - and either can carry IPv4 and IPv6 PORT. Section 4.2: TCP keep-alive. SCTP heartbeat is described. I understand PORT also includes an optional keep-alive mechanism using the transport service. TCP also contains an optional keep-alive mechanism. This should be mentioned. Is TCP keep-alive recommended for PORT or does the protocol recommend a keep-alive at the PORT layer? We chose to have our own keep-alive mechanism, as we believe that is better. There is nothing stopping an implementation from enabling TCP keep-alive if they want though. I guess we could do this change: OLD: SCTP has a heart beat mechanism that can be used to detect that a connection is working, even when no data is sent. NEW: SCTP has a heart beat mechanism that can be used to detect that a connection is not working, even when no data is sent. Many TCP implementations also support sending keep-alives for this purpose. Note that I changed working to not working, I think it makes more sense that way. Looks good to me. We're trying to not give any specific recommendations here, only enough to ensure interoperability. Both TCP keep-alive and the use of PORT keep-alive can be decided by independently by the peers. Note that this is an experimental protocol, and hopefully what works best, or is the preferred solution will become clearer with real use. Understood. If this is part of the experiment, then please say this (so we remember when the draft is revised in future). Section 4.2: TCP Reset The present text says that the TCP connection will be reset after a few reties. This does not seem clear. A lack of acknowledgement for a sent data segment will result in the underlying TCP tansport retransmitting after the Retransmission Time Out (RTO). Furthermore this would cause the RTO to be doubled with each
Re: TSVDIR review of draft-ietf-pim-port-08.txt
On 10/11/2011 10:03 AM, Gorry Fairhurst wrote: Thanks Stig - there are a few comments in-line. Note this review is really for the TSV ADs benefit, so be sure to check with them what needs to be done. However, I can clarify a few points that probably will help. Gorry On 10/10/2011 20:13, Stig Venaas wrote: Thanks for the review Gorry, please see below. On 10/7/2011 4:28 AM, Gorry Fairhurst wrote: Hi, all, I've reviewed this document as a part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. The document describes a protocol that is designed to use a TCP or SCTP transport. The use of TCP is application-limited and a negotiation mechanism is provided that helps select whether TCP or SCTP should be used. The note below includes transport issues, as well as additional comments that I hope are also useful. I hope this feedback will be useful to the authors, and will be glad to provide further assistance either on- or off-list as useful. Gorry - Overall this document seems complete and uses standard IETF transport mechanisms that support congestion control. Introduction: Recommend to specify the IANA-assigned port. Since this specifies a protocol that runs over a specific IANA-allocated port it would be good if the port number was mentioned in the Introduction. This may confirm that this is the correct document to read to find out about what happens when port 8471 is used (e.g. someone interpreting IPFIX or building a NAT, Firewall, etc). OK, can do that. I think they would typically check the IANA registry first though? Section 4 (and others, including section 7): AF for transport. I understand there is a rule to prefer SCTP over TCP when both transports are available. This seems OK. Various sections refer to the support for multiple address families (IPv4, IPv6) and I understand that the PORT information for an AF does need not to be carried over a transport connection using the same AF. What I do not yet understand is how PORT knows whether to use an IPv4 transport for IPv6 or to use an IPv6 transport for IPv6. I'd like this to be clear, so that I can understand what happens when TCP is available over Ipv4 and SCTP only over IPv6 and similar combinations. Which address family and address to use is determined by the Connection ID in the PORT Hello Option. It is up to the implementation and admin to choose which address the connection should go to. There are several implementation choices, but I think it will be common to use the primary interface address (the source address of PIM messages) as a default Connection ID, but allow the administrator to configure another address. The administrator can then choose which address and family to configure. Just to be clear, I was asking what the should happen when say IPv6/SCTP and IPv4/TCP are available - and either can carry IPv4 and IPv6 PORT. OK, maybe this needs to be clarified. But basically, IPv4 and IPv6 PIM are treated as entirely separate (except for connection sharing, see below). I thought that was clear. Everything is done separately for the two address families (just like is done today for PIM). Whether to use PORT or not, what transport, and the transport end-point addresses are all done separately. There are separate Hello messages with different options for the two families too. The only exception is connection sharing, which is described as: If PORT is used both for IPv4 and IPv6, both IPv4 and IPv6 PIM Hello messages MUST be sent, both containing PORT Hello options. If two neighbors announce the same transport (TCP or SCTP) and the same Connection ID in the IPv4 and IPv6 Hello messages, then only one connection is established and is shared. Otherwise, two connections are established and are used separately. Section 4.2: TCP keep-alive. SCTP heartbeat is described. I understand PORT also includes an optional keep-alive mechanism using the transport service. TCP also contains an optional keep-alive mechanism. This should be mentioned. Is TCP keep-alive recommended for PORT or does the protocol recommend a keep-alive at the PORT layer? We chose to have our own keep-alive mechanism, as we believe that is better. There is nothing stopping an implementation from enabling TCP keep-alive if they want though. I guess we could do this change: OLD: SCTP has a heart beat mechanism that can be used to detect that a connection is working, even when no data is sent. NEW: SCTP has a heart beat mechanism that can be used to detect that a connection is not working, even when no data is sent. Many TCP implementations also
Re: TSVDIR review of draft-ietf-pim-port-08.txt
Thanks for the review Gorry, please see below. On 10/7/2011 4:28 AM, Gorry Fairhurst wrote: Hi, all, I've reviewed this document as a part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. The document describes a protocol that is designed to use a TCP or SCTP transport. The use of TCP is application-limited and a negotiation mechanism is provided that helps select whether TCP or SCTP should be used. The note below includes transport issues, as well as additional comments that I hope are also useful. I hope this feedback will be useful to the authors, and will be glad to provide further assistance either on- or off-list as useful. Gorry - Overall this document seems complete and uses standard IETF transport mechanisms that support congestion control. Introduction: Recommend to specify the IANA-assigned port. Since this specifies a protocol that runs over a specific IANA-allocated port it would be good if the port number was mentioned in the Introduction. This may confirm that this is the correct document to read to find out about what happens when port 8471 is used (e.g. someone interpreting IPFIX or building a NAT, Firewall, etc). OK, can do that. I think they would typically check the IANA registry first though? Section 4 (and others, including section 7): AF for transport. I understand there is a rule to prefer SCTP over TCP when both transports are available. This seems OK. Various sections refer to the support for multiple address families (IPv4, IPv6) and I understand that the PORT information for an AF does need not to be carried over a transport connection using the same AF. What I do not yet understand is how PORT knows whether to use an IPv4 transport for IPv6 or to use an IPv6 transport for IPv6. I'd like this to be clear, so that I can understand what happens when TCP is available over Ipv4 and SCTP only over IPv6 and similar combinations. Which address family and address to use is determined by the Connection ID in the PORT Hello Option. It is up to the implementation and admin to choose which address the connection should go to. There are several implementation choices, but I think it will be common to use the primary interface address (the source address of PIM messages) as a default Connection ID, but allow the administrator to configure another address. The administrator can then choose which address and family to configure. Section 4.2: TCP keep-alive. SCTP heartbeat is described. I understand PORT also includes an optional keep-alive mechanism using the transport service. TCP also contains an optional keep-alive mechanism. This should be mentioned. Is TCP keep-alive recommended for PORT or does the protocol recommend a keep-alive at the PORT layer? We chose to have our own keep-alive mechanism, as we believe that is better. There is nothing stopping an implementation from enabling TCP keep-alive if they want though. I guess we could do this change: OLD: SCTP has a heart beat mechanism that can be used to detect that a connection is working, even when no data is sent. NEW: SCTP has a heart beat mechanism that can be used to detect that a connection is not working, even when no data is sent. Many TCP implementations also support sending keep-alives for this purpose. Note that I changed working to not working, I think it makes more sense that way. We're trying to not give any specific recommendations here, only enough to ensure interoperability. Both TCP keep-alive and the use of PORT keep-alive can be decided by independently by the peers. Note that this is an experimental protocol, and hopefully what works best, or is the preferred solution will become clearer with real use. Section 4.2: TCP Reset The present text says that the TCP connection will be reset after a few reties. This does not seem clear. A lack of acknowledgement for a sent data segment will result in the underlying TCP tansport retransmitting after the Retransmission Time Out (RTO). Furthermore this would cause the RTO to be doubled with each retransmission, until the RTO exceeds the maximum value when the connection will be reset, this is typically many 10s of seconds later. OK, what if I change it into a few TCP retransmissions? The main purpose here is to explain that we notice the connection is going down as long as we periodically send data. We're not going into details about exactly how long it takes. Section 5: Unexpected corruption of the stream It is good to see the service using the transport, in this case PORT verifies the integrity of the transported data. The recommendation seems
TSVDIR review of draft-ietf-pim-port-08.txt
Hi, all, I've reviewed this document as a part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. The document describes a protocol that is designed to use a TCP or SCTP transport. The use of TCP is application-limited and a negotiation mechanism is provided that helps select whether TCP or SCTP should be used. The note below includes transport issues, as well as additional comments that I hope are also useful. I hope this feedback will be useful to the authors, and will be glad to provide further assistance either on- or off-list as useful. Gorry - Overall this document seems complete and uses standard IETF transport mechanisms that support congestion control. Introduction: Recommend to specify the IANA-assigned port. Since this specifies a protocol that runs over a specific IANA-allocated port it would be good if the port number was mentioned in the Introduction. This may confirm that this is the correct document to read to find out about what happens when port 8471 is used (e.g. someone interpreting IPFIX or building a NAT, Firewall, etc). Section 4 (and others, including section 7): AF for transport. I understand there is a rule to prefer SCTP over TCP when both transports are available. This seems OK. Various sections refer to the support for multiple address families (IPv4, IPv6) and I understand that the PORT information for an AF does need not to be carried over a transport connection using the same AF. What I do not yet understand is how PORT knows whether to use an IPv4 transport for IPv6 or to use an IPv6 transport for IPv6. I'd like this to be clear, so that I can understand what happens when TCP is available over Ipv4 and SCTP only over IPv6 and similar combinations. Section 4.2: TCP keep-alive. SCTP heartbeat is described. I understand PORT also includes an optional keep-alive mechanism using the transport service. TCP also contains an optional keep-alive mechanism. This should be mentioned. Is TCP keep-alive recommended for PORT or does the protocol recommend a keep-alive at the PORT layer? Section 4.2: TCP Reset The present text says that the TCP connection will be reset after a few reties. This does not seem clear. A lack of acknowledgement for a sent data segment will result in the underlying TCP tansport retransmitting after the Retransmission Time Out (RTO). Furthermore this would cause the RTO to be doubled with each retransmission, until the RTO exceeds the maximum value when the connection will be reset, this is typically many 10s of seconds later. Section 5: Unexpected corruption of the stream It is good to see the service using the transport, in this case PORT verifies the integrity of the transported data. The recommendation seems to be that PORT skips any unknown data. While this may be good for interoperability between different flavours of the protocol, it is not good in terms of robustness, which could be an issue for long-lived connections. I suggest that if such errors occur they should be made visible, so that operators are aware that there are either PORT protocol issues or transport issues. That way a high count of such errors would alert a possible underlying problem. Could a single error in the transport result in loss of farming? I suspect so. I think it should be considered whether it be wise to close the connection (and reopen a new transport connection) after a repeated number of such errors. Section 9: ? The opening para concludes: /This the case even when the connection is down./ - I can see this case needs to be mentioned, but I am not sure from this text what exactly I am to understand. Section 11.4 This section describes critical and non-critical options. I could not find guidance for IANA on how to now whether a new option should be classified as one or the other. --- There are two general observations about this usage of TCP, I leave it to the TSV ADs to decide if any of these topics should be discussed further: 1) As I understand the protocol, it is application-limited, in that it will not usually use the entire TCP congestion window, but rather sends occasional small messages under the control of PORT. It seems important that such use does not grow an unbounded cwnd and then emit large bursts of data into the path when the application produces bursts of data that exceed a few MSS. It may be wise to consider a TCP stack that includes rate-limiting or burst-limiting. RFC 3645 (EXP) may also help in this case. 2) Since PORT may generate one or two segments of data per
Re: Last Call: draft-ietf-pim-port-08.txt (A Reliable TransportMechanism for PIM) to Experimental RFC
The choice of service name for this transport seems unfortunate; having a port number registry with a service in it called 'port' may be witty but seems like a source of future confusion. I notice that IANA currently have a service name of 'pim-port' which seems a better idea and one that I think that this I-D should adopt. Tom Petch - Original Message - From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Cc: p...@ietf.org Sent: Monday, September 26, 2011 9:40 PM Subject: Last Call: draft-ietf-pim-port-08.txt (A Reliable TransportMechanism for PIM) to Experimental RFC The IESG has received a request from the Protocol Independent Multicast WG (pim) to consider the following document: - 'A Reliable Transport Mechanism for PIM' draft-ietf-pim-port-08.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing. The reliable transport mechanism can use either TCP or SCTP as the transport protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pim-port/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pim-port/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-pim-port-08.txt (A Reliable TransportMechanism for PIM) to Experimental RFC
Hi, all, The IANA considerations in this doc are in error and need updating as follows. I agree that PORT is a poor acronym choice, FWIW. Joe 11. IANA Considerations This specification makes use of a TCP port number and a SCTP port number for the use of PIM-Over-Reliable-Transport that has been allocated by IANA. It also makes use of IANA PIM Hello Options allocations that should be made permanent. The current IANA allocation is called pim-port, not PIM-Over-Reliable-Transport. The long name (description) is PIM over Reliable-Transport, but that's not the authoritative name of the service - also, IANA does assignments (as per RFC 6335); this section should read as follows. This specification makes use of a TCP port number and a SCTP port number for the use of pim-port service that has been assigned by IANA. It also makes use of IANA PIM Hello Options assignments that should be made permanent. 11.1. PORT Port Number IANA has assigned a port number that is used as a destination port for PORT TCP and SCTP transports. The assigned number is 8471. References to this document should be added to the Service Name and Transport Protocol Port Number Registry. This should read: IANA has already assigned a port number that is used as a destination port for pim-port TCP and SCTP transports. The assigned number is 8471. References to this document should be added to the Service Name and Transport Protocol Port Number Registry for pim-port. On 9/27/2011 1:46 AM, t.petch wrote: The choice of service name for this transport seems unfortunate; having a port number registry with a service in it called 'port' may be witty but seems like a source of future confusion. I notice that IANA currently have a service name of 'pim-port' which seems a better idea and one that I think that this I-D should adopt. Tom Petch - Original Message - From: The IESGiesg-secret...@ietf.org To: IETF-Announceietf-annou...@ietf.org Cc:p...@ietf.org Sent: Monday, September 26, 2011 9:40 PM Subject: Last Call:draft-ietf-pim-port-08.txt (A Reliable TransportMechanism for PIM) to Experimental RFC The IESG has received a request from the Protocol Independent Multicast WG (pim) to consider the following document: - 'A Reliable Transport Mechanism for PIM' draft-ietf-pim-port-08.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing. The reliable transport mechanism can use either TCP or SCTP as the transport protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pim-port/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pim-port/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-pim-port-08.txt (A Reliable Transport Mechanism for PIM) to Experimental RFC
The IESG has received a request from the Protocol Independent Multicast WG (pim) to consider the following document: - 'A Reliable Transport Mechanism for PIM' draft-ietf-pim-port-08.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-10-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing. The reliable transport mechanism can use either TCP or SCTP as the transport protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pim-port/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pim-port/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
BCP 165, RFC 6335 on Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry
A new Request for Comments is now available in online RFC libraries. BCP 165 RFC 6335 Title: Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry Author: M. Cotton, L. Eggert, J. Touch, M. Westerlund, S. Cheshire Status: Best Current Practice Stream: IETF Date: August 2011 Mailbox:michelle.cot...@icann.org, lars.egg...@nokia.com, to...@isi.edu, magnus.westerl...@ericsson.com, chesh...@apple.com Pages: 33 Characters: 79088 Updates:RFC2780, RFC2782, RFC3828, RFC4340, RFC4960, RFC5595 See Also: BCP0165 I-D Tag:draft-ietf-tsvwg-iana-ports-10.txt URL:http://www.rfc-editor.org/rfc/rfc6335.txt This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice. This document is a product of the Transport Area Working Group Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6346 on The Address plus Port (A+P) Approach to the IPv4 Address Shortage
A new Request for Comments is now available in online RFC libraries. RFC 6346 Title: The Address plus Port (A+P) Approach to the IPv4 Address Shortage Author: R. Bush, Ed. Status: Experimental Stream: IETF Date: August 2011 Mailbox:ra...@psg.com Pages: 38 Characters: 89553 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ymbk-aplusp-10.txt URL:http://www.rfc-editor.org/rfc/rfc6346.txt We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4 world without assigning a unique globally routable IPv4 address to each of them is a challenging problem. This document proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional endpoint identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., Customer Premises Equipment (CPE), mobile phones), each with its assigned port range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process -- not some smart boxes in the core. This document defines an Experimental Protocol for the Internet community. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Additional registries converted to XML and announcement of new registry for Service Names and Port Numbers
On 7/23/2011 3:13 AM, Mykyta Yevstifeyev wrote: Hello, The new registry says: System Ports are assigned by IETF process for standards-track protocols, as per [RFC1340]. User Ports are assigned by IANA using the Expert Review process, as per [RFC5226]. Dynamic Ports are not assigned. I don't understand referencing RFC 1340 here. 1340 defines system vs. user ports. You're right; it should refer to RFC 5226 there instead. You could better change this to System Ports are assigned per Standards Action or IESG Approval process, as per [RFC5226]. That's OK. IESG Approval is assumed by the RFC-to-be, Section 8.1: o Reserved numbers and names are generally only assigned by a Standards Action or an IESG Approval, The above text isn't needed. Also, the new registry doesn't seem to match the following rule: The new assignment procedure conserves resources by assigning a port number to an application for only those transport protocols (TCP, UDP, SCTP and/or DCCP) it actually uses. The port number will be marked as Reserved - instead of Assigned - in the port number registries of the other transport protocols. Such entries as: tcpmux 1 tcpTCP Port Service Multiplexer [Mark_Lottor] [Mark_Lottor] tcpmux 1 udpTCP Port Service Multiplexer [Mark_Lottor] [Mark_Lottor] should be: tcpmux 1 tcpTCP Port Service Multiplexer [Mark_Lottor] [Mark_Lottor] tcpmux 1 udpTCP Port Service Multiplexer [Mark_Lottor] [Mark_Lottor] 1sctpReserved 1dccpReserved Yes. This is already the case for TCP/UDP entries, but we should be consistent with sctp and dccp. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Additional registries converted to XML and announcement of new registry for Service Names and Port Numbers
Hello, The new registry says: System Ports are assigned by IETF process for standards-track protocols, as per [RFC1340]. User Ports are assigned by IANA using the Expert Review process, as per [RFC5226]. Dynamic Ports are not assigned. I don't understand referencing RFC 1340 here. You could better change this to System Ports are assigned per Standards Action or IESG Approval process, as per [RFC5226]. IESG Approval is assumed by the RFC-to-be, Section 8.1: o Reserved numbers and names are generally only assigned by a Standards Action or an IESG Approval, Also, the new registry doesn't seem to match the following rule: The new assignment procedure conserves resources by assigning a port number to an application for only those transport protocols (TCP, UDP, SCTP and/or DCCP) it actually uses. The port number will be marked as Reserved - instead of Assigned - in the port number registries of the other transport protocols. Such entries as: tcpmux 1 tcpTCP Port Service Multiplexer [Mark_Lottor] [Mark_Lottor] tcpmux 1 udpTCP Port Service Multiplexer [Mark_Lottor] [Mark_Lottor] should be: tcpmux 1 tcpTCP Port Service Multiplexer [Mark_Lottor] [Mark_Lottor] tcpmux 1 udpTCP Port Service Multiplexer [Mark_Lottor] [Mark_Lottor] 1sctpReserved 1dccpReserved etc. Mykyta Yevstifeyev 22.07.2011 6:26, Michelle Cotton wrote: Attention: We recently combined and converted the Service Names and Port Numbers registry in accordance with a recently approved document to become an RFC. The legacy registries will be maintained for 2 more weeks so that anyone running scripts or gathering information can adjust/update what they need to. Legacy URLs: http://www.iana.org/assignments/service-names/service-names.xml http://www.iana.org/assignments/port-numbers NEW URL: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml We are aware that the new registry is very slow to load in some browsers and we are working on resolving the speed issue. If you have any questions, please do not hesitate to contact me. Thank you, Michelle Cotton ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fwd: Additional registries converted to XML and announcement of new registry for Service Names and Port Numbers
Begin forwarded message: From: Michelle Cotton michelle.cot...@icann.org Date: July 21, 2011 11:26:24 PM EDT To: i...@ietf.org i...@ietf.org Subject: Additional registries converted to XML and announcement of new registry for Service Names and Port Numbers IETF Community: This is a message for your information. Last year we archived some legacy text files and notified the IETF community which ones those were. This is follow-up message with a new set of registries that have been both converted and archived. A total of 78% of the registries we maintain have been converted to xml. We will repeat this step again in January 2012 with the registries that we convert between July 21, 2011 and December 31, 2011. Attention: We recently combined and converted the Service Names and Port Numbers registry in accordance with a recently approved document to become an RFC. The legacy registries will be maintained for 2 more weeks so that anyone running scripts or gathering information can adjust/update what they need to. Legacy URLs: http://www.iana.org/assignments/service-names/service-names.xml http://www.iana.org/assignments/port-numbers NEW URL: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml We are aware that the new registry is very slow to load in some browsers and we are working on resolving the speed issue. If you have any questions, please do not hesitate to contact me. Thank you, Michelle Cotton Manager, IETF Relations - IANA ICANN List of Registries that have been converted to XML between June 30, 2010 and July 20, 2011: http://www.iana.org/assignments/bgp-data-collection-communities-std http://www.iana.org/assignments/channel-binding-types/ http://www.iana.org/assignments/enum-services http://www.iana.org/assignments/eapsimaka-numbers http://www.iana.org/assignments/eappotp-identifiers http://www.iana.org/assignments/http-parameters http://www.iana.org/assignments/inst-man-values http://www.iana.org/assignments/integ-serv http://www.iana.org/assignments/icmp-parameters http://www.iana.org/assignments/ikev2-parameters http://www.iana.org/assignments/ipp-registrations http://www.iana.org/assignments/ipv6-address-space http://www.iana.org/assignments/ipv6-anycast-addresses http://www.iana.org/assignments/iana-ipv6-special-registry http://www.iana.org/assignments/ipv6-unicast-address-assignments http://www.iana.org/assignments/ipv6-parameters http://www.iana.org/assignments/ipv6-tla-assignments http://www.iana.org/assignments/isns-parameters http://www.iana.org/assignments/idxp-options http://www.iana.org/assignments/isis-tlv-codepoints http://www.iana.org/assignments/language-tags http://www.iana.org/assignments/lmp-parameters http://www.iana.org/assignments/mtqp-options http://www.iana.org/assignments/milnet-parameters http://www.iana.org/assignments/mpls-id-type http://www.iana.org/assignments/text-directory-registrations http://www.iana.org/assignments/pppoe-parameters http://www.iana.org/assignments/port-numbers http://www.iana.org/assignments/pwe3-parameters http://www.iana.org/assignments/public-data-network-numbers http://www.iana.org/assignments/rmt-fec-parameters http://www.iana.org/assignments/rsvp-parameters http://www.iana.org/assignments/ssh-parameters http://www.iana.org/assignments/svrloc-cryptographic-bsd http://www.iana.org/assignments/svrloc-error-numbers http://www.iana.org/assignments/service-names http://www.iana.org/assignments/sip-table http://www.iana.org/assignments/sip-priv-values http://www.iana.org/assignments/sieve-extensions http://www.iana.org/assignments/sieve-environment-items http://www.iana.org/assignments/sasl-mechanisms http://www.iana.org/assignments/smtp-enhanced-status-codes http://www.iana.org/assignments/snmp-number-spaces http://www.iana.org/assignments/sun-rpc-numbers http://www.iana.org/assignments/tcp-header-flags http://www.iana.org/assignments/sdp-security-descriptions ___ Ietf mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Additional registries converted to XML and announcement of new registry for Service Names and Port Numbers
IETF Community: This is a message for your information. Last year we archived some legacy text files and notified the IETF community which ones those were. This is follow-up message with a new set of registries that have been both converted and archived. A total of 78% of the registries we maintain have been converted to xml. We will repeat this step again in January 2012 with the registries that we convert between July 21, 2011 and December 31, 2011. Attention: We recently combined and converted the Service Names and Port Numbers registry in accordance with a recently approved document to become an RFC. The legacy registries will be maintained for 2 more weeks so that anyone running scripts or gathering information can adjust/update what they need to. Legacy URLs: http://www.iana.org/assignments/service-names/service-names.xml http://www.iana.org/assignments/port-numbers NEW URL: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml We are aware that the new registry is very slow to load in some browsers and we are working on resolving the speed issue. If you have any questions, please do not hesitate to contact me. Thank you, Michelle Cotton Manager, IETF Relations - IANA ICANN List of Registries that have been converted to XML between June 30, 2010 and July 20, 2011: http://www.iana.org/assignments/bgp-data-collection-communities-std http://www.iana.org/assignments/channel-binding-types/ http://www.iana.org/assignments/enum-services http://www.iana.org/assignments/eapsimaka-numbers http://www.iana.org/assignments/eappotp-identifiers http://www.iana.org/assignments/http-parameters http://www.iana.org/assignments/inst-man-values http://www.iana.org/assignments/integ-serv http://www.iana.org/assignments/icmp-parameters http://www.iana.org/assignments/ikev2-parameters http://www.iana.org/assignments/ipp-registrations http://www.iana.org/assignments/ipv6-address-space http://www.iana.org/assignments/ipv6-anycast-addresses http://www.iana.org/assignments/iana-ipv6-special-registry http://www.iana.org/assignments/ipv6-unicast-address-assignments http://www.iana.org/assignments/ipv6-parameters http://www.iana.org/assignments/ipv6-tla-assignments http://www.iana.org/assignments/isns-parameters http://www.iana.org/assignments/idxp-options http://www.iana.org/assignments/isis-tlv-codepoints http://www.iana.org/assignments/language-tags http://www.iana.org/assignments/lmp-parameters http://www.iana.org/assignments/mtqp-options http://www.iana.org/assignments/milnet-parameters http://www.iana.org/assignments/mpls-id-type http://www.iana.org/assignments/text-directory-registrations http://www.iana.org/assignments/pppoe-parameters http://www.iana.org/assignments/port-numbers http://www.iana.org/assignments/pwe3-parameters http://www.iana.org/assignments/public-data-network-numbers http://www.iana.org/assignments/rmt-fec-parameters http://www.iana.org/assignments/rsvp-parameters http://www.iana.org/assignments/ssh-parameters http://www.iana.org/assignments/svrloc-cryptographic-bsd http://www.iana.org/assignments/svrloc-error-numbers http://www.iana.org/assignments/service-names http://www.iana.org/assignments/sip-table http://www.iana.org/assignments/sip-priv-values http://www.iana.org/assignments/sieve-extensions http://www.iana.org/assignments/sieve-environment-items http://www.iana.org/assignments/sasl-mechanisms http://www.iana.org/assignments/smtp-enhanced-status-codes http://www.iana.org/assignments/snmp-number-spaces http://www.iana.org/assignments/sun-rpc-numbers http://www.iana.org/assignments/tcp-header-flags http://www.iana.org/assignments/sdp-security-descriptions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RFC 6284 on Port Mapping between Unicast and Multicast RTP Sessions
A new Request for Comments is now available in online RFC libraries. RFC 6284 Title: Port Mapping between Unicast and Multicast RTP Sessions Author: A. Begen, D. Wing, T. Van Caenegem Status: Standards Track Stream: IETF Date: June 2011 Mailbox:abe...@cisco.com, dw...@cisco.com, tom.van_caene...@alcatel-lucent.com Pages: 30 Characters: 73289 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02.txt URL:http://www.rfc-editor.org/rfc/rfc6284.txt This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Core Maintenance Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Port Mapping Between Unicast and Multicast RTP Sessions' to Proposed Standard (draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02.txt)
The IESG has approved the following document: - 'Port Mapping Between Unicast and Multicast RTP Sessions' (draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtcore-ports-for-ucast-mcast-rtp/ Technical Summary This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. Working Group Summary This document was discussed heavily in the AVT working group before moving to AVTCORE. There was a discussion if to use a token or cookie for the solution. The initial solution was based on a cookie but after a technical discussion in IETF78 and mailing list call for consensus the token based solution was selected. There was a consensus to use this approach. Document Quality This document received a high level of working group review over two last calls. Detailed reviews were received from several working group participants. Magnus Westerlund and Colin Perkins provided particularly extensive review comments. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
+1 /Markku On Mon, 28 Mar 2011, Michelle Cotton wrote: +1 Michelle On 3/28/11 5:46 AM, Lars Eggert lars.egg...@nokia.com wrote: As one of the authors/editors, I am fine with this change. Thanks! On 2011-3-28, at 14:14, Alexey Melnikov wrote: After discussing this new text with IESG and some participants of the TSVWG, it became clear that while there is clear agreement for adding the first sentence quoted above (There is no IETF consensus...), there is no clear cut consensus for adding the second sentence (Therefore, an expert reviewer should not reject a proposal). After even further discussions with proponents of this text, with editors, IANA, etc., the proposal is to strike the second sentence, i.e. only the following sentence is going to be added to the document: There is no IETF consensus on when it is appropriate to use a second port for an insecure version of protocol. The IESG is already alerted when there are problems with IANA registrations, so the requirement being removed is not needed. If people have problems with this change, please send your objections by 4pm Prague time on Wednesday, March 30th, as I would like to approve the document before my IESG term ends. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry' to BCP (draft-ietf-tsvwg-iana-ports-10.txt)
The IESG has approved the following document: - 'Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry' (draft-ietf-tsvwg-iana-ports-10.txt) as a BCP This document is the product of the Transport Area Working Group. The IESG contact persons are Alexey Melnikov and Lars Eggert. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ Technical Summary This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number Registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates IANA's procedures by obsoleting the previous procedures for TCP and UDP and updates procedures for other IETF transports. It also updates the DNS SRV specification Working Group Summary This document is a product of the TSVWG, and was reviewed in working group meetings and via the tsvwg list. Document Quality The document was reviewed by the WG, and reviewed by the group. In particular, Alfred Hoenes (a...@tr-sys.de) and Allison Mankin (man...@psg.com) contributed test, ideas and reviews. The document has also received an AD review, which has been posted to the WG. Personnel Gorry Fairhurst is the Document Shepherd for this document. Alexey Melnikov is the Responsible Area Director. RFC Editor Note Add to the end of Introduction a new paragraph: At the time of writing of this document the internal procedures of Expert Review teams, including that of IANA's port review team, are not documented in any RFC and this document doesn't change that. In Section 7.2, 1st paragraph, last sentence: OLD: These principles and general advice to users on port use are expected to change over time and are therefore documented separately, please see [I-D.touch-tsvwg-port-use]. NEW: These principles and general advice to users on port use are expected to change over time. In Section 7.2, 5th paragraph: OLD: o IANA strives to assign only one assigned port number per service or application NEW: o IANA strives to assign only one assigned port number per service or application Note: At the time of writing of this document there is no IETF consensus on when it is appropriate to use a second port for an insecure version of a protocol. In Section 7.2, 13th paragraphs: OLD: These principles of port conservation are explained further in [I-D.touch-tsvwg-port-use]. That document explains in further detail how ports are used in various ways, notably: NEW: Ports are used in various ways, notably: In Section 8.1.1, 13th paragraph, last sentence: OLD: Note that the applicant MUST NOT use the requested port prior to the completion of the assignment. NEW: Note that the applicant MUST NOT use the requested port in implementations deployed for use on the public Internet prior to the completion of the assignment, because there is no guaranty that IANA will assign the requested port. Please make the following reference Normative: [RFC4960] Stewart, R., Stream Control Transmission Protocol, RFC 4960, September 2007. Please delete the following Informative reference: [I-D.touch-tsvwg-port-use] ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
+1. On 3/28/11 3:52 PM, Michelle Cotton wrote: +1 Michelle On 3/28/11 5:46 AM, Lars Eggert lars.egg...@nokia.com wrote: As one of the authors/editors, I am fine with this change. Thanks! On 2011-3-28, at 14:14, Alexey Melnikov wrote: After discussing this new text with IESG and some participants of the TSVWG, it became clear that while there is clear agreement for adding the first sentence quoted above (There is no IETF consensus...), there is no clear cut consensus for adding the second sentence (Therefore, an expert reviewer should not reject a proposal). After even further discussions with proponents of this text, with editors, IANA, etc., the proposal is to strike the second sentence, i.e. only the following sentence is going to be added to the document: There is no IETF consensus on when it is appropriate to use a second port for an insecure version of protocol. The IESG is already alerted when there are problems with IANA registrations, so the requirement being removed is not needed. If people have problems with this change, please send your objections by 4pm Prague time on Wednesday, March 30th, as I would like to approve the document before my IESG term ends. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
Alexey Melnikov wrote: Peter Saint-Andre wrote: Agreed, thanks to Paul for the proposed text. On 2/15/11 9:02 PM, Cullen Jennings wrote: Paul's text is much better than mine. That was what I trying to get at. Agreed, I will add this as an RFC Editor's note. On Feb 15, 2011, at 8:59 PM, Paul Hoffman wrote: On 2/15/11 7:34 PM, Cullen Jennings wrote: I propose some text for the draft near the bottom of this email For the user ports the document should have some text along the lines of: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol therefor the export reviewer should not reject a request for a second port to run a secure variant of the protocol over. That feels close, but too prescriptive. Also, the requests are usually for a protocol with two ports, not a later request for a second port. How about: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol. Therefore, an expert reviewer should not reject a proposal for a protocol that uses a second part to run a secure variant for the sole reason that it is using two ports. After discussing this new text with IESG and some participants of the TSVWG, it became clear that while there is clear agreement for adding the first sentence quoted above (There is no IETF consensus...), there is no clear cut consensus for adding the second sentence (Therefore, an expert reviewer should not reject a proposal). After even further discussions with proponents of this text, with editors, IANA, etc., the proposal is to strike the second sentence, i.e. only the following sentence is going to be added to the document: There is no IETF consensus on when it is appropriate to use a second port for an insecure version of protocol. The IESG is already alerted when there are problems with IANA registrations, so the requirement being removed is not needed. If people have problems with this change, please send your objections by 4pm Prague time on Wednesday, March 30th, as I would like to approve the document before my IESG term ends. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
On 3/28/11 2:14 PM, Alexey Melnikov wrote: Alexey Melnikov wrote: Peter Saint-Andre wrote: Agreed, thanks to Paul for the proposed text. On 2/15/11 9:02 PM, Cullen Jennings wrote: Paul's text is much better than mine. That was what I trying to get at. Agreed, I will add this as an RFC Editor's note. On Feb 15, 2011, at 8:59 PM, Paul Hoffman wrote: On 2/15/11 7:34 PM, Cullen Jennings wrote: I propose some text for the draft near the bottom of this email For the user ports the document should have some text along the lines of: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol therefor the export reviewer should not reject a request for a second port to run a secure variant of the protocol over. That feels close, but too prescriptive. Also, the requests are usually for a protocol with two ports, not a later request for a second port. How about: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol. Therefore, an expert reviewer should not reject a proposal for a protocol that uses a second part to run a secure variant for the sole reason that it is using two ports. After discussing this new text with IESG and some participants of the TSVWG, it became clear that while there is clear agreement for adding the first sentence quoted above (There is no IETF consensus...), there is no clear cut consensus for adding the second sentence (Therefore, an expert reviewer should not reject a proposal). After even further discussions with proponents of this text, with editors, IANA, etc., the proposal is to strike the second sentence, i.e. only the following sentence is going to be added to the document: There is no IETF consensus on when it is appropriate to use a second port for an insecure version of protocol. The IESG is already alerted when there are problems with IANA registrations, so the requirement being removed is not needed. If people have problems with this change, please send your objections by 4pm Prague time on Wednesday, March 30th, as I would like to approve the document before my IESG term ends. As someone who was involved in formulating the two-sentence text and who raised concerns about removing the second sentence within the IESG, I'd like to publicly affirm that I find this resolution acceptable. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
As one of the authors/editors, I am fine with this change. Thanks! On 2011-3-28, at 14:14, Alexey Melnikov wrote: After discussing this new text with IESG and some participants of the TSVWG, it became clear that while there is clear agreement for adding the first sentence quoted above (There is no IETF consensus...), there is no clear cut consensus for adding the second sentence (Therefore, an expert reviewer should not reject a proposal). After even further discussions with proponents of this text, with editors, IANA, etc., the proposal is to strike the second sentence, i.e. only the following sentence is going to be added to the document: There is no IETF consensus on when it is appropriate to use a second port for an insecure version of protocol. The IESG is already alerted when there are problems with IANA registrations, so the requirement being removed is not needed. If people have problems with this change, please send your objections by 4pm Prague time on Wednesday, March 30th, as I would like to approve the document before my IESG term ends. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
As one of the authors, I'm fine with this change too. Joe On 3/28/2011 5:46 AM, Lars Eggert wrote: As one of the authors/editors, I am fine with this change. Thanks! On 2011-3-28, at 14:14, Alexey Melnikov wrote: After discussing this new text with IESG and some participants of the TSVWG, it became clear that while there is clear agreement for adding the first sentence quoted above (There is no IETF consensus...), there is no clear cut consensus for adding the second sentence (Therefore, an expert reviewer should not reject a proposal). After even further discussions with proponents of this text, with editors, IANA, etc., the proposal is to strike the second sentence, i.e. only the following sentence is going to be added to the document: There is no IETF consensus on when it is appropriate to use a second port for an insecure version of protocol. The IESG is already alerted when there are problems with IANA registrations, so the requirement being removed is not needed. If people have problems with this change, please send your objections by 4pm Prague time on Wednesday, March 30th, as I would like to approve the document before my IESG term ends. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
Joe Touch skrev 2011-03-28 15:33: As one of the authors, I'm fine with this change too. Me too, Magnus Westerlund ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
+1 Michelle On 3/28/11 5:46 AM, Lars Eggert lars.egg...@nokia.com wrote: As one of the authors/editors, I am fine with this change. Thanks! On 2011-3-28, at 14:14, Alexey Melnikov wrote: After discussing this new text with IESG and some participants of the TSVWG, it became clear that while there is clear agreement for adding the first sentence quoted above (There is no IETF consensus...), there is no clear cut consensus for adding the second sentence (Therefore, an expert reviewer should not reject a proposal). After even further discussions with proponents of this text, with editors, IANA, etc., the proposal is to strike the second sentence, i.e. only the following sentence is going to be added to the document: There is no IETF consensus on when it is appropriate to use a second port for an insecure version of protocol. The IESG is already alerted when there are problems with IANA registrations, so the requirement being removed is not needed. If people have problems with this change, please send your objections by 4pm Prague time on Wednesday, March 30th, as I would like to approve the document before my IESG term ends. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00.txt (Port Mapping Between Unicast and Multicast RTP Sessions) to Proposed Standard
The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'Port Mapping Between Unicast and Multicast RTP Sessions' draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-03-08. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avtcore-ports-for-ucast-mcast-rtp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avtcore-ports-for-ucast-mcast-rtp/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
Peter Saint-Andre wrote: Agreed, thanks to Paul for the proposed text. On 2/15/11 9:02 PM, Cullen Jennings wrote: Paul's text is much better than mine. That was what I trying to get at. Agreed, I will add this as an RFC Editor's note. On Feb 15, 2011, at 8:59 PM, Paul Hoffman wrote: On 2/15/11 7:34 PM, Cullen Jennings wrote: I propose some text for the draft near the bottom of this email For the user ports the document should have some text along the lines of: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol therefor the export reviewer should not reject a request for a second port to run a secure variant of the protocol over. That feels close, but too prescriptive. Also, the requests are usually for a protocol with two ports, not a later request for a second port. How about: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol. Therefore, an expert reviewer should not reject a proposal for a protocol that uses a second part to run a secure variant for the sole reason that it is using two ports. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
Cullen, there's a lot of history with port registrations. As you're probably aware in the past, there was a procedure for experts to sign an NDA before reviewing port requests. It's my understanding that is no longer done. However, it does suggest there's strong desire for proprietary protocol support. So, there's lots of complexity specific to this registry here that I don't know about. However, the general idea of having experts reviews on a public list, or even soliciting comments on a public list is well supported. There's specific discussion of this in RFC 5226. We've done it successfully in a number of cases. So, there's reason to believe that things in this space could be effective for IANA registries. I think soliciting public comments on port requests would be bad; I think your proposal of having the request/response be published would be as far as we should go for this registry at this time. So, I don't have the background to say this would be a good fit for the port registry, but to the extent that my background supports something like this I can support your idea. It's worked elsewhere at lesat. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (InternetAssigned Numbers Authority (IANA) Procedures for the Managementof the Service Name and Transport Protocol Port NumberRegistry) to BCP
Original Message - From: Cullen Jennings flu...@cisco.com To: Christian Huitema huit...@microsoft.com Cc: ts...@ietf.org; Paul Hoffman paul.hoff...@vpnc.org; Chris Benson cben...@adax.com; IESG IESG i...@ietf.org; Sam Hartman hartmans-i...@mit.edu; IETF discussion list ietf@ietf.org Sent: Wednesday, February 16, 2011 5:31 AM I've been thinking more about this thread and my concerns about this draft. I was originally looking for the draft to have advice for the expert review team that gave them guidance on what the IETF thought was all right to approve or not approve. It's become clear that this draft does not have that advice and is not likely to get it in the very short term. This BCP will empower the expert reviewer to reject or approve just about any request. Appeals are not the best way to balance putting that power because they are incredibly corrosive and time consuming to everyone involved. I think this thread somewhat suggests an alternative approach for a check and balance. Cullen My understanding of this draft is that Expert Review only applies when IETF Review or IESG Approval does not apply, so a duly approved Standards Track RFC trumps all Experts. I proposed text on 2nd February to make this clearer, and understand that this change was accepted. Where the request is not via IETF Review or IESG Approval, then I have less concern as to what the Expert may or may not allow. My text is For most IETF protocols, ports in the User Ports range will be assigned under the IETF Review or IESG Approval procedures [RFC5226] and no further documentation is required. Where these procedures do not apply, then the requester must input the documentation to the Expert Review procedure [RFC5226], by which IANA will have a technical expert review the request to determine whether to grant the assignment. The submitted documentation MUST explain why using a port number in the Dynamic Ports range is unsuitable for the given application. Tom Petch What do people think of the idea of: for all ports requests, the request and the expert reviewer reposes including reason for accepting or rejecting them need to be posted to a public email list. This seems like a simple way to help mitigate this issue and it will help educate people writing a port request to know what types of issues they need to address and what would be appropriate or not. Pros cons of this idea? On Feb 8, 2011, at 1:41 PM, Christian Huitema wrote: I don't see that public identity (of expert reviewers) is required for interactive discussion. Or would anonymous interaction fail a Turing test of some kind? Public identity is required for reviewer accountability. It is easy to imagine how withholding registration of some required numbers may delay a competitor's products. The best protection against shade is sunlight. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
I propose some text for the draft near the bottom of this email On Feb 2, 2011, at 2:16 AM, Magnus Westerlund wrote: Cullen Jennings skrev 2011-02-01 18:19: So to summarize what you are saying, ports are allocated based on an arbitrary view of the expert review. When this person will say yes or no too can't be described and will change over time. If that's how it works, there is not even any grounds for appeal of any given decision. You can't even use precedence as an argument. My view was the IESG has been trying to move to having much more concrete advice for registries that required expert review. If you agree that is about the right summary, then I'm pretty sure I can find plenty of other people that would agree with me that this is not OK. I'm not a fan of the WG could not get consensus on if we should allow A or not so we are just going to let the expert review do whatever they want. If the IETF could not come to consensus on if X or Y were reasons to deny a registration, then I don't think the expert review should be able to deny a registration due to X or Y. Cullen, Apparently you like to twist what I am saying in most negative way and without considering the checks that are in place. Sorry Magnus ... I really did not mean to twist your words. I know you are very straight up about this type of stuff. I suggested some text bellow. - I think general guidelines can and should be developed. But other than high level goals this isn't the document. Here Joe has the start of a document. But I do think that in long term this guidance may change. - There is an appeal process where the IESG and then IAB gets to sanity check the arguments that the reviewer + IANA has given towards the appealing requestor. I understand that but we both know appeals are a painful tool to use and we would like to avoid it where possible - they waste an incredible amount of time for everyone involved and particularly the IESG. - One can take a assignment request through the IETF process I'm not as focused on drafts in IETF process but even in theses cases, WGs will look to this BCP for guidance on what would be acceptable behavior. So even if this draft might not legally block a WG from doing something, the WG will still be influenced by the goals this draft strives for. That is a good thing - BCP advice that applies to non IETF work should guide IETF process work too. I hope that we can get consensus on the guidelines, because I think that would give the reviewers a lot of comfort being able to rely on that consensus. Cullen, what are your suggestion for how to improve the document? For the user ports the document should have some text along the lines of: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol therefor the export reviewer should not reject a request for a second port to run a secure variant of the protocol over. The reason I think this needs to be in the draft is very simple. In my mind there are clear and compelling cases for two ports - many of them involving DTLS and real time protocols that actually care about number of round trips. Joe Touch has already said he would reject an example use case that I think should be accepted. I think this is much easier to resolve this issue now than with an appeal. The CORE WG, which I co-chair, needs clear advice now on what direction would be acceptable and is not particular interested in waiting for a year or two for the drafts to be done, appealed, and then redesigned. Cheers Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
