Last Modified: 2005-01-18
|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|
|Done||Submit Link Scoped IPv6 Multicast Addresses to IESG for Proposed Standard|
|Done||Submit IPv6 Scoped Addressing Architecture to IESG for Proposed Standard|
|Done||Submit TCP MIB to IESG for Proposed Standard|
|Done||Submit Site-Local Deprecation document to IESG for Informational|
|Done||Submit Unique Local IPv6 Unicast Addresses to IESG for Proposed Standard|
|Done||Submit Router Preferences, More-Specific Routes to IESG for Proposed Standard|
|Done||Submit updates to Auto Configuration (RFC2462 to be republished at Draft Standard|
|Done||Submit update to ICMPv6 (RFC2463) to be republished at Draft Standard|
|Dec 04||Submit document defining DAD optimizations to the IESG for Proposed Standard|
|Dec 04||Submit Load Sharing to IESG for Proposed Standard|
|Dec 04||Submit updates to Neighbor Discovery (RFC2461) to be republished at Draft Standard|
|Jan 05||Submit Centrally Assigned Unique Local IPv6 Unicast Addresses to IESG for Proposed Standard|
|Jan 05||Submit Proxy ND to IESG for Informational|
|Jan 05||Resubmit Node Information Queries to IESG for Experimental status|
|Jan 05||Submit update to IPv6 over PPP (RFC2472) to IESG for Draft Standard|
|Jan 05||Submit Update to Privacy Extensions for Stateless Autoconfiguration document (RFC3041) to the IESG for Draft Standard|
|Mar 05||Submit update to IPv6 Address Architecture to the IESG for Draft Standard|
|Apr 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 Bits 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|
IETF 62 ipv6 wg meeting minutes
People referenced in minutes
Brian Haberman (Brian)
Margaret Wasserman (Margaret)
Jinmei Tatuya (Jinmei)
Pekka Savola (Pekka)
Alain Durand (Alain)
Bob Hinden (Bob)
Rob Austein (Rob)
Hideaki Yoshifuji (Hideaki)
Mukesh Gupta (Mukesh)
Dave Thaler (Dave)
Elwyn Davies (Elwyn)
Thomas Narten (Thomas)
George Michelson (George)
Bill Fenner (Bill)
Stig Venaas (Stig)
Mark Andrews (Mark)
Olafur Gudmundsson (Olafur)
Agenda and Document Status
No one had any comments on the Agenda during Agenda Bashing
Jinmei has a comment on the Doc status. He wants to know next steps for 2462bis as ADs need implementation status reports .
Margaret needs info if former impl reports apply (just checking to make sure). Also need statement from chairs and pointer to the old impl report to this effect. Mukesh Gupta (Mukesh) wants to know if the implementation reports are needed for the ICMPv6 revised draft as well. Brian clarifies they are needed for both ICMPv6 and for 2461bis. He also clarifies that they are not needed if the existing implementations are not affected. The loosening of algo for privacy addrs, for example, has no effect on existing implementations. Pekka thinks the reports are so general, that is hard to infer anything specific from them.Margaret thinks that they may not be complete but they were good enough for the first time. IESG will not force to redo a new format for the Implementation Reports
She has no slides. She already sent the info to the ML.
IESG review found an issue with the DNS section. The issue was the increased load due to reverse lookups on DNS. Added text to resolve this.The text Reverse queries MUST NOT be sent out of the site.
Alain is worried about how this will be implemented on the routers or on DNS servers? Mark thinks that basic premise is that this traffic should not leave the site and must egress filter it and must tell the client it does not exist. He said para had MUST in upper case.Brian and Margaret think that this is operational guidance and cannot use normative language.
Alain and Pekka think that if it needs to be in a DNS implementation it needs to be normative. Alain wants a separate document addressing the dns related issues and does not want this text here. After discussion between Alain, Margaret, and Bob agree to have the issue mentioned both in the ULA document and another separate document. Rob clarifies that this text does not apply to centrally assigned ULAs, which most likely will have a real reverse tree.
Alain thinks we need a BCP document containing the list of prefixes. Brian agrees with Alain. We have a problem which is holding up this doc. That is what we are fixing. We cannot wait for another doc to go all the way during the process.Margaret thinks there are 3 options 1) get the text in this doc and publish it2) wait for the other document and add a norm reference to it 3) do nothing. Alain: thinks there is a 4th option 4) take great care in this and point to an informative reference. He refers to RFC1918 that had text which said don't put this on the net. that does not work. We will have legacy clients still generating queries. We need to fix this in the servers
Pekka is worried about the effects this will have on caching resolvers that every host needs to be modified. Olafur feels that this will cause least damage as opposed to not doing this. Margaret: It does not hurt you any more if you get a no from your ISP rather than from the root server. Rob thinks we need to pick a default (pass or don't pass). This is the lesser of 2 evils. Make it a config option. we should not harm the public net. Pekka is concerned whether the people who use ULA will see it the same way.
Pekka: It is just not clear, that the people who use ULA will see this.
Jinmei and Alain don't want this work to be done in the IPv6 wg. Rob and Mark also think this should be done in the DNS space in the long term and this is a short term fix.
Brian wants to use this text as a rough guideline and asks for a show of hands.
Who wants to see this text in the doc? about 15 hands
Who does not? one or two hands
(CONSENSUS IN FAVOR)
Alain thinks the second question was a bit loaded.
Brian rephrases Q2 to be "Who does not feel this text should in this document and be in another document"? 3 hands
Update to address arch
It was approved as DS. There was an appeal. To resolve the appeal it was published as PS. There is most likely an implementation report already. The main changes were to resolve issues raised in Robert Elz's appeal and to deprecate site local. There were also a few mainly editorial changes. Bob will remove confusing text in the multicast scoping part of the draft.Pekka wants compatible addresses removed from the spec. Tim agrees. Bob thinks there are people who still want them in. Pekka feels that there was no consensus on ML. We should get the consensus here. Bob thinks that we should probably leave it alone as we are recycling an exisiting standard.
Q1) Who wants to remove of ipv6 mapped addresses.
(CONSENSUS AGAINST REMOVAL)
Q2) compatible addreses
who wants them to be removed? 20 hands
who does not want it removed? 3 hands
(CONSENSUS IN FAVOR OF REMOVAL)
Hideaki does not want compatible addrs removed. He wants the address space not to be reused. He is ok with deprecation.
Bob: Do we want to deprecate them? about 10 hands
No? 1 hand
(CONSENSUS IN FAVOR OF DEPRECATION)
Brian to be Hesham
The last major issue left is the processing messages without the SLLAO option. Will be adding text from Greg Daley to clarify this case. Will make sure that Hesham will send the propsed changes to ths list. Jinmei and Greg agree to take it on the list
(Reordering of presentations)
Major changes are
* text to allow disabling of sending Destination unreachable messages will be added as a SHOULD
* will remove security replated processing details for icmpv6 packets and add an informative reference to 2401bis. There is a downref issue if this needs to be done.
* New text for source address determination from Elym to be included as 2.2 (b) instead of 2.2 (b),(c) and (d)
Discussion between Suresh, Bob, Dave, Elwyn and Pekka on whether the sender should try to make the error message more informative when the the receiver might not know this or may not want to know this. Pekka thinks that adding this as a SHOULD will cover the existing implementations
Pekka the previous SHOULD will cover the existing implementations
Dave talks about why we need ndproxy and what are the characteristics of ndproxy. The doc is aimed to be EXPERIMENTAL. Loop prevention was a major issue in the ML discussions. Added text to say loop prevention is a MUST (and allow two ways to do it STP / physical constraints)
Erik had a new suggestion (P bit in RA)
-> if clear and on upstream proxy would set and forward on downstream
-> if set or on downstream the proxy would disable proxy func on that interface for some time.
hold down time of 2*maximum RA interval = 60 mins
now the draft has 3 options (P/STP/physical constraints)
Bob suggested the option (c) - physical constraints should be removed and the authors agreed. Pekka agrees with removing (c). Suresh is concerned that if a network contains some ndproxies which use the P-Bit and some which use STP there will be an issue. Greg suggests adding an appendix clarifying this.
SEND interoperability is another issue which remains. Dave talks about a draft draft-daley-send-spnd-prob-01 which talks about the scenarios send is not a blocking issue as long as the draft is consistent. The explicit requirement for send interop has been removed.
Alain wants to know if this is related to trill? Brian thinks it is not and is independent.
IAB ipv6 ad-hoc committee report
RIRs were starting to request large allocations from IANA(>/23). IANA wanted advice from the IAB. The ad hoc committee was formed to advice IAB on ipv6 addressing matters
Format of the IANA registry huston-ip6-iana-registry-05
ip6.int deprecation huston-ip6-int-01
Alain wants to know if there are stats for number of queries for ip6.int as he is concerned about the impact of doing this to existing equipment. Thomas does not have them. George has info collected over 2 years. He will make the info public, but he said the volume is pretty low but not trivial. George thinks that there will be some impact but we must not overstate this.
Thomas thinks allocating /23s to RIRs is not a good idea for agrgegation. The RIRs think /12 or /16s are better. He also thinks that we need to have a good balance between aggregation and conservation (in ipv6 the balance is more towards aggregation). The IETF interested in long term stewardship, and not day to day management. We need to get good aggregation over time
Currently each RIR has its own policy but they should converge on same process before going forward. We need to document technical considerations of allocation sizes, reservations etc. huston-ipv6-hd-metric-00 needs community review
Pekka thinks is not appropriate to discuss it here. Thomas and Pekka kind of agree on v6ops.
Bob announces that Thomas is retiring as AD. Thomas has been active a lot in the ipv6wg. Bob wants to give him a big hand.
(The crowd goes into WILD APPLAUSE)
Thomas has had a lot fun and is continuing to have fun
ipv6 scope identifiers in URIs
There is an issue with representing IPv6 scope IDs using URIs as % is used to introduce % encoded chars. There are three ways to go about fixing this
1) Use a non-% character which fits existing grammar: We cannot copy and paste
2) Use %25 :It needs update to uri spec and we still cannot copy and paste
3) Continue to use % : Does not fit URI spec. Exception to fundamental URI rule
Dave thinks Scope IDs appearing on the wire is a bad thing. Bill agrees with him. Margaret thinks these are being used in some docs the IESG has passed. Dave thinks this is OK to do as long as they are not called URIs. Margaret agrees with Dave. Brian, Bob, Mukesh think there is some utility for this. Jinmei is not convinced. Stig thinks there is no need to cut and paste as these URIs will only be used internally by applications. Brian wants to continue discussion on the ML as time is up.
(END OF MEETING)