Editor's note: These minutes have not been edited. IPng Working Group Meeting December 1996 IETF San Jose, CA Robert Hinden / Ipsilon Networks Steve Deering / Cisco Systems Co-Chairs Minutes taken by Robert Hinden -------------------------------------------------------------------- Agenda -------------------------------------------------------------------- Monday 1:00-3:00pm Introduction and Bash Agenda / Steve Deering (5 min) Document Status / Bob Hinden (10 min) ITU Addressing Request Status / Bob Hinden (1 min) Priority Field / Steve Deering (10 min) Default Hop Limit / Steve Deering (10 min) IPv6 over Token Ring (10 min) BSD API / Bob Gilligan (10 min) Simple IPsec API / Dan McDonald (5 min) Advanced API spec / Matt Thomas (15 min) Tunneling Spec / Alex Conta (10 min) Header Compression spec / Micke Degermark (10 min) Host Anycast / Jim Bound (10 min) IPv6 Multicast Address Assignment draft / Bob Hinden (5 min) Monday 7:30-10:00pm 8+8 Addressing Proposal / Mike O'Dell (45 min) Alternative Addressing Architectures / Masataka Ohta (5 min) Multihoming / Source Address Selection / Steve Deering (30 min) Interface ID Proposal / Steve Deering (20 min) IPv6 MIB / Dimitry Haskin (15 min) Thursday 1:00-3:00pm IPSEC Report on UNH Interoperability Event 8+8 Proposal Router Alert Option / Ran Atkinson (10 min) Moving Base IPv6 Specs to Draft Standard / Steve Deering (30 min) IPv6 Packets over IPv4 Networks without Tunnels / Brian Carpenter (15 min) Multicast Routing / Thomas Narten (10 min) Router and Network Renumbering / Geert Jan De Groot & Bob Hinden Inter-Domain Routing (IDRP, BGP5, ?) / Bob Hinden (10 min) Address Prefix Notation / Alain Durand (5 min) Unspecified Address in Neighbor Discovery (5 min) ------------------------------------------------------------------ Introduction and Bash Agenda / Steve Deering ------------------------------------------------------------------ Steve Deering introduced the meeting. He said he now works for the "borg" (e.g., Cisco systems). He introduced Bob Hinden from Ipsilon Networks (who said had not been assimilated (yet)). Summarized sessions and 6bone BOF. Reviewed agenda. Asked for additional or removal of agenda items. Question was raised about discussing TAG switching use of IPv6 flow label. Deering said depends on outcome of Tag switching BOF. Short report on a new implementation of IPv6 for Linux, done at INRIA, and to be available for research use. It was announced by Jean Bolot. Further info can be found at http://www.inria.fr/rodeo/IPv6/ ------------------------------------------------ Document Status / Bob Hinden ------------------------------------------------ The following RFC's were published with Proposed Standard status: - RFC1970, Neighbor Discovery for IP Version 6 (IPv6) - RFC1971, IPv6 Stateless Address Autoconfiguration - RFC1981, Path MTU Discovery for IP version 6 - RFC2019, A Method for the Transmission of IPv6 Packets over FDDI Networks - RFC2023, IP Version 6 over PPP The following RFC's were published with Experimental status: - RFC1888, OSI NSAPs and IPv6 The following document was advanced to Proposed Standard by the IESG (but has not been published as an RFC yet): - An IPv6 Provider-Based Unicast Address Format ------------------------------------------------ ITU Addressing Request Status / Bob Hinden ------------------------------------------------ Hinden reported that he had not done this yet, but would do it prior to the Thursday IPng session. He did complete this by the Thursday session. The reply is included here. Internet Engineering Task Force IP Next Generation Working Group December 11, 1996 Mr. H. V. Bartine AT&T Bell Labs, Room 4K-316 101 Crawfords Corner Road Holmdel, NJ 07733-3030 Subject: Response to ITU SG 7 Request for IPv6 Addressing Code Point The IETF received a request from ITU-Telecommunication Standardization Sector STUDY GROUP 17, Rapporteur Q3/7 on 17 July 1995. The ITU requested an IPv6 Format Prefix for X.121 Public Data Network Addresses. It also suggested that ITU-T Study Group 2 may also make a similar request for E.164 addresses. The IP Next Generation working group of the IETF discussed the request at the working group meeting held on June 24, 1996 in Montreal. The working group concluded that X.121 Public Network addresses are not Internetwork addresses and that a Format Prefix (code point) was not warranted at this time. Consequentially the working group concluded that a better approach would be to treat the X.121 addresses in a manner similar to how IPv6 runs other networks technologies such as Ethernet, FDDI, Token Ring, etc. A definition of interface identifiers from the X.121 addresses should be created. The BCD digits of the X.121 address would be converted to binary and used as an Interface Identifier. An IPv6 over X.121 Public Data Networks document could be written in a manner similar to RFC1972 "A Method for the Transmission of IPv6 Packets over Ethernet Networks" or RFC-2019 "Transmission of IPv6 Packets Over FDDI". This approach would be compatible with the IPv6 control functions as defined in RFC-1970 "Neighbor Discovery for IP Version 6 (IPv6)". It would also support the creation of small independent subnetworks (e.g., clouds) in the X.121 Public Data Networks instead a single very large subnetwork. At the working group meeting an alternative approach was also suggested that would make use of the AFI for X.121 addresses in the NSAP addressing plan. This would fit into the framework defined in RFC-1888 "OSI NSAPs and IPv6". This alternative provides another approach to support running IPv6 over public networks that use X.121 addressing. The IPng working group would also like to invite representatives from ITU-T SG7 to attend the next IETF meeting and to present the IP Next Generation working group their thoughts on how IPv6 could be run over the public data networks. We look forward to your response in this manner. Contact Person: Robert M. Hinden Ipsilon Networks, Inc. 232 Java Drive Sunnyvale, CA 94089 TEL: +1 408 990-2004 email: hinden@ipsilon.com ------------------------------------------------ Priority Field / Steve Deering ------------------------------------------------ Deering proposed at the Montreal meeting to change the definition of the priority field and make it reserved. The original intent was to: - Generalized "drop-preference" provides the wrong incentive, encourages sending packet that won't be delivered - Potential other uses for those bits (e.g., "RED" bit, Clark's in/out-of-profile bit, ISP-private use. This proposal was disliked by people who want to favor interactive traffic over dialup or wireless links. Steve Deering proposed a new definition: - Declare that 4 bits of Priority are rewritable by routers/ISPs for private purposes (and exclude from authentication header). - Priority bits have no significance to receivers - Convention: Sender sets low order bit to mean interactive traffic. o Delay more important than throughput o Suggests that routers/ISPs use other bits before touching the "interactive bit". o Affects queuing only, not routing (since re-writable). Deering will write up as a email message and send to list. ------------------------------------------------ Default Hop Limit / Steve Deering ------------------------------------------------ At last meeting we discussed a proposal to make default hop limit to 255. Discussion on mailing list came to conclusion that 64 would be better choice. Deering proposed that we make this the default value. Working group agreed to 64. Note: This has no effect on the use of setting the hop limit to 255 as a mechanism to insure that the packet has not gone off link. Document editor will send email to IANA to add this parameter to IANA registry for IPv6 defaults. Christian Huitema suggested that routers should not advertise any default hop limit value without being explicitly configured. Discussion. There was not a consensus reached on this topic. Will be discussed further on the email list. ------------------------------------------------ IPv6 over Token Ring / Bob Hinden ------------------------------------------------ Bob Hinden discussed remaining issues with "IPv6 over Token Ring" draft. The main issues are how to handle mixed media bridging and token ring source routing. Conclusion was to add section describing how to handle mixed media bridging. Main issue is the selection of MTU. Default (without any configuration) should be 1500. There may not be perfect solutions but it important to document issue so device can be configured correctly. Does token ring source route takes up space in packet, so MTU becomes smaller. Thomas Narten offered to own getting these issues resolved and getting a new version of the draft. A working group last call will be done when this ID is out. ------------------------------------------------ BSD API / Bob Gilligan ------------------------------------------------ Rich Stevens is now co-author. Split advanced features to a separate document. Changes from previous version include: - Added section on interface identification (in sync w/ Advanced API spec). - Change multicast setsockopt() options to use interface identifiers. Previously used IPv6 addresses which do not work in all cases. - Added descriptions of gethostbyname(), gethostbyname2(), and resolver options. This matches the new version of bind (4.9.4). - Posix-free description of getaddrinfo() to match Posix 1003.1g (but Posix is definitive spec) - Added description of getnameinfo(). This is inverse function to getaddrinfo(), not in Posix 1003.1ga - Renamed inet6_isipv4addr() to inet6_isipv4mapped() to make name more clearly describe function. - Small working clarifications. Gilligan commented that change the priority field definition would require this specification to change too. Document editor will do a working group last call on this document. Goal is to publish an informational RFC. ------------------------------------------------ Simple IPsec API / Dan McDonald ------------------------------------------------ IPsec is mandatory to implement in IPv6. Reviewed basic concepts of IPsec functions and terminology. Summarized API functions: - All socket options are at the IPPROTO_IP or IPPROT_IPV6 level. - Categories are the actual options to be set are IP{,V6}_AUTH_LEVEL, IP{,V6}_ESP_TRANS_LEVEL, and IP{,V6}_ESP_NETWORK_LEVEL - Levels are the values for IPSEC_LEVEL_NONE, IPSEC_LEVEL_AVAL, IPSEC_LEVEL_USE, IPSEC_LEVEL_REQUIRE, IPSEC_LEVEL_UNNIQUE - Need one additional level for special apps. Change terminology to call it "payload" instead of "transport" because it may not always be a transport protocol. This work is being done in IPsec group and will be advanced there. ------------------------------------------------ Advanced API spec / Matt Thomas ------------------------------------------------ Check if w.g. is happy with advanced API spec. Matt poised several questions to the working group: - Scope. Would be nice to extend definition of scope to extend. - Does WINSOC copy this work? Not too much. This follows POSIX, WINSOC does not. - Neither API doc has any mechanism to set the "flow id". Think it belongs in this API doc or one of the other API documents. Deering thought this would be correct place to put it. There needs to be a kernel function to pick flow labels inorder to make they don't collide. Matt Crawford offered to help add this. - Should there be a mechanism to retrieve routing table information (e.g., routing socket). Comment was made that this is beyond scope of this specification. Should be in another document. ------------------------------------------------ Tunneling Spec / Alex Conta ------------------------------------------------ Changes since last version: - Replace term recursive tunneling with nested tunneling. - Add text to ICMP related to nested tunneling packets. - Clarify that refers to point-to-point tunnels only. - IPv6 tunnels must end in a unicast address. - Clarified security section to discuss use of security headers and how they are processed. - Clarified usage of ICMP packet too big to max (576, tunnel MTU). - Typos fixed and other small changes. Would like to forward to IESG. No one had any objections to moving this document forward. Document editor will submit to IESG for a proposed standard. ------------------------------------------------ Header Compression spec / Micke Degermark ------------------------------------------------ Changes from previous version (v01->v02) - Packet types FULL HEADER, COMPRESSED_NON_TCP, COMPRESSED_TCP, COMPRESSED_TCP_MODEL_TA - Use of length fields - UDP checksum not sent when zero - 0-bit in TCP change mask. TIMPSTAMP options ruins compression otherwise. When OPTIONS change, set 0-bit and send whole OPTION. - Header request (for TCP) - Hook for passing sequence numbers by additional header compression on top of UDP. - Small changes to demultiplexing procedure - Defined the ranges of configuration. parameters. Believes that point-to-point mechanisms are stable now and would like the draft to go to proposed standard. CRTP draft relies on this draft. There are still problems on multi-access networks. Will a separate document be issued. Yes, but additional problems need to be solved. There is now an implementation on BSD. Document editor will do a working group last call. ------------------------------------------------ Host Anycast / Jim Bound ------------------------------------------------ Need for host anycast addresses to support cluster type of technology, load balancing for servers, and need to support distributed process migration. Also support dynamic address reassignment for an existing network connection for both TCP and UDP. Support multilink and multihoming dynamic address changes. Support for nomadic computing. Proposes to: - Add "p" bit to mobile binding Update IPv6 destination option - Use the replay protection and security inherent in IPv6 mobility specification. - Define the enhancements needed for implementations Deering asked how these would be routed? Need to define ICMP extensions to handle of routing of host anycast addresses. Discussion about need for specifying routing behavior. ---------------------------------------------------- IPv6 Multicast Address Assignment draft / Bob Hinden ---------------------------------------------------- Published an internet draft with initial fleshed out IPv6 multicast address assignments. Intent is to send this to IANA as initial list of addresses to be published. One issue raised by this document is that except for Neighbor Discovery solicited node addresses, all of the other multicast address assignments fit into the low order 32 bits of the IPv6 multicast address. This lead to a discussion about 1:1 mapping between multicast addresses and MAC addresses. Discussion about alternative of expanding address space to include ND solicited node address or to shrinking it to not conflict with other multicast mappings. Hinden and Deering will propose to the mailing list that the ND solicited node address be changed to fit into a longer prefix (reduce the unique part to fit into less than 32 bits) --------------------------------------------------------- Monday 7:30-10:00pm --------------------------------------------------------- --------------------------------------------------------- 8+8 Addressing Proposal / Mike O'Dell --------------------------------------------------------- Motivations - IPv6 gives us a bigger version of a problem we currently don't solve - Need aggressive topological aggregation going forward - CIDRv6 isn't the answer for several reasons o CIDR efficiency decays over time o Multihomming is become more and more prevalent o Forced renumbering will succumb to market pressure (e.g., won't happen) Origins of the Proposal - Old idea , Doesn't claim to invent. - XNS certainly had the locator and identifier idea - IPv4 went the other way - Personally believes that XNS got it right - Others have discussed this before in IPng discussions - This work was catalyzed by an email from Dave Clark Important Notions - Split address into two pieces - One part reflects topological attachment to the Global Internet - One part is topologically-invariant, known as an "End System Designator" or ESD - Current proposal divides the 16 bytes in half, hence "8+8" - Strong distinction between "public topology" and "private topology" - The site is the fundamental unit of attachment to the global internet. - Large Structures, fundamental large-scale aggregation object - Deep equivalence of rehoming and multihoming (Fall back to alternate path is a type of rehoming). - Provides for transparent rehoming of Sites and Resellers o End tyranny of CIDR - Make multihoming an explicit service o Upstream providers have to do something explicit to heal failures. o Users pay for it. - Dynamic Insertion of Routing Goop by border routers o End systems don't usually have to know own routing goop o Certainly "can" know it, but site border routers can impose exit policy - Upward delegation of DNS o Automatic propagation of Routing Goop for Site-external resolution provides for easy delegation of IN-ADDR.APRA inverse lookups End System Designators Properties (ESD's) - Globally Unique (but no more than IPv4, IEEE MAC is good enough) - Designates an End System interface - real or virtual - End systems may be designated by multiple ESD's - An ESD may not necessarily designate a particular physical computer o Neighbor discovery provides for virtual address translation o Service location possibilities - ESD's are not guaranteed to be perfectly time-invariant o Altered only by some site internal topology changes Structure of ESD's - 15 bits of Private topology partition 32,768 distinct partitions in the private topology Population of each partition limited by IEEE MAC address space Any of 32 hossts/partition gives million-host site - 1 Mode bit determines format of 48 bit identity token 0 implies 48 bit MAC address 1 implies top bits of identity token imply subtype - 48 bit identity token Mode 0 : IEEE MAC 48 bit address Mode 1 : 45 IETF Node ID which is densely assigned Mode 2 : Identity token is officially assigned, non RFC1918 IPv4 address, right justified, zero padded Other Mode values reserved Structures for Sites - Sites can be very large and complex. - Sites are cheap, so needing more than one isn't really a hardship - Lots of topology design options - Public topology transit networks can also be sites - PTP provides for network-internal designations of elements which are part of public topology Routing Goop - RG is hierarchical locator - Forest of spanning trees with flat-routed between root of the trees - Conceptually flows outward from the originating large structure Questions is this different from CIDR? Yes and no. Comment that this this needs a different/better description. Very hard to understand in it's current form. Long discussion. No clear outcome. - Provides a framework for allowing the network to self organize - Large Structures encapsulate significant topological aggregation o Intentionally not a lot of them, only 14 bits allocated for LSID o Limit worst-case flat-routing for top-level region o Provide "routes of last resort" for default-free routers Next version of document will be clearer and simpler. Mike O'Dell thought it would be 6+2+8. Long discussion. Many questions. Chairs will make a decision on how to proceed. --------------------------------------------------------- Alternative Addressing Architectures / Masataka Ohta --------------------------------------------------------- Complete Separation between Locators and ID | 64bits | 64bits | +---------------------+----------------------+ | ILOC | IID | +---------------------+----------------------+ ^ ^ | | Locate (structurally subnet) | in the global internet | | Identify a host with global Internet Wrote ID a year ago that is available at: ftp://ftp.jain.ad.jp/pub/ids/draft-ohta-ipv6-addr-arch-00.txt Problem with Mikes 8+8 - ID's have no hierarchical structure - 48 bits are not enough for globally unique ID Warts with Site Renumbering - The locator of the hosts in the site changes - Intra-site topology is unaffected - Global unique ID which depends on site local topology is fine Warts with Mobility and Multicast - Encapsulation (MTU) - Subnet model at foreign subnet - Multicast addresses are location independent - IDs must be globally unique independent of site local topology Topology Independent ID - Removes mobility warts - Removes multicast warts - Enables full process migration - Enables site renumbering, of course. - Thus, is the way to go. Discussion comparing this proposal with 8+8. Conclusion is that they are very similar. Deering concluded that there could be separation between global info, site info, and identifier. ------------------------------------------------------- Multihoming / Source Address Selection / Steve Deering ------------------------------------------------------- There was much discussion of this topic on the mailing list over the past few months. Deering presented a particular model of a multihomed host, in which interfaces are grouped by links, links are grouped by sites, and sites are grouped into the global scope. Discussed the weak and strong models of multihomed hosts: - strong: (1) a host must not send a packet whose source address does not belong to the origination interface. (2) a host must not accept a packet whose destination address does not belong to the arrival interface. - weak: (1) a host may send a packet whose source address belongs to any interface on that host. (2) a host may accept a packet whose destination address belongs to any interface on that host. Multicast uses strong model -- necessary for source-sensitive multicast routing, and to avoid duplicate reception. Concludes that unicast SHOULD use weak model, but with source-address selection rules that ensure that source address differs from origination interface address only in unusual circumstances, e.g., when responding to a ping of a receive-only interface. Noted that the weak model is "less weak" in IPv6 than in IPv4 -- even in the weak model, must not violate IPv6 address scope constraints (link-local, site-local). However, this does *not* mean that source and destination addresses must have the same scope, and Deering recommended not adopting such an unnecessary constraint. Strong support for weak addressing model with strong scoping rules. Expects to have a draft in early part of new year. --------------------------------------------------------- Interface ID Proposal / Steve Deering --------------------------------------------------------- Discussion on KRE's draft. Now that current API drafts don't use addresses to identify interfaces, this may not be needed. Discussion. Deering took poll. No one supported keeping proposal. It will not be moved forward. --------------------------------------------------------- IPv6 MIB / Dimitry Haskin --------------------------------------------------------- Updated MIB2 to IPv6. Allows to implement IPv6 MIB without requiring any changes to the SNMPv2 SMI and compliant SNMP implementations. Drawback: IPv6 address as an instance-identifier uses 16 sub-identifiers. IPv6 (network layer) interface identification - An 32 bit integer in the 1 to 2147483647 range IPv6 MIB Groups - IPv6 General - ICMPv6 - UDP for IPv6 - TCP for IPv6 IPv6 General Group - ipv6IfTable - Info on entity IPv6 interfaces - ipv6IfStatsTable - Info on traffic statistics - ipv6AddrPrefixTable - Info on address prefixes that are associated with the IPv6 interfaces. - ipv6AddrTable - Addressing information relevant to the entity's IPv6 interfaces - ipv6RouteTable - Contains an entry for each valid IPv6 unicast route - ipv6NetToMediaTable - IPv6 address to media address equivalencies ICMP, UDP, TCP groups contain info on protocols, changed to include IPv6 addresses. --------------------------------------------------------------- Thursday 1:00-3:00pm --------------------------------------------------------------- --------------------------------------------------------------- Router Alert Option --------------------------------------------------------------- Discussed briefly and group agreed to do a working group last call. --------------------------------------------------------------- IPSEC --------------------------------------------------------------- Heard rumor that IPSEC w.g. was considering changing IPSEC to not include the flow label. Working group thought that it was important that this change be discussed in the IPng working group prior to any change in IPSEC. --------------------------------------------------------------- Report on UNH Interoperability Event --------------------------------------------------------------- Tested base spec, neighbor discovery, routing, MTU path discovery, applications, and tunneling Participants included: DEC, SUN, HP, IBM, Bay Networks, Cisco Systems, WIDE, FTP Software, Sumitomo ,Fujitsu, Hitachi, and INRIA. Most implementations supported basic specifications, neighbor discovery was supported by 2/3 of participants. Serious problems were found less than 1/4 of participants. Future plans for IPv6 testing will be IPv6 testing at Connectatheon 1997 (March 1-6, 1997) and Network+Interop - Las Vegas (first week of May 1997). --------------------------------------------------------------- Moving Base IPv6 Specs to Draft Standard / Steve Deering --------------------------------------------------------------- Discussed whether w.g. thought we should advance basic protocols to Draft Standard. Mentioned that we will have to show evidence of implementations of all features. Question about impact of 8+8 proposal. Chairs agreed to generate a list of changes which are being considered to the basic specifications. --------------------------------------------------------------- 8+8 Proposal --------------------------------------------------------------- Chairs proposed to allocate a Format Prefix for 8+8 addresses. Implementations would have special pseudo checksum rules for this FP. Would allow us to experiment with 8+8 without making a final commitment. Discussion about impact of using 8+8 proposal on various parts of IPv6 architecture. Issues raised include: - IPv6 over Foo - DHCP impact - TCP pseudo checksum calculation - DNS changes - How routers would put new "Routing Goop" in addresses - Size of identifier - Are MAC addresses used as identifiers are globally unique Chairs proposed to hold a interim meeting before the next IETF to discuss 8+8 in more detail. Working group agreed. Details to be announced on mailing list. ----------------------------------------------------------------- IPv6 Packets over IPv4 Networks without Tunnels / Brian Carpenter ----------------------------------------------------------------- Brian Carpenter presented an overview of the draft written by Cyndi Jung and himself. The basic notion is to use an IPv4 multicast network as a local link for IPv6. Isolated IPv6 host just runs, it does not need a configured tunnel or IPv4 compatible addresses. MTU size default is 1480 (1500 - IPv4 header size). Router advertisements can change this. Alternative is to use "local IPv4 MTU" minus "local IPv4 header size". Probably not necessary because 1480 is likely to work over most multicast links. Comment multicast may be running over tunnel so 1460 might be better. Frame format shows IPv4 header over an IPv6 header. Proposes New protocol identifier to identify these packets. Comment that this may not be necessary. Link local address. Stateless autoconfig works as normal. Suggest normal 80 bit prefix FE80::. Use zero padded IPv4 address of host as 48 bit token. This seems more consistent than using 96 bit prefix and 32 bit token. Could easily be adapted to 8+8 token. Address Mapping: - Unicast : Neighbor discovery conveys IPv4 address around as link layer address. - Multicast: Use last 3 bytes of IPv6 multicast address as the last 3 bytes of IPv4 (pseudo link layer) multicast address. If no IPv4 multicast support, there is a possible kludge using IPv4 broadcast. - Another proposal (Steve Deering) would be to configure host with IPv6 host with unicast address of IPv6 router and run ND over this tunnel. Issues: - Pad to 64 bit align the IPv6 header - MTU = 1480 - IPv4 TTL - Token Length (32 or 48) - Drop the broadcast kludge - Drop the NBNA note - Enumerate multicast groups for ND - Define scaling limits The working group encouraged the authors to revise the draft and to continue discussion in the ngtrans working group. ---------------------------------------------------------------- Multicast Routing / Thomas Narten ---------------------------------------------------------------- Asked if we know what we are doing with multicast routing. Deering answered that he needs to write a document on how to generically (e.g. protocol independent) handle Multicast routing Deering mentioned that the decision was made to not port DVMRP to IPv6 because the plan it that unicast and multicast routing topologies should be the same. We should concentrate on multicast routing protocols that utilize the unicast routing table. PIM Dense and Sparse mode currently handle IPv4 and IPv6 multicast. Today people should use PIM for IPv6 multicast routing. ---------------------------------------------------------------- Router and Network Renumbering / Geert Jan De Groot & Bob Hinden ---------------------------------------------------------------- Geert Jan De Groot ------------------ We have auto configuration, but can't renumber routers automatically. Routers are still configured manually. Will network really be able to be renumbered. Renumbering is needed. Customers changing ISP's should not result in additional prefix. ISP changing transit provider should have minimal effect on customers (next level provider). Topology changes may make renumbering needed. The number of routing prefixes is the most important issues in the operation of the Internet. Also, Pilot-sites are asking for real address now to avoid having to renumber. Currently the are about 40,000 prefixes. There are 1800 autonomous systems. There are only 1800 routing policies. Ideally there should only one prefix per AS. Need some time of prefix redistribution mechanisms. Also need to work on Pier problem (IP addresses in configuration files, etc.). Bob Hinden ----------- Background - Neighbor Discovery Provides Mechanisms to Assign Prefixes to Nodes and Add / Delete Prefixes for Nodes - Currently Routers Must be Configured with Interface Specific Prefix Information - Missing Piece is how to Configure Routers Automatically Router Renumbering - Internet Wide Router Renumbering o Too Scary o Focus on Site - Functions Needed o Initial Configuration o Assign Prefixes (+ related parameters) to Interfaces o Change Configuration o Change Prefixes on Interfaces o Delete Prefixes on Interfaces o Work after Site Partition (e.g., Healing) Basic Mechanism - Periodic Multicast (~1-5 minutes) of Router Renumbering (RR) Advertisement o All Routers in Site process RR Advertisements o Authentication is Very Desirable - Two Multicast Addresses (with site scope) o Router Renumbering Advertisement Address o Router Renumbering Solicitation Address - Router can Solicit RR Advertisement by sending RR Solicitation to RR Solicitation Multicast Address o When Needs Prefixes or Prefixes timeout o When Partitioned is healed RR Advertisement - Contains One or More Sets of RR Info Each Set Contains: o Operator o "A" Prefix (128 bits) and Prefix Length (8 bits) o "B" Prefix (128 bits) and Prefix Length (8 bits) o Parameters o Lifetime o Precedence o Max Hop Limit o Other ? Operators - Add: On Interfaces that Match "A" Prefix / Length Add "B" Prefix / Length / Parameters - Change: On Interfaces that Match "A" Prefix / Length Change to "B" Prefix / Length / Parameters - Delete: Delete Prefix ("A") (and Parameters) from Interfaces which Match "A" Prefix / Length Misc - RR Advertisement also includes a Sequence Number o Increment Sequence Number when Contents Change o Receivers can ignore Duplicates Issues - Should RR be Used to Do Initial Interface Prefix Assignment? - Would "Current Prefix State" Messages be Simpler than Change State Operators? - Relationship to 8+8 Proposal? Summary - Proposal would Make it very Easy to Add New Global Prefix to Site o Add Operation with Match on Constant Part of Prefix on all Interfaces - Change and Delete also Easy - Supports Individual Interface Changes o Match on Link Local Interface Address with Prefix / Length (128) There was general interest in pursuing this work. An internet draft will be written. ------------------------------------------------- Inter-Domain Routing (IDRP, BGP5, ?) / Bob Hinden ------------------------------------------------- Hinden raised the issue that there was not very much progress on implementations of IDRP for IPv6. He mentioned that he had heard from ISP's that they did not want to deploy IDRP and would prefer an update to BGP. Joel Halpern added that the plan in the routing area was to not do another version of BGP. IGRP was to be the replacement for BGP. Dave Katz suggest that it would be very easy to add options to BGP4 to carry IPv6 interdomain routes. Dimitry Haskin said it would be very easy (two weeks work) to do this in his implementation, where doing IDRP would be a major effort. Working group thought this would be a good thing to pursue. Dimitry and Dave agreed to write up a proposal. ---------------------------------------------------------------- Address Prefix Notation / Alain Durand ---------------------------------------------------------------- Raised issue with how IPv6 addresses with prefixes should be written. Currently in the RIPE registry they are not being written consistently. Examples ::/96 FED0::/80 5F06:B500:/32 This needs to be added to the next version of the addressing architecture document. Will be added to list of changes for this document. ---------------------------------------------------------------- Unspecified Address in Neighbor Discovery / Dan Harrington ---------------------------------------------------------------- Use of unspecified address as source address is only defined for DAD, using multicast destination address (network + link). Should expand ND input packet validation rules to silently drop such packets. Group agreed to change this in next version of ND. ---------------------------------------------------------------- Tag Switching use of Flow Label ---------------------------------------------------------------- No one attended the meeting who wanted to talk about this. The working group said it was important that any proposal for changing the definition of the IPv6 flow label should be done here. The decision to change the semantics of the IPv6 flow label belongs to the IPv6 working group. ---------------------------------------------------------------- Mobile IP Request / Charlie Perkins ---------------------------------------------------------------- Mobile IP for IPv6 would like to be able to send a request to use an anycast cast address to all IPv6 mobile IP home agents. Approach is to tunnel to an anycast address for home agents with the inter packet addressed to the All Home Agents multicast destination with link scope. +---------------------+-----------------+ | Anycast | Multicast | +---------------------+-----------------+ | Subnet prefix + 000 | All Home Agents | With Hop limit = 1 Discussion about requiring all IPv6 routers to support mobile IP. Could also be done by allowing tunnels to be created to anycast address (which is not supported in current draft). The result of this discussion was to modify the tunneling draft to permit tunnels to be set up to anycast addresses to handle this function. ----------------------------------------------------------------------------- -----------------------------------------------------------------------------