IETF 72 - Dublin 2008 INTAREA Internet Area Open Meeting THURSDAY, July 31, 2008 0900-1130 Chairs Area Directors: Jari Arkko and Mark Townsley 0900 Notes takers, blue sheets, agenda bash (5 min) Joe Touch TUNNELLING AND MTUs http://tools.ietf.org/html/draft-touch-intarea-tunnels slides: http://www.ietf.org/proceedings/08jul/slides/intarea-1.ppt#290,1,Tunnel Issues ID Status Document to summarise talk given at last IETF on tunnel issues Added comments from mail list; MPLS is not in the draft because it is considered to be another layer in stack as opposed to be a tunnel. Send note to list if you like it Joe Touch IPv4 ID UNIQUNESS Draft: http://tools.ietf.org/html/draft-touch-intarea-ipv4-unique-id Slides: http://www3.ietf.org/proceedings/08jul/slides/intarea-1.ppt v4 and v6 identifiers are different and used for different things. 6.4Mbps throughput limit would be seen if people respected the V4 ID, clearly they don't. Document tries to align V4 and V6 behaviour. Therefore only use ID field if you fragment. Otherwise ignore the ID field. if DF=0 , you can fragment, then you need to think about how you are going to manage the ID - either rate limit or do something else as the field would not be unique for you to reassemble components ILJITSCH- assumes you need reliable delivery of packets? in that case wont you use MTU path discovery? JOE this is non-corrupted not reliable. Meaning is slightly different. TCP checksum is not strong enough. Don't want to force use of TCP ILJITSCH- shouldn't happen with TCP. Fragmentation not used JOE depends on TCP implementation. Make it clear that fragmentation should not be used ILJITSCH- - RTP can handle corruption, so is problem also moot there? JOE corruption is worse than loss. If packets can be fragmented, then the checksum protection needs to be very strong or they need to avoid fragmentation ILJITSCH- that would need application layer to do MTU discovery which they don't JOE exactly. Either don't fragment or use something to protect you from corrupted re-assembly. Don't know RTP well enough to comment on it specifically COLIN PERKINS : RTP has optional extension for security, provides strong authentication which would work; Standard sequence number and timestamp not enough. mis-assembly would probably be caught by codec; not big deal JOE maybe that's fine, if it doesn't affect timing or window. Specific cases off-line CARSTEN Borman: It would be great to get agreement on this as it could lead to great simplifications elsewhere (detail missed) ERIC: seems to be 2 things, telling the receiver not to depend on the field; are you also relaxing sender behaviour? JOE yes, it does not have to make it unique ERIC - but some routers (DSL space) fragment even it DF is set; could we not say more conservative receiver but not change the sender behaviour JOE Because things wrap, you might as well set to 0 ERIC no, it's a probability thing, the probability of corruption is completely different if you set to zero - the frequencies of corruption events will be much less if you don't change sender behaviour. Bad devices exist. ? take to hallway JOE a gentle introduction has been suggested whereby we start using a short 4bit sequence number field, to trip up but not fall over MARK stds track target for this since technical points that need input from community 0910 EVOLUTION OF THE IP MODEL Dave Thaler (30 min) Draft: http://tools.ietf.org/html/draft-thaler-ip-model-evolution Slides: http://www3.ietf.org/proceedings/08jul/slides/intarea-2.pdf iab architecture work; IP model - anything exposed by IP to the above layers. Application is used generically - could be transport layer - its above IP. IP model has not been constant over the years. apps have evolved around additional assumptions not listed in RFC 791. These assumptions not all listed in one place, indeed not all listed, not all well known and not always considered when changes made in IP model. The assumptions may never have been true and many are becoming less true. Set of examples given, theassumption what apps do and why its not necessarily true.(disjoint from set presented in EXPLISP BOF) GREGORY- did we decide reachability a better term? DAVE - reachability, connectivity same in this case not talking symmetric paths, just we can both reach each other Any changes to assumptions break some apps. Internet ossification. Optional functionality often safe but then its optional. Point to assumptions so people consider them. Changes might be intentional. ILJITSCH- - most assumptions are hidden feature requests - people want to do something and rely on features they have observed JOE - some issues are misconceptions and assumptions that were not clarified and other cases they are bugs that people have made incorrect assumptions - we should distinguish DAVE - some things are bad to assume, may need to be fixed and, some things that the industry should attempt to make more true This process documents everything for discussion first, recommendations to follow based on input BOB- Verizon business systems - Layer 2 people don't care about l3 stuff - ad hoc stuff we as layer 3 made assumptions about the layer 2, not them making assumptions about us DAVE yes we applied the existing RFC to the wrong type of L2 because we didn't see the difference JIM - v6 privacy addresses should be added, interesting as one host will use different address over time to same destination, so you seem to have many connections that look like different ones but are the same and it make management difficult DAVE not in presentation, its - I think - in the draft. Can you check that it's the same as what is in the draft. text suggestions would be great JIM - is there a resigned tone to the document - will things carry on going downhill? Will document get longer over time? DAVE - hope document does not get much longer. hope it's almost good enough. What would like now is to have your specific views on what are bugs and which assumptions should be made truer, input to list or mail IAB please. ?? This is the past not the future. Much can be broken. Today there are communities in Europe which are will spend millions on clean slate models which ignore all these problems. Not all researchers in universities believe we can carry on taking into account the legacy. Is there a message from IAB/IETF about this? DAVE - IAB not currently making recommendation, we are aware and involved in many of the other projects JARI - clean slate research is very valuable, how can we do a better network and work out deployment after. IETF needs to be informed on that. Similarly researcher will want things to be deployed, but that point might not be now. ERCI IAB needs to give clear message balancing the clean slate view and real engineering needs to be encouraged also DAVE - mail IAB please ILJITSCH- is this included - people complaining when they get different addresses every time they connect; webmail doesn't like this- assumption is that correspondent sees same src address all time DAVE difference address symmetric & non-symmetric nat CARSTEN 802.15.4 another interesting are, struggled in 6opp? WG with IP model here DAVE yes, that WG one of the reasons why we started this DAVID H building on from the DHCP over multiple interfaces - a more interesting problem is any protocol talking to different servers in different admin domains leading to different values. Has had implications in v6 deployment. MARK - this work heart of internet area - fascinating. IAB need our help 0940 IPv4 RUNOUT and IPv4-IPv6 CO-EXISTENCE JARI what else do we need? http://tools.ietf.org/html/draft-ietf-v6ops-nat64-pb-statement-req http://tools.ietf.org/id/draft-bagnulo-behave-nat64 http://tools.ietf.org/id/draft-durand-dual-stack-lite http://tools.ietf.org/id/draft-xli-behave- ivi http://tools.ietf.org/html/draft-shirasaki-isp-shared-addr http://www.ietf.org/mail-archive/web/ietf/current/msg48436.html TRANSITION AND EXHAUSTION SCENARIOS (Mark Townsley/Bagnulo, 20 min) Slides: http://www3.ietf.org/proceedings/08jul/slides/intarea-5.pdf 2 main problems: private and global v4 address exhaustion, step back, look at scenarios we need to focus work on most important and solvable problems. Some stuff is already solved. 3 scenario groupings 1 is reaching global IPv4, 2:is reaching IPv6 only servers; 3 I reaching privately addresses V4 servers ILJITSCH- 1c, 1d isn't the service provider giving you the same things? MARK - very similar, different business scenarios (who buys / owns the v4/v6 host end bit) - comcast =1c, wireless = 1d GREGORY (scenario 3) some sort of load balance function going on? MARK could be load balance; could be NAT 64 with DNS games. GREGORY what about this in a pure v4 world? MARK load balance is only option GREGORY are the servers private addressed because that is what you want, or simply because you can't get public addresses? MARK both relevant MARK NAT PT stuff is being used for these sorts of thing – should we define (something nicer) NAT 64? Scenario 3 = NAT 64, scenario 2 is NAT 46 is different - different business cases, and different technical. TOM - clarify key of scenario 1? MARK - V4 host to V4 internet over v6 bit. Scenario 2 specific only v4 host reaching to only v6 server. scenario 3 dual stack host starting with v6 network, reaching v4 server eg you in v6 internet and want to reach your home web cam which is V4 only/ MARK - v6-only client ruled out; dual stack assumed TOM - object to scenario 3 as described - where in the IETF do we do work about making private v4 servers reachable to public internet? MARK it's in scope because its being used NAT PT is being used to solve this problem even though we deprecated NAT PT JARI we are asking community should we do it? MARK - we need to explicitly rule this out as many people are asking for this TOM - I would describe scenario as assume a public v6 address on box and ignore the bits behind, so this becomes v4 only to v6 server MARK - but thats ok its just v6 (think Mark thinking dual stack host) . As Tom described its scenario 2 JARI are you objecting to Dual Stack? TOM Why is it a separate scenario? Back end is just a smaller problem which we should ignore DAVE T - this is case where guy on legacy v4 can't get public v4 address space so it's not his fault. In answer to Greg, load balance assumes all servers are equivalent. This is not what we consider. Lots of different things, all on port 80. NAT PT has problems which people are hitting. IETF can either replace it withsomething like NAT64, or the work can go on outside the IETF. DAVE T - scenario 1: This scenario does not require translation although it can be used. softwires and behave doing stuff. If not translation, then what is relevance to behave? MARK - Behave understands v4 v4 alg translation, port leasing with addresses. GREGORY Claify - Behave do 1 and 3. Anything with v4.specifically not ALG. Just translation of address DAVE - scenario 2 - v6 only server v4 only host - isn't really v6 only or v4 private very similar. NAT 46 is nigh impossible, so if you can make scenario 2 more like scenario 3 it's more solvable ROB? I wrote a NAT 46, so its not impossible. scenario 2, I think we know where the nat pt has to go....we need to rule out anything that plays dns games that make dns sec difficult, therefore the nat 46 with DNS sec only works if the validating recursive name server is very close to the legacy v4 hosts eg border router ?blue shirt Spanish? I think there is only 1 scenario. They look different depending on where you are putting the solutions (CPE, host, network), but we should look for a single solution that can be located in different places . Softwires is good+ perhaps 64 proxy. MARK - yip agree, just different business models - it is the same mechanism ?spanish? I think 2 and 3 are also the same. JARI significant differences in solution and how they affect the rest of the internet ? Spanish? Our experience is that anything solvable with softwires + proxy MARK yes if let yourself translate at application layer then yip it would be ok, but is an app proxy generally sufficient? - you say in your experience it was OK ? NEC - propose that we have private/global/public/local terminology issues. Global matches to local not private. MARK - could help understanding ILJITSCH- - agree with Thomas more complex than it needs to be. Doesn't divide responsibility between originator and receiver. Eg with private address for servers there are 2 issues who puts quad A records in DNS, and then how do you get from DNS addresses to real addresses on the servers, that is private matter that we know how to solve. How to get from something that only has IPv6 address to something that only has A records in DNS and vice versa? ILJITSCH- - scenario 2 - location of NAT is not unclear - it needs to go very close to users or you don't have enough identifiers. MARK - you agree with Rob? ILJITSCH - yes HESHAM Soliman another agreement on NAT location HESHAM Soliman can break scenarios up into groups that depend on what the hard problem is to solve. tunnelling and translation will solve all scenarios that we have. Within translation space hard problem - who is initiating communication and who is receiving? This is missing. MARK- the arrow indicates direction of communication initiation. We haven't got entire design space - we can't look at every option, just highlighting what we currently think is important; we need to know if other scenarios are important HESHAM Soliman The hard problem is simply reaching someone (in a different address space) behind a NAT, translation part can be solved. We know how to address the dns problems MARK is it important - to solve this with a NAT 64, NAT PT thing? HESHAM Soliman V6 aspect not too important. I don't think we should solve that problem now , long term. Scenario 1 is most interesting. Also can we consider mobility. LORENZO Agree I support scenario 1 especially in short term. On scenario 1. Lots of v4 content and not many addresses. Do hosts need to be modified? DAVE - only the phone customer. modem may need to be new. V6 clients out of scope in scenario 1. LORENZO - Lot stuff is out there and we can't change anything DAVE - buy big box from vendor is the most immediate option LORENZO 1F; turn on v6 in network, buy new edge box that can do the translation to allow you to reach v4 and v6. Requires dual stack on backbone. DAVE only to reach a v6 address LORENZO internet and private confuse me. Size of blobs is confusing. scenario 3 causing more confusions? Lorenzo would like that the private v4 bit is public interface LORENZO host as v6 e2e and v4 as today MARK - sounds like dual stack host - which is not covered here as its already sorted out LORENZO - but we need to give everything V4 and V6 addresses, and we run out even of private v4 address space for these dual stack hosts, so we would like to just have v6 on the hosts as its already on host stacks, and then enable them to access content and we don't want to have to rely on the ISP to provide the necessary support JARI trade off - tunnelling schemes need changes at both ends, with translation - one ended possible, but drawbacks with translation - messes up DNS. Dual-stack-lite will break less than translation, should be used where possible. We need to examine your scenario more closely LORENZO - it just seems simpler, don't know what translation drawbacks you refer to, but I don't know why you call facts of life as drawbacks - 90% of networks are like this JARI more problems with NAT PT than with regular NAT - DNS interactions for example MARK - please can we hash this out in the hallway to understand better Geza Turchanyi - what do I do with my old draft that is close to 1e? Mark - not familiar; is there a clear business driver? - again private chat required ? ?? - -. Scope of softwires for 1c and 1d included where the NAT may be in the CPE. mechanisms for leasing and such should b useable in both scenarios; behave would do that and needs to work over softwire tunnels ?? 1d can be done without any NAT at all PEKKA - 1d observation - it seems like that unless new deice is bundled with ISP offering, then can't mandate a device as users will want to use their existing devices. MARK - that's why a v6 only ISP is unlikely for a while. ISP wants to use v6 and has control over end devices, business reason exists. Cheap v6 service not tunnels etc then onus on end user to find right software, and if they pick a tunnel solution they need to find something to terminate the tunnel , not sufficiently different to justify creating a 1e scenario Pekka Savola - further comment on scenario 3; How is this provided today? MARK - NAT PT PEKKA - I mean to v4 users ? MARK they still have addresses PEKKA - not a problem for next 5 years? MARK - depends on size of server farm PEKKA problem is that users keep using to v4 so these private v4 servers need to be reachable by v4 clients also. Reachable to v6 is trivial in my opinion GREGORY customer requirement for this today PEKKA service not provided to v4 users any more. Change pc on left to be v6 only Gregory if this is really dual stack client it can be done for v4 today, so don't need to use any v6 PEKKA - is it enough to provide it to v6 client MARK may be different scenarios. The requirement we heard of was for v6 capable clients. PEKKA may not be different if its possible to locate NAT etc close to the private v4 stuff MAT Ford scenario 2. V6 only servers unlikely to appear before v4 addresses have vanished so a long time away. Also, if v4 hosts (or someone very close to the host) need to bear cost of connecting to V6 host that is also unlikely to happen until there are lots and lots of V6 hosts so it's a very long way out. No economic rational for V6 only servers. MARK when it happens there will be a scramble for something we just don't know what TIM strange we have v6 only servers as a scenario but not v6 only clients, more realistic JARI/MARK we have solutions for that, only considering hard stuff MARK why turn off v4? Tim management simplicity, subnet architecture simplicity MARK - we expect all hosts to remain dual stack. dual stack is a valid solution for lots of the problems that you would get if you have v6 only, and since all hosts have dual stack why turn it off? I think it's the best answer rather than creating a new box that will have its own problems. If you can convince us otherwise. JARI - need to focus on the key / top 3 problems TIM agree with Matt, scenario 2 (V6 only servers) would be less important/likely than V6 only clients in enterprise MARK why not give all hosts the same v4 private address 10.0.0.1, still need DHCPv4 for some stuff. V4 can be pared right down, they can send v4 over the v6 network to the edge box for NAT 44 - operationally simpler - good balance? Possibility? VIDYA - scenario 2 strange to have legacy devices but dual stack networks? isn't the problem legacy application not legacy hosts? And in the timescales we have its easy enough to upgrade the applications. Would a legacy app try to reach a v6 server? - i don't think its a relevant scenario - by the time you have dual stack internet, the # of legacy hosts is minimal so only legacy apps is the problem. Keeping v4 host to v4 server reachable over v6 network might be most important. TOMAS Narten - we desperately need v4 only client to v6 only content and vice versa - we can't rely on dual stack lots of diversity and economics at play in real world. Will happen outside the IETF badly if we don't solve it. Need 46 and 64 MARK - still worth keeping other scenarios in mind because it can help in specific situations. Making it clear where you can use a tunnel is good idea. JARI- yip things is happening whether we like it or not THOMAS- yip and we let NAT happen without us and look at the mess STUARTCheshire - risk of enumerating every possible case. eg v4 only hosts - we should strive for e2e v6 connectivity. isp mention v4 windows 95 customers that won't upgrade. Not everything new needs to work on legacy – can't run new apps without a ram upgrade GREGORY - scenario 3. what is the host? V4, dual, v6? MARK - always dual stack JARI - v6-only only in sensor networks GREGORY - Alain can't use dual stack because of lack of v4 addresses. My priority would be v4 only to v6 only. We can assume dual going forward. Encourage no v6 only ERIC - motivations are different in the different scenarios. 1 - keep v4 internet going, using v6 to make it happen. Others are about making it easier for people who want/ or have to put up with only v6 (as v4 becomes expensive). Should we rank them? V6 new network should be encouraged. Dual stack might be easy but addresses make it expensive. NAT 46 and 64 needed, used for different reasons ALANSO? I think 3 will happen before 2. but if you allow it then v6 will never happen THOMAS - we are reprehensive of rich countries. Other countries will have a lot of impediments to upgrade - v4 only stuff will remain in these areas much longer equipment we throw goes to other markets. People do bizarre patches to keep things working. ISP SHARED ADDRESSES (Miyakawa, 10 min) Draft: http://tools.ietf.org/html/draft-shirasaki-isp-shared-addr Slides: http://www3.ietf.org/proceedings/08jul/slides/intarea-3.pdf Need to allocate some address space for carrier grade NAT. Can't use class E space as CPE won't work properly. ? - i think it good ides. in my draft I proposed it. I also proposed a way to ? Not clear? MAT fORD - motivation? prolong life of exiting cpe? i think this will not be a problem because CPE has such short lifetime ? - we cant force customer to upgrade the cpe. some cpe can't do what we need MARK - is there a problem with subtended overlapping private V4 address spaces? seems to be the assumption why can't ISP use 1918? If not, we need some more private address space and can it be the same for all ISPs? Not extending 1918 only service providers are allowed to use it. Ans - make it contract with customer that they don't use it because standard says you shouldn't THOMAS who are you trying to avoid address space collisions? ans - between customer and the ISP network Rudiger Volk- if we just do this to avoid collision why don't you (ISP) assign a /24 from address space to all customers for use on CPE - or we could dedicate worldwide one of our /24 to all home networks. ANS - renumbering all home networks? ? Then change to 1981 to exclude net 10 ? Relevant also to small offices. End users use the default 192.168...but small business tends to use 10 multi-homing THOMAS - once you start allocation of globally (or within some scope bigger than local) private addresses you run into problems - lots of people wanting them. Not sure this is a safe direction to go in. IANA need you to say how much space you actually want. - Some other draft referred to ? WRAPUP Softwire re-chartered - to work on dual stack lite Discussion scenarios continue in intarea behave and v6opps