IPng Meeting Munich IETF August 1997 ------------ Meeting chaired by Steve Deering / Cisco and Bob Hinden / Ipsilon. Minutes by Bob Hinden. Agenda ------ Introduction / Deering, Hinden (5 min) Action Items / Hinden (5 min) Document Status / Hinden (10 min) Plan for Advancing Current Drafts / Hinden ( 10 min) IPv6 Protocol Updates / Deering (30 min) - Restrictions on Routing header reversal - Specification of Class (formerly Priority) field - Reserved bits for Explicit Congestion Notification bits - Inclusion of Class in Flow constant fields? - Neighborness rules for Strict/Loose Bit Map - Encoding of Option types TLA/NLA Assignment Rules / Hinden (20 min) Neighbor Discovery Issues / Nordmark, Narten (20 min) Decision on Advancing Current Documents / Hinden (10 min) Mobile IP / Johnson (10 min) IPv6/NBMA work in the ION group / Armitage (10 min) IPv6 Transmission over Frame Relay / Conta (5 min) IPv6 Transmission over IPv6/IPv4 Tunnels / Conta (5 min) Inverse Neighbor Discovery for IPv6 / Conta (5 min) Inverse Neighbor Discovery for IPv6/IPv4 Tunnels / Conta (5 min) Site prefixes in Neighbor Discovery / Nordmark (10 min) Router Renumbering / Crawford (10 min) IPv6 Name Lookups Through ICMP / Crawford (10 min) DNS Alternatives to ICMP Name Lookups / Gudmundsson (5 min) Header Compression / Degermark (10 min) Traceroute using hop-by-hop options / Durand (5 min) DHCP vs. Prefix changes Introduction / Deering, Hinden ------------------------------ Steve Deering introduced the meeting and reviewed the agenda. IPv6 Testing Event / Deering ---------------------------- 15 companies attended (up from 12). They were Digital, IBM, Sun Microsystems, FTP Software, Fujitsu, Hitachi, Bay, 3COM, Epilog, Toshiba, BSDI, Process Software, Ipsilon, SGI, and Inria. Testing included 11 host and 6 routers implementations (3 hosts did routing too). They did interoperability testing only, not conformance testing. Results were: - 15 nodes supported ping - All nodes supported new (aggregatable) address format - 3 nodes did Path MTU discovery and Packet too big, 6 did not, rest unknown. - 7 nodes did both client and server telnet - 6 nodes did client and server FTP - 2 nodes did PPP - 3 Routers sent ICMP redirects, 5 hosts processed them correctly - 5 1/2 hosts did auto-configuration - A few nodes supported FDDI and/or token ring Next event is first week in December. Action Items / Hinden --------------------- Action Items (San Jose IETF) - Document editor will submit Tunneling Spec to IESG for proposed standard. o Sent request to IESG on 12/10/96. IESG last call sent on 12/30/96 which ended on 1/17/97. Many comments received. IESG restarted last call for this document and two GRE documents on IPv4 tunneling. o Steve Deering currently reviewing GRE documents and will respond to IESG last call. On Agenda for Memphis. o IPng Chairs sent email to Internet ID's. Waiting for IESG action. o Jeff Burgan (Internet AD) reported that IESG would vote on this document separately from IPv4 tunneling documents. - Document editor will do a working group last call on Header Compression specification. o Sent on 12/10/96. Working group last call ended 12/24/96. o Comments received from Thomas Narten. Once comments resolved (and new draft published) document editor will send to IESG. o New Internet Draft Published. On agenda for Thursday session. - Dimitry Haskin and Dave Katz to write a draft proposing adding an option to BGP4 to carry IPv6 interdomain routes. o Drafts written for BGP4+ and BGP5. IDR discussed. Compromise discussions underway. o Discussed at Tuesday IDR session. Consensus to go forward with BGP4+. - Thomas Narten to include in next version of neighbor discovery rule to silently drop non-DAD packets which use the unspecified address as the source of the packet. o Open o On agenda for Wednesday session. Action Items (Interim Meeting) - "WhoAreYou" ICMP Message / Matt Crawford o Draft missed ID deadline. Sent to IPng list and on Memphis agenda. o On agenda for Thursday Session. - Modify Link Name Draft / Dan Harrington o Update underway o Waiting for outcome of "WhoAreYou" draft - Lessons from interim meeting / Thomas Narten, John Stewart, Allison Mankin, Lixia Zhang, Matt Crawford o Done. Internet Draft published. Discussion on agenda. o New draft published. Publish as Informational RFC? o Authors plan to publish as RFC. Action Items (Memphis IETF) - Issue working group last call for IPv6 MIB's once new drafts are published. o W.G. last call completed. o Sent to IESG for Experimental, Internet AD's reviewing. o Jeff Burgan (Internet AD) reported that it will be considered for proposed standard. Need to get a code-point outside of the experimental subtree. Document Status / Hinden ------------------------ - RFC - Proposed Standard o TCP and UDP over IPv6 Jumbograms (RFC2147) - IETF Last Call completed o Generic Packet Tunneling in IPv6 Specification - Submitted to IESG for Proposed Standard o IPv6 Router Alert Option - Submitted to IESG for Informational o Advanced Sockets API for IPv6 - Submitted to IESG for Experimental o MIB for IPv6: ICMPv6 Group o MIB for IPv6: TCP o MIB for IPv6: Textual Conventions & General Group o MIB for IPv6: UDP - Working Group Last Call Completed o Header Compression for IPv6 o IPv6 Router Alert Option o A Method for the Transmission of IPv6 Packets over ARCnet Networks o An IPv6 Aggregatable Global Unicast Address Format o IP Version 6 Addressing Architecture o IPv6 Multicast Address Assignments o IPv6 Testing Address Allocation o TLA and NLA Assignment Rules o Transmission of IPv6 Packets over Ethernet Networks o Transmission of IPv6 Packets over FDDI Networks Plan for Advancing Current Drafts / Hinden ------------------------------------------- Hinden talked about it is now time to move the base IPv6 specifications to Draft Standard. The main criteria is that they are stable. After some discussion with the Internet AD's the important thing is that we don't make any changes which break interoperability. Once a document is at Draft Standard it will be important to not make changes that are not critical. It is important that we stabilize the documents to encourage products and deployment. With each document we wish to move to Draft Standard an implementation report will have to be written. The document editor will coordinate the creation of a feature list for each specification with the authors and create a template for an implementation report. The list of documents with a proposal for advancement is as follows: Document Current Proposal ------------- ----------- ----------- IPv6 Protocol Proposed Std. Draft Std. Addressing Architecture Proposed Std. Proposed Std. ICMP Proposed Std. Draft Std. DNS Proposed Std. Draft Std. Neighbor Discovery Proposed Std. Draft Std. Address Auto Configuration Proposed Std. Draft Std. Aggregatable Addresses Internet Draft Proposed Std. IP_over_Ethernet Proposed Std. Proposed Std. IP_over_FDDI Proposed Std. Proposed Std. IP_over_PPP Proposed Std. Proposed Std. IP_over_ARCnet Internet Draft Proposed Std. TLA/NLA Assignment Rules Internet Draft BCP Testing Address Allocation Experimental Experimental Multicast Assignments Internet Draft Informational Path MTU Discovery Proposed Std. Draft Std. Packet Tunneling Internet Draft Proposed Std. This list will be reviewed later in the meeting after the current drafts are discussed. IPv6 Protocol Updates / Deering ------------------------------- Restrictions on Routing header reversal Question about need for requiring RH reversal. Currently: three legal behaviors: reply without a source route, reply with a configured source route (independent from received source route), or reverse received source route if packet was successfully authenticated. Current text is compatible with current Mobile IPv6 draft. Group agreed to keep current behavior. Specification of Class (formerly Priority) field 4 4 24 +-----+-------+-----------------------------------------+ | ver | class | flow label | +-----+-------+-----------------------------------------+ Bits are available for rewriting by routers. High order class bit recommended for interactive, other three are not defined, but left open for experimentation. These bits and flow label are not included in IPSEC AUTH header. Reserved bits for Explicit Congestion Notification bits Deering proposed congestion experienced bit (like "DEC" bit in CLNP). Has been lobbied for many years. Idea is to mark packets when congestion occurs to notify the receiver instead of just dropping packets. Van Jacobson had always resisted idea. At last End-to-End meeting, group came up with approach to use this bit with RED algorithm. Unfortunately VJ liked the new idea (not so bad). It is too early to be a required part of IPv6. Does show lots of potential. Thinking about freeing up more bits to allow this usage. Proposes: 4 8 20 +-----+-------+-----------------------------------------+ | ver | class | flow label | +-----+-------+-----------------------------------------+ The class bits would be set to zero on sending and ignored on reception. Reduces number of flows to ~1,000,000 per source address. Group agreed to make class field 8 bits long. Discussion about how tightly they should be defined. Deering thinks it is important to keep these bits reserved to allow IPv6 to be extensible. Suggestion to only reserve bits, and make definition of usage in a separate document. Christian Huitema disagreed, he thought it should be defined. Deering thought we should move the definition to a separate document. Group agreed to do this. Inclusion of Class in Flow constant fields? Question is: must the Class bits be constant for all packets in the same flow? One side of argument is that as long as the Class bits can affect routing, they should be constant within a flow -- otherwise, opportunistic flow set-up can violate desired routing semantics. The other side is the desire not to eliminate the potential flexibility of allowing applications to vary some of the Class bits within a single flow. Allison Mankin suggested we might delete opportunistic flow setup text. This would be reasonable when going to draft standard. Choices are to take class out of flow definition, or to define that the "D" bit is not to affect routing. Group agree to remove opportunistic behavior from specification, and to exclude Class from set of fields that must be constant within a flow. There are no known current implementations of opportunistic flow setup. Neighborness rules for Strict/Loose Bit Map Specification never defined Neighborness rules for strict/loose source behavior. Deering speculated that this was included in IPv4 was for security behavior. To keep this behavior it would require adding detailed rules for tunnel behavior, etc. Suggestion was made that we should get rid of strict source route capability. D. Hasken thought we should keep strict, but would need consistent set of rules. Deering polled group. Consensus to remove strict bits. Bits become zeros and text describing usage is removed. Further discussion, but no change of consensus. Encoding of Option types Should IPv6 option be identified by full 8 bit value or 5 bit option type. Current spec shows full 8 bits. No objections from group. Change recommended order of Extension Headers Deering had changed order based on what he thought was in ESP and AH drafts. This change was in error, and will be changed back to original behavior. Suggestion to make options fixed length to make it easier to implement IPv6 in hardware. Deering replied that this would also require removing all extension headers. There was a consensus to not make this change. Bigger MTU? Should we change the IPv6 minimum MTU to something closer to 1500 (i.e., something like 1300, to allow room for one or two levels of encapsulating/ tunnel overhead without exceeding the Ethernet MTU of 1500). This is the last opportunity to make this change, given the increasing number of existing implementations and the strong desire to move the base IPv6 spec to Draft Standard ASAP. This change would significantly reduce the importance of doing MTU discovery for multicast, which is something best avoided because of the ICMP implosion hazard. 576 was chosen because of IPoverAppletalk. Most links (except for dialup) are already ~1500. Comment that this would be a problem for dialup links. Deering replied that for slow-speed links it's preferable to do link-specific fragmentation and reassembly, below the IP layer. Several people supported the idea. Very strong consensus to raise MTU to ~1300 bytes. Editors Note: The Integrated Services over Specific Link-layers (ISSLL) working group is currently developing standards for doing link-specific fragmentation. Some of their techniques address criticisms of using large MTUs on slow links (e.g., having small packets get stuck behind bigger ones). This may be relevant to this issue. ------------------ Thursday Session ------------------ Deering reported continued issue with decision to increase MTU. Proposes to discuss on mailing list. Need to resolve quickly. Note: Alex Conta said that ICMP spec needs to get changed for multicast group membership messages. Deering proposes removing multicast membership messages from this document and create a new document for these messages. Proposal to Add Explicit Congestion Notification (ECN) to IPv6 and to TCP / Sally Floyd -------------------------------------------------------------- Reference: Floyd, S., TCP and Explicit Congestion Notification, ACM Computer Communication Review, V. 24 N. 5, October 1994, p. 10-23., http://www-nrg.ee.lbl.gov/ What is New - Deployment of active queue management (e.g., RED) in the internet. - Increasing amount of best-effort traffic where the user is sensitive to the delay (due to retransmission) or drop of an individual packet (e.g., telnet, web browsing, best-effort audio and video, etc. What is Needed in IPv6? - Two bits: o An ECN-capable bit set by the origin transport protocol o An ECN-bit set by the router (instead of dropping the packet) when the buffer has not overflowed, and the ECN-capable bit is set, and the router would otherwise drop the packet because of the RED algorithm, based on the average queue size. - There is a single-bit version of this, described in Floyd94, that overloads a single bit What does ECN Bit Indicate? - Indicates incipient congestion as indicated by the "average" queue size exceeding a threshold, using the RED algorithms [FJ93, RED-ietf-draft] - The ECN bit should "not" be set in response to an unfiltered signal such as the instantaneous queue size. - A "single" packet with the ECN bit set should be treated by the end-nodes as an indication of congestion, just as would a "single" dropped packet. How do transport protocols respond to the ECN bit? - Congestion control response should be the same as that to a dropped packet. - Details depend on specific transport o Reliable unicast (e.g., TCP) o Reliable multicast (e.g., SRM) o Unreliable unicast o Unreliable multicast (e.g., vic) What modifications are needed for TCP? - Negotiation between the endpoints during setup to determine if they are both ECN-capable - A TCP option with an ECN-Notify bit so that the data receiver can inform the data sender when a packet has been received with the ECN bit set. - The data sender halves its congestion window "cwnd" in response to an ECN-notify. This is done only once per window of data. Internet draft will be out in a few weeks. TLA/NLA Assignment Rules / Hinden --------------------------------- Overview - Goal to Provide Guidance to Registries and Organizations receiving TLA IDs o Avoid "Land Rush" on TLA IDs - Focus on assigning TLA IDs to Organizations providing Public Transit Service - Assignment does NOT mean ownership o It implies "stewardship" TLA Assignment Rules - Must have a plan to offer public native IPv6 service within 6 months from assignment. The plan must include plan for NLA ID allocation. - Must have a plan or track record of providing public Internet transit service on fair, reasonable, and non-discriminatory terms, to other providers. TLA IDs must not be assigned to organizations that are only providing leaf service even if multihomed. - Must provide registry services on fair, reasonable, and non-discriminatory terms, for the NLA ID address space it is responsible for under its TLA ID. This must include both sites and next level providers. - Must provide transit routing and forwarding to all assigned TLA IDs on fair, reasonable, and non-discriminatory terms. - Organizations are not allowed to filter out any specific TLA IDs (except temporarily for diagnostic purposes or emergency repair purposed). Periodically (interval set by registry) provide to registry utilization statistics of the TLA ID it has custody of. The organization must also show evidence of carrying TLA routing and transit traffic. This can be in the form of traffic statistics, traceroutes, routing table dumps, or similar means. Comments: Erik Nordmark: don't rule out tunnels for TLA access (e.g., for hopping over non-IPv6-supporting secondary provider). Brian Carpenter: The wg's responsibility is to specify technical proposal and the technical rationale/justification Steve Deering: Gov't example is special case of an ISP that serves a closed community Someone: please don't use word "rules". Too strong. Internet AD's will help wordsmithing. General consensus to move forward as a BCP when new draft is out incorporating suggested clarifications. An IETF last call will be useful to have the broader IETF community review the idea in this document. Neighbor Discovery Issues / Nordmark ------------------------------------ Changes - Change move solicited node MC address changed to pointer to Address Arch. - Remove priority references - Decrementing lifetime variables - Default lifetime infinity changed to 60 days Clarifications - Use of unspecified source - Setting of NUD state - Setting of Ls router flag - Added "renumbering considerations" section The zero lifetime issue is still unresolved. This is the remaining issue that needs to be resolved before moving ND and AddrConf to Draft Standard. The authors will make a proposal on the mailing list. Decision on Advancing Current Documents / Hinden ------------------------------------------------ IPv6 Protocol Group agreed to move to Draft Standard once the MTU issue was settled. Addressing Architecture Group agreed to move to Proposed Standard. ICMP Group agreed to move to Draft Standard once multicast membership messages were removed. DNS No action at this time. Waiting for resolution of other DNS related work. Neighbor Discovery No consensus to move this forward. Zero lifetime issue still open. Address Auto Configuration No consensus to move this forward. Zero lifetime issue still open. Aggregatable Addresses Group agreed to move to Proposed Standard. IP_over_Ethernet Group agreed to move to Proposed Standard. IP_over_FDDI Group agreed to move to Proposed Standard once bridging text was removed. IP_over_PPP Group agreed to move to Proposed Standard once terminology was clarified. IP_over_ARCnet Group agreed to move to Proposed Standard once terminology was clarified. TLA/NLA Assignment Rules Group agreed to request publication as a BGP once revision available. Testing Address Allocation Group agreed to move to Experimental. Multicast Assignments Group agreed to move forward as either Informational RFC or IANA database input. Path MTU Discovery Group agreed to move to Draft Standard. Packet Tunneling IESG will consider for Proposed. Mobile IP / Johnson ------------------- Status of IPv6 Mobile work. - Current spec is . - High Level Overview o Care-of addresses from IPv6 address autoconfiguration o Mobile node sends its own Binding Update o Uses for correspondent nodes and home registration o Nodes cache bindings in a Binding Cache o Correspondents route own packets directly to mobile node - One implementation almost available. Dynamic Home Agent Address Discovery - Mobile node may not always know its home agent address o While mobile node is away from home o Home network may need to be reconfigured o Different machine may take over as home agent - In Mobile IPv4, this is solved by o Mobile node can send to "directed broadcast" address o All home agents in home network receive request o All reject, giving their own unicast address o Mobile node tries again with one of these addresses - Can't do this in Mobile IPv6 since no broadcast in IPv6 New Home-Agents Anycast Address - To register when don't know own home agent address o Mobile node sends Binding Update to "Home-Agents anycast address" for home subnet o Receiving home agent replies, giving unicast address o Mobile node registers to that IP address o All IPv6 home agents MUST support this Deering suggested that we reserve some number local interface identifiers for anycast addresses for applications that need anycast addresses. Suggest a new document for initial anycast assignments. ACTION: Document Editor. Replay Protection for Binding Updates - Must guard against replay attacks on Binding Updates - IPsec AH and ESP can do replay protection o Protection based on sequence number o Must re-key before sequence number wraps around o Only accept packet if sequence number >= max or within a "replay window" of sequence numbers before that o Allows out-of-order delivery - Problem: Binding updates MUST be applied ONLY in order Solution for Binding Updates - Use IPsec for "Replay Protection" o Lets IPsec worry about re-keying before wrap around - Use our own sequence number for sequencing o Similar to TCP sequence number when using IPsec replay protection o Our sequence number only needs to be large enough to cover replay protection window reordering. Getting through Ingress Filtering - Original Mobile IPv6 addressing for packets sent from a mobile node o Source address = mobile node home address o Destination address = correspondent node address o Problem: Ingress filtering drops all these packets - New solution uses "Home Address" destination option o All IPv6 nodes MUST support receiving packets containing a Home Address option. Questions about how this works and if it affects FTP and telnet. Document will be clarified. Use of Home Address Option - Mobile node uses care-of address as source address... - But only while packet on its way to the destination node - At the Sender o Sender builds packet (e.g., TCP) using home address o Then substitutes care-of address as source o Move home address into a Home Address option in packet - At the Receiver o Receiver substitutes correct source address (home address) back into packet in place of care-of address - Implementation of this would be required in all IPv6 receivers Home Address Option vs. Binding Update Option - Binding Update option o Creates state in receiver in Binding Cache o Used by receiver for sending future outgoing packets o MUST be authenticated o Use is only an optimization (not required in all nodes) - Home Address option o Creates NO state in receiver o Does NOT affect future routing of any packets o Need NOT be authenticated (unless IPv6 header already is) o Receiving MUST be supported by ALL IPv6 nodes Home Address Option Security - If IPv6 header "source address" is authenticated o Home Address option MUST also be authenticated o Need to preserve protection of this field - Otherwise o Home address option need NOT be authenticated either o IPv6 header source address may be forged/modified o So may Home Address option data Movement Detection Timing - Helpful to know when to expect packets from router o Mobile node know when it missed one o Mobile node can decided for itself home many missed packets are a cause for concern (possible movement) - Neighbor discovery provides good source of packet form router o Periodic Router Advertisements o Must receive new one before old one expires o But router must send more frequently, since some might be dropped o Would help mobile node to know nominal advertisement interval o Example: long lifetimes, but frequent advertisements Comments Please - Send comments to mobile IP mailing list - Also can be sent to Dave Johnson and Charlie Perkins IPv6/NBMA work in the ION group / Armitage ------------------------------------------ Current draft is: Suggestion to put "ipv6" in name of draft Updates - Interface token now based on 8 octet EUI-64 - Cleaned up vague text - Specified host triggered transient neighbor discovery - folded in some text from expired TODO - Syntax mapping between ND and NHRP at routers - Clean up the misleading "ATM dependency" implied by current text Current approach - "on link" => "on logical link" (on LL) - ND used on LL (native multicast or augmented MARS/RFC2022) - Flow detection in router leads to NHRP query for destination o NHRP reply translated to Redirect on source LL o "transient" neighbor - Host Trigger (NS for remote dst sent to router) also leads to NHRP inter-router query - NHRP reply translated into NA back to soliciting host Current approach does not require ND to change. Questions to gja@lucent.com IPv6 Transmission over Frame Relay / Conta ------------------------------------------ Draft: Defines: - Min, max, default MTU - Frame format for IPv6 over FR - Interface ID for FR interfaces - IPv6 local address - Source/target link layer address options in ND MTU - Min frame size, 5,6, or 7 octets - General requirement for at least 262 octets - IPv6 requires a minimum MTU size of 576 - Default MTU = 1600 - 575 <= MTU <= 4080 with CRC16 - MTU > 4080 less error detection / correction at link layer - MTU defined per link - implementation limitation. Deering comment need strong link layer CRC. Should discourage MTU greater than 2080. Frame Format using SNAP identifier. Found out there is a NLPID (0x8E) , would save same header bits. Slides showing figures with two approaches to create Interface IDs (first includes FR Node Identifier, FR Link Identifier, and FR DLCI, second is random number and FR DLCI), Link Local address, and Unicast Address Mapping. Editors Note: After discussion with the author and the chairs of the ION working group, the IPng chairs decided that the ION working group should own this topic. The IPng working group will consulted to insure that the work is consistent with IPv6. IPv6 Transmission over IPv6/IPv4 Tunnels / Conta ------------------------------------------------- Draft: Extension to existing IPv6 tunneling document Goals - Tunnel minimum, maximum, and default MTU - Frame format for IPv6 over IPv6 and IPv4 tunnels - Interface ID for IPv6 tunnel interfaces - IPv6 link-local addresses for tunnel virtual links - Source/Target Link-layer address option used in ND or IND over IPv6 and IPv4 tunnels. MTU - Default tunnel MTU is Physical underlaying IPv6 interface MTU - tunnel headers size - 576 <= tunnel MTU < default tunnel MTU Tunnel Packet Format - IPv6 tunnel packets re encapsulated as IPv6 and IPv4 packets Interface ID (IPv6 tunnels only) - The IPv6 tunnel pseudo-interface ID o Unique on the virtual link represented by the tunnel o Based on the underlying physical interface identifier - Mask the forth and fifth octets of the EUI-64 identifier with the fixed 0xFFFC value - Example 36-56-78-FF-FE-9A-BC-DE becomes 36-56-78-FF-FC-9A-BC-DE Link Local Address - The IPv6 link-local address for an IPv6 tunnel interface is formed by appending the interface token, as defined above, to the prefix FE80::/64. Address Mapping [figure not included] Inverse Neighbor Discovery for IPv6 / Conta ------------------------------------------- Draft is Introduced topic. Extension to IPv6 for FR and similar links when link layer is known, but IPv6 address is not known. Read document and send comments to author . Inverse Neighbor Discovery for IPv6/IPv4 Tunnels / Conta -------------------------------------------------------- Draft is Introduced topic. Extension to ND to allow inverse discovery for tunnels to aid in tunnel configuration. Read document and send comments to author . Site Prefixes in Neighbor Discovery / Nordmark ---------------------------------------------- Includes automatic creation of site local addresses and the creation of global version for DNS lookup. Only global addresses need to be in the DNS. Motivation / Requirements - Reduce the risk of renumbering a site - Ensure that communication local to a site uses site-local addresses - Do not require that sites use a two-faced DNS (i.e., do not store the site-local addresses in the DNS). [Slide with additions to ND Prefix Option] Name Lookups - Create site-local addresses when an address returned by DNS matches a site prefix. The first Site PLength bits are taken from the site-local address (FEC0::0) and the remaining bits are taken from the returned address. - Add the created site-local addresses to the front of the list returned to the application. - Hidden from applications (i.e., in gethostbyname library). Name Lookup Example - Name service returns (for a multihomed node) 2837:a:b:987:X:Y:W:Z1 2837:a:b:34:X:Y:W:Z2 2abc:77:66:23:X:Y:W:Z3 2000:1:2:987:X:Y:W:Z1 2000:1:2:34:X:Y:W:Z2 - List of Prefixes 2837:a:b::0/48 2000:1:2::0/48 - Resulting list of addresses (duplicates removed) fec0::987:X:Y:W:Z1 2837:a:b:987:X:Y:W:Z1 2837:a:b:34:X:Y:W:Z2 fec0::34:X:Y:W:Z2 2abc:77:66:23:X:Y:W:Z3 2000:1:2:987:X:Y:W:Z1 2000:1:2:34:X:Y:W:Z2 Address Lookups - No change unless a site-local address - For site-local form the potential global addresses using the prefix list and the site-local address - For example, if the site-local address is: fec0::987:X:YX:W:Z1 - List of site prefixes 2837:a:b::0/48 2000:1:2::0/48 - The addresses that should be tried 2837:a:b:987:X:Y:W:Z1 2000:1:2:987:X:Y:W:Z1 Open Issues: - Node on link can be use this to spoof the address and names returned by the DNS. o But such a node can already intercept all traffic o Doing name/address lookup without communicating - Subnet number must be the same for all global and site-local addresses used by the site. Is this too strict? - Should the formed site-local address replace (instead of being added to) the global addresses returned to the application. - Common API to access the list of site prefixes. Many questions. Need additional discussion on the list. We need to discussion on the mailing list. Header Compression / Degermark ------------------------------ Three drafts: - Main draft: - How to compress RTP: Status - Protocol ID's from PPP ext - Negotiation of header compression parameters - Name Change: Header Compression for IP - Changed the order of the field in compressed TCP headers to conform with RFC1144 - Priority/Class field: How to deal with this when we go to Proposed Standard? - MTU: Not problematic fro PPP. There is a standard for link-level fragmentation. ACTION: Document editor will do W.G. last call once new draft is available. DHCP vs. Prefix changes -------------------------------------------------- Issue is nodes can get addresses through manual config, addr conf, and DHCP. If you have gotten addresses from one method, how to deal with changes received from DHCP and/or ADDR CONF. This needs clarification. One possible rule is that changes only apply based on way they were learned. This is consistent to how DHCP works now for IPv4 (dynamic from DHCP and manual config) and how routing protocols work with dynamic routes vs. static routes. ND and DHCP specs need minor revision. DNS Alternatives to ICMP Name Lookups / Gudmundsson --------------------------------------------------- IPng DNS, and DNS Provide an alternative to "WHO ARE YOU" message. This is a change from the plan to always return AAAA records. This would return two pieces and host would put together. Claim made that for secure DNS it is necessary to return two pieces. Needs to be discussed further on the mailing list. This affects moving the DNS draft to "Draft Standard". This needs to be resolved first. ------------------------------------------------------------------------- At this point the session ran out of time. The following agenda topics were not discussed: Router Renumbering / Crawford IPv6 Name Lookups Through ICMP / Crawford Traceroute using hop-by-hop options / Durand The IPng chairs apologize to speakers for not covering their topics at this meeting. -------------------------------------------------------------------------