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
-Teredo:
„ 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)
-draft-ietf-v6ops-natpt-to-exprmntl
-draft-ietf-v6ops-vlan-usage
Jim Bound - IPv6 Enterprise Network Analysis
draft-ietf-v6ops-ent-analysis-03.txt
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
draft-ietf-v6ops-nap-01.txt
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
draft-ietf-v6ops-security-overview-02.txt
Status
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)
Motivation
„ 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
Comments:
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
draft-ietf-v6ops-ipsec-tunnels-00.txt
„ 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
draft-ietf-v6ops-bb-deployment-scenarios-03.txt
Goals:
„ Cover different broadband technology (Cable, DSL, Ethernet, Wireless and PLC/Broadband Power line)
„ Provide detailed IPv6 deployment issues and solutions
Updates:
„ 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
Comments:
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-Franois Mule and take into account their inputs.
Jordi Palet - Distributed Security Framework
draft-vives-v6ops-distributed-security-framework-00.txt
Motivation
„ 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
Conclusions
„ 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
Observations
„ 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
Comments:
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.
|
