Last Modifield: 06/25/2002
This charter focuses on completing the remaining work items and providing a home for IPv6 work that spans multiple IETF working groups. The working group is being renamed the IP Version 6 Working Group (IPv6) because it is a better description of the working group's focus.
The specific working group's ongoing responsibilities are as follows:
- Complete work from the original charter and follow-on work, as outlined below.
- Keep all IPv6 working group documents moving along publication / standardization track.
- Complete work from the original charter and follow-on work, as outlined below.
- Keep all IPv6 working group documents moving along publication / standardization track.
- Serve as a review board and body of competence and coordination for IPv6 architectural issues that span multiple IETF working groups.
- Provide a home for IPv6-related work that doesn't fit in an existing IETF working group and doesn't merit a working group of its own.
- Provide technical input to the IAB, IANA and Internet Address Registries with regard to IPv6 address allocation policies and procedures.
The list of the working group's current work items is as follows:
- Revise and advance to Draft Standard the IPv6 Address Architecture document [RFC 2373]
- Revise IPv6 Aggregatable Unicast Addresses [RFC 2374], removing the policy aspects that are considered RIR issues.
- Complete work on recommended address-selection algorithms
- Revise ICMPv6 spec [RFC 2463] (scope-exceeded err, no error to redirect, editorial)
- Revise Generic Tunneling spec [RFC 2473] (add bidirectional tunnels)
- Update Basic and Advanced API specs [RFC 2553, RFC 2292]
- Complete Scoped Address Architecture spec and any necessary revisions to other working group drafts required to properly implement support for IPv6 address scoping
- Work on host-based solutions to site-multihoming problems (in coordination with multi6)
- Complete work on local IPv6 networking as part of IPv6 plug-and-play (to be coordinated with other WGs as appropriate, e.g., dnsext, zeroconf, etc.)
- Document IPv6 renumbering model
- Complete the IPv6 Node Information Queries spec
- Revise and update the base IPv4/IPv6 MIBs and produce a new consistent set of MIBs that cover IPv4 and IPv6 together. RFCs to be looked at together: 2011, 2012, 2013, 2096, 2851, 2452, 2454, 2465, 2466 and possibly 3019.
New work items not listed above require the approval of the working group and Internet Area directors before they will be taken on by the working group.
The working group would welcome contributions on the following topics this is not an exhaustive list):
- Flow label standardization
- Solutions to other multihoming issues, beyond those specific to site-multihoming
- Integration of autoconfiguration, mobility, DNS, service discovery and other technologies to enhance IPv6 plug-and-play
- IPv6 dial-up issues relating to address assignment, use of Neighbor Discovery, etc. (not including AAA work)
- Specifications for IPv6 over additional media
- Host use of anycast; TCP use of anycast
- Support for multi-link subnets (single subnet spans multiple links)
- Scope-name discovery
- IPv6 protocol extensions to accommodate mobile wireless networks.
|JUL 01||Revise IPv6 Address Architecture and resubmit to IESG for Draft Standard|
|JUL 01||Revise IPv6 Aggregatable Unicast Addresses and submit for publication as an RFC.|
|JUL 01||Resubmit the IPv6 Node Information Queries spec|
|AUG 01||Compete Address Selection specification and submit for Proposed Standard|
|DEC 01||Update ICMP document and resubmit for Draft Standard|
|DEC 01||Complete DNS Discovery draft and submit for Proposed Standard|
|DEC 01||Update Generic Tunneling specification and resubmit for Proposed Standard|
|DEC 01||Complete updates to Basic and Advanced API specifications and submit for Informational|
|MAR 02||Complete Scoped Address Architecture and submit for Proposed Standard|
|MAY 02||Submit document describing IPv6 renumbering model for Informational.|
|RFC1885||PS||Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)|
|RFC1883||PS||Internet Protocol, Version 6 (IPv6) Specification|
|RFC1886||PS||DNS Extensions to support IP version 6|
|RFC1884||PS||IP Version 6 Addressing Architecture|
|RFC1887||I||An Architecture for IPv6 Unicast Address Allocation|
|RFC1897||E||IPv6 Testing Address Allocation|
|RFC1981||PS||Path MTU Discovery for IP version 6|
|RFC1970||PS||Neighbor Discovery for IP Version 6 (IPv6)|
|RFC1972||PS||A Method for the Transmission of IPv6 Packets over Ethernet Networks|
|RFC1888||E||OSI NSAPs and IPv6|
|RFC2019||PS||Transmission of IPv6 Packets Over FDDI|
|RFC2023||PS||IP Version 6 over PPP|
|RFC2073||PS||An IPv6 Provider-Based Unicast Address Format|
|RFC2133||I||Basic Socket Interface Extensions for IPv6|
|RFC2147||PS||TCP and UDP over IPv6 Jumbograms|
|RFC2292||I||Advanced Sockets API for IPv6|
|RFC2375||I||IPv6 Multicast Address Assignments|
|RFC2373||PS||IP Version 6 Addressing Architecture|
|RFC2374||PS||An IPv6 Aggregatable Global Unicast Address Format|
|RFC2464||PS||Transmission of IPv6 Packets over Ethernet Networks|
|RFC2462||DS||IPv6 Stateless Address Autoconfiguration|
|RFC2463||DS||Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification|
|RFC2461||DS||Neighbor Discovery for IP Version 6 (IPv6)|
|RFC2460||DS||Internet Protocol, Version 6 (IPv6) Specification|
|RFC2471||E||IPv6 Testing Address Allocation|
|RFC2450||I||Proposed TLA and NLA Assignment Rules|
|RFC2454||PS||IP Version 6 Management Information Base for the User Datagram Protocol|
|RFC2465||PS||Management Information Base for IP Version 6: Textual Conventions and General Group|
|RFC2452||PS||IP Version 6 Management Information Base for the Transmission Control Protocol|
|RFC2466||PS||Management Information Base for IP Version 6: ICMPv6 Group|
|RFC2470||PS||Transmission of IPv6 Packets over Token Ring Networks|
|RFC2467||PS||Transmission of IPv6 Packets over FDDI Networks|
|RFC2472||PS||IP Version 6 over PPP|
|RFC2473||PS||Generic Packet Tunneling in IPv6 Specification|
|RFC2497||PS||Transmission of IPv6 Packets over ARCnet Networks|
|RFC2507||PS||IP Header Compression|
|RFC2526||PS||Reserved IPv6 Subnet Anycast Addresses|
|RFC2529||PS||Transmission of IPv6 over IPv4 Domains without Explicit Tunnels|
|RFC2553||I||Basic Socket Interface Extensions for IPv6|
|RFC2710||PS||Multicast Listener Discovery (MLD) for IPv6|
|RFC2711||PS||IPv6 Router Alert Option|
|RFC2732||PS||Format for Literal IPv6 Addresses in URL's|
|RFC2874||PS||DNS Extensions to Support IPv6 Address Aggregation and Renumbering|
|RFC2894||PS||Router Renumbering for IPv6|
|RFC2928||I||Initial IPv6 Sub-TLA ID Assignments|
|RFC3041||PS||Privacy Extensions for Stateless Address Autoconfiguration in IPv6|
|RFC3019||PS||IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol|
|RFC3122||PS||Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification|
|RFC3178||I||IPv6 multihoming support at site exit routers|
|RFC3146||PS||Transmission of IPv6 Packets over IEEE 1394 Networks|
IPv6 Working Group Minutes Atlanta IETF November 18 & 22,2002 ------------------- Bob Hinden <firstname.lastname@example.org> Margaret Wasserman <email@example.com> Chairs Slides can be found at http://playground.sun.com/ipv6/minutes/ Agenda ------------------------------- Introduction and Agenda Bashing -- Bob Hinden (5 min) Document Status and Priorities -- Margaret Wasserman (5 min) Proposed Charter Update -- Margaret Wasserman (15 min) MIB Updates -- Margaret Wasserman (5 min) <draft-ietf-ipv6-rfc2011-update-01.txt> <draft-ietf-ipv6-rfc2012-update-01.txt> <draft-ietf-ipv6-rfc2013-update-00.txt> <draft-ietf-ipv6-rfc2096-update-02.txt> Prefix Delegation: Prefix Delegation Requirements -- Shin Miyakawa (15 min) <draft-ietf-ipv6-prefix-delegation-requirement-00.txt> DHCP Option for Prefix Delegation -- Ralph Droms (10 min) <draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt > Flow Label -- Jarno Rajahalme (20 min) <draft-ietf-ipv6-flow-label-03.txt> Node Requirements -- John Loughney (30 min) <draft-ietf-ipv6-node-requirements-02.txt> Site-Local Usage / Scoped Address Architecture -- Bob Hinden & TBD (1-1/2 hour) <draft-ietf-ipngwg-scoping-arch-04.txt> [Needs to be updated to indicate real speakers] DNS Resolver Autoconfiguration -- Alain Durand (10 min) <draft-ietf-ipv6-dns-discovery-07.txt> Issues with DHCPv6 -- Ralph Droms (10 min) <draft-droms-dhcpv6-issues-00.txt> IPv6 over Fibre Channel -- Claudio DeSanti (10 min) <draft-desanti-ipv6-over-fibre-channel-00.txt> Monday, November 18, 2002, 1930-2200 ------------------------------------ [Notes taken by Bob Hinden and Margaret Wasserman] Introduction and Agenda Bashing -- Bob Hinden --------------------------------------------- Bob Hinden reviewed agenda. No changes. Document Status and Priorities -- Margaret Wasserman ---------------------------------------------------- [Slides can be found at http://playground.sun.com/ipv6/minutes/ ] Proposed Charter Update -- Margaret Wasserman --------------------------------------------- [Slides can be found at http://playground.sun.com/ipv6/minutes/ ] This is a proposed charter. It has not been officially submitted to IESG yet. Opportunity for working group to comment. Urgent for Deployment Carpenter: Sympathetic to what try to do. Have heard comment, why is the IPv6 w.g. still meeting? Thinks this is an important message. Kempf: Relationship to ND and Mobile IP? What should be done with ND? Should this be done in Mobile IP w.g.? Is there interest in this in the w.g. Hinden: thinks IPv6 is responsible for this work and changes to ND should be discussed in IPv6 w.g. Narten: Mobile IPv6 document currently has changes to ND. Doesn't think changes are bad, but doesn't think changes are appropriate in Mobile IP. Important that this be done as part of ND, not in Mobile. Should be in IPv6 w.g. Durand: There is a proposal 8:8 a long time ago. Wishes the GSE document has been published. Would be useful for current discussion. Droms: Thinks Link Scoped IPv6 multicast not being completed. Has work that depends on this. Perkins: Talks about ND advertisements. Has had modifications to ND in MIPv6 that have been there for a long time. It is crucial that these modifications be done. Thinks MIP w.g. should be making these changes. Doesn't think this would keep the v6 w.g. from making updates to ND specification. .... Thinks it would be a mistake to not do this in MIP6 w.g. Bound: Is goal, conclude or hiatus. A: Conclude. Agree with Charlie P. that ND changes should stay in MIP6. Hesham: What does point-to-point link bullet means. Needs more clarification if this is updates to existing document or new documents. A: Probably both. Hesham: Multilink subnets? A: Not sure where this is going to be done. No current plan. Narten: If ML subnets is important, where will work be done, who is going to do it, etc. Needs problem statement. Itojun: Status of anycast? A: Still in IESG, doesn't need to be listed as a work item. XXX: What about IPv6 over different media? A: Not in charter, but proposals can be made. Thaler: ML Subnet. Is being discussed at zero router BOF tomorrow. Currently an IPv6 w.g. document. Thinks ML subnets covers RA proxy. This is close to being done if it is solving RA proxy. More expanded solution should be done elsewhere in IETF. Narten: "Flexible Method for Managing the Assignment of Bits of an IPv6" is almost done. Should be reviewed and submitted. Need to check with author. No real work. Should be finished. MIB Updates -- Margaret Wasserman --------------------------------- <draft-ietf-ipv6-rfc2011-update-01.txt> <draft-ietf-ipv6-rfc2012-update-01.txt> <draft-ietf-ipv6-rfc2013-update-00.txt> <draft-ietf-ipv6-rfc2096-update-02.txt> [Slides can be found at http://playground.sun.com/ipv6/minutes/ ] ACTION: Chairs to start working group last call on UDP MIB ACTION: Chairs to start working group last call on IP Forwarding MIB Prefix Delegation ----------------- Prefix Delegation Requirements -- Shin Miyakawa ------------------------------------------------ [Slides can be found at http://playground.sun.com/ipv6/minutes/ ] <draft-ietf-ipv6-prefix-delegation-requirement-00.txt> Nordmark: Are there any security requirements? A: Doesn't think it is too complex. Are there any security issues for other environments, such as cable modems. Might want to be able to turn on security in some environments (perhaps where there is more shared media). Dayley(sp?): This would be good for network mobility too. Thinks really need strong security for this mode. Will add security section. Should be ready for w.g. last call after new draft is published. DHCP Option for Prefix Delegation -- Ralph Droms ------------------------------------------------- <draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt > [Slides can be found at http://playground.sun.com/ipv6/minutes/ ] Wants to do last call end of the year in both IPv6 and DHC working groups. Interoperability testing by TAHI in January. Moore: Has a lot of issues with the notion of leases for addresses. Thinks ISP's shouldn't be able to take addresses away. Nordmark: Suggestion, might have default lifetimes in specification that are weeks or months. Could make lease the same a contract with ISP. Hain: Don't put operational policy in specification. Keith: Understands need to keep in separate specification, but would like to see a solution. Discussion between Moore and Droms...... Nordmark: It's not about mandating operational procedure, it is about making suggestions for people to consider. It is OK to say we think we expect these to be long lived. Moore: Important for applications to know about the expected lifetimes. Flow Label -- Jarno Rajahalme ----------------------------- [Slides can be found at http://playground.sun.com/ipv6/minutes/ ] <draft-ietf-ipv6-flow-label-03.txt> Will issue a new draft. Ready for IETF last call? Steve Blake: Doesn't think that a destination can assign a flow label. There will be conflicts that can't be resolved. This at least needs to be clarified in document. Could be a new application try to connect to this destination. [Last bullet, slide 5] Bob proposed a much simpler flow label document, based on the appendix from RFC 2460, but using the source, dest and flow label. Has a first cut of a much simpler document that he will send to the authors for consideration. Jarno -- Concern that a simple implementation that only cared about three values (no wildcards) might be too limited for some uses. Needs for wildcarding might result in storing more than one entry. Doesn't think that this WG should decide whether or not RSVP is useful and should be enabled -- current draft defines how RSVP would work with the flow label instead of the ports. Christian -- two comments. (1) SDP is not a signally protocol, can't achieve what is specified with SDP, because it only passes one address, not two. Can't have tuple of source/dest. Jarno -- With this model, we could just have "to this address, use this flow label", would wildcard the source. Christian -- not consistent with the rest of the model. Doesn't think that an IPv6 specification should make assertions about how the parameters should be used in other protocols. Thinks we should say: (1) flow=source, dest, flow id. By definition, something with the same flow id is the same flow. (2) the flow id has no structure, mathematical or otherwise. Brian -- co-author of the document and he does agree with it with these modifications. Painfully hacked out to cut through a minefield of ideas about how the flow label should be used. But, also agrees with Bob Hinden that we don't need this for the IPv6 flow label definition. Could be a page surrounded by I-D boiler plate. We might be able to get consensus on Bob's proposal, where we have failed to get consensus on this longer document. If we go to last call with this document, as ammended, we may just go into another round of non-consensus. So, his tendency is to support Bob's approach. Then, there is work to do after that, which is to develop use-cases. Jarno -- recalls a desire to add default usage with transport connections and media streams. Now in section 4. Sections 4 and 5 can be removed to get to what Bob proposed. If that is what is needed to get the basics through, then that's what needs to be done. Hesham -- agrees very much with Bob. The document is very wordy right now, could be said in two paragraphs. Should stay away from usage, just list semantics and nothing more. Alex Conta -- Thinks that Jarno's presentation does a disservice to the draft. The presentation is longer than the draft. Jarno did a lot of work to explain the issues, but that gives the impression that the draft is long and complex. Thinks that if you try to address the issues that this draft is a addressing, you can't make it shorter. Jarno spent two slides on the definition of the flow label, but it is only two paragraphs. Concern about counting number of pages. This is the third version of the draft, and we got here through several consensus stages. The work today is the result of suggestions, things said on the mailing list, including by Bob and Margaret. Trying to address all of those comments will get to the same result. The reason we are at this draft is that there were so many issues with the appendix. Doesn't know how taking that appendix and massaging it will achieve consensus. Christian -- How do we proceed with usage cases? It is a pitfall of this WG that we do what other groups should be doing. We should not be defining a usage case for how this will work with RSVP, etc. Choy(?): Several groups are working on definitions concerning flows. Wants this document to describe its objective. Jarno -- already have this definition in the document. Doesn't include layer 2. John Loughney: Thinks that the draft is not overly long. Could find a middle point between Bob's suggestion and the current draft. Could remove parts of the draft that specify what a flow label is, etc. and move them to an appendix. Brian Zill -- Approach should be to take out "excess stuff" and keep definition. Remove signalling-related stuff and try to make the document as simple as possible. James Kempf -- Thinks the draft is fine. Lots of requirements are based on some uses of the flow label. Not related to the flow lable, per se, but based on how other groups might use it. Could move them out into a separate document. Erik -- Two different things that we need to do: (1) specify semantics, and define what people are doing today, and (2) specify constraints for how people can use them. Document seems not to include what you can do today. Hard to extract from section 4 on constraints. Constraints are more focused on how to use it for something new, not something you can do today. Bob will circulate what he has put together, at least to the authors. Bob doesn't want to be an author himself. Node Requirements -- John Loughney ---------------------------------- <draft-ietf-ipv6-node-requirements-02.txt> [Slides can be found at http://playground.sun.com/ipv6/minutes/ ] Thomas: MAY on privacy extensions is too weak. Should be a SHOULD if you are the type of node to which it applies. Tony: Shouldn't mention clients servers, etc., as this is too operational. Christian: Agrees that we shouldn't talk about clients and servers, as they are not part of the architecture. Tony: If you want an address to be private, it can't be in the DNS. John L: If you have suggestions, send them to the mailing list. Pekka: Doesn't think that a detailed treatment of the use of privacy addresses should be in this document. Should be in next revision of the Privacy Addresses document. John L: This document shouldn't specify any new behaviour. Ed Maholic(?): Isn't "SHOULD if you are concerned about it" the same as MAY? Thomas: No. Itojun: Personally votes for MAY, in the interest of avoiding duplicates. Condition for need is defined in RFC 3041. Alain: Back to issue of 3041 addresses in the DNS. This is not the place to talk about this. Elwin Davies: Thinks that we need to say that some things must be implemented, but must also include a knob to turn them off. We did a lot of that in IPv4 requirements. Bob: Not clear if that type of language should go in here, or in an update to 3041. Brian: SL wording needs editorial work. John L: Agrees. Christian: On principle, the default address selection rules are the default when you don't know better. So, at best they could be a SHOULD. John L: Sounds reasonable. Rich: Most of the rules in the default address selection are SHOULDs, but some are MUSTs. John L: Should we worry about IPv4? Bob: Doesn't know why we'd care, except for possible transition mechanisms. Brian: First sentence reads like a joke, but it is a good one and we should leave it in. Some day, we may need to start an OGTrans WG (old-generation) when IPv4 becomes a legacy protocol. Bob: Margaret should talk to v6ops chairs about whetherv6ops should do a "transition requirements" document. John L: Question on MIBs. Are they a MUST or a SHOULD? Margaret: Suggested SHOULD if you have an SNMP agent. Brian: Disagrees with MUST support MIBs. Agrees that you would only want to do this if you have an SNMP agent. Bob: Do we want to define a minimal set of MIBs, or ignore this? Does v4 host requirements say anything about MIBs. Dave Thaler: Host requirements doesn't, router requirements does. Choy(?): Title is node requirements, but seems to mix in functional and operational requirements. John L: Doesn't include operational requirements, etc., just what must be supported. Choy: Disagrees, thinks that the document should define some functions, such as QoS. John L: QoS and functional requirements are far outside the scope of this document. An IPv6 can be anything from a super computer to a temperature gauge. Bob: Thinks we may want to list that you MUST not implement A6 records. John L: May be appropriate to list this in the appendix. Alain: Does not think MUST NOT is appropriate, as A6 is experimental. Erik: If we point to the AAAA document, should point out new draft. Brian: When 1122 was done, the BCP designation had not been invented. Would BCP be more convenient than standards track? Bob: Preference for BCP. Over time, we'll change what we consider that this is, rather than making it more and more firm. Thursday, November 21, 2002, 0900-1130 ====================================== [Notes taken by Sharon Chisholm. Thanks, Sharon.] AGENDA TAHI Test Introduction -- Hiroshi Miyata Site-Local Usage/Scoped Addressing (1-1/2 hours) Introduction: Bob Hinden (5 min) Rich Draves (15 min) Brian Haberman (15 min) Rob Austein (10 min) Bob Hinden (15 min) DNS Resolver Autoconf -- Alain Durand (10 min) Issues with DHCPv6 -- Ralph Droms (10 min) IPv6 over Fibre Channel -- Claudio DeSanti (10 min) -- TAHI Interoperability Test Event Hiroshi Miyata ================================ Jan 20-24 2003, Makuhari Chiba Japan Test info Conformance and interoperability http://www.tahi.org -- IPv6 site-local usage Bob Hinden ===================== Site-local status Address architecture defines format Address selection defines selection rules Work ongoing on Node requirements Scoped address architecture Issues in several areas - Site border router - Multi-site routers Site local in routing protocols? - Multi-site hosts - DNS - Applications Choices for IPv6 wg - Limited usage only used in disconnected sites no multi-site nodes - Moderate usage simple site-border router no multi-site host or router requirements two-faces/split DNS - Full usage require all nodes to be multi-site routing protocols aware of site boundaries multi-site DNS Moore: Let me just suggest we don't talk about compromises at this point. I object to the direction the chair is trying to steer the group in. Site-local addresses Richard Draves ==================== Why do we have site-locals? How do they add complexity? IMHO Scoped addresses (link-local & site-local) Good features Recommendations 1. Simultaneous use of site-local & global addresses is allowed 2. Multi-site host support is not required 3. Routers required to support two modes 4. We should document issues surrounding site-locals and their deployment What is a site? Administrative/ routing boundary Not geography Convex routing Paths between site-local source & destination stays within the site Architectural reasons Scoped addresses are natural expressions of network topology They are being retrofitted into ipv4 Disconnected networks Global prefix not always available Intermittently connected networks with unstable global prefix [Crowd response about the wide deployment of this stuff] Security-related uses - Simple access control out of the box - Defence in depth because multiple routers between attackers and victim will filter site locals Renumbering-related uses - Site-local connections preserved across renumbering events probably not so useful because renumbering relatively ... - Site-local addresses in configuration files etc do not have to changed when renumbering - For example, filters/ACLs based in site-locals do not change Network stack complexity - Meaning tcp/udp/ipv6 - Very little additional complexity - Couple hundred lines of code, mostly in.. Application complexity - Default address selection sufficient for many apps - Distributed apps that do referrals - Multi-sited hosts - getaddrinfo() returns site-locals w/ scope-id - Apps preserve scope-id info (use sockaddrs) DNS - Two-faced DNS only current solution - draft-ietf-opngwg-site-prefix-05 - Mark Andrews suggestion - Works with links-locals too Mobile ipv6 - Can MN use a site-local home address? - MIPv6 could support using site-local home address to communicate with Site-local correspondent back in home site while away from home - But not as currently specified --- Q - You made a suggestion that site local and link local are similar from routing perspective, but I don't think that is true .... A - Certainly in the general case that is true. Q - To add site-local only a few lines? A - That is a host implementation Q - How much routing protocol support do we have in your stack? A - Static routes. --- Routing and forwarding of site local address Brian Haberman ============================================ Target network 1 - Broken up in two sites with dmv between Target network 2 - Threw in another border to determine scaling issues Test platform - Original IPv6 stack - Software-based v6 router - RIPng Modifications - Zone id support in RIB/FIB - RIPng - Forwarding plane - Correct forwarding table lookup - Destination & source address checks Test scenario - Reachability tested with ping6 - Throughput tested with ftp - FreeBSD workstations dumped route tables and snooped route advertisements Observed results - From 10k feet, looks like VPN support - Differs with sharing the global prefix RIB/FIB - Performance hit in forwarding - Site specific FIB in hardware would help Random comments - This was routing/forwarding only - RIPng is fairly straightforward - Link-state will be more difficult - Site boundaries should not be arbitrary - IGP/EGP - OSPF area boundaries Random thoughts - Site-border routers can work - How often will a router have to support more than one or two sites? - Routing/forwarding is not the hardest part of site-local support - Not all routers would be multi-sited - Today's VPN boxes are a good model Q - Clarifying question. given that hardware stuff would be beneficial with a few sites, what is the impact of deploying this on existing networks? A - Today you would have to use an ACL (forwarding). You could have a route filter in BGP ... I've seen that done. Q - I'm wondering if the existing hardware will handle this? A - It will be hard to do because the routing protocol does not handle this Q - You said like vpn? A - You can consider a site like private network, with the site-local tables like VPN tables. But, share one global table. Q - Have we created scenarios where we have looked at the uses of site-local and link-local and looked at how to make them work? A - No, we have not taken that approach ... we have a scoped address architecture doc. Q - When a packet comes in on specific interface, how to look up? A - # of ways to choose what table you are in ... One way is to keep zone id and use it to choose a table. Another way is to associate a linked list of routing tables with zone id. Q - Same address on different interfaces? A - Zone id is the key. The problem of carrying route-ids in the routing protocol is that each router has its own idea of zone ids. <General discussion of what a zone ID is...> Margaret - take this offline with Brian Q - Just want to point out there is a lot of legacy with VPN... Q - When you ran your tests, did you do any tests where you took links up and down and looked at the reaction of the routing protocol A - Yes Q - How did having multiple zones affect convergence of the routing protocol A - It affected it, but not much ------ Connected site-local considered harmful Rob Austein ======================================= Scopes and borders Scopes (which imply borders) - node - link - site - global Things that change at borders - routing - security - naming - addressing Is single "site" border a good place to put a border for all of these things? Application and scope - Some applications are intrinsically scoped (eg RA, ND) - Most applications have no concept of scope - Mmost applications have no way of expressing scope --> Stuff leaks across the borders - names leak (mail, web, files) - addresses leak (early name->address binding) One size does not fit all - Site borders sound at first like a nice simple approach ... but it's wrong - Are these the same border? - autoconfiguration system - address realm - two-faces DNS border - firewall - demarcation point Private addresses do not enhance security - Attacks via a border machine - Attacks via leakage - Weak ended node security sue to false sense of security - Firewalls have to filter bad global stuff anyway - Private addresses are just one more thing to filter - Private addresses do not make filtering easier Reachability versus ambiguity - Firewalls limit reachability - Private address realms also limit reachability - This is not an improvement - draft-ietf-dnsop-dontpublish-unreachable Multiple sites - Devices that have to live in multiple sites are hard - multiple routing tables - multiple naming realms - multiple (potentially colliding) addressing realms - complex forwarding and leakage rules [Comment from presenter that Mark Andrew's proposal is the least evil way to go down this horrible path] Recommendations - If we have to keep site-local at all, only use in disconnected case - Globally unique address would be better in disconnected-case ----- What next? Bob Hinden ============ [Admit that part of me likes global addresses like old internet architecture, but then the other part of my brain looks at what people are doing today, and people think that is how things should work.] My moderate proposal - Not an official chair position - Goal is to present a framework for what I think makes sense given the discussion - Pragmatically I think that people will create and use limited scope addresses even if we say "no" Simple site-border router - Router with "no-site" interfaces - hard site-local filters build in for interface in "no-site" site - black hole route for FEC0::/10 - Firewall at site border that enforces site boundary - Little or no impact on routing protocols, etc Nodes - No requirement for multi-site nodes - All routers include black hole route for FEC0::/10 - Vendors may build multi-site nodes - Useful to document pitfalls of doing multi-site nodes DNS - Keep site-local out of global DNS - Range of solutions possible - Two-face/split DNS - Mark Andrews' proposal - Ask dns-ext wg to take this work? Applications - Issues with applications are real - However, site-local usage isn't worse than the world we are in today - Important that API's allow applications to override address selection defaults Choices for IPv6 WG - My division - Limited usage - Moderate usage - Full usage - Other divisions? -- Discussion Margaret - (not chair view) site-local were invented for not-yet connected networks. Very useful for this purpose. I think we want to retain this usage. If we allow them to be used on connected networks we are overloading. Two different things should have two different concepts. Also is ambiguous scoped addressing the right way to solve the problems we are trying to solve? What we need is unique addressing ... site local is not the way to solve all of this. Other thing -- in general, we are not going to be able to tell people to not do local addressing, but we can try to give them a better way to do it. We can say site-local is for disconnected and we have something better for connected. Q - Thank chairs .. I've gone from trying to get site-local to work well, to restricting them to a disconnected is the right thing to do, now we may not even want to do this. We want to think of the implications of allowing them for disconnected sites, and consider getting rid of them. Philosophically, think of model .. create boundaries ... then later as network evolves, how to penetrate through boundaries, or start out within the boundaries ... thinking about what happens when you open things up. Other thing, engineers try to go off and solve interesting problems ... risk going forward, people will try to glue things together. A - I agree with some of that ... we may want use cases for gluing things together ... VPNs .. Q - Two important issues not mentioned ... First one - leakage of dns names If you know of a legendary black hole, it is causing big problems, and site local will cause more problems. Second problem -- possible to use site-local for mobile ip when offsite, for mobile nodes it is not possible to tell difference between local and not. We need to be careful. A - Take mobile ip to that wg Q - Claim that site locals provide additional security is dubious at best. Not clear how much it buys you. If someone gets local traffic in your network, you can't track it. You can't trust site locals because you can't trust an address. The question is is the marginal security benefit worth introducing complexity? This will touch all network equipment, cause operational problems... High cost for dubious benefit. I understand why people want it and why people think it makes sense . I'd like to propose a different set of compromises. If you buy the idea that people are going to use them anyway, you basically need to provide global addresses for your applications. Say use global addresses that you are sure are going to only be local... this is dubious. Rhird option ... deprecating. It's easier to say don't use site-locals at all instead of providing constraints that only provide minimal benefit. Q - Don't like site-locals. We should look at history ... or history will repeat itself. Last night in plenary people complain ... this is the same stuff. IPv4 address space before CIDR. people are not familiar with multi-address. If you put those two together ... people will want to use site-local. Q - Answer Alain's comment. There is an inherent bias to look at anything new with suspicion. The problem we have seen is that people have not really wrapped their minds around the concept completely. People have said that site-local was only intended for disconnected. I don't agree this was the intent. Certainly link-locals and global addresses are mixed in IPv6 architecture today -- no mapping expectation. We have accepted the complexity. If you take on the IPv6 mentality of link and global, then site fits in nicely, even if it didn't fit into the original IPv4 architecture. Also, Bob I like your intermediate proposal. To get people on the fence, although I would not want to do anything to prevent the usage of site-local in the overall schema. Q - I wanted to bring up a fact of operational network today. a typical ISP operation is one single router that is their network on one side and hundreds of customers on the other. Many hundreds of sites in one router. This seems to be a difficult situation and should be kept in mind as to how network are built today. Q - Hardware vendor. Once this stuff is in hardware, I can't change it. Didn't mention site-local in hardware ... I don't think I heard people saying that they had too much experience with this stuff. A - We are not here to talk about address architecture Q - One slide item, you say that people who do global address, same as scoped addresses, don't think this is true. Filters don't allow <something>, so you still have topology in the addresses ... need to ensure accuracy in this discussion. Hain - scoped addresses exists in reality. Can continue to meet people where they are and provide a way to move forward, or we can try to fight it. Most of arguments against them is that I don't understand things. Best current practice changes over time. Greg - My bias is new -- come to a decision. I don't think this is the site-local address solution. Recognize need for stable addresses and ability to deploy without having to change addresses. If we look at IPv6 routing architecture, we moved to isp provided prefixes, because we don't want routing tables too big. What we need to do is keep that -- can't change that. We can allocate specific site-specific addresses that are not routable. The principle problem is know that the address is not yours. If we can solve that problem then maybe site-local works. Bellovin - The original design is really bad. never defined a site. As for buying security ... it doesn't. We don't design for people only going out through ALGs. Most nodes are going to have global addresses. The switch can just reject what is not in its /48. Operational simplification. RFC 1918 made things complicated. We could do this today and are not, so probably won't happen in IPv6. Q - Local addresses are something everyone would like to have. First point. Two issues. What to put into the document? Second, what will people implement. Document should constrain the experiments ... The issues of dealing with site-locals are mainly transition cases. People then need to transition to global address space. We can put stuff in the document, but it is not going to limit implementations. Christian - Lots of opinions ... We will come up with a compromise that will be a "wink wink" compromise. Telling people to not use it will not stop the usage. If we want to stop usage then we need to provide an alternative that people like better. We should have compromise that is rational, but we should work on the alternative. There is difference between unreachability and ambiguity. You want unreachability. Problems come from ambiguity. Q - We are at the point where we have to make a decision. In 5 or 6 years people will look back and hope we did things different. If you don't solve the problem in a good way, something else will take its place. NATs require everyone to do things right, if not things stop working. IETF is about a simple Internet where things work. Case earlier about multi-sited nodes ... difficulty is that I see other cases where multi-sites nodes will cause problems. If things don't work, it will be difficult to debug. Is no worse than today. Q - In favour of site-local in moderate usage. It is reality now and will be used. I can see how it can be used. The reason that people NAT now will go away. There might be applications where site-local addresses would be useful, so support Bob's stuff. I don't think it will be that damaging. Q - If we allow site locals it is rather dangerous. If you decide to do this, it will again delay deployment of new protocols. If we do them, why such as large address space? Hinden - The main thing I heard, if we chose a limited approach, we should really go ahead and work on a real solution. <something off mike> Hinden - Not trivial ... Probably do go and work on something with slightly better properties. Take things to a vote. Q - My comments is: Can you say what the tree options are and what they mean? Moore - problem with phrasing the question this way. It glosses over the layer 7 issues. I think this is the real problem. plus two questions not being asked. Is there a consensus to accept site-local as trustworthy? Is there consensus that the WG should work on a real solution? Q - Quick comment ... also include address architecture changes? A - Approved for DS already. Q - In my opinion, these are not only choices. Several people said even the limited usage was evil. Repair the problem gives those people a voice. Q - Clarify question: Limited usage as currently defined? A - Yes Q - Trying to understand how questions will be asked... A - Which ones do you prefer? Which ones do you object do? Q - Rephrase ... None of the below and we define the real solution? Q - At some level this is a solution ... We should look at the problem. Margaret -- Is the problem statement to get global addresses non-ambiguously? Q - We should also ask if people are comfortable to answer this or are things to are too unclear. Margaret - Do people have enough info for us to ask the question? Consensus: Yes, enough info Margaret - First round .. vote once for what you prefer. - remove entirely - limited usage - moderate usage - full usage No consensus: ~30 Remove, ~51 Limited, ~57 Moderate, ~17 Full Christian - If you look at the result, it is clear that people don't like site-local addresses. The vast majority is somewhere between limited usage and moderate usage. Then we are close to the compromise. People know it is dirty -- then we go for the real solution. Margaret - It is difficult to limit something after the fact. I don't think the IETF should document something we don't think is right. Christian - People will be using it until we come up with a better solution. Q - Sense of room ... Really need to work on real solution. Based on numbers, think moderate approach. Strong limitations and move towards a real solution. Q - Think we can get consensus on limited usage and real solution. Q - Can we call the second question? Margaret - Time management question... Continue or cut off to allow other presentations? Consensus: continue Margaret - Vote for unacceptable solutions - remove entirely - limited usage - moderate usage - full usage Q - Confused. Do we agree we should focus on either limited or moderate usage. Consensus: One of those two choices or somewhere in between. Margaret - I think we need to go off and create proposals for people to look at with more details on which to base decisions. Margaret - The wg has agreed we don't want to remove them completely and that we don't want to document them completely Q - Volunteer to document limited uses. Q - I think if we have a divided effort, we won't make progress. Q - We have had a million emails on this and I'd like to come to a conclusion. I think we are very close. simple. clear cut. Q - Simple question, hard answers Q - Before deciding all of this, in the discussions, there was some interest in writing BCP for usefulness and non usefulness of site-local. This would be useful Margaret - I think we had some consensus on the list on this would be a Good Thing Q - We have agreed without saying it, that enterprise has things that they are trying to accomplish and will have to accomplish these regardless of what we do. Need to capture requirements. Margaret - Feel free to write a document. Q - <discussion of real solution> Requires provider-independent address space. Moore - Agree with Tony on this point. Don't want to get into this right now though. I want to see if I understand the polling that has taken place. I want to rephrase it slightly, it appears to me that we have near consensus that it is OK to use site-local in disconnected networks. We also have near-consensus that it may be OK to use site-locals in restricted other uses. Like to see a vote. Q - We need another level of detail before we can get further consensus Margaret - We have made some important decisions today. Margaret - Brian has volunteered to document stuff we can't explore this whole space in two minutes. Hinden - There needs to be some solution, otherwise there will be leakage. Q - in the real solution, we need to flesh out the problem space. Q - people think the real solution is impossible, but there are two drafts out there, look for "multi-six" on the internet draft page. Fred - like BCP idea. Willing to help, I would learn stuff and perhaps provide benefit. I like the idea of limited usage.