Editor's Note: These minutes have not been edited. IPng Meeting Memphis IETF April 10 & 11, 1997 Bob Hinden, Ipsilon Networks / co-chair Steve Deering, Cisco Systems / co-chair Minutes taken and edited by Bob Hinden ------------------------------------------------------------------------ Agenda ------- Thursday 1-3pm Introduction and Bash Agenda / Steve Deering (5 min) Document Status / Bob Hinden (5 min) Review of Action Items for Previous Meetings / Bob Hinden (5 min) Priority Field / Steve Deering (15 min) Conclusions/Results from Interim Meeting / (80 min) Meeting Summary / Bob Hinden (5 min) Revision to Provider Based Addressing / Bob Hinden (10 min) Analysis of GSE Proposal / Matt Crawford and others (25 min) IPv6 over Ethernet & FDDI / Matt Crawford (5 min) IPv6 over PPP / Dimitry Haskin (5 min) IPv6 over ARCNET and LocalTalk / Bob Hinden (5 min) The Use of End System Designators in IPv6 / Matt Thomas (5 min) Routing Goop and AAAA Records in DNS / Jim Bound (5 min) Numbering point-to-point and boundary links / John Stewart (5 min) ESD Pro and Con's / Thomas Narten (10 min) Friday 9-11:30am Conclusions/Results from Interim Meeting Continued / 60min Solicited Node Definition / Steve Deering (15 min) IPv6 Tunneling Spec and GRE / Steve Deering (15 min) Router Renumbering for IPv6 / Matt Crawford & Bob Hinden (15 min) Advertising site prefixes in RAs / Erik Nordmark (10 min) Prefix Notation / Bob Hinden (5 min) Who Are You / Matt Crawford (5 min) Inter-Domain Routing Status / Bob Hinden (5 min) ND Zero Lifetime advertisement issue / Thomas Narten (5 min) Advanced API Spec / Matt Thomas (5 min) Moving Base IPv6 Specs to Draft Standard / Steve Deering (5 min) Wrap Up and Action Items / Bob Hinden (5 min) Thursday 1-3pm -------------- Introduction and Bash Agenda / Steve Deering -------------------------------------------- Steve Deering introduced meeting. Asked for agenda changes. Request to add slot for Mobile IP and an SNMP issue Document Status / Bob Hinden ---------------------------- The following RFC's were published as Proposed Standard: - An IPv6 Provider-Based Unicast Address Format , RFC 2073 - RIPng for IPv6 , RFC 2080 The IESG Approved for Informational RFC: - Basic Socket Interface Extensions for IPv6 IETF Last Calls were completed for: - Generic Packet Tunneling in IPv6 Specification The IPng document editor submitted to IESG for IETF Last Call: - TCP and UDP over IPv6 Jumbograms Working Group Last Call were completed for: - Header Compression for IPv6 - IPv6 Router Alert Option These will be advance as soon as updated Internet Drafts are published based on the comments received during the last calls. Review of Action Items for Previous Meetings / Bob Hinden --------------------------------------------------------- Action Items from San Jose IETF ------------------------------- Steve Deering will write up description of proposed changes to Priority Field and send to IPng list. - OBE based on discussion on IPng list. Need to get closure at Memphis meeting. On Agenda for Memphis. Document editor will send email to IANA to add default hop limit of 64 parameter to IANA registry for IPv6 defaults. - Sent on 12/12/96. Can't find it on IANA web site. - Resent on 3/12/97. Thomas Narten owns getting "IPv6 over Token Ring" issues resolved. - Working group last call will be done when new Internet Draft is out. Document editor will do a working group last call on BSD API. Goal is to publish an informational RFC. - Sent on 12/10/96. Working group last call ended 12/24/96. A number of comments were received. Will advance to IESG once a new internet draft is available based on comments. - Done. Submitted to IESG, IESG approved as Informational RFC. Document editor will submit Tunneling Spec to IESG for proposed standard. - 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. - Steve Deering currently reviewing GRE documents and will respond to IESG last call. On Agenda for Memphis. Document editor will do a working group last call on Header Compression specification. - Sent on 12/10/96. Working group last call ended 12/24/96. Comments received from Thomas Narten. Once comments resolved (and new draft published) document editor will send to IESG. Hinden and Deering will propose to the mailing list that the ND solicited node address be changed to fit into a longer prefix - On Agenda for Memphis. Steve Deering expected to have a draft on "Multihoming / Source Address Selection" in early 1997. - Open. Document to do a working group last call on IPv6 Router Alert Option. - Last call sent on 12/17/96. Working group last call ended on 12/31/96. One minor comment received. Document editor will send to IESG once new ID is published. Chairs to generate a list of changes which are being considered for the base specifications. - Needs to be done. Hold an interim meeting to discuss the 8+8 proposal. - Done. Held on Feb 27, 28, 1997. Bob Hinden write internet draft on his Router and Networking Renumbering proposal. - Matt Crawford volunteered to write draft. - Done. Draft written and on Memphis agenda. Dimitry Haskin and Dave Katz to write a draft proposing adding an option to BGP4 to carry IPv6 interdomain routes. - Drafts written for BGP+ and BGP5. IDR discussed. Compromise discussions underway. Bob Hinden to add to the addressing architecture document prefix notation. - Work underway. Expect to have new draft by ID deadline. - Done. Draft published. Thomas Narten to include in next update of neighbor discovery a rule to silently drop non-DAD packets which use the unspecified address as the source of the packet. - Open Action Items from Interim Meeting --------------------------------- Minutes for Interim meeting, and meeting report / Bob Hinden - Done. Sent to IPng list and installed on IPng web site. "WhoAreYou" ICMP Message / Matt Crawford - Draft missed ID deadline. Sent to IPng list and on Memphis agenda. Modify Link Name Draft / Dan Harrington - Update underway. Synthesized AAAA Replies / Jim Bound , Mike O'Dell - Done. Jim Bound write draft. Revise Provider Based Addressing Architecture / Mike O'Dell and Bob Hinden - Work started. Proposal on Memphis agenda. Unique ID's (ESD's) Assignment / Mike O'Dell, Allison Mankin, Matt Thomas - Done. Matt Thomas submitted draft. On agenda. Experimental Addresses Rewrite: Bob Hinden - Waiting for Provider Unicast Formats to settle a bit more. IPoverEthernet/FDDI / Matt Crawford - Done. Internet Draft published. IPoverPPP / Dimitry Haskin - Done. Internet Draft published. Lessons from meeting / Matt Crawford, Allison Mankin, Thomas Narten, John Stewart, Lixia Zhang - Done. Internet Draft published. Discussion on agenda. Priority Field / Steve Deering ------------------------------ Discussion on mailing list, but did not reach consensus. Current proposal is: - Declare that 4 bits of Priority are rewritable by routers/ISPs for private purposes (and exclude from authentication header). - Priority bits have no significance to receivers - Convention: Sender sets low order bit to mean interactive traffic. o Delay more important than throughput o Suggests that routers/ISPs use other bits before touching the "interactive bit". o Affects queuing only, not routing (since re-writable). After email discussion Deering still thinks that proposal is correct. Charlie Perkins: If left undefined and people do use them, it might be hard to define them later. Nordmark: Could anyone modify in transit? Yes. Narten: How many bits do router vendors want? Also, thinks it is important to not have interactive bit rewritten to preserve function. John Stewart: Thinks one bit is enough for interactive traffic, but more bits will be needed for additional services. Thinks making bits an integer field instead of individual bits would be better. IPSEC had proposed not including the whole first four bytes of the IPv6 header from authentication. This is in the latest AH draft. Would give us more flexibility. John Stewart: If we define now, would preclude different usage in future. Nordmark: Should define what host does to these bits when sending, and how it should handle these bits when receiving. Need to do this first. Mike O'Dell, likes the proposal. Thinks it is best he had heard in discussion. Changing version field will break header compression. Matt C. Good to define default action for hosts now, routers could use them differently later. Need this to define application behavior. Deering took poll. More were in favor. Group will go forward with this proposal in next version of base IPng specification. Important to make sure AH is consistent. First 32 bits of header should not be included in authentication computation. Conclusions/Results from Interim Meeting ---------------------------------------- Meeting Summary / Bob Hinden ---------------------------- Deering talked. Showed table of results from interim meeting. Summarized into the following table: Legend: X = do not adopt Y = adopt * = needs more study X Rewriting by routers X Name for Sites & Mapping to/from RG * ESD's Y RG structure * PCB Lookup rules X Pseudo checksum rules Y 8byte node ID Y Two faced DNS for site local Y Resolve DNS via ICMP "Who Are You" Y DNS response synthesis * Auto-Injection of prefixes into sites Y Inter-provider partition healing protocol(s) * Use only site-local prefixes for intra-site communication * How much of address is AH * Flow identification change * SA Ident change Shows which items were agreed to do, not to do, and which need more study. Revision to Provider Based Addressing / Bob Hinden -------------------------------------------------- New draft will be called "Aggregation-Based Unicast Address Formats". This was an output of the Interim meeting. This will replace RFC-2073 "An IPv6 Provider Based Unicast Address Format" Goal is to provide additional flexibility based on O'Dell GSE Draft. Changes include: - Remove Registry field - Base Design around Large Structures Structures _______________ _______________ / \+--------------+/ \ ( P1 ) +----+ ( P3 ) +\_______________/ | |----+\_______________/ | +--| X | | _______________ / | |-+ _______________ +/ \+ +-+--+ \ / \ ( P2 ) / \ +( P4 ) \_______________/ / \ \_______________/ | / \ | | | / | | | | / | | | _|_ _/_ _|_ _|_ _|_ / \ / \ / \ / \ / \ ( S.A ) ( S.B ) ( P5 ) ( S.D ) ( P6 ) \___/ \___/ \___/ \___/ \___/ | / \ _|_ _/_ \ ___ / \ / \ +-/ \ ( S.E ) ( S.F ) ( S.G ) \___/ \___/ \___/ The aggregation based address format is designed to support both long haul providers (shown as P1, P2, P3, and P4), interchanges (shown as X ), multiple levels of subscribers (shown as S.x) and providers (shown at P5 and P6). Interchanges (unlike current NAP, FIX, etc. connection points) will allocate IPv6 addresses. Providers who connect to these interchanges will also subscribe for long haul service from one or more long haul providers and achieve a certain degree of addressing independence from long haul transit providers. Format | 3 | 13 | 32 bits | 16 bits | 64 bits | +---+-------+---------------+-----------+-----------------------+ |010| TLA | NLA* | Subnet | Interface ID | +---+-------+---------------+-----------+-----------------------+ <-----Public Topology-------> Site <-----------> Topology <--Interface Identifier-> Fields - FP Format Prefix (010) - TLA Top Level Aggregator - NLA* Next Level Aggregator(s) - SUBNET Site Specific Topology - INTERFACE ID Interface Identifier Top Level Aggregator - Top Level in Addressing Hierarchy - Assigned to Organizations providing Public Transit Topology o Not to Private Transit Topology - Supports 2^^13 TLA's (8K) o Additional available by using another FP - IANA Assigns Blocks to Registries o Registries assign to TLA's o Registries get more from IANA Next Level Aggregator - Used by TLA's to o Create TLA Hierarchy o Identify Sites - TLA's may support NLA's in their own Site ID space - NLA's may support NLA's in their... - Works exactly like CIDR delegation - TLA's assume registry duties for NLA's NLA* +-----+------------------+--------+-----------------+ |NLA1 | Site | Subnet | Interface ID | +-----+------------------+--------+-----------------+ +-----+------------+--------+-----------------+ |NLA2 | Site | Subnet | Interface ID | +-----+------------+--------+-----------------+ +-----+------+--------+-----------------+ |NLA3 | Site | Subnet | Interface ID | +-----+------+--------+-----------------+ Proposal was generally well accepted. Some discussion about fixed boundaries in these addresses, particularly about the TLA boundary. This was clarified that it was only there for address allocation and was not visible by the routing system. Bob Hinden will write a internet draft for "Aggregation-Based Unicast Address Formats". Analysis of GSE Proposal / Matt Crawford and others ---------------------------------------------------- Most topics will be outcome of PAL1, some were the result of additional analysis. Motivation for GSE - Renumbering must happen to achieve and maintain the necessary aggregation to keep routing computation feasible. o Make intra-site communication impervious to global renumbering o Make renumbering easier to do - Put the routing cost of multi-homing onto the parties involved. GSE Mechanisms - Conceal global-scope prefixes from the sites' interiors. o Insert source prefix at exit/remove destination prefix at entrance - Fixed boundaries in addresses - Modifications to checksum, PCB/SA lookup rules - Globally unique identifiers for nodes o DNS magic - Two-faced DNS - AAAA synthesis from parts - AAAA synthesis from parts - RG upward indirection - Multiple providers set up fallback tunnels to create the illusion that failed links are up o Hole-punching" is confined to consenting parties. Major Difficulties - Due to host ignorance of prefixes o New failure modes due to RG not covered by checksum o Can't construct source routes (in general). o Hosts can't influence traffic handling by source address selection. - Interior routing fluctuations cause source address to thrash o Any node that is a tunnel endpoint must act as a border router. - Due to DNS modifications o Delegation problem: the one who holds your glue is not the one who changes your prefix. - No visible solutions o Two-faces DNS is required - Might be solvable - Due to source address rewriting o Multicast packets duplicated at multiple site exits. Recommendations - Do not hide the global prefixes from the interior nodes. - There has to be an overlap period (on the order of days to weeks) during prefix reassignments. - Define boundaries in addresses o Between global and site topology o Between routing and node designator - Address architecture must be improved for better aggregation. - Using site-local addresses can help quite a lot o Work on two faced DNS (the alternative is address selection rules for hosts) - Globally unique end-system designators have potential uses o But aren't a panacea. - The next address architecture document should accommodate an 8 byte unique ESD. o Candidate: IEEE EUI-64. Question: what does "accommodate" mean? Does it mean require requiring globally unique now. Answer: Yes. Implications - Need to work on Two-faced DNS - Need to study coordination between renumbering and updating DNS delegations - Root DNS servers at fixed addresses, globally host-routed? - Hosts will do source address selection, even if only by default. - Boundaries in global addresses facilitate the use of site-local addresses. Questions: Should we also work on source selection algorithms? Yes, we should be comparing the two approaches. O'Dell raised difficulty with scaling when hosts have many addresses. Doesn't think this will scale. Do the recommendations mean that I can't use prefix ::1? Yes, that would not be allowed. - Starting off a connection with site-local addresses may become inconvenient if one end later goes mobile off-site o Could some hosts simply not have site-local addresses? - Globally unique ESD's preclude routing prefixes of 64 < length < 128 o Or do they? If you have an aligned blocks of ESD's - What's the ESD of an anycast address? Comment that Anycast do not need globally unique, but need ESD which do not conflict with any real ESD. Question and discussion about stability of dialin assigned addresses. Lixa Z: Question about what it means to require global unique ESD's. Comment about getting more feedback from DNS "experts". Agreement we need more overlook. Need more coordination. M. Ohta: Asked why did we look at only rewriting destination locator (based on his proposal of about six months ago). Wants to be able to rewrite destination RG. Could preserve original address in source route header. IPv6 over Ethernet & FDDI / Matt Crawford ----------------------------------------- Changes to accommodate ESD's - Prefix for stateless auto-config must be /64 - Auto-config address token is EUI64 - Link-local address token is EUI64 - EUI-64 is derived from MAC address o 00--8-55-12-34-56 -> 0008:55FF:FE12:3456 o http://standards.ieee.org/db/oui/tutorials/EUI64.html IPv6 over PPP / Dimitry Haskin ------------------------------ Change to make PPP support 64bit interface ID. Now reserves this size token. No changes to date to accommodate global token. Pending outcome of global ESD issue. IPv6 over ARCNET and Localtalk / Bob Hinden ------------------------------------------- Hinden mentioned both ARCNET and local talk do not have IEEE addresses in hardware and would need some mechanism to get global identifiers. The Use of End System Designators in IPv6 ----------------------------------------- IEEE/ANSI EUI Formats - EUI-64 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | | | | | | | | | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ <---- company_id -------><-------------vendor supplied id ------> - IEEE 802 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | | | | | F | F | F | E | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ <------- OUI ---------> <--- vendor id --------> - FiberChannel +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | | | | | ? | | | | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ <---- company_id -------> <-------vendor supplied id --------> Hard problem is what if you do not have an IEEE address in system. IANA EUI Formats - IPv4 Address +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 5 | E | 1 | 0 | C | 7 | 5 | 1 | D | C | 9 | D | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ <---- company_id -------> <-IPv4 Addr (199.81.220.157) ---> - ASN +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 5 | E | 2 | 0 | | | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ <---- company_id -------> <--- ASN -------><--- Assigned -> o PPP servers could use IANA OUI and IPV4 address. - Can not use private use IPv4 addresses o Use company ID and Autonomous System number (ASN) Comment companies do not normally get ASN numbers. Only assigned to organizations who are multihomed. Random ESD Format +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | 2 | | | | | | | | | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ <---> <-------------------------------------------------------> 60 Random bits <---> Fixed 4 bits (locally administrated address space which is not used by IEEE IPv4 addresses in IPv6 - IPv4 Compatible +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ <---- company_id -------> <------ IPv4 Address -----------> - IPv4 Mapped +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | F | F | F | F | | | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ <---- company_id -------> <------ IPv4 Address -----------> o IPv4 compatible are OK o IPv4 mapped have a problem because conflicts with other assignments. ESD Pro and Con's / Thomas Narten --------------------------------- Main Benefit - Automatic/transparent deliver of packet to transport endpoint, even if source or destination "Routing Stuff" changes (see below) - Transport endpoints ar TCP, UDP, IPSEC, etc. - Facilitates retroactive fix up of Routing Stuff o Mobile nodes says "I just moved" here is my new address" o During renumbering: "here is my new preferred address" o Required authentication prior to changing "routing stuff" Cons - Automatic delivery defined above simplifies implementation, but does NOT provide new functionality: o Functionality required: IPv6 destination option that says "use this address when demultiplexing instead of address in IPv6 header" o IPSEC AH provides assurance that option is not a hijack attempt o Basic idea has been proposed before - Context identifier parameter" in Huitema's "Multihomed TCP" draft. - "Source identifier Option" in Bound/Roque "IPv6 Anycasting Service" draft. - ESD uniqueness requirement adds complexity o Intruders guarantee that ESD can not be assumed unique, even if we design them to be o New denial-of-service attacks possible: - Intruder host "borrows" ESD of dilbert.foo.com, opens TCP connection to www.bar.com - Real dilbert.foo.com opens TCP connection to www.bar.com (using same port number) - Packets from both connections delivered to same TCP endpoint on web server - Second connection (real Dilbert) "loses" - Can't defend against without requiring authentication. o Need way dealing with devices that have no IEEE MAC address. Solution possible, but may require some manual configuration. o Accidential misdelivery of packet to wrong machine that is using same ESD may trigger dangerous error responses. o Disallows small subnets o Anycast address need ESD that doesn't conflict with existing ESD (solutions possible, misconfiguration possible) My opinion - Key issues: compare benefits against cost - There are real costs, some which are not fully understood - Supposed benefits oversold - Considered big picture, benefits not worth the cost. ---------------------------------------------------- Friday 9-11:30am ---------------------------------------------------- Mobile IP / Dave Johnson ------------------------ Mobile IPv6 - Allows transparent roaming of IPv6 mobile nodes o Routing to mobile node regardless of its current point of attachment to the Internet o Mobile node is always addressable by its "home agent" - High-level overview of operation o Care-of addresses from IPv6 address auto-configuration o Mobile node sends its own Binding Updates o Used for correspondent nodes and home registration o Nodes cache binding in a Binding Cache o Correspondents route own packets directly to mobile node - Current draft is 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 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 addresses o Mobile node tries again with one of these addresses - Can't do this in Mobile IPv6 since no broadcast in IPv6 Home Agent Discovery Proposal #1 - To register when don't know own home agent address o Mobile node sends "home agent discovery" packet to home network router "anycast" address o Probably an ICMP message o By IPv6, received by one border router on home network o Router receiving packet multicasts "home agent discovery" into home network to "all home agents group" o Home agent returns reply with its IP address to mobile node o Mobile node registers to that IP address - Implementation would be required in ALL IPv6 routers Proposal #2 - Define "home agent anycast" address o Prefix defines which subnet o Bottom part could be all-ones (instead of all-zeros) - For home agent discovery o Mobile node sends request to home agent anycast address for home network o Request answered home agent, giving unicast address o Mobile node registers to that IP address - Implementation of this would be required in ALL IPv6 routers Comments, Please - Need feedback from IPng working group - Send to mobile-ip@smallworks.com (mobile ip mailing list) Topologically Correct Addressing - Packets sent to a mobile node: o Source address = correspondent node address o Destination address = mobile node care-of address o Routing header = mobile node home address o (Problem: size of Routing header in every packet) - 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 of these packets! Proposed Solution: Source Address Remapping - Mobile node uses care-of-address as source address.. But only while packet on its way tot he destination node - At the sender: o Sender builds packet using home address o Then substitute care-of address as source o Makes packet source address topologically correct - At the receiver (only the end destination node) 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 routers Source Addressing Remapping Method #1 - Two source addresses in "every" packet o Carry real source address in a destination option o If present, receiver substitutes into IP header before passing it to the transport layer o Used for receipt of this packet only o Option creates no state in the receiver o Option does not affect any routing from receiver o Option is authenticated if packet itself is authenticated o Otherwise, no extra authentication needed. SAR, Method #2 - One one source address (the care-of address) in packet o Also a bit in every packet: "source is a care-of-address" o Bit probably encoded by presence/absence of a destination option o Could also be bit in header or bit in source address o Receiver caches mappings o If bit set in received packet and no cache entry: - Receiver request mapping form care-of address - Reply MUST be authenticated - Receiver saves original packet and processes after reply - Request/reply is probably ICMP Some discussion. Will be discussed on mailing list. Synthesis of DNS aAA and RG Resource Records / Jim Bound -------------------------------------------------------- Motivation - IPng w..g PAL1 interim meeting on alternative addressing architecture - Add connotation of location and identifier to DNS Resource Record "syntax" for future use. - Avoid alteration to DNS protocol and APIs for IPv6 - Adjunct to other Interim meeting action items - Determine initial affect to applications and DNS syntax and processing. Processing Model - No change to the DNS protocol - Client resolve still requests AAAA records in query (e.g., gethostbyname2() ), using ESD address - DNS server synthesizes from ESD address an AAAA record for each RG record associated with an aAA ESD - DNS returns in query response one AAAA record for each RG + aAA pair synthesized at the DNS server. - Transparent to client applications during the query operations. New aAA and RG Types foo.bar.com IN aAA aa:bb:cc:dd:ee:ff:01 /* ESD */ IN RG 5f09::/?? IN RG 5f08::/?? To be Determined - RG and ESD length, semantics, and uniqueness. - Processing cached AAAA records for resolvers - Affects RFC 1886 and DHCPv6 extensions - Dynamic updates to DNS must deal with granularity of aAA and RG records - Reverse DNS processing is TBD. Numbering point-to-point and boundary links / John Stewart ---------------------------------------------------------- If global ESD's, mask lengths will be either up to 64 or 128. Nothing in between. Notion that like in IPv4, with current form of interconnects, some global RG would have to be assigned to interconnects (e.g., NAP, etc.). Solicited Node Definition / Steve Deering ----------------------------------------- Issue was wanting to avoid a many to one mapping to Ethernet multicast addresses. Don't want to have collisions. L2 filtering, etc. Proposal was to allocate IPv6 multicast addresses to not have multicast group > 32bits. ND solicited addresses conflict with this approach. Currently: FF02::1:xxxx:xxxx Proposes: FF02::1:FFxx:xxxx Working group agreed adopt change. Will go into Addressing Arch and ND drafts. New addressing architecture w/ new solicited node definition soon because ND and IPoverFoo need to copy definitions. IPv6 Tunneling Spec and GRE / Steve Deering ------------------------------------------- IPv6 tunneling spec has gone through IPng last call and IETF last call twice. IESG want to form a working group to resolve the number of differently tunneling specs. GRE IPv4 specs submission has caused IESG to take a deeper look. One of the original IPng working group requirements was to define IPv6 tunneling. We only want one tunneling specification for IPv6. Alex Conta: GRE specification is not ready for an IPv4 specification because it is not complete. It does not cover IPv6 tunneling as currently written. Specs are not compete. Jeff Burgen / AD: IESG has decided to look at tunneling overall. Will be resolved to quickly. The new group be in the internet area. The AD's will scope work. Doesn't want to drag on a long time. Deering suggested that IPv6 need not be in that charter of this group. IPv6 already has one specification. IPng Chairs will write strong note to IESG requesting IPv6 not be included in this new working group and concern about the delay to existing IPv6 work. Router Renumbering for IPv6 / Matt Crawford ------------------------------------------- Internet draft written by Matt Crawford based on presentation at previous IETF by Bob Hinden Router Renumbering (RR) Packet contains - Anti-replay fields - Zero or more Prefix Control Operations (PCOs), each of which has: [missing remainder of slide] RR Message Processing - Check for valid sequence number o Optionally check for valid replay - Verify authentication - For each PCO o For each interface - For each address and/or Prefix on that interface o Compatible to MatchPrefix, if it matches, - Preform operation - Do not create duplicate prefixes Why not use SNMP - Multicast - Renumbering will be "more fundamental" than other management functions - Security Why not use IPSEC for Authentication - SA is looked up by SPI + destination address, but destination addresses are changing during RR. - No dynamic key negotiation protocol for multicast destination (correct me if I am wrong) Based on discussion will change draft to HMAC SHA1 Jim Bound mentioned that new docs need to require method for key selection. Open Issues - More than 1 match on a single interface o repeat operation on each match - Require duplicate suppression, or advise against construction of non-idempotent combinations? - All-routers multicast address is currently only defined at node- and link-local scope. Site- or org-scope would also be useful. - Asymmetric authentication scheme might be more appealing - No attempt to distribute information for RA fields other than Prefix information (e.g., hop limit.) Nordmark: Thinks this is a good idea. We should be careful to not include things which could break things. Would be better to make it harder to keep things from breaking. Might require more elaborate mechanisms and/or procedures. Need to be careful to make it harder. Next steps to update draft to use HMAC and finish missing sections. Think about Nordmark suggestions. Advertising site prefixes in RAs / Erik Nordmark ------------------------------------------------ Announcing Site Prefixes in Router Advertisements - Goals: o Limit effect of renumbering by ensuring that traffic local to the site use site-local addresses o Do this without requiring a two-faced DNS (i.e., no site local in the DNS) - Proposal o Advise the global prefixes (w/ lifetimes) for the site in ND messages o The host use this info to maintain a list of the current site prefixes o The host resolver (gethostbyname function) checks against list of prefixes after resolving the name. o When one of the addresses retrieves from the DNS matches one of the site prefixes (i.e., the first N bits match) then add the corresponding site-local address to the front.... [slides showing how to encode in prefix advertisements] [missing remainder] Prefix Notation / Bob Hinden ---------------------------- Prefix notations was added to current draft of addressing architecture document. General form proposed is: ipv6-address / prefix-length Examples: 12AB:0000:0000:CD30:0000:0000:0000:0000/60 12AB::CD30:0:0:0:0/60 12AB:0:0:CD30::/60 12AB:0:0:CD30/60 It included a notation (shown in last example) to not require "::" at the end of the prefix. Implied left justifying prefix and zero fill remainder. General consensus of group was that his added complexity and to not support this (e.g., require "::"). Who Are You / Matt Crawford (5 min) ---------------------------------------------------- Motivation - GSE would have made it difficult to have reverse lookup domains. - IN=ADDR.ARPA poorly maintained, will IP6.INT be better. - Maintenance of delegations will be more difficult in the expected frequent-renumbering environment of "THE FUTURE". - For access control, or even logging, IP6.INT provides nothing but a hint anyway History - Experimental RFC by W. Simpson, "ICMP Domain Name Messages", RFC 1788. Format of Packet - ICMP Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time-To-Live | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NameLen | FQDN ... | +-+-+-+-+-+-+-+-+ + / / + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA1 - FQDN Query (more pronouncably known as Who-Are- You or WRU). TBA2 - FQDN Reply (possibly to be known as Sam-I-Am). Code For FQDN Query, always zero. For FQDN Reply: 0 Indicates that the Time-To-Live field is meaningful 1 Indicates that the responding node cannot provide a meaningful TTL for its Address-to-FQDN association. Checksum The ICMPv6 checksum. ID A 16-bit field to aid in matching replies and requests. Its value is chosen by the querier and copied from a Request to a Reply by the responder. Cookie An opaque 64-bit field to aid in avoiding spoofing. Its value is chosen by the querier and copied from a Request to a Reply by the responder. Time-To-Live The number of seconds that the name may be cached. For compatibility with DNS [1035], this is a 32-bit signed, 2's-complement number, which must not be negative. NameLen The length in octets of the FQDN, as an 8-bit unsigned integer. FQDN The fully-qualified domain name of the responder, as a sequence of NameLen US-ASCII octets, with periods between the components. The last three fields (Time-To-Live, NameLen and FQDN) are not present in the FQDN Query. Steve Deering: Wondered about supporting multiple names in packet? Alex Conta: How different form DNS? Simpler fewer options/etc. Intended only for reverse lookups. Usage and Issues - The internet could easily get clogged with these messages. Therefore, this could be a back-end to DNS servers, which would catch the answers. o What's a good TTL when the responder can't provide one? o What about a timeout for negative caching? Question about viability of current reverse lookup database. Questioner thought premise was untrue. Thought was was getting better. Response was that with renumbering this would get even harder to maintain. This mechanism does not require manual configuration of a database. Important to keep this simple. Features - PLUS: Routing system takes the place of IP6.INT delegation o Always current - PLUS" A Meaningful TTL is usually available from Autoconf. or DHCP. - MINUS: Target must be up and reachable to do a lookup o But is it meaningful to say a certain FQDN is associate with an address when it isn't. Comment. Dialin users do not know their name. DHCP could tell host their domain name when they get the address. Could also return with a empty name length. What about negative caching? Inter-Domain Routing Status / Bob Hinden ---------------------------------------- Covered in document status. ND Zero Lifetime advertisement issue / Thomas Narten ---------------------------------------------------- Denial-of-Service vulnerability in Stateless Addrconf Attack: - Intruder connects to local link (remote access not sufficient) - Listen for RAs, determine what prefixes are in active use - Send out a single RA, advertise in-use prefix(es) with lifetime of zero Consequence: - Receiving host immediately invalidates address(es) formed via stateless autoconf for the specified prefix(es). - Host immediately terminates all transport layer connections (addresses) in use no longer exists). - Every host acts on received RA, entire network effectively brought down. - Subsequent RA containing correct (no-zero) Lifetime does not undo damage. One Possible Solution: - When a prefix lifetime reaches zero, host enters DELAY state, doesn't actually invalidate for two additional hours. - Receipt of subsequent lifetime value > zero cancels DELAY state - While in DELAY state, silently ignore additional Lifetime values of zero (for receiving prefixes) - Result: Intruder's zero Lifetime advertisement effectively ignored; subsequent RAs from real router cancel intruders RA before DELAY state expires. Question for WG? - Is this significant threat? - Is the cost of fixing vulnerability small enough to justify. - Should we fix problem? There are plenty of denial-of-service vulnerabilities already: Why fix this one given the others? - Other attacks must target individual hosts, one at a time. - Other attacks disrupt first-hop path, not the hosts themselves. o When intruder leaves, path is restored; host may be able to continue. o TCP connections break on a timeout, which takes several minutes o Doing long-term damage require long-term presence of intruder (increasing likelihood they will be discovered). o Vulnerabilities in IPv6 are analogous to those in IPv4 (i.e., IPv6 doesn't make problem worse than what we have today). - In contract to IPv4, IPv6 zero lifetime attack: o Single packet is processed by all hosts in the same way. o Host actively terminates all existing transport connections immediately, no recovery possible. o IPv4 has nothing like this; IPv6 has introduced a vulnerability not present in IPv4. Suggestion that before invalidating prefix, send a RS and see if RA is consistent with message which invalidated prefix. Discussion and additional suggestions. General consensus to fix vulnerability but there are issues with proposed mechanism. Author will propose to mailing list. Advanced API Spec / Matt Thomas ------------------------------- Any last comments, authors would like to issue working group last call. Document editor will do a working last call for Informational RFC. SNMP Issues / Margaret Forythe ------------------------------ Couple of issue with current MIB drafts and discuss solutions. IPv6 MIB Issues - Separate TCP/UDP tables for IPv4 and IPv6 - No way to represent an IP address in a MIB that can be ether IPv4 or IPv6. - Various Nit's o IP Routing table updates o IPv6IfIndex as index in TCP/UDP Tables Possible Solution(s) - Unified IP Address format - Single UDP &TCP Tables for IPv6 & IPv4 "connections" - Minor MIB cleanup Unified IP Address - Type/version in IP address type? - Octet string or OID? - SMI Change or Textual conv. o SMI change (new App. type) allows type discrimination in SNMP packet. o SMI change does not permit backwards compat. to current managers/agents. o SMI change may be politically difficult o Display hints in textual convention do not give info to mgr. unfamiliar w/ particular MIB. SMI App types do. UnifiedIPAddress::= textual convention DISPLAY HINT "X" (?) STATUS current DESCRIPTION "IP Address type for both IPv4 or IPv6 addresses. Particular type can be determined from length. Length of 4 = IPv4; 16 = IPv6. Addresses are stored in network byte order. IPv4 addresses should be displayed as with display hint "1d.:; IPv6 addresses as with "2x:"." SYNTAX OCTET STRING (SIZE (4 | 16)) SMI Applications Type - UnifiedIPAdress ::= [APPLICATION 7] IMPLICIT OCTET STRING (SIZE (4|16)) Will work with MIB author to resolve issues. When new drafts are out, IPng Document Editor will issue w.g. last call to move the to Experimental status. Destination Locator Rewrititing / Masataka Ohta ------------------------------------------------ Motivation Protocol Modifications - Don't checksum-protect destination locator - Modify routing header (w/ authentication) to Preserve the Original Locators - PCB lookup with Source and Destination ESDs (both Checksummed). Modifications to Routing Header - Add address[0] to contain the first destination address o Extra 16 byte in header - Copy, don't swap o Faster operation expected o Same level of security [slide showing change to pkt format] Comment: This looks like what Dave Johnson is proposing for mobile IP. Might be able to combine? Global ESD Proposal / Bob Hinden -------------------------------- Presented a proposal which would keep open the option for future transport protocols to use global ESD. Proposal was as follows: - Require all Interface ID be constructed using EUI-64 framework. Easy for both for devices which have hardware 48bit MAC's and with the use of the IANA or vendor specific prefix, easy for serial lines, tunnel interfaces, localtalk, etc. Only cost is use of 64bit ID's. - Part of EUI64 is a bit which says if the address has global scope (uniqueness). We require that bit be set correctly. EUI-64 which are built from hardware MAC will be global. Serial lines, tunnel end points, localtalk, etc. will not. - We do not make any change to current TCP/UDP connection identification, pseudo checksum, etc. Current transport protocols will treat all addresses as opaque 128bit quantities. - New transport protocols and/or research projects can tell if the destination with which they are about to communicate has an address with a global identifier when they get the results of a DNS lookup. If so, then can do what ever ESD magic they want. In practice many (most?) interface ID's will be global. This proposal would "keep the door open" for global ESDs but limit the impact now. The only cost now is requiring 64 bit interface ID and setting the global scope bit correctly. Considerable discussion resulted. Chairs polled the working group: 0 voted for global ESDs in IPv6 7 voted for no global ESD in IPv6 (e.g., keeping current interface ID behavior) 33 voted for proposal to use EUI-64 global/local bit to identify if interface ID is global. This was a rough consensus to adopt this approach. Will be added to addressing architecture document. --------------------------------------------------------------------------- ---------------------------------------------------------------------------