IPv6 Working Group (ipv6) Agenda IETF 56, San Francisco CHAIRS: Bob Hinden Margaret Wasserman Minutes notes taken: Bob Fink (March 17, 2003) Christian Huitema (March 20, 2003) AGENDA: Introduction and Agenda Bashing -- Bob Hinden (5 min) Updated Charter -- Bob Hinden (10 min) Working Group Action Plan -- Margaret Wasserman (15 min) Prefix Delegation: - Prefix Delegation Requirements -- Shin Miyakawa (10 min) - DHCP Option for Prefix Delegation -- Ole Troan (5 min) - Moving forward on Proxy RA Approach -- Bob Hinden (5 min) IPv6 MIBs -- Margaret Wasserman (10 min) IPv6 Addressing Architecture Appeal: - Overview of IAB Response -- Leslie Daigle (20 min) - Working Group Response to Appeal Process -- Margaret Wasserman (10 min) Access Control Prefix RA Option -- Steve Bellovin (10 min) IPv6 Node Requirements, Open Issues -- John Loughney (30 min) Analysis of IPv6 Anycast -- Itojun Hagino (10 min) DHCPv6 DNS Resolver Configuration Option -- Ralph Droms (10 min) IPv6 over Fibre Channel Review Request -- Claudio DeSanti (5 min) IPv6 Addressing Architecture - Review of IAB Recommendations & Next Steps -- Margaret Wasserman (30 min) Node-Requirements follow up (10 min) Site-Local Addressing -- Bob Hinden and Margaret Wasserman (60 min) IPv6 Socket API for source address selection -- Erik Nordmark (10 min) ================================================= First Session: Monday, March 17, 2003, 1930-2200 ================================================= Introduction and Agenda Bashing -- Bob Hinden --------------------------------------------- Bob opened the meeting and reviewed the agenda. There were no changes to the published agenda. Updated Charter -- Bob Hinden ----------------------------- As discussed in Atlanta, except: DNS Discovery removed from the charter ADs instructed chairs to remove work item (an explanation sent to working group mailing list) topic will be discussed at DNSOP session Goal for end of year is to either re-charter or close wg. Primary wg responsibilities are: Completing work on the IPv6 working group documents Reviewing and updating IPv6 specifications based on implementation and deployment experience, and advancing them on the standardization track as appropriate. Hinden presented a list of urgent work items and a list of current work. Action Plan -- Margaret Wasserman --------------------------------- Margaret Wasserman presented document status and related actions. Bob Hinden thanked the authors of flow label draft. Itojun asked what the status of the anycast analysis draft is. Margaret said not clear if it was part of the work of the wg yet. Need to decide. Prefix Delegation: Prefix Delegation Requirements -- Shin Miyakawa ------------------------------------------------------------------ Shin Miyakawa presented his work on prefix delegation requirements. Shin noted that he appreciated the Michel Py and Pekka Savola comments. Shin outlined them to see if there was agreement with going ahead with the draft with Pekka's changes or not. Michel Py said he was willing to go with the current text without changes for his comments. Margaret asked what the wg thought of the changes. Brian Haberman said layer two work out of scope. On lifetime he thinks it should cascade down. The wg agreed. Margaret asked how many people thought PPP be included, or should this layer two stuff be removed. Christian thinks there is a difference between a serial link and a shared link. So don't have to say PPP, but must note the difference. Dave Thaler thinks PPP and CHAP stuff should go away. Needs to be a mechanism that works on a shared link. Also prioritization should be removed. Margaret asked if PPP and CHAP should be removed: unanimous to remove. Margaret asked if the Layer 2 auth should be removed: unanimous generic layer 2 auth stuff to stay. Sentiment expressed there be a requirement for a solution that works on a shared link. Jordi Palet stated that it needs a shared link solution. Hesham Soliman asked why this was more complex? Shin said PPoE employed as it is easy to identify customer equipment. Francis Dupont agreed with PPoE, but need a shared link solution. Margaret asked if we need a prefix delegation solution on shared link: consensus was that we need a solution that does. Shin will modify the draft and get out for further review as soon as possible. DHCP Option for Prefix Delegation -- Ole Troan ---------------------------------------------- Ole presented his DHCP option for prefix delegation. He felt that it was ready for wg last call. There were no comments. Moving forward on Proxy RA Approach -- Bob Hinden ------------------------------------------------- Bob talked on Proxy RA solution. If progress, we need to have volunteers to work on draft to extract appropriate text from the multilink subnet stuff. Dave Thaler volunteered to work on this, but needs comments from folks that it meets requirements. Ole thinks it my be useful but that it doesn't meet all requirements. Christian happy that Dave will do the job, and wants to excise the proxy RA stuff from the multilink subnet draft, but there are problems with home users stacking routers at home. So there is a need for multilink subnet solution. Dave expressed concern as to what people think RA proxy means as there are different thoughts on this. Need input/comments to help. No further comment. Presumably Dave Thaler will proceed to work on this solution. IPv6 MIBs: Forwarding, TCP & UDP MIBs Open Issues -- Margaret Wasserman ----------------------------------------------------------------------- Margaret presented a status report on various IPv6 MIB efforts. There were few folk that have read this or that have any comments. Margaret extolled folk to review and help forwarding these drafts. Dave Thaler noted that he had read the TCP MIB and believes it is ready for wg last call. Generally there was agreement that these MIBs are needed, but very few have read them and have an opinion on technical content. Margaret noted that the UDP MIB needs an editor. Someone asked if the OPS area have reviewed them. Margaret said they have not and probably won't until forwarded. Margaret may mention these to the OPS area at their meeting this week. Dave Thaler outlined problem with the forwarding MIB. There is a problem with interpretation of TOS byte. Brian Carpenter said he would review and help resolve this. IP MIB Open Issues -- Shawn Routhier ------------------------------------ There was no presentation. Incorporated in previous talk. IPv6 Addressing Architecture Appeal ----------------------------------- Overview of IAB Response -- Leslie Daigle ----------------------------------------- Leslie presented a clarification of the IAB response to the Robert Elz appeal in the IPv6 Addressing Architecture as there was some apparent confusion of what the IAB was saying. It does not say this draft should not be forwarded. Nor does it give directive to the wg. It does say this draft is not clear enough for a DS, and clarity needed to ensure interoperable implementations. Not challenging the IPv6 architecture. A future version may go to DS. Some things are recommended to be fixed. Not treading on IESG space. All further discussion to be in wg. There were no comments. Working Group Response to Appeal Process -- Margaret Wasserman -------------------------------------------------------------- Margaret noted what further discussion on this topic would happen on Thursday, specifically on how to respond to the comments, and then on what to do with the draft. Margaret asked wg folk to review the available information in preparation for Thursday's meeting. There were no comments. Access Control Prefix RA Option -- Steve Bellovin ------------------------------------------------- http://www.ietf.org/internet-drafts/draft-bellovin-ipv6-accessprefix-01.txt Steve presented on his access control prefix RA option draft. Christian said the conclusion slide that this is not a security solution is why Brian Zill's solution wanted to keep the mechanism simple. Keith Moore asked if we want to build in network topology and addressing coincidence. He felt there were similar problem with this approach as with site-local, which Keith does not like. Perry Metzger said this proposal demonstrated we should get rid of site-local. Dave Thaler noted access control mechanism has similar problem to Brian's choice. Steve agreed. Tony Hain noticed this is not really different than site-local. Margaret disagreed and noted that there could be different prefixes with Steve's approach. Pekka Savola felt there are differences in Steve's approach and site-local. Dave Thaler agreed with Tony. Would prefer a change to the node rules. Christian had similar comments. Margaret noted that this is part of the greater site-local discussion to take place later in the week (when Steve won't be available). There was no further discussion as this will be revisited at Thursday's meeting. IPv6 Node Requirements, Open Issues -- John Loughney ---------------------------------------------------- John presented his open issues with his current version of IPv6 node requirements. --- Hesham Soliman asked about the DHCP support rewording re SHOULD or MAY. Doesn't consider it to be useful. Doesn't need to be a SHOULD. Dave Thaler asked Ralph Droms if there is still an interest in DHCP on this? Jim Bound felt stateful configuration is a MUST. M bit must be set. Node can ignore. Customers that have stateful environments will not go to stateless environments. Christian disagreed. No question that we must support stateless. Market will take care of this. MAY is enough. Rob Austein said that John should separate question on this. Bob Hinden, speaking personally, noted that he would not want to see people have to implement functionality they don't need. Perry Metzger felt that it doesn't matter which we choose as we are being precise about how to be imprecise. John wanted to know how to resolve. Bob Hinden asked who wanted to keep the existing text (says MAY). In looking at the text to see if this was the way to frame the question John decided it was best to send a proposed change to the list so it could be discussed Thursday. --- On privacy extensions for addr conf, Alain Durand said there are reverse path dns issues when a random address may not resolve. Keith said it is more general, and need an API for this. Pekka asked if this is actually used. John said probably good to have the code, but use can cause a problem so should be aware of that. If per node basis things will break it should be done on a per API basis. Seemed to be consensus to go with John's suggested text change. --- Mobile IP - Routers SHOULD support the requirements set for all IPv6 routers. Several comments that this doesn't sound right. Should be changed to routers SHOULD support mobile IP requirements. --- Security - still questions. What level of security to document. Gave example. Steve Belovin noted trying to get rid of DES. Thus should remove the MUST. John will ask someone in security to review this. Margaret noted that she liked the idea of separating security into a separate draft. Steve Belovin wanted to take this off line. John wants to hold off on the security section. He will edit the other items and ask if it is ready for last call, barring the way security is reviewed and/or changed. Bob Hinden wants to defer the security issue as IPSEC isn't useful in every device, e.g., a device that might want SSL or SSH for security, and doesn't want IPSEC. So need to think about this broadly, thus should go ahead without security for now to make progress. Jim Bound said that if we want to revisit MUST that it is an IPSEC job. Where do we stop if we do this. IPSEC is a MUST historically and IP6 is the front line of defense for security by using IPSEC to secure the IP level. Thomas concerned about a node requirements doc with no security. Need a lot of help from security group to have a serious discussion on this. John likes having a reference to a doc with current best current security practices for IPSEC. Keith doesn't like having IPSEC as it isn't really a solution. Jim Bound said we could make a more specific by node type document rather than this general approach. To alter the existing MUST/SHOULD with this doc is bad idea as it would be in conflict. Jim said he could do a review on MUSTS to see if anything should be changed. Keith felt that this specification should be for generic programmable nodes. Maybe other specific, i.e., fixed function, devices should not be covered by this. Margaret disagreed and noted that were many many of these types of devices to consider. Bob felt that the intro should note the scope re Keith's comment. John will pose issues about stateful addresses and M & O bits, as well as more discussion on security. Agreed that the wg needs to decide how to handle security. Analysis of IPv6 Anycast -- Itojun Hagino ----------------------------------------- Itojun presented a short status report on his analysis of IPv6 anycast. He has received some comments from Erik and he will generate a new version but doesn't know if it should require a last call. Margaret wanted to redo the w.g. last call this new draft as it has been a long time since it was last reviewed. =================================================== Second Session: Thursday, March 20, 2003, 0900-1130 =================================================== Bob Hinden presents the agenda. 60 minutes are left for the discussion of the site local addressing issue. Noted that original agenda items for site-local are changed. Now there will be a singe presentation jointly presented by both chairs. DHCPv6 DNS Resolver Configuration Option -- Ralph Droms ------------------------------------------------------- Ralph Droms presents the state of DNS configuration in DHCPv6. There are two DHCP options: DNS server and Domain search list. The DNS server option has been adopted by the DHCP group, after some searching of the proper option name, which turns out to be "recursive name server"; another issue was whether to carry IPv4 addresses as well as IPv6, which was resolved by only carrying IPv6 addresses. The Domain search list option is exactly copied from the similar DHCPv4 option. The two options have passed DHCP WG last call. DHCPv6 is now a proposed standard, in the RFC editor queue; implementations have been tested at TAHI connecthaton. Work is ongoing on a stateless DHCPv6 subset, which allows for a lightweight implementation. The stateless DHCPv6 draft needs review from implementers, to make sure that it is written in a "developer friendly" way. Dave Thaler asks what the resolution is for the search path option, and possible differences between a value returned over IPv6 and another received over IPv4? Ralph answers that this will be left to the host. Pekka Savola observes that there is the same issue with the DNS server list; but for Ralph this is not a really issue. Rob Austein: the choice of server is who you ask, but all are supposed to return the same answer; the search string is what you ask, which changes the answer. Alain Durand retorts that change in the calling order of servers can affect the response delays, so some precision is important to avoid operational problems. In any case, says Ralph, this is not really a DHCPv6 issue: DHC specifies a configuration mechanism; choosing the order of responses is a management option. The drafts will be updated to include a short discussion of this point. For Keith Moore, the search list mechanism is broken anyhow, and should not be used at all, so fixing it is irrelevant. Alain Durand points out the analogy with the choice of routers by hosts, which is indeed left to the host. IPv6 over Fibre Channel Review Request -- Claudio DeSanti --------------------------------------------------------- Claudio Desanti presents the work on IPv6 over Fiber Channel. FC is a Storage Area Network. There is an IPv4 specification already, but we need an IPv6 specification. IPv4 over FC defines its own ARP mechanism, but for IPv6 they want to leverage Neighbor Discovery. FC channel nodes have their own 64 bit identifier, but routing is based on volatile 24 bits labels; an upper layer protocol manages a sequence of frames. Work in ANSI T11 committee has defined how to map FC name identifiers into EUI 64 format. The draft defines how to generate a node identifier, how to map link local Unicast and Multicast, and how to map the channel and exchange management. The question to the IPv6 WG is what to do with the spec: either an "IPv6 over FOO" work item in the IPv6 WG, or an individual submission progressing to PS after IPv6 WG review. Margaret points out that IPv6 over FOO is not in our charter anymore, so the second option will have to be discussed with the AD. Pekka Savola observes that the draft is very hard to read by someone not versed in FC. Thomas Narten agrees with Margaret that the only role of the IPv6 WG should only be tasked to provide a review. Greg Carlson, as Thomas, mentions that the responsibility of the work should be in the TLC working group. IPv6 Addressing Architecture- Review of IAB Recommendations & Next Steps -- Margaret Wasserman ------------------------------------------------------------------------ Margaret Wasserman presents the IPv6 WG response to the IAB recommendations on Robert Elz appeal. The IAB response at several sections, one presenting their conclusion, and another presenting their recommendations. The recommendations are informative in nature, but they cannot be ignored. The questions to answer are: is 64 bit a hard boundary; what is the exact meaning of global scope, and what to do with the U bit. Margaret engages in a review of each of these issues. Is 64 bit a hard boundary? It is quite clear that all formats except those with a 000 bit prefix have a hard 64 bit boundary. Review of the text found a reference to CIDR that might be construed to envisage aggregation of prefixes longer than 64 bits; this will have to be fixed. Pekka Savola does not need it needs clarification; rather, we should revise the whole concept, because otherwise some implementations will stop prefix matching at 64 bits, which is in his mind broken. Thomas Narten restates the IAB requirement: was there an already made architecture decision on the 64 bits split , or is it left for further discussion; for example, should applications be required to enable routing on a /124? Margaret mentions that the only discussion is for the 0::/3 prefix. Bob Hinden mentions that the application only have to do CIDR on the first 64 bits. The current specification of the 0::/3 prefix is longest match to arbitrary length. We agree that the section is not clear, and will have to be edited. Erik Nordmark mentions that the spirit of the document is clear, the implementation requirement is not, and there is still discussion in the operator community, e.g. allow /127 bit prefix on PPP links. Jim Bound mentions that it is a well known fact that we should not restrict prefix match to 64 bits. Thomas asks whether this is actually the consensus of the group? Michel Py finds that the text is clear, so asks what exactly is confusing about it? Margaret answers that if the IAB cannot understand it there is an issue. Fred Templin mentions that there may be some need in the future to match more bits than 64. Hashim mentions that there is a prefix length in the RA options; how does the 64 decision affect RA processing? Keith Moore advocates that we do not repeat the class-full address assignment mistake of IPv4; he suggests that we keep a requirement for routers to match arbitrary length tables. The issue with global scope was a confusion between global scope and global uniqueness; it assumes that any address with the U bit set is globally unique. The proposal is to refer to the U bit as "universal", and to reserve use of the adjective "global" for global scope addresses. Erik Nordmark mentions that there is no requirement to consider the U bit in routing processing. Fred Templin agrees with Margaret. Keith Moore mentions that we should explicitly warn applications to make no assumption about the structure of the address. The interoperability requirements of the U bit were unclear; the appeal pointed out that we did not show two implementations that tested the U bit in an interoperable way. For Margaret, this is really a documentation issue: implementations are not required to allocate any meaning to the U bit and test its uniqueness; the U bit is only used as a way to construct host identifiers. Bob Hinden believes that changing the text to not require any test will remove the interoperability issue. Keith Moore goes one further: applications should not assume that an identifier with the U bit set is globally unique. This is pretty clear already, says Margaret. Obviously, there is wide consensus in the room. The IAB had 5 recommendations: publish the document at PS, which has been approved; update the document to include clear and concise interoperability requirement using RFC 2026 and 2119 language, which is agreed with the WG with two reservations regarding the U bit (see above) and the 2119 language; update the requirement for 64 bit identifiers, which we discussed previously; and that we revise the ND and auto-configuration specification to include the knowledge of the 64 bit boundary, which will be considered when we update these document at a later date. Margaret would like to thank the IAB for reviewing our document and helping us make it stronger. IPv6 Node Requirements, Follow Up -- John Loughney -------------------------------------------------- John Loughney provides a quick update on the nodes requirement draft. The big open issue was the state of the "stateful address auto-configuration" requirement. The agreement on the mailing list is to have this rated as "MAY support", for which John proposes a text; there is also a requirement that if the WG eventually chooses to say that application "SHOULD" support, there should be a strong qualifier authorizing implementations to opt out. A show of hands shows 59 hands up for preferring MAY, 21 for SHOULD; the chairs believe that this constitute rough consensus in the room, but we need to verify the decision on the mailing list. Another update on the requirement draft is the state of requirement of support for DHCPv6: must support if use for stateful address autoconfiguration; should support for other configuration; may support if no stateful or other configuration is needed. Christian Huitema asks for clarification, whether the "other configuration" really means "stateless DHCP". Thomas Narten asks whether we are making the explicit decision that DHCPv6 is "THE" stateful address configuration mechanism? John concludes that this specific paragraph needs further discussion on the mailing list. Ralph asks for clarification of the handling of the M bit and the O bit. Site-Local Usage Discussion -- Margaret Wasserman & Bob Hinden -------------------------------------------------------------- Margaret Wasserman opens the IPv6 site local discussion. Presentation done in round robin fashion by both chairs. Goals for discussion: analyze options, reach consensus on approach. It is important for WG to make a decision (don't want endless debate) chairs will support whatever achieves consensus. There are several choices: get rid of site local altogether; limit their use to disconnected sites; create an exclusion requirement so nodes cannot configure both site local and global addresses; a prohibition of nodes belonging to several sites; and full usage. There are documentation for the "limited", "moderate" and "full" options; the "exclusive" model is undocumented; there is WG consensus to not support the "full" option, and as a consequence the progress of the current scoped address architecture draft is frozen. The limited model implies only using site locals in disconnected sites, and requires renumbering when the site becomes connected. Margaret's slide mention usage behind an IPv6 NAT; Keith Moore objects that this is a license for NAT; Margaret agrees that the limited model could imply the use of IPv6-IPv6 NAT. The exclusive model mentions that nodes will never be configured with both site local and global addresses. This simplifies address selection a lot, but requires some form of host configuration. The exclusivity limits the potential for leakage. Brian Carpenter asks what happens when a site is oscillating between connected and disconnected; Bob Hinden answers that in the exclusive state, the globally addresses nodes will simply become unreachable when the site is disconnected. Alain Durand asks for clarification. Thomas suggests that this would become a router advertisement restriction, but this becomes hard to enforce when there are several routers on a link. Margaret restates the intention: even if hosts receive advertisements for both type of prefixes, a host configuration bit will govern which type of address gets configured. Alain Durand observes that if there is no enforcement mechanism, this exclusion requirement is totally useless. Jim Chang states something that the note taker could not understand. Michel Py suggests that we should make global and site local exclusive on a given subnet. Thomas wonders whether there are open issues in this proposal, and this is hard to assess in the absence of a formal document. Keith Moore wonders how that applies to hosts with multiple interfaces, which seems unwieldy. Marc Blanchet asks whether the requirement applies to routers? Answer: Yes. Erik Nordmark wonders whether a single link would have a site local printer and another global scope host; the answer is yes. Pekka Savola mentions that if nodes also mention routers, then we should say so explicitly, as it has wide consequences on routing. The moderate model allows for site local addresses if they are explicitly configured. Nodes can have both type of address. A site border router will be in exactly one site, with some interfaces in no site at all. We will have to revise the address selection algorithms to not prefer site local, and revise a couple of other documents as well. The benefit of the limited model is that it allows addressing for disconnected sites. Christian Huitema pointed out that Margaret's references to IPv6<->IPv6 NAT were divisive and unnecessary, and said that Margaret was trying to link the limited model to IPv6 NAT. Margaret said that the limited model could be used behind IPv6 NAT or NAT-PT, but did not require the use of either type of NAT. Margaret agreed that the topic of IPv6 NAT was divisive and agreed that, in retrospect, it would have been better not to include it on the slides. For Margaret, the exclusive model has the additional benefit that it allows stable addressing for local nodes. Bernard Thuy observes that this discussion never took multicast into account; what is the impact? Brian Carpenter points out that the limited model has a benefit not carried in the other model, i.e. simplifies the handling of addresses by applications. Alain Durand challenges the stated benefit of the exclusive model: nodes that have global addresses will have to oscillate between the two types of addresses. The moderate model has additional benefits: it allows stable addressing, and easy communication. The issue list included: IP layer address leaking; IP address selection issues; DNS address leaking; address leaking by other layers; handling of boundaries in routing protocols; forwarding table issues; and mobile IP issues. IP layer address leaking is addressed by all proposal. Limited and exclusive do not require changes to address selection rules; moderate requires switching the order of preference. Exclusive and moderate need enforcement mechanism to avoid leaking in the DNS. Limited does not have a leakage problem in applications, since there is no connectivity; exclusive probably eliminates the issue as well; moderate requires upper layers to incorporate some address selection rules. All proposals eliminate the routing protocol issues, as well as the forwarding table issues, as no proposal allows a router to be in more than one site at the same time. The limited proposal eliminates the possibility to support mobility out of the site; exclusive and moderate requires mobile nodes to use global addresses. As a summary, limited eliminates most problems, but it also eliminates all the benefits. Exclusive does not have the issue of requiring handling of scoped addresses in applications. Bob think it important that the working group gets consensus on the issue. Margaret tries to impress the need that we have to reach a decision today: choose between the 4 options, or possibly excise the site locals from the scope address document, and just consider global and site locals. Pekka Savola believes that the exclusive option as presented is broken; it is only usable in limited cases, e.g. placing a few local nodes in an otherwise global link; the only reason is to restrict access to nodes, which can be node by the less intrusive access prefix option. Alain Durand believes that the analysis of address leakage is wrong: we have an implementation of that model with RFC 1918 today, and addresses do leak; Margaret believes that this is due to implementation mistakes, which raises some heckles; Alain believes that the only way to avoid the issue is not use site locals at all. Keith Moore believes that IPv6 will not be useful as long as we don't support site local; reserving the site local addresses to disconnected sites will not work, as proven by the RFC 1918 experience. Matt Mathis wants to reinforce Keith's point: looking work at the early ways of the ROAD WG, having applications consider the scope of addresses was already consider a bad idea then, and is still a bad idea now; we should not require applications to know anything about the scope of addresses. Brian Haberman believes that any analysis of the issues is bound to be incomplete, and would support an option to just excise the site local addresses from the scoped address architecture; as an editor of the scoped address document, Brian proposes to just do that. Fred Templin believes that site locals will benefit intermittently connected sites. Michel Py supports the exclusive model as a way to move forward, if it is enforced on the entire link. Erik is concerned that we don't have enough information to decide yet, because we don't have consensus on requirements; for example, the requirement to renumber without breaking connections triggers lots of complexity for mobile nodes; the requirement of a security boundaries can be solved in other ways; disconnected sites should be able to use global addresses in most cases; and we don't have to make it easy to implement NATs. Christian Huitema suggests that the exclusive model is an illusion; it is not documented yet, and the devil is in the details; it is also not enforceable, as nodes who want both addresses just have to pretend that they have two link local addresses. Hesham Soliman agrees with Christian that the exclusive model is a charade. Rob Austein agrees with Erik Nordmark and Christian Huitema; thanks the chair for pointing out that all solutions solve the IP issue, and that only the limited model solves the application issue. Leif Johansson points out the very strong requirement that applications don't have to care with address scope. Dino Farinacci points out that a disconnected site can in fact use any prefix, his disconnected site uses 2001::/16; he does not need that we need site local addressing. Mohsen Feci wonders whether we really need site local addresses; IPv6 addresses are not rare; not having site local addresses to solve the problem. Kurtis Lindqvist points out that all proposal force the network to maintain some state; that the site local costs us more than it brings. Someone points out that the main benefit of IPv6 is global addresses; we can just use global addresses. Samita adds her voice to the idea of elimination of site local. Christian Huitema will prefer eliminating site local over adopting the "limited" option. Thomas Narten wonders whether the consensus in the room is for shifting towards eliminating site local. Bob and Margaret have a private conversation where they discuss how to proceed to measure w.g. consensus. Keith Moore would like to make an offer; observes that we cannot eliminate the site local, but that we should actively study alternatives for their various proposed use. He suggest that we write a document that deprecates the usage of site-local addresses and includes in that document ways of obtaining the features of site-local addresses using global IPv6 addresses. Marc Blanchet is afraid that if we forget about site local now, they will be invented back later. Dave Thaler mentions the zerouter BOF, which needs a recommendation for how to automatically configure a disconnected network. For Erik Nordmark, if we eliminate site local, we have to remove the currently existing code that handles FEC0::/10. Brian Carpenter comments that RFC 1597 was one of the worse end runs in the history of the IETF, and that interaction with NAT is clearly out of our control; however, he would prefer to deprecate these addresses. Fred Templin believes that we will still need a solution for intermittently disconnected sites; this problem should be addressed. Jim Bound points out that IPv4 NAT is a national security problem, and that an attempt to control them are misguided. Keith Moore repeats the requirement that applications should not be concerned with the scope of addresses. Margaret asks the question, do we want to deprecate site local addresses? There are 20 hands up for not deprecating, 102 hands up for deprecating; This is interpreted as rough consensus to deprecate site local addressing; this consensus will have to be verified on the mailing list. IPv6 Socket API for source address selection -- Erik Nordmark ------------------------------------------------------------- [No time for this talk] ------------------------------------------------------------------ ------------------------------------------------------------------ Meeting Adjourned ------------------------------------------------------------------ ------------------------------------------------------------------