[v6tc] BoF minutes

[Alain Durand <[e-mail]>]

Thanks to Tim Chown & Jeffrey Dunn for taking notes.

	- Alain.


TC BoF

IETF62, 3.30pm Monday 7th March

Chairs: Alain Durand, Thomas Narten
Mail list: [e-mail]

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.

_______________________________________________
v6tc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/v6tc