2.4.13 IPv6 Operations (v6ops)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.
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: 2005-06-15


Fred Baker <fred.baker@cisco.com>
Kurt Lindqvist <kurtis@kurtis.pp.se>

Operations and Management Area Director(s):

Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>

Operations and Management Area Advisor:

David Kessens <david.kessens@nokia.com>

Mailing Lists:

General Discussion: v6ops@ops.ietf.org
To 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/IPv6
Internet 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
global 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 guidance for
network operators on how to deploy IPv6 into existing IPv4-only
networks, as well as into new network installations.

The v6ops working group will:

1. Solicit input from network operators and users to identify
  operational or security issues with the IPv4/IPv6 Internet, and
  determine solutions or workarounds to those issues.  This includes
  identifying standards work that is needed in other IETF WGs or
  areas and working with those groups/areas to begin appropriate
  work.  These issues will be documented in Informational or BCP
  RFCs, or in Internet-Drafts.

  For example, important pieces of the Internet infrastructure
  such as DNS, SMTP and SIP have specific operational issues when
  they operate in a shared IPv4/IPv6 network. The v6ops WG will
  cooperate with the relevant areas and WGs to document those
  issues, and find protocol or operational solutions to those

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.

3. Publish Informational RFCs that help application developers
  (within and outside the IETF) understand how to develop IP
  version-independent applications.  Work with the Applications
  area, and other areas, to ensure that these documents answer
  the real-world concerns of application developers.  This
  includes helping to identify IPv4 dependencies in existing
  IETF application protocols and working with other areas and/or
  groups within the IETF to resolve them.

4. 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.

5. Publish Informational or BCP RFCs that identify and analyze
  for deploying IPv6 within common network environments, such as
  ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks),
  Enterprise Networks, Unmanaged Networks (Home/Small Office), and
  Cellular Networks.

  These documents should serve as useful guides to network
  operators and users on how to deploy IPv6 within their existing
  IPv4 networks, as well as in new network installations.

6. Identify open operational or security issues with the deployment
  scenarios documented in (5) and fully document those open
  issues in Internet-Drafts or Informational RFCs.  Work to find
  workarounds or solutions to basic, IP-level operational
  or security issues that can be solved using widely-applicable
  transition mechanisms, such as dual-stack, tunneling or

  If the satisfactory resolution of an operational or security
  issue requires the standardization of a new, widely-applicable
  transition mechanism that does not properly fit into any other
  IETF WG or area, the v6ops WG will standardize a transition
  mechanism to meet that need.

7. Assume responsibility for advancing the basic IPv6 transition
  mechanism RFCs along the standards track, if their applicability
  to common deployment scenarios is demonstrated in (5) above:

  Transition Mechanisms (RFC 2893)

  SIIT (RFC 2765)

  NAT-PT (RFC 2766)

  6to4 (RFC 3056 & 3068)

  This includes updating these mechanisms, as needed, to resolve
  problems.  In some cases, these mechanisms may be deprecated
  (i.e. moved to Historic), if they are not found to be applicable
  to the deployment solutions described in (5) or if serious flaws
  are encountered that lead us to recommend against their use.

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 group will provide input to those areas/groups, as
needed, and cooperate with those areas/groups in developing and
reviewing solutions to IPv6 operational and deployment problems.

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
Apr 05  Ensure draft-ietf-v6ops-v6onbydefault keeps going forward for RFC publication
Apr 05  Submit IPv6 deployment using VLANs to IESG for Info
Apr 05  Submit document describing issues with NAT-PT to IESG for Info
May 05  Submit document on IPsec w/ draft-ietf-v6ops-mech-v2 to IESG for Info
Jun 05  Submit IPv6 Network Architecture Protection to IESG for Info
Jun 05  Submit Enterprise Deployment Analysis to IESG for Info
Jul 05  Submit IPv6 Security Overview to IESG for Info
Jul 05  Submit ISP IPv6 Deployment Scenarios in Broadband Access Networks to IESG for Info


  • draft-ietf-v6ops-3gpp-analysis-11.txt
  • draft-ietf-v6ops-mech-v2-07.txt
  • draft-ietf-v6ops-onlinkassumption-03.txt
  • draft-ietf-v6ops-renumbering-procedure-05.txt
  • draft-ietf-v6ops-ent-analysis-03.txt
  • draft-ietf-v6ops-natpt-to-exprmntl-01.txt
  • draft-ietf-v6ops-bb-deployment-scenarios-03.txt
  • draft-ietf-v6ops-nap-01.txt
  • draft-ietf-v6ops-security-overview-02.txt
  • draft-ietf-v6ops-ipsec-tunnels-00.txt
  • draft-ietf-v6ops-vlan-usage-00.txt

    Request For Comments:

    RFC3574 I Transition Scenarios for 3GPP Networks
    RFC3750 I Unmanaged Networks IPv6 Transition Scenarios
    RFC3789 I Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards
    RFC3790 I Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards
    RFC3791 I Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards
    RFC3792 I Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards
    RFC3793 I Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards
    RFC3794 I Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards
    RFC3795 I Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards
    RFC3796 I Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards
    RFC3904 I Evaluation of Transition Mechanisms for Unmanaged Networks
    RFC3964 I Security Considerations for 6to4
    RFC4029 I Scenarios and Analysis for Introducing IPv6 into ISP Networks
    RFC4038 I Application Aspects of IPv6 Transition
    RFC4057 I IPv6 Enterprise Network Scenarios

    Current Meeting Report

    IETF 63 V6OPS meeting minutes
    WG chairs: Fred Baker and Kurt Lindqvist
    Secretary - Cedric Aoun
    Documents in RFC editorÕs queue
    -Analysis on IPv6 Transition in 3GPP Networks: 
    „	draft-ietf-v6ops-3gpp-analysis-11.txt
    -Procedures for Renumbering an IPv6 Network without a Flag Day: 
    „	draft-ietf-v6ops-renumbering-procedure-05.txt
    „	Tunneling IPv6 over UDP through NATs; draft-huitema-v6ops-teredo-05.txt
    -Basic Transition Mechanisms for IPv6 Hosts and Routers: 
    „	draft-ietf-v6ops-mech-v2-07.txt
    WG Last call has been completed on the following documents:
    -draft-ietf-v6ops-onlinkassumption (informational, corollary to draft-ietf-ipv6-2461bis-04.txt)
    Jim Bound -  IPv6 Enterprise Network Analysis 
    Changes from 02 to 03
    „	Fixed more IETF id-nits
    „	Added Section 8.4 Transition Mechanism Summary analysis
    „	Still have one more id-nit to fix on a few line lengths
    Section 8.4 summary
    „	Overview of the following mechanisms potential use within the Enterprise 
    o	Manual configured Tunnels (works but does not scale)
    o	6to4: every vendor has implemented it. Once an IPv6  prefix is selected for an enterprise, 6to4 might not work in certain networks as they will filter 6to4 prefixes.
    o	ISATAP (going to be an experimental RFC) supported on MS Windows, Linux, Symbian
    o	Teredo would work well if firewalls are configured to make it work 
    o	Tunnel Broker: is deployed and in production
    o	DSTM (experimental RFC): used when IPv4 is no longer used in the enterprise network, if IPv4 connectivity is required it will be tunneled over IPv6
    Gunter Van de Velde - IPv6 Network Architecture Protection
    Documented perceived benefits of IPv4 NATs and mapped these benefits to IPv6 without doing address translation
    Status update and summary of the pending issues:
    „	Some textual enhancements were suggested 
    „	External review from NAT communities is desired
    „	Section 6: IPv6 Gap Analysis needs some extra attention to correct the current reference document status
    „	/128 address suggestion on physical interface needs review
    „	Suggestion that text should place NAT in more NATs friendly way at most places
    „	Text is almost ready for IESG
    Section 2.2: (simple security) Better not to use the word evil in the text
    Section 2.5: IPv4 private addresses is not limitless 
    Section 4.2 (IPv6 and Simple security )
    The text introduces PING sweep and explains in more details what the operation is? Should the operation be explained or should just introduce the terminology?
    Section 4.4 : Privacy and topology hiding, mobile IPv6 will be removed and be replaced by a general statement on tunneling usage
    Section 5.4: case study: ISP networks
    ULA usage for ISP/Carrier-grade networks is not required 
    Section 6.1; completion of work on ULAs or remove the chapter?
    Section 6.2 Topology masking /128 addresses on an interface? Can we suggest this in the draft?
     Section 6.3: Minimal traceability
    Better to say topology masking may be required instead of is required
    Section 6.4: Renumbering Procedure
    „	Renumbering procedure is in RFC queue. 
    Received comments:
    Fred Baker: In IPv4, /32 addresses are used for virtual (such as loop-back, which is important to BGP) interfaces, and for point-to-point (such as dial and PPPoE Ņdial-likeÓ) interfaces. I would expect this to be true of /128 addresses in IPv6.
    A new last call will be required after the new draft is released.
    Elwyn Davies - IPv6 Transition/Co-existence Security Considerations
    Summary of main changes
    „	Removed details of ICMPv6 filtering (new draft created)
    „	Old section 4.2 (Enabling IPv6 by Default Reduces Usability) was replaced by DNS server issues 
    „	Router advertisement security section had minor editorial changes
    Believes that the draft is ready for WG LC as all the comments were fixed.
    Elwyn Davies - Best Current Practice for Filtering ICMPv6 Messages in Firewalls
    This work was suggested by:
    „	work in EU 6NET project (www.6net.org) and Terena (www.terena.nl)
    „	ICMPv6 is a fundamental component of IPv6 networks
    o	Some parts of ICMPv6 have an essential role in establishing communications
    o	Less of an auxiliary than ICMP in IPv4
    „	Some ICMPv6 renumbering (NS, NA + renumber)
    „	Path MTU determination (packet 2 big)
    Classifying ICMPv6 functions and messages
    „	Error and informational Messages
    „	Addressing
    o	Lots of different possibilities
    „	Network Topology and address scopes
    o	Intra-link 
    o	End to end
    o	Any to end 
    Security issues
    „	Denial of service possibilities
    „	Network probing
    „	Redirection attacks
    „	Renumbering attacks
    Common considerations - canÕt blindly filter messages
    „	Need to filter on
    o	ICMPv6 type
    o	Address types and scopes
    „	If possible: deep packet inspection could be used
    o	ICMPv6 code field
    o	Stateful mechanisms may be able to match an inbound ICMPv6 response to an outbound ICMPv6 request
    Missing pieces
    „	Inverse neighbor discovery messages (#141/142)
    „	No mention of SEND
    o	Role in securing Intra-link messages
    o	Certification Path message
    Next steps
    „	Ask the working group to make this a WG document/task
    „	Encourage comments especially from firewall administrators!
    „	Generate a new version to fill in the gaps
    Fred Baker (WG chair hat on): it seems logical that the WG picks up the document as this document was split from an accepted WG document.
    Pekka Savola: prefers that the draft be informational as there is not a lot of experience yet to verify the draft.
    David Kessens (Area Director hat off): thinks the same as Pekka
    Alain Durand thinks that the document is useful, but thinks that if the document should be BCP as normally only BCPs get updated and there are already sufficient deployments to learn from and verify the BCP recommendations.
    Some other speaker, need to make it BCP as implementations are ramping up and we need to finish the work ASAP
    Richard Graveman, no issues if it gets to BCP since they could be changed
    The WG hummed for accepting the document as a WG document and as a BCP.  Several people confirmed that they will be reviewing the document
    Pekka Savola - Using IPsec to Secure IPv6-in-IPv4 Tunnels 
    „	The transition mechanisms document (draft-ietf-v6ops-mech-v2-07.txt) was low on IPSEC details
    o	The details are non trivial and lengthy
    o	This doc was written to describe those details for v6inv4 tunnels
    Lots of good feedback since version 03 (December 04)
    „	WG -00 was published in July
    „	Aiming for an Informational RFC
    The biggest changes since -03
    „	All the tunnel traffic is protected 
    „	IPSEC processing vs. ingress filtering is clarified
    „	Section on EAP was removed (out of scope as was discussing boot strapping)
    „	We describe three ways of protecting the tunnel
    o	Transport mode
    „	Tunnel mode with generic selectors
    o	Both approaches assume the tunnel is modeled as an interface
    o	Tunnel mode with specific selectors
    „	Assumes the tunnel is not modeled as an interface and not recommended to be used
    What next?
    „	Feedback in welcome
    o	Especially if you read a previous version of the draft
    „	The chairs should judge when the document is ready for WG LC
    o	WeÕll revise (at least) once before WGLC
    „	Any specific comments/suggestions?
    Authors will update draft based on ElwynÕs received version and then go to WG LC
    Jordi Palet - ISP IPv6 Deployment Scenarios in Broadband Access Networks
    „	Cover different broadband technology (Cable, DSL, Ethernet, Wireless and PLC/Broadband Power line)
    „	Provide detailed IPv6 deployment issues and solutions 
    „	Last changes driven by comments received during LC 
    „	Clarified text in the PLC sections 
    „	Clarified the Edge outer nomenclature in point V of the GAP analysis
    „	Updated point I from the gap analysis section to better explain the provisions
    Next steps:
    „	Any other comments?
    „	The last call was completed and would like to move the document to the next phase
    Alain Durand - Comcast: wants to merge sections 6.2.1 and 6.2.2, these sections are very complicated to understand for MSOs deploying IPv6
    „	DOCSIS 3.0 is currently being defined by Cable Labs and is  relevant to cable scenarios and should be inline with the draft. DOCSIS 3.0 dates are not finalized yet.
    Jean-Francois Mullet - Cable labs - interested on providing requirements from DOCSIS 3.0.  No clear consensus within Cable Labs and cable providers when deployments scenarios will be finished
    Alain Durand - Comcast; MSOs wonÕt wait long for 6 months or more. Believes that for the next IETF, MSOs could clarify the IPv6 deployments in cable networks.
    Pekka Savola - since cable providers will need to change their H/W we could probably delay the documents
    Tony Haines - certain scenarios doesnÕt require H/W changes
    WG Chairs - Jordi to work with Alain and Jean-Franois Mule and take into account their inputs.
    Jordi Palet - Distributed Security Framework
    „	Foreseen medium/Short term future
    o	Increase in type and number of threats
    „	Emerging technologies
    Analyses the network based security model
    Introduces the host based security model
    „	New technologies, behaviors and threats require improving the security mechanisms actually being used,
    „	By one side the integration of different mechanisms and by other side the movement of the security policy enforcement point towards the hosts 
    „	Not sure if this document should be a V6OPS WG document or ask for a BOF.
    WG chair (Fred) suggested to Jordi to contact the security ADs and the operations ADs to decide how to move forward.
    Operational experience in IPv6 network renumbering
    Two years ago, the IPv6 renumbering effort was started and some experiences were required to validate the work. Several teams within the 6net and Cisco have been testing the IPv6 renumbering procedures.
    A little history on the work and introduction by Ralph Droms:
    „	IPv6 design goals include (RFC1726)
    o	Scale - including size of core routing tables
    o	Ease of changing the topology of the network within a particular routing domain 
    Project sponsorship and goal
    „	Project jointly sponsored by Cisco and 6NET to conduct experimental
    „	Validate current renumbering procedures and identify gaps in tools and protocols
    JOIN/Uni Muenster, Thorsten Kuefer - prior art and tools, backbone renumbering and BGP issues, SOHO renumbering
    IPv6 was designed with renumbering in mind:
    „	IPv6 auto-configuration
    „	Multiple addresses per interfaces, essential when the old and new addresses are used
    „	DHCPv6 prefix delegation
    „	RFC2894 - Router Renumbering - but there is no working implementation of it, hence manual configuration was required for the German research network
    „	Unique Local Addresses useful for internal communications
    For their backbone renumbering experiment the following was used/occurred:
    „	The new WG renumbering procedures which is based on RFC2072, Router Renumbering guide
    „	DNS server entry changes: reduced the timers in the beginning and extend them when renumbering ends, and other expected changes (new address entries etc É)
    „	BGP peering configuration 
    Testing scenarios:
    „	Backbone of 5 routers, had to change all the interface addresses manually, as well as DNS entries and BGP peering
    „	Static routes ha
    „	Renumbering took four weeks (mainly because of 40 customers), could be possible in 1-2 days
    Uni Southampton, Tim Chown - enterprise renumbering
    About 1K hosts, about 20 subnets. All services are ran on dual-stack hosts. A /48 was renumbered to a /52 prefix.
    Procedure specifics
    „	No issues were found in the new renumbering procedure.
    From the host point of view
    „	RFC3484 address selection used when:
    o	(1) nodes have both prefixes in use, equal preference
    o	(2) Nodes use new prefix, old prefix deprecated
    „	RFC3484 implementations on Linux, BSD, OS X ad XP behave well for (2), but less so for (1)
    „	Some hosts (OS X, bsd, Linux) still send data with old source address even after marked invalid
    o	Receiver cannot then communicate back to sender
    o	This shouldnÕt happen according to RFC2462
    „	Unless authenticated RAs are used, the minimal renumbering time is two hours
    „	Important to identify where literals used (since they need to be changed/updated)
    o	No sites they spoke to had a literal usage inventory
    „	It's very useful to have tools to detect missed instances, e.g. using scripts looking at data from a Neflow collector
    „	Need to watch for DNS cached entries
    „	Would like to be able to use tokens in configurations vs. ACL entries (with IP addresses which get broken with the renumbering unless able to just filter on the Interface ID)
    What about use of ULAs?
    „	IPv6 has ULAs
    o	Replaces old site local unicast prefixes
    „	Can use both ULAs and global addresses (without NAT)
    o	Use ULAs for stable internal communications
    Future work
    „	Analysis/testing of policy based routing where required
    o	Issue is somewhat skipped over in the new renumbering procedure text
    Router Renumbering protocol , gap analysis Jerome Durand (Renater)
    Renater had to renumber 3 times it was very painful, a one year process every time  need to make it automatic (but still under control)
    Move step by step
    „	Easy rollback process
    Router Renumbering and baker/drom/lear procedures
    „	Things in procedures RR canÕt do:
    o	DNS modifications
    „	Update timers
    „	Change forward tree
    „	Change reverse tree
    o	Update non-router equipments
    „	Firewalls
    o	DHCPv6 server changes
    „	Update timers
    „	Update pools
    o	Deal with hard-coded IPv6 addresses
    o	Internet Registries interaction
    o	Management
    „	Nice Interface to be able to control the different steps
    „	Monitoring the process
    o	Rollback
    NetSB - Renater tool to monitor the renumbering - was found to be very useful
    „	Collects information sent by the monitored/renumbered hosts
    Need to be able to renumber some parts of the network and not all of it
    Cisco results on renumbering will be hosted on the Cisco web site
    Alain Durand - Need to identify renumbering tools useful for DNS tools. Question to Tim Chown: was IPv4 running ? as IPv4 could be used for IPv4 mgmt tools.
    A speaker - in his enterprise renumbering experience only IPv6 was used
    Erick Nordmark - was netflow there by design?
    Unknown speaker-  they donÕt want everything to be automatic as they still wants to have control on the renumbering.
    On stateless and stateful configured nodes, when the address changes the socket is still bounded to the old address until the application discovers the issues? Was that what they talked about? Fred said that there was a timer of less than 5 minutes for that. 
    Stig Venaas mentioned that the issue is due to the socket being bounded to a specific address. For TCP the socket is bounded by default to an address and hence it would be detected but in the case of UDP the application continues using it unless it has a feedback mechanism that no packets are received anymore.
    Alain Durand - the need is more on tools than protocols. Chairs feel that the presentations highlight good opportunities for S/W mgmt tools. It seems that Router Renumbering protocol didnÕt solve the issues, as there is still a need to configure the routers individually. Should the protocol be deprecated? Chair: no RFC is needed to deprecate the protocol, AD could do that. 
    Pekka Savola: suggest doing further analysis to see if only tools are required
    Ralph.D: current Router Renumbering protocol, does not have an add, remove prefix at certain times. 
    Jerome thinks that a reporting and rollback capability is required. 
    Tim discussed his inputs in the things to think about document - maybe pick up some parts of the document and put it in the WG renumbering document. 
    Summary of discussion is basically analyze the required tools and see if new protocols are required to support these tools.


    IPv6 Operations Agenda
    Enterprise IPv6 Transition Analysis
    Network Architecture Protection
    Using IPsec to Secure IPv6-in-IPv4 Tunnels
    ISP IPv6 Deployment Scenarios in Broadband Access Networks
    IPv6 Transition/Co-existence Security Overview
    BCP for Filtering ICMPv6 Messages in Firewalls
    Operational Experience in IPv6 Network
    Renumbering: General problem statement, Prior art/tools, Backbone renumbering and BGP issues, SOHO
    IPv6 Renumbering: Enterprise Tests Overview
    Router renumbering protocol, Gap Analysis