home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ipngwg / ipngwg-minutes-97aug.txt < prev   
Text File  |  1997-10-10  |  35KB  |  964 lines
  1. IPng Meeting
  2. Munich IETF
  3. August 1997
  4. ------------
  5.  
  6. Meeting chaired by Steve Deering / Cisco and Bob Hinden / Ipsilon.
  7. Minutes by Bob Hinden.
  8.  
  9.  
  10. Agenda
  11. ------
  12.  
  13.   Introduction / Deering, Hinden (5 min)
  14.   Action Items / Hinden (5 min)
  15.   Document Status / Hinden (10 min)     
  16.   Plan for Advancing Current Drafts / Hinden ( 10 min)
  17.   IPv6 Protocol Updates / Deering (30 min)
  18.    - Restrictions on Routing header reversal
  19.    - Specification of Class (formerly Priority) field
  20.    - Reserved bits for Explicit Congestion Notification bits
  21.    - Inclusion of Class in Flow constant fields?
  22.    - Neighborness rules for Strict/Loose Bit Map
  23.    - Encoding of Option types
  24.   TLA/NLA Assignment Rules / Hinden (20 min)
  25.   Neighbor Discovery Issues / Nordmark, Narten (20 min)
  26.   Decision on Advancing Current Documents / Hinden (10 min)
  27.  
  28.   Mobile IP / Johnson (10 min)
  29.   IPv6/NBMA work in the ION group / Armitage (10 min)
  30.   IPv6 Transmission over Frame Relay / Conta (5 min)
  31.   IPv6 Transmission over IPv6/IPv4 Tunnels  / Conta (5 min)
  32.   Inverse Neighbor Discovery for IPv6 / Conta (5 min)
  33.   Inverse Neighbor Discovery for IPv6/IPv4 Tunnels / Conta (5 min)
  34.   Site prefixes in Neighbor Discovery / Nordmark (10 min)
  35.   Router Renumbering / Crawford (10 min)
  36.   IPv6 Name Lookups Through ICMP / Crawford (10 min)
  37.   DNS Alternatives to ICMP Name Lookups / Gudmundsson (5 min)
  38.   Header Compression / Degermark (10 min)
  39.   Traceroute using hop-by-hop options / Durand (5 min)
  40.   DHCP vs. Prefix changes 
  41.  
  42.  
  43. Introduction / Deering, Hinden
  44. ------------------------------
  45.  
  46. Steve Deering introduced the meeting and reviewed the agenda.
  47.  
  48.  
  49. IPv6 Testing Event / Deering
  50. ----------------------------
  51.  
  52. 15 companies attended (up from 12).  They were Digital, IBM, Sun
  53. Microsystems, FTP Software, Fujitsu, Hitachi, Bay, 3COM, Epilog, Toshiba,
  54. BSDI, Process Software, Ipsilon, SGI, and Inria.
  55.  
  56. Testing included 11 host and 6 routers implementations (3 hosts did routing
  57. too).  
  58.  
  59. They did interoperability testing only, not conformance testing. 
  60.  
  61. Results were:
  62.  
  63.  - 15 nodes supported ping
  64.  - All nodes supported new (aggregatable) address format
  65.  - 3 nodes did Path MTU discovery and Packet too big, 6 did not, rest
  66.    unknown.
  67.  - 7 nodes did both client and server telnet
  68.  - 6 nodes did client and server FTP
  69.  - 2 nodes did PPP
  70.  - 3 Routers sent ICMP redirects, 5 hosts processed them correctly
  71.  - 5 1/2 hosts did auto-configuration
  72.  - A few nodes supported FDDI and/or token ring
  73.  
  74. Next event is first week in December.
  75.  
  76.  
  77. Action Items / Hinden
  78. ---------------------
  79.  
  80.  Action Items (San Jose IETF)
  81.  
  82.  - Document editor will submit Tunneling Spec to IESG for proposed
  83.    standard.
  84.     o Sent request to IESG on 12/10/96.  IESG last call sent on 12/30/96
  85.       which ended on 1/17/97.  Many comments received.  IESG restarted last
  86.       call for this document and two GRE documents on IPv4 tunneling.
  87.     o Steve Deering currently reviewing GRE documents and will respond to
  88.       IESG last call.  On Agenda for Memphis.
  89.     o IPng Chairs sent email to Internet ID's.  Waiting for IESG action.
  90.     o Jeff Burgan (Internet AD) reported that IESG would vote on this
  91.       document separately from IPv4 tunneling documents.
  92.  
  93.  - Document editor will do a working group last call on Header
  94.    Compression specification.
  95.     o Sent on 12/10/96.  Working group last call ended 12/24/96.
  96.     o Comments received from Thomas Narten.  Once comments resolved (and
  97.       new draft published) document editor will send to IESG.
  98.     o New Internet Draft Published.  On agenda for Thursday session.
  99.  
  100.  - Dimitry Haskin and Dave Katz to write a draft proposing adding an
  101.    option to BGP4 to carry IPv6 interdomain routes.
  102.     o Drafts written for BGP4+ and BGP5.  IDR discussed.  Compromise
  103.       discussions underway.
  104.     o Discussed at Tuesday IDR session.  Consensus to go forward with
  105.       BGP4+.  
  106.  
  107.  - Thomas Narten to include in next version of neighbor discovery rule to
  108.    silently drop non-DAD packets which use the unspecified address as the
  109.    source of the packet.
  110.     o Open
  111.     o On agenda for Wednesday session.
  112.  
  113.  Action Items (Interim Meeting)
  114.  
  115.  - "WhoAreYou" ICMP Message / Matt Crawford 
  116.      o Draft missed ID deadline.  Sent to IPng list and on Memphis agenda.
  117.      o On agenda for Thursday Session.
  118.  
  119.  - Modify Link Name Draft / Dan Harrington 
  120.     o Update underway
  121.     o Waiting for outcome of "WhoAreYou" draft
  122.  
  123.  - Lessons from interim meeting / Thomas Narten, John Stewart, Allison
  124.    Mankin, Lixia Zhang, Matt Crawford
  125.     o Done.  Internet Draft published.  Discussion on agenda.
  126.     o New draft published.  Publish as Informational RFC?
  127.     o Authors plan to publish as RFC.
  128.  
  129.  Action Items (Memphis IETF)
  130.  
  131.  - Issue working group last call for IPv6 MIB's once new drafts are published.
  132.     o W.G. last call completed.
  133.     o Sent to IESG for Experimental, Internet AD's reviewing.
  134.     o Jeff Burgan (Internet AD) reported that it will be considered for
  135.       proposed standard.  Need to get a code-point outside of the
  136.       experimental subtree.
  137.  
  138.  
  139. Document Status / Hinden
  140. ------------------------
  141.  
  142.  - RFC - Proposed Standard
  143.     o TCP and UDP over IPv6 Jumbograms (RFC2147)
  144.  
  145.  - IETF Last Call completed
  146.     o Generic Packet Tunneling in IPv6 Specification
  147.  
  148.  - Submitted to IESG for Proposed Standard
  149.     o IPv6 Router Alert Option
  150.  
  151.  - Submitted to IESG for Informational
  152.     o Advanced Sockets API for IPv6
  153.  
  154.  - Submitted to IESG for Experimental   
  155.     o MIB for IPv6: ICMPv6 Group
  156.     o MIB for IPv6: TCP 
  157.     o MIB for IPv6: Textual Conventions & General Group
  158.     o MIB for IPv6: UDP
  159.  
  160.  - Working Group Last Call Completed
  161.     o Header Compression for IPv6
  162.     o IPv6 Router Alert Option
  163.     o A Method for the Transmission of IPv6 Packets over ARCnet Networks
  164.     o An IPv6 Aggregatable Global Unicast Address Format
  165.     o IP Version 6 Addressing Architecture 
  166.     o IPv6 Multicast Address Assignments
  167.     o IPv6 Testing Address Allocation
  168.     o TLA and NLA Assignment Rules
  169.     o Transmission of IPv6 Packets over Ethernet Networks
  170.     o Transmission of IPv6 Packets over FDDI Networks
  171.  
  172.  
  173. Plan for Advancing Current Drafts / Hinden
  174. -------------------------------------------
  175.  
  176. Hinden talked about it is now time to move the base IPv6 specifications
  177. to Draft Standard.  The main criteria is that they are stable.  After
  178. some discussion with the Internet AD's the important thing is that we
  179. don't make any changes which break interoperability.  Once a document is
  180. at Draft Standard it will be important to not make changes that are not
  181. critical.  It is important that we stabilize the documents to encourage
  182. products and deployment.
  183.  
  184. With each document we wish to move to Draft Standard an implementation
  185. report will have to be written.  The document editor will coordinate the
  186. creation of a feature list for each specification with the authors and
  187. create a template for an implementation report.
  188.  
  189. The list of documents with a proposal for advancement is as follows:
  190.  
  191.  
  192.    Document                    Current             Proposal
  193.    -------------               -----------         -----------
  194.    IPv6 Protocol               Proposed Std.       Draft Std.
  195.    Addressing Architecture     Proposed Std.       Proposed Std.
  196.    ICMP                        Proposed Std.       Draft Std.
  197.    DNS                         Proposed Std.       Draft Std.
  198.    Neighbor Discovery          Proposed Std.       Draft Std.
  199.    Address Auto Configuration  Proposed Std.       Draft Std.
  200.    Aggregatable Addresses      Internet Draft      Proposed Std.
  201.    IP_over_Ethernet            Proposed Std.       Proposed Std.
  202.    IP_over_FDDI                Proposed Std.       Proposed Std.
  203.    IP_over_PPP                 Proposed Std.       Proposed Std.
  204.    IP_over_ARCnet              Internet Draft      Proposed Std.
  205.    TLA/NLA Assignment Rules    Internet Draft      BCP
  206.    Testing Address Allocation  Experimental        Experimental
  207.    Multicast Assignments       Internet Draft      Informational
  208.    Path MTU Discovery          Proposed Std.       Draft Std.
  209.    Packet Tunneling            Internet Draft      Proposed Std.
  210.  
  211. This list will be reviewed later in the meeting after the current drafts
  212. are discussed.
  213.  
  214.  
  215. IPv6 Protocol Updates / Deering
  216. -------------------------------
  217.  
  218. Restrictions on Routing header reversal
  219.  
  220.   Question about need for requiring RH reversal.  Currently: three legal
  221.   behaviors: reply without a source route, reply with a configured source
  222.   route (independent from received source route), or reverse received
  223.   source route if packet was successfully authenticated.  Current text is
  224.   compatible with current Mobile IPv6 draft.  Group agreed to keep current
  225.   behavior.
  226.  
  227. Specification of Class (formerly Priority) field
  228.  
  229.       4      4                      24
  230.    +-----+-------+-----------------------------------------+
  231.    | ver | class |   flow label                            |
  232.    +-----+-------+-----------------------------------------+
  233.  
  234.   Bits are available for rewriting by routers.  High order class bit
  235.   recommended for interactive, other three are not defined, but left open
  236.   for experimentation.  These bits and flow label are not included in IPSEC
  237.   AUTH header.
  238.  
  239. Reserved bits for Explicit Congestion Notification bits
  240.  
  241.   Deering proposed congestion experienced bit (like "DEC" bit in CLNP).
  242.   Has been lobbied for many years.  Idea is to mark packets when congestion
  243.   occurs to notify the receiver instead of just dropping packets.
  244.   Van Jacobson had always resisted idea.  At last End-to-End meeting, group
  245.   came up with approach to use this bit with RED algorithm.  Unfortunately
  246.   VJ liked the new idea (not so bad).  It is too early to be a required
  247.   part of IPv6.  Does show lots of potential.  Thinking about freeing up
  248.   more bits to allow this usage.  Proposes:
  249.  
  250.       4      8                      20
  251.    +-----+-------+-----------------------------------------+
  252.    | ver | class |   flow label                            |
  253.    +-----+-------+-----------------------------------------+
  254.  
  255.   The class bits would be set to zero on sending and ignored on reception.
  256.   Reduces number of flows to ~1,000,000 per source address.
  257.  
  258.   Group agreed to make class field 8 bits long.  Discussion about how
  259.   tightly they should be defined.  Deering thinks it is important to keep
  260.   these bits reserved to allow IPv6 to be extensible.
  261.  
  262.   Suggestion to only reserve bits, and make definition of usage in a
  263.   separate document.  Christian Huitema disagreed, he thought it should be
  264.   defined.
  265.  
  266.   Deering thought we should move the definition to a separate document.
  267.   Group agreed to do this.
  268.  
  269. Inclusion of Class in Flow constant fields?
  270.  
  271.   Question is: must the Class bits be constant for all packets in the same
  272.   flow?  One side of argument is that as long as the Class bits can affect
  273.   routing, they should be constant within a flow -- otherwise, opportunistic
  274.   flow set-up can violate desired routing semantics.  The other side is the
  275.   desire not to eliminate the potential flexibility of allowing applications
  276.   to vary some of the Class bits within a single flow.
  277.  
  278.  
  279.   Allison Mankin suggested we might delete opportunistic flow setup text.
  280.   This would be reasonable when going to draft standard.
  281.  
  282.   Choices are to take class out of flow definition, or to define that the
  283.   "D" bit is not to affect routing.
  284.  
  285.   Group agree to remove opportunistic behavior from specification, and to
  286.   exclude Class from set of fields that must be constant within a flow.
  287.   There are no known current implementations of opportunistic flow setup.
  288.  
  289.  
  290. Neighborness rules for Strict/Loose Bit Map
  291.  
  292.   Specification never defined Neighborness rules for strict/loose source
  293.   behavior.  Deering speculated that this was included in IPv4 was for
  294.   security behavior.  To keep this behavior it would require adding
  295.   detailed rules for tunnel behavior, etc.
  296.  
  297.   Suggestion was made that we should get rid of strict source route
  298.   capability.
  299.  
  300.   D. Hasken thought we should keep strict, but would need consistent set
  301.   of rules.  Deering polled group.  Consensus to remove strict bits.
  302.   Bits become zeros and text describing usage is removed.
  303.  
  304.   Further discussion, but no change of consensus.
  305.  
  306. Encoding of Option types
  307.  
  308.   Should IPv6 option be identified by full 8 bit value or 5 bit option
  309.   type.  Current spec shows full 8 bits.  No objections from group.
  310.  
  311. Change recommended order of Extension Headers
  312.  
  313.   Deering had changed order based on what he thought was in ESP and AH
  314.   drafts.  This change was in error, and will be changed back to original
  315.   behavior.
  316.  
  317.   Suggestion to make options fixed length to make it easier to implement
  318.   IPv6 in hardware.  Deering replied that this would also require
  319.   removing all extension headers.  There was a consensus to not make this
  320.   change.
  321.  
  322. Bigger MTU?
  323.  
  324.   Should we change the IPv6 minimum MTU to something closer to 1500 (i.e.,
  325.   something like 1300, to allow room for one or two levels of encapsulating/
  326.   tunnel overhead without exceeding the Ethernet MTU of 1500).  This is the
  327.   last opportunity to make this change, given the increasing number of
  328.   existing implementations and the strong desire to move the base IPv6 spec
  329.   to Draft Standard ASAP.  This change would significantly reduce the
  330.   importance of doing MTU discovery for multicast, which is something best
  331.   avoided because of the ICMP implosion hazard.  576 was chosen because of
  332.   IPoverAppletalk.  Most links (except for dialup) are already ~1500.
  333.   Comment that this would be a problem for dialup links.  Deering replied
  334.   that for slow-speed links it's preferable to do link-specific fragmentation
  335.   and reassembly, below the IP layer.  Several people supported the idea.
  336.  
  337.   Very strong consensus to raise MTU to ~1300 bytes.
  338.  
  339.   Editors Note: The Integrated Services over Specific
  340.   Link-layers (ISSLL) working group is currently developing standards for
  341.   doing link-specific fragmentation. Some of their techniques address
  342.   criticisms of using large MTUs on slow links (e.g., having small
  343.   packets get stuck behind bigger ones).  This may be relevant to this
  344.   issue.
  345.  
  346.  
  347. ------------------
  348. Thursday Session
  349. ------------------
  350.  
  351. Deering reported continued issue with decision to increase MTU.  Proposes
  352. to discuss on mailing list.  Need to resolve quickly.
  353.  
  354. Note: Alex Conta said that ICMP spec needs to get changed for multicast
  355. group membership messages.  Deering proposes removing multicast
  356. membership messages from this document and create a new document for
  357. these messages.
  358.  
  359.  
  360. Proposal to Add Explicit Congestion Notification (ECN) to IPv6
  361. and to TCP / Sally Floyd
  362. --------------------------------------------------------------
  363.  
  364. Reference: Floyd, S., TCP and Explicit Congestion Notification, ACM
  365.            Computer Communication Review, V. 24 N. 5, October 1994,
  366.            p. 10-23., http://www-nrg.ee.lbl.gov/
  367.  
  368. What is New
  369.  - Deployment of active queue management (e.g., RED) in the internet.
  370.  - Increasing amount of best-effort traffic where the user is sensitive to
  371.    the delay (due to retransmission) or drop of an individual packet
  372.    (e.g., telnet, web browsing, best-effort audio and video, etc.
  373.  
  374. What is Needed in IPv6?
  375.  - Two bits:
  376.     o An ECN-capable bit set by the origin transport protocol
  377.     o An ECN-bit set by the router (instead of dropping the packet)
  378.       when the buffer has not overflowed, and the ECN-capable bit is
  379.       set, and the router would otherwise drop the packet because of the
  380.       RED algorithm, based on the average queue size.
  381.  
  382.   - There is a single-bit version of this, described in Floyd94, that
  383.     overloads a single bit
  384.  
  385. What does ECN Bit Indicate?
  386.  - Indicates incipient congestion as indicated by the "average"
  387.    queue size exceeding a threshold, using the RED algorithms [FJ93,
  388.    RED-ietf-draft] 
  389.  - The ECN bit should "not" be set in response to an unfiltered signal
  390.    such as the instantaneous queue size.
  391.  - A "single" packet with the ECN bit set should be treated by the
  392.    end-nodes as an indication of congestion, just as would a "single"
  393.    dropped packet. 
  394.  
  395. How do transport protocols respond to the ECN bit?
  396.  - Congestion control response should be the same as that to a dropped
  397.    packet.
  398.  - Details depend on specific transport
  399.     o Reliable unicast (e.g., TCP)
  400.     o Reliable multicast (e.g., SRM)
  401.     o Unreliable unicast
  402.     o Unreliable multicast (e.g., vic)
  403.  
  404. What modifications are needed for TCP?
  405.  - Negotiation between the endpoints during setup to determine if they
  406.    are both ECN-capable
  407.  - A TCP option with an ECN-Notify bit so that the data receiver can
  408.    inform the data sender when a packet has been received with the ECN
  409.    bit set.
  410.  - The data sender halves its congestion window "cwnd" in response to an
  411.    ECN-notify.  This is done only once per window of data.
  412.  
  413. Internet draft will be out in a few weeks.
  414.  
  415.  
  416. TLA/NLA Assignment Rules / Hinden
  417. ---------------------------------
  418.  
  419. Overview
  420.  
  421.  - Goal to Provide Guidance to Registries and Organizations receiving TLA
  422.    IDs
  423.     o Avoid "Land Rush" on TLA IDs
  424.  - Focus on assigning TLA IDs to Organizations providing Public Transit
  425.    Service
  426.  - Assignment does NOT mean ownership
  427.     o It implies "stewardship"
  428.  
  429. TLA Assignment Rules
  430.  
  431.  - Must have a plan to offer public native IPv6 service within 6 months
  432.    from assignment.  The plan must include plan for NLA ID allocation.
  433.  
  434.  - Must have a plan or track record of providing public Internet transit
  435.    service on fair, reasonable, and non-discriminatory terms, to other
  436.    providers.  TLA IDs must not be assigned to organizations that are
  437.    only providing leaf service even if multihomed.
  438.  
  439.  - Must provide registry services on fair, reasonable, and
  440.    non-discriminatory terms, for the NLA ID address space it is
  441.    responsible for under its TLA ID.  This must include both sites and
  442.    next level providers.
  443.  
  444.  - Must provide transit routing and forwarding to all assigned TLA IDs
  445.    on fair, reasonable, and non-discriminatory terms.
  446.  
  447.  - Organizations are not allowed to filter out any specific TLA IDs
  448.    (except temporarily for diagnostic purposes or emergency repair
  449.    purposed).  Periodically (interval set by registry) provide to
  450.    registry utilization statistics of the TLA ID it has custody of.  The
  451.    organization must also show evidence of carrying TLA routing and
  452.    transit traffic.  This can be in the form of traffic statistics,
  453.    traceroutes, routing table dumps, or similar means.
  454.  
  455. Comments: 
  456.  
  457. Erik Nordmark: don't rule out tunnels for TLA access (e.g., for hopping
  458. over non-IPv6-supporting secondary provider).
  459.  
  460. Brian Carpenter: The wg's responsibility is to specify technical proposal
  461. and the technical rationale/justification
  462.  
  463. Steve Deering: Gov't example is special case of an ISP that serves a
  464. closed community
  465.  
  466. Someone: please don't use word "rules".  Too strong.  Internet AD's will
  467. help wordsmithing.
  468.  
  469. General consensus to move forward as a BCP when new draft is out
  470. incorporating suggested clarifications.  An IETF last call will be useful
  471. to have the broader IETF community review the idea in this document.
  472.  
  473.  
  474. Neighbor Discovery Issues / Nordmark
  475. ------------------------------------
  476.  
  477. Changes
  478.  - Change move solicited node MC address changed to pointer to Address
  479.    Arch.
  480.  - Remove priority references
  481.  - Decrementing lifetime variables
  482.  - Default lifetime infinity changed to 60 days
  483.  
  484. Clarifications
  485.  - Use of unspecified source
  486.  - Setting of NUD state
  487.  - Setting of Ls router flag
  488.  - Added "renumbering considerations" section
  489.  
  490. The zero lifetime issue is still unresolved.  This is the remaining issue
  491. that needs to be resolved before moving ND and AddrConf to Draft
  492. Standard.  The authors will make a proposal on the mailing list.
  493.  
  494.  
  495. Decision on Advancing Current Documents / Hinden
  496. ------------------------------------------------
  497.  
  498. IPv6 Protocol
  499.  
  500.   Group agreed to move to Draft Standard once the MTU issue was settled.
  501.  
  502. Addressing Architecture
  503.  
  504.   Group agreed to move to Proposed Standard.
  505.  
  506. ICMP                   
  507.  
  508.   Group agreed to move to Draft Standard once multicast membership messages
  509.   were removed.
  510.  
  511. DNS                    
  512.  
  513.   No action at this time.  Waiting for resolution of other DNS related
  514.   work. 
  515.  
  516. Neighbor Discovery     
  517.  
  518.   No consensus to move this forward.  Zero lifetime issue still open.
  519.  
  520. Address Auto Configuration
  521.  
  522.   No consensus to move this forward.  Zero lifetime issue still open.
  523.  
  524. Aggregatable Addresses
  525.  
  526.   Group agreed to move to Proposed Standard.
  527.  
  528. IP_over_Ethernet          
  529.  
  530.   Group agreed to move to Proposed Standard.
  531.  
  532. IP_over_FDDI              
  533.  
  534.   Group agreed to move to Proposed Standard once bridging text was
  535.   removed. 
  536.  
  537. IP_over_PPP               
  538.  
  539.   Group agreed to move to Proposed Standard once terminology was
  540.   clarified. 
  541.  
  542. IP_over_ARCnet            
  543.  
  544.   Group agreed to move to Proposed Standard once terminology was
  545.   clarified. 
  546.  
  547. TLA/NLA Assignment Rules  
  548.  
  549.   Group agreed to request publication as a BGP once revision available.
  550.  
  551. Testing Address Allocation
  552.  
  553.   Group agreed to move to Experimental.
  554.  
  555. Multicast Assignments     
  556.  
  557.   Group agreed to move forward as either Informational RFC or IANA
  558.   database input.
  559.  
  560. Path MTU Discovery        
  561.  
  562.   Group agreed to move to Draft Standard.
  563.  
  564. Packet Tunneling          
  565.  
  566.   IESG will consider for Proposed.
  567.  
  568.  
  569. Mobile IP / Johnson
  570. -------------------
  571.  
  572. Status of IPv6 Mobile work.  
  573.  - Current spec is <draft-ietf-mobileip-ipv6-03.txt>.
  574.  - High Level Overview
  575.     o Care-of addresses from IPv6 address autoconfiguration
  576.     o Mobile node sends its own Binding Update
  577.     o Uses for correspondent nodes and home registration
  578.     o Nodes cache bindings in a Binding Cache
  579.     o Correspondents route own packets directly to mobile node
  580.  - One implementation almost available.
  581.  
  582. Dynamic Home Agent Address Discovery
  583.  - Mobile node may not always know its home agent address
  584.     o While mobile node is away from home
  585.     o Home network may need to be reconfigured
  586.     o Different machine may take over as home agent
  587.  - In Mobile IPv4, this is solved by
  588.     o Mobile node can send to "directed broadcast" address
  589.     o All home agents in home network receive request
  590.     o All reject, giving their own unicast address
  591.     o Mobile node tries again with one of these addresses
  592.  - Can't do this in Mobile IPv6 since no broadcast in IPv6
  593.  
  594. New Home-Agents Anycast Address
  595.  - To register when don't know own home agent address
  596.     o Mobile node sends Binding Update to "Home-Agents anycast address"
  597.       for home subnet
  598.     o Receiving home agent replies, giving unicast address
  599.     o Mobile node registers to that IP address
  600.     o All IPv6 home agents MUST support this
  601.  
  602.  Deering suggested that we reserve some number local interface identifiers
  603.  for anycast addresses for applications that need anycast addresses.
  604.  
  605.  Suggest a new document for initial anycast assignments.  
  606.  ACTION: Document Editor.
  607.  
  608. Replay Protection for Binding Updates
  609.  - Must guard against replay attacks on Binding Updates
  610.  - IPsec AH and ESP can do replay protection
  611.     o Protection based on sequence number
  612.     o Must re-key before sequence number wraps around
  613.     o Only accept packet if sequence number >= max or within a "replay
  614.       window" of sequence numbers before that
  615.     o Allows out-of-order delivery
  616.  - Problem: Binding updates MUST be applied ONLY in order
  617.  
  618. Solution for Binding Updates
  619.  - Use IPsec for "Replay Protection"
  620.     o Lets IPsec worry about re-keying before wrap around
  621.  - Use our own sequence number for sequencing
  622.     o Similar to TCP sequence number when using IPsec replay protection
  623.     o Our sequence number only needs to be large enough to cover replay
  624.       protection window reordering.
  625.  
  626. Getting through Ingress Filtering
  627.  - Original Mobile IPv6 addressing for packets sent from a mobile node
  628.     o Source address = mobile node home address
  629.     o Destination address = correspondent node address
  630.     o Problem: Ingress filtering drops all these packets
  631.  - New solution uses "Home Address" destination option
  632.     o All IPv6 nodes MUST support receiving packets containing a Home
  633.       Address option.
  634.  
  635.  Questions about how this works and if it affects FTP and telnet.
  636.  Document will be clarified.
  637.  
  638. Use of Home Address Option
  639.  - Mobile node uses care-of address as source address...
  640.  - But only while packet on its way to the destination node
  641.  - At the Sender
  642.     o Sender builds packet (e.g., TCP) using home address
  643.     o Then substitutes care-of address as source
  644.     o Move home address into a Home Address option in packet
  645.  - At the Receiver
  646.     o Receiver substitutes correct source address (home address) back
  647.       into packet in place of care-of address
  648.  - Implementation of this would be required in all IPv6 receivers
  649.  
  650. Home Address Option vs. Binding Update Option
  651.  - Binding Update option
  652.     o Creates state in receiver in Binding Cache
  653.     o Used by receiver for sending future outgoing packets
  654.     o MUST be authenticated
  655.     o Use is only an optimization (not required in all nodes)
  656.  - Home Address option
  657.     o Creates NO state in receiver
  658.     o Does NOT affect future routing of any packets
  659.     o Need NOT be authenticated (unless IPv6 header already is)
  660.     o Receiving MUST be supported by ALL IPv6 nodes
  661.  
  662. Home Address Option Security
  663.  - If IPv6 header "source address" is authenticated
  664.     o Home Address option MUST also be authenticated
  665.     o Need to preserve protection of this field
  666.  - Otherwise
  667.     o Home address option need NOT be authenticated either
  668.     o IPv6 header source address may be forged/modified
  669.     o So may Home Address option data
  670.  
  671. Movement Detection Timing
  672.  - Helpful to know when to expect packets from router
  673.     o Mobile node know when it missed one
  674.     o Mobile node can decided for itself home many missed packets are a
  675.       cause for concern (possible movement)
  676.   - Neighbor discovery provides good source of packet form router
  677.     o Periodic Router Advertisements
  678.     o Must receive new one before old one expires
  679.     o But router must send more frequently, since some might be dropped
  680.     o Would help mobile node to know nominal advertisement interval
  681.     o Example: long lifetimes, but frequent advertisements
  682.  
  683. Comments Please
  684.  - Send comments to mobile IP mailing list <mobile-ip@smallworks.com>
  685.  - Also can be sent to Dave Johnson <dbj@cs.cmu.edu> and 
  686.    Charlie Perkins <cperkins@eng.sun.com>
  687.  
  688.  
  689. IPv6/NBMA work in the ION group / Armitage
  690. ------------------------------------------
  691.  
  692. Current draft is: <draft-ietf-ion-tn-01.txt>
  693.  
  694.   Suggestion to put "ipv6" in name of draft
  695.  
  696. Updates
  697.  - Interface token now based on 8 octet EUI-64
  698.  - Cleaned up vague text
  699.  - Specified host triggered transient neighbor discovery
  700.  - folded in some text from expired <draft-ietf-ion-ipv6nd>
  701.  
  702. TODO
  703.  - Syntax mapping between ND and NHRP at routers
  704.  - Clean up the misleading "ATM dependency" implied by current text
  705.  
  706. Current approach
  707.  - "on link" => "on logical link" (on LL)
  708.  - ND used on LL (native multicast or augmented MARS/RFC2022)
  709.  - Flow detection in router leads to NHRP query for destination
  710.     o NHRP reply translated to Redirect on source LL
  711.     o "transient" neighbor
  712.  - Host Trigger (NS for remote dst sent to router) also leads to NHRP
  713.    inter-router query
  714.  - NHRP reply translated into NA back to soliciting host
  715.  
  716. Current approach does not require ND to change.
  717.  
  718. Questions to gja@lucent.com
  719.  
  720.  
  721. IPv6 Transmission over Frame Relay / Conta
  722. ------------------------------------------
  723.  
  724. Draft: <draft-conta-ipv6-trans-fr-00.txt>
  725.  
  726. Defines: 
  727.  - Min, max, default MTU
  728.  - Frame format for IPv6 over FR
  729.  - Interface ID for FR interfaces
  730.  - IPv6 local address
  731.  - Source/target link layer address options in ND
  732.  
  733.  
  734. MTU
  735.  - Min frame size, 5,6, or 7 octets
  736.  - General requirement for at least 262 octets
  737.  - IPv6 requires a minimum MTU size of 576
  738.  - Default MTU = 1600
  739.  - 575 <= MTU <= 4080 with CRC16
  740.  - MTU > 4080 less error detection / correction at link layer
  741.  - MTU defined per link - implementation limitation.
  742.  
  743.  Deering comment need strong link layer CRC.  Should discourage MTU
  744.  greater than 2080.
  745.  
  746. Frame Format using SNAP identifier.  Found out there is a NLPID (0x8E) ,
  747. would save same header bits.
  748.  
  749. Slides showing figures with two approaches to create Interface IDs (first
  750. includes FR Node Identifier, FR Link Identifier, and FR DLCI, second is
  751. random number and FR DLCI), Link Local address, and Unicast Address
  752. Mapping.
  753.  
  754. Editors Note: After discussion with the author and the chairs of the ION
  755. working group, the IPng chairs decided that the ION working group should
  756. own this topic.  The IPng working group will consulted to insure that the
  757. work is consistent with IPv6.
  758.  
  759.  
  760. IPv6 Transmission over IPv6/IPv4 Tunnels  / Conta
  761. -------------------------------------------------
  762.  
  763. Draft: <draft-conta-ipv6-trans-tunnel-00.txt>
  764.  
  765. Extension to existing IPv6 tunneling document
  766.  
  767. Goals
  768.  - Tunnel minimum, maximum, and default MTU
  769.  - Frame format for IPv6 over IPv6 and IPv4 tunnels
  770.  - Interface ID for IPv6 tunnel interfaces
  771.  - IPv6 link-local addresses for tunnel virtual links
  772.  - Source/Target Link-layer address option used in ND or IND over IPv6
  773.    and IPv4 tunnels. 
  774.  
  775. MTU
  776.  - Default tunnel MTU is Physical underlaying IPv6 interface MTU - tunnel
  777.    headers size
  778.  - 576 <= tunnel MTU < default tunnel MTU
  779.  
  780. Tunnel Packet Format
  781.  - IPv6 tunnel packets re encapsulated as IPv6 and IPv4 packets
  782.  
  783. Interface ID (IPv6 tunnels only)
  784.  - The IPv6 tunnel pseudo-interface ID 
  785.     o Unique on the virtual link represented by the tunnel
  786.     o Based on the underlying physical interface identifier
  787.  - Mask the forth and fifth octets of the EUI-64 identifier with the
  788.    fixed 0xFFFC value
  789.  - Example
  790.        36-56-78-FF-FE-9A-BC-DE
  791.      becomes
  792.        36-56-78-FF-FC-9A-BC-DE       
  793.  
  794. Link Local Address
  795.  - The IPv6 link-local address for an IPv6 tunnel interface is formed by
  796.    appending the interface token, as defined above, to the prefix
  797.    FE80::/64.
  798.  
  799. Address Mapping
  800.   [figure not included]
  801.  
  802.  
  803. Inverse Neighbor Discovery for IPv6 / Conta
  804. -------------------------------------------
  805.  
  806. Draft is <draft-conta-ipv6-nd-ext-inv-00.txt>
  807.  
  808. Introduced topic.  Extension to IPv6 for FR and similar links when link
  809. layer is known, but IPv6 address is not known.  Read document and send
  810. comments to author <aconta@lucent.com>.
  811.  
  812.  
  813. Inverse Neighbor Discovery for IPv6/IPv4 Tunnels / Conta
  814. --------------------------------------------------------
  815.  
  816. Draft is <draft-conta-ipv6-inv-nd-tun-00.txt>
  817.  
  818. Introduced topic.  Extension to ND to allow inverse discovery for tunnels
  819. to aid in tunnel configuration.  Read document and send comments to
  820. author <aconta@lucent.com>.
  821.  
  822.  
  823. Site Prefixes in Neighbor Discovery / Nordmark
  824. ----------------------------------------------
  825.  
  826. Includes automatic creation of site local addresses and the creation of
  827. global version for DNS lookup.  Only global addresses need to be in the
  828. DNS.
  829.  
  830. Motivation / Requirements
  831.  - Reduce the risk of renumbering a site
  832.  - Ensure that communication local to a site uses site-local addresses
  833.  - Do not require that sites use a two-faced DNS (i.e., do not store the
  834.    site-local addresses in the DNS). 
  835.  
  836. [Slide with additions to ND Prefix Option]
  837.  
  838. Name Lookups
  839.  - Create site-local addresses when an address returned by DNS matches a
  840.    site prefix.  The first Site PLength bits are taken from the
  841.    site-local address (FEC0::0) and the remaining bits are taken from the
  842.    returned address.
  843.  - Add the created site-local addresses to the front of the list returned
  844.    to the application.
  845.  - Hidden from applications (i.e., in gethostbyname library).
  846.  
  847. Name Lookup Example
  848.  - Name service returns (for a multihomed node)
  849.  
  850.      2837:a:b:987:X:Y:W:Z1
  851.      2837:a:b:34:X:Y:W:Z2
  852.      2abc:77:66:23:X:Y:W:Z3
  853.      2000:1:2:987:X:Y:W:Z1
  854.      2000:1:2:34:X:Y:W:Z2
  855.  - List of Prefixes
  856.      2837:a:b::0/48
  857.      2000:1:2::0/48
  858.  - Resulting list of addresses (duplicates removed)
  859.      fec0::987:X:Y:W:Z1
  860.      2837:a:b:987:X:Y:W:Z1
  861.      2837:a:b:34:X:Y:W:Z2
  862.      fec0::34:X:Y:W:Z2
  863.      2abc:77:66:23:X:Y:W:Z3
  864.      2000:1:2:987:X:Y:W:Z1
  865.      2000:1:2:34:X:Y:W:Z2
  866.  
  867. Address Lookups
  868.  - No change unless a site-local address
  869.  - For site-local form the potential global addresses using the prefix
  870.    list and the site-local address
  871.  - For example, if the site-local address is:
  872.      fec0::987:X:YX:W:Z1
  873.  - List of site prefixes
  874.      2837:a:b::0/48
  875.      2000:1:2::0/48
  876.  - The addresses that should be tried
  877.      2837:a:b:987:X:Y:W:Z1
  878.      2000:1:2:987:X:Y:W:Z1
  879.  
  880. Open Issues: 
  881.  - Node on link can be use this to spoof the address and names returned by
  882.    the DNS.
  883.     o But such a node can already intercept all traffic
  884.     o Doing name/address lookup without communicating
  885.  - Subnet number must be the same for all global and site-local addresses
  886.    used by the site.  Is this too strict?
  887.  - Should the formed site-local address replace (instead of being added
  888.    to) the global addresses returned to the application.
  889.  - Common API to access the list of site prefixes.
  890.  
  891. Many questions.  Need additional discussion on the list.  We need to
  892. discussion on the mailing list.
  893.  
  894.  
  895. Header Compression / Degermark
  896. ------------------------------
  897.  
  898. Three drafts:
  899.  - Main draft: <draft-degermark-ipv6-hc-03.txt
  900.  - Negotiate for PPP: <draft-engan-ip-compress-01.txt>
  901.  - How to compress RTP: <draft-ietf-avt-crtp-xx.txt>
  902.  
  903. Status
  904.  - Protocol ID's from PPP ext
  905.  - Negotiation of header compression parameters
  906.  
  907.  - Name Change: Header Compression for IP
  908.  - Changed the order of the field in compressed TCP headers to conform
  909.    with RFC1144
  910.  - Priority/Class field: How to deal with this when we go to Proposed
  911.    Standard? 
  912.  - MTU: Not problematic fro PPP.  There is a standard for link-level
  913.    fragmentation. 
  914.  
  915. ACTION: Document editor will do W.G. last call once new draft is
  916. available.
  917.  
  918.  
  919. DHCP vs. Prefix changes 
  920. --------------------------------------------------
  921.  
  922. Issue is nodes can get addresses through manual config, addr conf, and
  923. DHCP.  If you have gotten addresses from one method, how to deal with
  924. changes received from DHCP and/or ADDR CONF.  This needs clarification.
  925.  
  926. One possible rule is that changes only apply based on way they were
  927. learned.  This is consistent to how DHCP works now for IPv4 (dynamic from
  928. DHCP and manual config) and how routing protocols work with dynamic
  929. routes vs. static routes.  ND and DHCP specs need minor revision.
  930.  
  931.  
  932. DNS Alternatives to ICMP Name Lookups / Gudmundsson
  933. ---------------------------------------------------
  934.  
  935. IPng DNS, and DNS
  936.  
  937. Provide an alternative to "WHO ARE YOU" message.  
  938.  
  939. This is a change from the plan to always return AAAA records.  This would
  940. return two pieces and host would put together.  Claim made that for
  941. secure DNS it is necessary to return two pieces.
  942.  
  943. Needs to be discussed further on the mailing list.  This affects moving
  944. the DNS draft to "Draft Standard".  This needs to be resolved first.
  945.  
  946.  
  947. -------------------------------------------------------------------------
  948.  
  949. At this point the session ran out of time.  The following agenda topics
  950. were not discussed:
  951.  
  952.      Router Renumbering / Crawford
  953.      IPv6 Name Lookups Through ICMP / Crawford
  954.      Traceroute using hop-by-hop options / Durand
  955.  
  956. The IPng chairs apologize to speakers for not covering their topics at
  957. this meeting.
  958.  
  959. -------------------------------------------------------------------------
  960.  
  961.  
  962.  
  963.  
  964.