IPng Working Group December IETF Bob Hinden / Nokia Steve Deering / Cisco Co-Chairs Steve Deering introduced the meeting. Two meeting slots were scheduled. Bob Hinden took and edited the minutes. Thursday 3:30PM - 5:30PM Friday 9:00AM - 11:30AM The agenda was reviewed. The resulting agenda was: Agenda: - Introduction / S. Deering - Review Agenda / S. Deering - Unified IPv6/IPsec Stack / K. Kamamoto - Document Status / R. Hinden - IPv6 Code Points / R. Hinden - IPv6 6REN Status and Plans / R. Fink - Addressing to Draft Standard / R. Hinden - Initial IANA Sub-TLA Assignments / R. Hinden - IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter - Basic API Revision / J. Bound - DNS Extension to Support IP Version 6 / M. Crawford - Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering - Jumbograms / S. Deering - Router Renumbering / M. Crawford - Multicast Listener Discovery Protocol / S. Deering - Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 / L. Zhang, et. al. - Site Prefixes in Neighbor Discovery / E. Nordmark - Future IPv6 Direction / S. Deering - Mobile IPv6 Status / D. Johnson - IPv6 TCP and anycast address / Jun-ichiro Itoh - RPC and NFS over IPv6 / L. Wu - Tunnel Broker / A. Durand ------------------------------------------------------------------------ ------------------------------------------------------------------------ Unified IPv6/IPsec Stack / K. Kamamoto -------------------------------------- We decided to merge our code: - INRIA - NRL - Kame Project - to provide a single free reference code Targets are BSD variants - FreeBSD - NetBSD - OpenBSD - BSD/OS Schedule - Hopefully by next summer Document Status / R. Hinden --------------------------- - RFC Published o RFC2460 Internet Protocol, Version 6 Specification (DS) o RFC2463 ICMPv6 (DS) o RFC2461 Neighbor Discovery for IP Version 6 (IPv6) (DS) o RFC2462 IPv6 Stateless Address Autoconfiguration (DS) o RFC2454 MIB for IPv6: UDP (PS) o RFC2452 MIB for IPv6: TCP (PS) o RFC2465 MIB for IPv6: Textual Conventions & General Group (PS) o RFC2466 MIB for IPv6: ICMPv6 Group (PS) o RFC2472 IPv6 over PPP (PS) o RFC2471 IPv6 Testing Address Allocation (Experimental) o RFC2470 IPv6 Packets over Token Ring Networks (PS) o RFC2467 IPv6 Packets over FDDI Networks (PS) o RFC2464 IPv6 Packets over Ethernet Networks (PS) o RFC2450 Proposed TLA and NLA Assignment Rules (I) o RFC2473 Generic Packet Tunneling in IPv6 Specification (PS) - IETF Last Call completed for Proposed Standard o IP Header Compression / Nov 97 - Waiting for new draft o IPv6 over ARCnet Networks - Waiting for new draft o Router Renumbering for IPv6 - IESG Comments - Submitted to IESG for Proposed Standard o IPv6 Router Alert Option - IESG wants to reconcile w/ IPv4 Router Alert o Reserved IPv6 Subnet Anycast Addresses o DNS Extensions to Support IP Version 6 - IPng Working Group Last Call Completed for Proposed Standard o IPv6 Jumbo Payload Option o Transmission of IPv6 over IPv4 Domains without Explicit Tunnels - IPng Working Group Last Call Completed for Informational o Basic Socket Interface Extensions for IPv6 - Waiting for new draft o Initial IPv6 Sub-TLA ID Assignments - IPng Working Group Last Call Completed for Experimental o IPv6 Name Lookups Through ICMP IPv6 Code Points / R. Hinden ---------------------------- - Assignments for: o ICMPv6 Parameters o IP Version 6 Parameters - Accepted by IANA - Available on IANA Assigned Numbers Web Site: http://www.iana.org/numbers.html Carpenter: Important to carefully document IANA<->WG procedures for parameter assignment. Best to do as an RFC with big stamp of approval from the IESG. Addressing to Draft Standard / R. Hinden ---------------------------------------- - Addressing Documents o RFC2373 IPv6 Addressing Architecture o RFC2374 An Aggregatable Global Unicast Address Format - Implementation reports available at: ftp://playground.sun.com/pub/ipng/implementation-reports/ file name: add-arch-aggregat.txt o Additional reports desirable - Start working group last call for Draft Standard Implementation reports available. Bob proposes to start last call at this point for advancement of these 2 documents to Draft Standard. No objections. ACTION: Document editor will start working group last call to move the IPv6 addressing specifications to Draft Standard. Initial IANA Sub-TLA Assignments / R. Hinden -------------------------------------------- - Regional IP Registries plan to start allocating IPv6 addresses in Q1 1999 o Responding to requests from ISPs planning production IPv6 service - RIRs each need initial blocks of Sub-TLA ID's to assign - New draft to propose initial Sub-TLA ID Blocks: "Initial IPv6 Sub-TLA ID Assignments" Background | 3 | 13 | 13 | 19 | 16 | 64 | +----+------+-------+---------+------+--------------------------+ | FP | TLA |Sub-TLA| NLA | SLA | Interface ID | | | ID |ID | ID | ID | | +----+------+-------+---------+------+--------------------------+ ^ | | FP = 001 = Format Prefix TLA ID = 0x0001 = Top-Level Aggregation Identifier Sub-TLA ID Assignments Binary Range (Hex) Assignment ---------------- --------------- ------------------- 0 0000 00XX XXXX 0x0000 - 0x003F IANA 0 0000 01XX XXXX 0x0040 - 0x007F APNIC 0 0000 10XX XXXX 0x0080 - 0x00BF ARIN 0 0000 11XX XXXX 0x00C0 - 0x00FF RIPE NCC 0 0001 00XX XXXX 0x0100 - 0x013F (future assignment) 0 0001 01XX XXXX 0x0140 - 0x017F (future assignment) 0 0001 10XX XXXX 0x0180 - 0x01BF (future assignment) 0 0001 11XX XXXX 0x01C0 - 0x01FF (future assignment) 0 0010 00XX XXXX 0x0200 - 0x023F (future assignment) . . . . . . . . . 1 1111 11XX XXXX 0x1FC0 - 0x1FFF (future assignment) Where "X" indicates "0" or "1". Carpenter: Tuesday night, the IAB sent a request to IANA to assign blocks of sub-tla's to APNIC, ARIN, and RIPE-NCC in the same manner as specified in the draft. IPv6 6REN Status and Plans / R. Fink ------------------------------------ IPv6 Research and Education Networks Initiative The problem - Given the several years it will take to integrate existing implementations of IPv6 into production release products - and the several years it will take to work out all the details of making Internet applications work transparently over IPv6 - what do we do during this interval to maintain momentum for IPv6...? Where we are - We have standards, we have lots of implementations... we now need deployment - The R&E network community can now contribute substantially to IPv6, in the way it did to establish the Internet, ... - by creating production IPv6 networks suitable for real applications to use A start - In early October, ESnet established native IPv6 over ATM peering with CAIRN, Internet2/vBNS and CA*net2 - In December, with WIDE - and established an open participation initiative, the 6REN, to act as a rallying point for all RENs world-wide to provide production IPv6 service Isn't this just the 6bone? - The 6bone is a testbed network, operated under a testbed AUP, and is not operationally robust due to this fact - The 6ren is going to promote and coordinate production quality IPv6 service - The 6ren is NOT a network 6REN participation - Free and open to all Research and Education Networks that provide IPv6 service - Other for-profit and not-for-profit IPv6 networks are also encouraged to participate on this basis as well - The 6REN is more like a NANOG for IPv6 Work underway - A planning/formation meeting was held during this IETF Orlando meeting week - Existing 6bone pTLAs are being approached to find out can participate in this effort More work - Working with David Kessens to provide network registry service similar to that provided for the 6bone - Reverse DNS (ip6.int) registry planned to be provided through ISI, under IANA oversight, as done now for 6bone - ESnet will provide transit for the 6bone to all 6ren participants (with some proviso) next line - Convert the early participants to production IPv6 addresses as soon as the registries start handing out Sub-TLAs early next year - Work on making these networks provide production quality IPv6 service Also of interest - Effort is underway to help Australia and China RENs to develop plans and proposals to provide country-wide production IPv6 service o AARNET - the Australian Academic and Research Network o CERNET - the China Education and Research Network The Environment Today - State as of mid-December 1998 +------------+ Direct native IPoverATM /| Internet 2 | PVC links w/ BGP4+ peering / +------------+ / +-------+ / +------+ | |/ | | | ESnet |----------------| WIDE | | |\ | | +-------+ \ +------+ | \ | \ | \ +-------+ \+-------+ | CA*net| | CAIRN | +-------+ +-------+ Providing... - Motivation to run real Internet applications over a native IPv6 infrastructure - A possible incentive might be using it to provide a "quality" path - ... and because it's the "right" thing to do :-) Applications and IPv6 - Remember, no application we know of needs IPv6 to run - This is a feature, not a "bug" - This feature is the way we guarantee transitioning from IPv4 to IPv6 is transparent as possible Join the 6REN Initiative - See the new web site for the 6REN: http://6ren.net -Contact Bob Fink if you have any questions Bound: Corporate America doe snot have to wait for Microsoft. There are reasons to deploy now. IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter ---------------------------------------------------- Working group last call. Draft discussed here and in NGTRANS. Comments: Section 7 of document will be removed because it was half baked and draft will be reissued. ACTION: Document editor to send "IPv6 over IPv4 w/out Explicit Tunnels" to IESG for PS when new draft is out. Basic API Revision / J. Bound ------------------------------ As soon as new ID is out, DE is submitted for Informational. ACTION: Document editor to send "Basic API Revision to IESG for informational when new draft is out. DNS Extension to Support IP Version 6 / Matt Crawford ----------------------------------------------------- Document Status - Chairs requested ADs to advance it on October 15, 1998. - Depends on two dnsind wg drafts, which that chair passed to ADs Sep 22 & Sep 27. - One or both of which depend on "EDNS0" draft that just need a an IANA considerations section. Implementation / Experimentation - A6, binary labels and DNAME will be in BIND 9. - Experimental variant of 8.2 may be available sooner. Deployment Concerns - What if site is partitioned from the internet for an extended period? o At least two classes of solutions, including a spectrum of configurations choices in zone. - Need applicability statement o Glue records need scrutiny - ... to see how much of the same protection is appropriate. - What if your provider or DNS parent makes a mistake? o Same foot, same gun, new bullet. Router Renumbering / M. Crawford -------------------------------- Two small sets of IESG comments received - Editorial and wording preferences - Request for instructions to implementors and user regarding retransmission strategy. New draft should resolve IESG issues and allow this to move forward. Jumbograms / S. Deering ----------------------- It was reported that we now have two interoperable implementations. Can this move to Draft Standard now? Will this satisfy IESG requirements? It was already at proposed when it was part of IPv6 specification. Internet AD answered that it would be better to start at Proposed Standard. Comment to combine this with TCP/UDP jumbograms to produce one Jumbogram documents. After some discussion, documents authors will decide appropriate approach. Multicast Listener Discovery Protocol / S. Deering -------------------------------------------------- A new version of the draft is needed. Also, found problem with behavior when query time of zero. Needs to be defined meaning of zero. Zero will mean zero delay. Deering will issue new draft. It was noted that is dependent of IPv6 Router Alert. Concern raised about attack w/ zero value. Need to make sure these messages can not be forwarded from routers. ACTION: Document Editor will start w.g. last call for "Multicast Listener Discovery Protocol" for Proposed Standard once new ID is published. Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 / L. Zhang, et. al. ------------------------------------------------------------------------ History - Feb '97: IPng interim meeting on GSE proposal - draft-00 in summer '97, mostly reporting on the meeting discussion and consensus, received lots positive feedback and comments. - The authors all got overloaded, dragged on the revision for a looooong time period Current State and Next Step - draft--3 (this IETF) mostly focus on the analysis of pro's and con's of separating locators and identifiers: o Overloading address field with both functions has its architectural importance o The separation introduces new issues that have no clear solutions - Request WG last call to publish the analysis as an Info RFC. ACTION: Document editor will issue w.g. last call for publishing "Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6" as an Informational RFC. Site Prefixes in Neighbor Discovery / E. Nordmark ------------------------------------------------- Site prefixes in Neighbor Discovery Outline - Site model including mobile nodes - Proposed protocol - Mobility issues Model - An interface belongs to (at most) one site. - A link belongs to (at most) one site. - A node (host or router) can have interfaces in multiple sites. - Site boundaries pass through nodes - not through links. Model for mobile nodes away from home - Always considered to have one interface in its home site. - This interface is the conceptual tunnel to its home agent and nodes in the home site. - Implies that mobile nodes are "multi-sited". Proposal - Routers advertise "site prefixes" - global address prefixes assigned to the site. - Nodes use the site prefixes to determine what global addresses are part of the site. - Site local (and global) addresses stored in the (global) DNS. - "Resolver" filters out site local addresses unless one or more global addresses match a site prefix. o Site locals only used when peer is known to be in same site as sender. Prefix option format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |L|A|R|S|Resvd1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Site PLength | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S site prefix flag: Site PLength is valid. Site PLength: Number of bits in site prefix. Example - RRset in DNS 2837:a:b:987:X:Y:W:Z1 2000:1:2:987:X:Y:W:Z1 fec0::987:X:Y:W:Z1 2837:a:b:34:X:Y:W:Z2 2000:1:2:34:X:Y:W:Z2 fec0::34:X:Y:W:Z2 2abc:77:66:23:X:Y:W:Z3 - Advertised site prefixes: 2837:a:b::0/48 2000:1:2::0/48 - Addresses used by application: fec0::987:X:Y:W:Z1 fec0::34:X:Y:W:Z2 - Instead if site prefix list is empty apps use: 2837:a:b:987:X:Y:W:Z1 2000:1:2:987:X:Y:W:Z1 2837:a:b:34:X:Y:W:Z2 2000:1:2:34:X:Y:W:Z2 2abc:77:66:23:X:Y:W:Z3 Question about motivation. Beneficial, if you think internet is not going to renumber, wants to use site local addresses for all internal traffic. Only have external traffic use global addresses. Make internal traffic impervious to renumbering. Comments: This is a big deal and makes DNS resolver very complex. Thinks draft has not been read/understood. Thinks we should do this. Should we add this to BIND9? Some work in resolver. Another motivation for this is that site local address are the IPv6 equivalent of "Net10" private address space. Some people think having private addresses are important. This draft helps make this work. Allows site to use both private and public with not difficult transition. Impact of deployment? Can we get all implementations done in timely manner? Requiring two-faced DNS would be a mistake. Mobile nodes - Will acquire global care of address(es). - Might acquire a site-local care of address. (but not useful). - Retain any site local address from home site. o Only use this when communicating over the conceptual interface to the home site. - Detect when moving away from the home site and back. o Using the advertised site prefixes. Home agents - No changes. Proper source address selection when originating packets sufficient. Correspondent nodes - When the binding cache for a site local destination has a global care of address: o Include a Home Agent option containing the site local source address. - Ensures that the source address of the IPv6 header is a global address when the packet leaves the site. Summary - All nodes must start ignoring site local addresses returned from the DNS. - As site prefixes become advertised these addresses can be used. Questions/Comments: This works by matching up something in ND messages w/ what is in DNS. Could also do DNS-DNS matching. Reply: This wouldn't work for Mobile nodes. Deering: Some people are unhappy with this. Any impact on firewalls? No Question about leakage of internal structure of DNS information outside of network. How would work w/reverse zones. Answer in draft. Can construct reverse addresses Jim Bound thinks this will help deployment. Chair took poll to see if having to make resolver changes to support this is too hard. No strong objection. Strong agreement to continue this work. Future IPv6 Direction / S. Deering ---------------------------------- What should happen next? Lots of this we could do? Or not. - more auto config, discovery of names, etc. What chairs had in mind was to hold an interim IPv6 meeting. Tentatively first week of February. Review state of IPv6 protocols and transition mechanisms. Identify new works, new approaches, etc. Initial proposal to meet at LBNL in S.F. Bay area. First two day would be combined NGTRANS and IPng first two days. Third day would be coordination, 6REN, 6BONE, etc. Polled room to see who could attend: Many would attend. Another proposal to have meeting in Europe or Japan. Possible sponsors should talk to Chairs after meeting. Editor Note: Subsequent to the meeting it has been announced that the Interim meeting will be held on February 2-4 in Grenoble France. Details sent to IPng and NGTRANS mailing lists. Mobile IPv6 Status / D. Johnson ------------------------------- Completed w.g. last call and has been submitted to IESG. IETF last call should occur soon. New Encoding for Operational Information Unique Identifier Sub-Option Home Agents List Sub-Option Dynamic Home Agent Address Discovery Details Comment: This and RR need to handle "R" bit behavior correctly. Miscellaneous Changes Question: Should we put the required part for every host in separate document. Would highlight this functions. Several comments that this is not necessary. ACTION: Document Editor will produce web page that lists required IPv6 specifications. Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering --------------------------------------------------------------- Previously submitted to IESG for PS. Waiting for IETF last call. IPv6 TCP and anycast address / Jun-ichiro Itoh ---------------------------------------------- Problem in TCP and anycast - Anycast addr MUST NOT be used as source addr - Can not disconnect TCP connection to anycast addr, by TCP RST o Source address must match the SYN's destination - Sender must wait till the TCP SYN timeout comes Sender Receiver S R, Anycast A SYN _______________ \______________\ / ______________ /_______________/ \ RST When this situation happens - Any situations possible o No way to distinguish anycast addr - Anycast addr in DNS database o telnet host.foo.com makes connection to the addr - Addr typed in by hand - Addr given to client from some server - We need a common way to disconnect TCP to anycast addr Proposed Solution - Transmit ICMP addr unreachable o No restriction on source addr o More quick disconnection possible Sender Receiver S R, Anycast A SYN _______________ SYN \______________\ / ______________ /_______________/ \ ICMP addr unreach - Implemented into KAME IPv6 stack - Works fine against BSD-based TCP stack o Listen to ICMP errors, disconnect TCP connection if # exceeds limit Comments: This should not be the behavior. TCP is not supposed to close connections on receipt of ICMP error messages. This error does not usually indicate "permeant" error. BSD is not a good model for this behavior. Issues - Per-address notification, not per-port o OK since TCP to anycast is always disallowed - Security o Malicious router can disconnect any TCP session o Problem is in ICMP, not new - Future update in anycast to allow TCP? o Implementations MUST make a flog to disable this - Need your experience for non-BSD TCP o Experiments welcome, at terminal room - UDP6 suffers from this problem too... o Example: name server on anycast addr Deering: Was hoping there would be a proposal to change TCP to allow connection initialization using any anycast address. Special option in TCP to allow this. Asked if author interested in creating a TCP option. Reply: Likes idea but think there are security problems to deal with this. Problem w/ UDP is not a severe as with TCP. Some UDP applications already work w/ multicast. DNS is a problem. Would like to experiment with this, then submit an internet draft for consideration by the w.g. RPC and NFS over IPv6 / L. Wu ----------------------------- RPC is supposed to be transport independent. Why would it ever be an issue for RPC over IPv6? - RPC service lookup protocol o Overview of RPC Service Lookup protocol o What are the issues - RPC-API RPC service lookup protocol Overview - RPC Service Lookup protocol enables client and server to bind dynamically. - It was also know as PORT MAPPER - Now it's evolved from the PORT MAPPER (version2) to RPCBIND (version 3&4). However PORT MAPPER is more widely deployed. +----------------+ +--------+ | | | |------------------------->| | | Client | | Server | | |<-------------------------| | +--------+ | | | | +----------------+ Version 2: protocol = 32-bit integer, Port = 32 bit integer Version 3&4: protocol = string, port = string RPC IPv6 Service lookup Issues? - How to lookup IPv6 RCP services? o Using PORT MAPPER o Using RPCBIND o Enforce IPv6 RPC services to use the port as IPv4 service? Using PORT MAPPER - Portmapper Request: - Proposing: o Create a new protocol number to indicate services running tcp over IPv6 and udp over IPv6. There is no restriction in the protocol to be coincide with IANA number. or o Have PORT MAPPER listens on a different port than 111 for IPv6 service Editor's Note: in slide, they don't mean changing TCP protocol number, just local identifier inside of implementation for port mapper. Using RPCBIND RPCBIND request: - Proposing netid to be: tcp6 - for service running TCP over IPv6 udp6 - for service running UCP over IPv6 Enforcing IPv6 service port - If we are enforcing IPv6 service port to be the same as IPv4 service on a dual stack hosts. There won't be any issues with IPv6 service lookup. - Proposing: o Not to support the above idea, because it's not possible to differentiate a RPC service only support IPv4 on a dual stack host. Discussion. RPC API - There are two major sets of RPC-APIs: o Socket based RPC-API, as known as TS-RPC o TLI/XTI based RPC-API, also known as TI-RPC TS-RPC API - Many APIs embedded sockaddr_in as parameters, for example: clntudp_create(sockaddr_in *raddr, rpcprog_t, prog, rpcvers_t vers, register int *sockp, u_int sendsz, u_int recvsz) - Proposing o Create new API that support sockaddr_in6 TI-RPC API - It's not an issue for TI-RPC APIs since no sockaddr_in structure is exposed SUMMARY - Use TI-RPC APIs - Have a separate service port for IPv4 and IPv6 service, and use RPCBIND for RPC service lookup with netid of TCP6 and UDP6 to specify services over IPv6 - Leave PORT MAPPER for IPv4 service lookup only. If want to extend it for IPv6, we have to resolve the issues. - Current TS-RPC API is not able to support IPv6. Tunnel Broker / A. Durand ------------------------- Tunnel Broker / Server Web page +-----+ +-----+ +-----+ | | /| S | | B |\ | | / | | | | \ +-----+ Tunnel / +-----+ +-----+ \ IPv6 target ^ | Broker / +------+ | | +-----+ | | | | +------>| B | IPv6 netowrk | | | | / +------| |\ | | | | / / +-----+ \4 +------+ 1 | | 2 3/ / \ \ / | | / /5 \ V / | V / / \ +-----+ +-----+ / +----+ / / \ | | | | / | |/ / 6 | S | | S |/ | |=======================| | | | +----+ +-----+ +-----+ Dual stack IPv4 host Tunnel server The basic idea is to get the address of a tunnel broker from a web page (step 1 & 2), then running a tunnel broker protocol to the tunnel broker (steps 3 & 5) automatically obtain the address (similar to the way DHCP provides addresses) obtain a tunnel endpoint address of a tunnel server (step 6). The tunnel broker would communicate with the tunnel server as part of this process (step 4). Discussion, many questions. Plans on experimenting w/ this. Later might need to standardize a tunnel broker protocol. Brian C: Does this replace 6over4 approach. Reply: No, it is complementary. ---------------------------------------------------------------- ---------------------------------------------------------------- Meeting adjourned