home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ipngwg / ipngwg-minutes-97apr.txt < prev    next >
Text File  |  1997-05-22  |  50KB  |  1,327 lines
  1. Editor's Note:  These minutes have not been edited.
  2.  
  3.  
  4. IPng Meeting
  5. Memphis IETF
  6. April 10 & 11, 1997
  7.  
  8. Bob Hinden, Ipsilon Networks  / co-chair
  9. Steve Deering, Cisco Systems / co-chair
  10.  
  11. Minutes taken and edited by Bob Hinden
  12.  
  13. ------------------------------------------------------------------------
  14.  
  15. Agenda
  16. -------
  17.  
  18.  Thursday 1-3pm
  19.    Introduction and Bash Agenda / Steve Deering (5 min)
  20.    Document Status / Bob Hinden (5 min)
  21.    Review of Action Items for Previous Meetings / Bob Hinden (5 min)
  22.    Priority Field / Steve Deering (15 min)
  23.    Conclusions/Results from Interim Meeting / (80 min)
  24.       Meeting Summary / Bob Hinden (5 min)
  25.       Revision to Provider Based Addressing / Bob Hinden (10 min)
  26.       Analysis of GSE Proposal / Matt Crawford and others (25 min)
  27.       IPv6 over Ethernet & FDDI / Matt Crawford (5 min)
  28.       IPv6 over PPP / Dimitry Haskin (5 min)
  29.       IPv6 over ARCNET and LocalTalk / Bob Hinden (5 min)
  30.       The Use of End System Designators in IPv6 / Matt Thomas (5 min)
  31.       Routing Goop and AAAA Records in DNS / Jim Bound (5 min)
  32.       Numbering point-to-point and boundary links / John Stewart (5 min)
  33.       ESD Pro and Con's / Thomas Narten (10 min)
  34.  
  35.  Friday 9-11:30am
  36.    Conclusions/Results from Interim Meeting Continued / 60min
  37.    Solicited Node Definition / Steve Deering (15 min)
  38.    IPv6 Tunneling Spec and GRE / Steve Deering (15 min)
  39.    Router Renumbering for IPv6 / Matt Crawford & Bob Hinden (15 min)
  40.    Advertising site prefixes in RAs / Erik Nordmark (10 min)
  41.    Prefix Notation / Bob Hinden (5 min)
  42.    Who Are You / Matt Crawford (5 min)
  43.    Inter-Domain Routing Status / Bob Hinden (5 min)
  44.    ND Zero Lifetime advertisement issue / Thomas Narten (5 min)
  45.    Advanced API Spec / Matt Thomas (5 min)
  46.    Moving Base IPv6 Specs to Draft Standard / Steve Deering (5 min)
  47.    Wrap Up and Action Items / Bob Hinden (5 min)
  48.  
  49.  
  50. Thursday 1-3pm
  51. --------------
  52.  
  53. Introduction and Bash Agenda / Steve Deering
  54. --------------------------------------------
  55.  
  56. Steve Deering introduced meeting.  Asked for agenda changes.  Request to
  57. add slot for Mobile IP and an SNMP issue
  58.  
  59. Document Status / Bob Hinden
  60. ----------------------------
  61.  
  62. The following RFC's were published as Proposed Standard:
  63.  
  64.  - An IPv6 Provider-Based Unicast Address Format , RFC 2073
  65.  - RIPng for IPv6 , RFC 2080
  66.  
  67. The  IESG Approved for Informational RFC:
  68.  
  69.  - Basic Socket Interface Extensions for IPv6
  70.  
  71. IETF Last Calls were completed for:
  72.  
  73.  - Generic Packet Tunneling in IPv6 Specification
  74.  
  75. The IPng document editor submitted to IESG for IETF Last Call:
  76.  
  77.  - TCP and UDP over IPv6 Jumbograms
  78.  
  79. Working Group Last Call were completed for:
  80.  
  81.  - Header Compression for IPv6
  82.  - IPv6 Router Alert Option
  83.  
  84. These will be advance as soon as updated Internet Drafts are published
  85. based on the comments received during the last calls.
  86.  
  87. Review of Action Items for Previous Meetings / Bob Hinden
  88. ---------------------------------------------------------
  89.  
  90. Action Items from San Jose IETF
  91. -------------------------------
  92.  
  93. Steve Deering will write up description of proposed changes to Priority
  94. Field and send to IPng list.
  95.  
  96.  - OBE based on discussion on IPng list.  Need to get closure at Memphis
  97.    meeting. On Agenda for Memphis.
  98.  
  99. Document editor will send email to IANA to add default hop limit of 64
  100. parameter to IANA registry for IPv6 defaults.
  101.  
  102.  - Sent on 12/12/96.  Can't find it on IANA web site.
  103.  - Resent on 3/12/97.
  104.  
  105. Thomas Narten owns getting "IPv6 over Token Ring" issues resolved.
  106.  
  107.  - Working group last call will be done when new Internet Draft is out.
  108.  
  109. Document editor will do a working group last call on BSD API.  Goal is to
  110. publish an informational RFC.
  111.  
  112.  - Sent on 12/10/96.  Working group last call ended 12/24/96.
  113.    A number of comments were received.  Will advance to IESG once a new
  114.    internet draft is available based on comments.
  115.  
  116.  - Done.  Submitted to IESG, IESG approved as Informational RFC.
  117.  
  118. Document editor will submit Tunneling Spec to IESG for proposed standard.
  119.  
  120.  - Sent request to IESG on 12/10/96.  IESG last call sent on 12/30/96
  121.    which ended on 1/17/97.  Many comments received.  IESG restarted last
  122.    call for this document and two GRE documents on IPv4 tunneling.
  123.  
  124.  - Steve Deering currently reviewing GRE documents and will respond to
  125.    IESG last call.  On Agenda for Memphis.
  126.  
  127. Document editor will do a working group last call on Header Compression
  128. specification.
  129.  
  130.  - Sent on 12/10/96.  Working group last call ended 12/24/96.  Comments
  131.    received from Thomas Narten.  Once comments resolved (and new draft
  132.    published) document editor will send to IESG.
  133.  
  134. Hinden and Deering will propose to the mailing list that the ND solicited
  135. node address be changed to fit into a longer prefix
  136.  
  137.  - On Agenda for Memphis.
  138.  
  139. Steve Deering expected to have a draft on "Multihoming / Source Address
  140. Selection" in early 1997.
  141.  
  142.  - Open.
  143.  
  144. Document to do a working group last call on IPv6 Router Alert Option.
  145.  
  146.  - Last call sent on 12/17/96.  Working group last call ended on
  147.    12/31/96.  One minor comment received.  Document editor will send to IESG
  148.    once new ID is published.
  149.  
  150. Chairs to generate a list of changes which are being considered for the
  151. base specifications.
  152.  
  153.  - Needs to be done.
  154.  
  155. Hold an interim meeting to discuss the 8+8 proposal.
  156.  
  157.  - Done.  Held on Feb 27, 28, 1997.
  158.  
  159. Bob Hinden write internet draft on his Router and Networking Renumbering
  160. proposal.
  161.  
  162.  - Matt Crawford volunteered to write draft.
  163.  - Done.  Draft written and on Memphis agenda.
  164.  
  165. Dimitry Haskin and Dave Katz to write a draft proposing adding an option
  166. to BGP4 to carry IPv6 interdomain routes.
  167.  
  168.  - Drafts written for BGP+ and BGP5.  IDR discussed.  Compromise
  169.    discussions underway.
  170.  
  171. Bob Hinden to add to the addressing architecture document prefix
  172. notation.
  173.  
  174.  - Work underway.  Expect to have new draft by ID deadline.
  175.  - Done.  Draft published.
  176.  
  177. Thomas Narten to include in next update of neighbor discovery a rule to
  178. silently drop non-DAD packets which use the unspecified address as the
  179. source of the packet.
  180.  
  181.  - Open
  182.  
  183.  
  184. Action Items from Interim Meeting
  185. ---------------------------------
  186.  
  187. Minutes for Interim meeting, and meeting report / Bob Hinden
  188.  
  189.  - Done.  Sent to IPng list and installed on IPng web site.
  190.  
  191. "WhoAreYou" ICMP Message / Matt Crawford
  192.  
  193.  - Draft missed ID deadline.  Sent to IPng list and on Memphis agenda.
  194.  
  195. Modify Link Name Draft / Dan Harrington
  196.  
  197.  - Update underway.
  198.  
  199. Synthesized AAAA Replies / Jim Bound , Mike O'Dell
  200.  
  201.  - Done.  Jim Bound write draft.
  202.  
  203. Revise Provider Based Addressing Architecture / Mike O'Dell and Bob Hinden
  204.  
  205.  - Work started.   Proposal on Memphis agenda.
  206.  
  207. Unique ID's (ESD's) Assignment / Mike O'Dell, Allison Mankin, Matt Thomas
  208.  
  209.  - Done.  Matt Thomas submitted draft.  On agenda.
  210.  
  211. Experimental Addresses Rewrite:  Bob Hinden
  212.  
  213.  - Waiting for Provider Unicast Formats to settle a bit more.
  214.  
  215. IPoverEthernet/FDDI /  Matt Crawford
  216.  
  217.  - Done.  Internet Draft published.
  218.  
  219. IPoverPPP / Dimitry Haskin
  220.  
  221.  - Done.   Internet Draft published.
  222.  
  223. Lessons from meeting / Matt Crawford, Allison Mankin, Thomas Narten, 
  224.                        John Stewart, Lixia Zhang
  225.  
  226.  - Done.  Internet Draft published.  Discussion on agenda.
  227.  
  228.  
  229. Priority Field / Steve Deering
  230. ------------------------------
  231.  
  232. Discussion on mailing list, but did not reach consensus.  Current proposal
  233. is:
  234.  
  235.   - Declare that 4 bits of Priority are rewritable by routers/ISPs for
  236.     private purposes (and exclude from authentication header).
  237.   - Priority bits have no significance to receivers
  238.   - Convention: Sender sets low order bit to mean interactive traffic.
  239.       o Delay more important than throughput
  240.       o Suggests that routers/ISPs use other bits before touching the
  241.         "interactive bit".
  242.       o Affects queuing only, not routing (since re-writable).
  243.  
  244. After email discussion Deering still thinks that proposal is correct.
  245.  
  246. Charlie Perkins: If left undefined and people do use them, it might be
  247. hard to define them later.
  248.  
  249. Nordmark: Could anyone modify in transit?  Yes.
  250.  
  251. Narten: How many bits do router vendors want?  Also, thinks it is
  252. important to not have interactive bit rewritten to preserve function.
  253.  
  254. John Stewart: Thinks one bit is enough for interactive traffic, but more
  255. bits will be needed for additional services.  Thinks making bits an integer
  256. field instead of individual bits would be better.
  257.  
  258. IPSEC had proposed not including the whole first four bytes of the IPv6
  259. header from authentication.  This is in the latest AH draft.  Would give
  260. us more flexibility.
  261.  
  262. John Stewart:  If we define now, would preclude different usage in future.
  263.  
  264. Nordmark:  Should define what host does to these bits when sending, and
  265. how it should handle these bits when receiving.  Need to do this first.
  266.  
  267. Mike O'Dell, likes the proposal.  Thinks it is best he had heard in
  268. discussion.
  269.  
  270. Changing version field will break header compression.
  271.  
  272. Matt C.  Good to define default action for hosts now, routers could use
  273. them differently later.  Need this to define application behavior.
  274.  
  275. Deering took poll.  More were in favor.  Group will go forward with this
  276. proposal in next version of base IPng specification.  Important to make
  277. sure AH is consistent.  First 32 bits of header should not be included in
  278. authentication computation.
  279.  
  280.  
  281. Conclusions/Results from Interim Meeting
  282. ----------------------------------------
  283.  
  284. Meeting Summary / Bob Hinden
  285. ----------------------------
  286.  
  287. Deering talked.  Showed table of results from interim meeting.
  288.  
  289.    Summarized into the following table:
  290.  
  291.      Legend:  X = do not adopt
  292.               Y = adopt
  293.               * = needs more study
  294.  
  295.      X  Rewriting by routers
  296.      X  Name for Sites & Mapping to/from RG
  297.      *  ESD's
  298.      Y  RG structure
  299.      *  PCB Lookup rules
  300.      X  Pseudo checksum rules
  301.      Y  8byte node ID
  302.      Y  Two faced DNS for site local
  303.      Y  Resolve DNS via ICMP "Who Are You"
  304.      Y  DNS response synthesis
  305.      *  Auto-Injection of prefixes into sites
  306.      Y  Inter-provider partition healing protocol(s)
  307.      *  Use only site-local prefixes for intra-site communication
  308.      *  How much of address is AH
  309.      *  Flow identification change
  310.      *  SA Ident change
  311.  
  312. Shows which items were agreed to do, not to do, and which need more
  313. study.
  314.  
  315.  
  316. Revision to Provider Based Addressing / Bob Hinden
  317. --------------------------------------------------
  318.  
  319. New draft will be called "Aggregation-Based Unicast Address Formats".
  320. This was an output of the Interim meeting.  This will replace RFC-2073
  321. "An IPv6 Provider Based Unicast Address Format" Goal is to provide
  322. additional flexibility based on O'Dell GSE Draft.  Changes include:
  323.  
  324.  - Remove Registry field
  325.  - Base Design around Large Structures
  326.  
  327. Structures
  328.  
  329.           _______________                  _______________
  330.          /               \+--------------+/               \
  331.         (       P1        )    +----+    (       P3        )
  332.         +\_______________/     |    |----+\_______________/
  333.         |                   +--| X  |
  334.         | _______________  /   |    |-+    _______________
  335.         +/               \+    +-+--+  \  /               \
  336.         (       P2        )     / \     +(      P4         )
  337.          \_______________/     /   \      \_______________/
  338.              |                /     \           |       |
  339.              |               /       |          |       |
  340.              |              /        |          |       |
  341.             _|_           _/_       _|_        _|_     _|_
  342.            /   \         /   \     /   \      /   \   /   \
  343.           ( S.A )       ( S.B )   ( P5  )    ( S.D ) ( P6  )
  344.            \___/         \___/     \___/      \___/   \___/
  345.                                      |                 / \
  346.                                     _|_              _/_  \   ___
  347.                                    /   \            /   \  +-/   \
  348.                                   ( S.E )          ( S.F )  ( S.G )
  349.                                    \___/            \___/    \___/
  350.  
  351.  
  352. The aggregation based address format is designed to support both long
  353. haul providers (shown as P1, P2, P3, and P4), interchanges (shown as X ),
  354. multiple levels of subscribers (shown as S.x) and providers (shown at P5
  355. and P6).  Interchanges (unlike current NAP, FIX, etc. connection points)
  356. will allocate IPv6 addresses.  Providers who connect to these
  357. interchanges will also subscribe for long haul service from one or more
  358. long haul providers and achieve a certain degree of addressing
  359. independence from long haul transit providers.
  360.  
  361. Format
  362.  
  363.    | 3 |  13   |    32 bits    |  16 bits  |       64 bits         |
  364.    +---+-------+---------------+-----------+-----------------------+
  365.    |010|  TLA  |    NLA*       |  Subnet   |   Interface ID        |          
  366.    +---+-------+---------------+-----------+-----------------------+
  367.    
  368.    <-----Public Topology------->   Site
  369.                                <----------->
  370.                                  Topology  
  371.                                            <--Interface Identifier->
  372.  
  373. Fields
  374.  
  375.  - FP   Format Prefix (010)
  376.  - TLA  Top Level Aggregator
  377.  - NLA* Next Level Aggregator(s)
  378.  - SUBNET       Site Specific Topology
  379.  - INTERFACE ID Interface Identifier
  380.  
  381. Top Level Aggregator
  382.  
  383.  - Top Level in Addressing Hierarchy
  384.  - Assigned to Organizations providing Public Transit Topology
  385.     o Not to Private Transit Topology
  386.  - Supports 2^^13 TLA's (8K)
  387.     o Additional available by using another FP
  388.  - IANA Assigns Blocks to Registries
  389.     o Registries assign to TLA's
  390.     o Registries get more from IANA
  391.  
  392. Next Level Aggregator
  393.  
  394.  - Used by TLA's to
  395.     o Create TLA Hierarchy
  396.     o Identify Sites
  397.  - TLA's may support NLA's in their own Site ID space
  398.  - NLA's may support NLA's in their...
  399.  - Works exactly like CIDR delegation
  400.  - TLA's assume registry duties for NLA's
  401.  
  402. NLA*
  403.  
  404.    +-----+------------------+--------+-----------------+
  405.    |NLA1 |  Site            | Subnet | Interface ID    |          
  406.    +-----+------------------+--------+-----------------+
  407.          +-----+------------+--------+-----------------+
  408.          |NLA2 |   Site     | Subnet | Interface ID    |          
  409.          +-----+------------+--------+-----------------+
  410.                +-----+------+--------+-----------------+
  411.                |NLA3 | Site | Subnet | Interface ID    |          
  412.                +-----+------+--------+-----------------+
  413.  
  414.  
  415. Proposal was generally well accepted.  Some discussion about fixed
  416. boundaries in these addresses, particularly about the TLA boundary.
  417. This was clarified that it was only there for address allocation and was
  418. not visible by the routing system.
  419.  
  420. Bob Hinden will write a internet draft for "Aggregation-Based Unicast
  421. Address Formats".
  422.  
  423.  
  424. Analysis of GSE Proposal / Matt Crawford and others 
  425. ----------------------------------------------------
  426.  
  427. Most topics will be outcome of PAL1, some were the result of additional
  428. analysis.
  429.  
  430. Motivation for GSE
  431.  - Renumbering must happen to achieve and maintain the necessary
  432.    aggregation to keep routing computation feasible.
  433.     o Make intra-site communication impervious to global renumbering
  434.     o Make renumbering easier to do
  435.  -  Put the routing cost of multi-homing onto the parties involved.
  436.  
  437. GSE Mechanisms
  438.  - Conceal global-scope prefixes from the sites' interiors.
  439.     o Insert source prefix at exit/remove destination prefix at entrance
  440.        - Fixed boundaries in addresses
  441.        - Modifications to checksum, PCB/SA lookup rules
  442.        - Globally unique identifiers for nodes
  443.     o DNS magic
  444.        - Two-faced DNS
  445.        - AAAA synthesis from parts
  446.        - AAAA synthesis from parts
  447.        - RG upward indirection
  448.  - Multiple providers set up fallback tunnels to create the illusion that
  449.    failed links are up
  450.     o Hole-punching" is confined to consenting parties.
  451.  
  452. Major Difficulties
  453.  - Due to host ignorance of prefixes
  454.     o New failure modes due to RG not covered by checksum
  455.     o Can't construct source routes (in general).
  456.     o Hosts can't influence traffic handling by source address selection.
  457.        - Interior routing fluctuations cause source address to thrash
  458.     o Any node that is a tunnel endpoint must act as a border router.
  459.   - Due to DNS modifications
  460.     o Delegation problem:  the one who holds your glue is not the one who
  461.       changes your prefix.
  462.        - No visible solutions
  463.     o Two-faces DNS is required
  464.        - Might be solvable
  465.   - Due to source address rewriting
  466.       o Multicast packets duplicated at multiple site exits.
  467.  
  468. Recommendations
  469.  - Do not hide the global prefixes from the interior nodes.
  470.  - There has to be an overlap period (on the order of days to weeks)
  471.    during prefix reassignments.
  472.  - Define boundaries in addresses
  473.     o Between global and site topology
  474.     o Between routing and node designator
  475.  - Address architecture must be improved for better aggregation.
  476.  - Using site-local addresses can help quite a lot
  477.     o Work on two faced DNS (the alternative is address selection rules
  478.       for hosts)
  479.  - Globally unique end-system designators have potential uses
  480.     o But aren't a panacea.
  481.  - The next address architecture document should accommodate an 8 byte
  482.    unique ESD.
  483.     o Candidate: IEEE EUI-64.
  484.  
  485.   Question: what does "accommodate" mean?  Does it mean require requiring
  486.   globally unique now.  Answer: Yes.
  487.  
  488. Implications
  489.  - Need to work on Two-faced DNS
  490.  - Need to study coordination between renumbering and updating DNS
  491.    delegations
  492.  - Root DNS servers at fixed addresses, globally host-routed?
  493.  - Hosts will do source address selection, even if only by default.
  494.  - Boundaries in global addresses facilitate the use of site-local
  495.    addresses.
  496.  
  497.    Questions: Should we also work on source selection algorithms?  Yes,
  498.               we should be comparing the two approaches.
  499.  
  500.               O'Dell raised difficulty with scaling when hosts have many
  501.               addresses. Doesn't think this will scale.
  502.  
  503.               Do the recommendations mean that I can't use prefix ::1?
  504.               Yes, that would not be allowed.
  505.  
  506.   - Starting off a connection with site-local addresses may become
  507.     inconvenient if one end later goes mobile off-site
  508.      o Could some hosts simply not have site-local addresses?
  509.  
  510.  - Globally unique ESD's preclude routing prefixes of 64 < length < 128
  511.     o Or do they?  If you have an aligned blocks of ESD's
  512.  
  513.  - What's the ESD of an anycast address?
  514.  
  515. Comment that Anycast do not need globally unique, but need ESD which do
  516. not conflict with any real ESD.
  517.  
  518. Question and discussion about stability of dialin assigned addresses.
  519.  
  520. Lixa Z:  Question about what it means to require global unique ESD's.
  521.  
  522. Comment about getting more feedback from DNS "experts".  Agreement we
  523. need more overlook.  Need more coordination.
  524.  
  525. M. Ohta: Asked why did we look at only rewriting destination locator
  526. (based on his proposal of about six months ago).  Wants to be able to rewrite
  527. destination RG.  Could preserve original address in source route header.
  528.  
  529.  
  530. IPv6 over Ethernet & FDDI / Matt Crawford
  531. -----------------------------------------
  532.  
  533. Changes to accommodate ESD's
  534.   - Prefix for stateless auto-config must be /64
  535.   - Auto-config address token is EUI64
  536.   - Link-local address token is EUI64
  537.   - EUI-64 is derived from MAC address
  538.      o 00--8-55-12-34-56  -> 0008:55FF:FE12:3456
  539.      o http://standards.ieee.org/db/oui/tutorials/EUI64.html
  540.  
  541.  
  542. IPv6 over PPP / Dimitry Haskin
  543. ------------------------------
  544.  
  545. Change to make PPP support 64bit interface ID.  Now reserves this size
  546. token.  No changes to date to accommodate global token.  Pending outcome
  547. of global ESD issue.
  548.  
  549.  
  550. IPv6 over ARCNET and Localtalk / Bob Hinden
  551. -------------------------------------------
  552.  
  553. Hinden mentioned both ARCNET and local talk do not have IEEE addresses in
  554. hardware and would need some mechanism to get global identifiers.
  555.  
  556.  
  557. The Use of End System Designators in IPv6
  558. -----------------------------------------
  559.  
  560. IEEE/ANSI EUI Formats
  561.  
  562.  - EUI-64
  563.  
  564.    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  565.    |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
  566.    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  567.  
  568.    <---- company_id -------><-------------vendor supplied id ------>
  569.  
  570.  - IEEE 802
  571.  
  572.    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  573.    |   |   |   |   |   |   | F | F | F | E |   |   |   |   |   |   |
  574.    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  575.  
  576.    <-------  OUI  --------->                <--- vendor id -------->
  577.  
  578.  - FiberChannel
  579.  
  580.    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  581.    |   |   |   |   |   |   | ? |   |   |   |   |   |   |   |   |   |
  582.    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  583.  
  584.    <---- company_id ------->    <-------vendor supplied id -------->
  585.  
  586.  
  587.   Hard problem is what if you do not have an IEEE address in system.
  588.  
  589. IANA EUI Formats
  590.  
  591.  - IPv4 Address
  592.  
  593.    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  594.    | 0 | 0 | 0 | 0 | 5 | E | 1 | 0 | C | 7 | 5 | 1 | D | C | 9 | D |
  595.    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  596.  
  597.    <---- company_id ------->       <-IPv4 Addr (199.81.220.157) --->
  598.  
  599.  - ASN
  600.  
  601.    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  602.    | 0 | 0 | 0 | 0 | 5 | E | 2 | 0 |   |   |   |   |   |   |   |   |
  603.    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  604.  
  605.    <---- company_id ------->       <--- ASN -------><--- Assigned ->
  606.  
  607.  
  608.     o PPP servers could use IANA OUI and IPV4 address.
  609.         - Can not use private use IPv4 addresses
  610.     o Use company ID and Autonomous System number (ASN)
  611.  
  612.    Comment companies do not normally get ASN numbers. Only assigned to
  613.    organizations who are multihomed.
  614.  
  615. Random ESD Format
  616.  
  617.    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  618.    |   | 2 |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
  619.    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  620.  
  621.    <--->   <------------------------------------------------------->
  622.                      60 Random bits
  623.        <--->  Fixed 4 bits (locally administrated address space 
  624.               which is not used by IEEE
  625.  
  626. IPv4 addresses in IPv6
  627.  
  628.  - IPv4 Compatible
  629.  
  630.    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  631.    | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |   |   |   |   |   |   |   |   |
  632.    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  633.  
  634.    <---- company_id ------->       <------ IPv4 Address ----------->
  635.  
  636.  - IPv4 Mapped
  637.  
  638.    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  639.    | 0 | 0 | 0 | 0 | F | F | F | F |   |   |   |   |   |   |   |   |
  640.    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  641.  
  642.    <---- company_id ------->       <------ IPv4 Address ----------->
  643.  
  644.     o IPv4 compatible are OK
  645.     o IPv4 mapped have a problem because conflicts with other assignments.
  646.  
  647.  
  648.  
  649. ESD Pro and Con's / Thomas Narten
  650. ---------------------------------
  651.  
  652. Main Benefit
  653.  - Automatic/transparent deliver of packet to transport endpoint, even if
  654.    source or destination "Routing Stuff" changes (see below)
  655.  - Transport endpoints ar TCP, UDP, IPSEC, etc.
  656.  - Facilitates retroactive fix up of Routing Stuff
  657.     o Mobile nodes says "I just moved" here is my new address"
  658.     o During renumbering: "here is my new preferred address"
  659.     o Required authentication prior to changing "routing stuff"
  660.  
  661. Cons
  662.   - Automatic delivery defined above simplifies implementation, but does
  663.     NOT provide new functionality:
  664.     o Functionality required: IPv6 destination option that says "use
  665.       this address when demultiplexing instead of address in IPv6 header"
  666.     o IPSEC AH provides assurance that option is not a hijack attempt
  667.     o Basic idea has been proposed before
  668.       - Context identifier parameter" in Huitema's "Multihomed TCP" draft.
  669.       - "Source identifier Option" in Bound/Roque "IPv6 Anycasting Service"
  670.         draft.
  671.  - ESD uniqueness requirement adds complexity
  672.     o Intruders guarantee that ESD can not be assumed unique, even if we
  673.       design them to be
  674.     o New denial-of-service attacks possible:
  675.       - Intruder host "borrows" ESD of dilbert.foo.com, opens TCP
  676.         connection to www.bar.com
  677.       - Real dilbert.foo.com opens TCP connection to www.bar.com (using
  678.         same port number)
  679.       - Packets from both connections delivered to same TCP endpoint on
  680.         web server
  681.       - Second connection (real Dilbert) "loses"
  682.       - Can't defend against without requiring authentication.
  683.     o Need way dealing with devices that have no IEEE MAC address.
  684.       Solution possible, but may require some manual configuration.
  685.     o Accidential misdelivery of packet to wrong machine that is using same
  686.       ESD may trigger dangerous error responses.
  687.     o Disallows small subnets
  688.     o Anycast address need ESD that doesn't conflict with existing ESD
  689.       (solutions possible, misconfiguration possible)
  690.  
  691. My opinion
  692.    - Key issues: compare benefits against cost
  693.    - There are real costs, some which are not fully understood
  694.    - Supposed benefits oversold
  695.    - Considered big picture, benefits not worth the cost.
  696.  
  697.  
  698. ----------------------------------------------------
  699. Friday 9-11:30am
  700. ----------------------------------------------------
  701.  
  702. Mobile IP / Dave Johnson
  703. ------------------------
  704.  
  705. Mobile IPv6
  706.  - Allows transparent roaming of IPv6 mobile nodes
  707.     o Routing to mobile node regardless of its current point of
  708.       attachment to the Internet
  709.     o Mobile node is always addressable by its "home agent"
  710.  - High-level overview of operation
  711.     o Care-of addresses from IPv6 address auto-configuration
  712.     o Mobile node sends its own Binding Updates
  713.     o Used for correspondent nodes and home registration
  714.     o Nodes cache binding in a Binding Cache
  715.     o Correspondents route own packets directly to mobile node
  716.  - Current draft is <draft-ietf-mobileip-ipv6-02.txt>
  717.  
  718. Dynamic Home Agent Address Discovery
  719.   - Mobile node may not always know its home agent address
  720.      o While mobile node is away from home
  721.      o Home network may need to be reconfigured
  722.      o Different machine may take over as home agent
  723.   - In Mobile IPv4
  724.      o Mobile node can send to "directed broadcast" address
  725.      o All home agents in home network receive request
  726.      o All reject, giving their own unicast addresses
  727.      o Mobile node tries again with one of these addresses
  728.   - Can't do this in Mobile IPv6 since no broadcast in IPv6
  729.  
  730. Home Agent Discovery Proposal #1
  731.   - To register when don't know own home agent address
  732.      o Mobile node sends "home agent discovery" packet to home network
  733.        router "anycast" address
  734.      o Probably an ICMP message
  735.      o By IPv6, received by one border router on home network
  736.      o Router receiving packet multicasts "home agent discovery" into
  737.        home network to "all home agents group"
  738.      o Home agent returns reply with its IP address to mobile node
  739.      o Mobile node registers to that IP address
  740.   - Implementation would be required in ALL IPv6 routers
  741.  
  742. Proposal #2
  743.  - Define "home agent anycast" address
  744.     o Prefix defines which subnet
  745.     o Bottom part could be all-ones (instead of all-zeros)
  746.  - For home agent discovery
  747.     o Mobile node sends request to home agent anycast address for home
  748.       network
  749.     o Request answered home agent, giving unicast address
  750.     o Mobile node registers to that IP address
  751.  - Implementation of this would be required in ALL IPv6 routers
  752.  
  753. Comments, Please
  754.  - Need feedback from IPng working group
  755.  - Send to mobile-ip@smallworks.com (mobile ip mailing list)
  756.  
  757. Topologically Correct Addressing
  758.  - Packets sent to a mobile node:
  759.     o Source address = correspondent node address
  760.     o Destination address = mobile node care-of address
  761.     o Routing header = mobile node home address
  762.     o (Problem: size of Routing header in every packet)
  763.  - Packets sent from a mobile node
  764.     o Source address = mobile node home address
  765.     o Destination address = correspondent node address
  766.     o Problem: ingress filtering drops all of these packets!
  767.  
  768. Proposed Solution: Source Address Remapping
  769.  - Mobile node uses care-of-address as source address..
  770.    But only while packet on its way tot he destination node
  771.  - At the sender:
  772.     o Sender builds packet using home address
  773.     o Then substitute care-of address as source
  774.     o Makes packet source address topologically correct
  775.  - At the receiver (only the end destination node)
  776.     o Receiver substitutes correct source address (home address) back
  777.       into packet in place of care-of address.
  778.  - Implementation of this would be required in ALL IPv6 routers
  779.  
  780. Source Addressing Remapping Method #1
  781.  - Two source addresses in "every" packet
  782.     o Carry real source address in a destination option
  783.     o If present, receiver substitutes into IP header before passing it
  784.       to the transport layer
  785.     o Used for receipt of this packet only
  786.     o Option creates no state in the receiver
  787.     o Option does not affect any routing from receiver
  788.     o Option is authenticated if packet itself is authenticated
  789.     o Otherwise, no extra authentication needed.
  790.  
  791. SAR, Method #2
  792.  - One one source address (the care-of address) in packet
  793.     o Also a bit in every packet: "source is a care-of-address"
  794.     o Bit probably encoded by presence/absence of a destination option
  795.     o Could also be bit in header or bit in source address
  796.     o Receiver caches <care-of address, home address> mappings
  797.     o If bit set in received packet and no cache entry:
  798.        - Receiver request mapping form care-of address
  799.        - Reply MUST be authenticated
  800.        - Receiver saves original packet and processes after reply
  801.        - Request/reply is probably ICMP
  802.  
  803. Some discussion.  Will be discussed on mailing list.
  804.  
  805.  
  806.  
  807. Synthesis of DNS aAA and RG Resource Records / Jim Bound
  808. --------------------------------------------------------
  809.  
  810. Motivation
  811.  - IPng w..g PAL1 interim meeting on alternative addressing architecture
  812.  - Add connotation of location and identifier to DNS Resource Record
  813.    "syntax" for future use.
  814.  - Avoid alteration to DNS protocol and APIs for IPv6
  815.  - Adjunct to other Interim meeting action items
  816.  - Determine initial affect to applications and DNS syntax and
  817.    processing. 
  818.  
  819. Processing Model
  820.  - No change to the DNS protocol
  821.  - Client resolve still requests AAAA records in query (e.g.,
  822.    gethostbyname2() ), using ESD address
  823.  - DNS server synthesizes from ESD address an AAAA record for each RG
  824.    record associated with an aAA ESD
  825.  - DNS returns in query response one AAAA record for each RG + aAA pair
  826.    synthesized at the DNS server.
  827.  - Transparent to client applications during the query operations.
  828.  
  829. New aAA and RG Types
  830.  
  831.     foo.bar.com  IN    aAA   aa:bb:cc:dd:ee:ff:01 /* ESD */
  832.                  IN    RG    5f09::/??
  833.                  IN    RG    5f08::/??
  834.  
  835. To be Determined
  836.  - RG and ESD length, semantics, and uniqueness.
  837.  - Processing cached AAAA records for resolvers
  838.  - Affects RFC 1886 and DHCPv6 extensions
  839.  - Dynamic updates to DNS must deal with granularity of aAA and RG
  840.    records
  841.  - Reverse DNS processing is TBD.
  842.  
  843. Numbering point-to-point and boundary links / John Stewart
  844. ----------------------------------------------------------
  845.  
  846. If global ESD's, mask lengths will be either up to 64 or 128.  Nothing
  847. in between.
  848.  
  849. Notion that like in IPv4, with current form of interconnects, some global
  850. RG would have to be assigned to interconnects (e.g., NAP, etc.).
  851.  
  852.  
  853. Solicited Node Definition / Steve Deering
  854. -----------------------------------------
  855.  
  856. Issue was wanting to avoid a many to one mapping to Ethernet multicast
  857. addresses.  Don't want to have collisions.  L2 filtering, etc.
  858.  
  859. Proposal was to allocate IPv6 multicast addresses to not have
  860. multicast group > 32bits.  ND solicited addresses conflict with this
  861. approach.
  862.  
  863. Currently:
  864.  
  865.     FF02::1:xxxx:xxxx
  866.  
  867. Proposes:
  868.  
  869.     FF02::1:FFxx:xxxx
  870.  
  871. Working group agreed adopt change.  Will go into Addressing Arch and ND
  872. drafts.  New addressing architecture w/ new solicited node definition soon
  873. because ND and IPoverFoo need to copy definitions.
  874.  
  875.  
  876. IPv6 Tunneling Spec and GRE / Steve Deering
  877. -------------------------------------------
  878.  
  879. IPv6 tunneling spec has gone through IPng last call and IETF last call
  880. twice.  IESG want to form a working group to resolve the number of
  881. differently tunneling specs.  GRE IPv4 specs submission has caused IESG
  882. to take a deeper look.  One of the original IPng working group
  883. requirements was to define IPv6 tunneling.  We only want one tunneling
  884. specification for IPv6.
  885.  
  886. Alex Conta:  GRE specification is not ready for an IPv4 specification because
  887. it is not complete.  It does not cover IPv6 tunneling as currently
  888. written.  Specs are not compete.
  889.  
  890. Jeff Burgen / AD: IESG has decided to look at tunneling overall.  Will be
  891. resolved to quickly.  The new group be in the internet area.  The AD's will
  892. scope work.  Doesn't want to drag on a long time.
  893.  
  894. Deering suggested that IPv6 need not be in that charter of this group.
  895. IPv6 already has one specification.
  896.  
  897. IPng Chairs will write strong note to IESG requesting IPv6 not be
  898. included in this new working group and concern about the delay to
  899. existing IPv6 work.
  900.  
  901.  
  902. Router Renumbering for IPv6 / Matt Crawford
  903. -------------------------------------------
  904.  
  905. Internet draft written by Matt Crawford based on presentation at previous
  906. IETF by Bob Hinden
  907.  
  908. Router Renumbering (RR) Packet contains
  909.     - Anti-replay fields
  910.     - Zero or more Prefix Control Operations (PCOs), each of which has:
  911.         
  912. [missing remainder of slide]
  913.  
  914. RR Message Processing
  915.     - Check for valid sequence number
  916.         o Optionally check for valid replay
  917.     - Verify authentication
  918.     - For each PCO
  919.         o For each interface
  920.             - For each address and/or Prefix on that interface
  921.                 o Compatible to MatchPrefix, if it matches,
  922.                     - Preform operation
  923.                     - Do not create duplicate prefixes
  924.  
  925. Why not use SNMP
  926.     - Multicast
  927.     - Renumbering will be "more fundamental" than other management
  928.       functions
  929.     - Security
  930.  
  931. Why not use IPSEC for Authentication
  932.     - SA is looked up by SPI + destination address, but destination
  933.       addresses are changing during RR.
  934.     - No dynamic key negotiation protocol for multicast destination
  935.       (correct me if I am wrong)
  936.  
  937.    Based on discussion will change draft to HMAC SHA1
  938.  
  939.    Jim Bound mentioned that new docs need to require method for key
  940.    selection.
  941.  
  942. Open Issues
  943.  - More than 1 match on a single interface
  944.     o repeat operation on each match
  945.  - Require duplicate suppression, or advise against construction of
  946.    non-idempotent combinations?
  947.  - All-routers multicast address is currently only defined at node- and
  948.    link-local scope.  Site- or org-scope would also be useful.
  949.  - Asymmetric authentication scheme might be more appealing
  950.  - No attempt to distribute information for RA fields other than Prefix
  951.    information (e.g., hop limit.)
  952.  
  953. Nordmark: Thinks this is a good idea.  We should be careful to not
  954. include things which could break things.  Would be better to make it
  955. harder to keep things from breaking.  Might require more elaborate
  956. mechanisms and/or procedures.  Need to be careful to make it harder.
  957.  
  958. Next steps to update draft to use HMAC and finish missing sections.
  959. Think about Nordmark suggestions.
  960.  
  961.  
  962. Advertising site prefixes in RAs / Erik Nordmark
  963. ------------------------------------------------
  964.  
  965. Announcing Site Prefixes in Router Advertisements
  966.  - Goals:
  967.     o Limit effect of renumbering by ensuring that traffic local to the
  968.       site use site-local addresses
  969.     o Do this without requiring a two-faced DNS (i.e., no site local in
  970.       the DNS)
  971.  - Proposal
  972.     o Advise the global prefixes (w/ lifetimes) for the site in ND
  973.       messages
  974.     o The host use this info to maintain a list of the current site
  975.       prefixes
  976.     o The host resolver (gethostbyname function) checks against list of
  977.       prefixes after resolving the name.
  978.     o When one of the addresses retrieves from the DNS matches one of the
  979.       site prefixes (i.e., the first N bits match) then add the corresponding
  980.       site-local address to the front....
  981.  
  982. [slides showing how to encode in prefix advertisements]
  983.  
  984. [missing remainder]
  985.  
  986.  
  987.  
  988. Prefix Notation / Bob Hinden
  989. ----------------------------
  990.  
  991. Prefix notations was added to current draft of addressing architecture
  992. document.  General form proposed is:
  993.  
  994.     ipv6-address / prefix-length
  995.  
  996. Examples:
  997.  
  998.     12AB:0000:0000:CD30:0000:0000:0000:0000/60
  999.     12AB::CD30:0:0:0:0/60
  1000.     12AB:0:0:CD30::/60
  1001.     12AB:0:0:CD30/60
  1002.  
  1003. It included a notation (shown in last example) to not require "::" at the
  1004. end of the prefix.  Implied left justifying prefix and zero fill remainder.
  1005.  
  1006. General consensus of group was that his added complexity and to not
  1007. support this (e.g., require "::").
  1008.  
  1009.  
  1010. Who Are You / Matt Crawford (5 min)
  1011. ----------------------------------------------------
  1012.  
  1013. Motivation
  1014.  
  1015.  - GSE would have made it difficult to have reverse lookup domains.
  1016.  - IN=ADDR.ARPA poorly maintained, will IP6.INT be better.
  1017.  - Maintenance of delegations will be more difficult in the expected
  1018.    frequent-renumbering environment of "THE FUTURE".
  1019.  - For access control, or even logging, IP6.INT provides nothing but a
  1020.    hint anyway
  1021.  
  1022. History
  1023.  - Experimental RFC by  W. Simpson, "ICMP Domain Name Messages", RFC 1788.
  1024.  
  1025. Format of Packet
  1026.  
  1027.   - ICMP Message
  1028.  
  1029.      0                   1                   2                   3
  1030.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1031.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1032.     |     Type      |     Code      |           Checksum            |
  1033.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1034.     |              ID               |            unused             |
  1035.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1036.     |                                                               |
  1037.     +                            Cookie                             +
  1038.     |                                                               |
  1039.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1040.     |                          Time-To-Live                         |
  1041.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1042.     |    NameLen    |                   FQDN ...                    |
  1043.     +-+-+-+-+-+-+-+-+                                               +
  1044.     /                                                               /
  1045.     +                                                               +
  1046.     |                                                               |
  1047.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1048.  
  1049.  
  1050.    Fields:
  1051.  
  1052.    Type        TBA1 - FQDN Query (more pronouncably known as Who-Are-
  1053.                You or WRU).
  1054.                TBA2 - FQDN Reply (possibly to be known as Sam-I-Am).
  1055.  
  1056.    Code        For FQDN Query, always zero.
  1057.                For FQDN Reply:
  1058.  
  1059.                0   Indicates that the Time-To-Live field is meaningful
  1060.  
  1061.                1   Indicates that the responding node cannot provide a
  1062.                    meaningful TTL for its Address-to-FQDN association.
  1063.  
  1064.    Checksum    The ICMPv6 checksum.
  1065.  
  1066.    ID          A 16-bit field to aid in matching replies and requests.
  1067.                Its value is chosen by the querier and copied from a
  1068.                Request to a Reply by the responder.
  1069.  
  1070.    Cookie      An opaque 64-bit field to aid in avoiding spoofing.  Its
  1071.                value is chosen by the querier and copied from a Request
  1072.                to a Reply by the responder.
  1073.  
  1074.    Time-To-Live
  1075.                The number of seconds that the name may be cached.  For
  1076.                compatibility with DNS [1035], this is a 32-bit signed,
  1077.                2's-complement number, which must not be negative.
  1078.  
  1079.    NameLen     The length in octets of the FQDN, as an 8-bit unsigned
  1080.                integer.
  1081.  
  1082.    FQDN        The fully-qualified domain name of the responder, as a
  1083.                sequence of NameLen US-ASCII octets, with periods
  1084.                between the components.
  1085.  
  1086.    The last three fields (Time-To-Live, NameLen and FQDN) are not
  1087.    present in the FQDN Query.
  1088.  
  1089.  
  1090. Steve Deering: Wondered about supporting multiple names in packet?
  1091.  
  1092. Alex Conta:  How different form DNS?  Simpler fewer options/etc.
  1093. Intended only for reverse lookups.
  1094.  
  1095. Usage and Issues
  1096.  - The internet could easily get clogged with these messages.  Therefore,
  1097.    this could be a back-end to DNS servers, which would catch the answers.
  1098.     o What's a good TTL when the responder can't provide one?
  1099.     o What about a timeout for negative caching?
  1100.  
  1101. Question about viability of current reverse lookup database.  Questioner
  1102. thought premise was untrue.  Thought was was getting better.  Response was
  1103. that with renumbering this would get even harder to maintain.  This
  1104. mechanism does not require manual configuration of a database.
  1105.  
  1106. Important to keep this simple.
  1107.  
  1108. Features
  1109.  - PLUS:  Routing system takes the place of IP6.INT delegation
  1110.     o Always current
  1111.  - PLUS" A Meaningful TTL is usually available from Autoconf. or DHCP.
  1112.  - MINUS: Target must be up and reachable to do a lookup
  1113.     o But is it meaningful to say a certain FQDN is associate with an
  1114.       address when it isn't.
  1115.  
  1116. Comment.  Dialin users do not know their name.  DHCP could tell host
  1117. their domain name when they get the address.  Could also return with a
  1118. empty name length.
  1119.  
  1120. What about negative caching?
  1121.  
  1122.  
  1123. Inter-Domain Routing Status / Bob Hinden
  1124. ----------------------------------------
  1125.  
  1126. Covered in document status.
  1127.  
  1128.  
  1129. ND Zero Lifetime advertisement issue / Thomas Narten
  1130. ----------------------------------------------------
  1131.  
  1132. Denial-of-Service vulnerability in Stateless Addrconf
  1133.  
  1134. Attack:
  1135.  - Intruder connects to local link (remote access not sufficient)
  1136.  - Listen for RAs, determine what prefixes are in active use
  1137.  - Send out a single RA, advertise in-use prefix(es) with lifetime of
  1138.    zero
  1139.  
  1140. Consequence:
  1141.  - Receiving host immediately invalidates address(es) formed via stateless
  1142.    autoconf for the specified prefix(es).
  1143.  - Host immediately terminates all transport layer connections
  1144.    (addresses) in use no longer exists).
  1145.  - Every host acts on received RA, entire network effectively brought
  1146.    down. 
  1147.  - Subsequent RA containing correct (no-zero) Lifetime does not undo
  1148.    damage. 
  1149.  
  1150. One Possible Solution:
  1151.  - When a prefix lifetime reaches zero, host enters DELAY state, doesn't
  1152.    actually invalidate for two additional hours.
  1153.  - Receipt of subsequent lifetime value > zero cancels DELAY state
  1154.  - While in DELAY state, silently ignore additional Lifetime values of
  1155.    zero (for receiving prefixes)
  1156.  - Result: Intruder's zero Lifetime advertisement effectively ignored;
  1157.    subsequent RAs from real router cancel intruders RA before DELAY state
  1158.    expires. 
  1159.  
  1160. Question for WG?
  1161.  - Is this significant threat?
  1162.  - Is the cost of fixing vulnerability small enough to justify.
  1163.  - Should we fix problem?
  1164.  
  1165. There are plenty of denial-of-service vulnerabilities already: Why fix
  1166. this one given the others?
  1167.  
  1168.  - Other attacks must target individual hosts, one at a time.
  1169.  - Other attacks disrupt first-hop path, not the hosts themselves.
  1170.     o When intruder leaves, path is restored; host may be able to
  1171.       continue.
  1172.     o TCP connections break on a timeout, which takes several minutes
  1173.     o Doing long-term damage require long-term presence of intruder
  1174.       (increasing likelihood they will be discovered). 
  1175.     o Vulnerabilities in IPv6 are analogous to those in IPv4 (i.e., IPv6
  1176.       doesn't make problem worse than what we have today).
  1177.  - In contract to IPv4, IPv6 zero lifetime attack:
  1178.     o Single packet is processed by all hosts in the same way.
  1179.     o Host actively terminates all existing transport connections
  1180.       immediately, no recovery possible.
  1181.     o IPv4 has nothing like this; IPv6 has introduced a vulnerability not
  1182.       present in IPv4.
  1183.  
  1184. Suggestion that before invalidating prefix, send a RS and see if RA is
  1185. consistent with message which invalidated prefix.  Discussion and
  1186. additional suggestions.
  1187.  
  1188. General consensus to fix vulnerability but there are issues with
  1189. proposed mechanism.  Author will propose to mailing list.
  1190.  
  1191.  
  1192. Advanced API Spec / Matt Thomas
  1193. -------------------------------
  1194.  
  1195. Any last comments, authors would like to issue working group last call.
  1196.  
  1197. Document editor will do a working last call for Informational RFC.
  1198.  
  1199.  
  1200.  
  1201. SNMP Issues / Margaret Forythe
  1202. ------------------------------
  1203.  
  1204. Couple of issue with current MIB drafts and discuss solutions.
  1205.  
  1206. IPv6 MIB Issues
  1207.  - Separate TCP/UDP tables for IPv4 and IPv6
  1208.  - No way to represent an IP address in a MIB that can be ether IPv4 or
  1209.    IPv6.
  1210.  - Various Nit's
  1211.     o IP Routing table updates
  1212.     o IPv6IfIndex as index in TCP/UDP Tables
  1213.  
  1214. Possible Solution(s)
  1215.  - Unified IP Address format
  1216.  - Single UDP &TCP Tables for IPv6 & IPv4 "connections"
  1217.  - Minor MIB cleanup
  1218.  
  1219. Unified IP Address
  1220.  - Type/version in IP address type?
  1221.  - Octet string or OID?
  1222.  - SMI Change or Textual conv.
  1223.     o SMI change (new App. type) allows type discrimination in SNMP
  1224.       packet.
  1225.     o SMI change does not permit backwards compat. to current
  1226.       managers/agents.
  1227.     o SMI change may be politically difficult
  1228.     o Display hints in textual convention do not give info to
  1229.       mgr. unfamiliar w/ particular MIB.  SMI App types do.
  1230.  
  1231. UnifiedIPAddress::= textual convention
  1232.  
  1233.  DISPLAY HINT "X" (?)
  1234.  
  1235.  STATUS current
  1236.  
  1237.  DESCRIPTION
  1238.  
  1239.    "IP Address type for both IPv4 or IPv6 addresses.  Particular type can
  1240.     be determined from length.  Length of 4 = IPv4; 16 = IPv6.
  1241.     Addresses are stored in network byte order.
  1242.     IPv4 addresses should be displayed as with display hint "1d.:; IPv6
  1243.     addresses as with "2x:"."
  1244.  
  1245.   SYNTAX OCTET STRING (SIZE (4 | 16))
  1246.  
  1247.   SMI Applications Type -
  1248.     UnifiedIPAdress ::=
  1249.       [APPLICATION 7]
  1250.         IMPLICIT OCTET STRING (SIZE (4|16))
  1251.  
  1252. Will work with MIB author to resolve issues.  When new drafts are out,
  1253. IPng Document Editor will issue w.g. last call to move the to
  1254. Experimental status.
  1255.  
  1256.  
  1257. Destination Locator Rewrititing / Masataka Ohta
  1258. ------------------------------------------------
  1259.  
  1260. Motivation
  1261.  
  1262. Protocol Modifications
  1263.  - Don't checksum-protect destination locator
  1264.  - Modify routing header (w/ authentication) to Preserve the Original
  1265.    Locators 
  1266.  - PCB lookup with Source and Destination ESDs (both Checksummed).
  1267.  
  1268. Modifications to Routing Header
  1269.  - Add address[0] to contain the first destination address
  1270.     o Extra 16 byte in header
  1271.  - Copy, don't swap
  1272.     o Faster operation expected
  1273.     o Same level of security
  1274.  
  1275.   [slide showing change to pkt format]
  1276.  
  1277. Comment:  This looks like what Dave Johnson is proposing for mobile IP.
  1278. Might be able to combine?
  1279.  
  1280.  
  1281. Global ESD Proposal / Bob Hinden
  1282. --------------------------------
  1283.  
  1284. Presented a proposal which would keep open the option for future
  1285. transport protocols to use global ESD.  Proposal was as follows:
  1286.  
  1287.   - Require all Interface ID be constructed using EUI-64 framework.  Easy
  1288.     for both for devices which have hardware 48bit MAC's and with the use
  1289.     of the IANA or vendor specific prefix, easy for serial lines, tunnel
  1290.     interfaces, localtalk, etc.  Only cost is use of 64bit ID's.
  1291.  
  1292.   - Part of EUI64 is a bit which says if the address has global scope
  1293.     (uniqueness).  We require that bit be set correctly.  EUI-64 which
  1294.     are built from hardware MAC will be global.  Serial lines, tunnel end
  1295.     points, localtalk, etc. will not.
  1296.  
  1297.   - We do not make any change to current TCP/UDP connection
  1298.     identification, pseudo checksum, etc.  Current transport protocols
  1299.     will treat all addresses as opaque 128bit quantities.
  1300.  
  1301.   - New transport protocols and/or research projects can tell if the
  1302.     destination with which they are about to communicate has an address
  1303.     with a global identifier when they get the results of a DNS lookup.  If
  1304.     so, then can do what ever ESD magic they want.  In practice many
  1305.     (most?) interface ID's will be global.
  1306.  
  1307. This proposal would "keep the door open" for global ESDs but limit the
  1308. impact now.  The only cost now is requiring 64 bit interface ID and
  1309. setting the global scope bit correctly.
  1310.  
  1311. Considerable discussion resulted.  Chairs polled the working group:
  1312.  
  1313.   0  voted for global ESDs in IPv6
  1314.   7  voted for no global ESD in IPv6 (e.g., keeping current interface ID
  1315.      behavior)
  1316.   33 voted for proposal to use EUI-64 global/local bit to identify if
  1317.      interface ID is global.
  1318.  
  1319. This was a rough consensus to adopt this approach.  Will be added to
  1320. addressing architecture document.
  1321.  
  1322.  
  1323. ---------------------------------------------------------------------------
  1324. ---------------------------------------------------------------------------
  1325.  
  1326.  
  1327.