IPv6 Operations (v6ops) Internet Drafts
| IPv6 Unicast Address Assignment Considerations | |||||||||||||||||
|
One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the deployment and integration of IPv6. This document aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments. The document also provides IPv6 addressing case studies for both an enterprise and an ISP network. | ||||||||||||||||
| Requirements for address selection mechanisms | |||||||||||||||||
|
There are some problematic cases when using the default address selection mechanism which RFC 3484 defines. This document describes additional requirements co-working with RFC 3484 to solve the problems. | ||||||||||||||||
| Problem Statement of Default Address Selection in Multi-prefix Environment: Operational Issues of RFC3484 Default Rules | |||||||||||||||||
|
A single physical link can have multiple prefixes assigned to it. In that environment, end hosts might have multiple IP addresses and be required to use them selectively. RFC 3484 defines default source and destination address selection rules and is implemented in a variety of OS's. But, it has been too difficult to use operationally for several reasons. In some environment where multiple prefixes are assigned on a single physical link, the host using the default address selection rules will experience some trouble in communication. This document describes the possible problems that end hosts could encounter in an environment with multiple prefixes. | ||||||||||||||||
| Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service | |||||||||||||||||
|
This document makes specific recommendations to the makers of devices that provide "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. | ||||||||||||||||
| Teredo Security Concerns | |||||||||||||||||
|
Additional security concerns with Teredo are documented, beyond what is in RFC 4380. This is based on an independent analysis of Teredo's security implications. The primary intent of this document is to raise the awareness regarding the security issues in Teredo as deployed today. | ||||||||||||||||
| IPv4/IPv6 Coexistence and Transition: Requirements for solutions | |||||||||||||||||
|
This note presents the problem statement, analysis and requirements for solutions to IPv4/IPv6 coexistence and eventual transition in a scenario in which dual stack operation is not the norm. | ||||||||||||||||
| IPv6 RA-Guard | |||||||||||||||||
|
When using IPv6 within a single L2 network segment it is neccesary to ensure that all routers advertising their services within it are valid. In cases where it is not convinient or possible to use SeND [RFC3971] a rogue Router Advertisement (RA) [RFC4861] could be sent by accident due to misconfiguraton or ill intended. Simple solutions for protecting against rogue RAs are beneficial in complementing SeND in securing the L2 domain for ceratin types of devices or in certain transitional situations. This document proposes a solution to reduce the threat of rogue RAs by enabling layer 2 devices to forward only RAs received over designated ports. | ||||||||||||||||
| vCard Format Specification | |||||||||||||||||
|
This document defines the vCard data format for representing and exchanging a variety of information about an individual (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). | ||||||||||||||||
| vCard Extensions to WebDAV (CardDAV) | |||||||||||||||||
|
This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. Discussion of this Internet-Draft is taking place on the mailing list | ||||||||||||||||
| Extended MKCOL for WebDAV | |||||||||||||||||
|
This specification extends the WebDAV MKCOL method to allow collections of arbitrary resourcetype to be created and to allow properties to be set at the same time. | ||||||||||||||||
 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
IPv6 Operations (v6ops)
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:
Additional V6OPS Web Page
Last Modified: 2008-04-22
Additional information is available at tools.ietf.org/wg/v6ops
Chair(s):
Operations and Management Area Director(s):
Operations and Management Area Advisor:
Mailing Lists:
General Discussion: v6ops@ops.ietf.orgTo Subscribe: majordomo@ops.ietf.org
In Body: subscribe v6ops
Archive: http://ops.ietf.org/lists/v6ops/
Description of Working Group:
The global deployment of IPv6 is underway, creating an IPv4/IPv6Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and
nodes. This deployment must be properly handled to avoid the division
of the Internet into separate IPv4 and IPv6 networks while ensuring
addressing and connectivity for all IPv4 and IPv6 nodes.
The IPv6 Operations Working Group (v6ops) develops guidelines for the
operation of a shared IPv4/IPv6 Internet and provides operational
guidance on how to deploy IPv6 into existing IPv4-only networks,
as well as into new network installations.
The main focus of the v6ops WG is to look at the immediate
deployment issues; more advanced stages of deployment and transition
are a lower priority.
The goals of the v6ops working group are:
1. Solicit input from network operators and users to identify
operational issues with the IPv4/IPv6 Internet, and
determine solutions or workarounds to those issues. These issues
will be documented in Informational or BCP RFCs, or in
Internet-Drafts.
This work should primarily be conducted by those areas and WGs
which are responsible and best fit to analyze these problems, but
v6ops may also cooperate in focusing such work.
2. Publish Informational or BCP RFCs that identify potential security
risks in the operation of shared IPv4/IPv6 networks, and document
operational practices to eliminate or mitigate those risks.
This work will be done in cooperation with the Security area and
other relevant areas or working groups.
3. As a particular instance of (1) and (2), provide feedback to
the IPv6 WG regarding portions of the IPv6 specifications that
cause, or are likely to cause, operational or security concerns,
and work with the IPv6 WG to resolve those concerns. This feedback
will be published in Internet-Drafts or RFCs.
4. Publish Informational or BCP RFCs that identify and analyze
solutions
for deploying IPv6 within common network environments, such as
ISP Networks, Enterprise Networks, Unmanaged Networks (Home/Small
Office), and Cellular Networks.
These documents should serve as useful guides to network
operators and users on possible ways how to deploy IPv6 within their
existing IPv4 networks, as well as in new network installations.
These documents should not be normative guides for IPv6 deployment,
and the primary intent is not capture the needs for new solutions,
but rather describe which approaches work and which do not.
IPv6 operational and deployment issues with specific protocols or
technologies (such as Applications, Transport Protocols, Routing
Protocols, DNS or Sub-IP Protocols) are the primary responsibility of
the groups or areas responsible for those protocols or technologies.
However, the v6ops WG may provide input to those areas/groups, as
needed, and cooperate with those areas/groups in reviewing solutions
to IPv6 operational and deployment problems.
Future work items within this scope will be adopted by the WG only if
there is a substantial expression of interest from the community and
if the work clearly does not fit elsewhere in the IETF.
There must be a continuous expression of interest for the WG to work
on a particular work item. If there is no longer sufficient interest
in the WG in a work item, the item may be removed from the list of WG
items.
Specifying any protocols or transition mechanisms is out of scope of
the WG.
Goals and Milestones:
| Done | Publish Cellular Deployment Scenarios as a WG I-D | |
| Done | Publish Unmanaged Network Deployment Scenarios as a WG I-D | |
| Done | Publish Survey of IPv4 Addresses in IETF Standards as WG I-D | |
| Done | Publish Cellular Deployment Solutions as a WG I-D | |
| Done | Publish Unmanaged Network Deployment Solutions as a WG I-D | |
| Done | Submit Cellular Deployment Scenarios to IESG for Info | |
| Done | Submit Unmanaged Network Deployment Scenarios to IESG for Info | |
| Done | Publish Enterprise Deployment Scenarios as a WG I-D | |
| Done | Submit Survey of IPv4 Addresses in IETF Standards to IESG for Info | |
| Done | Publish ISP Deployment & Solutions as a WG I-D | |
| Done | Submit Cellular Deployment Solutions to IESG for Info | |
| Done | Submit Transition Mechanisms to IESG for PS | |
| Done | Submit IPv6 Neighbor Discovery On-Link Assumption to IESG for Info | |
| Done | Submit Dual Stack IPv6 on by Default to IESG for Informational | |
| Done | Submit Unmanaged Network Deployment Solutions to IESG for BCP | |
| Done | Submit ISP Deployment Scenarios & Solutions to IESG for Info | |
| Done | Submit Application Aspects of IPv6 Transition to IESG for Informational | |
| Done | Submit 6to4 Security Analysis to IESG for Informational | |
| Done | Submit Enterprise Deployment Scenarios to IESG for Info | |
| Done | Submit Renumbering Procedures to IESG for Info | |
| Done | Adopt IPv6 Network Architecture Protection as WG item | |
| Done | Adopt document describing how to use IPsec with draft-ietf-v6ops-mech-v2 as WG item | |
| Done | Adopt IPv6 Security Overview as WG item | |
| Done | Ensure draft-ietf-v6ops-v6onbydefault keeps going forward for RFC publication | |
| Done | Submit IPv6 deployment using VLANs to IESG for Info | |
| Done | Submit document describing issues with NAT-PT to IESG for Info | |
| Done | Adopt IPv6 deployment using VLANs to IESG for Info | |
| Done | Adopt ISP IPv6 Deployment Scenarios in Broadband Access Networks as WG item | |
| Done | Submit document on IPsec w/ draft-ietf-v6ops-mech-v2 to IESG for Info | |
| Done | Submit IPv6 Network Architecture Protection to IESG for Info | |
| Done | Submit Enterprise Deployment Analysis to IESG for Info | |
| Done | Submit IPv6 Security Overview to IESG for Info | |
| Done | Submit ISP IPv6 Deployment Scenarios in Broadband Access Networks to IESG for Info |
Internet-Drafts:
IPv6 Unicast Address Assignment Considerations (83001 bytes)Requirements for address selection mechanisms (16793 bytes)
Problem Statement of Default Address Selection in Multi-prefix Environment: Operational Issues of RFC3484 Default Rules (35525 bytes)
Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service (59715 bytes)
Teredo Security Concerns (43746 bytes)
IPv4/IPv6 Coexistence and Transition: Requirements for solutions (39027 bytes)
IPv6 RA-Guard (16384 bytes)
Request For Comments:
Transition Scenarios for 3GPP Networks (RFC 3574) (23359 bytes)Unmanaged Networks IPv6 Transition Scenarios (RFC 3750) (48153 bytes)
Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards (RFC 3793) (11624 bytes)
Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards (RFC 3789) (22842 bytes)
Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards (RFC 3790) (102694 bytes)
Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards (RFC 3791) (27567 bytes)
Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards (RFC 3792) (46398 bytes)
Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards (RFC 3794) (60001 bytes)
Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards (RFC 3795) (92584 bytes)
Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards (RFC 3796) (78400 bytes)
Evaluation of Transition Mechanisms for Unmanaged Networks (RFC 3904) (46844 bytes)
Security Considerations for 6to4 (RFC 3964) (83360 bytes)
Application Aspects of IPv6 Transition (RFC 4038) (69727 bytes)
Scenarios and Analysis for Introducing IPv6 into ISP Networks (RFC 4029) (64388 bytes)
IPv6 Enterprise Network Scenarios (RFC 4057) (33454 bytes)
Procedures for Renumbering an IPv6 Network without a Flag Day (RFC 4192) (52110 bytes) updates RFC 2072
Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks (RFC 4215) (52903 bytes)
Basic Transition Mechanisms for IPv6 Hosts and Routers (RFC 4213) (58575 bytes) obsoletes RFC 2893
Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks (RFC 4554) (23355 bytes)
ISP IPv6 Deployment Scenarios in Broadband Access Networks (RFC 4779) (188511 bytes)
IPv6 Enterprise Network Analysis - IP Layer 3 Focus (RFC 4852) (76199 bytes)
Recommendations for Filtering ICMPv6 Messages in Firewalls (RFC 4890) (83479 bytes)
Using IPsec to Secure IPv6-in-IPv4 Tunnels (RFC 4891) (46635 bytes)
Local Network Protection for IPv6 (RFC 4864) (95448 bytes)
Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status (RFC 4966) (60284 bytes) obsoletes RFC 2766
IPv6 Neighbor Discovery On-Link Assumption Considered Harmful (RFC 4943) (16719 bytes)
IPv6 Transition/Co-existence Security Considerations (RFC 4942) (102878 bytes)
IPv6 Implications for Network Scanning (RFC 5157) (29054 bytes)
Special-Use IPv6 Addresses (RFC 5156) (11931 bytes)
IPv6 Deployment Scenarios in 802.16 Networks (RFC 5181) (36671 bytes)
IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.
Return to working group directory. 
