Last Modified: 2005-02-09
|
TC BoF
IETF62, 3.30pm Monday 7th March Chairs: Alain Durand, Thomas Narten Mail list: v6tc@ietf.org Problem Statement (Narten) --------------------------- [See presentation "Problem Statement"] IPv6 enabled core, but no IPv6 in access network. How to set up tunnel between a home site and core? Need to agree properties: authentication, mtu, encapsulation Also need to find the TEP. Can make assumptions about the ISP e.g. ISP may have multiple POPs around world, so need to pick 'nearby' TEP Can make assumptions about the customer e.g. might be a node, or a router, with IPv4-only connection to ISP Need to have negotiation due to wide variety of access media and whether features like authentication are required, encryption of tunnel, etc. Need to consider keep alives, NAT refresh, etc. TEP discovery is orthogonal to the configuration. Generic automatic discovery is 'difficult' in the general case. Note that SMTP, SIP etc do not provide general discovery like this. Encapsulation: IPv6 over IPv4, or IPv6 over UDP over IPv4, or specialist encapsulation Some limitations, e.g. 64K port numbers for a NAT box with many TEPs behind it e.g. L2TP includes a demux key for the TEP. Might we do something generic enough to be used for other tunnel types? Are there off-the-shelf solutions? [Discussion] Miakawa) ISPs might have some access networks that are upgraded some not (Bound) Change to say ISP does not offer IPv6 natively to *all* customers (Palet) Auto decide whether to tunnel or not depending on whether native available (Palet) Some networks are IPv6-only, so need IPv4-in-IPv6 tunneling here (Hans Trefini) You have one solution providing light weight solution with out mandatory authentication. This should be negotiated. Do you also consider mobile end points? Not part of the current problem statement, but inside or outside of NAT could be dynamic, but we do not want to consider Mobile IP. Might want to consider IPSec tunnel paradigm. (Ron Bonica) Could be applicable elsewhere, change IPv6 to any arbitrary service, e.g. IPv4 multicast. Merging goals (Palet) ----------------------------- draft-palet-v6tc-goals-tunneling-00 [see presentation "merged Goals"] Converged three separate documents to work on a single document Basic objective to describe set of goals, and cross check against scenarios. [Discusssion] (Meyer) IPv4 multicast tunneling often doesn't get removed from service. (Narten) Not engrained here, ISP can just stop using it. (Savola) multicast tunnels were inter-domain not to end user (Narten) tunnel setup is important for service, but also need addresses... maybe combine all into one, (Chown) ISP has cost for tunnels - concentrator cost, customers can't talk direct, tunnel overhead in bandwidth, so will want to remove. (Chown) On the draft, the scenario section should just be removed since you have aggregated requirements into the first sections. The first sections could be compressed more. (Kurtis) Mixing service description and tunnel configuration protocol (Mark Townsley) 'latency' is a vague term, what is acceptable latency? is it set up once and stays, or fired up frequently? (Palet) Design protocol with different functionalities for different networks? May not want keep alives in some networks for example. (Mark Townsley) Lots of issues - scalability, QoS, ...? (Thaler) On TEP, what is scope? Is it discovering endpoint in same ISP or could it be larger? (Narten) Open question. (Thaler) Great if in scope, but makes it harder (Bound) Spec doesn't belong in this BoF or the IETF. No innovation or technical creativity - is an interesting deployment spec but not sure why I'm here listening to this. It should go away. (Ross Callen) If were some way to tell a v6 router there is someone trying to get to you you may be able to fire up a tunnel dynamically? (Dave Green) Many systems integrators are doing this already, so why not BCP? (Durand) Not clear something off the shelf ready yet (Dave Green) Firewall an issue if bypassing site security Existing protocol analysis (Parent) [see presentation "Protocol Analysis"] ISATAP, STEP, AYIYA, TSP, L2TP (RFC2661) Differences tend to lie in prefix delegation, NAT traversal, (un)registered mode, security, setup latency, otherwise most goals are met. [Discussion] (Mark Townsley) Again, latency is a tough thing to measure, e.g. 13 packets in AYIYA, is this an issue? Maybe total round trips would be a better measure? (Bound) You missed IPv6 dominant network scenario and DSTM? No Teredo either. (Parent) We can add them in. (Bound) Who are you representing? You missed some of the past five year's work (Narten) I'd question whether Teredo is appropriate - not setup to ISP TEP. (Bound) All you want to do is define parameters? (Narten) You need a tunnel, and you need to originate from client to clear TEP in ISP. (Bound) Mechanisms will not be defined here (Durand) Not here to do that, just here to configure tunnels (Thaler) Clarify address stability please (Parent) IPv6 address will not change if underlying IPv4 address changes, thus ISP uses own IPv6 address space. (Narten) If you roam to multiple POPs, do you keep stability? (Parent) Good question. (Townsley) Is it a strict requirement? Affects solution dramatically (Parent) Main issue is not embedding IPv4 addresses in IPv6 addresses, for example. (Dupont) We used L2TP and I have that for any Linux or BSD. L2TO or not (Durand) ---------------------------- [See presentation "L2TP"] Need to look at total latency, e.g. if using DHCPv6 on top of the tunnel, you add more latency, e.g. L2TP(8), PPP+CHAP(11), DHCPv6(4) = 23 packets. May be a big issue if RTT is 0.5 sec in 3GPP. Strength of this requirement will vary with the scenario. Can we collapse all this into one protocol? <some example 'maths' presented> Layers there for a reason e.g. PPP does MTU adaptation, L2TP is doing tunnel management, e.g. keepalive and can make sure packets ordered If we don't use L2TP the node may need to do that. [Discussion] (Hans) Investigate IKE? (Durand) Yes, this is a candidate. (Dupont) L2TP is good candidate for header compression (Townsley) Few people implement header compression (Thaler) DHCPv6 isn't a major contributor to latency, but you don’t want to have to duplicate all new DHCPv6 options. Push back on putting DHCPv6 into this. Stick to Layer 2. Solution Space Analysis (Savola) -------------------------- [See presentation "Solution Space Analysis"] First issue is tunnel link configuration What to be configured, and how to configure it. Separate question is how to do IP configuration of the tunnel, e.g. DHCPv6, RA. Avoid reinventing IP configuration or DHCPv6. Generic solution might lead to some L2TP 'reinvention' A specific solution might address only IPv6 over (UDP) IPv4. So, main approaches would be - use L2TP, maybe modify it - use TSP - create collapsed in-band mechanism, reusing DHCPv6 or RAs Some considerations, like NAT detection (maybe just assume there is a NAT?) Probably just pick the IPv6 over UDP IPv4 for encapsulation Authentication supported, but probably only when roaming? (otherwise use IP check) (Durand) You have described in-band and out-of-band mechanisms. Will now look at an example of each. (Savola) <presented STEP as in-band solution> [See presentation "Step"] IP and link configuration is just 2 or 4 packets. (Parent) <presented TSP as out-of-band solution> [See presentation "TSP"] Open Discussion ------------------------ (Hans) Why do you use XML if worried about efficiency? Other efficiency issues exist (Savola) Were we redesigning it may be done in a more optimal way (Chown) Where are the potential ISP users of this? Note 'costly' is a vague term - where is cost - e.g. user support, which is same for native or tunneled? Would actual ISPs make a deployment using this now ahead of a full native deployment? Any ISPs here? (Durand) Please comment (Miakawa) No implementation, we can't use it, timeline is important. Not sure why no IPsec on the list. Problem space similar to VPN extension issues. (Palet) Main difference is in Enterprise VPN don't need tunnel discovery, will be manually configured. (Miakawa) Users don’t care to configure network number. (Savola) VPNs must use encryption, here you may not want to do that for scalability (Miakawa) Have to authenticate users. (JDurand) we deployed a broker, so surprised to see work on this. networks in the middle, hence deployed broker, otherwise would go native. (Narten) some ISPs don’t want to upgrade across the board (JDurand) We bypass equipment in the middle (Miakawa) We are doing IPv6 native because cheaper than tunnel (Chown) Enterprise wants to offer v6 to remote users e.g. at home or at WLAN hotspot - so see Thaler cross-ISP issue (Palet) Some existing tunnel brokers don’t work in some cases, hence this generic work. Also make the broker discovery automatic. (Bound) WG should do 4-in-6 and 6-in-4 and security should be included. If broker can be made better its code that runs in user space, so that's fair game. TEP discovery (Savola) -------------------------------- [see presentation "End Point Discovery"] Proposed solutions work using one of: - Well-known unicast address (anycast) for discovery of 'real' unicast address - DNS forward or reverse - DHCP or PPP options - SLP If need to work through NAT, options limited. [Discussion] (Kurtis) This is problem we don’t want to solve. Closer to service description than having much to do with tunnel configuration protocol. Should be separated. Only solutions I believe we could do are signed reverse tree or manual configuration. Others wont scale or work. Draft is weak on security. (Savola) I don't buy argument anycast can't be secured. (Kurtis) As a user I don't know if network is secure or not (i.e. is anycast address configured locally or leaked from somewhere else - no way to verify). (Savola) Could also spoof DNS! (Miakawa) I agree with Pekka. From ISP point of view we don’t care. Need username or password off client anyway. (Savola) TC and TEP discovery could be deployed without username or passwd and just use IPv4 access authentication. (Kurtis) ISP may not care less, but me as a user, I do. No idea who is receiving anycast traffic. (Williams) With millions of users we need to load balance tunnel servers, can't statically allocate? (Durand) Layer 4 load balancer? (Narten) Dynamic discovery can be good, but is it a strong requirement? Or is it 'needed' because it's nice to have. Wrap up ------------ (Durand) Time to wrap up. [Question] (Durand) How many people interested in TC work for 6 in 4 or 4 in 6 only? - Lots, maybe 50% (Durand) For any kind of tunnels? - Few, maybe 10 (Meyer) Would be to everyone's benefit to find balance of IPv6 need and generic solution for other uses. (Kurtis) We don't know enough yet. Getting a consolidated effort across WGs doing this would be useful. (Ron Bonica) Suggest rule out any solution that can't be generalized to other domains. (Savola) Need to analyze generic issue if we go wider, else lose IPv6 deadlines (Hinden) Have a zillion tunnel protocols and I don't see advantage of new generic one. I vote for limited scope. (Durand) (hat off) example of the schizophrenia of IETF - requirements analysis vs desire to be generic... ball going back and forth. Chances of success higher if we stay focused on IPv6. (Townsley) Naive to think we'd create something to kill other protocols. (Narten) Brokers are being shipped - why is that not good enough? [Question] (Narten) Go with TSP as is? - about 10 people (Durand) Is TSP good enough to get by on? - about 10/20 people (Durand) Need something more? - less than 10 people (Narten) Which ISPs need to solve this problem? - 4 people (Parent) TSP is just a draft - need expert review (Thaler) Maybe L2TP is enough? TSP doesn't solve TEP discovery. [Question] (Durand) Who wants TEP discovery solved? - 12 yes (Durand) And not? - none (Miakawa) Need implementations. Only Hexago client is GPL. (Savola) need to pick the TC protocol before pick TEP discovery (Townsley) Why not separate? (Savola) If some using L2TP, TSP, then can't assume same service elements in place, need to make it interoperable. Meeting closed at 17.50pm. |