IPng Meeting Washington, DC IETF December 8-12, 1997 ---------------------- Chaired by Steve Deering (Cisco) and Robert Hinden (Ipsilon). Minutes taken and prepared by Robert Hinden. Agenda ------- MONDAY, December 8, 1997, 1530-1730, (Empire Room) Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) Document Status / R. Hinden (10 min) Status of moving base specs to Draft Standard / R. Hinden (5 min) TLA/NLA Assignment Rules Status / R. Hinden (15 min) Resolve Neighbor Discovery and Addr Conf issues / T. Narten (20 min) Interface Identifier Global Flag / S. Deering (10 min) Mobile IPv6 Status / D. Johnson (10 min) THURSDAY, December 11, 1997, 0900-1130, (Empire Room) IPv6/NBMA Status / G. Armitage (10 min) IPv6 over PVC ATM / K. Yamamoto (10 min) Router Renumbering / M. Crawford (20 min) DNS mappings / C. Huitema (20 min) IPv6 Name Lookups Through ICMP / M. Crawford (15 min) Reverse Address lookup in DNS for IPng / O. Gudmundsson (15 min) Gethostbyname update to RFC 2133 / B. Gilligan, J. Bound (10 min) Traceroute hop-by-hop option / A. Durand (10 min) ECN Bit Assignment / S. Floyd (20 min) FRIDAY, December 12, 1997, 0900-1130, (Empire Room) IGMP for IPv6 / S. Deering (15 min) Neighbor Discovery over Tunnels / S. Deering (20 min) IPv6 Transmission over IPv6/IPv4 Tunnels / A. Conta (10 min) Site prefixes in Neighbor Discovery / E. Nordmark (20 min) Router Alert / C. Partridge (10 min) VRRP for IPv6 / R. Hinden (15 min) DHCP vs. M & O Bits / Narten (10 min) IPv6 Addresses in URL's / Deering, Carpenter (10 min) Non-Corrosive Multi-Homing Idea / Matt Crawford --------------------------------------------------- MONDAY, December 8, 1997, 1530-1730, (Empire Room) --------------------------------------------------- Introduction / S. Deering Review Agenda / S. Deering -------------------------- Steve Deering introduced the meeting and reviewed the agenda. UNH Testing Report / Bill Lenharth ----------------------------------- Interoperability test session last week at UNH. First purely interoperability test session at UNH. First time to put routers into the test network. There were 10 hosts and 6 routers tested. 90% of the host implementations worked well as did 70% of router implementations. After work on site most of the problems discovered were "addressed". Both BGP4+ and RIPng routing protocols, including route redistribution, worked. Three long days of testing. Next test period is with Sun Connectathon in March. Both conformance and routing testing will be done. No IPSEC testing was done. Document Status / R. Hinden --------------------------- IETF Last Call completed for Proposed Standard - Generic Packet Tunneling in IPv6 Specification / Dec 96 (IESG Comments received 11/25/97, waiting for new ID) AD reported that this should resolved soon. - Transmission of IPv6 Packets over Ethernet Networks / Nov 97 (IESG: Resolve Global/Local bit setting issue) - Transmission of IPv6 Packets over FDDI Networks / Nov 97 (G/L) - IP Version 6 Addressing Architecture / Nov 97 (G/L) - An IPv6 Aggregatable Global Unicast Address Format / Nov 97 (comments from Registries) IETF Last Call completed for Experimental - IPv6 Testing Address Allocation / Nov 97 IETF Last Call completed for Informational - IPv6 Multicast Address Assignments / Nov 97 Submitted to IESG for Proposed Standard - IPv6 Router Alert Option (IESG returned, need new ID) - MIB for IPv6: ICMPv6 Group / Jun 97 - MIB for IPv6: TCP / Jun 97 - MIB for IPv6: Textual Conventions & General Group / Jun 97 - MIB for IPv6: UDP / Jun 97 - Transmission of IPv6 Packets over Token Ring Networks / Nov 97 (G/L) - IPv6 over PPP / Nov 97 (G/L) - IP Header Compression / Nov 97 Submitted to IESG for Informational - Advanced Sockets API for IPv6 / Jul 97 Submitted to IESG for BCP - TLA and NLA Assignment Rules / Nov 97 Status of moving base specs to Draft Standard / R. Hinden --------------------------------------------------------- BASE SPECS TO DRAFT - IPv6 Specification o MTU Issue Resolved (1280 octets) o New Draft Issued o Starting to Collect Implementation Info - ICMP o New Draft issued w/out IGMP messages o Starting to Collect Implementation Info - Path MTU Discovery o Starting to Collect Implementation Info Will be sending questionnaire about implementation info to the ipngwg list in next day or two. [Editors Note: Bill Lenharth of UNH, volunteered after to the session to help with this based on the testing being done at UNH. He will be contacting implementers.] TLA/NLA Assignment Rules Status / R. Hinden ------------------------------------------- TLA/NLA ASSIGNMENT RULES STATUS - Updated Draft based on IANA Comments o Added Established Provider Criteria, Registration Fee, and Auction for New Organizations - Submitted to IESG for BCP 11/11/97 - Considerable Controversy!!! - Waiting for IESG Direction on how to proceed Met with registry folks this morning about their concerns about TLA doc. Progress made, but nothing concrete to report yet. Will report again at Friday session. Resolve Neighbor Discovery and Addr Conf issues / T. Narten ----------------------------------------------------------- Talk about remaining issues with ND and Addr conf doc. Zero Lifetime denial of service attack - Bad guy sends out a single bogus Router Advertisement (RA) - RA contain prefix info option with Valid lifetime of zero - Host interprets RA to mean address is now invalid, stop using it immediately. - Upper layer protocols may stop working (e.g., all TCP connections break) This is not a hard requirement in spec but some implementations may do this] Not like other Denial of Service attacks - No comparable "hit and run" packet in IPv4 (or IPv6) as dangerous - Once upper layer have aborted open connections, no recovery is possible. - Problem must be fixed in IPv6 is to be no more vulnerable than IPv4 Proposal 1 - If received with Valid Lifetime > 2 hours or greater than lifetime in cache, process as before - Attempts to reduce the valid lifetime to value less than 2 hours and less than lifetime of cached entry require special processing. [pseudo code for algorithm] This proposal limits removing prefix to 2 hours units. Can't remove one in shorter time. Proposal 2 [from Erik Nordmark] - Avoid defining special mechanism to handle this one specific denial of service attack. - Rely on robustness of transport protocol to limit impact of zero lifetime denial of service attack. - Already have many denial of service attacks (both IPv4 and IPv6) that cause packets to be blackholed. - Transports (e.g., TCP) are robust in such cases by continuing to retransmit (e.g., not allowing ICMP destination unreachable to terminate connection) - IP layer continues processing zero lifetime as specified inRFC1971, but transport layer is not required to terminate connections using addresses that become invalid. - IP layer on host would blackhole packets form invalid source address (i.e., no violation of existing spec). Comments that this proposal, is just focused on TCP. Problem is worse, it affects all other transports, SNMP, etc. Everyone that the machine uses addresses. Attack is much worse than just TCP. Suggestion that we should do both. They are not really in conflict. Could also use authenticated router advertisements. Comment that this is not normal behavior for TCP. Should kill all state with TCP and other transports. R. Hinden suggested that lifetimes less than two hours should be accepted only if packet was authenticated. This allows for finer grained control (e.g., less that two hours) in environments that need it and two hour everywhere else. Suggestion was made for Proposal 1 unless packet was authenticated. If authenticated, then accept lifetime less than 2 hours. Strong consensus to adopt this proposal. DHCP-specific bits in Router Advertisement - "M" bit indicates DHCP should be used to obtain addressing information. - "O" bit indicates DHCP should be used to obtain other (i.e., non-addressing) information. Proposal - Do away with "O" bit - Single bit would say "do" or "don't" use DHCP Rational - Separate bits complicates protocol - Having "O" bit raises issue of what to do if DHCP server returns DHCP option that "O" bit says shouldn't be obtained - Benefit unclear. Behavior of the two bits can be obtained by having DHCP server decide what information it wants to give out. J. Bound thinks we only need one bit. All that stateless is for is addresses and link parameters. Critical parts of IPv6 is to make renumbering work. Important part of this is dynamic DNS. Thinks that the router should only control the address allocation. Rest of configuration is independent of what router can supply. DHCP w.g. does not have a strong feeling either way. Matt C. suggested that these bits tell the host when it is completely configured. If both bits are zero it is done. Otherwise it needs to go to DHCP to get additional information. It should not come up until it has all information. Narten suggest wait to come to closure on this topic until after discussed by DHCP w.g. IPng will continue this in the Friday session. Default value for valid lifetime in Prefix information options: - RFC1970 says default preferred lifetime is 7 days - RFC 1970 says default valid lifetime is infinity - Value of infinity problematic: o Suppose system administrator decides to timeout prefix o Subsequent Router advertisements advertise small lifetimes, eventually going to zero. o Lifetime of zero must be advertised forever, to be sure nodes that are disconnected from the link receive updated value on reconnection. o Danger that any prefix advertised with infinite Lifetime will be hard to completely purge from network. - Propose setting default value to 30 days o System administrator is free to change this value; 30 days is the default value in the absence of input from system administrator o Having an address without properly functioning router is of limited benefit; if router is functioning properly, it will be sending out proper Prefix Advertisement options. Consensus to adopt this proposal. Summary of Open Issues - Protection from zero life denial of service attacks. - If Proposal 1, is 2 hours the right time? No objections to 2 hours. [Editor's note: Remaining issue to be resolved at Thursday w.g. session before moving this to draft standard] Mobile IPv6 Status / D. Johnson ------------------------------- High-level overview of operation: - Care-of addresses from IPv6 address autoconfiguration - Mobile node sends its own Binding Updates - Used for correspondent nodes and home registration - Nodes cache bindings in a Binding Cache - Correspondents route own packets directly to mobile node Current spec is draft-ietf-mobileip-ipv6-04.txt One implementation done so far (CMU). Other implementations in progress? Editorial Changes: - Added a statement of some non-goals of the protocol in Section 1. - Added definition for home link and home subnet prefix, replacing the old term home subnet. - The new terms foreign link and foreign subnet prefix likewise replace the old term foreign subnet. - Moved the Comparison with Mobile IP for IPv4 section to earlier in the document (now Section 2) - Added specific in Section 4 listing the fields conceptually present in each Binding Cache entry and in each Binding Update List entry. - Added Section 12 on IANA Considerations. - Replaced the description of specification language keywords, MUST, MAY, SHOULD, etc., with the new standard reference to RFC 2119. - Updated the References to point to the most recent version of each cited RFC or Internet-Draft. Binding Update Option Changes: - Increased the Lifetime field from 16 bits to 32 bits, to allow consistency with other lifetime values used in IPv6. - Replaced the Home Link-Local Address Present (L) bit and the Home Link-Local Address field with a new mechanism implemented by the ID Length field: o Home agent becomes home agent for all on-link home addresses with this interface ID o Proxies for mobile node in Neighbor Discovery with this ID o If ID Length is 0, only use single specific home address o Mobile node may send separate Binding Updates for each ID if different - Change sending of Binding Update to a mobile node's previous default router from SHOULD to MAY. - Clarified handling for packets addressed to a mobile node's link-local address or site-local address: o Data packets are not forwarded to the mobile node while away from home. o Home agent returns ICMP Destination Unreachable, Code 3, for any received. o Home agent continues to defend for Neighbor Discovery. o As the use of link-local addresses or site-local addresses evolves over time in IPv6, this disposition of such packets may need to change, however. Binding Update Option Format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|C| Reserved| ID Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Care-of Address + | (only present if C bit set) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Binding Acknowledgment Option Changes: - Changed the Option Type value to now ignore rather than returning an ICMP error if not recognized. - Increased the Lifetime field from 16 bits to 32 bits. - Increased the Refresh field from 16 bits to 32 bits. Binding Acknowledgment Option Format: +-+-+-+-+-+-+-+-+ | Option Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Length | Status | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Binding Request Option Changes: - Changed the Option Type value to now ignore rather than returning an ICMP error if not recognized. - Added a discussion of sending Binding Requests in Section 7.6. - Added a discussion of receiving Binding Requests in Section 9.11. Binding Request Option Format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home Address Option Changes: - Added details of how and when Home Address option is added to a packet when sending: o TCP/UDP/etc. generates packet as normal. o In IP (Mobile IP), if the Source Address is not home address, just send packet normally. o Otherwise, insert a Home Address option: + Copy Home Address field from Source Address + Change the Source Address to care-of address + Must be performed before outgoing IPsec processing, if any - Added details for inbound IPsec processing: o Must be performed before any packet modifications for Home Address option processing. Home Address Option Format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Comments, Please: - We need feedback/agreement from IPng Working Group - Please send e-mail comments to Mobile IP mailing list: mobile-ip@SmallWorks.COM - Comments can also be sent to: o Dave Johnson, dbj@cs.cmu.edu o Charlie Perkins, cperkins@eng.sun.com Wants processing of home address option on the receive side to be required by all receivers. Not just the ones that implement Mobile-IPv6. Need Home agents anycast address, and option code for bridging xxx, yyy, zzzz options. IPng chairs will figure out how to do these allocations. Need to reserve a group of interface identifiers to be used as anycast addresses. Chairs promised to resolve issue this week. Interface Identifier Global Flag / S. Deering --------------------------------------------- [Figure showing how EUI-64 based interface identifiers are created from IEEE 48bit MAC addresses] Current algorithm for doing this fabrication inverts the state of the "Global/Local" bit. Becomes "1" if global, "0" if local. Reason for inversion is to make it easier on links that do not have hardware tokens, such as dialup links, tunnels, etc.to set this bit correctly. Comment on mailing list that this is complex and the bit should not be inverted. IESG sent it back to the working group to review earlier decision. Matt Crawford: Arguments in favor of inverting the bit. Makes it easier to recognize vendor type code when looking at wire. We are corrupting the use of EUI64 format. Would be better to not change bit. KRE: Matt's comment is correct, but he came to the wrong conclusion. Packet trace will still have real MAC addresses at front of frame. Thinks a better way to do this would be to XOR with different value to make it look very different. M. Wasserman: Thinks we should have a fixed prefix for manually assigned interface identifiers. Brian C: Thinks current approach will make things harder for maintenance technicians. C. Huitema: Thinks the problem is reversed. Real problem is that managers will assign bit's incorrectly. Computers will not have a problem. KRE: Also disagrees with Brian C. Thinks we should leave the way it is. A. Durand: In the ten implementations he has seen nine out of ten do it correctly, and would like to keep it as it is. S. Deering took poll. 1) Keep it as is, 2) eliminate inversion, 3) KRE proposal Rough consensus to keep things the way they are now. Document editor will report w.g. consensus to area director. [Editor's note: done as of 12/29/97] ------------------------------------------------------------ THURSDAY, December 11, 1997, 0900-1130, (Empire Room) ------------------------------------------------------------ IPv6/NBMA Status / G. Armitage ------------------------------ ION w.g. summary relevant for IPng Since last meeting - In Munich, much confusion - Action items o Generalize the architecture - ATM Split document into two o draft-ietf-ion-ipv6-oo.txt o draft-ietf-ion-ipv6-atm-00.txt - Other IPv6 related drafts o draft-conta-ion-ipv6-fr-00.txt o draft-conta-ion-ipv6-ind-00.txt General Architecture - Assume general NBMA "cloud" o Capable of p-p links, pt-mpt links, may/may not native multicast - MBMA could be ATM, Frame Relay, IPv4, ... - MARS? NHRP? Major New Item / Shortcut suppression - Request in Munich for host controlled shortcut suppression - How to convey this indication in-band? - Original default, discover shortcut whenever a "flow" is detected - Need indication of "flows" that should not have this default action applied - Proposal for broad interpretation of flow label field Interpretation of Flow Label - Flow label == 0 o Apply default IPv6/NBMA flow-detection and short cut discovery - Flow label != 0 o Do not apply IPv6/NBMA flow-detection and shortcut discovery by default - Support whatever other packet forwarding, queuing, and/or scheduling rules may have been negotiated with each router along the path - Perform best effort in absence of negotiated service - No additional semantic restrictions Discussion how this would interact with other usage of flow label. C. Huitema pointed out that it is backwards. Flowlabel indicates that it is a long lived flow. That is the case when extra overhead to shortcut flow is worthwhile. No flow label probably indicates that flow will be short lived. Long discussion about merits/cons of this proposal. draft-ietf-ion-ipv6-atm-00.txt - Media specific companion document to draft-ion-ipv6-00.txt PVC rules - Standard LLC/SNAP encaps, with IPv6 PID (null encapsulation allowed/negotiable) Document currently in ION working group last call. If doesn't go through quickly, ATM Point-to-Point link text will be moved to a separate document. Status of "IPv6 Transmission over Frame Relay" and "Extensions to IPv6 Neighbor Discovery for Inverse Discovery" was also reviewed. They will become ION w.g. drafts and pursued there. Router Renumbering / M. Crawford -------------------------------- RR Goals - One step changes to the set of prefixes in use site-wide o Including ND timers and flags - Spectrum of finer-grained operations, down to a single interface of a single router - Reliability - Security RR Basics - Carried in ICMPv6, type = TBD - two codes: Command & Result - Built-in authentication and & replay protection, or use IPSEC - "Dry-run" mode to simulate a Command - "site-conscious" can apply command to subset of multi-sited router RR Command Structure [Using ABNF of RFC2234] - CmdPkt = Header *PCO AuthData - PCO = Op MatchPrefix *UsePrefixPart - UsePrefixPart = cut & paste info to combine old & new bits Mask & Flags to set ND PIO flags ND RA timers New Prefix bits RR Result Structure - ResPkt = Header *MatchReport AuthData - MatchReport identifies a match by Which PCO in the corresponding Command packet Interface Prefix - The new prefixes, if any, can be inferred Lacking in current draft - Examples! - Asymmetric keys?? - Is message processing section sufficiently rigorous - Other error contradictions? Comments: Doesn't deal with result implosion. Author agrees, needs to be added. Is there any way to have routers tell what prefixes you have now without changing anything. Answer: could ask for zero prefix match and look at replies. Also use SNMP. Deering suggested to use similar mechanisms that IGMP uses to space out replies to multicast query. Would like to see ICMP code assigned, then folks build implementations. Need to resolve open issues. DNS mappings / C. Huitema ------------------------- Revising the AAAA record New AAAA Record? - One proposal: draft...-aaaa-00.txt - Main feature: indirection AAAA = prefix length + suffix + name of prefix - Three questions: o Do we need this? o Shall we use the same record number? o Shall we maintain upward compatibility? Needs, Let's take an example +--------+ +--------+ | | | | | TLA-1 | +--+ TLA-2 | | | / | | +---+----+ / +----+---+ | / | | / | +---+----+ / +----+---+ | +-+ | | | ISP-A | | ISP-B | | | | | +----+---+ +---+----+ \ / +--+--------------+--+ | Site | +--------------------+ | Host - We will Consider o Change provider, o Network multi-homing o Provider renumbering, o Provider multihoming What we have today will not scale - For each host, 3 records TLA1/A/SiteA/LinkID TLA2/A/SiteA/LinkID TLA2/B/SiteA/LinkID - Change provider Change all records - Network multihoming Duplicate record Provider renumbering Phone call to site - Provider multihoming Duplicate prefixes Local copies Using the new format solves the problem - For each host, one record Link/ID + net.site.com - For the site NLA-A + net.ips-a.net - Change provider update net.site.com/AAAA - Network multihoming Two AAAA records for net.site.com - Provider renumbering - Provider multihoming Update provider AAAA record Question 2 - Resource Record Number - Using new RR type o Allows parallel deployment, o But resolvers will never look for two records - Use same RR type (AAAA) o Will break old software o Forces transition to new structure Question 3 - Format compatibility +---+--------+-------------+ | L | Suffix | Domain Name | +---+--------+-------------+ +-----------------+---+-------------+ | 128 bit address | L | Domain Name | +-----------------+---+-------------+ +-----------------+---+-------------+ | 128 bit address | 0 | ...... | +-----------------+---+-------------+ - If compatible, two phase deployment - Longer records per host (128 bits v.s. 80) - Sill wins over current AAAA record (multihoming) A decision on AAAA record? - Shall we o Leave RFC1886 alone, or o Modify & recycle to Proposed Standard? - If we modify: o Shall we keep the AAAA record? - If we modify the AAA record Shall we adopt the new format (draft) ? or shall we maintain compatibility ? Question about impact on gethostbyname. Would not change gethostbyname interface in host. Could this be hidden from hosts? Answer: Doesn't work, caching problems, some parts short lived, some long lived. Won't work. Authors conclusion is that we want to modify RFC1886. Recycle at PS. How does this relate to dynamic updates? Group wants to adopt this proposal. Then do a working group last call. This will replace RFC1886 IPv6 Name Lookups Through ICMP / M. Crawford -------------------------------------------- Who-Are-You? ------------ Format +-----------+-----------+-----------+-----------+ | Type | Code | Checksum | +-----------+-----------+-----------+-----------+ | ID | unused | +-----------------------+-----------------------+ | | + Nonce + | | +-----------------------------------------------+ | Time-to-Live | +-----------+-----------------------------------+ | NameLen | | +-----------+ + | | + FQDN.... + | | +-----------------------------------------------+ Review of Motivation - IN-ADDR.ARPA poorly maintained, will IPv6.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. Features - PLUS: Routing system takes the place of IP6.INT delegations o Always current - PLUS: A meaningful TTL is usually available from Auto config or DHCP - MINUS: Target must be up and reachable to do a lookup o But is it meaningful to say a certain FQDN is associated with an address, when it isn't up? Status of -01 - Query & Response processing: done - Rules for TTL field: done - Added terminology section; guidelines & discussion; security considerations, IANA considerations. - Open issues: o Possible change to DNS client view o Negative caching - Authentication: new issue DNS Delegation and Renumbering ------------------------------ Two General Modifications to DNS Problems - aaaa-00 DBIT records o Rely on wildcard records which produce intermediate data of no later use - dns-reverse-lookup-00 DBIT records o Require lower zones to be renamed on renumbering * Even DynDNS can't pull off that trick New Proposal - Previous proposal involved only new RR types and new resolver/additional section processing rules - I propose two extension to DNS which have uses unrelated to IPv6 Non-Terminal CNAMEs - ... or whatever you want to call them - Translate a suffix of the queried domain. - Query to be repeated with same initial part of translated suffix - Examples 225.131.in-addr.arpa ZNAME in-addr.final.gov. foo.com ZNAME foo-division.bar.com Counted Bit-Strings - Length-of-Label counts bits, not octets. o Pad data to octet, of course - To be considered: as a sequence of 1-bit labels (at an almost 16x space saving) - Consider it a form of compression +------+------------------+------------------------+ | 01xy | bit count | bit string | +------+------------------+------------------------+ What they can do for IPv6 - Simplify and shrink synthesized AAAA records - Enable reverse zones which are nearly hands-free maintainable across "renumbering events." o Non-terminal ZNAME > delegation o Counted bit strings > N x (single purpose RR) Discussion. Conclusions: Make ICMP approach experimental. With multiple names? With warnings for scope? Keep ICMP for link-local. Could also add local name to address lookups as well for dentist office operation. Reverse Address lookup in DNS for IPng / O. Gudmundsson ------------------------------------------------------- IPng reverse DNS address lookup - Storing all reverse records under name like 0102030405060708090a0b0c0d0e0f10 o Is impossible to maintain o Is impossible to secure - Addresses consist of fields that reflect the delegation authorities, reverse lookup should maintain this information. - It is impossible to know the size of the next delegation unless it is fixed or it is explicitly stated. DBIT (delegated BITs) record - RBATA contains last bit delegated, DNS name of the authority assignment has been delegated to - Name on DBIT record encodes prior delegations o First byte is length of bit field o Subsequent bytes is the bit field o Names are stored as binary values - Examples: (in hex) o 08aa.ip6.ing IN DBIT 20 ripe.net - Last bit delegated == 128 delegates all remaining bits and corresponding DBIT record is expected in the domain delegated to - Last bit delegated == 0 is a EID/host DBIT record DBIT Example - Query for address aa2f:34:1::3fff:1234 - Server needs to query for the following DBIT records o IP6.INT DBIT 8 iana.org. o 08aa.IP6.INT DBIT 20 ripe.org. o 0c02f0.08aa.IP6.INT DBIT 32 isnet.is.example. o 0c0034.0c02f0.08aa.IP6.INT DBIT 64 ismennt.is.example - 2000010000.0c0034.0c02f0.08aa.IP6.INT. DBIT 128 thorshofn.ismennt.is.example. - 40000000003fff1234.thorshofn.ismennt.is.example. DBIT 0 sia.thorshofn.ismennt.is.example Example 1: Query for address - Ask server ipv6.int for DBIT record ofip6.int o IN.INT DBIT 8 iana.org o + NS records for iana.org + glue - Now ask iana.org for 08aa.IP6.INT DBIT record o 08aa.IP6.INT DBIT 20 ripe.org o + NS records for rip.net + glue - Now ask one of the ripe.net servers for 0c02f0.08aa.IP6.INT DBIT o 0c02f0.08aa.IP6.INT DBIT 32 isnet.is.example o 0c0034.0c02f0.08aa.IP6.INT DBIT 64 ismennt.is.example o 20000020000.0c0034.0c02f0.08aa.IP6.INT DBIT 128 thorshofn.ismennt.is.example DBIT Example (2) - At this point all remaining bits are delegated now asks server thorshofn.ismennt.is.example. for 40000000003fff1234.thorshofn.isment.is.example o 40000000003fff1234.thorshofn.isment.is.example DBIT 0 sia.thorshofn.ismennt.is.example. for - Now server has all the DBIT records in and can generate an answer that looks like: o 80aa2f003400010000000000003fff1234.IP6.INT DBIT 0 sia.thorshofn.ismennt.is.example. - The last answer is not signed but the server can return to the resolve all DBIT records used to allow signature verification. DNS Impact of DBIT records - DBIT ignorant servers and resolvers will ask for 80aa2f003400010000000000003fff1234.IP6.INT - DBIT aware server needs to break address requested into the different fields o Servers SHOULD be able to longest prefix match on DBIT records in cache o Servers need to issue multiple queries to generate correct answers o Servers need to be able to merge multiple DBIT records into one answer. - DBIT preprocessing is similar to KEY chain verification in DNSSEC. Advantages of DBIT records - Allows delegations to take place on any bit boundary - Explicitly state the delegations and size of delegations o Allows full verification of the bindings - Fits well with caching name servers - End sites do not have to resign any DBIT records when renumbering Discussion. Contrasted with other proposals. CH: Suggests leaving 1886 alone (existing practice), wait until the newer stuff is ready to bring forward when we have all of the tools. Suspect that 1886 and new ZNAME will be OK to pursue. Chairs will discuss how to move these drafts forward and report back to the working group. J. Bound reports that this will slip deployment by 6 months. Gethostbyname update to RFC 2133 / B. Gilligan, J. Bound -------------------------------------------------------- RFC1233 Update - flags now - Freehostent MUST always be called! - Flags Default (continues ....) 7. Agreement on change by hostbyaddr() 8. Suggest we use AI.Default as a system default. Also suggested to author off-line -> xxxxx 10. Name change suggestions: getdynhostbyname() Freedynhostent() getdynhostbyaddr() Suggestion to use "node" instead of "host" 11. Add new AI_Flags to getaddrinfo() Warning - TOG/XNET owns this spec ???? Thanks to Bob, Sue, Jim, & Rich [Jim Bound will send slides by email] Traceroute hop-by-hop option / A. Durand ---------------------------------------- Round trip Traceroute Traceroute Problem - Route for the direct patch - No information about the reverse path - Source-routing is not a solution - Many (most?) routes are asymmetrical (difficult to debug) - Can go through firewalls... Proposed Solution - Based on RFC1394 for IPv4 & IPv4 Record Route option - Define an hop-by-hop option processed by routers on the direct and the reverse path. - Define a new ICMP traceroute message - 4 different strategies can be used Traceroute hop-by-hop option 0 3 0 1 +-----------+-----------+ | Value=TBD | Length | +-----------+-----------+-----------+-----------+ | ID | Ptr | Flags | Boundary | +-----------+-----------+-----------+-----------+ | | | space to record information | . . . | | +-----------------------------------------------+ Router Information 0 3 0 1 +-----------+-----------+-----------+-----------+ | Type | HL | Medium | Reserved | +-----------+-----------+-----------+-----------+ | MBZ | AS | +-----------------------+-----------------------+ | | | Address | | | | | +-----------------------------------------------+ ICMP Traceroute message 0 3 0 1 +-----------+-----------+-----------+-----------+ | TBD | MBZ | Checksum | +-----------+-----------+-----------+-----------+ | ID | HL | Medium | Reserved | +-----------------------+-----------------------+ | MBZ | AS | +-----------------------+-----------------------+ | Reserved | +-----------------------------------------------+ | Address | | | | | +-----------------------------------------------+ Strategy #1 Two Packet traceroute - Originator send ICMP echo request to target with traceroute hop-by-hop - Routers store information within the option - Target send ICMP echo reply with traceroute hop-by-hop option initialized with data from the received packet. - How many routers can be recorded? o min MTU 576 => up to 21 o min MTU 1200 => up to 47 - OK for small networks, not enough in the general case [figure of two packet traceroute] Strategy #2 Limited Traceroute - Originator specifies to record the direct path or the reverse path. - Originator includes a boundary indication - Packet is sent with Hop Count set to 255 - Routers should record information iff current Hop Count <= Boundary [figure of limited traceroute] Strategy #3 Debug Mode - Originator set a "debug flag" in the hop-by-hop option - Routers send their information in a new ICMP traceroute message back to the originator. [figure of debug traceroute] Comments: Have looked at multicast route traceroute draft? Deering very nervous about debug mode because it generates so much traffic. Suggest modeling this like multicast traceroute and remove debug mode. CH: Two problems with approach. Real reason IPv4 traceroute not uses was that it was a stupid idea. Debug mode is a great tool for denial of service attack. This is very bad. M. Wasserman: Thinks proposal needs some more work. Likes the goal for what this does, but isn't sure this is the right mechanism. Overall conclusion that work should continue. DHCP vs. M & O Bits / Narten ---------------------------- M bit to control how if DHCP should be used to get addresses O bit to get other info from DHCP. Discussed in DHCP w.g. Agreed on clarification to language in spec. Issue is if different advertisements have different M & O bit values also resolved. Once use DHCP keep using it. Ignore changes in bits. Text will also be clarified. Bound suggested alternative. Bits not needed. If administrator has policy, then they control ND advertisements or turn on DHCP. Discussion and clarifications. Comment bit is important, because otherwise you have to wait for a timeout before continuing. Suggesting that we should keep bits and clarify usage. Bits are advisory. Hint to use DHCP or not. Working group consensus to leave keep bits and clarify text as to usage. ------------------------------------------------------------ FRIDAY, December 12, 1997, 0900-1130, (Empire Room) ------------------------------------------------------------ Document Status (continues) / R. Hinden --------------------------------------- Neighbor Discovery & Address Auto-Conf - Document editor will do wg last call for advancement to Draft as soon as updated drafts are out. Unicast Aggregation Formats draft - Author will add motivations section based on last call discussions. [Editor's note: Following additional discussions, author will change format to add a 8 bit reserved field between TLA and NLA field (reduces NLA to 24 bits). This resolves issue of allowing additional TLA's if routing system evolves to handle more top level routes but keeps initial limit at ~8K for initial allocations.] TLA/NLA Assignment Rules draft - After discussions with lots of IESG folks and other interested parties this week, decision is to form operations area WG to progress rules document. Allison Mankin and Erik Huizer will co-chair working group. ECN Bit Assignment / S. Floyd ----------------------------- A Proposal to add Explicit Congestion Notification (ECN) to IPv6 and to TCP Internet Draft ECN Web page: http://www-nrg.ee.lbl.gov/floyd/ecn.html What is needed from IPv6 - An ECN-capable bit set by the origin transport protocol (for incremental deployment) - 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, base don the average queue size. Where would the bits come from? - The IPv4 TOS byte and/or the IPv6 traffic class byte - Our original proposal was only in terms of IPv6 - IPv4: The current draft of draft-ellesson-tos-00.txt includes the CE and ECT (ECN-capable transport) bits - What would be the time scale of making this decision? - Where? Intserv/diff-serv? or IPng? Planning an ECN BOF at next IETF. Could make a formal request to IESG for two bits in IPv4 Why two bits instead of one? - The One-bit approach: The single bit would have two values: "ECN-Capable", and "either not-ECN-Capable, or Congestion Notification". - The ECN-Capable functionality is needed to allow a viable incentive for incremental deployment of ECN-aware hosts. - Robustness issues for one bit approach: o Default setting MUST be "either non ECN capable, or Congestion Notification" - The receiver has to know in advance that the sender is sending all packet with the bit set as "ECN-Capable". Why not Source Quench? - The delay difference (between RTT and part of an RTT) is not a critical issue for most environments - The ECN bit is applicable for multicast as well as for unicast applications. - With Source Quench, care must be taken not to add significant extra traffic in times of congestion. How would the router decide whether to drop the packet or set the ECN bit? - For ECN-capable packets, the router would set the ECN bit when it is in the regime of using RED to "mark" packets probabilistically. When the average queue size exceeds the maximum queue threshold, the router would drop arriving packets. - For most routers today, the packet drop rate is less than 10%. If these routers deploy RED, they are therefore generally in the regime of probabilistic marking. Does ECN make it easy for evil applications to ignore congestion control? - Already easy for "evil" applications to ignore congestion control. Just use UDP, and add a little FEC to counteract the packet drop rate. Or "turn off" congestion control for TCP. - In the absence of congestion control in the end-nodes, a moderate (less than 10%) packet drop rate is not, in and of itself, an effective mechanism of congestion control, or an effective deterrent to any application that wishes to "turn off" end-to-end congestion control. - ECN does add another way that applications could ignore congestion control, but setting the "ECN-capable" bit but ignoring the ECN bit in received packets. What applications would benefit from ECN - Reliable multicast - Real time flows with (fixed or adaptive) playback times - Very short web transfers - Low-bandwidth telnet connections ECN Simulations and Experiments - Simulations: the ns-1 and ns-2 simulators [floyd1994] - Experiments: UCLA (Chris Chen, Hariharam Krishnan, Steve Leung, Nelson Tang) has an ECN implementation in IPv6 FreeBSD. Using RED implementation from ALTQ. - The bits to use in the IPv6 header for experimental purposes? IGMP for IPv6 / S. Deering -------------------------- Based on IGMPv2 for IPv4 Spec (recently approved as proposed standard) Changes of terminology from IPv4 version - Host/Router/Node, Network/Link, etc. - "multcast listener discover" Uses ICMPv6 message types, not protocol ID #2 Uses Link-local source address for messages - Link-Scope all-nodes multicast destination address for queries Didn't get new draft out prior to ID deadline. Will get it a week or two after IETF. Packet Format +--------+-------+-----------------| | Type | Code | checksum | +--------+-------+-----------------| | Max resp delay | reserved | +----------------+-----------------+ | | | Multicast | | | | Address | | | +----------------------------------+ Types: Query 130 Report 131 Done 132 Code: 0 Max resp delay: in milliseconds (Router alert also present) Suggestion: Reserve these type codes in ICMP spec. Also the ND type codes. Also reference to other docs. IPng Document editor will reissue ICMP draft with type codes. Question about Multicast routing protocols: PIM and MOSPF currently support OSPF. DVMRP will not. Neighbor Discovery over Tunnels / S. Deering -------------------------------------------- Should we run ND over tunnels and p-p links? Suggestion that we need additional specification about how to run ND on point-to-point links. Bi-directional links only. Probably should not run it over uni-directional links. When a pair of routers are at ends of link, ND is also not needed. Routing protocols have needed functionality. In some ways ND is the routing protocol for Host-Host and Host-Router. NUD may be used between routers. Required for other cases. Should we consider ND on or off, or should we allow it's individual components to be used individually? Questions: Should we use ND between hosts and router on bi-directional p-p link? Deering would like this to be the case. Parts can be turned off as appropriate. Issue may be mostly focused on address resolution. Deering wants resolution of should we do this so, if so, we can write a document that defines operation. Discussion. Define p-p link as one that there can only be two nodes. Given that property, we can leave out specific ND components. M. Wasserman will outline the issues on the mailing list. IPv6 Transmission over IPv6/IPv4 Tunnels / A. Conta --------------------------------------------------- Define - 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 = ( physical underlying IPv6 interface MTU - tunnel headers size) o For Ethernet 1500-20=1480 - 1280 <= tunnel MTU < default tunnel MTU Tunnel Packet Format - IPv6 tunnel packets are encapsulated as: o IPv6 packets o IPv4 packets Interface ID (token) - The IPv6 tunnel pseudo-interface ID (token) o Unique on the virtual link represented by the tunnel - Method 1 o Use underlying physical interface identifier (e.g., EUI-64, EUI-48, etc.) - Method 2 o Based on random number - local, individual 7 6 5 4 3 2 1 0 (bit order +-----+-----+-----+-----+-----+-----+-----+-----+ 0 | Random Number | MBZ | + +-----+-----+ . . . . . . 7 | | +-----+-----+-----+-----+-----+-----+-----+-----+ o Advantage: survives underlying physical interface NIC changes Comment: This might conflict with vendor assignments. If using this, why transform the interface ID. Could use it without change. Question are both end of links required to be on the same subnet. Answer: No we can have unnumbered links. Not prohibited either. Could also use link-local addresses. Comment: It is very important to keep the token the same when rebooting, rebooting, etc. Author will revise draft and republish. Site prefixes in Neighbor Discovery / E. Nordmark -------------------------------------------------- Goals - Limit effect of renumbering in a site by ensuring that traffic local to the site use site local addresses. - Do this without requiring a two-faced DNS. Proposal - Advertise the global prefixes (w/ lifetimes) for the site in Neighbor Discovery messages. - The hosts use this information to maintain a list of the current site prefixes. - The host resolver (gethostbyname function) checks against list of prefixes after resolving the name. - When one of the addresses retrieved from the DNS matches one of the site prefixes (i.e., the first N bits match) then replace with the corresponding site local address. Open issue 1 - Mobile nodes moving off site and have been using site local addresses. - Clarify in architecture: mobile is part of home site, not part of visited site - Site local packets (src or dst) over bi-directional tunnel to mobile KRE: The problem is that we have not defined what is a site. Need to do this. Proposal: Node or link are never in more than one site. Some node/links are not in any site (used to connect sites). Question about if tunnel is bi-directional or uni-directional. Issue is more complex. Disagreement about KRE's definition of site. Alternative definition is that node can be in multiple sites and link can only be in one. Agreement on criteria that sites can never overlap. Open Issue 2 - Node multihomed to multiple sites - Disable algorithm (in draft), or - Christian H. proposal with random site ID in site local address +-------+-------------------+--------+--------------+ | xxxx | 0........0 | Subnet | Interface id | +-------+-------------------+--------+--------------+ put random # here Comment: Same issue as what we decided with link local addresses. Should not need random number. Just need to keep track of scope of these addresses. Additional discussion..... Open Issue 3 - Site local address in DNS - Flexibility - not all nodes in the site must have a site local address - Limits denial of service attack? - No need for two-faced DNS - Site local address is ignored unless in same site - If RRset contains global address matching a site prefix => Use site local RRset Open Issue 4 - Include or remove global addresses? - Site local should be tried first by application - Returning globals => accidentally using global when site local would have worked - No globals => site locals better work! - Admin applications need to see content of DNS Open Issue 5 - Encoding the exact semantics of advertisement: - Note: Separate prefix option advertisement to assign site local address - Should the site prefix be a separate prefix option (i.e., remove Site PLength? Open Issue 6 - Security considerations: - Any node on the link can cause a denial of service attack by advertising a bogus site prefix - This is not any worse than other on-link DoS attacks. Open Issue 7 - Assumes common SLA (subnet number): - 16 bits in site local - Must match in all global and the site local addressing plans - Relax if site locals in DNS Open Issue 8 - Are the benefits worth the added complexity? Discussion will be continued on mailing list. Router Alert / R. Hinden ------------------------ This draft has been returned from the IESG for several changes. C. Partridge will be submitting a new draft in the next few weeks that should resolve the problems. Comment: IPsec supposedly is requesting an additional code point in the router alert option for multicast key. VRRP for IPv6 / R. Hinden ------------------------- Virtual Router Redundancy Protocol (VRRP) developed initially for IPv4. VRRP Overview - VRRP allows one router to back up another router transparently to hosts o Goal is to keep TCP connections from breaking - Current Host OS's don't handle switching to a second router well or at all - Mechanisms such as Router Discover were not designed for this function and are not widely implemented. IETF - VRRP being developed in IETF o VRRP Working Group o Current draft is: - Provides functions similar to Proprietary Protocols o Cisco HSRP o Digital IP Standby Protocol - Work Includes o VRRP Protocol o VRRP MIB o VRRP for IPv6 [Figure showing basic operation of VRRP] VRRP Mechanisms - Virtual MAC Addresses o Mapping between Router IP Address and MAC Address o Host Default Gateway stays the same - VRRP Protocol and State Machine o Determines which router is Master o Sends Periodic Advertisements + Default is 1 second o Backup takes over if three Advertisements not heard Additional Detail - Priority Allows control over which router backs up another - Supports Loadsharing by setting Default Gateway in Hosts to different VRRP Routers - More sophisticated control can be done by dynamically changing priority based on status of other interfaces - Runs over Shared Media LAN's - Authentication choices include MD5 Status - Working Group Meet at this week's IETF - Group agreed to move to Proposed Standard with small changes - Work starting on o VRRP MIB o VRRP for IPv6 Issue for IPv6 is to either add VRRP features to neighbor discovery or to define a profile for current ND mechanisms that meet VRRP goals. Comments were mostly to just use ND (with some tuning if necessary). IPv6 Addresses in URL's / B. Carpenter -------------------------------------- Design team meet in the bar a few nights ago. Need numeric address in URL's for emergency operations (or robotic apps). Colons break URL parsers "hostname" syntax Proposals: http://--ABCD-EF12-192.100.1.2.ipv6:80/ http://[ABCD:EF12:192.100.1.2]:80/ Issue: Should IPng w.g. reopen the "colon" notation? Heated discussion. Most comments that this is stupid, we should not reopen IPv6 text notation. Long discussion. Issue seems to be that many parsers that take URL's are very limited. No one was in favor of changing current text representation. Extremely strong consensus! It was noted that the issue is probably only relevant for complete web browsers (e.g., Netscape, Microsoft, etc.), not all other applications that use URL's. If the complete web browsers can be changed it is very likely to be sufficient. Recommend that the primary preferred syntax for IPv6 addresses in URL's be: http://[ABCD.EF01::2345:6789]:80/ The IPv6 address should be enclosed in brackets. URL parsers that can not support this notation can either support the proposed alternative syntax: http://--ABCD-EF12-192.100.1.2.ipv6:80/ or not allow IPv6 addresses to be entered directly. Non-Corrosive Multi-Homing Idea / Matt Crawford ----------------------------------------------- Goal - Allow a multihomed site to use other links for existing sessions which have addresses derived from the provider on the failed link. - Do not inject long prefixes into global routing. - Do not tell ISP's how to run their busine$$es. Three Magic Words - Multicast - Security - Mobility [three diagrams showing basic topology of site connected to two providers and how mechanism works when a link to one of the providers fails.] Basic idea is for border router to send a renumbering message when link fails. New flag for prefix info. option - The "B" (for broken) flag o Valid/preferred lifetimes unchanged - Host action: o Do not select this prefix for new communication if there's a non-broken prefix available o For existing communication, use IPv6 mobility as if host has moved to A::S::HL Wants discussion on mailing list.