Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ipngwg / ipngwg-interim-97feb.txt < prev next >

Wrap

Text File | 1997-04-22 | 30KB | 809 lines

IPng Working Group February 27 & 28, 1997 Palo Alto, CA USA Bob Hinden, Steve Deering Co-Chairs Meeting hosted by Allyn Romanow / Sun Microsystems, Inc. Many thinks to Allyn and Sun for this service to the IETF. The minutes were taken by Bob Hinden. ---------------------------------------------------------------------- ---------------------------------------------------------------------- Agenda ------- Thursday Introduction Review Agenda 8+8 Overview Detailed Review Uniqueness of ESD's DNS forward lookups DNS reverse lookups DNS Structure TCP/UDP Connection Identification Effects on Applications Rewriting of RG (inbound, outbound) Lunch Continuation of Detailed Review Map RG into current Internet Rehoming Site Multihoming Site Rehoming Multihomed Site Rehoming Small Provider Multihoming Small Provider Rehoming Multihomed Small Provider Summary of Discussions Friday Review Remaining Agenda Review impact on existing specifications Base IPv6 Specification Addressing Architecture Provider Based Addressing Documents Neighbor Discovery Address Autoconfiguration IPoverFoo ICMP Lunch New Documents which Need to be Written GSE Specification ESD Guidelines RG Allocation Impact on Implementations Summary and Conclusions Review of Agenda ---------------- Discussion about purpose of meeting and outcome of meeting. Possible outcomes: 1) Working group will not adopt GSE proposal. 2) Working group will adopt proposal. 3) Working group leaning toward adoption, but there important missing pieces that must be specified before the working group can make final the decision What problems is this solving? Suggestion was made to generate list of pro's and con's Problems being Solved / Mike O'Dell ----------------------------------- Goals and Non-Goals Goals: Thinks biggest problem in internet is complexity of routing computation in the backbones (where there are no default routes). Specifically, the cost of BGP computations increases as internet grows and policy issues become more complex. Thinks computation grow is exponential. Issue is that from a routing perspective the backbone is relatively flat. Why is this better than current provider based design? Current provider based topology schemes rely on renumbering sites to improve route computation. He thinks the aggregation model for provider based addressing has potential for catastrophic collapse. What could happen is that a few very large sites will refuse to renumber (i.e., lawyers go to court), and that will effectively stop everyone from renumbering. CIDR has worked well, but will not continue into the future. GSE deals with this problem by keeping changes resulting from renumbering the Internet local to edge of site, and keeps changes from propagating into the site. Internal routing infrastructure is isolated from external changes. Proposal allows backbone routing topology to change independently of sites without having to get the sites involved in. Advantage is allows backbone renumbering to happen independently from site renumbering. Allows Multihoming without increasing size of backbone routing. This is important because more and more sites are becoming Multihomed. Also helps second tier providers to change their first tier providers without forcing their customers to renumber (and potentially losing their customers). This is a very important benefit. Comment by Masataka Ohta: Doesn't think completely solves multihoming, but is a good first step. Non Goals: Does not solve mobility problem. Does not keep TCP connections alive during renumbering. It would be nice to have TCP connections survive loss of one connection when multihomed. Uniqueness of ESD's -------------------- 6Byte IEEE Mac's are proper subset of 8byte IEEE-1394 (firewire) addresses. Are they unique enough? Dimitry Haskin said he doesn't like using MAC addresses for ESD's. He would like something which has same properties of current IP address. Discussion about how most sites will use MAC, while still allowing sites to use something else if desired. Jim Bound thinks it is unique enough. ESD should be eight bytes long. Discussion about this. Thomas Narten: What are the consequences if there is a collision? Easy to detect on a link, but hard to detect globally. Steve Deering suggested that it is a relatively low probability event. We could later build in additional mechanism to help deal with this. Are IEEE1394 addresses compatible with SMDS addresses? Not an issue, SMDS addresses are E.164. Erik Nordmark: Think they are unique enough. Hinden: Thinks MAC address will be unique enough. He mentioned that MAC only addressing has been used successfully in large bridged networks and in large IPX networks. Also, IPX networks are mostly PC which is the area where there has been the most concern about duplicate MAC address. Bound: Do we have a consensus on uniqueness? Questions about systems (such as Sun's) which only have one MAC per Node? Long discussion. Group concluded that IEEE Mac addresses are unique enough to serve as globally unique ESD's. Does ESD need to have structuring? ---------------------------------- Masataka Ohta: Thought they should have structure for security. Discussion about this point, concluding that structure was not necessary for the purpose. Jim Bound: This all requires changes to DNS. Everyone agreed. He does not think there is a need for structure in an ESD. Assumption that to do reverse mapping is more difficult if there is not some structure in ESD. Discussion of this point. Discussion evolved into what are requirements for reverse mappings of ESD's. Alternative suggestion was made for ICMP "Who Are You" with ICMP "I Am XXX" message returning DNS name to perform this reverse mapping function. We will need manual defined ESD space, but this should be the exception. Most nodes will not need to use. Discussion about Adding Routing Goop Records to the DNS ------------------------------------------------------- Proposing to add "site names" to DNS. Would correspond to routing group for site. Could reverse lookup RG to "site name". "Site name" is not the same as DNS suffix. Important to only do connection identification using only ESD, not RG+ESD. This will allow future development of secure RG redirect later to improve transport behavior when RG changes. Assumption that site renumbering was relatively infrequent, not a frequent "real time" event. Discussion about use of RG as identifier for site and effects on firewalls. There will not be inverse lookups of IPv6 addresses! It will be replaced by ICMP "Who Are You" message. Matt Crawford raised issue about rate limiting "Who Are You" messages. He is concerned if senders don't cache answers. This could create a heavy load of "Who Are You" message. An alternative is to have the DNS servers send the "Who Are You" message when the receive a reverse mapping request. This seems to be a good idea. Rough consensus of the group is that ESD's do not need to have structure. Dimitry Haskin pointed out that for links which do not have MAC such as PPP serial links we can no longer auto-configure these links. ESD's for these links will have to be manually assigned. This is about the same as IPv4 operation today, but not as good as what the current IPv6 over PPP specification provides. Is this an acceptable limitation? Discussion about use of random numbers as ESD tokens. Are they unique enough, etc. Not much agreement on using random numbers as ESD tokens. Mike O'Dell Presentation on Multihoming ------------------------------------- Provider Provider 1 2 +----+ +----+ | | | | | | | | |PBR | |PBR | +--x-+ +-x--+ | | RG1| | RG2 | | +--x-----x--+ | SBR SBR | | | | Site | +-----------+ If RG1 link fails, then Provider PBR tunnels traffic which would have been sent to the site via RG1 and sends it to the Provider 2 via RG2. Requires that both PBR in site 1 & 2, and SBR's understand that tunnel has been created. If TCP saves RG when SYN packet is received for connection, and never switches to RG received in subsequent packets, it can protect against it's connections being hijacked. Long discussion, even more complicated pictures and scenarios. Hinden asked question of how this was different/better from what can be done with current IPv6 specifications. Not clear what the win is here for multihoming. Erik Nordmark made observation that if node remembers all of the RG's returned from the original DNS lookup, then it would be OK for it to switch to one of the returned RG's if packet started arriving from a different one. Rebecca Nitzen talked about how in this scheme it will be very easy to load share multihomed site. Traffic in both directions will follow the same route. The only thing necessary to do is divide the primary default between the ISP connections. Might also be possible to return DNS replies for the site to divide the load by replying with the appropriate RG based on where the requester is. TCP/UDP Connection Identification --------------------------------- Pseudo header checksum always use ESD. Do we require all unicast to work the same way? Yes. OK for provider addresses which been autoconfigured. Important to require all addressing plans to have same characteristic. How about multicast addresses? Include an ESD? Discussion about what to do when node starts receiving packets with new routing goop. When node does not have any other information, node should drop packet. If node thinks the new routing goop is valid (perhaps by having received it in original DNS lookup) then it can reply and start sending to new Routing Goop. Need to look at what happens if routing goop is corrupted? This needs analysis to access the impact. Long discussion about if some of the RG could be included in the checksum. Allison proposed having the host include it's RG in checksum. Not clear how source node would get RG. Makes rewriting RG on in bound traffic impossible (?). This could be viewed as a hybrid proposal. Mike O'Dell suggested that TCP should not bind to a particular RG for remote side until three way handshake is completed. General comment made that it is important that this proposal not change TCP protocol. No TCPng!!!!!! Long discussion about what happens if RG is corrupted. Worst case is when first SYN packet is corrupted because connection will never be established. Erik Nordmark asked would implementing this architecture make it harder to make changes to TCP later in the future? What is the effect of hiding RG from the host? Matt Crawford proposed that we continue to rewrite RG, do not include RG in pseudo checksum, non-established TCP treat packets with different RG as different connections, for any UDP or TCP in established state pass all packets to application, connected socket for any transport do not update outgoing RG address. Long discussion about connection identification, checksums, what happens when RG changes, etc. Jim Bound stated that renumbering while important was it was not the top of the list of what his customers wanted. --------------------------------------------------------------------------- Friday --------------------------------------------------------------------------- Introduction to meeting. Today will continue detailed review of proposal. Start with DNS issues. Continue to work through the list: Uniqueness of ESD's DNS forward lookups DNS reverse lookups DNS structure (effect on caching, performance) TCP/UDP Connection Identification Effects on Applications Rewriting of RG (inbound, outbound) Effect on V6 mobility, multicast, anycast DNS Forward lookups ------------------- What if site is multihomed, does requester get multiple DNS entries? Two-Faced DNS Solution: Remote DNS are sort of part of local universe, so they need to know site RG and provide appropriate answer. Jim Bound: Thinks the split between RG records and AAA will work. Suggested list of topics to discuss on DNS: - Boot strapping DNS delegation records - How do replies get fabricated - What new record Types - Two faced DNS - Dynamic Update to RG (for renumbering) Boot strapping DNS delegation records ------------------------------------- Need to have hard coded address of DNS servers. For example to get to foo.sun.com, .com server needs to have address of ns.sun.com. This is way IPv4 works today. Discussion focus on making DNS servers have addresses which are not renumbered. This should work as long as there are not too many DNS servers. Need to update DNS servers when RG changes. Likewise this is essentially the same as IPv4 and a general IPv6 issue not specific to this proposal. When site renumbers, it must change it's DNS servers. When an ISP renumbers it must make it transparent to sites. O'Dell suggested that if DNS servers get RG info from routers this could be made easier. Problem could be made less severe if the top level name servers had addresses which were not renumbered. We could support some amount of non-renumbered addresses for important servers. Important to identify where in DNS there are hardwired addresses. Thomas Narten: This is a generic point about renumbering. Not specific to this proposal. What new record Types ------------------------------ RG Record AAA (Deering suggested calling it "aAA") How do replies get fabricated ------------------------------ Matt Thomas suggested that AAA record be split into Subnet + ESD record (AA) Matt Crawford agreed this would be a good idea. We do need a site record for RG? General conclusion that splitting the DNS records was a good idea even if proposal not adopted in whole. Two Faced DNS ------------- Server has to have information to know what kind of reply to send. If RG of source address from request is same as RG which was to be in the reply it should substitute site local RG. Matt Crawford described a problem where DNS queries are forwarded between servers, RG will be lost as request goes between sites and backbone and this will not be work. General conclusion that these topics needs an owner to describe how all of this works. Dynamic Update to RG (for renumbering) -------------------------------------- Decided this was a future need and was not required now for this proposal. Effects on Applications ----------------------- - Prohibition of Storing non-refreshed non-ESD addresses. Not specific to this proposal. General renumbering (and transition to IPv6) issue. - Use only ESD for peer identification (not address) - Avoid carrying addresses in payload - Flow identification. Probably need to only use ESD instead of whole address. - Effect on reassembly - All packet identification needs to use ESD's - Effect on routing header? If RH is to be replied then BR would have to fix up RG inside of RH. This happens on both first exit BR and final BR. Not clear if it is important to make source routes RH reversible. Border router (which may not be one of the SR hops) will have to know to look inside of RH to rewrite appropriate RG's. Might be better to embed DNS names in packets because they are global and can be looked up. Comment that overall this adds complexity for programmers. They would need to have good understand of RG, subnet, ESD's, addresses, and how they interact.. Prior to this proposal they only need to understand addresses. - Effects on tunnels. If tunnel crosses site boundary, end points must perform BR functions. Which router does rewriting? Long discussion on how this works. End point of tunnel needs to be able to rewrite destination RG w/ site prefix. Host-Host secure IPSEC tunnels require hosts to be able to recognize that the RG (actually it's own) is one of it's interface and accept the packet. Anytime you tunnel it in effect requires all tunnel end points to be border routers. They need to be able to rewrite RG on exit and entry. Renumbering breaks all configured tunnels. - Addresses in MIB's and Address in SNMP Traps. Makes it harder for agents. - ICMP error messages. Returned packet has packet with error. Need to only look at ESD to match error reply. Steve Deering's fortune cookies from lunch ------------------------------------------ "A thrilling time is in your immediate future" "Avert misunderstanding by calm, poise, and balance" "He who hurries cannot walk with dignity" "If your desires are not extravagant they will be granted" "Simplicity and clarity should be your theme in dress" "Strong and bitter words indicate a weak cause" "The best prophet of the future is the past" "The laws sometimes sleep, but never die" "Time is precious, but truth is more precious than time" "What's vice today may be virtue tomorrow" "Wise men learn more from fools, than fools from the wise" "You have a quiet and unobtrusive nature" "You will be recognized and honored as a community leader" TCP Connection Identification / Matt Crawford & Allison Mankin -------------------------------------------------------------- If checksum doesn't cover RG, and we want to accept packets from different RG's, there are a few problems. The most serious are avoided by sending only to one RG in any given connection. Replying to any RG that is heard from opens TCP to serious security and reliability holes. Proposed Rules for Case of RG-Rewriting, RGs not Checksummed: 1. Accept any source RG on incoming packets and deliver to application. Only use ESD for this. 2. For Active TCP "Open" and all UDP: Application specifies destination RG. Send only to the application's requested RG, but receive from any. 3. For Passive TCP Open: send only to the first RG that arrives during the opening handshake. Based on 3., if source RG is corrupted, the connection will never open. The passive open side will ack the good SYNs to the corrupt return RG of its peer. The alternatives to this (if we can't have the sender able to checksum its local address's RG) require opening up the TCP handshake logic into three or so special cases, and they also may still have security problems. Result: if there is a bit error in the source RG received in TCP LISTEN state, the rescue can only come from a higher layer than TCP. Weighed likelihood of this corruption against the risks of choosing from among several RGs that arrive during the handshake, and decided the best thing to do is recommend that source RGs be known to senders, so they can be included in the checksum. Corrupted of destination RG is not a problem. Packet will be misdelivered and discarded, retransmission will get to correct site, connection will open. Because of never switching RG, multihomed connection will be broken if RG changes. Also applies to rehoming. The approach does help when there are two different RG exit paths and routing changes which causes a different RG to start being used in the middle of the connection. Nordmark noted that this makes connection identification easier than existing IPv6 because only need to look at ESD instead of list of possible addresses. Also suggested that it might be worse because sender doesn't know anything changed. Future transports could be developed which allow complete separation of RG and ESD which had other connection identifications mechanisms, authentication, etc. Conclusions ----------- Deering asked group for their overall impression of what people think now Mike O'Dell: He draws several conclusions: Thinks it is unreasonable to move forward with the current proposal. Thinks there are a number of things which are worth pursing. There are a bunch of pieces which we think we should do. This has really pushed our thinking about what it means to renumber. Most of hard questions dealt with impact of renumbering. He is perfecting willing to not go forward with his as main proposal. Thinks we should see what we can extract and move forward. Steve Deering: Can we still get some of these advantages with current scheme? Mike O'Dell: Long term requirement is to control aggregation topology independent of getting sites to participate. That was the fundamental goal. This proposal does not enable this in toto. Still other things which need to be done. Questions is what pieces should we take? Jim Bound: Likes some of the parts of GSE, does not like some of current parts of provider based addressing. There are lots of pieces here which are improvements. Main thing didn't like was the renumbering approach. Dimitry Haskin: Agree with Mike that at this point proposal is not deployable. Too much risk involved. When meeting started he thought it was feasible, but now thinks it is not possible. Should we continue working on proposal as research project? Not practical for deployment now. Could have a transition mechanism. Lixia Zhang: Thinks fundamental problem is renumbering. DNS still needs work. Charlie Perkins: Agree this is too much definition to be done in time for IPv6 deployment. Likes separation of address into ESD and locator. Might make other problems easier in the future. John Stewart: Advantage he sees of independent of rewriting packets is aggressive aggregation. This proposal does it by rewriting of addressing. Wondering if there is a middle ground with provider based addressing but changing with [???] Take best pieces of each approach. There are lots of subtle transport issues that we may not understand yet. Mike O'Dell: Believes that large structure proposal used is a much better model for aggregation than provider based addressing. Margaret Forsythe: Thinks the addressing part is inherently useful. Could have something like this, but do not need to take full advantage of this now. New transport protocols could take advantage of protocol. Allison Mankin: A lot of the attractions are ones which are ones which we have been striving for in the IPng area. Thinks would be a shame if we didn't pursue this. Thinks we should pursue some parts of GSE in transitional way. Erik Nordmark: Thinks it would be useful to take advantage of ESD's. We could use for connection identification. Bob Hinden: Suggested that it is good to require an ESD in all addresses. This may have advantages for multihoming (sites and nodes) and permit new transport protocols to be developed which take full advantage. Jim Bound: Will put out draft why renumbering is not important. Location and identification is not going to work for a long time. John Stewart: Ramification of large routing tables along with increase with things like multihoming. Reasons why we now need to aggregate from leaf up. Single homed sites do not need any information about routing (just default), they don't much want any pain to renumber. We should put the work of renumbering in places which need flexibility. Multihomed sites. Alex Conta: Thinks current provider based addressing scheme is good. Reason we thought that provider based scheme was thing to do, because we thought there would be problems with separate identification and location. We now have a better view of the costs of renumbering. We should document this. Cost to site, provider, etc. Could also conclude the multihoming problem is not solved by node-id and locators. GSE did seem to provide better form of aggregation. We should continue looking for better forms of aggregation. Conclusions we draw today are the high costs for using GSE to improve aggregation. Dimitry Haskin: Does not like requirement to make ESD in all addresses. He is opposed to this. Thinks price of administration is too high. Matt Thomas: Like the ICMP "Who Are You" message and putting it in DNS server. Dan Harrington: Renumbering is hard, we now know better. Need support to support multihoming without breaking aggregation. Matt Crawford: Hope that by 3:30pm we will list topics to pursue. For now have the sense of the room but thinks that it is something that is worth going forward with but don't have time to fully pursue. Should do a few small things now to allow options later. Possibilities: - PCB Lookup Rules - Pseudo checksum rules - "Who Are You" you message - 8 byte node id - Two faced DNS ? O'Dell added: - Split records in DNS - Revisit provider based addressing model. Problematic. - Minimal address is to split Steve Deering: Keep term "Routing Goop"!!! Erik Nordmark: Argument to make two faced DNS is to isolate site from changes would be to return site local addresses in site to site local communication. Reduces the risk of a failure of renumbering from disrupting site communication. Allison Mankin: Should remove "registry" field from provider based addressing. We can work to improve this. Steve Deering: TCP depends on it's weak security by depending on address providing both location and identification. TCPng could do different things which allow separation. Jim Bound: Seconds large structure internet draft. Provider based document was compromise. Thinks we can do better. Agrees about TCP weak security. Bob Hinden: Suggested that if connection identification is limited to ESD and pseudo-checksum covers full addresses (essential providing packet integrity) that it would be easier to support multihomed sites and nodes. TCP would then accept packet sent from any interface of multihomed node and/or received on any interface, but avoids the problems relating to corrupted source addresses. Masataka Ohta: Hope that many things can be made to work with GSE. Would like pursue as an informational RFC. Thomas Narten: Will need a two faced DNS if we are using site local addresses. Allison Mankin: There should be work done to develop a new transport which could just work with ESD's. Next Steps ---------- Steve Deering broke out parts of proposal to see what parts the working group could move forward. Node ID: Change from 6 bytes to 8 bytes. This would break provider based addressing documents. Discussion about keeping 6byte MAC or expanding to allow 8 bytes. Deering polled group. Most people thought we should change to make room for 8byte MAC. Brief discussion and poll to put structure in ESD's to allow lookup. Strong consensus to not add structure to ESD's. Group initially agreed that low order 8 bytes would be required to be globally unique. This will make it harder for links without built in MAC addresses. More discussion. Now less clear that there is a consensus on making ESD globally unique. Conclusion is to review the ESD issue at the Memphis IETF. We need more data before we can make a final decision. RG Structure: General agreement to rewrite provider based addressing specifications. We can make a number of improvements. PCB look up rules: Document now, but decision depends on making globally unique ID's. Also applies to flow identification, fragment identification, etc. Checksum: Don't change pseudo checksum algorithm. Will continue to include full IPv6 source and destination addresses. Two faced DNS is useful for site local address. Work on how to use site local addresses for intra-site communication. Summarized into the following table: Legend: X = do not adopt Y = adopt * = needs more study X Rewriting by routers X Name for Sites & Mapping to/from RG * ESD's Y RG structure * PCB Lookup rules X Pseudo checksum rules Y 8byte node ID Y Two faced DNS for site local Y Resolve DNS via ICMP "Who Are You" Y DNS response synthesis * Auto-Injection of prefixes into sites Y Inter-provider partition healing protocol(s) * Use only site-local prefixes for intra-site communication * How much of address is AH * Flow identification change * SA Ident change Actions Items for Memphis ------------------------- 1. Minutes for this meeting, and meeting report / Bob Hinden 2. "WhoAreYou" ICMP Message / Matt Crawford 3. Modify Link Name Draft / Dan Harrington 4. Synthesized AAAA Replies / Jim Bound , Mike O'Dell 5. Revised Provider Based Addressing and Addr Architecture / Mike O'Dell and Bob Hinden 6. Unique ID's (ESD's) Assignment, Mike O'Dell, Allison Mankin, Matt Thomas 7. Experimental Addresses Rewrite: Bob Hinden 8. IPoverEthernet/FDDI : Matt Crawford 9. IPoverPPP: Dimitry Haskin 10. Lessons from meeting: Thomas Narten, John Stewart, Allison Mankin, Lixia Zhang, Matt Crawford Work We Think Other People Should Do ------------------------------------ 1. Non-corrosive multihoming of sites (partition homing) 2. Auto-aggregation of public topology 3. Auto-aggregation of site topology 4. Auto prefix dissemination in site 5. Auto prefix acquisition by sites 6. DNS vs. Renumbering Meeting End ----------- Next meeting will be at the Memphis IETF. Sessions are schedule for Thursday and Friday. --------------------------------------------------------------------- ---------------------------------------------------------------------