Scribe: Bruno STEVANT
###################################
Hub&Spoke Phase 0 Framework
Objective: Wrap up Phase 0 and submit it to IESG after San Diego
Presentation from Bill.
Update to 01 :
* Intro: Phase 0 not One
* AD: Labelling BCP is a bit early, label it "Recommandation"
o David: Recommandations were based on how L2TP is deployed
o Need to check each part for Recommandation specific to Softwires or scenarios
* AD: remove normative language ?
o DW: should check each use of normative languge ?
* IPv4 PD: Carlos agrees on Radius attributes
* MT: How do you do IPv4 PD ? IPCP or DHCP ?
o Bill: IPCP
o MT: DNS and IPv4 address may be send through IPCP (Microsoft Impl)
o DW: mark attributes delegation with DHCP as a MUST, with pointers is people wants to use IPCP
* DW: Put back the "Bruno draft" in a informative reference (it is already ?)
* MT: Is dhc-subnet-alloc alive ?
* DW: Section 3.2.2: no phrase without verb ;)
* Section 7.2: put all verb in lowercase,
o s/The SC MUST associate/The SC should associate/
o s/RFC2865 MAY/RFC2865 should/
* AD: put radext-delegated-prefix out of normative ref
* Section 8.1: Remove phrase "Softwires implementers ..." or the entire section
* Section 4.3: Move "Bruno's draft" in a seperated line
Recommandations bashing:
* Section 1.4: Rename section as "Recommandation for operations"
* Section 5:
o IPv6 address stability depends on business model
o Focus on the goal of provisioning
o Keep recommandation to the case of a single or a small number of SC (in case of load balancing), mention that the distributed hubs case make prefix stability tough
* Section 5.1.1: Same /64 for all tunnels ? => controversy on link numbering.
* Section 5.1.2: Does nested NAT break something ?
* Section 5: Section overloaded with philosophy ;) Talk about a general IPv6 problem. Should make reference to v6ops documents. (DW)
Why not do a recommandation document and push it to v6ops ?
DW: For recommandations, do one section with very light examples
Section 6:
* Keep two pictures, one simple picture stating the steps of SW establishment, oneother detailled. (Restate PPP+NeighDiscovery as Link Config)
Section 6.1:
* JP: Unify all L2TP ref to L2TPv2
* No textual ref to picture 11
Section 6.1.1.1 : Move introduction sentence.
* Uppercase COULD does not exist
* Host Name : to be removed
* MT: What is the meaning of beeing ignored ? What about LNS implementation ? Should it have a specific SW code ? Move it "SHOULD be ignored" ? => To be discuss offline
* AD: SHOULD, MUST, to be reviewed by the author
* all verbs in Uppercase
Section 6.1.1 : What is the differents between "Optional" and "Not required". RFC2661: Section 6.0 states which AVPs MUST be present and AVPs MAY be present in each messages. SW draft should state which AVP MUST be handled by implementation and make recommandations for other optionnal (e.g. Authentication)
Section 6.1.2
* DW: Existing impl have optimisation for LCP HELLO messages
* Use LCP if you want tight Dead-End Failure Detection
* State that implementations should support both mecanism, but should not use them concurrently
Section 6.1.3:
* "after" out
Section 6.2.1
* DT there a document in pwe3 talking about MTU and fragmentation for LT2P (v2 and v3). Point to RFC 4623
Section 6.2.2
* Make ref to LCP RFC (1662 ?)
* If figures are copied from RFC, make ref
Section 6.2.3
* Make ref for CHAP, EAP, etc
* Missing comma "MS-CHAP, EAP"
* Section to point to Security document
Section 6.2.4.1
* AD: Is Interface ID of the IEEE EUI64 or the *modified* IEEE EUI format ?
Section 6.2.4.2
* Sentence "If the Softwire Conc ..." to be moved at the end of the paragraph
Section 6.3: "IPv6 Neighbor discovery"
* RA may or may not contain IPv6 prefix, depending if DHCPv6 IANA is used
* Contents to be clarified
Section 6.4.2
* Remove normative reference. For IPv4 PD, put some text sayingit is optional (we dont know about the whereabouts of the draft).
Section 7: Rename it "Radius Recommandation"
* Second paragraph to be detailled
Section 7.1.1
* Put more information about mechanism (for example poit the RRAO document)
Section 7.1.2, 7.2.1, 7.2.2
* Same thing, point documents
Section 8: Remove BCP
* Ref RFCs ?
Section 9:
* Point security document
* typo L2PT :p
Section 10&11 to be removed - in Security framework
* Document to refer to phase 0
* SC blackhole out-of-scope => ref to documents w. solutions (IPsec)
* Authentication : (MT) PAP OK for OTP. Security pb with L2TPv3/ IPsec ?
* Phase 0 : use current IPsec document, talk with the "delegated Security person" for next phase
############################
L2TPv3 required changes
How to solve H&S issues with L2TPv3
L2TPv3 Improvements
* Integration with existing L2TPv2 ?
o Back-compatibilty with fall-back
o MT: If you stay with PPP, you dont have beneficits of L2TPv3
o Bruno: Softwire should define transition for architecture
o Consensus: remove PPP from L2TPv3 ? => Send a message to the list
* Questions to be sent to the list (Draft by Mickael Liad Hexago)
o Do we need back compatibility ?
o Do we need DHCP support ?
o Do we need PPP support ?
* How does the auth scheme for L2TPv3 can match auth with DHCP (DOCSIS way)
* Auth schme may be different between PPP and L2TPv3 (password has to be local to SC ?)
* In the mesh case (or Hub-to-Hub), we never use the L2TPv3 control plan to set up a tunnel.
* HELLO or VCCV ? => Use VCCV, but optimisation is still draft
* DW: IP version selection : do we have a field for that ? Do we want to handle IPvX/IPvX case ?
o Bruno: It may depend on which DHCP version is run after tunnel setup
* DW: Softwires should stick on IP over IP model
* Explicit Ack Message : used to put the digest into a message (replace ZLB)
* DW: We discuss changes in protocol, not of framework modification
o Cookie usage to emulate VPN ?
o Phase 1 Framework should cover all the MUST of Pb Statement, plus other optionnal feature ... Should we work on these feature or push it to pwe
Presented by Shu Yamamoto
Scribe: Bill Storer
The .00 level of the doc is discussed
The document discusses security in reference to Hub and spoke
The group agrees we should just discuss security in reference to the l2tpv2 framework doc.
The document will reference that it is connected to the l2tpv2 framework doc.
The document will be named in the same fashion as the l2tpv2 framework doc.
Black hole attacks on concentrator access are out of scope for this document.
We should point to other docs talking about black hole attacks.
Phantom concentrators are out of scope of this doc.
We will point to other docs which Dave will provide.
Should we mention PAP in this doc? Mark suggests it may be used in one time passwords.
Check with our security person if we can use PAP.
There is an existing IPSec doc for this phase, l2tpv2. We will reference that and get a security review.
We will likely need more IPSec changes and work for l2tpv3.
Bruno asks, Should we include the SI as the attack vector?
We should ask our security person about documentation on this type of thing.
Taro is our security person.
kivinen@safenet-inc.com
4over6 Multicast Presentation - Yong Cui
Scribe: Carl Williams
- illustrate IPv6 backbone surrounded by IPv4 islands
- solutions is SSM
- how to setup IPv6 tree rooted at edge PE
- Auto-discovery of PEs
+ use MP-BGP between PEs
- Potential Solution
+ dynamic map IPv4 mgroup to IPv6 mgroup
+ single static tree in IPv6
+ single root PE-based static tree rooted at PE
- Solution #1
+ map v4(s,g) to v6(s',g') where s' is IPv6 addr of PE
+ P maintains multicast IPv6 group states
- Solution #2
+ use RP-rooted shared tree inside IPv6 backbone
+ not optimized
+ O(1) trees in core
- Solution #3
+ per-PE SPT
+ each PE advertises its IPv6 group address using MP-BGP
+ egress PE joins each PE-rooted SPT
+ O(N) trees in core
- illustrates PIMv4 register encap across softwires cloud
- illustrates multicast forwarding across softwires cloud
- Conclusion and Future Work
+ summarized three solutions
+ solicited comments and co-authors
+ Frame work may be WG document
DaveW: talk to Greg Shephard and or Eric Rosen as co-author; does not address multicast VPN requirements; good that 3 x basic solutions are documented;
Alain: concerns that sub-optimality is not way to address solution
DaveW: Classic trade-offs on scale vs optimality seen multicast
DaveW: Need to solve multicast VPN problem so that this doc could become-possibly-eventually WG document
DaveW: leverage mVPN where appropriate
DaveW: need to look at transmitter efficiency problem (#4) as well.
Jordi: concern over 6over4 terminology collision.
Yong Cui Presentation (4over6)
Scribe: Carl Williams
- agenda
- reviewed original draft-wu 4over6 protocol
- illustrated cernet2 IPv6 backbone surrounded by IPv4 and IPv6 access islands
- illustrated 4over6 control and data flow
- MP_REACH_NLRI extensions are NH=1Pv6, NLRI=IPv4 prefix, SAFI=67
- IANA assigned new SAFI=67 for this draft
- illustrated implementation framework on Linux box, same slide from HK meeting
+ Linux and Bitways are implementations
- CERNET2 deployment w/ IPv6 backbone surrounded by 7 x 4over6 routers
- 4over6 draft status reviewed
+ -00 is orginal
+ -01, added 4over6 deployment on cernet2, extension for 6over4, revised SNPA-related fields in MP_REACH_NLRI attribute
- Requirement
+ mention that advancing 4over6 in Montreal IETF meeting achieved consensus in Montreal IETF meeting (experimental)
+ advance draft to RFC (experimental)
DaveW: Montreal consensus was to advance this to **experiemental** RFC
Mark: While Softwires WG is building on standards-based track solutions, other solutions would be put on "hold" ... other work like 4over6 cannot be
published as experimental/informational RFC until WG is completed
DaveW: currently 3 x SW mesh solutions exist, would prefer to have one solution covering all AFI/SAFI and encaps versus individual solutions for each
Mark: would be held up in RFC editor because it overlaps existing Softwires Mesh WG efforts
Mark: Experimental not required to have MIBs
Mark: Mentions to Yong that to get 4over6 to experimental RFC, you need to advance SW MESH solution (whatever that is) to consensus
Yong: Could be 3 years
Jordi: No, should be much shorter
DaveW: Will present simplified SW Mesh solution but technical issues remain to be resolved
Carl: Is draft-wu hold-up from RFC a problem for China and Dr. Wu?
Mark: Multiple alternative drafts that might conflict with WG efforts are being held up; authors will need re-submit once "ban" is lifted
DaveW: Forced one solution with H&S, need one for Mesh as agreed upon at last 3 WG and interim meetings
Mark: Best way to make it go fast is to "pool" efforts to get consensus
Yong: already deployed in real networks
Alain: for H&S we decided one solution; we need similar procedures for Mesh
Yong: Framework is not the solution
DaveW: Framework defines the solution parameters, may not include actual encodings, etc. but normative references to particular drafts. This solution doesn't solve VPN, Mcast or multiple encodings that were specified in the framework.
Mark: Thus, it was moved to experimental.
DaveW Softwire Mesh Update for Eric Rosen/John Scudder
Scribe: Carl Williams
- Eric Rosen and John Scudder presentation authors
- existing point solutions should be out of scope
- NH Encoding is a technical constraint
- does not want to invalidate install base
- original MP-BGP was not correct in stating common af/saf for NLRI and NH
- Simon: why NH length?
- DaveW: to differentiate IPv4 or IPv6
- Length-based encoding
+ need capabilities exchange to make it work
- TLV-based encoding
+ capabilities exchange to make it work
- need to rectify interoperability of legacy with new-encoding schemes
- all AFBRs must be able to understand new NH addr semantics which is a deployment restriction
- depends on practical problems to solve vs architectural purity
- new SAF solution
+ 4over6 SAFI=67 is an example
+ NH transformation (rewrite) could occur
+ forwarding
+ ms-bgp
+ also need SAFI for multicast
+ future: NH in VRF
- NH encoding is a contentious issue
- Encapsulation
+ do we need to support more than 2 encaps?
MCast and Security for future
WG accepts Rosen/Scudder alt as solution for Mesh