INTAREA WG Meeting Minutes 29 March 2010 Meeting minutes based on notes taken by Dow Street. --------------- Administrativia --------------- (jari) christian vogt has stepped down as WG co-chair. - scott brim is taking over. ----------------------------------------------------- Updated Specification of the IPv4 ID Field, Joe Touch ----------------------------------------------------- (joe) the ID isn't unique - purpose of this is to document existing practice, and discuss when this is a problem and when it is not - rewrote the draft for clarity, and updated recommendations based on DNS - see slides... - between 01 and 02 the purpose was to remove some refs from the abstract, and update the refs - things to do : replace the phrase NAT with 'address sharing devices' - since this is not specific to NAT - another issue - the impact of application layer gateways in boxes - waiting for reviews from DNS OPS - been through WG last call - once have those other reviews we should be ready to go to the main list ---------------------------------------------------------- IPv6 Support Required for all IP-capable nodes, Wes George ---------------------------------------------------------- (wes) this draft is pretty straightforward - issue is that IETF has remained mostly IP version agnostic - this is mostly good - but a lot of other orgs, RIRs, have become more and more focused on moving to IPv6 - primarily driven by IPv4 space exhaustion - now that that has happened, IETF hasn't updated recommendation to implementers - realistically it is still their decision, but we often provide this kind of guidance - also, have a lot of things that refer generically to 'IP' ... - we keep pushing out the time where you will have a critical mass of IPv6 devices - said in discussions that most think of NAT44 as necessary evil - NAT 444 as a bad thing - hard to deploy IPv6 - there really is not a great deal of consumer hardware with great IPv4 support (wes) if considered an IP implemenation then it must support IPv6 - says currently that it SHOULD support IPv6, and should be equivalent quality to IPv4 - and MUST not require IPv4 for proper and complete function. and recommends best effort to update HW and SW to support V6 - we recognize limitations of updating HW, but this is 'if capable, then it should' - and last thing - within the IETF we should not be doing anything that puts out v4 only protocols (fred baker) you mean like ARMD - which is IPv4 only - they are having their first WG meeting this week (jari) they are chartered to look at scalability of ARP and neighbor discovery, not yet work on solutions - if chartered to do what was initially asked, would have been v4 only, but that's not what the charter ended up (fred) i sent an inquiry to the IAB last oct - move IPv4 as 'historic' - they didn't like that idea - in v6 OPS at the last IETF meeting we had a proposal from 5 ISPs who wanted to change the definition of 'IP' - e.g. specify in RFP that they want to do something about IP - define it so that it means IPv6, and IPv4 is optional - discussion in the WG was that that will be difficult - it suddenly reinterprets a whole lot of RFCs - is this the kind of direction you're suggeting - moving IPv4 to historic? (wes) no (fred) 'historic' doesn't mean 'no longer in use' - it means no more maintenance (wes) we read it - our interpretation was 'not in use' - i'm not opposed to revising the wording - but trying to get something out there that acknowledges that IPv4 by itself is not a valid direction going forward - if there is later push to make IPv4 historic, can do that, but this is just a first step - it could come from the IAB, but since didn't this is a step (alain) saying 'not v4-only' not good, but ipv6-only is not good recommendation at this point either - taking this recommendation to the letter we would stop work on v4, and then nothing would happen on the internet next 10 years (wes) not stopping v4, but trying to give IPv6 equal status - not optional anymore - that the IETF needs to focus on IPv6. not saying stop IPv4... (alain) if working on a solution that uses IPv6, but tunnels using v4, then by your definition would not do that? - or v4 over v6 - to make v4 only work, then reading your last bullet would not support this (wes) draft says transition technologies are acceptible (alain) devil is in details, and to get that right would take 500 pages - i like the idea saying 'take v6 more seriousy', but not the part about stopping working on v4 (wes) viewed this that how this gets applied will be up to individual ADs and WG chairs - acknowledge your concern, happy to wordsmith, but don't think we need to detail every permutation (scott) ... (jari) i do support the message here - especially that new implementations should support dual stack, and IPv6-only devices as well - that works in some environaments - but default should be dual stack - and to distinguish between what the world does and the IETF does... - question is whether we do new IETF work that is only IPv4 capable - i think we have been more or less following this rule (not to do this) the last few years - not always easy - e.g. one doc that does the v4 thing, and a later doc for v6? - do they both need to be in the same doc, or both in the charter? we have been making those judgement calls in the IESG... (margaret) this doc does two things - 1. tells implementers what they should do to be compliant with this RFC. ok... new implementations do this... - i won't object to that - i think the people who agree will pay attention, others who don't won't - 2. it tries in a BCP-like manner to constrain what the IETF works on - decide about what to charter - does work fit into BCP - i object to that - not that i think we should do new work that is arbitrarily v4 only, but i don't think there is anything wrong if v4 work is needed - don't hamper our best judgement - suggest take that out, and then i don't care about part 1 (wes) that is why as a SHOULD (margaret) the IESG has already decided to do this - there is already a policy in the IESG - is this BCP or standards track? (wes) standards track currently (jari) i have been filing those DISCUSSes quite a bit that say "can't do this because not v6" - having a BCP to point to would make that easier (margaret) is this a BCP then, not standards track - can't use a BCP for implementer guidance - don't see how this is one doc (wes) would appreciate guidance from jari about whether to break into two docs (alain) today we have tons of v4 stuff that will need maintenance. - talking about mechanism that is allowed or not, but there are cases where that is not true - we need to care about the legacy stuff (tim shephard) - 3rd point - IPv6 support must be equivalent... - if have flaky v4 support - hope that you could implement v6 that would be better, rather than 'equivalent' to v4 - (wordsmithing) - question that popped into mind - if have little node, want to add v6, do i have to implement IPsec? - draft doesn't mention this currently - sec considerations says 'no direct generated here...' - looked at bunch of RFCs to see if I have to implement IPsec - couldn't find out definitively if need to implement IPsec (wes) can bring this to v6 ops? - this is broken in the node requirements (narten) look at IPv6 node requirements doc... draft-ietf-6man-node-req-bis-08.txt - it has a nice long section on IPsec... (becarpenter) Fact: it is NOT broken in the documents. IPsec is not considered mandatory any more. (wes) unless the ADs have a recommendation of somewhere to take this, would like to get it to standard soon.. --------------------------------------------------------------------------- On demand IPv4 address provisioning in Dual-Stack PPP deployment scenarios, Karsten Fleischhauer --------------------------------------------------------------------------- - in IPv4 only network have direct coupling on PPP ... - we will see the demand increase because 100% are using voice services - would have to provide a v4 address to each in addition to v6 address - this brought us the idea to provide v4 address on demand, only when needed - what we're targeting is a PPP scenario - on slide 4 - in this scenario we have opportunity to lease a v4 address dynamically - using an existing network control protocol - different message - during our discussion with vendors we discussed why we cannot have other solutions - PPP for v4 and for v6 - there are reasons not to do this - double the AAA, scalability issues on the network access, additional config on the home gateway - additional PPP session, additional credentials - opportunity to introduce large-scale NAT is too expensive, maybe not necessary to have once you have introduced IPv6 - we have customer device that terminates PPP - needs to support dual-stack natively - slide 5 - there is a need on the network access server to recognize the messages from the home gateway - new messages to give the addresses back, or request them - based on IPCP - the mechanism itself is part of BBF-standardization - intend to introduce this year in the IETF - slide 6 - we can discuss ... the protocol flows - 4 blocks - establish the PPP session, which is IPv6 only - next block is assignning theIPv4 - then have dual stack connectivity - then releasing V4 if there is no v4 traffic - can terminate the IPCP - slide 7 - these detailed messages are not yet in the draft - will introduce in the next version - slide 8 - this is the signing of the IPv4 address parameters - slide 9 - sending a termination request - we are presenting this to the IETF community - we are looking for your feedback - would like to get some feedback on the messages - then at the next IETF discuss if the WG wants to adopt (eliot) thank you for your draft - interesting - it is an important area for all providers to think about - managing the tail of IPv4 - do you have information now that discusses the ability of the network - how much this would save? - that we don't need the V4 address eveywhere all the time, and could have some returned during normal operation? - do you get to a point - is there data - where v4 addresses would be released, or are PCs too chatty... (narten) Does this proposal require any PPP changes? I would assume not.... (karsten) similar as it is today for PPP - we will not terminate the PPP, only the v4 (eliot) do you have data in that department? (karsten) yes (jari) are you specifying new behavior, or just how to use the existing stuff? (karsten) usage of existing functionality - but it is useful to have a document that describes the special use case - to explain how we are using it in detail (jari) i think it would be useful to describe the use case - like eliot i wonder how much this would save - e.g. v4 device checking for software every few minutes - we looked at something similar in the mobile case and found it was not worth it (mark townsley) i have some similar worries to jari - another thing... - in the 90s wrote a lot of code for PPP, dailup - 'interesting traffic' will bring up the ISDN connection (in cisco code) - other stuff spoofed - because if billed by the minute you don't want it up all the time - there is a similar thing here - the valuable resource is the IPv4 address - the PPP code that is out there has been running for a long time - and now mostly in maintenance mode - the idea to give and take away address while keeping LCP there is 'new world' for those existing implementations - even if can find a few that would work, by and large not used to for a long time. either would need to restrict to a few well-tested devices, or just 'hope' not going to get a bunch of support calls when things break - could try to wake up the PPP extensions group, craig fox... - but this is taking an old settled protocol to new territory (??) how will this work? - usually getting / taking addresses is what OS(s) do - apps generally open a socket (karsten) if app is on home gateway, knows that v4 is possible, open a v4 socket... - (missed this) - discuss this further on the mailing list? (SwedeMike) (in jabber room) - what happens if someone needs to call TO the phone? - how is that signalled? -------------------------------------------------------------------- Reusing the IPv4 Identification Field in Atomic Packets, Bob Briscoe -------------------------------------------------------------------- (bob) this draft is about IPv4 - recycling the 16 bits in the header. motivation is adding something to v6 in CONEX and want to add it to v4 too - others want to add things to v4 also - and you need some bits in the v4 header - and the current extensibility mechanisms in there now are pretty unusable - in another space we are trying to do this in v6 - so in v4 need some innovative thinking - the reason extensibility is broken is the punting to slow path - to acknowledge rob hancock - need to put the options where existing kit will ignore - that is the principle behind it - so looking for a field that is currently ignored... - what happens is, as we need it, what we're trying to do is extend v4 header. atomic packet - from joe's draft - DF set, offset 0 - not fragmentable, and hasn't been fragmented. in those the ID field is redundent - this draft proposes how to use it (SwedeMike) should we really do this kind of work on IPv4? isn't it too late for that? (bob) people talking about different uses for this field, so would need a registry (jlcJohn) (in jabber room) - I love you, Bob, but this is IPv4-only work. (bob) how do you know whether it is coming from an implementation that is using this protocol, or just noise - use the reserve flag to free up the other 16 bits - that only works if the packet is also atomic - then your implementation knows it's talking to another implementation that understands - but then about 10% of the firewalls will drop those packets - (+/- 50%) - so what's the use of an extensibility protocol that gets dropped? - use that same ID field without the reserve flag set if all the other fields are 0 and the packet is atomic - have a way to send out packets that look like existing packets - but new implementations can probabilistically pick these out - for an initial experimentation - test out the code - it's got an incremental deployment path, with a deterministic bit at the end - but the probablistic part - you have to assume the other end is implemented, but may not - so only works if the result of that is 'no harm' - only works on atomic packets - IPsec uses ID field for AH - and problems with tunnel encapsualtion - tried to cover all of this in the draft - there are some non-trivial constraints. please read the draft and comment. - story for incremental deployment - a bit of a hack - is this too constrained a use to burn that bit? (SwedeMike) (in jabber room) - ECN hasn't been implemented since the 10 years it was invented, I don't see this getting traction for any widespread use before we're hopefully stopped using IPv4. (joe touch) the only observation to make - think it is reasonable - if we end up redefining the RC bit - it is supposed to be 0 - things don't check it - we think it's ok to redefine - but that is the level of the change - if we free up 16 bits to play with - should have an organized line for how to use those bits - lot of different uses for these bits possible (bob) tried to think of how to deal with that clamor - have to decide 'are we going to burn the one bit to allow some experiments that may not suceed' - keep the whole thing experimental initially ---------------------------------------- Stateless 4via6 Address Sharing, Woj Dec ---------------------------------------- (woj) a number of techniques derived from A+P have been recently proposed - tried to summarize the essential pieces of those - the progress has not been very strong in the IETF - stateless 4V6 - the NAT44 is inside the CPE - this is intended to relay traffic from v6 network to v4 public internet - not showing v6 on the user side here, assume ships in the night - other assumptions - NAT44 on the CPE - crucially, it is an address sharing solution using port ranges on the CPE - assuming that things like DNS would over v6 from the CPE - the issues: dave thaler collected some of these - in A+P there is ambiguity in v4 addresses - in the 4V6 domain we are addressing the CPE - so the issue doesn't seem to be applicable (thaler) actually I mainly collected them, not raised them (I agree with them but I can't take credit for them) (woj) two hosts on the same link sharing the same address... - and there are big changes to provisioning to roll out something like this - need to deploy v6 natively, and then need to provision the CPEs - that goes for many other solutions also - operators have been doing similar things for years - also useful to note that a number of the other solutions do introduce OSS challenges that this doesn't have - so it is a deployment tradeoff, not a technical show-stopper - has some advantages over some alternatives - but training and education challenges granted - v6 troubleshooting - we will be living in a port constrained world - developers need to learn this - but similar in any NAT44 approach - also claimed that security is compromised due to restricted port range - from a TCP perspective - doesn't appear that a smaller port range matters much - only 10 bit s - still challenge to do random - UDP/DNS it is a different case - aside from that, can do the resolution over v6 - extensions have been proposed to address this through port range randomization - another issue is that lack of ports causes problem with statistical multi-plexing slide 9 - so there is a tradeoff - - for any NAT44 technique lead to monetization of ports and the issue of re-addressing - in this case it is not the same type of problem - only need to change the address of the CPE - conclusion is that v6 re-addressing problem does not apply entirely, or in a more constained manner, with this solution - the majority of issues attributed to A+P do not seem to be applicable - there are tradeoffs in the areas of operations, scalability, and design and implementation - think it is time to progress some of these on standards track (lars) had two failed BOFs on this how many times to sit through these presentations? (ralph droms) INT area - translating 4 to 6 to 4 - are there issues that get lost in translation? (woj) calling it IPv6 adaptation function (ralph) so not looking at header translation? (mark) in response to the failed BOFs - what i see here is that you tried to scope this down so that some of the issues from before are now out of scope - smaller scope - trying to address a topologically limited solution space - i shared a lot of concerns originally with A+P - scoped down to CPE, it seems a lot more tractable (remi) talk was good - appreciate it (jari) i think we can find a home - softwires seems like the right place if we want to do this - the question is whether there is demand, does the community want to do this - this presentation was mostly going over issues - that is not enough from my perspective - i want to see demand to do the work - can you say something about that? (woj) the demand is certainly there - the demand is hit on the head with all the A+P issues that have been raised - a lot of this has been on the mailing list (jari) not just a question about IETF process - i don't think we want to standardize every possible approach to transition tools (woj) speaking for customers, there is interest in this (mohamed) there is a lot of state to be stored in the device - please don't stop one solution over the other - let the industry make the choice (alain) made the case that this was applied to limited environment and that got rid of the issues - take exception to that - starting to see more and more CPE acting like a host - has it own application - and then all the other stuff still applies (woj) this CPE provisioned by the service provider (alain) but all the issues remain - how do you know if you send a packet, but it is not you - different port - you need to change the logic related to addresses - you came to say that with the limited scope all the previous issues do not apply - but i don't think that is correct (??) dispelling the misconceived notion about this set of solutions - limiting to CPE reduces the issues - the IETF should not block based on the past discussion - once applied on the CPE side, many of the concerns go away (remi) about jari's question - i think the next presentation gets at that - providers - at least for one of these solutions there is running code (dave thaler) one reason i collected the list of issues was so that someone could do this kind of presentation - that was not specific to just A+P at the time - it was 5 or 6 similar things - not all issues apply to all of them - what happens if you plug a host in where intended to be a CPE (woj) CPE behind CPE will work fine (dave) instead of plugging in a NAT, a user plug in that spot instead - what happens - one outcome of the previous discussion - chartered PCP - encourage you to compare / contrast with the currently chartered stuff - and bring those up in the relevant working groups - e.g. in PCP, consensus that use of tunneling is better than translation - encourage you to do a comparison ------------------------------------------------------------------------------- The necessities of stateless 4-over-6 tunneling with address sharing mechanism, Satoru Matsushima and Jie Jiao ------------------------------------------------------------------------------- (jie) i will give the first part - then satoru san will follow up - from the matrix there are two kinds of models - also have two different kinds of solutions - stateful and stateless - the remaining part is stateless for IPv6 only core - so why standardize stateless for v6-only core? - this will be the main network service in the future - and prefer a stateless solution - since there are a number of advantages (slide 2) - slide 3 - we know that the users are identified by a dynamic address and port 'NAT log' - for stateless, users are identified by pre-assignned static address and port range - so there is less burden - for routing optimization - know stateful uses hub and spoke - stateless can use an optimal path (satoru) our network is currently v4 only - we decided to use v6 over v4 solution in 2010 -we are going to build v6 only network starting this year - so we need a v4 over v6 solution - right now there is only a stateful solution available (danwing) (on jabber) - the routing optimization doesn't work once there are overlapping IPv4 addresses in the ISP's network. (satoru) we observed the comparison - stateless solution is less expensive - operator needs to work with business guy - have to look at what is the most inexpensive solution - the issue is that there is no solution to stateless for IPv4 over v6 with address sharing mechanism (rajiv asati) how much of optimized routing part is really a problem - what % of traffic that would benefit (satoru) care about the latency - if customer uses P2P application that needs less latency need to use mesh topology (rajiv) heard that amount of traffic is less than 10% with this issue (satoru) not have exact percentage (ralph) can you comment on the additional complexity incurred by mesh compared to tunnel? (satoru) complexity is really stateful to stateless - it is easy to have hub and spoke also (??) as operator we share your opinioin - have you considered to deploy A+P? (?) see statement that logging is reduced i don't think that is a big advantage (mark) logging is simply a matter of ranges instead - when we created softwires we took many solutions and tried to come up with one - we came up with a couple, hub and spoke, mesh, then later DSlite, ... - and now hitting another phase - i like the matrix - we learned that there are stateful and stateless, and they have trade-offs - they are different enough that they deserve their own solutions - customers buying both - idea that you have stateful and stateless of DSlite problem space makes a lot of sense to me - would like to see that space described - two of the biggest ISP deploying v6 only are in japan and china - hearing 'we want stateless for 4 over 6' - at least in terms of an alternative (dan wing) route optimization doesn't work if there is v4 overlap - and if there is no v4 overlap then you don't need v6 - so doesn't work - this slide conflating two things - will take those to the mailing list (alain) understand stateful and stateless but advantages - .... - i think the community will benefit from an analysis of advantages and disadvantages of stateful and stateless ------------------------------------------------------------------------- Analysis of Solution Candidates to Reveal the Origin IP Address in Shared Address Deployments, Mohamed Boucadair ------------------------------------------------------------------------- (mohamed) document some of the issues in this space - we focus most on the NAT flavor - the context - the main requirement is to maintain v4 service continuity - need to rationalize the remaining addresses - maintain service, and allow additional customers without fragmenting the internet - so have to introduce NAT in the network - depends on the flavor of your NAT - in both v4 and NAT64, the customer facing interface can be encapsulated or plain v4 slide 5 - if the customer is mis-behaving, blacklist uses the source v4 address - then new customer tries to access same service (with same address) so will hit the blacklist - another problem - customer tries to connect using an infected machine, traffic redirected - all the customers sharing that address will be impacted (wes) a lot of this is covered in the address sharing drafts (mohamed) so need a host identifier - can be assigned by the address sharing device - must be unique - when to put this identifier? - all the packets, or only on the connection oriented messages? - blacklist uses v4 address and the identifier slide 10 - the document has an analysis of the possible solutions - (see matrix) slide 11 (lars) for the TCP solution - how many bytes in the option in the SYN? (mohamed) there are two variants (joe) a lot of the entries need to be re-checked - this is work in progress (mohamed) can we recommend a solution now? -or aware of the issues, but not recommendation yet - same issues as NAT64 (lorenzo) can we please just deploy v6 instead of wasting everyones time - and as service provider - requires bilateral agreements with all CGNs to make this work - very hard (joe) purpose is not to create new solutions - but rather to explain where all the bodies are buried - real purpose of this doc is to explain the space and the problems ----------------------------------------------------- Internet Routing Overlay Network (IRON), Fred Templin ----------------------------------------------------- (fred) regarding the presentation on stateful vs. stateless, i think that is incomplete without a study of IRON proposal - this has a solution for route optimization and mobility management, mobile interfaces, multi-homing.. - would like this to be included in the various analysis - it solves a bunch of problems not addressed by the other solutions (margaret) what fred just said - 15 min presentation for 15 min slot - need better scheduling next time --------------------------------------------------------------------- IPv4 Header Option for User Identification in CGN Scenario, Tina Tsou --------------------------------------------------------------------- slide 3 (tina?) CGN inserts an IP option pro - implemented at the IP layer con - packet dropped by middle router - should be fixable by only a few edge AS(s) con - slow path processing (alain) issue is that you need to do something special to every router on the planet - that is a heavy price (?) only need to do it in a few routers