2.4.13 IPv6 Operations (v6ops)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. 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-09-20

Chair(s):

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

Internet-Drafts:

  • draft-ietf-v6ops-onlinkassumption-03.txt
  • draft-ietf-v6ops-ent-analysis-03.txt
  • draft-ietf-v6ops-natpt-to-exprmntl-03.txt
  • draft-ietf-v6ops-bb-deployment-scenarios-04.txt
  • draft-ietf-v6ops-nap-02.txt
  • draft-ietf-v6ops-security-overview-03.txt
  • draft-ietf-v6ops-ipsec-tunnels-01.txt
  • draft-ietf-v6ops-vlan-usage-00.txt
  • draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt

    Request For Comments:

    RFCStatusTitle
    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
    RFC4192 I Procedures for Renumbering an IPv6 Network without a Flag Day
    RFC4213 Standard Basic Transition Mechanisms for IPv6 Hosts and Routers
    RFC4215 I Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks

    Current Meeting Report

     
    v6ops minutes

Note taker: Alain Durand 

Agenda 

  short discussions, 4 presentations 


Status 

  docs sent to IESG: 

	draft-ietf-v6ops-onlinksuumption, draft-ietf-v6ops-vlan-usage, draft-ietf-v6ops-natpt-to-experimental 
  experiment: use someone that was an ex-RFC editor to help fine tune the document 

  5 documents that have been through wg last call and need decision on what to do 

  other documents need discussions 


Short discussions: 

  Draft-ietf-v6ops-ipsec-tunnel 

	7 people read it. Few says ready to go. 

	Kurtis: not much support. By default , it need more support to go to IESG. 

	Call again: 9 for sending the doc to IESG 

	Merike: ESP/null encryption vs AH... Question the decision to make ESP/null a MUST 
	and AH a may.... Issue: threats against the header (not covered by ESP/null) 

	Graveman: ESP is mandatory is 2401 bis. No issues where there is a real attack on the 
	header. 

	Fred: configuration guidance or implementation guidance in the draft? 

	Pekka: configuration guidance 

	Fred: Merike may have a legitimate concern, but this is a comment on 2401bis, 
	this issue should be brought in the security community and then v6ops will act on this 
	if need be. 

	Thaler: clarification: some extension headers may be attacked by man in the middle. 

	Pekka: we are talking about v4 encaps, we may not care about them 

	Fred: some people do care about v4 options... 

	Chairs: conclusion: the doc is ready to go 


  Draft-ietf-v6ops-security-overview 

	2 people read the update 

	Chair is going to take them to the list and ask people 


Draft-ietf-v6ops-nap 

	20 people read it. 

	Ready to go to IESG: most says it is ready to go, few don't care 


BB-deployment 

	In Paris, docsis community said it was going to change things 
	and was going to produce comment. No comments received yet. 

	Alain: clarification on the docsis process, need to reach internal milestone 
	before issuing public statement, that milestone was not met before the 
	draft cut-off date. 

	Who read it: 10 doc 

	Ready to go (about the docsis case) 7 

	Prefer to hold/no opinion: 2 


Enterprise analysis doc 

	Remaining issue: the use of the term DSTM 

	Fred: DSTM; reference to an experimental doc, dual stack: generic term 

	IETF should not recommend an experimental tool 

	Jim Bound: DSTM is a large effort outside of IETF. 
	More docs will be submitted to experimental track. 

	There is a precedent in IETF to refer DSTM (unmanaged doc) 

	Pekka's has lost the debate on the list (no one supported him) 

	Fred: RFC2026 says an experimental document is not done, you are not allowed to 
	make recommendation in PS doc to tools in experimental doc. 

	Jim: Tim Chown proposed to change wording to say "DSTM is an example..." 

	Kurtis: This would be ok 

	Fred: ok 

	David Kessens: AD hat on. No problem making an example. 

	Question: does the wg think is is a "good" example? 

	Pekka: DSTM spec is not enough to describe what need to be implement... 
	The doc should say which exact feature requires DSTM? 

	Fred: would referencing DSTM among other examples be ok? 

	Answer: yes 

	Who read it: lots 

	Ready to go: lots. Not ready: 1 (pekka) 

	Pekka: issue with critical infrastructure appendix 

	Jim: authors are not willing to remove it 

	Action Item: Jim to send text to the list about DSTM as example, 
	and then the chairs will issue a wg last call. 


Fred will send mail to the list to get comments on: 

	Draft-kim-v6ops-ipv6overwibro-issues and 

	Draft-lee-v6ops-natpt-mobility. 


Draft-blanchet-v6ops-routing-guidelines 

	Alain: not enough delta from what was made in NGtrans for the 6bone. 
	This would be better handled in the RIPE, NANOG, APRICOT community 

	Pekka: IETF had a mandate to make recommendation for the 6bone experiment, 

	IETF has no mandate for the larger community 

	Jordi: this would be useful in v6ops. 


Draft-baker-v6ops-end2end 

	Purpose was to generate discussion, not much discussion happened... 

	Fred: RFC1958 connectivity has is own reward. This gets broken by 
	IPv6-only / IPv4-only networks. 
	Question: is this an issue or not? 

	Pekka: agree with concerns, issues will come up. 
	-00 not concrete enough to reach the audience 

	Tony Hain: the issue is when the infrastructure gets fragmented 

	Elwyn Davies: 

	Alain: this goes back from the original IPv6 design decision to make IPv6 
	not backward compatible. You have the choice: dual stack, NAT or live 
	with fragmentation. It will be good to document what breaks if you decide 
	to fragment the infrastructure 

	Fred: summary: a document saying stupid things are stupid will be good 


Port scanning (Stig ) 

	Overview of the draft 

	Can we adopt this as wg item? 

	Pekka: useful work. Concern: wg has 5-10 active docs, not much activity happening, 

	wg should focus on current docs first. 

	Dave Thaler: this is about address scan, not port scan. 

	12 people read the current doc 

	About same think the doc is sound, 5 people are willing to contribute 
	Chairs: ok to accept as wg doc 


6 in 4 versus 6 over 4 (Jordi Palet) 

	Issue: confusion between 6in4, 6over4, ipv6 in ipv4,... 

	Draft: clarify that x in y means encapsulation, 
	x over 4 is referencing a particular transition document 

	Hesham: an ietf doc will not help people who do not read ietf doc 

	Kurtis: (chair hat off) echo Hesham concern 

	Tony: it is going to be d 

	Alain: the real issue is confusion with 6to4, people think is is NAT Ipv6 to IPv4 

	X over Y is a very generic terminology. Don't change it, revisit the 6over4 document 

	Pekka: echo Alain's comment 

	Brian Carpenter: (author of 6over4) the genius is out of the bottle, difficult to fix it 

	Fred: the right way to handle may be an article in wickopedia 

	Who is in favor of wickopedia: all room. Who in favor of IETF doc: zero 


IP in IP tunnel MTU assurance (Fred Templin) 

	Draft presentation 

		Tunnel mechanisms have no means of assuring tunnel MTU 

		Issue: IPv4 fragmentation is bad, IPv4 path MTU is not reliable (NAT, Firewall) 

		List of requirements 


	Dave Thaler: assurance might be too strong a word, we have no assurance 
	on Ethernet for example, this is best effort. 

	Fred: best effort is what is meant, need to define the terminology 

	Dave Thaler: this should be reviewed by the pmtud wg 

	Pekka: see some potential problems, maybe not as bad as author sees. 

	Would be interested in working on this if this was done in the venue that 
	will work on the solution 

	Fred: what would be the correct venue? Pmtud? 

	Pekka: maybe, need to look again at their charter 

	Dave Thaler: pmtud is the right place with the right expertise, 
	may require a charter update. Documenting the issue in v6ops 
	(and separating the requirement) is the right thing to do 

	Alain: the purpose of v6ops is to document operational issues, 
	so this document belongs here 

	Thomas Narten: Softwire may be the right place to fix the problem 
	pmtud is focusing on TCP, this is a generic tunneling problem, 
	so softwire might be a better place. 

	Fred: go talk to chairs of pmtud and chairs of softwire if they want to take it. 
	If this remains an issue, go back to v6ops and we will see with AD what to do 


BCP for filtering ICMPv6 messages (Elwyn Davies) 

	Updated as wg draft, include suggestion received 

	To do list: add example of firewall rules 

	Fred: look for comment of the list, then will issue a wg last call.

    Slides

    Agenda
    Requirements for IP-in-IP Tunnel MTU Assurance
    IPv6 Transition/Co-existence Security Overview
    BCP for Filtering ICMPv6 Messages in Firewalls