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.|
|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|
|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
Robert Hinden <firstname.lastname@example.org>
Brian Haberman <email@example.com>
- 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
no issues or comments on document status
- Milestone Updates Hinden 10 Minutes
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.
- Privacy Addresses v2 Krishnan 15 Minutes
- Goal: Progress as Draft Standard
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
- 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
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
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.
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.
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.
- 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
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
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.