Last Modified: 2004-09-09
| Done | Submit A Flexible method to manage the assignment of bits of an IPv6 address block to the IESG for Informational. | |
| Done | Submit Flow Label specification to IESG for Proposed Standard. | |
| Done | Submit Prefix Delegation requirements and submit to IESG for Informational. | |
| Done | Revise Aggregatable Unicast Addresses (RFC2374) to remove TLA/NLA/SLA terminology. | |
| Done | Draft on Proxy RA solution for prefix delegation. | |
| Done | Submit IPv6 Node Requirements to IESG for Informational. | |
| Done | Submit Site-Local Deprecation document to IESG for Informational. | |
| Done | Submit Unique Local IPv6 Unicast Addresses to IESG for Proposed Standard | |
| Apr 04 | Submit Link Scoped IPv6 Multicast Addresses to IESG for Proposed Standard | |
| Apr 04 | Submit IPv6 Scoped Addressing Architecture to IESG for Proposed Standard | |
| Apr 04 | Submit TCP MIB to IESG for Proposed Standard | |
| Apr 04 | Submit Site-Local Deprecation document to IESG for Informational | |
| Apr 04 | Submit Unique Local IPv6 Unicast Addresses to IESG for Proposed Standard | |
| May 04 | Submit update to ICMPv6 (RFC2463) to be republished at Draft Standard | |
| May 04 | Submit Router Preferences, More-Specific Routes, and Load Sharing to IESG for Proposed Standard | |
| Jun 04 | Resubmit Node Information Queries to IESG for Proposed Standard | |
| Jun 04 | Submit updates to Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461) to be republished at Draft Standard | |
| Jun 04 | Submit Proxy ND to IESG for Informational | |
| Jun 04 | Submit update to IPv6 over PPP (RFC2472) to IESG for Draft Standard | |
| Jun 04 | Submit update to IPv6 Address Architecture to the IESG for Draft Standard | |
| Aug 04 | Submit Update to Privacy Extensions for Stateless Autoconfiguration document (RFC3041) to the IESG for Draft Standard | |
| Dec 04 | Submit document defining DAD optimizations to the IESG for Proposed Standard | |
| Jan 05 | Re-charter or close working group. |
| RFC | Status | Title |
|---|---|---|
| RFC1883 | PS | Internet Protocol, Version 6 (IPv6) Specification |
| RFC1884 | PS | IP Version 6 Addressing Architecture |
| RFC1885 | PS | Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) |
| RFC1886 | PS | DNS Extensions to support IP version 6 |
| RFC1887 | I | An Architecture for IPv6 Unicast Address Allocation |
| RFC1888 | E | OSI NSAPs and IPv6 |
| RFC1897 | E | IPv6 Testing Address Allocation |
| RFC1970 | PS | Neighbor Discovery for IP Version 6 (IPv6) |
| RFC1972 | PS | A Method for the Transmission of IPv6 Packets over Ethernet Networks |
| RFC1981 | PS | Path MTU Discovery for IP version 6 |
| RFC2019 | PS | Transmission of IPv6 Packets Over FDDI |
| RFC2023 | PS | IP Version 6 over PPP |
| RFC2073 | PS | An IPv6 Provider-Based Unicast Address Format |
| RFC2133 | I | Basic Socket Interface Extensions for IPv6 |
| RFC2147 | PS | TCP and UDP over IPv6 Jumbograms |
| RFC2292 | I | Advanced Sockets API for IPv6 |
| RFC2373 | PS | IP Version 6 Addressing Architecture |
| RFC2374 | PS | An IPv6 Aggregatable Global Unicast Address Format |
| RFC2375 | I | IPv6 Multicast Address Assignments |
| RFC2450 | I | Proposed TLA and NLA Assignment Rules |
| RFC2452 | PS | IP Version 6 Management Information Base for the Transmission Control Protocol |
| RFC2454 | PS | IP Version 6 Management Information Base for the User Datagram Protocol |
| RFC2460 | DS | Internet Protocol, Version 6 (IPv6) Specification |
| RFC2461 | DS | Neighbor Discovery for IP Version 6 (IPv6) |
| RFC2462 | DS | IPv6 Stateless Address Autoconfiguration |
| RFC2463 | DS | Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification |
| RFC2464 | PS | Transmission of IPv6 Packets over Ethernet Networks |
| RFC2465 | PS | Management Information Base for IP Version 6: Textual Conventions and General Group |
| RFC2466 | PS | Management Information Base for IP Version 6: ICMPv6 Group |
| RFC2467 | PS | Transmission of IPv6 Packets over FDDI Networks |
| RFC2470 | PS | Transmission of IPv6 Packets over Token Ring Networks |
| RFC2471 | E | IPv6 Testing Address Allocation |
| RFC2472 | PS | IP Version 6 over PPP |
| RFC2473 | PS | Generic Packet Tunneling in IPv6 Specification |
| RFC2497 | PS | Transmission of IPv6 Packets over ARCnet Networks |
| RFC2507 | PS | IP Header Compression |
| RFC2526 | PS | Reserved IPv6 Subnet Anycast Addresses |
| RFC2529 | PS | Transmission of IPv6 over IPv4 Domains without Explicit Tunnels |
| RFC2553 | I | Basic Socket Interface Extensions for IPv6 |
| RFC2675 | PS | IPv6 Jumbograms |
| RFC2710 | PS | Multicast Listener Discovery (MLD) for IPv6 |
| RFC2711 | PS | IPv6 Router Alert Option |
| RFC2732 | PS | Format for Literal IPv6 Addresses in URL's |
| RFC2874 | PS | DNS Extensions to Support IPv6 Address Aggregation and Renumbering |
| RFC2894 | PS | Router Renumbering for IPv6 |
| RFC2928 | I | Initial IPv6 Sub-TLA ID Assignments |
| RFC3019 | PS | IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol |
| RFC3041 | PS | Privacy Extensions for Stateless Address Autoconfiguration in IPv6 |
| RFC3122 | PS | Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification |
| RFC3146 | PS | Transmission of IPv6 Packets over IEEE 1394 Networks |
| RFC3178 | I | IPv6 multihoming support at site exit routers |
| RFC3306 | PS | Unicast-Prefix-based IPv6 Multicast Addresses |
| RFC3314 | I | Recommendations for IPv6 in 3GPP Standards |
| RFC3316 | I | IPv6 for Some Second and Third Generation Cellular Hosts |
| RFC3484 | PS | Default Address Selection for Internet Protocol version 6 (IPv6) |
| RFC3493 | I | Basic Socket Interface Extensions for IPv6 |
| RFC3513 | PS | IP Version 6 Addressing Architecture |
| RFC3531 | I | A Flexible Method for Managing the Assignment of Bites of an IPv6 Address Block |
| RFC3542 | I | Advanced Sockets Application Program Interface (API) for IPv6 |
| RFC3587 | I | IPv6 Global Unicast Address Format |
| RFC3697 | Standard | IPv6 Flow Label Specification |
| RFC3769 | I | Requirements for IPv6 prefix delegation |
| RFC3879 | Standard | Deprecating Site Local Addresses |
|
IP Version 6 WG (ipv6) Thursday, November 11 at 0900-1130 =================================== Chair(s): Robert Hinden <bob.hinden@nokia.com> Brian Haberman <brian@innovationslab.net> Agenda: - Agenda Bashing Haberman 04 Minutes dupont - requests time to speak about getting /16 prefix allocated for crypto generated id's. hinden - if we have time haberman - tahi interop test announcement - similar structure to previous tahi tests, some new things for ike, nemo, etc. more info at tahi web page. - Document Status Haberman 01 Minute http://www.innovationslab.net/~brian/IETF61/IPv6/IPv6DocumentStatus.html no issues or comments on document status - Milestone Updates Hinden 10 Minutes http://www.ietf.org/html.charters/ipv6-charter.html chairs have worked with ADs to update charter milestones. the things-done list is bigger than the to-do list :). hope to get outstanding work done within next couple of ietf meetings. - Node Information Queries Hinden 10 Minutes - Goal: determine direction of the work last draft is -10, now shipping in several implementations. need to get this published. was consensus after vienna provided some clarifications on privacy addresses are made. plan was to make those changes and then submit as PS. is there anyone interested working on this? author hasn't been active lately. no questions/comments - Privacy Addresses v2 Krishnan 15 Minutes - Goal: Progress as Draft Standard - draft-ietf-ipv6-privacy-addrs-v2-01.txt what's new? - see slides hinden - agrees there are no interop issues, nor is the new algorithm better or worse, but the issues which caused the community to switch don't relate to this. there is no reason for implementors to change. the goal is not to get people to change code to comply with this. need to make this clear in doc. krishnan - has change pending that may require code changes hinden - well we can't do that, but let's discuss it when you present the change greg daley - we already understand well what well-distributed random numbers are. just need references to docs that explain that. krishnan - does have reference open issues - per-prefix knobs (will break backwards compatibility) ralph droms - how does it break backwards compatibility? author - not required in previous version of rfc3041 thaler - don't make it a must, make it a may or a should and then it is a non-issue savola - this is connected to next issues regarding ULAs, so should discuss these together hain - this is no different to changing the default of generate or not. if you get per-prefix knobs, nodes that do that don't break older implementations. just means that older nodes are doing something different. nordmark - is there any possibility that the tie-breaker rules in RFC3848 has any interaction with this? hain - if you don't have one of these suffixes then tie-breaker won't take effect. thaler - longest-prefix match is last rule, so this comes in first. prefix doesn't matter until you've looked at every other rule there is. - isatap and rfc2526 downref thaler - don't have problem with new text. avoiding isatap addrs isn't really a MUST. - unique local addresses do they need temp addrs? daley - don't treat them differently, at least don't explicitly exclude hinden - yes, they're just unicast prefixes, don't treat them differently hain - agrees shouldn't consider them to be different, but there is a strong bias for operators to not want random values to show up in their internal network. so probably don't want to do this in the ULA case. per-prefix knobs solves this problem. carpenter - ULAs special? yes and no. in large company they're not special at all. outside that company those addrs are a bug. should be prefix specific and then ULA is just a special prefix. nordmark - agrees thaler - only concern about per-prefix knobs is that hosts won't know their prefix until they get RA, so how does host get configured? krishnan - it is configured on host, hasn't thought about how this is administered. savola - assume many enterprises will want to use ULAs for local communication only, but might still want to generate temp addrs for global communication. therefore recommend that by default ULAs don't generate temp addrs. but then you need normative ref to something that defines ULA. hinden - might be better to put text in ULA doc as this doc is going to DS. hain - are you considering lifetime support? krishnan - higher lifetime is bound to RA, but max for temp addr is independent of that. hain - per-prefix knobs might require per-prefix temp valid lifetime thaler - pleas make clear that prefix doesn't need to be subnet prefix but something shorter could be used hinden - that would work well for regular unicast addresses as well -02 version has been submitted, but hasn't been published yet. ULA text is in there. -64-bit IID only? will add clarifying text to say that IIDs don't have to be 64 bit, but this text only applies to 64-bit IIDs. Any other issues? droms - if there will be another rev and opportunity to comment, then he has new text that doesn't need to be discussed here krishnan - there will be another rev - IPv6 over PPP v2 Varada 10 Minutes - Goal: Progress as Draft Standard - draft-ietf-ipv6-over-ppp-v2-01.txt no changes since last -01 rev was released in June is in last call now one editorial change planned, unless further comments come in please review and make any comments on the mailing list soon. savola - i have provided feedback a couple of times, but has not gone anywhere other than author contacting me off list. what i see as problematic is that DAD can be disabled under certain circumstances, but doesn't say how implementations figure out whether these circumstances are met. haberman - will take action to talk to author to see what's going on with those comments. - AD feedback on 2462 update Jinmei 20 Minutes - Goal: Resolve AD comments - draft-ietf-ipv6-rfc2462bis-06.txt WGLC completed in July 2004, new rev -06 published in August submitted to IESG in Sept, AD review finished in Oct two major issues - M/O flag clarification - confusing wording regarding 'stateful' vs dhcpv6 would like to confirm mailing list consensus in this meeting M/O flag behaviour - proposed resolution - describe details on flags in separate PS doc - (draft-daniel-ipv6-ra-mo-flags-01.txt, just adopted as WG work item) stateful vs dhcpv6 - wording used as part of the 'O' flag, clarify why we use 'stateful' while RFC3736 calls it 'stateless', ugly but didn't want to introduce radical change - AD comment - it's just confusing proposed resolution - remove 'stateful' and just use dhcpv6 instead, should be ok if we agree with the previous change, RFC2462bis won't use the phrase of 'other stateful config' for the O flag. additional effects - 2461bis and M/O doc will need to be modified. nordmark - 2461 uses 'stateful' in 4 or 5 places. if we change name of O flag to 'other config' then we're fine. replace 'stateful' with dhcpv6 as appropriate in 2461bis. droms - agrees with nordmark. other minor issues - change on the 'A' flag what happens if value of A flag changes over time answer: nothing - should be pretty clear in section 5.5.3. droms - can't think of situation were previously advertised prefix becomes unavailable for autonomous auto-config, but just wants to be clear that this is being prohibited by this nordmark - prefixes should time out for SAAD. receiving a prefix means nothing. this needs to be clarified tatuya - this doesn't seem to be a substantial issue nordmark - if setting A flag off doesn't result in prefixes timing out for SAAD, then there is a problem, right? wasserman - if previously advertised prefix is re-advertised without A flag, then don't stop using previously configured address. but if lifetime times out, then you have to stop using the addr. needs clarifications for implementors. hain - agrees with margaret. during multi6 discussion there was some talk about prefixes in the RA used to determine whether this is the same link, so there might be a reason for RAs to turn up with A flag off (just to serve as link determinants). krishnan - thinks this is already clear from current text. daley - DNA is looking at link identification. link identification using prefixes might be a product of DNA design team. there may be some subtleties here. people may be relying on what they believe existing behaviour to be, so clarification may be useful here. tatuya - let's confirm consensus on mailing list, if changes are required then he will make them in next rev. other issues terminology ordering - alphabetical or 'as is'? wasserman - it's fine as it is need ref to addr-arch in LL conf - will do inconsistent wording regarding DAD section. just a wording issue - replace lowercase 'must' with 'should' to avoid possible confusion. next steps verify proposed resolutions to issues are OK. several positive responses and no negative ones on list. so WG agreeing on course of action. revised draft will be issued including further clarifications and changes and discussed above. snapshot is available at http://www.jinmei.org/draft-ietf-ipv6-rfc262bis-07beta1.txt hold it waiting for 2461bis? another AD comment proceed to IETF LC anyway? Daley - has this already completed WG LC? Tatuya - Yes. Initial AD review has also been done. Chairs - will send to IESG with 2461bis when that is ready. Router selection draft update - dave thaler draft -05 passed wg last call, submitted to IESG several editorial nits, and 2 technical ones draft-06 addresses all but 1 issue editorial nits are available on issues list for this draft all included in -06 implicit deletion (issue from Thomas Narten) - delete all routes if router lifetime -> 0? - no, requires explicit deletion of each route, therefore no change in -06 current behaviour is also consistent with Prefix Info Opts Narten - when I made comment, I had notion that default router that stops being router, doesn't make sense to forward traffic to it any more. nordmark - there might be a useful distinction between default router = send me packet and i'll send it off where i can, and being a good router for default... thaler - draft addresses this already, there is some discussion and an example or two thaler - interpreation of router lifetime is lifetime of presence of router in default router list some discussion between narten and thaler that went too fast for me to catch, but sounded like agreement :) last two issues are separate on issues list, but turn out to be the same issue 24 dynamic routes (alex zinin), 27 end-to-end reachability (steve bellovin) zinin has submitted text savola - isn't this issue also in basic RA? are we trying to fix a specific case of a more generic problem here? is this the right place to fix this? maybe as this is a PS while ND is going for DS, but fixing it in ND might be more appropriate as that is where the problem is. thaler - that's true nordmark - redirects should take care of this. introducing more-specifics makes this more complex. thaler - having two on-link routers that don't co-operate can be made to work with this. wasserman - doesn't think this is reasonable text. agrees that routers dumping tables to hosts is obviously brain-dead, but this doesn't seem like it makes sense. thaler - clarifies wasserman - this still seems over-constrained. why MUST routers have this level of state complexity? thaler - zinin said that not doing route-damping in this scenrio is a 'recipe for disaster' savola - operationally this damping-feature is not called for. not typically implemented in IGPs. doesn't see the use here. does see the benefit of only advertising a prefix if link is up. nordmark - two routers on link that don't co-operate is a scenario where this doesn't help, so what are we really solving with this. arturo azcorra - involved in research project working on home-gateways. thinks home gateway will typically have capabilities for routing, security savola - what about damping? azcorra - don't know hinden - being a backup or master tied to state of uplink is well-understood concept and there is lots of experience about that. doesn't want to tie this to route-damping. if you're going to do this, make sure it's stable - a general statement would help here, but the proposed text is too prescriptive. pascal thubert - does MAY correspond to point 1 and point 2? point 2 explicity excludes some potentially useful functionality. krishnan - this only usefully applies to home gateways, so don't need damping savola - could be two home routers, then it might be useful. operational status of link only goes so far. thaler - this is the 'better than nothing' case. authors have no preference. sounds like there is rough consensus to keep the first sentence, change point1 to SHOULD and remove point2. no objections - Multi6 Update Nordmark 20 Minutes - Progress update WG is at: identify proposals for further development - recharter soliman - have there been any discussions about failure discovery and propagating that to the site nordmark - there is a draft that talks about how to detect working path. ipv6 transport protocols to give positive advice to L3 probes. also link-layer indicators. there isn't anything about routers telling hosts that prefixes aren't working. itojun - is the Design Team aware that the L3 shim is basically a host-based NAT? nordmark - there have been exchanges about this on the multi6 list. depends what you mean by NAT. this is 1:1 mapping across whole system, which is not what NAT does. hinden - clarification - so IPsec would work? nordmark - yes itojun - presentation at app area meeting is required because you have broken something at L3? nordmark - no, the issue is that if apps today are doing caching or referalls then they won't get benefit of the existence of multiple other locators. so apps need to switch to using FQDN or keep track of full list of IP locators - this is the message that apps area needs to hear. hinden - this is really cool stuff, good job. in last slide, this provides multihoming to small sites that would never run BGP. People who run BGP have a solution today. don't lose the benefits for small sites by focussing on large sites. nordmark - issue is middle-ground where providing some policy tweaks might reduce pressure for small sites to go to the BGP solution. is there something easy that can be done to widen applicability. savola - of course small v4 sites solution is to use NAT. huston - BGP is BGP. the issue about why do it this way as distinct from the way it is done with IPv4 is related to fundamental considerations about the scalability of BGP. BGP won't handle the load if multihoming for small sites gets popular. soliman - do you need this if you have mobileipv6? nordmark - interactions with mobility have to be considered. jason schiller - need a mechanism for doing multihoming for small orgs. hinden - does this have characteristic that people who deploy it get to be multihomed, or does it require other people to play ball too? nordmark - peers don't have to be multihomed, but have to implement protocol to produce multihoming benefits. has been suggested that for transition reasons a proxy might be a nice way to go, but that proxy turns out to have nat-like characteristics. bagnulo - need to upgrade both hosts to preserve established communications through outages, but there are other problems that are solved without needing to upgrade peers. nordmark - You're right. One can get multihoming benefits while the communication is established without requiring the peer to implement the protocol. But if you want the multihoming benefit for established connections, both ends need to implement the protocol. carpenter - full benefits needs both hosts to have code in their stacks, but there is no flag-day. deployment is 'creeping'. conscious choice not to solve mobility problem in multi6 - keen to keep these two problems orthogonal. pascal hubert - could this replace nemo or mip route optimisation? doesn't know, but both groups should keep track of what each other are doing going forward. route-projection concept may be useful for multi6 for example. lot of synergies to be gained, even if requirements are not shared. - Address Selection for multihoming Matsumoto 10 Minutes - Goal: Informational - draft-arifumi-multi6-sas-policy-dist-00.txt same slides as were presented to multi6 mtg yesterday. thaler - src and dst come from common prefix. RFC3484 rule number 7? says prefer longest-prefix match. don't see any other rule to override that, so you'd get the desired behaviour already. these examples don't seem to require this mechanism. hain - the issue is where end node is talking with someone *beyond* ISP B. these examples don't show that. droms - initial example also needs prefix C added to WGP-A network that has no more bits in common to prefixes A and B. thaler - right, but router selection draft also deals with this. droms - there are cases where the router selection draft isn't enough soliman - even if you construct a case where router selection draft isn't enough, it doesn't seem practical. please come back with a practical example. hain - case 2 is already a practical example. soliman - why isn't router selection sufficient hain - this is a different approach to the same problem that may be desirable in some circumstances thaler - agrees with hain that router selection can't help here. soliman - but if you configure routers correctly router selection does work hain - 'correctly' is a relative term, if you have two provider provisioned routers that you have no control over, they are configured according to each providers definition of 'correct', that may not be useful tatuya - be more specific about prefix C that causes the problem - this will help to clarify the problem and the need for the solution thaler - agrees this is a problem. not convinced this is the best way to solve it. hinden - chairs view is that this needs more consideration and discussion before there is any need for WG to consider what to do. - Anycast Analysis Chairs 10 Minutes - Goal: determine direction of the work - draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt basic problem is that there are disagreements on content of document in IESG. chairs have discussed with ADs and asked them to return doc to WG so that issues can be addressed. will go into 'AD-is-watching' state. also have another anycast BCP document that is being considered for adoption by grow WG. this is dealing with IPv4 anycast BCP at the moment. input on IPv6 anycast is appreciated. savola - it is useful to clarify somewhere that the role of anycast in ipv6 specs may be slightly different than what people expect. but the issue is that now that we have this document on 'shared-unicast', what should the ipv6 wg be documenting? is it right to do this work here now given that scope might change significantly? lindquist - this might be better in the grow WG - it's not IPv6 specific - it's operational. haberman - need to decide this as a group - will have this discussion on the mailing list after people have had time to digest work of itojun, kurtis and new anycast mailing list. kitamura - is setting up anycast mailing list. issue is different from current situation with anycast. don't care if itojun's work goes to BCP in this WG or not - will start discussion anyway. hinden - another WG to focus on this may be a good idea lindquist - this is good work that needs to be done, wasn't trying to prevent it being done. |