CURRENT MEETING REPORT Reported by Bob Hinden, Ipsilon Minutes of the IP: Next Generation Working Group Agenda Bash Agenda Status of Base set of Docs Status of WG Last Called Docs Changes in IPv6 and ICMP Specs Status of other IPv6-over-Foo Docs Token Ring FDDI PPP ATM other Multi-Homed Hosts Unique link-local address other issues PMTU Discovery Tunneling specification Anycast usage by Hosts API Specification ICMP Echo Response Truncation What Pieces are Left? FTP Header compression Multicast (son of RFC1112 Multihoming Routing Protocols MIBs (many?) Service Location Protocol IPng Area Conclusion Status of 6-Bone / Testing & Deployment Status of Implementations Introduction Steve Deering introduced meeting. He reviewed the agenda and asked for additional topics to be added to agenda. Status of Base set of Docs Bob Hinden reviewed status of the base documents. The following documents were approved by the IESG and as of last week are at the RFC editor waiting for publication as RFC's: Proposed Standard "Internet Protocol, Version 6 (IPv6) Specification" "IP Version 6 Addressing Architecture" "DNS Extensions to support IP version 6" "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" Informational RFC "An Architecture for IPv6 Unicast Address Allocation" After the meeting the RFC Editor indicated he expects to release these documents as RFC's by the end of the year. The following documents were previously recommended by the working group to be published as RFC with the indicated status: Proposed Standard "An IPv6 Provider-Based Unicast Address Format" Experimental "IPv6 Testing Address Allocation" The IESG did not approve these documents. The IPng w.g. chairs have written and sent (with a cc: to the IPng w.g.) a response to the IESG comments. The reply responds to the issues raised by the IESG which the chairs believe represents a misunderstanding with the motivation behind the design choices. The IPng working group chairs believe that these document should go forward. Status of WG Last Called Docs The following documents have completed working group last call: "A Method for the Transmission of IPv6 Packets over Ethernet Networks "Neighbor Discovery for IP Version 6 (IPv6)" There were no comments received during the last call or at the meeting. The chairs will forward these documents to the IPng Area Directors with a recommendations that they become Proposed Standards. Changes in IPv6 and ICMP Specs Steve Deering summarized the editorial changes and protocol changes agreed to by the working group at the Stockholm IETF meeting which made to these documents as part of submitting them to the RFC editor. IPv6 1) Headers and options must be processed in order, not in the order picked by receiver. Important to preserve semantics specified by sender and to make it easier to add new kinds of headers and options in the future. There are security issues in how headers/options are processed, but options must still be processed in order. 2) Description of jumbo payload options made clearer. Length includes length of header and all options. 3) Routing header changed to allow final destination to skip the routing header if it does not know about a new type of routing header. This was agreed to at the Stockholm meeting. Also added examples and text to describe how the routing header should be processes. 4) Fragmentation section augmented with additional text to describe how it works and how suggested mechanisms work. 5) Added requirement that all nodes must be able to reassemble packets 1500 bytes long. Min MTU still 576. ICMP 1) Deleted description of Pseudo header and replace it with a pointer to the pseudo header in the base IPv6 document. Status of other IPv6-over-Foo Docs FDDI: Same state as Ethernet. Ready to do last call. Working group chairs will issue working group last call. Token Ring: Status unknown. Author did not attend. Will check with author then do a last call. PPP: Need to get a code point. Document editor will ask Internet AD to get a code point. Dimitry Haskin will write a IPv6overPPP document. ATM: Work going on in IPoverATM w.g. There are several proposals. Other: AppleTalk? HIPPI? FiberChannel? Discussion about AppleTalk. There is a old working group and a draft (expired?). We need to find this draft and do a IPv6overAppleTalk version. Chairs will talk to Internet AD's. AppleTalk Forum may have started doing an IPv4 version, but did not complete it. This document appears to be harder to write than the Ethernet/FDDI versions. Brian C. this is an IPv6overPropritary protocol, maybe we don't have to worry about it. Deering mentioned that Appletalk was the reason to have 576 MTU. It would be very unfortunate if we don't end up doing IPv6 over Appletalk. Running IP over Appletalk is also very common. No plan to do IPv6 over SLIP. Multihomed Hosts Multihomed hosts need to have an unique interface token for of their interfaces on the same link. One way to accomplishing this is to add a unique value (such as an interface number) to link local address. There was not a consensus on this approach. A number of questions and issues were raised, and further discussion was deferred to the mailing list. KRE said w.g. need to define what bits are in the address format. Does not need to define the contents of the field. Nordmark said that it was not clear what is the advantage of this approach. Doesn't think this would make multihomed easier. It was also pointed out this approach has a conflict with duplicate detection in ND. Gilligan mentioned that new API spec. has some features with make multihomed easier. The feature depends on each interface having unique addresses (not same link local address). KRE said he was not sure the API interface alone is sufficient to solve this problem. Long discussion. Important to have overall solution. This proposal only helps host differentiate it's own interface address. It does not help host know which interface to use when going to a specific off link destination. No consensus on this approach. We need a document which covers the whole issue. KRE agreed to write a draft. Dan McDonald, Jim Bound (and other people from Digital) are also working on a multihomed proposal. Suggestion that this should also cover multiple interfaces on same link. PMTU Discovery / Jack McCann Started with RFC1191. Took out IPv4 specific pieces which include: router specification DF bit TCP MSS old stype DGTP messages plateau tables What is left: definition of path : src, dest, flow-id, routing header info Packet too big message detecting MTU increases (timers) implementation suggestions This document also applies to multicast. Note need to do PathMTU discovery for local link destinations. No issues raised. Chairs will do a working group last call when next version of the internet draft is out. Anycast usage by Hosts Currently anycast addresses can only be assigned to routers. Discussion on mailing list about also assigning anycast addresses to hosts. Anycast are desirable powerful tool, but are also dangerous due to scaling problems. What is next step to use? Currently hosts can not be members of anycast groups because routing system needs to learn about anycast addresses. Hosts do not currently participate in routing protocols. Proposal on list to use an extension to the IGMP protocol for hosts to tell routers what anycast addresses they have (similar to the way they tell routers which multicast addresses they). The working group like this proposal. It might not even have to define any new messages, though it may not fit exactly. The larger questions is how to distribute this information around routing system? A good next step is a write a document describing how hosts should tell routers which anycast addresses a host has. First step should be how host should use these address, not how to inject into routing system. Someone should write a specification. Working group is inviting a document to be written. API Specification / Bob Gilligan Reviewed detailed changes in new version of document. Changes from previous version of the document include: - Changed u_long and u_short types in structures to u_int32_t and u_int16_t for consistency and clarity. - Added implementation-provided constants for IPv4 and IPv6 text address buffer length. - Defined a set of constants for subfields of sin6_flowid and for priority values. - Defined constants for getting and setting the source route flag. - Define where ansi prototypes for hostname2addr(), addr2hostname(), addr2ascii(), ascii2addr(), and ipv6_isipv4addr() reside. - Clarified the include file requirements. Say that the structure definitions are defined as a result of including the header file , not that the structures are necessarily defined there. - Removed underscore chars from is_ipv4_addr() function name for BSD compatibility. - Added inet6_ prefix to is_ipv4_addr() function name to avoid name space conflicts. - Changes setsockopt option naming convention to use IPV6_ prefix instead of IP_ so that there is clearly no ambiguity with IPv4 options. Also, use level IPPROTO_IPV6 for these options. - Made hostname2addr() and addr2hostname() functions thread-safe. - Added support for sendmsg() and recvmsg() in source routing section. - Changed in_addr6 to in6_addr for consistency. - Re-structured document into sub-sections. - Deleted the implementation experience section. It was too wordy. - Added argument types to multicast socket options. - Added constant for largest source route array buffer. - Added the freehostent() function. - Added receiving interface determination and sending interface selection options. - Added definitions of ipv6addr_any and ipv6addr_loopback. - Added text making the lookup of IPv4 addresses by hostname2addr() optional. A few issues were brought up in the resulting discussion: - Matt Thomas suggested that in addition to the global variables ipv6addr_any and ipv6addr_loopback, systems should also provide constants for that can be used for initializing IPv6 address variables to these values. - A number of people suggested that systems should be allowed to use the all-zeros IPv6 address as the value for ipv6addr_any. - Erik Nordmark suggested that the return parameter to the hostname2addr() function be changed to include the address lifetime (TTL) which is stored with the address in the DNS. This would provide applications with the information they need to know when to stop using an address. Bob agreed to make these changes and re-issue the internet-draft. After that, a working group last-call will be held to promote the specification to Informational RFC. ICMP Echo Response Truncation Text should be changed suggest to hosts should try to send back all data. Document editor will talk to RFC editor to see if this change can be made before RFC is published. [Should I include this section] What Pieces are Left? This working group should deal with: FTP, header compression, multicast, multihoming, Brian Carpenter suggested we look at list in RFC 1752 for topics to be addresses. FTP Discussion about using FooBAR. Some input that might be better to include names instead of addresses. Needs to be looked at again. Routing Protocols RIP, OSPF, IDRP, InterDomain (IDRP or BGPng), Multicast Routing? MIBs Dimitry Haskin has a private MIB for v6, is willing to propose it to the w.g. IESG started working group in internet area to do IPv6 MIBs. Dave Arneson is chair of this group. Name of group is ipv6-mib w.g. Subscribe by sending email to: ip6mib-request@research.ftp.com There is a document archive at: ftp://research.ftp.com/pub/ip6mib/archive Service Location Important for plug and play operation. Current working group working on service for IPv4. Charlie Perkins thinks it would be easy to adapt for IPv6. Some question about using names instead of address in service location protocol. Deering suggest when group produces protocol for IPv4, we should look at it see how it applies to IPv6. Mobility Assigned to Mobile IP group. Our goal is that every IPv6 host can be mobile and know how to talk to a mobile host. Nice to eliminate triangle routing problem too. Charlie Perkons has written a draft. Dynamic DNS New Lifetimes in DNS The issue is whether we need lifetime fields in the DNS to handle renumbering or if it is sufficient to overload the cache TTL values for this purpose. A second point/question was whether the standard gethostbyname()-type API routines should be changed to return a TTL as well, so applications could determine how long the addresses they cache are valid. Tunneling Specification / Alex Conta Presented model for IPv6 tunnels, each tunnel is only one directions. Showed effect on protocol modules and packet flows through system. Specification does not have any association between hop-limit of encapsulated packet and tunnel header. Results in having to limit number of recursive encapsulations because it will not detect tunnel routing loops. Discussion on how tunnel destination option works. Some question if it is really necessary. Continuing working on this on the mailing list then do a last call. Status of IPng Area Steve Deering reported on lunch meeting w/ IPng area directors and Internet Area and Routing AD on discussion when IPng area concludes. Then the IPng working groups will move into appropriate area. IPng will move into Internet area. AddrConf will conclude and work will move into IPng working group. NG-Trans will move into Ops area. Sue Thompson will be primary AD for the IPng working group. Working group also thanked Scott Bradner and Allison for their work as Internet AD's. They did a great job! Implementation Status / Questions SD mentioned again the importance of IPv6 extension headers be processed in order. To subscribe to IPv6 Implementors list send email to: ipv6imp-request@munuari.oz.au Request to add notice of this list in IPng list mail signatures, in the charter, and on the IPng web pages. IPng bakeoff will be held February 6-10 at the University of New Hampshire. There is a small charge to cover food and other minor expenses. IPv4 mobility group approved the general direction of IPv6 mobility specification. It is important that every IPv6 node support mobility. Time for Implementors to look at current draft. Charlie Perkins described the features of this draft. IPv6 Mobility draft written by Perkins. Deering suggested that it would be good for current routers to be assigned native IPv6 address and set up tunnels to other similar nodes. Dimitry Haskin asked if any provider wanted to donate any links for IPv6 native testing. Jim Bound reported that he thought that ISI will do a RIPng and IDRP. Deering mentioned the test address allocation document and suggest that people use it to get native IPv6 addresses. Suggestion to add list of current IPv6 hosts on IPng web page. Bill Manning had previously volunteered to do initial IPv6 DNS. Bob Hinden volunteered to have people install machines at Ipsilon to be on the Internet. Geert Jan de Groot, RIPE NCC, volunteered to become the first root server for the IPv6 6-BONE. Discussion of approach to use a new root domain for experimentation. Goal of group is to set up 6-BONE by the next IETF meeting. Discussion about what IPv6 features should be tested during interoperability testing. The group came up with the following list: o Base IPv6 o Option Processing o Fragmentation & Reassembly o MTU Discovery (unicast & multicast) o Routing Header handling o Authentication Header o ESP Header o Neighbor Discovery - Router Discovery - Address Resolution (normal & proxy) - Redirects - Prefix Discovery - Auto-Configuration - Duplicate Detection - Neighbor Unreachability Detection o Transition - Dual IP stack selection - Configured Tunnels - Automatic Tunnels o Multicast (sending, receiving, ICMP) o DNS Resolver o Routing - Unicast - Multicast o Applications - Ping - Telnet - FTP - email - NFS - vat - traceroute - X11 - WWW / HTTP o BSD API o ICMP Error generation and processing o No Next Header This list will be posted on the implementations mailing list and Implementors should respond with which thing they can be ready to test in February at UNH. The current Implementors meet and came up with the following subset of features they thought could be ready for testing in February at UNH: - base ipv6 - option processing - fragmentation and reassembly - mtu discovery (unicast and multicast) - routing header handling - authentication - esp (not) - router discovery - address resolution (but no proxy yet) - redirects - prefix discovery - stateless autoconfig - duplicate detect - nud - stack selection for dual IP (not an interoperability issue) - configured tunnels - automatic tunneling - multicast (sending, receiving, icmp) (yes, optional for icmp) - dns resolver (over v4) (optional, or /etc/hosts6) - bsd api (by porting a simple application) - ICMP error generation and processing (yes, exercised by testing program) - no next header - unicast routing (static, then RIP by February) Test applications: - ping, traceroute - telnet, ftp (with foobar), email - vat/ ivs - multicast version of rwhod, mping, mtest...