IPng Working Group Meeting Redmond, Washington May 30, 31, June 1, 2001 Meeting hosted by Microsoft Bob Hinden (Nokia), Steve Deering (Cisco) Chairs Minutes taken by Bob Hinden (Nokia) Slides available at http://playground.sun.com/ipng/meetings.html ------------------------------------------------------------------------ ------------------------------------------------------------------------ Agenda ------ Wednesday, May 30, 2001 0900-1700 ---------------------------------- Joint meeting between IPng Working Group and 3GPP ------------------------------------------------- 9:00 Introduction / Steve Deering & Bob Hinden (15 min) Local Arrangements / Christian Huitema (15 min) 3GPP Architecture / Jonne Soininen (60 min) 10:30 Break (15 min) 11:45 3GPP QoS architecture / Bonnie Chen (30 min) Answers to IETF questions (1) / TBD (60 min) 12:15 Lunch (90 min) 13:45 Answers to IETF questions (2) / TBD (60 min) 3GPP documents structure and relevance to IPV6 (15 min) 15:00 Break (30 min) 15:30 3GPP2 Overview / Pat Calhoun (45 min) Follow up Discussion / Action Points (45 min) 17:00 Adjourn Thursday, May 31, 2001 0900-1700 --------------------------------- IPng Working Group ------------------ 09:00 Introduction / Steve Deering & Bob Hinden (5 min) Multi-Link Subnets / Dave Thaler (45 min) Router Selection / Rich Draves (30 min) 10:20 Break (15 min) 10:35 Ingress Filtering / Rich Draves (45 min) Dialup Architecture / Jun-ichiro itojun Hagino (40 min) 12:00 Lunch (90 min) 13:30 DAD Reduction / Markku Savela (30 min) Comments on Address Selection Last Call / Rich Draves (15 min) Updates to Addressing Architecture / Bob Hinden (15 min) Flow Label Discussion / Steve Deering (60 min) 15:30 Break (30 min) 16:00 DNS Discovery / Dave Thaler (30 min) Scoped Address Architecture / Steve Deering (60 min) 17:30 Adjourn Friday, June 1, 2001 0900-1700 ------------------------------- IPng Working Group ------------------ 09:00 Reserved for additional items 10:30 Break (15 min) 10:45 Reserved for additional items 12:00 Lunch (90 min) NGTRANS Working Group --------------------- 13:30 ISATAP - Intra-site tunneling 15:00 Break (30 min) 15:30 Matrix of transition mechanisms 17:00 Meeting Adjourned ---------------------------------- Wednesday, May 30, 2001 0900-1700 ---------------------------------- Joint meeting between IPng Working Group and 3GPP ------------------------------------------------- ------------------------------------------------- Introduction / Steve Deering & Bob Hinden ----------------------------------------- Steve Deering introduced the meeting. Reviewed the agenda. Announced that the 3GPP Architecture and 3GPP QOS talks will be combined. Local Arrangements / Christian Huitema -------------------------------------- Reviewed meeting logistics, coffee (very important), food, restaurants in Bellevue. Recommended Tosoni (20th Ave. and 143 street). Also in Bellevue, Spazzo (Union Bank tower, 4th street between 102 & 106). 3GPP Architecture / Jonne Soininen ---------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Reviewed 3GPP organization. 3GPP TSG WG 2 SA is group that is working on overall architecture and "All IP" architecture. This is where most of IPv6 work is going on. Technical work is done in WGs. Most of work is done in meetings, not on mailing lists. Frequent meetings. Technical reports discuss issues, changes, etc. Technical specifications are the protocol/system specifications. Approval by consensus or vote. Voting isn't used very often. Participation is based on companies. Membership is based on national standards structure. ANSI in US, ETSI in Europe, etc. Note that multinational companies may have access via several national organizations. All standards, documents, and project plans are available at: http://www.3gpp.org 3GPP specifications come out in releases. First release was release 99 (came out in March 2000). Next release is called Release 4 (March 2001). Some corrections still possible for release 4. Corrections are also possible for old releases when errors are found. Currently working on Release 5, targeted for December 2001. New releases can add and delete functionality. Strong emphasis on backwards compatibility. Releases not tied to implementation experience. [Slides showing Release 99 architecture] 3GPP specifications does not include IP address allocation, NAT, etc. This is considered an Operator deployment issue. Release 4/5 architecture [slide]. Biggest change is IP everywhere. SS7 over IP. GGSN and SGSN functions don't change too much in Packet Switched domain. Adds IP Multimedia Core Network subsystem (IM CN IMS) based on SIP. This part is IPv6 exclusively. In the standard there is no dual stack. Can not deploy IPv4 only terminal. Note that the underlying infrastructure can be either IPv4 or IPv6. GTP tunneling is used to carry the multimedia layer, datagrams, etc. What is different from MM subsystem and packet domain? One runs on top of the other. Packet Switch Domain Architecture Transmission of packets from mobile to GGSN is carried over GTP tunnel via the SGSN (tunnels bridged). Mobility in GTP moves the mobile end of the tunnel from one SGSN to another as the mobile moves. The IP address of the mobile is allocated by the GGSN. Mobile is TE (terminal equipment) and MT. Example: TE is laptop, MT is phone. This mode uses phone as an agent (bridge?) to allow the laptop to get to the GGSN. This is not using the mobile phone as a router. PDP context was originally designed to carry several concurrent data services such as X.25, IPv4, etc. Limit on number of PDP contexts to terminal? Thinks 16. Terminal can create multiple PDP contexts. Each can have specific QOS and/or different IP domains (company, Internet, etc.) An IP address may be shared across several PDP contexts or not depending if they are directed toward different APNs (access point name). GGSN will map outgoing from handset packets to the appropriate PDP context based on QOS and address. No more than one IPv6 address per PDP context. IPSEC is not mandated in terminal. Multicast support? An implementation issue for GGSN. Not specified in specifications. Access point name is a logical name referring to a GGSN. APN also identifies an external network such as a corporate network. Traffic flow templates allow traffic to be controlled to/from handset. Comment that it is missing the protocol number. Has ports, but misses protocol. This is a mistake. Mostly focused on distinguishing different QOS. QOS: Using SIP and COPS as the basis for setting up QOS. QOS not specific to IPv6. This is an optional functionality that may not always be implemented. IPv6 Details IPv6 PDP type introduced in GPRS release '97. Transport plane, IPv6 is optional. UTRAN: IP transport study is being conducted now. IMS has been standardized to be based on the following: IM CN subsystem shall exclusively support IPv6. [Shall in 3GPP means the same as Must in IETF]. TE shall exclusively support IPv6 for the connection to services provided by the IM CN subsystem. IPv6 Address allocation methods Stateless address auto-configuration introduced in GPRS R'99. Stateful address auto-configuration, optional DHCPv6 client in terminal, requires DHCP relay agent in the GGSN. GPRS specific address configuration; Two options: 1) Static address configuration: The MS provides its statically configured IPv6 address at PDP context activation. 2) Dynamic address allocation: the IPv6 address is provided by the GGSN at PDP context activation. Discussion on what is supported. Stateless address auto-configuration. Discussion on limitations of mode of GGSN always providing address to MS. Used IMSI to identify MS. IMSI is 15 digits. Duplicate address detection is disabled on this link. Comments: What we see here is a need to associate a 64bit prefix to a PDP context. This will allow the GGSN as a router and permit the MS to have multiple address per PDP. This will result in something simpler and more flexible. This is an area that is broken. This is very limiting and should be changed. Christian Huitema and others will write up comments on this area to send to 3GPP. [Note: it was later decided that a design team will be formed to address this feedback] Is there any tie in to the DNS to allow a handset to be reached? No current specification for DNS in handset or for use of DNS in these networks. Discussion about privacy. Deering: Device will want to have both kinds of addresses (static and temporary). They both have important usage. Is a prefix assigned to a single mobile or is it shared among many mobiles? Currently this is implementation dependent. Another topic to bring back to 3GPP. Deering: Is the interface ID supplied in the activate PDP context global or local? Important that the global/local bit is set correctly. Should reference RFC2373 IPv6 Address Architecture. Is the expectation that each GGSN will get a prefix to assign? Operators will have to do it. Nothing in 3GPP specs defines how to do address assignment/management. Header compression. Uses RFC2507, RFC3095, RFC3096 used on air interface. IPv4/IPv6 Transition. No mandatory requirements. Specification cites Dual stack, NAT/PT, Tunneling as examples. Left to operators and vendors to decide. Issues relating to what has to be implemented in the handsets needs to specified. Not everything can be an implementation decision if there is to be interoperability between handsets and the infrastructure. Handsets want to be usable in any operator's network. Goal of release 5 is to allow VoIP support exclusively. Some operators are looking at this. 3GPP QoS architecture / Bonnie Chen ----------------------------------- [Note: Talk was combined w/ previous talk] Answers to IETF questions / Jonne Soininen -------------------------------------------- Note: Questions were sent to 3GPP prior to the meeting. They are shown here by leading "**"s. ** What is the addressing model for the network and handsets? Will each ** handset be given a single 128-bit address and no more? Or will each ** handset be given its own /64 (e.g. an entire network) so that it can ** connect additional devices, say through a bluetooth or 802.11 ** interface? ** ** related question is how many additional devices (e.g., a laptop) ** will be able to connect to a handset (e.g., via bluetooth) and use ** IP. Doing so would suggest each device would need an IPv6 address ** and both the handset and the device being on the same subnet. One ** way of providing such a capability would be to have each handset be ** a router for a /64 subnet. Is such a configuration envisioned now, ** or in the future? Currently a mobile device can not work as router. Specified as bridge. Has there been thinking about doing this? Hadn't been investigated yet, but there is a desire to pursue this. Durand: Does this mean that two devices behind the mobile phone need to send their packets to the GGSN in order to communicate (i.e., they can't do it directly via the mobile phone). Yes, that is what would happen. ** What parts of Neighbor Discovery (RFC 2461) will be implemented on ** handsets? All of it? How will handsets using IPv6 communicate with ** each other when on the same subnetwork (or link in IPv6 ** terminology)? Is ND needed to resolve addresses or does the handset ** view its connection to the network as a point-to-point link with a ** router on the other end (i.e., the GGSN)? Handset views itself as being connected to one or more serial links. Neighbor Unreachability Detection (NUD) is done. Router advertisements are used to tell handset the prefix to use. Only a single prefix is allowed to be advertised per a PDP context. ** What is the scope of problem for which IPv6 is viewed as a solution? ** I.e., what features of IPv6 are needed immediately, and which are ** assumed to be of interest at some later point in the future? Address space is the primary reason IPv6 is being used. This is the main point. Mobile IPv6 will be added later to support mobility across different media. ** How permanent are the IPv6 addresses that are assigned to handsets? ** From our understanding, interface identifiers are assigned by the ** GGSN, and handsets then form addresses by combining the interface ** identifier with a prefix learned through Router Advertisements ** (RAs). Is it envisioned that information specific to the mobile will ** be used to form the interface identifier (e.g., IMSI)? Or will the ** interface identifier assigned to a handset change over time (e.g., ** if it is power cycled or moves)? This question is important as it ** will determine whether addresses are effectively permanent in the ** sense that it will be stable for weeks or more. ** ** In the case that addresses remain stable for weeks or longer, are ** any of the concerns raised in RFC 3041 viewed as applicable? The IPv6 address life is tied the length of time the PDP context exists. They are created when the PDP context starts and are lost when it is ended. A new IPv6 address will be assigned to the phone when a new PDP context is started (e.g., either an additional one or when the mobile is powered on). ** Will handsets be dual stack (i.e., support both IPv4 and IPv6) or ** will they support only IPv6? Some of the documents suggest that in ** the IM domain, IPv6 will be used "exclusively". Does that ** specifically mean that IPv6 must be supported and the IPv4 doesn't ** apply? Handsets may be dual stack. They must have IPv6, they may also have IPv4. ** Where will IPSEC (RFC 2401) be used? Will IPSEC be implemented on ** the handset (to provide true end-to-end encryption) or will IPSEC ** terminate at the GGSN, with the remainder of the path (from the GGSN ** to the handset) protected by link-layer encryption? ** ** Note that it is our understanding that in the current specs MN to ** SGSN communication is protected by GSM privacy but there is nothing ** specified between the SGSN and the GGSN. Will the tunnel between the ** SGSN and the GGSN will be carried over the Internet? ** ** Finally, are there any plans to implement IKE? If not, how will ** IPsec security associations be created? IPSEC not defined by SA WG 2 (Architecture). SA WG 3 (Security) is currently looking at IPSEC usage. Compression raised as an reason why this isn't currently specified? None of the 3GPP specs require IPSEC to be in handset. GTP security is allowed to use IPSEC for security. Has 3GPP looked at IP payload compression to allow payload to be compressed before encrypting with IPSEC? Thinking that IPSEC will not be used for RTP data. Might be used for SIP. Still under study. ** Are there any requirements in the area of QOS? Are diffserv and/or ** RSVP being looked at as something that is important? Nothing required in the current release. There are several scenarios how QoS can provided. DiffServ and RSVP are being looked at. May be an operator implementation option. ** What transition schemes will be used in communicating with IPv4 ** sites? Some of the 3GPP documents make mention of NAT-PT as well as ** automatic and configured tunnels. However, automatic tunnels only ** make sense if address numbering is done in a certain way. It is not ** clear that the use of automatic tunnels makes sense in the 3GPP ** environment. Has there been any study of schemes, in addition to ** NAT-PT, that allow IPv6-only and IPv4-only nodes to communicate? Transition is not currently specified by 3GPP. It is left up to the operators to decide. ** Which IPv6 RFCs does 3GPP consider to be part of IPv6, in the sense ** that they must be implemented as part of the 3GPP Release 5 ** specification? Are all of these RFCs to be implemented in their ** entirety, or are only subsets of (some of) them needed? Is there any ** intention to take parts of the IETF protocols and modify or extend ** them? Would be good to generate a list. Would help to see if there are dependencies and identify musts and should's. ** Are there any plans or needs with regards to compression? For ** example, the IETF has existing standards (e.g., RFC 2507) and ** on-going efforts to compress IP traffic over link layers. Is it ** anticipated that 3GPP will have needs here? RFC2507, RFC3095, and RFC3096 used on air interface. ** What DNS components will be used? For example, IPv6 addresses can ** reside in either AAAA or A6 records. Will resolvers in handsets be ** implementing A6 records? Or both AAAA & A6? Not discussed, need to look at. 3GPP documents structure and relevance to IPv6 / Jonne Soininen --------------------------------------------------------------- Stage 1 Requirements 21.101 Specifications list 22.060 General Packet Radio Service (GPRS); Stage 1 Stage 2 23.221 Architectural requirements (e.g. Transition examples) 23.060 General Packet Radio Service (GPRS) Service description; Stage 2 (e.g. Address Autoconfig) Stage 3 Minor detail 24.323 Packet Data Convergence Protocol (PDCP) protocol (Header Compression for UTRAN) 04.65 GPRS Subnetwork Dependent Convergence Protocol (SNDCP) (Header Compression for GSM/Geran) 29.060 GPRS Tunnelling Protocol (GTP) Across the Gn and Gp Interface 29.061 General Packet Radio Service (GPRS); Interworking between the Public Land Mobile Network (PLMN) supporting GPRS and packet 27.060 GPRS Mobile Stations Supporting GPRS (e.g. PPP link between MT and TE) 3GPP2 Overview / Pat Calhoun ---------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Organizational structure TSG-A air network access, IP based access network, Mobile IP based RAN portion of network. BTS to BSC TSG-P CDMA2000 packet data specification is based on mobile IPv4, working to incorporate IPv6 support TSG-N Supporting specs to support existing mobiles over an IP based core network, multimedia SIP mobiles This is part of the overall 3GPP2 work. There is currently a packet data network based on circuit switching. All-IP is working to have the packet data network run over an IP infrastructure. What is "All-IP" in 3GPP "All-IP" is the concept of moving the current wireless network architecture from the current circuit based concept to an packet based architecture utilizing IP protocols and technology where possible. Discussion about how All-IP Architecture works based on IPv4. All-IP not currently deployed. TSG-P is currently working to include support for IPv6 into next release, scheduled in 4Q01. Assuming that a migration from IPv4 to IPv6 is possible, and that IPv4 and IPv6 based All-IP networks must interoperate. Operators understand need for IPv6 addressing, but need to allow existing IPv4 users on All-IP network. Allow both IPv4 and IPv6 users to access applications and services on IPv4 networks. Comments that this needs to be better defined to make it more realistic. Concerns w/ IPv6 - Security holes in Mobile IPv6 binding update [speaker acknowledge this was a mis-characterization of the mobile IPv6 issue] - Is Mobile IPv6 baked enough to support base voice handoffs? - How will IPv6 networks interact with services on IPv4 networks? General comments that these comments are apples to oranges as IPv4 doesn't have these issues solved. IPv4 solutions don't solve these problems either. Also, does attendant (access control) functions using IPv6 and AAA. Note: Not clear this issue is specific to IPv6. General discussion of relationship between 3GPP and 3GPP2, are they competing, are they working toward common architecture. They are separate organizations, they share some common interests, but they are not currently working toward a single solution. They are focused on competing markets. Time frame for All-IP. First phase end of this year. More in later phases. Follow up Discussion / Action Points ------------------------------------ Deering suggested that we create a design team to provide feedback to 3GPP on our input from the working group. Publish it as an internet-draft and have it reviewed by the working group. Would like participation from people from 3GPP as well. Took poll of room and there were enough people interested in doing this. Goal is to have a draft out by the ID deadline for the August IETF. This is 6-7 weeks for now. Narten: Thinks it should be done sooner. Would like more informal interaction. Jonne: Could pass comments along sooner. Minutes would be a good start at this. Margaret: Thinks we will need to do both. Minutes will capture discussion, ID will have discussion of design choices and possible recommendations. Narten: Need to get meeting minutes to 3GPP by their next meeting in two weeks. Some discussion about forming a mailing list for this and who can join. --------------------------------- Thursday, May 31, 2001 0900-1700 --------------------------------- IPng Working Group Meeting -------------------------- -------------------------- Multi-Link Subnets / Dave Thaler -------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Multilink subnet is a subnet that spans multiple links, but is routed at layer three. Similar to bridging except all hops are visible. TTL will be decremented. Only need a single /64 for multiple links, even where you only get a /64. Simplifies management, don't have to allocate subnet, etc. Why not just bridge? Link-scoped multicast hits low bandwidth links, heterogeneous link types, some links don't have promiscuous mode. Some bridging protocols as L3, can't handle heterogeneous links, etc. Goals: No change to end host behaviour, no change to link-scope behavior , avoid routing loops, fast convergence. Non-goal: scalability to huge subnets. Comment that there are some simple topologies where this is very useful. More complex topologies is much harder. Sub-problems: Duplicate address detection, address resolution, multicast, router-router (ISR-ISR) communication. Hosts view of the subnet. Approaches: "off link" and "on link". Off link: Use ND to tell hosts to send all packets to router, router redirects for on link, On Link: hosts send NS, router proxies NA if off link destination. Duplicate address detection: DAD is only on link currently, DAD not required for other addresses with same Interface ID. Question: do we skip this for non-global interface IDs? Routers need to make sure address is unique across multiple subnets. What about links where we don't run ND on (e.g., Point-Point link)? For multicast, can't use subnet route (multiple directions), need either non-RPF based mechanisms (e.g., spanning tree) or host routes/neighbor cache entries for RPF. Router-router communication approaches. 1) create spanning tree, 2) flood neighbor solicitations, 3) populate host routes, d) use a subnet server (bad). Comments: This is mixing up different dimensions. This is somewhat similar to what MANET w.g. is doing for ad-hoc networks. Thinks spanning tree is too complex. Flood NS's: Router stores sources of all NS's seen and floods NS out of all links in subnet. NS propagates across entire subnet. Only the end node responds with a NA. Router sends proxy NA only if heard a real NA. Deering: Thinks this is trying to turn NA/NS into a routing protocol. Why not use existing solution (spanning tree, routing protocols, etc.)? This has much of the complexity of routing protocols, but is not proven. Proactively populate host routes. Uses routers to listen to DAD approaches. Problem that DAD are not sent periodically, new router, would not hear DAD. Comparing NS flood w/ host routes: NS-flood takes longer, bursty source problem, timers might be tricky; Host routes use more state, need to solve simultaneous DAD problem. Discussion. Comments about comparison with add hock approaches. Needs more analysis. If limited to simple topologies like single router this is a lot simpler. Problem is that may not be able to tell if there is only one router. Could solve by adding info to ND to indicate if it was a multi-link subnet. Issue is that there are so many solutions it might be hard to settle on one. Worthwhile to focus on simple solutions. Could also generate a lot of multicast traffic. Polled room to see if there is interest to work in this area (in the IETF). Consensus that there was interest in this work. Should work be limited to simple topologies? No consensus on this question. Mention of relationship to zero conf working group. Zero-conf limed their work to a single router. Doesn't deal with multi-link subnets. Router Selection / Rich Draves ------------------------------ [Slides available at http://playground.sun.com/ipng/meetings.html] Changes: Specified receiver processing for the reserved preference value, specified that routers should not include more than 17 router info options, added discussion of destination cache invalidation, removed discussion of "host D". These changes reflect feedback received to date. Open issues: Feedback from operational folks. Sent to multi6 list, didn't get any reply. Suggestion to talk to folks in Japan who are running operational networks. Interactions with router renumbering? Hasn't look at it. Needs more thought. Getting close to last call. ACTION: Document editor to start last call when new draft is out. Ingress Filtering / Rich Draves ------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Discussion draft to discuss issues. Problem for multihomed site with different prefix for each ISP. ISPs perform source-address based ingress filtering. Routing may cause packets to an ISP with a source address from another ISP. Tunneling between Egress Routers. Problem is that this is relatively inefficient. No changes in hosts. Sites w/ one link. Each ISP router only advertises its own prefix, then router choice could influence source address selection if hosts remember which router advertised the prefix used to generate each address. Only works with very simple case. Could be generalized to site networks where each internal router only forwards toward one egress. Use prefix policy table that source address selection. Drawbacks need to understand how intra-site routing partitions destination space. Also need to distribute policies to hosts. New ICMP error. Destination unreachable due to source filter, supplies the required prefix. Host can associate this prefix with a destination address and use it to influence source address selection. Analogous to PMTU discovery. Comments: Could be extended as a mechanism to influence general address selection. Sometimes hosts (servers) have to respond with address connection was sent to. Could also use mobile IPv6 option to get around. Issue w/ TCP interaction. This doesn't help with the first packet sent to a destination. Must modify TCP to recognize this error in response to a SYN and redo source address selection. Comments: Deering thinks this is mostly covered in source address selection draft. Other approach, do source and destination based routing in site, and more general mechanism of using all source/destination pairs would cover this as well. Dupont: Thinks TCP recognition should go in draft. Issue, how to route the error. If ISP generating the error sends to the source address with original address, will do back through another ISP. Might not arrive at all. Solutions: Force this particular ICMP error back out link it came in on, or send the ICMP error using a routing header w/ intermediate hop. More discussion. Mention that source based routing may be needed in the site. Pro: Like PMTU discovery, good robustness, Con: Like PMTU discovery, first packet is dropped, needs additional mechanisms Could this be handled by telling your ISPs the prefixes you have and to accept them. This is the current practice. Bush: This is focused on solution area where ISPs don't support current Multihoming solution. Where there is no cooperation from ISPs. Discussion.... If new ICMP for this, it would like it to be more generalized to provide other routing based feedback. Also some DNS issues. More than just defining a new ICMP, would require TCP behavior to change. Could it be use to disrupt a TCP connection maliciously? Host would have to do sanity check before closing the TCP connection. Is this within scope of IPng w.g., or should it be in multi6 w.g. Has a relationship to multihoming work. Not clear if we should proceed in IPng or Multi6. It would be good to present to Multi6 w.g. Dialup Architecture / Jun-ichiro itojun Hagino ---------------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] IPv6 PPP Requirements Main issue is dialup, not PPP. IPv6 dialup requirements are different from IPv4. Usage patterns: static client, PC at home wants static assignment; roaming client: traveling PC, get dynamic assignment. Address space /48 or /64. Never do /128. Cases: /64 to PPP link; not recommended /64 to ethernet behind the router /64 to (virtual) ethernet behind the router /48 to ethernet behind the router; best choice, ISP doesn't care about customer topology Routing (customer - ISP); either static or RIPng, BGP, etc. User/Prefix management in ISP; Use static configuration or RADIUS attribute could be used. RADIUS draft is in last call. Roaming client prefix assignment. ISP tells customer about /48 or /64 prefix to use. Could use router renumbering, DHCPv6, PPP extensions, RA on PPP, ICMPv6 auto-prefix-assign. Prefers ICMPv6 auto-prefix assignment approach. Router renumbering is not suitable, requires sharing of keys w/ ISP. DHCPv6 doesn't currently have suitable attribute. Extensions to PPP not general enough. RA on PPP link does not create allocation ICMPv6 auto-prefix-assign. Discussion.... Deering likes RA on PPP link for roaming users. Natural to use RA in this case. Huitema: DHCP could be used, but it is a stretch. Issue with ICMPv6 auto-prefix-assign. Approach needs an authentication mechanism. Risk is somewhat limited because protocol just runs on one link so it is hard for someone to inject traffic on link. With /64, customer router has to update RAs to the subnet behind it. If more than /64 (e.g., /48) customer routers need to be reconfigured. What are next steps? Thinks we need standard for how to use dialup links in IPv6. Might have different approaches for dynamic or static dialup cases. Discussion: Huitema: RA extension w/ multilink prefix would be a good combination. Conta: Thinks we should be looking at access networks, not just dialup. Brian Zill: Doesn't like the DHCPv6 or PPP approach. Likes the RA and ICMPv6 approaches. Bound: Likes RA approach. Wants to look at PPP approach as well. Also doesn't think DHCPv6 is good approach. Dave Thaler: Also doesn't like PPP. Prefers solution that works on non-point-point links as well. Doesn't want to be limited to p-p links. Margaret: We need to distinguish between router and host. Otherwise we move in multi-link subnets quickly. Like separate mechanisms for routers and hosts. Nordmark: We should think about future uses of this (beyond point-to-point). Most like RA approach but need way of telling next hop router what prefix to use. Huitema: RA no way to pull static prefix from a router. In RADIUS draft there is a way to have the dialup server to learn a specific prefix. Extends to non dial up links. Thinks we have need for ICMPv6 auto-prefix is when node has a requirement for another prefix. Other cases (RA) can handle first prefix. Dupont: Thinks DHCP would be good to use for this case. Deering: Are we expecting to use DHCP to configure routers? Dupont: yes. More discussion...... Aboba: Thinks we should stop talking about PPP. The issue is broader than point-point links. Thinks the issue is just access, not media specific. Doesn't like PPP and DHCPv6. Doesn't like RA on PPP. Should use to get things on links behind router. Prefers ICMPv6 approach. Phil: Thinks ICMPv6 is good for routers. Conta: Think should be extended to access. Should continue at next draft. Deering: Took poll in room on approaches to see if we could reduce number of choices: Router Renumbering: 0 DHCPv6: 0 PPP extension: 1 RA on link: many ICMPv6 many Consensus of the room is to focus on RA on link and ICMPv6 approach. DAD Reduction / Markku Savela ----------------------------- Unique ID on Link? TAHI expected to see DAD for each new prefix/id combination after sending a RA. Is this a DAD storm? [maybe just a shower] Solution1: Any normal ID on the link can be assigned only to one host at a time. DAD is skipped if ID is same on different addresses. Discussion: ND spec says you don't have to do DAD it if DAD had been done for link local addresses. TAHI test is wrong to require DAD on every address. However, most implementations always do it, because they don't distinguish between manually configured addresses, auto-configured addresses, etc. Is this a problem in practice? Deering: It would it be better to distinguish between manually configured ID's and auto-configured IDs. Addrconf RFC and privacy RFC combined have a conflict. If auto-config uses a non-global ID and privacy creates random ID, they might collide. Margaret: Choices are either do DAD on all addresses, or only check ID portion, not prefixes. Deering: Is there any reason to have nodes with the same ID but different prefixes? Proposal is to only do DAD for interface IDs. Discussion..... Decision? DAD for unique ID only?, or adjust Addr Conf to prevent DAD storm? Need to remove "may" close from AddrConf spec and add a random delay. Compatibility between old and new hosts. Can this change be made. More discussion..... Three arguments against doing this: 1) not backwards compatible with existing stuff, 2) spec is at draft standard, 3) xxx Reason for DAD is to detect bad manual configuration and network cards with duplicate IDs. Deering proposal: If interface ID is generated by HW token or random token, don't do DAD. Only do it for manually configured IDs or DHCP generated. Depends on quality of a random destruction. Zill: Thinks cost of DAD is not worth the benefit. The biggest cost is the delay. More discussion..... Proposal to require private addresses to first do an DAD test on the link local version of the random ID. This should be backwards compatible with base ND and specification. Discussion, but no clear consensus on what to do. Current specifications might need to be updated. Some cases may be ambiguous, for example manual address. Discuss on mailing list. Comments on Address Selection Last Call / Rich Draves ----------------------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Changes from previous draft. Reversed treatment of temporary address. Implementation should use public address unless application directs otherwise. Clarified expectation that applications will loop over destination addresses. Removed references to getipnodebyname. Issues raised on mailing list during working group last call Standard vs. informational? Dupont objected because takes freedom away from implementors and this behavior should not be a standard. There is still a rough consensus to proceed with standards track. Source address selection for multicast destination. Deering thinks this rule is OK with the requested example. Discussion.... Need to document IPv6 multicast behavior, but should be separate document. The Addr Selection draft will be updated to clarify this. Privacy: temporary vs. public preference. Conservative thing to do is to make the default behavior prefer the public. Applications may get unexpected behavior if temporary address is the default. No route to destination? Change wording to clarify that node should avoid using a destination address if next hop is unreachable. May be an issue in the transition specifications. Important that address selection work correctly. Will clarify text to cover more cases and clarify the issues. ISATAP? Will be discussed in NGTRAN's meeting on Friday. Various minor editorial comments Open issues: Changes to Base API spec to allow applications to influence address selection? This is not an open issue for this draft. New draft should resolve open issues. ------------------------------------------- Friday, June 1, 2001 0900-1700 ------------------------------------------- Report from Interoperability Testing / Brian Zill ------------------------------------------------- Fifteen people, 7 implementations 4 subnets, 3 different routers (different vendors) Tested: Router redirects w/ 2 implementations RAs w/ preferences with 2 implementations (host and router) RAs w/ more specific routes Routing header handling on 4 implementations 6to4 with 2 implementations Mobility without and with IPSEC (home agent and correspondent node) For the most part everything worked fairly well!! Solid implementations. All basic IPv6 features seemed to work well. IPv6 DNS Discussion / Randy Bush -------------------------------- Much discussion on A6, DNAME, and bit string labels. Pushed from DNSOPS and NGTRANS to DNS directorate who has been discussion and a recommendation. Bit stream labels 39.0.28.147.in-addr.arpa Can't us NS records to delegate first octet in DNS name (last octet of IPv4 address). Hack to use CNAMES to do phony delegation. Needed in IPv4 because there is delegation in first digits. RFC2317. Bitstrings were invented to handle this in IPv6, to allow allocation of bit boundaries in name space. Issues: Requires new label type and a change in protocol on the wire. DNS directorate conclusion is that the bit string RFC should be moved to historic because there won't be any delegation at the low order part of the IPv6 address. Will make recommendation to this effect. A6 Allows split of address to make lookup easier. Motivation was to make it easier to deploy new routing mechanism such as GSE and rapid renumbering. Conclusion is that we don't need A6 until we have either something like GSE or rapid renumbering. May be recommended to move to either historic or experimental. Bound: Comment that the BIND folks think that if we limit chain to two entries, it would be helpful with multihoming. Three might be OK, but more is completely unknown. This might be a reasonable usage of A6. DNAME Developed in anticipation of changes that IPv6 might need later. Has issue of casting this in concrete. Can be deferred until something is needed. Discussion of what to do is ongoing. Olifer is writing up conclusions. Plan to transition from ipv6.int to ipv6.arpa was going to use DNAME, but can also done by just running the two structures in parallel. Not a major issue. General comment that it is very important to resolve these issues soon. Need to be done by London. Updates to Addressing Architecture / Bob Hinden ----------------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Changes from -05 Draft - Added an IANA considerations section. - Added clarification that "IPv6 Addresses with Embedded IPv4 Addresses" must use global IPv4 addresses. - Divided references in to normative and non-normative sections. - Added reference to [PRIV] in section 2.5.1 - Revised section 2.4 to clarify the FPs that are for Global Unicast Addresses and combined sections on the Global Unicast Addresses and NSAP Addresses into one section on Global Unicast Addresses. - Added clarification that all unassigned FP's must be treated as global unicast addresses unless unless another standards document defines an exception. - FP Table Revision Discussion: IPv4-compatible IPv6 addresses should contain only global v4 addresses (e.g., ::10.x.x.x is illegal). This does not apply to v4-mapped v6 addresses. Clarify text. Suggestion deprecating v4-compatible addresses. After discussion conclusion was to leave as is. There are many places where they are references. NGTRANS may change their specifications to no longer use. FP Table Revision [Note: "xxxxx" indicates line to be removed, will not be in next draft] Allocation Prefix Fraction of (binary) Address Space ----------------------------------- -------- ------------- Reserved 0000 0000 1/256 Global Unicast 0000 0001 1/256 xxxxx Reserved for NSAP Allocation 0000 001 1/128 xxxxx Global Unicast 0000 001 1/128 Global Unicast 0000 010 1/128 Global Unicast 0000 011 1/128 Global Unicast 0000 1 1/32 Global Unicast 0001 1/16 xxxxxx Aggregatable Global Unicast Addresses 001 1/8 xxxxx Global Unicast 001 1/8 Global Unicast 010 1/8 Global Unicast 011 1/8 Global Unicast 100 1/8 Global Unicast 101 1/8 Global Unicast 110 1/8 Global Unicast 1110 1/16 Global Unicast 1111 0 1/32 Global Unicast 1111 10 1/64 Global Unicast 1111 110 1/128 Global Unicast 1111 1110 0 1/512 Link-Local Unicast Addresses 1111 1110 10 1/1024 Site-Local Unicast Addresses 1111 1110 11 1/1024 Multicast Addresses 1111 1111 1/256 Discussion of naming all reseved prefixes to Global Unicast. No change from what was proposed. IANA Considerations - The table at http://www.isi.edu/in-notes/iana/assignments/ipv6-address-space.txt should be replace by the table and notes in section 2.4. - All IANA allocations of IPv6 address space to the Internet Address Registries should be made from FP 001. All other Global Unicast format prefixes are reserved for future use and are not to be assigned by IANA at this time. - Format prefix 0000 001 is reserved for NSAP Allocation as defined in [NSAP]. Global Unicast Adddress Section | n | |bits| m bits | p bits | 128-n-m-p bits | +----+-------------------+-----------+----------------------------+ | FP | routing prefix | subnet ID | interface ID | +----+-------------------+-----------+----------------------------+ - Lists OSI NSAPs and IPv6 and Aggregatable Global Unicast Addresses as examples Open Issues - Add ::FFFF:0:0:0/96 IPv4 translatable prefix [SIIT] to global unicast addresses exception list or generalize to 0000:0000::/32 Discussion of excluding SIIT addresses. Proposal to name make either change, but to change text to only refer to exceptions defined in address architecture document. Erik N. who proposed this change is OK with this solution. Flow Label Discussion / Steve Deering ------------------------------------- [No talks were given] DNS Discovery / Dave Thaler --------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html ] Transport mechanism Q: How to do discovery messages get from devices to servers (if any)? A: Site-scoped anycast Content Mechanism Q: What's format of the discovery messages? A: DNS SRV lookups Requirements for payload One or more DNS server addresses (ordered?) Client's domain name (domain, not host name) Clients search path Must fit in 512 bytes Other requirements Allow single config for entire site Allow per subnet config as an option implies request needs to identify subnet Want a single request message implies a single response in practice Proposal Well known (domain) name => local.arpa Well known Protocol: => _dnsinfo Put SLA in Service field of query Example: Client is on subnet fec0:0:1234::/64 Query for _1234._dnsinfo.local.arpa Comment: Host will need to know it's subnet / interface boundary. Might be better to require site local prefix in request. Proposal (server config) Use port to encode type (e.g., 0=domain name, 1=search path, 2=server) Use Priority to specify ordering within a type Only server targets need address records Discussion: Might be a problem with using ports in this manner. It is within scope of specification, but it might break assumptions that implementations has made. Also, spec requires every record to have an address. Discussion about merits of using this approach vs. using DNS text records. Might also require some changes to DNS server implementation. Big issue??? CH: Thinks this approach will work fine for getting server addresses, but don't think it is good for other information. Bush: There must be an address record in response. Conclusion: Can encode multiples types of information Can support 2 level "longest" match No changes to existing DNS servers Issues have been identified. Authors needs to address. Look at different record types. Does this break the assumptions that made this approach attractive (i.e., no changes to DNS protocol, DNS server implementations, etc.)? Scoped Address Architecture / Steve Deering ------------------------------------------- Would like to resolve one open issue from presentation at last IETF and subsequent email discussion: Agreed at Pittsburgh IETF: 1) Zone indices are distinct from interface indices 2) One number space for all zones+interfaces (e.g., sin6_scope_id is a 4-bit scope + 28 bit index) 3) When an address is qualified by a zone index, scope of zone index must = scope of address Issue: (3) would be easier to enforce if (2) were not true e.g., Making zone IDs be flat 32-bit integers and determining zone scope from address's scope Much debate, including disagreement over which is the simpler approach. Took poll to see if there was a consensus. No clear consensus at meeting, but a clear desire to just pick one. Will take it up on the apifolks mailing list, and try to drive to a decision within a few weeks. 3GPP Design Team ---------------- Steve Deering announced that Bob Hinden will be charing the design team to provide feedback to 3GPP on the use of IPv6 in 3GPP. Contact Bob Hinden if interested. Point to Point Links (not PPP) / Deering ---------------------------------------- What the best way to treat point to point links? Should they be treated as special case as a link with only two end points. P-P links only have two end points but each end can have multiple addresses. One issue is what to do if router receives packet on P-P link that is addressed to the link but not to the router's address. Should the packet be forwarded back on the same link. Should the router could send an NS and time out if a NA isn't received, and/or send an ICMP error message indicating this error. We could either us ND or have an ICMP error messages to determine reachability. Do we recognize that some links can only have two points so we could treat differently? Discussion: Need to clarify if NS should be used on point-to-point links. Could always set "R" bit on RA sent on P-P links. We may now have an interoperability problem because not all implementations use ND in the same way. Need to have a default behavior that everyone uses. Agreement that we don't have to require other end of link to send back to the sender a packet that is not for it on the P-P link (e.g., on the same link). Draft will be written to describe the issue and propose a solution. ----------------------------- IPng Meeting Adjourned ----------------------------- [Note: Minutes from the NGTRANS meeting will be published separately and sent to the ngtrans mailing list. NGTRANS Working Group --------------------- IATAP - Intra-site tunneling ----------------------------- Matrix of transition mechanisms -------------------------------- ---------------------------------------------------------- ----------------------------------------------------------