IPng Working Group Meeting Tokyo September 29, 1999 - October 1, 1999 Robert Hinden/ Nokia Steve Deering/ Cisco Co-Chairs Minutes taken by Robert Hinden and Steve Deering. ------------------------------------------------------------ Agenda ------ Introduction / S. Deering, B. Hinden Local Site Introduction / Jun Murai ICANN IPv6 Status / Jun Murai Multihoming - IPv6 Address Scoping Model / S. Deering - Multihoming Overview / S. Deering - Near term host mechanisms / R. Draves o Source & Destination Address Selection o Multihoming, Policy and Home Networking / G. Tsirtsis - Mobile IP Mechanisms for Multihoming / F. Dupont - Longer term Host Mechanisms / E. Nordmark o API w/ DNS Names interface o Preserving Active TCP Sessions / P. Tattam Multihoming (continued) - Router Only Mechanisms / Itojun o RFC2260 Style for IPv6 o Multiple Prefix ISP Support o Use of Router Renumbering for ISP Selection / G. Tsirtsis DNS Games / F. Dupont Model for IPv6 Renumbering / B. Hinden Plug & Play Architecture / S. Deering API Issues / E. Nordmark - Multihoming - Scoping --------------------------------------------------------------- --------------------------------------------------------------- Wednesday / 29 September 1999 ----------------------------- Introduction / S. Deering, B. Hinden ------------------------------------- Chairs presented a gift to Jun Muri. Reviewed agenda. No changes to agenda. Local Site Introduction / Jun Murai ----------------------------------- Acknowledged sponsors that made this meeting possible. Local info: - Staff w/ KAME polo shirt or WIDE yellow tag. - Lunch on fifth floor, need name tag - Reception tonight at Miyako Hotel at 1830 tonight. Info about meeting - 91 registered attendees (one over meeting limit) 18 outside of Japan - Use microphones, meeting being audio cast. - No smoking in meeting room Japan Session - 1330 - 1530 on 1 October Agenda KAME project Hitachi IPv6 router: GR2000 IIJ IPv6 trial service WIDE 6bone JANOG IPv6 installation event THAI IPv6 conformance test WIDE Project - Research consortium on the Internet in Japan since 1988 - 39 universities and 66 companies - 18 working groups - More info at http://www.wide.ad.jp/ Group of developers/operators/researchers Project Approaches - Missionary work IPv6 - Challenges TCP protocols Mobile internet - Testbeds IPv6 Multicast Mobile - Deployment WIDE Camp - 4 day camp in country area, every March and September - 230 participants - Working group meetings - Large testbeds IPv6 ready, OSPFv6 - IPv6 installation program KAME Project - Single effort 8 core members from 7 Japanese companies Fujitsu, Hitachi, IIJ, NEC, Toshiba, YDC, Yokogawa - Two year joint project April 98 - March 2000 Core members for IPv6 three days a week. - KAME A short word of KArigoME, where our office locates Turtles IPv6 on Production JB (Japan Bone) Full native IPv6 backbone across Japan # of IPv6 over IPv4 tunnel is being decreased Remote Classes - Two sites in Japan and another in US. Jun Murai and Larry Landweber. - 15Mbps line between US and Japan. - Planning to use IPv6 multicast. Future Plans Household equipments - Cheap IPv6 chips are necessary Cellular Phones - Cellular phones oriented mobile IPv6 Automobiles Home network - How many subnets One /64 enough - Prefix allocation from ISP ICANN IPv6 Status / Jun Murai ----------------------------- IPv6 Address Allocation ICANN Working w/IANA, RIR not to slow down process APNIC 2001:200::/35 Wide project 2001:208::/35 National University of Singapore 2001:210::/35 Connect AT 2001:218::/35 OCN (NTT) JPNIC Started working w/ APNIC ----------- Multihoming ----------- IPv6 Address Scoping Model / S. Deering --------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] Questions/Discussion How do 6to4 address fall into this framework. Answer: They are normal global scope addresses. Also see RFC2546. Question about if unicast and multicast scope boundaries must be the same. Yes, no reason to make them different and Unicast probably does need more scope values. ACTION: Deering to write document defining IPv6 Address scoping model Multihoming Overview / S. Deering --------------------------------- Repeat of talk Rich Draves gave at Oslo IETF. [See slides at http://playground.sun.com/pub/ipng/html/meetings.html ] Question that ND does not clearly define what is a neighbor regarding sending redirects. This may need clarification in the ND spec. Nordmark suggested we think about better terminology. For example multi-sited host is better than just saying a multihomed host. It will help to make these issues clearer. ------------------------------------- Near term host mechanisms / R. Draves ------------------------------------- Source & Destination Address Selection -------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html ] Source Address Selection and Destination Address Ordering - Minimal requirement for all implementions - Automatically pick reasonable source and destination addresses - Compliment other multi-homing approaches. The Big Picture - Using longest-matching-prefix getipnodebyname Inside IPv6 stack +-----------------------------+ +-------------------------+ | Destination Address Ordering| | Source Address Selection| +-----------------------------+ +-------------------------+ + minimal changes - dies not try all pairs + scope/prefix matching - apps must try multiple destinations ? incorporate TCP feedback - needs positive feedback ? big timeouts ? poor admin control Just Use Router-Based (RFC22260) Approaches? - Doesn't find common scope/prefix - Doesn't help multihomed hosts - Doesn't help with ISP/router failures o Just ISP/site link failure - Inefficiency of using a tunnel - ISPs unwilling? Just use address selection/ordering? +--------+ +---| ISP A |--+ / +--------+ \ / | \ +--------+ / | \ +--------+ | Site 1 |/ | \| Site 2 | |1a, 1b |\ | | 2a | +--------+ \ | +--------+ \ +--------+ +----| ISP B | +--------+ Suppose the link between site 1 and ISP A fails Then Site 1 initiates a TCP connection to Site 2 Only works if you try all of the tuples. Source Address Selection < draft-draves-ipngwg-simple-srcaddr-01.txt> - Only applies when app has not specified a source address - Define candidate set of source addresses - Define candidate set of source addresses - Define pair wise source address comparison - Always attempts communication Candidate Source Address Set - RECOMMEND just addresses assigned to outgoing interface, but allow addresses assigned to other interfaces (depending on destination addresses) - Implies routing is done before source address selection - Q: Under what circumstances, if any, should we allow a source address not assigned to the outgoing interface? Discussion on how to control this behavior. Assuming the semi-strong model, then the document should be very clear on what must be done and what things are alternatives. The document should discuss them in detail. Some addresses like home address need to be handled differently. Might want to treat this as a separate interface. It can be considered as a pseudo interface. Scoping document needs to include discussion on how to handle mobile addresses. A home address is real when the node is "home", and virtual when it is away. Using Differently Scoped Address - Small Source => Large destination o Packet may fail to reach destination - Large source => small destination o Asymmetric routing may cause replies to fail o Possible confusion interpreting ICMP errors Using A Deprecated Address Question: Recommend, allow, forbid: - When there are preferred addresses of larger scope? - When there are preferred address of smaller scope? - When there are preferred addresses on other interfaces? Deprecated means to only use deprecated addresses for continuing communication, but to not use them for new connections. Source selection should not override this. Discussion. Need to also better define what initiating new communication means. What does this mean for protocols like UDP? Needs to be clarified. Comment made that this approach will make it easy for hostile host to cause all address on the link to be unusable. Maybe deprecated should just be at the end of the list (e.g. after link local). Multicast Scopes - Mapping unicast scopes to multicast scopes o unicast link -> multicast link o unicast site -> multicast site o unicast global -> multicast global - Then do scope comparisons using multicast scope values - Q: Unicast vs multicast site boundaries? Non-Aggregatable Addresses - v4-compatible: global scope, preferred - loopback: node-local scope, preferred - other prefixes: global scope, preferred Destination Address Ordering - Try destination addresses w/ smaller scope first - Try addresses that have longest possible match with a potential source addresses - User-level library code calls into stack to get potential source addresses appropriate for the destination addresses. Alain D. pointed out that 6to4 addresses the longest match prefix approach does not always make the correct choice. Long discussion. Need to discuss 6to4 later in the meeting. Perturbing DNS Order - DNS order may reflect admin preference o Round robing among server replicas - Use "stable sort" that does not return order when the matching prefix lengths equal - Q: Hardcode bit length boundaries, or rounding to nearest 4 bits? Discussion about cases that don't work. Conclusion is that this approach may be suboptimal, but is sill better than random. Can't put rules in selection criteria that know about allocation boundaries in addresses. Performance - Getting list of source addresses may be expensive - Use simple caching to avoid system calls - Q: Invalidation strategy. Simple one second timeout? Trying Multiple source addresses - TCP tries multiple source addresses Serially? Parallel? - Implementation change, NOT protocol change - Then RFC2260 not needed for basic availability - All dst/src/ addresses pairs get tried But in the wrong order - Q: Should we pursue this approach Comment that this has a scaling problem if done in parallel. Serial might be better but how long to wait. Might also appear to be like a TCP SYN attack. Have to be careful to not use up all of a servers TCP connection resources. Will have new draft including destination address selection in time for next IETF meeting. ACTION: Continue w/ this work. Draves to revise src address draft and produce new destination ordering document. Standards track. Multihoming, Policy and Home Networking / G. Tsirtsis ------------------------------------------------------ [See slides at http://playground.sun.com/pub/ipng/html/meetings.html ] Pro-Multihoming technologies - ADSL modems w/multiple PVC's - 2B ISDN lines - phone line + cable modems - phone link p+ satellite set top box - power lines, home w/ central networking, etc. - Any combination of the above - Any combination of the above is possible and most probably happens by accident! o Always ON is the turning point! Picture of PC connected to two ISP's Router at connected to two ISP's IPv4 - IPv6 Comparison - In IPv4 endpoints have 1 address each (often in private w/ NAT on the gateway) o Policy in Gateway is OK (since there is NAT) but not mechanisms to se it up (manual) o If more than one gateways... forget it! - In IPv6 end points may have as many addresses as external connections + local ones o Policy in gateway is not enough (no NAT) o If more than one gateway...? Policy Example - IPv4 [figure w/ text] Policy Example - IPv6 Home Networking evolution - Home networking is still embryonic - Zeroconf wg will look at autoconfig of an HN "walk before you fly" approach - In future more complex mechanisms will be required - IPv6 should offer "hooks" to allow this to evolve, but probably too early to actually define Multihoming and Policy - Problem: Local policy may need to override normal (network layer) address selection decisions! - Solution: provide hooks so higher layers can impose policy to address selection. Agree on interaction between address selection and policy Discussion. How to define these policy rules? Need to get agreement on these rules. Where do these rules fit in source/destination address rules? Also, limits on what policy can specify. Need to pick some things if we expect implementors to do similar things. Suggestion that if there is some way to think about this as a table of records to step through. Need to define semantics of records. Other issue raised is who will control policy, who advertises it, etc. It is premature to make this a working group item. Need to define mechanisms of S/D address selection, before we can apply policy to them. Mobile IP Mechanisms for Multihoming / F. Dupont ------------------------------------------------ [See slides at http://playground.sun.com/pub/ipng/html/meetings.html ] Figure w/ example of Site connected to multiple ISP w/ one access link broken. .............................................. . . +----------+ +-----------+ . | | | | +---+ | A | | B |.....| X | | | | | +---+ +----------+ +-----------+ | | | X (link down) | +--------------+ | +------| Site |--------+ | H | +--------------+ - Host H uses the A-H for source address and sets a Home Address destination option w/ B-H in all packets - Host X swaps A-H and B=H addresses before looking for the PCB of the connection for received packets - Host H sends a Bind update to X w/ A-H for the care of address - Then host X send packets for H a/ A-H as the destination address and with a Routing Header for B-H (immediate hop) - On reception host H swaps A-H and B-H addresses Issues - Common Mobility -> Security - Bindings are only an optimization for mobility - Only works for TCP - Can't send a binding update if both source and destination sites share the same prefix (of the provider that is down). - Binding updates are only an optimization for mobility o Refresh strategy o Correspondent detection o Double move - Security Discussion about if mobile IP group will solve security related issue. This approach is a solution that can be considered once IPv6 Mobility is done and deployed. IPv6 Mobility is is dependent on IPSEC deployment. IP Mobility can then be considered a solution for IPv6 multihoming later once these dependencies are resolved. ----------------------------------------- Longer term Host Mechanisms / E. Nordmark ----------------------------------------- API w/ DNS Names interface -------------------------- [ See slides at http://playground.sun.com/pub/ipng/html/meetings.html ] Goals - Try all possible destination addresses each with the "best" source address o Possible without any modifications - Try all destination and source addresses in some order - Try all destination and source addresses in "best" order - Take into account previous communication attempts - UDP as well as TCP Existing APIs - getipnodebyname() - just for IP address - getaddrinfo() - returns full sockaddr o Could return different address families - connect()/ sendto()/ sendmsg() getipnodebyname() - Can return all destination addresses - The application can try them in turn - The protocol stack will pick "best" souse address for each attempt getipnodebyname() example (I) int myconnect2( char *hostname, int port) { struct sockaddr_ in6 sin; struct hostent *hp; int sock, err; int h_ addr_ index; /* Open socket. */ sock = socket( AF_ INET6, SOCK_ STREAM, 0); if (sock == -1) ... /* Get host address. An IPv4-mapped IPv6 address is okay. */ hp = getipnodebyname( hostname, AF_ INET6, AI_ DEFAULT | AI_ ALL, &err); if (hp == NULL) ... /* Make sure all sockaddr_ in6 fields are zero */ bzero(& sin, sizeof (sin)); sin. sin6_ family = hp-> h_ addrtype; sin. sin6_ port = htons( port); getipnodebyname() example (II) /* Try all returned addresses until one works */ h_ addr_ index = 0; while (hp-> h_ addr_ list[ h_ addr_ index] != NULL) { bcopy( hp-> h_ addr_ list[ h_ addr_ index], &sin. sin6_ addr, hp-> h_ length); if (connect( sock, (struct sockaddr *)& sin, sizeof (sin)) == -1) { if (hp-> h_ addr_ list[++ h_ addr_ index] != NULL) { /* Try next address */ continue; } perror(" connect"); freehostent( hp); (void) close( sock); return (-1); } break; } freehostent( hp); return (sock); } getaddrinfo() - Can return any address family o AF_ INET, AF_ INET6, or something else - Returns all of sockaddr structure o Could add fields to sockaddr_ in6? o Or define new address family with new sockaddr structure? getaddrinfo() example int myconnect3( char *hostname, char *servicename) { struct addrinfo *res, *aip; struct addrinfo hints; int sock = -1; int error; /* Get host address. Any type of address will do. */ bzero(& hints, sizeof (hints)); hints. ai_ flags = AI_ ALL | AI_ ADDRCONFIG; hints. ai_ socktype = SOCK_ STREAM; error = getaddrinfo( hostname, servicename, &hints, &res); if (error != 0) ... /* Try all returned addresses until one works */ for (aip = res; aip != NULL; aip = aip-> ai_ next) { sock = socket( aip-> ai_ family, aip-> ai_ socktype, aip-> ai_ protocol); if (sock == -1) ... if (connect( sock, aip-> ai_ addr, aip-> ai_ addrlen) == -1) { perror(" connect"); (void) close( sock); sock = -1; continue; } break; } freeaddrinfo( res); AF_INET6LIST idea (Itojun) - Have getaddrinfo return a new address family where the sockaddr is an array of sockaddr_in6 - Applications transparently pass the to connect() and the protocol stack receives all addresses for destination - Issue: What about UDP applicaitons? sento() does not know when to try the next address Could pass AF_INET6LIST as hint to getaddrinfo for TCP applications sin6_src_id (Erik) - Add a (hidden) field to sockaddr_in6 structure to encode an identifier for the source address By default set to zero - Protocol stack u uses a non-zero number as a hint for which source address to use - Getaddrinfo() can set this thereby controlling the order of the (dest, source) pairs - Getaddrinfo() can set this thereby controlling the order of the (dest, source) pairs o Implies that it would return N* M addresses when there are N destination addresses and M possible source addresses sin6_src_id (II) - Also helps w/ UDP servers if recvfrom sets the id value based on the destination - UDP application would need to try all addresses returned by getaddrinfo() - Issue: adding field to sockaddr_in6 breaks binary compatibility - Issue: requires that applications zero out all of sockaddr_in6 when using getipnodebyname o To avoid spurious non-zero src_id values o sin5 scope_id might already require this? New API ideas - Connect to FQDN - Connect to a list of addresses - Only works for TCP o UDP needs list of pairs plus the ability to provide feedback on what pairs worked or failed Discussion about what IETF and do and what XNET is doing. XNET is currently working on the basic API. We should be able to send them changes now regarding changes we are considering. Question about when people can use the advanced API. Might be too late for most people. Long discussion about IETF's role in developing API. Connect to FQDN - tcp_connect(char *hostname, uint16_tport) o patterned on java.net API o Would try all source and destination address combinations until one succeeds o Potential for building TCP "renumbering"under this API (but might be true for the other APIs as well) - Do we need symmetry - add a tcp_accept() which returns a hostname? Connect to list of addresses - Could use regular connect() with AF_ INET6LIST and getaddrinfo - mconnect( int sock, int num_ addrs, struct sockaddr *addrs[], int length[]); - UDP would still need separate mechanism UDP API Idea? - Define AF_INET6PAIR and struct sockaddr_in6pair which contains a source and a destination in6_addr (and port, etc.) - Use AF_INET6PAIR as hints with getaddrinfo - Application loops over address pairs calling sendto/ sendmsg - When failed calls inet6_ addrhints(& sin6pair, 0); - When ok calls inet6_ addrhints(& sin6pair, 1); - Note: semantics of address pair rather similar to sin6_ src_ id idea. UDP API Idea? (II) Issue: can one roque application calling inet6_addrhints() cause denial-of-service for other applicaitons running on the same node? o This is not an issue if the feedback is done by the trusted TCP protocol stack Proving base for TCP Survivability and reachability history - Either FQDN or address list can provide TCP w/ list of addresses for connection - Sharing information (history) across connections require a "key" to identify the information o Can't use an address to identify other addresses - FQDN foo.example has addresses A.1, A.2, B.3 - FQDN foo_A.example has addresses A.1, A.2 - A.1 can't identify the set of addresses o Seems to imply FQDN as a "key" i.e. TQDN connect() is needed. Discussion. Notes - We talk about (src, dest) pairs but it should really be (src, dest, outbound interface) to be general o Or can we assume that a source address uniquely identifies the interface? A non-global scope source address should have sin6_scope_id to indicate the interface. Discussion. What happens next? Would be good to do some prototyping. Also, need to get a handle on what UDP applications need. Comment, it is ok to start w/ TCP. What is learned can be applied to UDP applications. ACTION: Continue work on this API. ---------------------------- Thursday / 30 September 1999 ---------------------------- Preserving Active TCP Sessions / P. Tattam ------------------------------------------- Introduction - Multihoming can break TCP end-end connectivity - Possible technique allows end points to multihome without multiple session establishment or router intervention Required conditions to be met by solution - Meets minimum security requirements - at same level as IPv4? - Fits established IPv6 multihoming principles (must be aggregatable) - Needs minimum participation by intervening routers - Preserves TCP checksum constraints - Needs to survive network outage in either direction Redefine problem - Existing practice insists one address to one address - Can we redefine connection to be many address to many address? - Can we secure the set of addresses at each end? - Concept of a bounded set of addresses ( key to security) - Set of (Src[n], Dst[m]) represents all valid paths How do we do it - By establishing a set of addresses at the beginning of session - Use the 3 way handshake to facilitate - Use IPv6 options to send list of additional prefixes in SYN packet (PREFIX_SYN option) - In the ACK packet to SYN, send back subset of prefixes (PREFIX_ACK option) - If bounded, security should be about same level as 1-1 - Once the sets are negotiated at each end, they should not be allowed to alter Discussion about why IPv6 option, not TCP option. TCP options size is limited to 40 bytes. This is not enough to add many IPv6 addresses. Also currently used for current TCP options. Question as to why send ack w/ subset of options. Wanted to have other end to have control of what was actual used. Also, serves as confirmation that this options was received and understood. Comment that IPv6 options are not covered by TCP checksum. Not in pseudo checksum calculation. This might be an issue. Breaks security assumptions. Loss of connectivity - View connection as having multiple addresses at each end - Visualize it as two barrels representing the source & destination addresses respectively - If the connectivity is lost, rotate the barrel at either end until it works - Will need information from routing subsystem to make decisions Question if initial connection set up can work with first addresses. If not, might cause spoofing problems. Proposal assumes that it must be set up w/ initial addresses. Comment that this does not help w/ renumbering unless new prefixes are know in advance. Comment that it would be good to include in list of addresses some sort of preference or ordering requirement. This might be better than a random selection. Downsides? - Can't renumber - Need to develop mechanisms to feed back broken connection information. - Not as secure as an IPsec solution - Needs stack modifications - Will take more memory in TCP stack implementation, but cost is not excessive Question about which addresses to for TCP checksum calculation. Could be either, but might be more efficient to use the addresses on the receive side. Transmit might be reverse. Can both ends use any combination of addresses, or must both sides use the same address pairs. If former, then it would create asymmetric routes. Questions arising - Can this mechanism be improved to allow for parallel connects? - Can't allow additions to set after establishment of connection - Should we allow prefixes to be removed from the sets (DoS attack?) - Deprecating? (tag prefix as lower priority?) - What about VALID -> DEPRECATED -> VALID? Discussions. General feeling that this is worthwhile. Not clear it is with in the scope of working group. On the other hand, the w.g. is responsible for solving multihoming and renumbering. Comment that use of IPv6 option (as opposed to TCP option) not being covered in checksum header. Might be able to extend TCP in backward compatible way. On the other hand this approach is easier to apply to other protocols like UDP. Could include an additional related checksum in new options. Concern that algorithm when to switch addresses needs to be better specified. Performance problems for big servers if they have to try a long list of addresses. This is a good reason to allow ACK to carry a list of acceptable addresses. ACTION: Author will write up a draft describing this proposal. Needs to be looked at by transport experts. Update on Longest Prefix Match (LPM) / A. Durand ------------------------------------------------- Three Remaining Issues - IPv4 compatible You may end up selecting IPv4 compatible instead of global IPv6 - 6to4 Unpredictable behavior, depends on TLAs - Several xTLAs for one ISP You may select a sub optimal path Three Solutions - IPV4 compatible Create a new pseudo scope, larger than global - 6to4 idem, with: scope(global) < pscope(6to4) < pscope(::IPv4) - Many sTLAs perform LPM on a restricted subset, if src and dst belongs to the same meta-prefix Questions: Would pseudo scope apply to source and destination address selection. Yes. Not so clear you want to do it for source address selection. Desirable to pick source address of same scope of destination address. Comment that we really need a policy hook regarding 6to4 addresses. Meta Prefix: update RA (1/3) - In each Prefix Advertisement P/Plen (optional) o Add 1 bit flag M o Add 1 byte in reserved2 for the size of your ISP sTLA: MPlen - New rule: prefer (P, src, dst( if: o scr in included in P/Plen o dst is included in P/Mplen - Fall back o Choose randomly among global scope pairs - if M flag is not set: o Do not perform LPM on the set of global pairs (src,dst), choose randomly among global scope pairs - Mplen is manually configured on each router Comment that this adds considerable complexity to configuration and hosts. Not clear that this really helps. Uncomfortable that this is adding in detailed about the boundaries in the address. We worked very hard to keep hosts ignorant of allocation boundaries in addresses. [Format of proposed Router Advertisement changes] -------------------------------------- Router Only Mechanisms / Itojun Hagino -------------------------------------- Clever exit Router Approach / Jun-ichiro itojun Hagino ------------------------------------------------------ Multihoming support approaches - "Clever end node" approach o Try to find the best (src,dst) pair on connection establishment o Switch to better (src,dst) pair during connection - "Clever exit router" approach o Try to deliver packets of any (src,dst) during failure on exit links o Needs no implementation change, or changes in specific machines only - The latter makes problem easier for the former Comment that this doesn't always help the hosts. It may keep the host mechanisms to not be used as much. Problem w/ "clever end node" approach - Needs implementation change everywhere - deployment problem - End node does/should not not have topology/routing info o IPv6 spec tries to simplify host model - Without probe packet, only implements heuristics o Longest match does not work for different TLAs - With probe packet, adds delay in setup o Use of history may raise cache management issue/overhead - May introduce complex interaction between router and host - Slow if there's reachability problem - I'm not objecting, just saying it's not enough "Clever exit router" approach - Try to deliver packets of any (src,dst) during failure on exit links - Needs no implementation change, or changes in specific machines only - Exit routers knows about topology at the exit link - Improving reachability is always a good thing o Helps "clever end node" - May need ISP coordination RFC2260, chapter 5.2 - draft-itojun-ipv6-2260-00.txt - Deliver traffic across link, during link failure - No extra routing announcement o Friendly with IPv6 aggregation policy - Solves ISP link failure, no others o Reachability will be improved o No specific "policy" implemented - Needs a bit of coordination on routing metric RFC2260: initial setup Get address from multiple ISPs, route them locally IPv6: an end host can get addresses from multiple ISPs, \ or single address (ISP A) (ISP B) ISP-BR-A ISP-BR-B | | |Primary link | | | | | +---|-----------------------------|--+ | E-BR-A E-BR-B | | | | Pref-A <----------> Pref-B | +------------------------------------+ RFC2260: configuring secondary link Configure backup link over other physical medium Announce weaker route via secondary link ISP-BR-A ISP-BR-B | | | | | \-----------------------+ | | | Secondary link | | | | +----------------------|-/ | | | | | | | | | | | | | | | | | +---|--|----------------------|---|--+ | E-BR-A E-BR-B | | | | | +------------------------------------+ RFC2260: stable state Primary link is used ISP-BR-A ISP-BR-B | . . | | \.......................+ . | | Secondary link . . | | +......................../ | | . . | | . . | | . . | | . . | +---|--.----------------------.---|--+ | E-BR-A E-BR-B | | | | | +------------------------------------+ RFC2260: unstable state Link to ISP-A is down, secondary link is used Reachability is guaranteed ISP-BR-A ISP-BR-B . . | | . \.......................+ | | . Secondary link . | | . +------------------------/ | . | . | . | . | . | . | . | . | +---.--|----------------------.---|--+ | E-BR-A E-BR-B | | | | | +------------------------------------+ RFC2260: IPv6 extensions - Interaction with router renumbering o Deprecate ISP prefix with link trouble, by advertising small preferred lifetime - Address assignment issue o Problem does not change at all - Scalability in very large site o Do not try to make a full-mesh configuration with ISPs - Too much de-route kills you, solve problems locally Comment: 2260 applies for failure of link to ISP. Can this also be applied to failure in ISP (partitioned). No, this depends on ISP having reachability. Question if this has been tested yet. Not currently, but plan to do it in the future. SMPL - - Deliver traffic across link, during link failure (same goal) - With extra routing announcement to adjacent ISP-B o Friendly with worldwide IPv6 aggregation policy o Need extra routing entry in ISP-B - Single address assignment to end host (from ISP-A) - Solves ISP link failure, no others o Reachability will be improved o No specific "policy" implemented - Needs ISP coordination, of course SMPL: setup Get address from ISP-A only ISP-A and ISP-B needs to be "directly peered" ISP-B announces routes for Pref-A, to ISP-A only (ISP A) (ISP B) | ISP-BR-A --------------------- ISP-BR-B | | |Primary link | | | | | +---|-----------------------------|--+ | E-BR-A E-BR-B | | | | Pref-A | +------------------------------------+ SMPL: extensions - Interaction with router renumbering o Deprecate ISP prefix with link trouble, by advertising \ o small preferred lifetime o Can be used with SMPL as well, if you monitor link status \ carefully Discussion: Does this handle ISP failure. 2260 vs SMPL - Solves similar problem o ISP link failure - SMPL assumes single address assignment - SMPL needs direct peering between ISP-A and ISP-B o Does it hold for many cases? - 2260 needs "secondary link" Discussion about tunneling and native. Relationship to path MTU discovery. SMPL can have multiple prefixes but requires symmetric peering. SMPL is good solution when there are multiple routers in edge to site. Discussion on how to move forward. Deering suggested that these are complementary and both should go forward. We might need to have some sort of comparison and/or applicability statement. Both are useful. Big difference is if ISPs can directly peer or if they are separate and must tunnel. Problem w/ "clever exit router" approach - May not not reflect policy of the end node o 2260 and SMPL only improves reachability, nothing more o Combination with RR may help site behavior in unstable state - May need ISP/site coordination o 2260: route metric o SMPL: non-aggregated route announcement to ISP-B - BGP hack needs AS# o 2260 can be implemented with RIPng Point made that this approach (unlike the current IPv4 practice) is not limited by the number of AS numbers. Conclusion - "Clever exit router" helps "Clever end node" - We need both of them - Policy? o Needs knowledge about global topology o Can't be implemented without global coordination Multihoming with Router Renumbering / G. Tsirtsis ------------------------------------------------- Multihome with RR Only Deprecate address prefix associated with a failed link, to cause other link to be used itojun: handles outgoing new sessions, but not incoming ones (need to update DNS, or something) RFC2260/itojun review of this proposal problem: new connections may use prefix of failed link, and incur tunnel overhead -- can be helped by router renumbering, so new, outbound sessions use working link's prefix Issues - After how much time does it make sense to do RR? - Destination address selection may make you use deprecated prefix o Propagate in DNS(play with TTLs)? o Existing/cached entries will not change - Security concerns with Pref. Lifetime = 0 Ingress Filtering Problem explanation of ingress filtering issues Nordmark: there is an RFC 2267 on ingress filtering; thinks it contains warning that it only applies to constrained topologies; it does not contain any words about multihoming. RFC2260/itojun variation tunnel from the router attached to failed link becomes tunnel entry point (tunnel goes to other router inside site), to avoid ingress filtering problems. DNS Games / F. Dupont --------------------- - expiration dates can't go backward ex: at noon, TTL = 6 hours at 2pm, TTL = 2 minutes -- this doesn't work - short TTLs can increase DNS traffic too much proposed hack in BIND in order to artificially raise low TTLs to something like 2 hours - dynamic updates don't work so well - implementation issues - IXFR is broken - not secure + A6 resource records add an indirection at the right place itojun: what will be effect of A6 records on number of messages required to resolve a name? (no answer) discussion about A6 operational concerns -- need to get real experience to understand envelope of reasonable use IPv6 Site Renumbering / B. Hinden --------------------------------- Background - Site Renumbering has become important IPv6 topic o Some thought that ISP's should be able to renumber sites very frequently - Site renumbering is useful to allow o Changing ISP's o Maintain route aggregation in Internet Core What Makes Sense - Renumbering under the control and cooperation of the Site administration - Initiated by the Site o Site incurs the cost and most of the effort o Must be consistent w/ site's organizational objectives - Planned Activity o Requires long lead time and overlapping service o Time frame in Weeks to Months What Doesn't - Site Renumbering initiated by ISP o Without cooperation of Site o Without incentive to Site - Very Frequent Site Renumbering o Days, Hours, Minutes, … - Internet Wide Renumbering o Change prefixes of many sites at the same time - Renumbering Active Sessions Ipv6 Renumbering Tools - Multiple prefixes per Node o Node Multihoming - Autoconfiguration - New Prefixes learned from Routers - Control of prefix preference - Router Renumbering Protocol - A6 DNS Structure - Link, Site, and Global Scope Addresses - Literal Address unlikely to be used as frequently as IPv4 What Is Not Covered - Where Address are Manually Configured o Tunnel configurations o Firewall rule sets o IPSEC Policies o QOS Rules o Static Routes o DNS Servers o IPv6-IPv4 NAT o Other? - Where Addresses are Learned o Active Sessions o DNS Caches How To Renumber A Site - Time 0 o Contract w/ new ISP for Service o Get new IPv6 prefix from ISP o Establish peering w/ ISP - Time 1 o Add New Prefix to Address Related Configuration o Tunnels, FW rule sets, IPSEC, ... o Add new Static Routes o Verify Routing and Forwarding w/ new Prefix How To Renumber A Site - Time 2 o Use Router Renumbering to o Add New Prefix o New Prefix lower preference than old o Routers Advertise new Prefixes w/ Preference o Update Site DNS o Add new Prefix to A6 Records - Time 3 o Use Router Renumbering to o Increase preference of new prefix o Deprecate old prefix How To Renumber A Site - Time 4 o Verify site using new Prefix - Time 5 o Give notice to old ISP to terminate contract - Time 6 o Use Router Renumbering to o Remove old Prefix - Time 7 o Stop peering w/ old ISP Next Steps - Move Router Renumbering to Proposed Standard - Write document describing state of IPv6 renumbering and scenarios - Implement and get operational experience Comments: Add to list of other renumbering problems: IBGP config software license servers Kerberos (IP addresses encrypted inside certificates?) Perhaps add a step in which both new and old prefixes are "preferred" Discussion about term "deprecated" being a poor choice -- ought to be "not preferred"?) Include garbage collection step to clean up old addresses from manually configured stuff Meeting Network Configuration / Itojun Hagino --------------------------------------------- Network Configuration - 4 prefixes advertised 3ffe:501:0:180f::/64 2001:200:0:180f::/64 3ffe:8020:1:ffff::/64 3ffe:1801:0:1000::/64 - IPv4 world via TCP relay translator NTT IIJ WIDE others | | | | | | | | ===+=======+=====+========+==== NSPIXP6 ||| 384K bridge ||| 128K ||| meeting room NOC | =+=======+=====+===== =======+===== IPv4 | | | | | | | | NTT IIJ WIDE-----------------------+ | | | =+=======+=====+===== Meeting room user segment | | | your end node Some Stats - 20+ IPv6 nodes in user segment - 1627 translated TCP connection until Sep 30 14:55 o 878 http, 846 SSL, 88 pop3, 46 telnet, 32 ssh, 16 smtp, 5 ftp o Translation prefix:3ffe:501:0:18aa::/64 o 3ffe:501:0:18aa::x.y.z.u gets translated to x.y.z.u o DNS server side hack will automatically enable it - (stats from wandel) - (stats for videocast) Demonstration of local based network analysis tools Topics / Issues - SRC/DST selection, default router selection o Latter seems more important in this config - No "clever exit router" o They share the same outgoing link! - On link determination o Disable RA from faulty router o Route to DNS server becomes suboptimal - DNS needed IPV5 (root servers) - WIDE router panicing on September 28 o Tiny bug in KAME code Friday / 1 October 1999 ----------------------- Plug & Play Architecture / S. Deering ------------------------------------- Plug and Play is (supposed to be) a Major Feature of IPv6 - reduces IP support/maintenance costs for enterprises - essential for areas of IP growth: o hand held, mobile devices (PDAs, cell phones,...) o home networks o vehicles o appliances o ... How are we doing - stateless (and DHCP-based) addr config and neighbor discovery are key, and work well - mobile is close to dine (has IPSEC issues) - dynamic DNS updates? (many updates) - server/service discovery? - how does it all fit together? - ongoing discussion of ipngwg charter/future My reasons for bringing this up - discussion on mailing list after Oslo IETF - concern that questions I raised in Grenoble interim meeting are not so well answered - zeroconf working getting started, will depend on work from other WGs - ongoing discussions of IPng wg charter/future What constitutes "plugging in" - starting up an IPv6 module with interface(s) to one or more (non-loopback) links - enabling an additional interface on a running IPv6 module (incl. configuring a tunnel) - connecting an enabled interface to a (new) link (incl. entering range of new wireless link) - learning new addresses(es) for existing interfaces (either multihoming or mobility) - manually configuring new addresses (incl. "virtual home address") - ... Different Plugging-In Scenarios will require different host behavior - First time on new (or initial) "home subnet" o get forward and reverse DNS entries installed o store new home address - Subsequent times on current network o verify DNS entries? o (note that stateless autoconfig: is stateless for the network, not necessarily for the host) - plugging into additional subnet (multihoming) o get forward and reverse DNS entries installed - subsequent time on additional subnets(s) o verify DNS entries? - plugging into a "foreign" subnet (mobility) o do mobile IP bindings , etc. - plugging into a foreign subnet as "client only" o no DNS or mobile IP actions - discarding (deciding never to plug in again o discard DNS entries Questions - How to recognize these different scenarios? o some mix of automatic and manual mechanisms? - Do different types of devices need too behave differently? o light switches vs. cell phones - what, if any, work has been or is being done to specify the required behaviors? - what, if any, work should the IPng WG do? Discussion: Most of the complexity comes from mobile IP support. Simpler for non-mobile nodes. Need for automatic way to learn DNS server address. Nordmark: role of zeroconf w.g. is to set requirements. Who develops protocols is not clear at this time. Good to make them aware of these requirements. What happens when you reconnect and prefixes have changed. Needs to work without DNS servers. Very small environments will have DNS servers. Suggestion to do draft as input for the zeroconf w.g. Deering could give presentation to w.g. Discussion about role of developing new mechanisms vs. charter of zeroconf w.g. Can the development of new mechanisms continue in this area, or does it need to wait until the zero conf w.g. finish requirements and survey of mechanisms. Not clear what can be standardized now. Discussion about how much router Autoconfiguration is needed. Would be nice for simple environments if routers could be like L2 switches. Just plug them in and they work. Routers and autoconfig: Some please the routers need to be manually configured. Home routers do not need this same level of control and wish to be automatically configured. Home device wants to be a router that knows how to be automatically configured. ACTIONS: 1) Feed back this information to zero configuration w.g. 2) Chairs welcome drafts and idea in this area. API Issues / E. Nordmark ------------------------ Scope and multihoming API Issues - basic applications - scope zone - Scope zone aware applications - Ability specify more detail or override - What a complete API could look like o For interfaces, links, and sites Scope - Zone unaware applications - sin6_ scope_ id handles interface and site zones o Could presumably handle link scope zones as well o Can't use getipnodebyname - must use getaddrinfo o Can't use literal addresses - must use names o Details of how getaddrinfo determines scope_ id is TBD - Can send multicast to non-global groups o Assuming getaddrinfo is used!!! - Can not join non-global scope groups o No scope_ id in IPV6_ JOIN_ GROUP Discussion about need to be able to specify zone (when necessary). Nordmark thought this could be done inside of the API. Discussion about how to specify scope for multicast. Scope - Zone aware applications - Applications which want to control the scope zone being used - Can use sin6_ scope_ id for link scope o Using if_ nametoindex() family of functions and interface names (e. g., "le0") - No name space and corresponding functions for other scopes - Can not join a group on a site or a link o Can only specify an interface when joining the group Specifying more detail or overriding - An scope-zone aware application might o specify a scope (e. g. at the site level) o in addition specify a finer granularity concept (e. g. at the link/ interface level) o For instance, send to A in site X and use interface "le0 - (where le0 is in site X) - Allow or not allow "override"? o For instance, send to A in site X and use interface "le0 - (where le0 is NOT in site X) Elements of a complete API (I) - For each scope of interest! - A character string "user friendly" name space o Are the names local to a node (like "le0" for ifs)? o MZAP names? (UTF-8 encoded with language tags) o DNS names - useful when A6 is used to give names to sites and links? o What administrative overhead is reasonable? - A local identifier space for the sin6_ scope_ id o Visible in SNMP MIBs like the ifindex? Discussion about how to specify name, character set, language, multi-lingual, etc. How to pick up Elements of a complete API (II) - Functions to determine the mapping between the name and id and also discover the available names o Like if_ nametoindex(), if_ indextoname(), and if_ nameindex() - The ability to pass the scope_ id in all places where addresses are used o IPV6_ JOIN/ LEAVE_ GROUP is an example where this is missing (the only case?) Elements of a complete API (III) - Do we also need the ability for more detailed specifications? (in the advanced API?) o Complex since there are potentially multiple levels o For instance, site-local address where sin6_ scope_ id specifies site - desire to specify link, interface, or link and interface - The convention that multicast addresses have well-defined FQDNs and applications use these to lookup addresses (where the address comes with an attached scope_ id) Strawman proposal for site scope (I) - Use FQDN syntax for names - Add option to router advertisements for name o With "scope level" so that option can be used for other scopes in the future - Add functions to map between names and ids o site_ nametoindex(), site_ indextoname(), site_ nameindex() - New socket options for joining/ leaving groups o with a sockaddr_ in6 (i. e. a scope_ id) (and an ifindex?) Strawman proposal for site scope (II) - New socket option for specifying multicast transmit "interface" o "scope level" (e. g., "site local") o scope_ id - Logically extend IPV6_ PKTINFO (as separate socket option?) to specify site id o IPV6_ SCOPEINFO with scope level and scope id o Allows one level of finer granularity Strawman proposal for link scope (I) - Claim: In all places where the API uses interface ids it should really use link ids o Applications do not care which interface is used to send/ receive on a given link - Cost of adding separate name space and id space for link is significant o Additional administrative cost for maintaining name space o And all applications which use ifindex in the API would need to be modified to use the link index and name Strawman proposal for link scope (II) - Redefine semantics of ifindex in the API to mean "the link to which the interface is attached" o For example, if hme3 (ifindex 7) and le1 (ifindex 3) are attached to the same link the protocol stack would interpret ifindex 7 and 3 as "aliases" for the link. - Issue: will MZAP (assuming it will be deployed) already provide a name space for links? Next Steps? ACTIONS: Find an author who can take on writing extended API document. A Proposal of format for IPv6 scoped addresses / Tatuya Jinmei -------------------------------------------------------------- Problem - An IPv6 scoped address does not provide sufficient information for a scope boundary o "ping fe80::1" would confuse the ping program if you have two links - some identifier of the link should be provided to the program - same kind of problem arising site-local addresses o It's hard to resue the address by "cut and paste" Solutions so far - Specify the scope ID as a command line option or something o e.g. "ping -L link1 fe80::1" - need extra code for each application - you can't always use a same option for this purpose - Introduce a "default" scope id of the system o Not an complete solution, you should still specify the ID when using a scope other than the default Proposed Solution - Introduce a new format for scoped addresses o o Example: fe80::1-link1 scoped_address - "fe80::1" delimiter = '-' scope_id="link1" - Extend a library function that translates a hostname to a numeric address o takes a literal address with the extended format o returns a numberid address structure that contains the scope ID o e.g., getaddrinfo - An application can ust use the extended library function o no extension per application is necessary o only for internal use - does not affect other nodes Discussion.... Implementation - KAME's getaddrinof supports the extended format o takes an extended format as a hostname o sets the according scope ID to the sin6_socpe_id field o "@" as the delimiter o Currently for link-local addresses only o interface name as link ID - getnameinfo was also extended o takes sockaddr{} o returns a literal address w/ the extension [example slide] Issues - What is the desired delimiter o do we have to standardize a "desired" one? "@" would be confusing in a mail address - naming issue o An interface name doesn't necessarily specify a link o "link1" is too abstract for users o appropriate name to specify a site? o should the name be unique in the scope? - Can / should we apply a same kind of approach for multicast addresses? - Can't be applied for scoped addresses without any hints (e.g., ftp PROT command) - What if an application doesn't use getaddrinfo()? Discussion on how to use, aliases for link names, and user interface issues. Do we want a different way to refer to name that are local. ACTION: Speaker will write internet draft. ---------------------------------------------------------------- Meeting Adjourned ----------------------------------------------------------------