Softwires Working Group Interim Meeting Minutes

February 23-24, 2006, China University - Hong Kong

Chairs: Alain Durand <alain_durand@cable.comcast.com> and David Ward <dward@cisco.com>

Scribe: Spencer Dawkins <spencer@mcsr-labs.org>, David also contributed notes.

Many, many thanks to our hosts CUHK and CERNET (Tsinghua University, Beijing).

Attendees:

1. Alain Durand <alain_durand@cable.comcast.com>
2. David Ward <dward@cisco.com>
3. Mark Townsley <townsley@cisco.com>
4. Bill Storer <bstorer@cisco.com>
5. Maria A. Dos Santos <mariados@cisco.com>
6. Chris Metz <chmetz@cisco.com>
7. Laurent Toutain <laurent.toutain@irisa.fr>
8. Florent Parent (Florent.Parent@hexago.com)
9. Simon Barber (sbarber@cisco.com)
10. Jordi Palet Martinez <jordi.palet@consulintel.es>
11. Spencer Dawkins <spencer@mcsr-labs.org>
12. Ole Troan <ot@cisco.com>
13. Shu Yamamoto <sy-yamamoto@cn.kddilabs.jp>
14. Tetsuya Murakami <rmurakam@cisco.com>
15. Jean-Francois Tremblay <tremblay@hexago.com>
16. Carl Williams <carlw@mcsr-labs.org>
17. Peter Arberg <parberg@redback.com>
18. Yong Cui <cuiyong@tsinghua.edu.cn>
19. Mingwei Xu <xmw@csnet1.cs.tsinghua.edu.cn>
20. Jianping Wu <jianping@cernet.edu.cn>
21. Andy Li <ali@cisco.com>

Consensus Summary:

1. H&S scenario: L2TPv2 chosen as the immediate solution, L2TPv3 in phase 2
2. Mesh scneario: Conjoined effort for extensions to MPBGP based on work presented by Chris Metz and Yong Cui
3. Deliverables below to be produced

Deliverables (docs to be made WG docs):

General docs:

(The names below lists the suggested authors by the WG chairs and interim meeting participants. All are welcome to participate)

1. Security analysis (delivered July 2006 IETF) - Florent, Shu, Carl
2. Radius accting (delivered July 2006 IETF) - Laurent, Bruno

Mesh:

1. Framework doc using MPBGP (delivered July 2006 IETF) - Chris, Yong
2. Multicast draft  (delivered March 2006 IETF) - Greg, Dino, Jiaping Wu, Xing Li
3. Extensions (delivered July, Nov 2006 IETF)
   1. tunnel-safi
   2. tunnel connector
   3. softwires attributes

Hub and Spoke:

1. Phase 1 Framework doc using L2TPv2 (delivered July 2006 IETF) - Jean-Francois, Bill, Laurent, Alice, Jordi
2. Phase 2 Framework doc using L2TPv3 (requirements and progress discussed at post-July '06 interim meeting, delivered Nov 2006 IETF)
3. Extensions (discussed next interim meeting, delivered Nov '06 IETF, March '07 IETF)
   1. DHCP

Proposed Agenda for Dallas Meeting - David and Alain

1. Report from the Interim Meeting
2. Hubs and Spokes: Phase One L2TPv2 as selection and framework overview
3. Mesh: BGP-MP as selection and framework overview
4. General documents the working group needs to take on
5. Next Steps and Phase 2

NOTES:

Thursday

Welcome & introduction - David and Alain

• Focus is on solving the problems as stated in the problem statement draft, in this meeting.
• Added short summary on Problem Statement draft to agenda
• Will use decision criteria posted on website for solution selection
• Later in the meeting, we noted that this is the first official IETF activity in China!
  

Discussion of Decision Criteria - Alain

NOTE: matrix used for decision criteria is hanging off the meeting page and the one filled in during the meeting is linked at the end of this page

• Time-to-market is implicit in non-technical requirements
• Scoring for each criteria will be 100-to-0 (some choices may be binary)
• Carl asked about technologies that have been used, but not in softwires, or even in tunneled solutions - does this count as "deployed"? Partial credit is OK as we are using a "range."
• "PDU" under security = Must support payload encryption and authentication, but may be turned off. Within building blocks is OK, just show how the building blocks work together.
• "L2 and L3 connectivity"? This is whether a solution requires L2 in order to work, for example.
• Is "user authentication" the same as "integrated with deployed AAA?" We'll know more when we talk more.
• Mutual authentication isn't in the criteria, either
• We will leave the criteria as "MUSTs" from the problem statement for now.

Status of Problem Statement - Spencer

Preso here

Problem Statement here

Spencer believes that all of the mailing list traffic has been captured in the draft, with one exception - a note that we need to mention Maximum Transmission Unit (MTU) considerations. The same note also mentioned Robust Header Compression (ROHC), but Spencer doesn't think ROHC will be a problem for Softwires.

A lot of people have sent a lot of e-mail comments on the draft. That's good.

Spencer believes that all of the people who have sent detailed comments on the draft have been acknowledged in the draft - if Spencer has missed anyone, it wasn't intentional, so please let Spencer know.

Spencer would like guidance on next steps for the draft - previous versions had a "compare and contrast" section that has now been deleted. Is it necessary to do a detailed analysis in the problem statement? Maybe not, Spencer is just asking - the larger question is, are there requirements that have been identified for one scenario and have not been analyzed for the other scenario? Resolution was that other authors have completed a review and that the analysis  and results are "good enough."

Expect to WGLC this draft very soon (probably immediately after Dallas IETF).

Session 1 - Service Provider deployments for Hubs and Spokes

Shu Yamamoto, KDDI Hubs and Spoke

Preso here

• Trial for home users, IPv4 over IPv6 tunnels, currently have 1000 tunnels total activated throughout Japan, serving 130,000 users
• Trial will end at end of March 2006
• Provides connectivity from user's PC to home network, from user's cell phone to home network
• Requirement is to avoid complex tunnel setup for home users
• Do not require static IPv4 address
• Tunnel health monitoring is mandatory
• NAT traversal is mandatory
• Coordination with AAA server is desirable
• Using TSP in this environment, with one server and 1000 clients
• Any services that are pure IPv6-to-IPv6? So far, no
• Any IPv6 over IPv4? So far, no.
• Home devices are dual-stack, home network is IPv6. Therefore, V6 over V4. One end is the cell phone which is V4 but, translated into V6.
• Are home users aware of IPv6? No, addressing is automatically configured, so they don't see IPv6 addresses
• Devices ARE aware of IPv6, just not users. E.g. Panasonic cameras are IPv6-only and this sort of device is what is needed to be supported.
• Not completely IPv6 end-to-end, but getting data past NATs, etc. without having to open ports on the NAT. Still useful, though.
  

Jean-Francois Trembley, Freenet6

Preso here

• Has been operational since Feb 1999, using TSP since May 2001.
• Real deployment in February 2003, NAT traversal in September 2004 with "production" (non-6Bone) IPv6 addresses
• Transferred to Teleglobe POP for better performance and routing
• On old servers - about 112,000 unique endpoints, about 4500 active tunnels at any given time. Traffic is 1.5Mbps Total.
• With new servers - about 16,000 registered users, 3737 prefixes, 9239 tunnels, about half of the tunnels with NAT traversal
• Using one box now - what's the bottleneck? could be bandwidth, forwarding rate, or number of users, depends on application (e.g. IPTV has different bottleneck from general Internet access)
• Expect to support 10,000 tunnels simultaneously given enough Hardware (control and forwarding plane)

Carl Willaims and Florent Parent, Security Review of Softwire

Preso here

• Think there is motivation for Softwire Security draft beyond what's in Problem Statement, L2TP IPSec draft, etc.
• Softwire Problem Statement has user authentication as MUST, but not mutual (should), and user authentication may be out-of-band. User authentication will be intra-provider, with filtering (requires controlled environment).
• L2TP using IPv6 has comparable security requirements
• We get IPSec NAT traversal from existing specs if SOAF is IPv4
• Is IKE "deployed enough" for Softwires with time-to-market constraints?
• What is relationship between Softwires authentication and IKE authentication?
• Mark is really happy that we have a threat analysis now (we'll need this at document approval time anyway, and we'll have it for deployment advice as well).
• Were threats just KDDI concerns? No, KDDI was starting point, but we looked at other literature as well
• Is failure detection a threat vector? Haven't thought about this yet, no. Could be attacked either way (is up, we're lying, it's down, we're lying).
  

Session 2: Hub & Spoke candidates 1 & 2

Jordi's ATS

Preso here

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-softwires-ats6-01.txt

• Jordi believes that ATS meets the requirements from the problem statement draft
• Concentrator discovery is "by other means" - may be another mechanism or manual configuration
• Includes liveness testing (NS in IPv6, PING in IPv4). Tunnels may be explicitly ENDed, or simply timed out if no END is received
• Can use IPv6 prefix delegation or ATS6 built-in mechanism
• Why must the MAC address be the link-local address? Because you can have multiple boxes behind NAT box - but this doesn't work anyway? It's just a design choice, made very early (and can't remember right now - may have been something like host changing its IP address). MAC isn't used for authentication, only for disambiguation - trying to separate location from name, but doesn't proposal reauthenticate when IP addresses change anyway? Which IP address changes (behind NAT or in front of NAT)? Some confusion about whether DHCP servers give the same IP address to the same MAC, but this is a SHOULD, not a MUST, and not obvious how this is implemented on home gateways, etc.
• Basic IPv6 tunnel addressing is automatic (from link locals), and global address is auto-configured
• Detects Proto-41 black holing and encapsulates into UDP instead of IPv4
• Can derive IPv4 addresses from IPv6 addresses, obtain via DHCPv4, or through ATS6 built-in mechanism.
• Handshake can be UDP or PPP (Mark said, "huh?")
• User ID is a 32-bit number? Yes. Also signature, etc. (which doesn't sound like a 32-bit number, either).
• Can be done peer-to-peer (so traffic does not go to SC), and could be done peer-to-peer with Teredo clients
• David - Pre-Auth realm isn't in the problem statement at all. Do you want to add it? Half the text in the draft is discussing Pre-Auth comparisons. Jordi: Yes, want to add, to accommodate unauthenticated/out of band authenticated users. No consensus on this point.
• IPv6 encapsulation is to support multicast.
• Compared with STEP proposals? Jordi isn't following STEP during last couple of years, so don't know details. Alain thinks it's similar.
  
• What is authentication mechanism? Everything is reused except signalling. Should support various mechanisms, whatever AAA says.
  
• Is there a shared secret with the SC? Assume user is registered somehow.
• Document does have choices left to be made (may not need three alternatives to do something, for example).
• Don't really care what authentication mechanism is used.
• How can a machine distinguish between a configured tunnel and a discovered tunnel?
• Is there any absolute dependency on ND?No, just need another way to figure out what addresses are.
• Routers will be accepting ICMP packets from a tunnel that doesn't exist yet - isn't this a forced change to silicon? Need to look at this more closely (think the same issue applies to 6to4, and maybe even Teredo. But this looks like a router has to inspect ICMP packets pretty deeply.
• Group discusses that issue is that packets have to be inspected and perhaps delivered for tunnels that don't exist yet. Large security hole and different semantics than normal.
  

• David: Document has many TBDs - is it complete? "No known issues", but defining new ICMP messages isn't reflected in a score of 98...
  
• Not sure how to score "implemented", because several protocols are being reused in different context. Score based on "ISPs have experiemented with all the components TOGETHER".
• Not sure how many boxes to assume for "scalability" scoring - this is very box-scaling-specific. "Scale to the limit of the box?"
• Will update PDU answer based on discussion this morning.
• Keepalive is for endpoint failure detection, not path failure detection? But Jordi assumes that keepalive is sufficient. PING and TRACEROUTE inside the tunnel. Who actually sends ICMP keepalives? SI, inside the initiator. David doesn't understand (from the draft) how this mechanism begins (and neither does Peter).
• Mark - would like to see servers initiating keepalives, not clients, since there are big issues if a million users all ping, decide the server is dead, and tear down/set up new tunnels.
• Mark - rate-adaptive failure detection protocol would be really nice...
  

Tunnel Setup Protocol (TSP) - Jean-Francois Tremblay and Florent Parent

Preso here

• Signaling protocol, XML-based, SASL based for user authentication, uses existing tunnel interfaces on dual-stack nodes.
• Client configures its interface and routing table after receiving tunnel parameters
• Has been published in NGTRANS, V6OPS (version 2.0), now published as version 3.0. Only as individual submission on informational track.
• No draft MIB for this proposal (just supporting the tunnel MIB meets many requirements
• No security related drafts for BCP or encryption.
• Not touching multipoint in this proposal. If we support IPv6-in-IPv6, we don't need to.
• Draytek, Panasonic, and NEC (among others, but "others" are under NDA) are implementing now on client side. Some non-commercial implementations exist as well.
• Deployed in KDDI, AT&T, and Wanadoo (so far) - US DoD may also deploy this.
• We do have concerns about network synchronization with large number of clients.
• DSTM is mentioning TSP as its setup protocol.
• DHCPv6 would work over these tunnels, but we've already exhanged most of the required information already.
• Includes TSP redirection, so can do own loadbalancing and support multiple tunnel brokers. Have tested 50,000 tunnels on one broker, assuming that 64K would be a hard limit based on tyical OS  limitations.
• Some concerns about redirection from authenticated load balancing box - "redirect to rogue tunnel broker", but presume you can't authenticate the rogue tunnel broker, so this at least gets cought by the client.
• Concerns about hardware support for XML (variable-length fields), but there are advantages (easy to read for debugging). It's a tradeoff.
• Use something besides MD-5? Also PASS-DSS (plus plain and unauthenticated) - SASL handles the extension, so don't have to solve this problem in TSP.
• Tunnel setup installs a default route. Routing is then done according to the routing table. Some discussion of relationship between multiple tunnels and multihoming, but we're assuiming this is "multihoming by address family", with only one interface in each AF.
• Move to binary for TSP - is this at all realistic? Would lose time-to-market advantage.
• Was XML problematic for finding a home for TSP standardization at all?
• Signaling and tunneled traffic do not follow same path. therefore have to have signaling that broker and path is down.
• Failure detection not adaptive

Laurent's Point6

Preso here

• Using L2TP because it is well-standardized and complete (includes NAT traversal over UDP, etc.).
• PPP/DHCPv6 interaction is tricky - need to document this?
• Need to study prefix delegation (linked to IPv4 softwire concentrator discovery).
• RADIUS doesn't include IPv4/IPv6 distinction - do the work here, or in RADEXT?
• Shares "secret" with lots of people, so this isn't a "shared secret".
• How is tunnel tied to DHCP? This is an implementation issue, when we get DHCP request with unknown device ID, you cache and return the values consistently when queries come from that same device ID. This assumes that one PE gets all the traffic - if you have multiple PEs, this may not work, but it's important to make it work because the alternative is /48s or even /60s in the routing table.
  

Session 4 hub & spoke candidates

Bill Storer, Maria Alice Dos Santos, on L2TPv2, L2TPv3

Preso here

References {

RFC 2661 - L2TPv2
RFC 3931- L2TPv3
draft-ietf-pwe3-vccv-07.txt - VCCV for L2TPv3
draft-ietf-l2tpext-l2tp-ppp-03.txt - PPP over L2TPv3
draft-ietf-l2tpext-pwe3-ip-01 - IP PW Type
RFC 2867 - RADIUS Accounting Modifications for Tunnel Protocol Support
RFC 3371 - L2TPv2 MIB
RFC 3193 - Securing L2TP using IPsec
RFC 3948 - UDP Encapsulation of IPsec ESP Packets

}

• Both L2TPv2 and L2TPv3 meet stated problem requirements.
  
• Can authenticate tunnel requester, user inside the tunnel, or both simultaneously.
• L2TPv2 provides tunnel keepalive, accounting, and MIB support
• L2TPv3 provides VCCV support for diagnostic and fault detection capabilities at the session level. This provides ongoing control, not just at setup time. Rate is adaptive (thank you, Dave, for mentioning this)
• L2TP is in-band, so no data = tunnel setup failure
• Supporting multicast transparently (PIM or IGMP in the tunnel transparently)
• L2TP and IPsec - requires support for transport mode and ESP for this functionality
• L2TPv2 is providing tunneling services today with millions of tunnels. L2TPv3 should be even more efficient for softwires.
• Could use L2TPv2 or L2TPv3. L2TPv2 meets requirements with one clarification ("try another directed" message includes an IPv4 address). L2TPv3 is a superset for scalability, security, flexibility, and IPv6 support - it's just not as widely used today.
• What about v6inv6? wouldn't matter.
• Proposal is for L2TPv2 as immediate solution and L2TPv3 as second phase solution
• L2TPV2 is available and widely deployed today in V6 in V4 scenarios. Both client and server.
• Windows Longhorn is shipping next Christmas - is Microsoft shipping anything for XP? Jordi says, "no".
• How many packets to set up session? Bill knows but doesn't have the numbers right now; Dave points out that we don't have a number of packets requirement, we have an elapsed time requirement, so we need to focus there instead.
• Can we bypass RADIUS altogether (Cable networks use DOCSIS, for example)? Could use tunnel authentication using host name as effective user name, but we haven't built this yet. Would require that every session in the tunnel has the same security, but that's OK for softwires (especially if there is only one session in most tunnels). L2TPv3 is in the DOCSIS 3.0 standard. Need to think about more than just RADIUS.
• L2TPv3 also adds ability to run over raw IP and bypass UDP and PPP encapsulation. Would need to add a few new AVPs to make this work. Or - Don't need to add this stuff because IPv6 "does it for you".
• Could scrap PPP from IPv4 as well - this could be done in any tunneling solution, not unique to what's being discussed here.
• If IPv6 address is global, that's sufficient.
• Are we inventing new mechanisms or trying to reuse existing stuff from hardwires? Group agrees we shouldn't be. If we're reusing, why aren't we using DNS name resolvers, etc.?
• If you have PPP, that's great, but not everyone has PPP in their networks (and still need to do softwires).
• Group agreed new AVPs to act like PPP not necessary for L2TPv3 solution.
• L2TPv3 discussion is actually the second phase of a solution - L2TPv2 is the proposed first phase.
• Using an L2TPv3 "cookie" associated with the session - used to avoid blink insertion attacks.
• What is the price of bypassing L2TPv2 entirely? Just time to market ("just") - Microsoft has L2TPv2 support, not L2TPv3 support. Routers also have L2TPv2, including freeware.
• Status of normative dependencies in this proposals? What's experimental or informational? Mark says RFCs are standards-track, with maybe one or two exceptions.
• Is ESP mandatory? No, but L2TPv3 has ESP as mandatory-to-implement anyway, and we need something like this to survive the security review during approval and publication.
• Jordi reported L2TP problems in hotels and hot spots that prevented successful tunnel setup 60 percent of the time.
  • This was just personal observation of what he observed years ago. Most likely due to early windows client

• Some discussion about what "commercially supported" means - for example, if it's possible to purchase support from a commercial company, that is fine.

Session 5 Mesh candidates

Solving the Softwire Mesh Problem - Chris Metz

Preso here

• IPv4 islands connected across an IPv6 core, and vice versa
• Need to provide "multi-AF route distribution"
• Need to encapsulate packets within another AF, and need to have AFBRs agree on what encapsulation is needed
• Problem looks a lot like L3VPN problem (perhaps solution should look a lot like L3VPN solution, as well)
• L3VPN uses multi-protocol BGP to distribute multi-AF routes
• Classic MPLS VPN solution is complete for IPv4 unicast, and has drafts for IPv6 and multicast
• Interoperability is well-known, scalability is BGP scalability, security is well-known (RFC 4111 for provider-provisioned VPNs)
• If backbone is NOT MPLS, this still works, either through nailed-up tunnels or extending BGP-4 to advertise IP tunnel reachability. Could use GRE, L2TPv3, IPSec (all have been deployed already).
• Using well-understood building blocks for this solution
• Mark - IP-in-IP seems impossible? No, it is very possible but it needs to be defined. Question from the  group if it should be the default.
• Need to extend BGP-MP to advertise softwire tunnel capabilities, encapsulation parameters, and preferences, advertise AF prefixes and associated softwires
• Can I learn my prefixes via IS-IS? No, because IS-IS doesn't run over IP.
• AFBR may support more than one softwire encapsulation type
• BGP4-MP simply distributes AF island prefixes along with other helpful BGP attributes
• Also need to distribute softwire tunnel IDs
• MP_REACH_NLRI adds "tunnel attributes are present" value= 64 (has been allocated by IANA)
• What is benefit of tunnel ID? Why can't we just learn next hops in "soft GREs?" Mostly so we can support more than one encapsulation type, etc. between two softwire terminations.
• Proposal could support global IPv6 multicast and VPN multicast
• Reuses code, deployment etc. from IPv4 VPNs.
• Conclusion - BGP-based VPNs are sufficient for Softwires, but need new attributes.
• Do Tunnel SAFI and Connector Attributes in Softwires, or in IDR? Belived that IDR expects to review a proposal, not do the work itself
• Mark is OK with doing the work here, but needs to be reviewed and last called for L2VPN and L3VPN as well. Also run past Security ADs for IPsec stuff, also needs to go to IDR because it touches BGP.
• Note that MPLS encap that is described needs to have fuller definition of signaling.
  

4over6 Transit using Encapsulation and BGP-MP extension - Yong Cui 

Preso here

• Proposed solution for mesh problem is data plane of PE routers, control plane of PE routers
• Encapsulation table maps from IPv4 destination edge networks (based on prefixes) to IPv6 address of VIF on egress router
• Believe a peering relationshop between AFBRs is appropriate, anyway.
• Could support multiple ASes but have not included this in the presentation/draft yet.
• How do you set up the configuration of telling what encapsulation to use? Is this hand-configured? It's actually specific to particular networks.
• Taking on multihoming across multiple provider backbones.
• OAM - accounting use still needs to be defined. Endpoint failure and path failure are detected using BCP mechanisms. MIB is also open ussue.
• Some discussion about using multiple encapsulations simultaneously - we think this would work, but it's silly. Do all PEs have to run the same encapsulation? Chris's proposal allows policy, but this proposal requires all peers to use one encapsulation type - we could use static configuration to support multiple encapsulation types in this proposal, too.
• Need to either change BGP to add capability advertisement or give up on multiple encapsulations.

• Has WG achieved room-consensus on using BGP for mesh? In this room, yes.
  
• Could we have a two-author design team for a single proposal? Do authors agree on differences (and need for those differences)? We believe we could use these proposal in a complementary way.
• Can we have a merged proposal presented in Dallas? Yes, but we will not have a draft due to amount of work we would have to do in the next four days.
• Mark - please pick one must-implement when there are multiple ways to do something that will work in the merged proposal. Doesn't have to be optimized, just has to work.

Comparison of two ideas here

Friday

Session 8: Meeting recap & analysis - David Ward

Here is a copy of the matrix the group filled out for all solutions. Note that 0-100 are numbers given by authors/presenters w/ minimal sanity checking by group.

• Would like to develop a framework document of Hubs and Spokes after Dallas.
• Optimized framework for multicast specification should be submitted next week, aiming for Last Call by July.
• Extension drafts will follow the framework documents, as quickly as possible (Last Call by November).
• Take security analysis as working group document.
• Take accounting requirements as working group document (overlaps with RADEXT) - need cross-working group review.
• Mark believes that adding milestones within charter does not require rechartering (between AD and WG chairs) as long as the milestones are within the scope of the charter.".
• All these meeting agreements are subject to list ratification, of course.
• TSP and L2TP solution authors believe that L2TPv2 could be phase one solution.
• Jordi concerned that the metrics aren't the right metrics - "time to market" isn't one horizon, and we haven't thought about reuse of our solution by 3GPP, etc. yet.
• Framework document will be written after Dallas meeting, after presenting results of the interim meeting, to be presented in July.
• Spencer - do we have to lockstep with the IETF plenary meetings? David - we actually need the time to write the text, we're not just waiting for an opportunity to present.
• Assume we have an interim meeting in September (between July IETF and November IETF). Possible to adopt a solution for phase two at the interim meeting.
• Are we having too many interim meetings? Mark says we're having a lot of interim meetings, but it's OK if we agree to work that way. It was agreed to work this way as we are making progress mainly during interim meetings.
• Jordi - why do we need two phases, if L2TPv2 is an adequate solution? Dave - time to market is critical, and we're behind what's being deployed. L2TP and TSP authors agree L2TPv3 is right solution for phase two, but has open issues for now.
• We still need to do SC discovery, etc. in phase two, and we don't have all the answers now.
• Phase two requires backward compatibility and we're doing L2TPv3 for phase two. L2TPv3 is BW compatible w/ L2TPv2
• Jordi agrees that L2TPv2 for Phase 1 and L2TPv3 for Phase 2 is correct path forward.
• Carl - agree that we are behind Hubs-and-Spokes deployment at DoD.
• Document author lists are not closed for the framework documents.
• Mesh and Hubs-and-Spokes frameworks are both needed by July. Phase two framework should be done in parallel with phase one framework - need to balance work on phase one with work on phase two, so we get phase one done.
• Does security document cover both mesh and hubs-and-spokes? Mostly hubs-and-spokes for now, need to do mesh. Will do one document for both scenarios. Can we do Last Call in July timeframe? This seems optimistic - shoot for November - but Mark needs a reasonably mature security analysis to advance the framework focuments. Expecting that phase two security analysis will be done in a separate document.
• Can we do accounting by July? Only if we can get RADEXT engaged at Dallas, but this should be doable.
• Want to see where July IETF will be held so we can pick a location for interim.
• Extension drafts (DHCP, autodiscovery, IP or PPP AVPs) are realistically Last Called in March of next year - need to coordinate with a lot of working groups (IDR, L2VPN, L3VPN, RADEXT, L2TP, etc.).
• Jordi - is it obvious that we need an interim meeting for phase two? Alain - We have a lot of details to work out on SC discovery, etc.
• Peter - why are we planning an interim meeting for phase two? Carl - we are behind deployment. Dave - we make infinitely more progress at interim meetings. No one sends anything to the list
• The group agreed (again) that developing a new provisioning model for softwires is a bad idea. Softwire provisioning should work just like for hardwires. What should be the requirement is that whatever provisioning mechanism is used for hardwires should also work on softwires. The softwires WG should not
  • define new mechanisms for IP address assignment
  • address block / prefix delegation
  • DNS discovery
  • the plethora of other information you want to pass between the ISP and the customer. (SMTP, NTP, POP servers... )
  • Softwires should just specify a new type of link and encapsulation. From an IPv4 or IPv6 perspective it should look like any other link type.

Further discussion summary after meeting "closed" but, everyone continued working in scenario groups

Hub & Spoke

Issues that were mentioned at some point about L2TP:

• Lack of implementations (mostly public ones) on Windows XP.
  • No L2TP interface available without IPsec.

L2TP was written to run separately from IPsec, though you have to change some  settings in the windows registry to make it happen. Information to the list  forthcoming.

NTT and AOL are examples of two companies that have successfully shipped and  deployed commercial L2TP clients for their users in the past or now. NNT for  IPv6, AOL was not.

There are at least two free or GPL L2TP clients for Linux, BSD, MacOS or any POSIX environment.

• No IPv6CP implementation
• No DHCPv6 client support

 

• For DSTM support, IPv4 prefix delegation is mandated for some  scenarios. DHCPv4 does not provide prefix delegation support.

This is outside the scope of the WG. As stated earlier in the day, the group agreed that softwires should be provisioned just like hardwires.

• It isn't clear at this point how to support IPv6 DNS in all  scenarios. A DHCPv6 client implementation may be required, since PPPv6 can't do it.

There is the same problem for hardwires, see RFC4339.

• Proper handling of MTU and fragmentation didn't seem to be covered in  the current documentation.

There is a lot of experience with MTU and fragmentation issues with L2TP. Here  is a writeup cisco did for their implementation:

http://www.cisco.com/warp/public/471/l2tp_mtu_tuning.html

This includes specifics for windows implementations as well, so could be generally useful.

MTU and tunneling is a generic problem. Anytime you encapsulate one packet in  another it is an issue, and the size of the tunnel header itself is not always  the biggest concern. Whether this breaks the MTU depends a great deal on the  average size of the packets being tunneled and what link-types they are being  tunneled onto (for example, if packets to be tunneled are largely 1500 bytes, 576, or 64 bytes, a small tunnel header is going to cause no less fragmentation than a large one).

There is a document from Pekka S. that discusses MTU fragmentation with  tunneling in general:

http://tools.ietf.org/id/draft-savola-mtufrag-network-tunneling

PWE3 has a document that discusses fragmentation, including when to fragment  before a packet enters the tunnel, when to fragment with IP, and when all else  fails how to fragment in the PW. This includes how to fragment within L2TPv2 and L2TPv3.

draft-ietf-pwe3-fragmentation-10.txt (Proposed Standard)

This document is in IESG Evaluation and on the Mar 2 agenda for advancement to PS.

Note that when PPP is used, MRU can be negotiated end to end. Further, if you  want to take the performance hit, PPP LFI (Link Fragmentation and Interleaving)  is well supported. This essentially uses MLPPP (so, an MRRU is negotiated during  LCP) to break packets up into small bits. It was developed and deployed to  reduce latency for small packets on slow links (think ATM cells and QoS). It  also has the property of forcing down the max mtu (though at a rather high cost  if it is not implemented in hardware or some other accelerated fashion).

In any case, there are a lot of tools available here. Clearly MTU is something  we struggle with when tunneling, and there is no magic solution.

• It wasn't clear if the L2TPv2 specification and implementations  actually covers and implement a redirection mechanism to help with  load-balancing deployments.

Yes. In the SCCRQ (the first message sent to setup a tunnel) the reply (SCCRP)  may include a "try another" or "try another directed" result code. The latter  includes a suggested set of IP addresses for other endpoints. In L2TPv2, the  encoding is only for IPv4, and is the one item that needs to be defined for IPv6  (alice and bill mentioned this in their presentation). For L2TPv3, it is defined  for both (so, L2TPv2 simple needs to adopt L2TPv3's result code here, if  necessary to do directed load-balancing on IPv6 transport). Note that the SCCRQ could be anycast.

Generally, we see the initiator (LAC) load-balancing across a set of responders  (LNSes) on its own. It has a set of destination IP addresses, and if it doesn't  get a reply quickly, it moves on, and incorporates its own random scheme with  respect to which it tries first. There are specific cases where the LNS needs to  direct a session to a specific box, but this requires back-end processing among  the LNSes to indicate which is less loaded, or a load-balancing box in front.

Mesh

• Softwires mesh scenario is analogous to BGP-free core - which is often discussed in VPN context
• Tunnel SAFI should be advertised with no-export, no-advertise - "here are my tunnel attributes but don't tell anyone else"
• Requirement is to tunnel one AF per distinct tunnel and/or more than one (multiplexed) AF/SAF across tunnels between AFBRs
  • No mandatory support for VPNs is required for transporting the BGP updates, we are not piggybacking the MPBGP VPN UPDATE message
  • It is mandatory that the solution support the ability to announce VPN reachability
• Use BGP cap adverts to convey AFBR softwire mesh support capabilities
• Egress AFBR uses BGP to advert a group of individual tunnel types/encaps/prefs along with the payload and transport headers supported by the tunnel
• Egress AFBR uses BGP to advert AF/SAF prefixes and connector attribute pointing to tunnel group. The highest pref active tunnel in the group is used.