From rfc-editor at rfc-editor.org Wed Jan 10 14:07:34 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Wed, 10 Jan 2007 14:07:34 -0800 Subject: [rfc-dist] RFC 4770 on vCard Extensions for Instant Messaging (IM) Message-ID: <200701102207.l0AM7YSk032017@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4770 Title: vCard Extensions for Instant Messaging (IM) Author: C. Jennings, J. Reschke, Ed. Status: Standards Track Date: January 2007 Mailbox: fluffy at cisco.com, julian.reschke at greenbytes.de Pages: 7 Characters: 11077 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-jennings-impp-vcard-08.txt URL: http://www.rfc-editor.org/rfc/rfc4770.txt This document describes an extension to vCard to support Instant Messaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming increasingly common ways of communicating, and users want to save this contact information in their address books. It allows a URI that is associated with IM or PP to be specified inside a vCard. [STANDARDS TRACK] 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Wed Jan 10 14:11:58 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Wed, 10 Jan 2007 14:11:58 -0800 Subject: [rfc-dist] RFC 4788 on Enhancements to RTP Payload Formats for EVRC Family Codecs Message-ID: <200701102211.l0AMBwVG032029@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4788 Title: Enhancements to RTP Payload Formats for EVRC Family Codecs Author: Q. Xie, R. Kapoor Status: Standards Track Date: January 2007 Mailbox: Qiaobing.Xie at Motorola.com, rkapoor at qualcomm.com Pages: 22 Characters: 42216 Updates: RFC3558 See-Also: I-D Tag: draft-ietf-avt-compact-bundled-evrc-11.txt URL: http://www.rfc-editor.org/rfc/rfc4788.txt This document updates the Enhanced Variable Rate Codec (EVRC) RTP payload formats defined in RFC 3558 with several enhancements and extensions. In particular, it defines support for the header-free and interleaved/bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B-encoded speech transported via RTP. Voice over IP (VoIP) applications operating over low bandwidth dial-up and wireless networks require such enhancements for efficient use of the bandwidth. [STANDARDS TRACK] This document is a product of the Audio/Video Transport 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Tue Jan 16 16:49:29 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Tue, 16 Jan 2007 16:49:29 -0800 Subject: [rfc-dist] RFC 4760 on Multiprotocol Extensions for BGP-4 Message-ID: <200701170049.l0H0nTX4017782@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4760 Title: Multiprotocol Extensions for BGP-4 Author: T. Bates, R. Chandra, D. Katz, Y. Rekhter Status: Standards Track Date: January 2007 Mailbox: tbates at cisco.com, rchandra at sonoasystems.com, dkatz at juniper.com, yakov at juniper.com, Pages: 12 Characters: 24542 Obsoletes: RFC2858 See-Also: I-D Tag: draft-ietf-idr-rfc2858bis-10.txt URL: http://www.rfc-editor.org/rfc/rfc4760.txt This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS TRACK] This document is a product of the Inter-Domain Routing Working Group of the IETF. This is now a Draft 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Tue Jan 16 16:49:35 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Tue, 16 Jan 2007 16:49:35 -0800 Subject: [rfc-dist] RFC 4761 on Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling Message-ID: <200701170049.l0H0nZOI017787@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4761 Title: Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling Author: K. Kompella, Ed., Y. Rekhter, Ed. Status: Standards Track Date: January 2007 Mailbox: kireeti at juniper.net, yakov at juniper.net Pages: 28 Characters: 65219 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l2vpn-vpls-bgp-08.txt URL: http://www.rfc-editor.org/rfc/rfc4761.txt Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature. This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network. [STANDARDS TRACK] This document is a product of the Layer 2 Virtual Private Networks 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Tue Jan 16 16:49:40 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Tue, 16 Jan 2007 16:49:40 -0800 Subject: [rfc-dist] RFC 4724 on Graceful Restart Mechanism for BGP Message-ID: <200701170049.l0H0neA3017792@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4724 Title: Graceful Restart Mechanism for BGP Author: S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter Status: Standards Track Date: January 2007 Mailbox: rsrihari at cisco.com, enkechen at cisco.com, rex at juniper.net, jgs at juniper.net, yakov at juniper.net Pages: 15 Characters: 32343 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-idr-restart-13.txt URL: http://www.rfc-editor.org/rfc/rfc4724.txt This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined that would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment. The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). [STANDARDS TRACK] This document is a product of the Inter-Domain Routing 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Tue Jan 16 16:49:44 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Tue, 16 Jan 2007 16:49:44 -0800 Subject: [rfc-dist] RFC 4762 on Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling Message-ID: <200701170049.l0H0niWn017797@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4762 Title: Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling Author: M. Lasserre, Ed., V. Kompella, Ed. Status: Standards Track Date: January 2007 Mailbox: mlasserre at alcatel-lucent.com, vach.kompella at alcatel-lucent.com Pages: 31 Characters: 82778 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l2vpn-vpls-ldp-09.txt URL: http://www.rfc-editor.org/rfc/rfc4762.txt This document describes a Virtual Private LAN Service (VPLS) solution using pseudowires, a service previously implemented over other tunneling technologies and known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users; i.e., it creates a Layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses and that is closed to a given set of users. Multiple VPLS services can be supported from a single Provider Edge (PE) node. This document describes the control plane functions of signaling pseudowire labels using Label Distribution Protocol (LDP), extending RFC 4447. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing in particular on the learning of MAC addresses. The encapsulation of VPLS packets is described by RFC 4448. [STANDARDS TRACK] This document is a product of the Layer 2 Virtual Private Networks 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Thu Jan 18 10:43:15 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Thu, 18 Jan 2007 10:43:15 -0800 Subject: [rfc-dist] RFC 4753 on ECP Groups For IKE and IKEv2 Message-ID: <200701181843.l0IIhFqK027789@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4753 Title: ECP Groups For IKE and IKEv2 Author: D. Fu, J. Solinas Status: Informational Date: January 2007 Mailbox: defu at orion.ncsc.mil, jasolin at orion.ncsc.mil Pages: 16 Characters: 28760 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsec-ike-ecp-groups-03.txt URL: http://www.rfc-editor.org/rfc/rfc4753.txt This document describes new Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups. Specifically, the new curve groups are based on modular arithmetic rather than binary arithmetic. These new groups are defined to align IKE and IKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. This memo provides information for the Internet community. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Thu Jan 18 10:43:05 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Thu, 18 Jan 2007 10:43:05 -0800 Subject: [rfc-dist] RFC 4764 on The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method Message-ID: <200701181843.l0IIh57T027779@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4764 Title: The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method Author: F. Bersani, H. Tschofenig Status: Experimental Date: January 2007 Mailbox: bersani_florent at yahoo.fr, Hannes.Tschofenig at siemens.com Pages: 64 Characters: 133990 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-bersani-eap-psk-11.txt URL: http://www.rfc-editor.org/rfc/rfc4764.txt This document specifies EAP-PSK, an Extensible Authentication Protocol (EAP) method for mutual authentication and session key derivation using a Pre-Shared Key (PSK). EAP-PSK provides a protected communication channel when mutual authentication is successful for both parties to communicate over. This document describes the use of this channel only for protected exchange of result indications, but future EAP-PSK extensions may use the channel for other purposes. EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11. This memo 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Thu Jan 18 10:43:19 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Thu, 18 Jan 2007 10:43:19 -0800 Subject: [rfc-dist] RFC 4754 on IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA) Message-ID: <200701181843.l0IIhJKW027794@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4754 Title: IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA) Author: D. Fu, J. Solinas Status: Standards Track Date: January 2007 Mailbox: defu at orion.ncsc.mil, jasolin at orion.ncsc.mil Pages: 15 Characters: 27948 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsec-ike-auth-ecdsa-06.txt URL: http://www.rfc-editor.org/rfc/rfc4754.txt This document describes how the Elliptic Curve Digital Signature Algorithm (ECDSA) may be used as the authentication method within the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols. ECDSA may provide benefits including computational efficiency, small signature sizes, and minimal bandwidth compared to other available digital signature methods. This document adds ECDSA capability to IKE and IKEv2 without introducing any changes to existing IKE operation. [STANDARDS TRACK] 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Thu Jan 18 10:43:10 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Thu, 18 Jan 2007 10:43:10 -0800 Subject: [rfc-dist] RFC 4781 on Graceful Restart Mechanism for BGP with MPLS Message-ID: <200701181843.l0IIhALN027784@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4781 Title: Graceful Restart Mechanism for BGP with MPLS Author: Y. Rekhter, R. Aggarwal Status: Standards Track Date: January 2007 Mailbox: yakov at juniper.net, rahul at juniper.net Pages: 10 Characters: 23249 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-bgp-mpls-restart-05.txt URL: http://www.rfc-editor.org/rfc/rfc4781.txt A mechanism for BGP that helps minimize the negative effects on routing caused by BGP restart has already been developed and is described in a separate document ("Graceful Restart Mechanism for BGP"). This document extends this mechanism to minimize the negative effects on MPLS forwarding caused by the Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its BGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart. The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network Layer Reachability Information (NLRI) field. As such, it works in conjunction with any of the address families that could be carried in BGP (e.g., IPv4, IPv6, etc.). [STANDARDS TRACK] This document is a product of the Multiprotocol Label Switching 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Thu Jan 18 10:43:24 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Thu, 18 Jan 2007 10:43:24 -0800 Subject: [rfc-dist] RFC 4771 on Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP) Message-ID: <200701181843.l0IIhO8Z027799@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4771 Title: Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP) Author: V. Lehtovirta, M. Naslund, K. Norrman Status: Standards Track Date: January 2007 Mailbox: vesa.lehtovirta at ericsson.com, mats.naslund at ericsson.com, karl.norrman at ericsson.com Pages: 12 Characters: 27945 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-lehtovirta-srtp-rcc-06.txt URL: http://www.rfc-editor.org/rfc/rfc4771.txt This document defines an integrity transform for Secure Real-time Transport Protocol (SRTP; see RFC 3711), which allows the roll-over counter (ROC) to be transmitted in SRTP packets as part of the authentication tag. The need for sending the ROC in SRTP packets arises in situations where the receiver joins an ongoing SRTP session and needs to quickly and robustly synchronize. The mechanism also enhances SRTP operation in cases where there is a risk of losing sender-receiver synchronization. [STANDARDS TRACK] 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Mon Jan 22 18:01:23 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Mon, 22 Jan 2007 18:01:23 -0800 Subject: [rfc-dist] RFC 4779 on ISP IPv6 Deployment Scenarios in Broadband Access Networks Message-ID: <200701230201.l0N21N2N006492@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4779 Title: ISP IPv6 Deployment Scenarios in Broadband Access Networks Author: S. Asadullah, A. Ahmed, C. Popoviciu, P. Savola, J. Palet Status: Informational Date: January 2007 Mailbox: sasad at cisco.com, adahmed at cisco.com, cpopovic at cisco.com, psavola at funet.fi, jordi.palet at consulintel.es Pages: 81 Characters: 188511 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-bb-deployment-scenarios-05.txt URL: http://www.rfc-editor.org/rfc/rfc4779.txt This document provides a detailed description of IPv6 deployment and integration methods and scenarios in today's Service Provider (SP) Broadband (BB) networks in coexistence with deployed IPv4 services. Cable/HFC, BB Ethernet, xDSL, and WLAN are the main BB technologies that are currently deployed, and discussed in this document. The emerging Broadband Power Line Communications (PLC/BPL) access technology is also discussed for completeness. In this document we will discuss main components of IPv6 BB networks, their differences from IPv4 BB networks, and how IPv6 is deployed and integrated in each of these networks using tunneling mechanisms and native IPv6. This memo provides information for the Internet community. This document is a product of the IPv6 Operations Working Group of the IETF. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Wed Jan 24 18:19:45 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Wed, 24 Jan 2007 18:19:45 -0800 Subject: [rfc-dist] RFC 4795 on Link-local Multicast Name Resolution (LLMNR) Message-ID: <200701250219.l0P2Jjti014442@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4795 Title: Link-local Multicast Name Resolution (LLMNR) Author: B. Aboba, D. Thaler, L. Esibov Status: Informational Date: January 2007 Mailbox: bernarda at microsoft.com, dthaler at microsoft.com, levone at microsoft.com Pages: 31 Characters: 71969 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dnsext-mdns-47.txt URL: http://www.rfc-editor.org/rfc/rfc4795.txt The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types, and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. This memo provides information for the Internet community. This document is a product of the DNS Extensions Working Group of the IETF. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Wed Jan 24 18:19:39 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Wed, 24 Jan 2007 18:19:39 -0800 Subject: [rfc-dist] RFC 4797 on Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks Message-ID: <200701250219.l0P2JdS2014437@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4797 Title: Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks Author: Y. Rekhter, R. Bonica, E. Rosen Status: Informational Date: January 2007 Mailbox: yakov at juniper.net, rbonica at juniper.net, erosen at cisco.com Pages: 10 Characters: 18985 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l3vpn-gre-ip-2547-05.txt URL: http://www.rfc-editor.org/rfc/rfc4797.txt This document describes an implementation strategy for BGP/MPLS IP Virtual Private Networks (VPNs) in which the outermost MPLS label (i.e., the tunnel label) is replaced with either an IP header or an IP header with Generic Routing Encapsulation (GRE). The implementation strategy described herein enables the deployment of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS and VPN aware, but whose interior devices are not. This memo provides information for the Internet community. This document is a product of the Layer 3 Virtual Private Networks Working Group of the IETF. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Wed Jan 24 18:19:54 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Wed, 24 Jan 2007 18:19:54 -0800 Subject: [rfc-dist] RFC 4792 on Encoding Instructions for the Generic String Encoding Rules (GSER) Message-ID: <200701250219.l0P2JsYX014447@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4792 Title: Encoding Instructions for the Generic String Encoding Rules (GSER) Author: S. Legg Status: Standards Track Date: January 2007 Mailbox: steven.legg at eb2bcom.com Pages: 9 Characters: 17637 Updates: RFC3641 See-Also: I-D Tag: draft-legg-ldap-gser-ei-02.txt URL: http://www.rfc-editor.org/rfc/rfc4792.txt Abstract Syntax Notation One (ASN.1) defines a general framework for annotating types in an ASN.1 specification with encoding instructions that alter how values of those types are encoded according to ASN.1 encoding rules. This document defines the supporting notation for encoding instructions that apply to the Generic String Encoding Rules (GSER) and, in particular, defines an encoding instruction to provide a machine-processable representation for the declaration of a GSER ChoiceOfStrings type. [STANDARDS TRACK] 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Mon Jan 29 16:48:40 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Mon, 29 Jan 2007 16:48:40 -0800 Subject: [rfc-dist] RFC 4782 on Quick-Start for TCP and IP Message-ID: <200701300048.l0U0mehx030714@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4782 Title: Quick-Start for TCP and IP Author: S. Floyd, M. Allman, A. Jain, P. Sarolahti Status: Experimental Date: January 2007 Mailbox: floyd at icir.org, mallman at icir.org, a.jain at f5.com, pasi.sarolahti at iki.fi Pages: 82 Characters: 214489 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tsvwg-quickstart-07.txt URL: http://www.rfc-editor.org/rfc/rfc4782.txt This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request. This document describes many paths where Quick-Start Requests would not be approved. These paths include all paths containing routers, IP tunnels, MPLS paths, and the like that do not support Quick- Start. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start Requests could be difficult to approve over paths that include multi-access layer- two networks. This document also describes environments where the Quick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. This memo defines an Experimental Protocol for the Internet community. This document is a product of the Transport Area Working Group Working Group of the IETF. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Wed Jan 31 18:17:25 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Wed, 31 Jan 2007 18:17:25 -0800 Subject: [rfc-dist] RFC 4778 on Operational Security Current Practices In Internet Service Provider Environments Message-ID: <200702010217.l112HPhG011846@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4778 Title: Operational Security Current Practices In Internet Service Provider Environments Author: M. Kaeo Status: Informational Date: January 2007 Mailbox: merike at doubleshotsecurity.com Pages: 37 Characters: 88344 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsec-current-practices-07.txt URL: http://www.rfc-editor.org/rfc/rfc4778.txt This document is a survey of the current practices used in today's large ISP operational networks to secure layer 2 and layer 3 infrastructure devices. The information listed here is the result of information gathered from people directly responsible for defining and implementing secure infrastructures in Internet Service Provider environments. This memo provides information for the Internet community. This document is a product of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Wed Jan 31 18:17:30 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Wed, 31 Jan 2007 18:17:30 -0800 Subject: [rfc-dist] RFC 4785 on Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) Message-ID: <200702010217.l112HUMs011851@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4785 Title: Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) Author: U. Blumenthal, P. Goel Status: Standards Track Date: January 2007 Mailbox: urimobile at optonline.net, Purushottam.Goel at intel.com Pages: 5 Characters: 9550 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tls-psk-null-03.txt URL: http://www.rfc-editor.org/rfc/rfc4785.txt This document specifies authentication-only ciphersuites (with no encryption) for the Pre-Shared Key (PSK) based Transport Layer Security (TLS) protocol. These ciphersuites are useful when authentication and integrity protection is desired, but confidentiality is not needed or not permitted. [STANDARDS TRACK] This document is a product of the Transport Layer Security 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Wed Jan 31 18:17:44 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Wed, 31 Jan 2007 18:17:44 -0800 Subject: [rfc-dist] BCP 127 RFC 4787 on Network Address Translation (NAT) Behavioral Requirements for Unicast UDP Message-ID: <200702010217.l112Hifj011866@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. BCP 127 RFC 4787 Title: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP Author: F. Audet, Ed., C. Jennings Status: Best Current Practice Date: January 2007 Mailbox: audet at nortel.com, fluffy at cisco.com Pages: 29 Characters: 68693 Updates: See-Also: BCP0127 I-D Tag: draft-ietf-behave-nat-udp-08.txt URL: http://www.rfc-editor.org/rfc/rfc4787.txt This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is a product of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. BEST CURRENT PRACTICE: 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Wed Jan 31 18:17:35 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Wed, 31 Jan 2007 18:17:35 -0800 Subject: [rfc-dist] RFC 4629 on RTP Payload Format for ITU-T Rec. H.263 Video Message-ID: <200702010217.l112HZ4F011856@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4629 Title: RTP Payload Format for ITU-T Rec. H.263 Video Author: J. Ott, C. Bormann, G. Sullivan, S. Wenger, R. Even, Ed. Status: Standards Track Date: January 2007 Mailbox: jo at netlab.tkk.fi, cabo at tzi.org, garysull at microsoft.com, stewe at stewe.org, roni.even at polycom.co.il Pages: 29 Characters: 67231 I-D Tag: draft-ietf-avt-rfc2429-bis-09.txt URL: http://www.rfc-editor.org/rfc/rfc4629.txt This document describes a scheme to packetize an H.263 video stream for transport using the Real-time Transport Protocol (RTP) with any of the underlying protocols that carry RTP. The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.263 video codec. The document obsoletes RFC 2429 and updates the H263-1998 and H263-2000 MIME media type in RFC 3555. [STANDARDS TRACK] This document is a product of the Audio/Video Transport 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Wed Jan 31 18:17:40 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Wed, 31 Jan 2007 18:17:40 -0800 Subject: [rfc-dist] RFC 4721 on Mobile IPv4 Challenge/Response Extensions (Revised) Message-ID: <200702010217.l112Hexa011861@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4721 Title: Mobile IPv4 Challenge/Response Extensions (Revised) Author: C. Perkins, P. Calhoun, J. Bharatia Status: Standards Track Date: January 2007 Mailbox: charles.perkins at nokia.com, pcalhoun at cisco.com, jayshree at nortel.com Pages: 26 Characters: 60386 I-D Tag: draft-ietf-mip4-rfc3012bis-05.txt URL: http://www.rfc-editor.org/rfc/rfc4721.txt Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, that extension does not provide the foreign agent any direct guarantee that the protocol is protected from replays and does not allow for the use of existing techniques (such as Challenge Handshake Authentication Protocol (CHAP)) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. Furthermore, this document updates RFC 3344 by including a new authentication extension called the Mobile-Authentication, Authorization, and Accounting (AAA) Authentication extension. This new extension is provided so that a mobile node can supply credentials for authorization, using commonly available AAA infrastructure elements. This authorization-enabling extension MAY co-exist in the same Registration Request with authentication extensions defined for Mobile IP Registration by RFC 3344. This document obsoletes RFC 3012. [STANDARDS TRACK] This document is a product of the Mobility for IPv4 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ...