IPv6 Operations WG
Monday, November 6 at 0900-1130

The meeting was opened with a description of the agenda, including a discussion
on what advice should be given to the ISPs regarding address allocations and
filtering.

NAT-PT:

Alain Durand requested comments on ongoing work on a replacement for NAT-PT,
in the context of an IMS network.   He reported that some IDs will be posted soon.
Jonne Soininen, Nokia:  3GPP has done some work on this, and used a media gateway, but we can look at your work.
??:  Is there a problem statement for this?
Fred: Please discuss with Alain offline.

There was then a review of document status, as listed at http://tools.ietf.org/wg/v6ops/.
It was noted that per Dave Kessens, NAT-PT cannot be moved to Experimental, only to Historic.
Two drafts are in the RFC editor queue, namely the broadband scenarios (v05) and IPv6 on by default assumption (v04) texts. Three other drafts are in review with the IESG at this point and are awaiting updated documents.

The v6ops session presentations are available online at:
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
Notes on presentations themselves are thus not in the minutes.

There was then discussion of seven IDs, five approaching WGLC, and two ongoing items.

Drafts approaching Last Call (5 drafts):

** IPv6 Deployment Scenarios in 802.16(e) Networks
draft-ietf-v6ops-802-16-deployment-scenarios-01

Some small updates have been made on the draft describing IPv6 WiMAX scenarios,
after discussion with 16ng people.

Fred: how many have looked at this?   <2 hands>   OK, I would like to see more review.
Alain:  the draft is good.   One thing is that there are similarities with cable so you might want to extract this to a separate document for point to point vs shared media, especially for multicast.   Secondly, a lot of WiMAX knowledge is assumed in the text, so it's hard to assess the reasons for decisions you have made.  Some more background would be helpful.
Fred: any other comments?  <none>  
Dave Thaler: Will be some discussion at 16ng this week that may affect the draft.
Fred: So we want review from MIPv6 and 16ng.  We want comments like these in WGLC.  Alain please take up your comments with authors.
Fred: Will open WGLC.

Additionally, it was noted that 16ng and mip6 are doing related work, so reviews will be requested from them prior to the initiation of the working group last call.

** Using IPsec to Secure IPv6-in-IPv4 Tunnels
draft-ietf-v6ops-ipsec-tunnels-03

The draft completed WGLC in Aug 2005 but has had IPsec review since then, leading to omission of tunnel mode leading to the 03 version with only transport mode, with
tunnel mode in an appendix (mainly for MOBIKE).

Alain: is this document applicable for IPv4 over IPv6 tunnels?
Richard: no.  That's not the problem we're working on.
Richard: transport mode is the simpler method, the only advantage for tunnel mode is in the mobile area.
Fred: well, tunnel mode is heavily used
Richard: we have Protocol 41 tunnels still, just not IPsec tunnels.   Most people have probably not thought about the mixed mode cases.    
DaveT: the difference is only in key negotiation, the packets on the wire are identical.  I agree with the recommendation being simpler.  I also think IPv4 in IPv6 should be covered.
Richard: it's late in the draft's life to add that now, the original problem was defined 2 years ago.
DaveT: it wouldn't change it significantly.
Alain: it would help the softwires WG to have the IPv4 in IPv6 case included, so we can refer to this text rather than writing new material.
Richard: who will add the text and think about it?
DaveT: IPsec was defined in a way that's independent of IPv4 or IPv6, so arguments for one should apply to the other.
Richard: this may reopen the AH can of worms.   AH is a may in RFC4301. 
Fred: how much work is it to add Alain's request?
Richard: it touches the text in a lot of little places, we'd need to check paragraph by paragraph.  But it might not be hard.   
Fred: I will open WGLC and this topic can be discussed there.

** IPv6 Unicast Address Assignment Considerations
draft-ietf-v6ops-addcon-02

The main change in the draft was adding more detail in the ISP case study.

Fred: who has reviewed the document? <1 hand!>
Fred: we will open a WGLC in December, please read the document and comment.

** IPv6 Campus Transition Scenario Description and Analysis
draft-ietf-v6ops-campus-transition-00

Few people read the draft in the room (+- 6 people).
Brian Carpenter: concerns that document is written too positive on IPv6.
Suggestion to have it reviewed by people from IPv4 community
WGLC to avoid IESG complications when being submitted (??)
WGLC?

** IPv6 Implications for Network Scanning
draft-ietf-v6ops-scanning-implications-01

Presentation of the slides
Eric N: Question if this paper written for operational people. <yes>.  Suggestion
for DHC server implementors to support random IP allocations in a pool rather than sequential.
No other comments
Fred: text is ready for last call. Document support is requested.
Remote comment (DK (Dieter Koch)): could discourage reverse DNS usage.  Suggests dnsop WG review.
Fred will open a WGLC because the text is referred to by two drafts in the IESG queue. Additionally, dnsop, dnsext, and dhcwg will be asked to review the document, as it makes comments that relate to their work.

Ongoing Work (2 drafts):

** Things to thinkabout when Renumbering an IPv6 network
draft-chown-v6ops-renumber-thinkabout-05

Alain D: Is this draft specific to IPv6?
Tim: Item is that PI is not available for many networks
Alain: Still, the problems between IPv4 and IPv6 are similar
Tim: But some mechanisms between IPv4 and IPv6 are different, for example on multi-addressing and RFC3484.   Also IPv4 networks often use NAT to avoid renumbering.
Bob Hinden: suggest to answer the question from Alain in the document
Fred: Considers this as being part of v6ops, until decided to take this
elsewhere

** Problem Statement of Default Address Selection in Multi-prefix Environment: Operational Issues of RFC3484 Default Rules
draft-arifumi-v6ops-addr-select-ps-01

Fred: v6ops is precluded from doing protocol work, so it should be in DHC, but DHC thinks it's a v6ops work item.   The compromise is that the requirements should be done in v6ops, and the solution done in DHC.    We should also see if there are other solutions.
Dave Thaler: I don't see an issue raised at IETF66 included here, i.e. the difference between source and destination address selection with multiple interfaces.    Destination selection is more complicated with two interfaces, since it decides the interface, and the policy may be fetched via the interfaces.
Alain:  It depends if the two interfaces are in the same administrative domain.
Dave Thaler: Yes.   Only a problem if you get different answers over different interfaces.
Arifumi:   The multi interface environment is not our target, we are aiming at residential or enterprise network, i.e. normal users.
Fred: What's a normal user?   They might have complex requirements.
Iljitsch: Isn't whether DHC is the right method something that follows from requirements, not to be decided now?
Fred: Yes.
Alain: There is some discussion on 3484 as to which types of address should be preferred, so we need a mechanism to propagate those choices.    But these may not be best chosen at the box level, it may be application dependent for example.    We need to have a policy that captures all those environments, not just prefixes.
Fred: So you're questioning if 3484 is the right approach for prefix selection?
Ralph: Can we use 3484 to describe any particular set of policies for a specific host, can we describe different policies for different hosts, and get the policies to specific hosts?  
Alain: 3484 has a prefix table, but we also need to have a mechanism to change switches
Shin Miyakawa: Do we need to consider multi-prefix in general?   Maybe we need an upgrade to node requirements
Dave Thaler: Some things you want to configure are outside the scope of 3484, and there should be some way to change things included in 3484 that are not part of the policy table.  There may be issues over who is authoritative, e.g.  a user may want 3041 addresses, but an ISP may not want to allow this.  So there may be different sets of solutions, so we should have two documents, and remove destination address selection here,
Arifumi: Application based selection is another issue.  Would need some API.   Do we really need to update an Informational node requirements RFC?
Alain: I agree with Dave's comments, but not the solution.   We need to describe a policy, maybe XML, and then how we distribute it.
Ralph: Is there a consistent description of he requirements, even as an English language algorithm before any XML is used?
Fred:  Should we bring the requirements document in as a WG item? <many hands>
Fred: OK.
Bob Hinden: We need to figure out that data that needs to be managed in the device.   There are many ways to configure a device, the important thing is to identify the data and how its structured, rather than how it's put on the device.
Dave Thaler: 3484 does that currently, good or bad, as a policy table and 'other parameters'.  So do we agree or disagree with that?
Bob Hinden: I'm assuming there's more stuff than what's in 3484.
Dave Thaler: Not sure that's true.
Alain: Recent discussions on the v6ops list show that 3484 updates are required.
Fred: Where will 3484 updates occur?   We assume ipv6 WG
Fred: OK, so post as an IETF document.  Let's focus on getting the problem well defined.

Open discussion:

The fundamental question being asked is what the IETF would recommend to 
the operators and registries regarding address allocation and filtering 
in the presence of IPv6 multihoming. This will in turn affect 
draft-ietf-v6ops-routing-guidelines and may result in other documents.

Fred: We need to make address allocation and use scalable.  Right now it isn't.   What we're looking at here is the question of scalability, and how to answer Marla's request for guidance.

Dave Meyer presented a summary of the IAB Routing and Addressing Workshop 
held recently in Amsterdam.  The key driver for the workshop was the serious
scaling problems being faced, and the operators believing that no current IETF
solution is appropriate.    So the workshop objectives were to understand the problems being faced and to inform the IETF on these.   

Scalability of routing is seen as an urgent problem, e.g. FIB memories, dynamics on the RIB, along with requirements that include avoiding provider lock, supporting TE, and offering multihoming.  The overloading of IP addresses with locator and identifier is a problem.  And these problems are urgent (though there is no 'hit the wall' date, things will just get more expensive).  However the workshop showed that there's an enthusiasm to solve the problems.   The report will be available soon.   What is needed now is engagement by the community.

Alain: How urgent is urgent?
DaveM: At some point we'll hit the unacceptable price points, if we don't act.  That's what we want to avoid.   

Vince Fuller then presented on scaling issues with routing and multihoming.  The main problem is that addresses are both locators and identifiers, and a single numbering space cannot support both needs.  A 'what if we do nothing' projection was made, and the results indicated exponential or quadratic growth.   For just IPv4, that's 370K routes in 5 years, churn up to 2.8M/1.8M updates/withdrawals per day and growth from 30% to 120% CPU use for a 1.5GHz CPU.  It's worse when you include IPv6 route handling as well; with IPv6 dual-stack, the Tier 1 view will raise to 381K-561K routes (from 249K to 349K IPv4 routes).   It is unlikely to actually double due to efficiencies in IPv6 allocations.   It is also felt that today's solutions won't work: PA only for IPv6 (no multihoming), PI for all (doesn't scale), geo/metro/exchange addressing (requires regulatory changes), shim6 (no-one wants it).   It seems that an id/loc solution is required, and should be progressed now (within one year) to be deployed within 5-7 years.

Fred: we're out of time.  I'll skip my talks but we'll run Marla's.

Marla Azinger presented a set of solutions that could be used, but stated that a solution is needed today, and the right solution needed for the future, as soon as possible.   She requested feedback on a working document on issues.

Fred: No time left, will take discussion to the list.