Last Call: (Protocol for Carrying Authentication for Network Access (PANA) Relay Element) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Protocol for Carrying Authentication for Network Access (PANA) Relay Element' 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-06-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 specifies Protocol for carrying Authentication for Network Access (PANA) Relay Element functionality which enables PANA messaging between a PANA Client (PaC) and a PANA Authentication Agent (PAA) where the two nodes cannot reach each other by means of regular IP routing. The file can be obtained via http://datatracker.ietf.org/doc/draft-ohba-pana-relay/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ohba-pana-relay/ 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
Last Call: (PPP TRILL Protocol Control Protocol) to Proposed Standard
The IESG has received a request from the Point-to-Point Protocol Extensions WG (pppext) to consider the following document: - 'PPP TRILL Protocol Control Protocol' 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-06-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 The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes PPP support for Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/ 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 6127 on IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios
A new Request for Comments is now available in online RFC libraries. RFC 6127 Title: IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios Author: J. Arkko, M. Townsley Status: Informational Stream: IETF Date: May 2011 Mailbox:jari.ar...@piuha.net, towns...@cisco.com Pages: 20 Characters: 48227 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-arkko-townsley-coexistence-06.txt URL:http://www.rfc-editor.org/rfc/rfc6127.txt When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition. This document was originally created as input to the Montreal co- existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 co-existence work. This document is published as a historical record of the thinking at the time, but hopefully will also help readers understand the rationale behind current IETF tools for co-existence and transition. 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
RFC 6255 on Delay-Tolerant Networking Bundle Protocol IANA Registries
A new Request for Comments is now available in online RFC libraries. RFC 6255 Title: Delay-Tolerant Networking Bundle Protocol IANA Registries Author: M. Blanchet Status: Informational Stream: IRTF Date: May 2011 Mailbox:marc.blanc...@viagenie.ca Pages: 9 Characters: 19606 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-irtf-dtnrg-iana-bp-registries-02.txt URL:http://www.rfc-editor.org/rfc/rfc6255.txt The Delay-Tolerant Networking (DTN) Research Group research group has defined many protocols such as the Bundle Protocol and Licklider Transmission Protocol. The specifications of these protocols contain fields that are subject to a registry. For the purpose of its research work, the group created ad hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official custody. This document describes the actions executed by IANA. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IRTF. 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
RFC 6256 on Using Self-Delimiting Numeric Values in Protocols
A new Request for Comments is now available in online RFC libraries. RFC 6256 Title: Using Self-Delimiting Numeric Values in Protocols Author: W. Eddy, E. Davies Status: Informational Stream: IRTF Date: May 2011 Mailbox:w...@mti-systems.com, elw...@folly.org.uk Pages: 17 Characters: 40765 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-irtf-dtnrg-sdnv-09.txt URL:http://www.rfc-editor.org/rfc/rfc6256.txt Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type in proposed Delay-Tolerant Networking protocols. SDNVs encode an arbitrary-length non-negative integer or arbitrary- length bitstring with minimum overhead. They are intended to provide protocol flexibility without sacrificing economy and to assist in future-proofing protocols under development. This document describes formats and algorithms for SDNV encoding and decoding, along with notes on implementation and usage. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IRTF. 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
RFC 6257 on Bundle Security Protocol Specification
A new Request for Comments is now available in online RFC libraries. RFC 6257 Title: Bundle Security Protocol Specification Author: S. Symington, S. Farrell, H. Weiss, P. Lovell Status: Experimental Stream: IRTF Date: May 2011 Mailbox:su...@mitre.org, stephen.farr...@cs.tcd.ie, howard.we...@sparta.com, dtn...@gmail.com Pages: 60 Characters: 142509 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-irtf-dtnrg-bundle-security-19.txt URL:http://www.rfc-editor.org/rfc/rfc6257.txt This document defines the bundle security protocol, which provides data integrity and confidentiality services for the Bundle Protocol. Separate capabilities are provided to protect the bundle payload and additional data that may be included within the bundle. We also describe various security considerations including some policy options. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community. This document is a product of the IRTF. 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
RFC 6258 on Delay-Tolerant Networking Metadata Extension Block
A new Request for Comments is now available in online RFC libraries. RFC 6258 Title: Delay-Tolerant Networking Metadata Extension Block Author: S. Symington Status: Experimental Stream: IRTF Date: May 2011 Mailbox:su...@mitre.org Pages: 10 Characters: 22584 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-irtf-dtnrg-bundle-metadata-block-10.txt URL:http://www.rfc-editor.org/rfc/rfc6258.txt This document defines an extension block that may be used with the Delay-Tolerant Networking (DTN) Bundle Protocol. This Metadata Extension Block is designed to carry additional information that DTN nodes can use to make processing decisions regarding bundles, such as deciding whether to store a bundle or determining to which nodes to forward a bundle. The metadata that is carried in a metadata block must be formatted according to the metadata type that is identified in the block's metadata type field. One specific metadata type, for carrying URIs as metadata, is defined in this document. Other metadata types may be defined in separate documents. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community. This document is a product of the IRTF. 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
RFC 6259 on Delay-Tolerant Networking Previous-Hop Insertion Block
A new Request for Comments is now available in online RFC libraries. RFC 6259 Title: Delay-Tolerant Networking Previous-Hop Insertion Block Author: S. Symington Status: Experimental Stream: IRTF Date: May 2011 Mailbox:su...@mitre.org Pages: 10 Characters: 23278 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-irtf-dtnrg-bundle-previous-hop-block-12.txt URL:http://www.rfc-editor.org/rfc/rfc6259.txt This document defines an extension block for use with the Delay- Tolerant Networking (DTN) Bundle Protocol. This Previous-Hop Insertion Block (PHIB) extension block is designed to be inserted by a forwarding node to provide the endpoint identifier (EID) of an endpoint of which the forwarding node is a member so that this EID may be conveyed to the next-hop receiving node. Knowledge of an EID of an endpoint of which a previous-hop node is a member may be required in some circumstances to support certain routing protocols (e.g., flood routing). If this EID cannot be provided by the convergence layer or other means, the PHIB defines the mechanism whereby the EID can be provided with the bundle. Each PHIB is always removed from the bundle by the receiving node so that its presence within the bundle is limited to exactly one hop. This document defines the format and processing of this PHIB. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community. This document is a product of the IRTF. 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
RFC 6260 on Compressed Bundle Header Encoding (CBHE)
A new Request for Comments is now available in online RFC libraries. RFC 6260 Title: Compressed Bundle Header Encoding (CBHE) Author: S. Burleigh Status: Experimental Stream: IRTF Date: May 2011 Mailbox:scott.c.burle...@jpl.nasa.gov Pages: 12 Characters: 25381 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-irtf-dtnrg-cbhe-09.txt URL:http://www.rfc-editor.org/rfc/rfc6260.txt This document describes a convention by which Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent endpoint identifiers in a compressed form within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention. Compressed Bundle Header Encoding (CBHE) compression is a convergence-layer adaptation. It is opaque to bundle processing. Therefore, it has no impact on the interoperability of different Bundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community. This document is a product of the IRTF. 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
