IETF Jabber server changes
At the request of various IETF participants, the IETF Secretariat is offering Jabber service between meetings, on a trial basis, to observe what the usage and demand might be. We are planning to make the following changes to the IETF jabber server: 1). The domain name of the chat room server will be changed from rooms.jabber.ietf.org to jabber.ietf.org. Please note that as soon as this change is made, all connections to the IETF jabber chat rooms will have to specify jabber.ietf.org in the server field of the client software being used. 2). The chat room logs will be renamed. We were asked to have the chat room logs directories appear on the web page as roomname instead of roomname.jabber.ietf.org. Note that all previous chat room logs will continue to be available under the new room directory name. E.g. to see all the chat logs for the sip WG, you will point a browser to www.ietf.org/meetings/ietf-logs. You will then click on the directory line labeled sip, and will be able to see all past chat logs for that WG. Also note that the past chat room logs that were sent to us from xmpp.org will be added to the web site at this time. 3) The chat room logs will be pruned such that the only daily log files that will be retained on the web site will be those which have actual content, i.e. completely empty log files will be removed. 4) Rooms will be created for the IRTF working groups in the jabber.ietf.org domain. Specifically, the following rooms will be added to the available room list: rch, asrg, cfrg, dtnrg, end2end, gsec, iccrg, imrg, nmrg, p2prg, rr, siren, smrg, tmrg. We will make these changes on Tuesday, April 18 during the afternoon. Consequently the IETF jabber server will be off-line during that time. For planning purposes, assume the server will be unavailable between the hours of 2:00pm and 5:00pm EST. It is likely that the server will be returned to service prior to 5:00pm. Regards, The IETF Secretariat. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4472 on Operational Considerations and Issues with IPv6 DNS
A new Request for Comments is now available in online RFC libraries. RFC 4472 Title: Operational Considerations and Issues with IPv6 DNS Author: A. Durand, J. Ihren, P. Savola Status: Informational Date: April 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 29 Characters: 68882 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-dnsop-ipv6-dns-issues-12.txt URL:http://www.rfc-editor.org/rfc/rfc4472.txt This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehavior, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS. This memo provides information for the Internet community. This document is a product of the Domain Name System 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 [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Constrained VPN Route Distribution' to Proposed Standard
The IESG has approved the following document: - 'Constrained VPN Route Distribution ' draft-ietf-l3vpn-rt-constrain-02.txt as a Proposed Standard This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Mark Townsley and Margaret Wasserman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-rt-constrain-02.txt Technical Summary This document addresses scaling issues for VPN routing information maintained atroute reflectors. It extends the RFC2547bis approach using âCooperative Route Filteringâ between router reflectors for support multiple autonomous systems and asymmetric VPN topologies such as hub-and-spoke. The solution uses MP-BGP UPDATE messages to propagate Route Target membership information. Received RouteTarget membership information can then be used to restrict advertisement ofVPN NLRI to peers that have advertised their respective Route Targets, effectively building a route distribution graph. In this model, VPN NLRI routing informationflows in the inverse direction of Route Target membership information. This mechanism is applicable to any BGP NLRI that controls the distribution of routing information based on Route Targets, such as BGP L2VPNs [L2VPN] and VPLS [VPLS]. Working Group Summary There were several detailed issued which were raised when the document was submitted to the WG. Constructive comments led to modifications to the document which addressed the concerns that were raised. Protocol Quality In addition to L3VPN review, this document was reviewed by the IDR WG where it received review comments from Rick Wilder, Chandrashekhar Appanna, and Jeff Haas. Multiple implementations exist. Note to RFC Editor The upper left hand corner of the title page should include: Updates: draft-ietf-l3vpn-rfc2547bis-03 In section 2, please replace proposal with document in the following text: This proposal extends the RFC2547bis [3] ORF work to include support for multiple autonomous systems, and asymmetric VPN topologies such as hub-and-spoke. Also in section 2, please remove the [?] reference, new text is: This mechanism is applicable to any BGP NLRI that controls the distribution of routing information based on Route Targets such as VPLS [9]. Please change the title to: Constrained Route Distribution for BGP/MPLS IP VPNs Please replace the Abstract with: This document defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information. This information can be used to build a route distribution graph in order to limit the propagation of Virtual Private Network (VPN) Network Layer Reachability Information (NLRI) between different autonomous systems or distinct clusters of the same autonomous system. This document updates draft-ietf-l3vpn-rfc2547bis-03. [RFC Editor: please replace this Internet-Draft reference with an RFC number when it is assigned.] Please add a Terminology Section with the following acronyms expanded and defined and the informational reference to RFC4026: This document uses a number of terms and acronyms specific to Provider-Provisioned VPNs, including those specific to L2VPNs, L3VPNs and BGP. Definitions for many of these terms may be found in the VPN terminology document [RFC4026]. This section also includes some brief acronym expansion and terminology to aid the reader. AFI - Address Family Identifier (a BGP address type) BGP - Border Gateway Protocol BGP/MPLS VPN - A Layer 3 VPN implementation based upon BGP and MPLS. CE - Customer Edge (router) iBGP - Internal BGP; i.e., a BGP peering session that connects two routers within an autonomous system L2VPN - Layer 2 Virtual Private Network L3VPN - Layer 3 Virtual Private Network MP-BGP - Multi-Protocol Border Gateway Protocol MPLS - Multi-Protocol Label Switching NLRI - Network Layer Reachability Information ORF - Outbound Route Filtering PE - Provider Edge (router) RT - Route Target (i.e., a BGP extended community that conditions network layer reachability information with VPN membership) SAFI - Subsequence Address Family Identifier (a BGP address sub-type) VPLS - Virtual Private LAN Service VPN - Virtual Private Network Editor: Please include an informational reference to RFC 4026 in the referencessection. Please change the following text in section 6 From: A BGP speaker should generate the minimum set of BGP VPN route updates necessary to transition between the previous and current state of the route distribution graph that is derived from Route Target membership information. To: A BGP speaker should generate the minimum set of BGP VPN route updates (advertisements and/or withdrawls) necessary to transition between the previous and current state of the route distribution graph that is derived from Route Target membership information.
Protocol Action: 'BGP-MPLS IP VPN extension for IPv6 VPN' to Proposed Standard
The IESG has approved the following document: - 'BGP-MPLS IP VPN extension for IPv6 VPN ' draft-ietf-l3vpn-bgp-ipv6-07.txt as a Proposed Standard This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgp-ipv6-07.txt Technical Summary This document describes a method by which a Service Provider may use its packet switched backbone to provide Virtual Private Network services for its IPv6 customers. This method reuses, and extends where necessary, the BGP/MPLS IP VPN method [2547bis] for support of IPv6. In particular, this method uses the same peer model as [2547bis], in which the customers' edge routers (CE routers) send their IPv6 routes to the Service Provider's edge routers (PE routers). BGP (Border Gateway Protocol, [BGP, BGP-MP]) is then used by the Service Provider to exchange the routes of a particular IPv6 VPN among the PE routers that are attached to that IPv6 VPN. Eventually, the PE routers distribute, to the CE routers in a particular VPN, the IPv6 routes from other CE routers in that VPN. As with IPv4 VPNs, a key characteristic of this peer model is that the (IPv6) CE routers within an (IPv6) VPN do not peer with each other and there is no overlay visible to the (IPv6) VPN's routing algorithm. A VPN is said to be an IPv6 VPN, when each site of this VPN is IPv6 capable and is natively connected over an IPv6 interface or sub- interface to the SP backbone via a Provider Edge device (PE). A site may be both IPv4-capable and IPv6-capable. The logical interface on which packets arrive at the PE may determine the IP version. Alternatively the same logical interface may be used for both IPv4 and IPv6 in which case a per-packet lookup at the Version field of the IP packet header determines the IP version. This document only concerns itself with handling of the IPv6 packets. As such the inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. In a similar manner to how IPv4 VPN routes are distributed in [2547bis], BGP and its extensions are used to distribute routes from an IPv6 VPN site to all the other PE routers connected to a site of the same IPv6 VPN. PEs use VPN Routing and Forwarding tables (VRFs) to separately maintain the reachability information and forwarding information of each IPv6 VPN. As it is done for IPv4 VPNs [2547bis], we allow each IPv6 VPN to have its own IPv6 address space, which means that a given address may denote different systems in different VPNs. This is achieved via a new address family, the VPN-IPv6 Address Family, in a fashion similar to the VPN-IPv4 address family defined in [2547bis] and which prepends a Route Distinguisher to the IP address. In addition to its operation over MPLS Label Switched Paths (LSPs), the IPv4 BGP/MPLS VPN solution has been extended to allow operation over other tunneling techniques including GRE tunnels, IP-in-IP tunnels [2547-GRE/IP], L2TPv3 tunnels [MPLS-in-L2TPv3] and IPsec- protected tunnels [2547-IPsec]. In a similar manner, this document allows support of an IPv6 VPN service over MPLS LSPs as well as over other tunneling techniques including GRE tunnels, IP-in-IP tunnels, L2TPv3 tunnels and IPsec-protected tunnels. This document allows support for an IPv6 VPN service over an IPv4 backbone as well as over an IPv6 backbone. The IPv6 VPN service supported is identical in both cases. Working Group Summary This document went smoothly through the WG process. Protocol Quality At least two vendors have developed to earlier versions of this draft. Jeffrey Haas and Pedro Marques both commented on the draft as it went through multiple revisions. RFC Editor Note: The document's references to draft-ietf-ipv6-unique-local-addr-09.txt need to be updated; one section refers to Section 10, which no longer exists. I believeit should refer to Section 4.7. Please search and replace on byte replacing it with octet throughout the document. Please remove the reference to [RFC2547bis] in the Abstract. There are citation inconsistencies, please work with the authors to clear theseup. See tracker for reference check tool output. Please add the following clarifying sentence at the end of Section 5: Recommendations and considerations for which of these supported address types should be used in a given IPv6 VPN environments are beyond the scope of this document ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
