IPv6 Maintenance - 6man Minutes - IETF 71 Wednesday, March 12, 2008, Morning Session I, 0900-1130 Room Name: Franklin 13 Bob Hinden, Brian Haberman, chairs Minutes taken by Lucy Lynch. ----------------------------------------- Bob conveyed regrets for Brain Haberman who is completing his PhD and couldn't attend the meeting. Agenda http://tools.ietf.org/wg/6man/agenda Agenda Hash - Request to add one short talk ------------ Node Requirements Update - John Loughney (remote via phone) draft: http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.txt Slides: http://www3.ietf.org/proceedings/08mar/slides/6man-2.pdf IPv6 Node Requirements - bis (see slides) - Current Status - Potential Issues -- doing general requirements, not specific, but could consider adding informative appendix on DOD stuff -- DOD to send info to the list - Status of the draft -- INFO status in question - make this standards track? --- D Thaler, ST means implementers can claim conformance MAY/MUST/SHOULD language would hold B. Hinden, Agrees, make it ST, don't use it to fix bugs in other parts of the system. Establishes clarity. - Security -- active discussion re: mandatory mechanism - Security next steps -- drop the SHOULD for ESP? --- ? requirement for IPSec in draft ? (Bellovin) Open discussion on Security before cleaning up the draft. Hinden - questions, and then poll --- Pekka S - early drafts had sec text, removed after IESG review, need to engage Sec area Jari A - agrees, RFC 2460, any others that inform requirements? Need Sec AD attention Fred T - relationship of draft to DOD and NIST documents John L - need analysis of where docs differ, then add appendix Thomas N - There is NO relationship, reference docs will be cross reviewed but not aligned. Wes B - question, refs to other RFCs, is there traceability study? BH - are you volunteering? JL - has tried not to make new requirements and refer others back to docs that need update. Ed Jankiewicz- DISA/DOD do see relationship of docs, draft is a source, but may need to state additional requirements offered to do side-by-side. Will work on appendix text and will take it to the list. Just did traceability on IPsec - useful exercise. Support that here as well. Pekka S - doesn't support a DOD appendix, need to understand, but diffs should be in their docs. IPsec - MUST for ESP, so may need to look at changes. Doug M (NIST) - don't site node requirements in their docs, have looked at diffs - should go in DOD doc JL - thanks Alain D - ESP/SHOULD - in the node requirement, if you want to implement, see other RFCs, Wes B - scope of node doc is different from DOD profiles, keep in mind Dave T - agrees with Alain (IF/than SHOULD.) BH - making Standards Track would allow first order refs on IPsec. poll, non-binding, small response - more favor ST then oppose, -------------------- IPv6 Subnet Model - Erik Nordmark draft: http://www.ietf.org/internet-drafts/draft-wbeebee-on-link-and-off-link-determination-02.txt slides: http://www3.ietf.org/proceedings/08mar/slides/6man-0.pdf - Agenda - Updates - Recap -- Dave T - on-link comment is true for v4 sub-nets but not all links EN - agrees - IPv6 subnet model - What becomes on-link -- static configuration needs clarification - Observed v6 inter-op issues - Consensus Call -- Dave T - this is great, might ref other off-link models not just configuration - may be no model, legacy, etc. EN - API issues, see other docs... BH - thinks we should take on, what status? EN - Standards Track (ST)? Clarify docs in DNS are often ST so they can be found JA - This is informational EN - findablity JA - could go either way Hemant Singh - should be ST (MUST/MAY) EN - agrees as Static cfg was added JA - new info, should then in ST DT - still could go either way, more like basic socket's APIs BH - not quite the same as APIs Jinmei Tatuya- not strong opinion either way, but is goal is to reach operators, ST may be better Remi Denis-Courmont - supports ST BH - any objection to taking this on - none - taking on as new work. ------------- Address Selection - Arifumi Matsumoto draft: http://www.ietf.org/internet-drafts/draft-ietf-6man-addr-select-sol-00.txt slides: http://www3.ietf.org/proceedings/08mar/slides/6man-3.pdf - status of addr-select docs -- 4 kinds of approach - scope of the problem - Problem Example: NAT replace - Problem Example: ULA (both taken from v6ops PS doc) - Problem Summary -- goal: narrow down the solution space -- JinMei T - not sure UAL example is suitable AM - (missed comment) JT - introduce imaginary scope AM- may be able to add one line fix EN - at introduction of ULA, host doesn't need to change, host-to-host comment (lost) Tony H - ULAs exist because of local address, points at the wrong prefix, really is a local scope problem. Change rules DT - 2 mechanisms, using scope or table - row in table is simpler how do you get cfg out of the host without changing specs | Remi - need ? | DT - | Remy - private addresses? | DT - doesn't matter | Remy - | DT - just follow the RFC on ULAs | Remy - BH - take this off line - two possible approaches - Analysis of mechanisms in approach b) -- EN - questions now? BH - finish last slide -- Conclusions & Next Steps -- EN b) slides - not completely static (periodic updates) w/ DHCP won't scale as rapid RD - yes EN - don't know if the host will support, what happens when requests aren't honored (Q&A) - fail back to old DT - agrees with EN, requirement to host multiple connections sites requirements must work with multi path. second comment - an approach that Christan proposed like Q&A that was passive AM - in category A DT - thanks TH - information from multiple sites and selection of best DT - agrees TH - need hints DT - just like router prefs are a hint TN - need to work in space, need to sketch out the Arch. source and destination, forwarding all needed, host may not have information. Making hints scale. Security considerations come with hints. Convergence isn't fast enough AM - agree, that's the problem EN - not looking for prefect, looking for better, more flexible 3484 already has one step in selection (interface) Look at policy tables - not creating a priory rules. AM - DNS server option (host constructs DNS info) - implementation specific (ie. windows) DT - Erik was it right destination selection is hard, source selection is a bit easier, leverage the look ups already done. Constrained source addresses (easy case). Not always "best" address - may not be the same in every case. long-term efficient vs reliable example. Update 3484 want want to allow client to select "best" type. AM - trying to optimize local policy. DestAdd selection - may be solvable re: EN suggests. JT - need to understand history - key point is w/we want general solutions simple ones seem easy. in WG last call? AM - yes EN - hasn't read v6ops docs - what about multiple prefixes problem? Having a way to provide a policy table helps. M - ingress routing is future work BH - WG not ready to close, may want to start side conversations, may need a 3484 update. if we use table update model, that needs to be fleshed out. ----------------- Address Selection 2 - Fujikawa Kenji Source Address selection using just routing information draft: http://www.ietf.org/internet-drafts/draft-fujikawa-ipv6-src-addr-selection-03.txt slides: http://www3.ietf.org/proceedings/08mar/slides/6man-6.pdf - RFC3484 src-addr selection rule 8 -- longest matching prefix - An Unsuitable situation (for rule 8) - A proposed method -- use global add instead of link-local for interfaces -- longest match to next hop - Some Issues -- End Node can use default, not best path - Discussions -- update 3484 to include next hop -- informational rfc suitable as one implementation -- TH - on proposed method, could work but will not work if ISP 1 isn't connected to ISP 3 - same as private network problem. Was not solved problem FK - expect available routes TH - may not connect to anything else DT - doesn't solve that problem, doesn't intend to see other draft (?) EN - If you run a RP, your next hop will be link-local address FK - need global add EN - routing protocols don't work that way CM connections? FK - talking about single instance - application doesn't supply source add EN - solving only a very narrow case, won't help in other cases. TN - AddSel hard problem, this is one scenario where the rules don't work, but fix may add more complexity in working simple rule cases. Need larger view. Needs to be more flexible. FK - Makes matching case better. No gap in choosing routes or SA DT - Link-local - expecting them to move the announce strategy may need two instead of one - host remembers scenario arises again. JT - isc - Using GA for routers - deprecate default router? FK - answer in no, don't modify RAs JT - seems won't introduce positive change BH - wrap up, feedback from the discussion is that the solution is not worth the cost of larger changes. Please take further discussion to the list. ------------------- Hop by Hop Options - Suresh Krishnan draft: http://www.ietf.org/internet-drafts/draft-krishnan-ipv6-hopbyhop-02.txt slides: http://www3.ietf.org/proceedings/08mar/slides/6man-4.pdf - why are they dangerous? - What is the attack? - Proposed Solutions (1) -- deprecation - Proposed Solutions (2) -- skipping EN - isn't that what you would do anyway SK - no, process in order EN - understood - Proposed Solutions (3) -- rate limiting - Conclusion -- agreement on 2? EN - doesn't solve new problem, implementers have experience don't need to charge protocol. Removing HbyH is counter-productive SK - expands attack vector EN - receive one,, send one - may flag to implementers, but not worth expanding SK - why should we process all steps if the information isn't being use. EN - in place for trouble shooting. Router alert is there for a reason HS - Not sure draft is needed, implementers already aware. Rating limiting is an acceptable solution. TN - no problem to be solved JA - careful about introducing new things, not sure this is a real problem - resource run-out issue. PS - There is a problem, with the assumption that HbyH is a good signaling mechanism. EN - advise folks not to do hop-by-hop flows. Rate limiting is necessary, so mitigate use of h-by-h TN - problem to solve - waste of resource caused by h-by-h processing, look at why h-by-h is proposed. BH - worth documenting, but not ST TH - maybe, but H-by-H doesn't get any traction BH - skinny part of the network... PS - Give some direction re: H-by-H - need a consensus doc that gives recommendations - BCP ? (french accent) - ambiguity about h-by-h - first option best. TH - BCP is the wrong answer, and documenting should be done carefully - don't tell people how to run their networks. Note performance impacts. EN - target audience, IETF standards groups SK - DDOS TN - how frequent if multiple send SK - attacks TN - can't note every attack vector every time. H-by-H can be useful, may prove valuable SK - extension headers BH - please take to the list --------------- IPv6 Extension headers - Suresh Krishnan draft: http://www.ietf.org/internet-drafts/draft-krishnan-ipv6-exthdr-01.txt slides: http://www3.ietf.org/proceedings/08mar/slides/6man-5.pdf - Extensions headers - Unknown Extension Headers - Advantages of a standard format - Proposed Format - Backward Compatibility - Ways Forward -- TH - no problem with concept of standardizing formats, but don't pick firewall as example of skipped header! EN - haven't created many new ones - hard to do - IP protocol numbers best thing to do, reserve values - hard to do. James W - third way forward, don't do a damn thing - airport apple guy -coder - firewall products - long example on AAAA records problem - upper layer header, not extension header. Firewall screening. JieMai - may need to deal with evil devices. standard format would help coders. EN - responding to James - use this format for new extensions, won't help unless we know which protocol numbers BH - to late to partition PNum space SK - wasn't born then ;-) BH - fine to have a document, not sure it solves a problem. ---------------- RA/RS Extensions to Support Mobile IP Proxies -Domagoj Premec for patil et al) draft: http://www.ietf.org/internet-drafts/draft-damic-netlmm-pmip6-ind-discover-03.txt slides: http://www3.ietf.org/proceedings/08mar/slides/6man-1.pdf PMIP6 - problem Statement -- PS ? how can there be multiple hosts on a link DP see next slide - overview -- TN - base assumption of NETLMM was that no host change requirement was needed? TN - what is the status of the draft, is it well received in ??? DP - individual draft TN - how is it accepted? SK - defends mobility considerations DT - opt out model JA - view as link layer tech, local mobility and only renegotiate when you move away from local node. picture doesn't seem to show a win in terms of internet traffic. Raj - way for the host to figure out if it's a home prefix or use PMIP - Proposal - Option layout - flags - new prefix information options - Next Steps TN - pre-mature to take on as WG item RD - which WG? DP - not sure - mobile Ip SK - NetLMM or --- looking for feedback PS - easiest approach may be to add new code values (RS/RA) EN - current spec says ignore? There has been other discussion around mobility - stability vs mobile in router announcements flagging properties might be useful less sure about this - modifying RA Need to understand bigger problem DP - prefix discussion mech DT - understand the model - opt out, allows a host to drop out of mobility (host isn't required to change) Use of RA isn't wrong, weird part is this real point to point or single host. SK - RA is unicast RA DT - changing RA/RS model - neither option normal model TN - Unified model is good for sending info, Network operators choice to opt in or out. Wonder why this is better than NetLMM JA - suspect the RS part won't work in current model, to early to talk about this work - back to NetLMM which needs to complete. BH - thanks! out of time ---------------- Meeting adjourned ----------------