Internet Area Meeting 20/3/2006 - Coronada Meeting Room ADs: Margaret Wasserman, Jari Arkko & Mark Townsley Minutes: Danny McPherson Jabber logger: Dave Thaler? ----- Margaret: Agenda Overview - Full agenda here: http://www3.ietf.org/proceedings/06mar/agenda/intarea.txt Agenda Bashing - No Comments Introduce Jari Arkko - New Internet Area Director Jari details slide of Mark & Jari WG Split within Internet Area. ----- 3 BOFS in Internet Area this meeting: - 16NG - IPv6 over Foo (802.16/WIMAX) o Multiple COnvergence Sublayers o Multiple SDOs involved o Wednesday 1300-1500 - L2CP: Configuration of access devices o Protocol to control L2 operation of access devices o Name will probably change, comes from origination in Frame Relay forum. o Related to IETF GSMP work o Wednesday 0900-1130 - NEA: Network Endpoint Assessment o Ability to assess the status of devices before they attach to the network o Solution likely involves EAP methods to pass information o Tuesday 1520-1720 - Another related BOF in Security Area: - Hoakey: Handover Keys and Pre Authentication o Potentially related to mobility and network access groups o Thursday 0900-1130 ----- Declined BOF: Practical Anycast pointer here: http://anycast.anarg.jp ----- Some WG News - MIPSHOP WG o Completed Previous WG items o New Charter, Pending - NETLMM WG o New group, approved in JAN o Local, network-based mobility o Working on solution - MONAMI6 WG o Initially not going to meet here o They are now meeting on Tuesday 1850-1950 - SHIM6 WG o Discussion on whether SHIM6 satisfies requirements o Intra-site TE issues to be discussed - L*VPN WG o Security & multicast - PWE3 WG o Multi-segment PWs being discussed o MPLS/IP PW (open mic discussion at end) - SOFTWIRES WG o Had a successful interim meeting o Consensus at meeting brought to list, reviewing here ----- Area Document Status - -fenner-iana-exp-2780-02 o Defines experimental values o IESG Eval - -bagnulo-cga-ext-01 o A TLV structure for SEND CGA address inputs needed by shim6 o IESG Eval - bonica-internet-icmp-01 o Past discussion in this group o document revised o need to complete discussion - bagnulo-ipv6-rfc3480-update-00 o shim6 spin off o vast discussion o no home currently, need to decide to proceed - laganier-ipv6-khi-01 o "identifier space" for IPv6 o spinoff from HIP WG o needed for HIP implementations to avoid referral problems o Need to see if revision satisfies concerns ----- Margaret Wasserman: Experimental Values Discussion - Document provides specific values for use in experiments - Experiments can run before permanent allocations are required - Describes existing experimental allocations for: o Link Local and scope-relative IPv4 multicast addresses o IPv4 option number & IPv6 option type o IPv6 ND option formats o ICMPv4 type numbers o UDP & TCP system port numbers o TCP Options numbers - IETF LC complete - In process of resolving IESG discusses comments addressed in -03 that has not shown up in ID directory yet - hope to publish this week documents that don't go out this week will have to be re-reviewed per IESG churn this year - Values should be available for experimental use soon ----- Margaret Wasserman: IPv6 issues - Many documents come to IESG with IPv6-related issues: o mistakes in use of IPv6 o failure to note differences from IPv4 o ignore IPv6 entirely without explanation - Embarassing when this happens in INT area documents - Differences in addressing architecture - Frag & MTU - Neighbor discovery v. ARP - IPv6 Documentation Prefixes - IPv6 not just bigger addresses - no IPv6 broadcast address - use All-Nodes mcast addy instead - There is an IPv6 loopback address - IPv6 addresses with embedded IPv4 addresses - Use IPv4-Mapped IPv6 address, IPv4-compatible address is deprecated - use NON-deprecated addy Q: Why would anyone use these? R: Not sure, but if so... - Scoped Unicast Addressing o Link Local & Local Addresses which is more appropriate - local or global? o Support for ULAs Not a direct map to IPv4 net 10 addresses o ULAs are probalistically unique, so a nide can be on more than one local network at a time o Has implications on how you get these addresses o Useful for local or private addressing - MTU & Fragmentation Issues o Minimum required MTU in IPv6 is larger than that of IPv4 o IPv6 routers do NOT fragment packets o PMTU is mandatory o ALL fragmentation happens at the source o Comes up a lot in many of the tunneling protocols o Many times academic discussions but need to be addressed - ND v. ARP o IPv6 uses ND for address resolution o IPv4 uses ARP o ND is ICMP-based o Uses solicited-mode multicast addresses o Combines address resoltion with host auto-configuration and reachability detection o Multicast must be supported for address resolution Dave Thaler: (MISSED COMMENT about MULTICAST) IPv6 Address Documentation: RFC 3849 - Is IPv6 required? No IETF-wide policy that requires IPv6 be supported, but essentially, we do require it. If omitted and no information provided. Adding support usually ranges from trivial to simple, though sometimes quite complicated. Question to room: Should IETF be required for new IETF protocols? Pekka Savalo: IETF guidelines document has guidelines, but not hard rule. Bernard: Should be discussed in charter - not a last minute item. It should be clarified before it goes to the IESG. Geoff Huston: It would be easier to make it clear in charter. I.e., shim6 says charter excludes IPv4 explicitly. Make it clear in charter Jean-Paul: IP-CDN working on MIBS. Explicit mention in charter that IPv6 would be supported but after a couple years work just IPv4 you end up relaxing IPv6 requirements Tim: Only fair if it's in the charter - should IPv6 considerations section be required? Bob: Charter is the right place for this and what the WG is expected to do. MW: If int-area WG chair and don't know whether you're supposed to support you should ask Jari or Mark John Loughney: My guess is that there should be a general assumption that if charter isn't explicit then the correct assumption would be that both should be supported NAME?: Document like 3 years ago about IETF specifications re: lack of IPv6 support. Don't want to redo this in a couple years - hope every specification would support it unless good reason exists not to. Should be required by default MW: Left to discretion of ADs and community at the moment nothing explicit exists to date ----- IPv6 in CableLabs DOCSIS 3.0: Ralph Droms - Working on new revision of DOCSIS specifications - IPv6 will have key role in DOCSIS specification Discussion about: - Motivation: Why IPv6 in cable networks? - DOCSIS 3.0 modems in IPv6 - Deployment Scenarios; how is IPv6 used Details here, draft will be posted to IETF ID repository soon: http://www.cablelabs.com/downloads/ietf/draft-mule-cablelabs-docsis3- ipv6-00.txt Why IPv6? - provisioning and management of end devices (CM, MTA, STB) o some MSOs running into RFC1918 addressing limitations o video set top boxes becoming DOCSIS provisioned create a surge in IP address demand - provide IPv6 connectivity within the home Mode of Operation - DOCSIS 3.0 modems will be IPv6 ready (dual stack) - Detailed slide CM Features - CM can pass IPv4 or IPv6 - CM is provisioned with DHCP or DHCPv6 o no stateless autoconf - Some CM will operate as a L2 Bridge, some as L3 routers o misc details on this... Slide with detailed DOCSIS 3.x IPv6 Example Architecture Slide on Address Configuration choices - Why DHCPv6 for CM address allocation - How can a CMTS force DHCPv6 ? - The rest is plain vanilla IPv6 Comment on Slides/Architecture from from Dave Thaler Jim Bound: Discussions about privacy, 3041, etc.. PARAPHRASED: How do I make sure that DHCPv6 data is in sync? Discussion about anonymizing, etc.. I may NOT want my ISP to have knowledge of my lower 64 bits anytime, etc.. Dave Thaler: 3041 prevents tracking and something else.. someone who moves, etc.. Pekka Savalo: Comments about keeping state of addresses Conclusion: IETF Takeaways - Lots of dual-stack devices - some will be IPv6 only - CMs are tip of the iceberg - other set top boxes tomorrow - these are closed systems, not a lot of other stuff that has to be considered - DOCSIS 3.0 depends on IETF specification on DHCPv6 options ------ Issues with Protocols Proposing Multilink Subnets: Dave Thaler - IPv6 considered multilink subnets and rejected it - Multiple variants of multilink subnets exists - seems to be fragmenting - Slide on why IPv6 WG rejected Multilink subnets o affects arbitrarily large number of upper layer applications o DAD, TTL, Security, Mutlicast, etc.. - 2462 allows for implementation allowed for duplicate interface identifier detection; no longer recommended but there are implementations that do this - TTL/Hop Limit Issues Slide - Security Issues Slide o Some want support ND proxies o Some applications and protocols mitigate against off-link spoofing attempts by requiring TTL/HopLimit on receipt - if removed, mitigation against threat removed - Link-scoped multicast/broadcast slide Thomas Narten: Comment about brokenness being binary rather than it working under defined scenarios -Discussion: Should we: a) Stick to classical IP model? o update MIPv6 o provide guidance to other WGs b) change the IP model? o update many upper layer protocols o update many applications o update documentation o etc.. c) Continue fragmenting Thomas Narten: prefer option a, but don't understand MIPv6 bullet, can you explain? Dave Thaler explains [very quickly] Hesham S(?): see several different categories of issues.. MISSED THE REST OF HIS COMMENTS: Is there an option D? ---long discussion ensues with Dave & Hesham--- Comment: How does option A work in MANET environment? Comment: Is it possible to avoid DAD is mutual assurances that no addressing conflicts exist? Dave: YES, but there are other issues Margaret Wasserman: I would pick option A except when it's not the right choice - would love to see model documented, education, and then understand when exceptions may have to occur. Jari Arkko: Agree with Margaret. Would like to understand exact scope of this problem - what are other cases in IETF where this problem occurs - e.g., VPNs? Dave: Discussed in NETLM, AUTOCONG for MANET, MIPv6, etc.. At least 3 or 4 different areas that need to take this into account Greg Daly(?): Need to be careful WRT multicast issue. Some discussion about multilink or multisegments within a link? Are we pushing the problem down the stack and is that the right solution? Dave: Yes, and good question. Pushing down to Layer 2 - whether that's the right thing or not is a question Bernard: Having another RFC that says thing doesn't impact the process - publishing something doesn't make anything happen. Dave to ADs: What should the next step be if any? Jari: Document history in more detail and discuss, agree with Bernard but need to impact WGs that are doing this stuff. Margaret: who's read the draft, would like to see discussion on INT Area mailing list. please comment there. ----- Routing Protoocl Standardization Criteria: Mark Townsley - About how it affects the Internet Area - Also being discussed in RTG Area Open meeting - Note about running code: o w/o running code wasting our time o not about implemntation experience being good or bad, about where to freeze the document and publish RFC - RFC 1264 background slide o Informational RFC Bob Hinden: only had informational RFCs then! o Predates 2026 o reflects thinking of IAB at the time o refers specifically to IGPs & EGPs o outlines additional procedures to standarize routing protocols - Motivation o Routing protoocols are: ..... o should be subject to more stringent critera as specified in the document - RFC 1264 Current Impact o discussed in fenner-zinin-rtg-standard-reqts-01.txt o additonal requirements defined at proposed standard - must have MIB - key features tested - two interoperable implementations MUST exist (like DRAFT Standard) - Scoped beyond EGPs and IGPs o LDP & RSVP-TE subject to requirements - Currently effecting many INT AREA WGs - Escape procedures defined - features can go on EXP track, IETF LC for variance can occur - Process Summary Slide and explanation provided - Obvious Questions for the INT Area o Why does this effect me? Criteria targets protocol, not area. o RFC 1264 is not binding IETF consensus o RFC 2026 does allow demaninding additional criteria o RFC1264bis if/when will be officially binding process - Will this slow down my draft getting to RFC? o probably - at least for PS - What about IPv6? o IPv6 implementations without 2 implementations will advance on EXP, or a variance requested via LC - Will our documents improve if we do this? o Yes & No: implementation experience is good but some issues (e.g., IPv6) will arise - What about newtrk? o can only affect some day in the future, we have to decide what we are doing today o a significant change in standards track procedures resulting from the newtrk effort could render RFC1264bis obsolete - What about my document - do I need to write an implementation report? o Be prepared if you're going toward PS o Lots of INT area documents in queue waiting on implementation reports o can INT area and RTG keep separate policies on this for routing protocols? - NO, doesn't make sense - Comments? o routing-discussion@ietf.org o http://rtg.ietf.org o rtg-area meeting this afternoon Thomas Narten: Concern with this - well intentioned but world has changed since when this was put out. If an ISP wants to deploy something internally and hasn't checked, let them. The purpose of this is to make sure we don't deploy something totally broken and horribly complex and we want to avoid that. Is this something that's a real issue today? Mark: Creates work today, have to see if documents fall under criteria - but it is a lot of process. Bob Hinden: Folks in routing area hate this as well. The world is different - the reasons that caused us to write this was ideas out of the IESG that they were seeing a lot of potentially new routing protocols and they weren't going to work and there was harm there and wanted to raise the bar for creating standards and this was seen as the way to do that. The way the system has evolved implementations don't seem to be cared about at all now. Don't know what's in all the documents blocked by discuss - intent was for new routing protocols - whether changes to new routing protocols should be applied here it should be applied with some analysis that it shouldn't be applied blindly Alex Zinin: The world has indeed changed. The primary motivation changed from preventing routing meltdowns to ensuring that specifications put on standards track such that independent interoperable implementations can be developed based solely on the specifications. This is a very real problem based on my experience in the IESG. Main point is making sure specifications have enough details. Dave Thaler: Implementations v. feature tests IPv6 questions becomes subjective thing and differences arise. Could classify as major feature - or not. MISSED ADDITIONAL COMMENTS. Ross Callon: beginning to wonder if "major" is the right word for the feature. Use of word "major" v. risk are very different. Wondering if it's risky features that should be tested rather than "major". Rules can't be perfect and must have some common sense about how they're applied. Mark Townsley: All comments: please feel free to reiterate opinions in RTG WG there as well. Sounds like what I'm hearing is that at the end of the day we're going to have to use out judgement. To Alex's point about how these reports improve the quality of a document - they do - that's why we have Draft Standard. The question becomes how much we allow ourselves to use our own judgement to Joao??: Judgement call must be contract between IESG and WG - not a last minute surprise. Mark: yes, needs to be defined up front - really affects how the WG operates. John Loughney: First implementation protocols tend to be done by students, etc.. Can be very different than what's deployed in production - may not actually see what people really do. Mark: When you have these folks producing implementations it's a different mode. All good points, please make them again. ----- MEETING Adjourned - 1720