Editor's Note:  These minutes have not been edited.


IPng Meeting
Memphis IETF
April 10 & 11, 1997

Bob Hinden, Ipsilon Networks  / co-chair
Steve Deering, Cisco Systems / co-chair

Minutes taken and edited by Bob Hinden

------------------------------------------------------------------------

Agenda
-------

 Thursday 1-3pm
   Introduction and Bash Agenda / Steve Deering (5 min)
   Document Status / Bob Hinden (5 min)
   Review of Action Items for Previous Meetings / Bob Hinden (5 min)
   Priority Field / Steve Deering (15 min)
   Conclusions/Results from Interim Meeting / (80 min)
      Meeting Summary / Bob Hinden (5 min)
      Revision to Provider Based Addressing / Bob Hinden (10 min)
      Analysis of GSE Proposal / Matt Crawford and others (25 min)
      IPv6 over Ethernet & FDDI / Matt Crawford (5 min)
      IPv6 over PPP / Dimitry Haskin (5 min)
      IPv6 over ARCNET and LocalTalk / Bob Hinden (5 min)
      The Use of End System Designators in IPv6 / Matt Thomas (5 min)
      Routing Goop and AAAA Records in DNS / Jim Bound (5 min)
      Numbering point-to-point and boundary links / John Stewart (5 min)
      ESD Pro and Con's / Thomas Narten (10 min)

 Friday 9-11:30am
   Conclusions/Results from Interim Meeting Continued / 60min
   Solicited Node Definition / Steve Deering (15 min)
   IPv6 Tunneling Spec and GRE / Steve Deering (15 min)
   Router Renumbering for IPv6 / Matt Crawford & Bob Hinden (15 min)
   Advertising site prefixes in RAs / Erik Nordmark (10 min)
   Prefix Notation / Bob Hinden (5 min)
   Who Are You / Matt Crawford (5 min)
   Inter-Domain Routing Status / Bob Hinden (5 min)
   ND Zero Lifetime advertisement issue / Thomas Narten (5 min)
   Advanced API Spec / Matt Thomas (5 min)
   Moving Base IPv6 Specs to Draft Standard / Steve Deering (5 min)
   Wrap Up and Action Items / Bob Hinden (5 min)


Thursday 1-3pm
--------------

Introduction and Bash Agenda / Steve Deering
--------------------------------------------

Steve Deering introduced meeting.  Asked for agenda changes.  Request to
add slot for Mobile IP and an SNMP issue

Document Status / Bob Hinden
----------------------------

The following RFC's were published as Proposed Standard:

 - An IPv6 Provider-Based Unicast Address Format , RFC 2073
 - RIPng for IPv6 , RFC 2080

The  IESG Approved for Informational RFC:

 - Basic Socket Interface Extensions for IPv6

IETF Last Calls were completed for:

 - Generic Packet Tunneling in IPv6 Specification

The IPng document editor submitted to IESG for IETF Last Call:

 - TCP and UDP over IPv6 Jumbograms

Working Group Last Call were completed for:

 - Header Compression for IPv6
 - IPv6 Router Alert Option

These will be advance as soon as updated Internet Drafts are published
based on the comments received during the last calls.

Review of Action Items for Previous Meetings / Bob Hinden
---------------------------------------------------------

Action Items from San Jose IETF
-------------------------------

Steve Deering will write up description of proposed changes to Priority
Field and send to IPng list.

 - OBE based on discussion on IPng list.  Need to get closure at Memphis
   meeting. On Agenda for Memphis.

Document editor will send email to IANA to add default hop limit of 64
parameter to IANA registry for IPv6 defaults.

 - Sent on 12/12/96.  Can't find it on IANA web site.
 - Resent on 3/12/97.

Thomas Narten owns getting "IPv6 over Token Ring" issues resolved.

 - Working group last call will be done when new Internet Draft is out.

Document editor will do a working group last call on BSD API.  Goal is to
publish an informational RFC.

 - Sent on 12/10/96.  Working group last call ended 12/24/96.
   A number of comments were received.  Will advance to IESG once a new
   internet draft is available based on comments.

 - Done.  Submitted to IESG, IESG approved as Informational RFC.

Document editor will submit Tunneling Spec to IESG for proposed standard.

 - Sent request to IESG on 12/10/96.  IESG last call sent on 12/30/96
   which ended on 1/17/97.  Many comments received.  IESG restarted last
   call for this document and two GRE documents on IPv4 tunneling.

 - Steve Deering currently reviewing GRE documents and will respond to
   IESG last call.  On Agenda for Memphis.

Document editor will do a working group last call on Header Compression
specification.

 - Sent on 12/10/96.  Working group last call ended 12/24/96.  Comments
   received from Thomas Narten.  Once comments resolved (and new draft
   published) document editor will send to IESG.

Hinden and Deering will propose to the mailing list that the ND solicited
node address be changed to fit into a longer prefix

 - On Agenda for Memphis.

Steve Deering expected to have a draft on "Multihoming / Source Address
Selection" in early 1997.

 - Open.

Document to do a working group last call on IPv6 Router Alert Option.

 - Last call sent on 12/17/96.  Working group last call ended on
   12/31/96.  One minor comment received.  Document editor will send to IESG
   once new ID is published.

Chairs to generate a list of changes which are being considered for the
base specifications.

 - Needs to be done.

Hold an interim meeting to discuss the 8+8 proposal.

 - Done.  Held on Feb 27, 28, 1997.

Bob Hinden write internet draft on his Router and Networking Renumbering
proposal.

 - Matt Crawford volunteered to write draft.
 - Done.  Draft written and on Memphis agenda.

Dimitry Haskin and Dave Katz to write a draft proposing adding an option
to BGP4 to carry IPv6 interdomain routes.

 - Drafts written for BGP+ and BGP5.  IDR discussed.  Compromise
   discussions underway.

Bob Hinden to add to the addressing architecture document prefix
notation.

 - Work underway.  Expect to have new draft by ID deadline.
 - Done.  Draft published.

Thomas Narten to include in next update of neighbor discovery a rule to
silently drop non-DAD packets which use the unspecified address as the
source of the packet.

 - Open


Action Items from Interim Meeting
---------------------------------

Minutes for Interim meeting, and meeting report / Bob Hinden

 - Done.  Sent to IPng list and installed on IPng web site.

"WhoAreYou" ICMP Message / Matt Crawford

 - Draft missed ID deadline.  Sent to IPng list and on Memphis agenda.

Modify Link Name Draft / Dan Harrington

 - Update underway.

Synthesized AAAA Replies / Jim Bound , Mike O'Dell

 - Done.  Jim Bound write draft.

Revise Provider Based Addressing Architecture / Mike O'Dell and Bob Hinden

 - Work started.   Proposal on Memphis agenda.

Unique ID's (ESD's) Assignment / Mike O'Dell, Allison Mankin, Matt Thomas

 - Done.  Matt Thomas submitted draft.  On agenda.

Experimental Addresses Rewrite:  Bob Hinden

 - Waiting for Provider Unicast Formats to settle a bit more.

IPoverEthernet/FDDI /  Matt Crawford

 - Done.  Internet Draft published.

IPoverPPP / Dimitry Haskin

 - Done.   Internet Draft published.

Lessons from meeting / Matt Crawford, Allison Mankin, Thomas Narten, 
                       John Stewart, Lixia Zhang

 - Done.  Internet Draft published.  Discussion on agenda.


Priority Field / Steve Deering
------------------------------

Discussion on mailing list, but did not reach consensus.  Current proposal
is:

  - Declare that 4 bits of Priority are rewritable by routers/ISPs for
    private purposes (and exclude from authentication header).
  - Priority bits have no significance to receivers
  - Convention: Sender sets low order bit to mean interactive traffic.
      o Delay more important than throughput
      o Suggests that routers/ISPs use other bits before touching the
        "interactive bit".
      o Affects queuing only, not routing (since re-writable).

After email discussion Deering still thinks that proposal is correct.

Charlie Perkins: If left undefined and people do use them, it might be
hard to define them later.

Nordmark: Could anyone modify in transit?  Yes.

Narten: How many bits do router vendors want?  Also, thinks it is
important to not have interactive bit rewritten to preserve function.

John Stewart: Thinks one bit is enough for interactive traffic, but more
bits will be needed for additional services.  Thinks making bits an integer
field instead of individual bits would be better.

IPSEC had proposed not including the whole first four bytes of the IPv6
header from authentication.  This is in the latest AH draft.  Would give
us more flexibility.

John Stewart:  If we define now, would preclude different usage in future.

Nordmark:  Should define what host does to these bits when sending, and
how it should handle these bits when receiving.  Need to do this first.

Mike O'Dell, likes the proposal.  Thinks it is best he had heard in
discussion.

Changing version field will break header compression.

Matt C.  Good to define default action for hosts now, routers could use
them differently later.  Need this to define application behavior.

Deering took poll.  More were in favor.  Group will go forward with this
proposal in next version of base IPng specification.  Important to make
sure AH is consistent.  First 32 bits of header should not be included in
authentication computation.


Conclusions/Results from Interim Meeting
----------------------------------------

Meeting Summary / Bob Hinden
----------------------------

Deering talked.  Showed table of results from interim meeting.

   Summarized into the following table:

     Legend:  X = do not adopt
              Y = adopt
              * = needs more study

     X  Rewriting by routers
     X  Name for Sites & Mapping to/from RG
     *  ESD's
     Y  RG structure
     *  PCB Lookup rules
     X  Pseudo checksum rules
     Y  8byte node ID
     Y  Two faced DNS for site local
     Y  Resolve DNS via ICMP "Who Are You"
     Y  DNS response synthesis
     *  Auto-Injection of prefixes into sites
     Y  Inter-provider partition healing protocol(s)
     *  Use only site-local prefixes for intra-site communication
     *  How much of address is AH
     *  Flow identification change
     *  SA Ident change

Shows which items were agreed to do, not to do, and which need more
study.


Revision to Provider Based Addressing / Bob Hinden
--------------------------------------------------

New draft will be called "Aggregation-Based Unicast Address Formats".
This was an output of the Interim meeting.  This will replace RFC-2073
"An IPv6 Provider Based Unicast Address Format" Goal is to provide
additional flexibility based on O'Dell GSE Draft.  Changes include:

 - Remove Registry field
 - Base Design around Large Structures

Structures

          _______________                  _______________
         /               \+--------------+/               \
        (       P1        )    +----+    (       P3        )
        +\_______________/     |    |----+\_______________/
        |                   +--| X  |
        | _______________  /   |    |-+    _______________
        +/               \+    +-+--+  \  /               \
        (       P2        )     / \     +(      P4         )
         \_______________/     /   \      \_______________/
             |                /     \           |       |
             |               /       |          |       |
             |              /        |          |       |
            _|_           _/_       _|_        _|_     _|_
           /   \         /   \     /   \      /   \   /   \
          ( S.A )       ( S.B )   ( P5  )    ( S.D ) ( P6  )
           \___/         \___/     \___/      \___/   \___/
                                     |                 / \
                                    _|_              _/_  \   ___
                                   /   \            /   \  +-/   \
                                  ( S.E )          ( S.F )  ( S.G )
                                   \___/            \___/    \___/


The aggregation based address format is designed to support both long
haul providers (shown as P1, P2, P3, and P4), interchanges (shown as X ),
multiple levels of subscribers (shown as S.x) and providers (shown at P5
and P6).  Interchanges (unlike current NAP, FIX, etc. connection points)
will allocate IPv6 addresses.  Providers who connect to these
interchanges will also subscribe for long haul service from one or more
long haul providers and achieve a certain degree of addressing
independence from long haul transit providers.

Format

   | 3 |  13   |    32 bits    |  16 bits  |       64 bits         |
   +---+-------+---------------+-----------+-----------------------+
   |010|  TLA  |    NLA*       |  Subnet   |   Interface ID        |          
   +---+-------+---------------+-----------+-----------------------+
   
   <-----Public Topology------->   Site
                               <----------->
                                 Topology  
                                           <--Interface Identifier->

Fields

 - FP   Format Prefix (010)
 - TLA  Top Level Aggregator
 - NLA* Next Level Aggregator(s)
 - SUBNET       Site Specific Topology
 - INTERFACE ID Interface Identifier

Top Level Aggregator

 - Top Level in Addressing Hierarchy
 - Assigned to Organizations providing Public Transit Topology
    o Not to Private Transit Topology
 - Supports 2^^13 TLA's (8K)
    o Additional available by using another FP
 - IANA Assigns Blocks to Registries
    o Registries assign to TLA's
    o Registries get more from IANA

Next Level Aggregator

 - Used by TLA's to
    o Create TLA Hierarchy
    o Identify Sites
 - TLA's may support NLA's in their own Site ID space
 - NLA's may support NLA's in their...
 - Works exactly like CIDR delegation
 - TLA's assume registry duties for NLA's

NLA*

   +-----+------------------+--------+-----------------+
   |NLA1 |  Site            | Subnet | Interface ID    |          
   +-----+------------------+--------+-----------------+
         +-----+------------+--------+-----------------+
         |NLA2 |   Site     | Subnet | Interface ID    |          
         +-----+------------+--------+-----------------+
               +-----+------+--------+-----------------+
               |NLA3 | Site | Subnet | Interface ID    |          
               +-----+------+--------+-----------------+


Proposal was generally well accepted.  Some discussion about fixed
boundaries in these addresses, particularly about the TLA boundary.
This was clarified that it was only there for address allocation and was
not visible by the routing system.

Bob Hinden will write a internet draft for "Aggregation-Based Unicast
Address Formats".


Analysis of GSE Proposal / Matt Crawford and others 
----------------------------------------------------

Most topics will be outcome of PAL1, some were the result of additional
analysis.

Motivation for GSE
 - Renumbering must happen to achieve and maintain the necessary
   aggregation to keep routing computation feasible.
    o Make intra-site communication impervious to global renumbering
    o Make renumbering easier to do
 -  Put the routing cost of multi-homing onto the parties involved.

GSE Mechanisms
 - Conceal global-scope prefixes from the sites' interiors.
    o Insert source prefix at exit/remove destination prefix at entrance
       - Fixed boundaries in addresses
       - Modifications to checksum, PCB/SA lookup rules
       - Globally unique identifiers for nodes
    o DNS magic
       - Two-faced DNS
       - AAAA synthesis from parts
       - AAAA synthesis from parts
       - RG upward indirection
 - Multiple providers set up fallback tunnels to create the illusion that
   failed links are up
    o Hole-punching" is confined to consenting parties.

Major Difficulties
 - Due to host ignorance of prefixes
    o New failure modes due to RG not covered by checksum
    o Can't construct source routes (in general).
    o Hosts can't influence traffic handling by source address selection.
       - Interior routing fluctuations cause source address to thrash
    o Any node that is a tunnel endpoint must act as a border router.
  - Due to DNS modifications
    o Delegation problem:  the one who holds your glue is not the one who
      changes your prefix.
       - No visible solutions
    o Two-faces DNS is required
       - Might be solvable
  - Due to source address rewriting
      o Multicast packets duplicated at multiple site exits.

Recommendations
 - Do not hide the global prefixes from the interior nodes.
 - There has to be an overlap period (on the order of days to weeks)
   during prefix reassignments.
 - Define boundaries in addresses
    o Between global and site topology
    o Between routing and node designator
 - Address architecture must be improved for better aggregation.
 - Using site-local addresses can help quite a lot
    o Work on two faced DNS (the alternative is address selection rules
      for hosts)
 - Globally unique end-system designators have potential uses
    o But aren't a panacea.
 - The next address architecture document should accommodate an 8 byte
   unique ESD.
    o Candidate: IEEE EUI-64.

  Question: what does "accommodate" mean?  Does it mean require requiring
  globally unique now.  Answer: Yes.

Implications
 - Need to work on Two-faced DNS
 - Need to study coordination between renumbering and updating DNS
   delegations
 - Root DNS servers at fixed addresses, globally host-routed?
 - Hosts will do source address selection, even if only by default.
 - Boundaries in global addresses facilitate the use of site-local
   addresses.

   Questions: Should we also work on source selection algorithms?  Yes,
              we should be comparing the two approaches.

              O'Dell raised difficulty with scaling when hosts have many
              addresses. Doesn't think this will scale.

              Do the recommendations mean that I can't use prefix ::1?
              Yes, that would not be allowed.

  - Starting off a connection with site-local addresses may become
    inconvenient if one end later goes mobile off-site
     o Could some hosts simply not have site-local addresses?

 - Globally unique ESD's preclude routing prefixes of 64 < length < 128
    o Or do they?  If you have an aligned blocks of ESD's

 - What's the ESD of an anycast address?

Comment that Anycast do not need globally unique, but need ESD which do
not conflict with any real ESD.

Question and discussion about stability of dialin assigned addresses.

Lixa Z:  Question about what it means to require global unique ESD's.

Comment about getting more feedback from DNS "experts".  Agreement we
need more overlook.  Need more coordination.

M. Ohta: Asked why did we look at only rewriting destination locator
(based on his proposal of about six months ago).  Wants to be able to rewrite
destination RG.  Could preserve original address in source route header.


IPv6 over Ethernet & FDDI / Matt Crawford
-----------------------------------------

Changes to accommodate ESD's
  - Prefix for stateless auto-config must be /64
  - Auto-config address token is EUI64
  - Link-local address token is EUI64
  - EUI-64 is derived from MAC address
     o 00--8-55-12-34-56  -> 0008:55FF:FE12:3456
     o http://standards.ieee.org/db/oui/tutorials/EUI64.html


IPv6 over PPP / Dimitry Haskin
------------------------------

Change to make PPP support 64bit interface ID.  Now reserves this size
token.  No changes to date to accommodate global token.  Pending outcome
of global ESD issue.


IPv6 over ARCNET and Localtalk / Bob Hinden
-------------------------------------------

Hinden mentioned both ARCNET and local talk do not have IEEE addresses in
hardware and would need some mechanism to get global identifiers.


The Use of End System Designators in IPv6
-----------------------------------------

IEEE/ANSI EUI Formats

 - EUI-64

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   <---- company_id -------><-------------vendor supplied id ------>

 - IEEE 802

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |   |   |   |   |   |   | F | F | F | E |   |   |   |   |   |   |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   <-------  OUI  --------->                <--- vendor id -------->

 - FiberChannel

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |   |   |   |   |   |   | ? |   |   |   |   |   |   |   |   |   |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   <---- company_id ------->    <-------vendor supplied id -------->


  Hard problem is what if you do not have an IEEE address in system.

IANA EUI Formats

 - IPv4 Address

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   | 0 | 0 | 0 | 0 | 5 | E | 1 | 0 | C | 7 | 5 | 1 | D | C | 9 | D |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   <---- company_id ------->       <-IPv4 Addr (199.81.220.157) --->

 - ASN

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   | 0 | 0 | 0 | 0 | 5 | E | 2 | 0 |   |   |   |   |   |   |   |   |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   <---- company_id ------->       <--- ASN -------><--- Assigned ->


    o PPP servers could use IANA OUI and IPV4 address.
        - Can not use private use IPv4 addresses
    o Use company ID and Autonomous System number (ASN)

   Comment companies do not normally get ASN numbers. Only assigned to
   organizations who are multihomed.

Random ESD Format

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |   | 2 |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   <--->   <------------------------------------------------------->
                     60 Random bits
       <--->  Fixed 4 bits (locally administrated address space 
              which is not used by IEEE

IPv4 addresses in IPv6

 - IPv4 Compatible

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |   |   |   |   |   |   |   |   |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   <---- company_id ------->       <------ IPv4 Address ----------->

 - IPv4 Mapped

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   | 0 | 0 | 0 | 0 | F | F | F | F |   |   |   |   |   |   |   |   |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   <---- company_id ------->       <------ IPv4 Address ----------->

    o IPv4 compatible are OK
    o IPv4 mapped have a problem because conflicts with other assignments.



ESD Pro and Con's / Thomas Narten
---------------------------------

Main Benefit
 - Automatic/transparent deliver of packet to transport endpoint, even if
   source or destination "Routing Stuff" changes (see below)
 - Transport endpoints ar TCP, UDP, IPSEC, etc.
 - Facilitates retroactive fix up of Routing Stuff
    o Mobile nodes says "I just moved" here is my new address"
    o During renumbering: "here is my new preferred address"
    o Required authentication prior to changing "routing stuff"

Cons
  - Automatic delivery defined above simplifies implementation, but does
    NOT provide new functionality:
    o Functionality required: IPv6 destination option that says "use
      this address when demultiplexing instead of address in IPv6 header"
    o IPSEC AH provides assurance that option is not a hijack attempt
    o Basic idea has been proposed before
      - Context identifier parameter" in Huitema's "Multihomed TCP" draft.
      - "Source identifier Option" in Bound/Roque "IPv6 Anycasting Service"
        draft.
 - ESD uniqueness requirement adds complexity
    o Intruders guarantee that ESD can not be assumed unique, even if we
      design them to be
    o New denial-of-service attacks possible:
      - Intruder host "borrows" ESD of dilbert.foo.com, opens TCP
        connection to www.bar.com
      - Real dilbert.foo.com opens TCP connection to www.bar.com (using
        same port number)
      - Packets from both connections delivered to same TCP endpoint on
        web server
      - Second connection (real Dilbert) "loses"
      - Can't defend against without requiring authentication.
    o Need way dealing with devices that have no IEEE MAC address.
      Solution possible, but may require some manual configuration.
    o Accidential misdelivery of packet to wrong machine that is using same
      ESD may trigger dangerous error responses.
    o Disallows small subnets
    o Anycast address need ESD that doesn't conflict with existing ESD
      (solutions possible, misconfiguration possible)

My opinion
   - Key issues: compare benefits against cost
   - There are real costs, some which are not fully understood
   - Supposed benefits oversold
   - Considered big picture, benefits not worth the cost.


----------------------------------------------------
Friday 9-11:30am
----------------------------------------------------

Mobile IP / Dave Johnson
------------------------

Mobile IPv6
 - Allows transparent roaming of IPv6 mobile nodes
    o Routing to mobile node regardless of its current point of
      attachment to the Internet
    o Mobile node is always addressable by its "home agent"
 - High-level overview of operation
    o Care-of addresses from IPv6 address auto-configuration
    o Mobile node sends its own Binding Updates
    o Used for correspondent nodes and home registration
    o Nodes cache binding in a Binding Cache
    o Correspondents route own packets directly to mobile node
 - Current draft is <draft-ietf-mobileip-ipv6-02.txt>

Dynamic Home Agent Address Discovery
  - Mobile node may not always know its home agent address
     o While mobile node is away from home
     o Home network may need to be reconfigured
     o Different machine may take over as home agent
  - In Mobile IPv4
     o Mobile node can send to "directed broadcast" address
     o All home agents in home network receive request
     o All reject, giving their own unicast addresses
     o Mobile node tries again with one of these addresses
  - Can't do this in Mobile IPv6 since no broadcast in IPv6

Home Agent Discovery Proposal #1
  - To register when don't know own home agent address
     o Mobile node sends "home agent discovery" packet to home network
       router "anycast" address
     o Probably an ICMP message
     o By IPv6, received by one border router on home network
     o Router receiving packet multicasts "home agent discovery" into
       home network to "all home agents group"
     o Home agent returns reply with its IP address to mobile node
     o Mobile node registers to that IP address
  - Implementation would be required in ALL IPv6 routers

Proposal #2
 - Define "home agent anycast" address
    o Prefix defines which subnet
    o Bottom part could be all-ones (instead of all-zeros)
 - For home agent discovery
    o Mobile node sends request to home agent anycast address for home
      network
    o Request answered home agent, giving unicast address
    o Mobile node registers to that IP address
 - Implementation of this would be required in ALL IPv6 routers

Comments, Please
 - Need feedback from IPng working group
 - Send to mobile-ip@smallworks.com (mobile ip mailing list)

Topologically Correct Addressing
 - Packets sent to a mobile node:
    o Source address = correspondent node address
    o Destination address = mobile node care-of address
    o Routing header = mobile node home address
    o (Problem: size of Routing header in every packet)
 - Packets sent from a mobile node
    o Source address = mobile node home address
    o Destination address = correspondent node address
    o Problem: ingress filtering drops all of these packets!

Proposed Solution: Source Address Remapping
 - Mobile node uses care-of-address as source address..
   But only while packet on its way tot he destination node
 - At the sender:
    o Sender builds packet using home address
    o Then substitute care-of address as source
    o Makes packet source address topologically correct
 - At the receiver (only the end destination node)
    o Receiver substitutes correct source address (home address) back
      into packet in place of care-of address.
 - Implementation of this would be required in ALL IPv6 routers

Source Addressing Remapping Method #1
 - Two source addresses in "every" packet
    o Carry real source address in a destination option
    o If present, receiver substitutes into IP header before passing it
      to the transport layer
    o Used for receipt of this packet only
    o Option creates no state in the receiver
    o Option does not affect any routing from receiver
    o Option is authenticated if packet itself is authenticated
    o Otherwise, no extra authentication needed.

SAR, Method #2
 - One one source address (the care-of address) in packet
    o Also a bit in every packet: "source is a care-of-address"
    o Bit probably encoded by presence/absence of a destination option
    o Could also be bit in header or bit in source address
    o Receiver caches <care-of address, home address> mappings
    o If bit set in received packet and no cache entry:
       - Receiver request mapping form care-of address
       - Reply MUST be authenticated
       - Receiver saves original packet and processes after reply
       - Request/reply is probably ICMP

Some discussion.  Will be discussed on mailing list.



Synthesis of DNS aAA and RG Resource Records / Jim Bound
--------------------------------------------------------

Motivation
 - IPng w..g PAL1 interim meeting on alternative addressing architecture
 - Add connotation of location and identifier to DNS Resource Record
   "syntax" for future use.
 - Avoid alteration to DNS protocol and APIs for IPv6
 - Adjunct to other Interim meeting action items
 - Determine initial affect to applications and DNS syntax and
   processing. 

Processing Model
 - No change to the DNS protocol
 - Client resolve still requests AAAA records in query (e.g.,
   gethostbyname2() ), using ESD address
 - DNS server synthesizes from ESD address an AAAA record for each RG
   record associated with an aAA ESD
 - DNS returns in query response one AAAA record for each RG + aAA pair
   synthesized at the DNS server.
 - Transparent to client applications during the query operations.

New aAA and RG Types

    foo.bar.com  IN    aAA   aa:bb:cc:dd:ee:ff:01 /* ESD */
                 IN    RG    5f09::/??
                 IN    RG    5f08::/??

To be Determined
 - RG and ESD length, semantics, and uniqueness.
 - Processing cached AAAA records for resolvers
 - Affects RFC 1886 and DHCPv6 extensions
 - Dynamic updates to DNS must deal with granularity of aAA and RG
   records
 - Reverse DNS processing is TBD.

Numbering point-to-point and boundary links / John Stewart
----------------------------------------------------------

If global ESD's, mask lengths will be either up to 64 or 128.  Nothing
in between.

Notion that like in IPv4, with current form of interconnects, some global
RG would have to be assigned to interconnects (e.g., NAP, etc.).


Solicited Node Definition / Steve Deering
-----------------------------------------

Issue was wanting to avoid a many to one mapping to Ethernet multicast
addresses.  Don't want to have collisions.  L2 filtering, etc.

Proposal was to allocate IPv6 multicast addresses to not have
multicast group > 32bits.  ND solicited addresses conflict with this
approach.

Currently:

    FF02::1:xxxx:xxxx

Proposes:

    FF02::1:FFxx:xxxx

Working group agreed adopt change.  Will go into Addressing Arch and ND
drafts.  New addressing architecture w/ new solicited node definition soon
because ND and IPoverFoo need to copy definitions.


IPv6 Tunneling Spec and GRE / Steve Deering
-------------------------------------------

IPv6 tunneling spec has gone through IPng last call and IETF last call
twice.  IESG want to form a working group to resolve the number of
differently tunneling specs.  GRE IPv4 specs submission has caused IESG
to take a deeper look.  One of the original IPng working group
requirements was to define IPv6 tunneling.  We only want one tunneling
specification for IPv6.

Alex Conta:  GRE specification is not ready for an IPv4 specification because
it is not complete.  It does not cover IPv6 tunneling as currently
written.  Specs are not compete.

Jeff Burgen / AD: IESG has decided to look at tunneling overall.  Will be
resolved to quickly.  The new group be in the internet area.  The AD's will
scope work.  Doesn't want to drag on a long time.

Deering suggested that IPv6 need not be in that charter of this group.
IPv6 already has one specification.

IPng Chairs will write strong note to IESG requesting IPv6 not be
included in this new working group and concern about the delay to
existing IPv6 work.


Router Renumbering for IPv6 / Matt Crawford
-------------------------------------------

Internet draft written by Matt Crawford based on presentation at previous
IETF by Bob Hinden

Router Renumbering (RR) Packet contains
    - Anti-replay fields
    - Zero or more Prefix Control Operations (PCOs), each of which has:
        
[missing remainder of slide]

RR Message Processing
    - Check for valid sequence number
        o Optionally check for valid replay
    - Verify authentication
    - For each PCO
        o For each interface
            - For each address and/or Prefix on that interface
                o Compatible to MatchPrefix, if it matches,
                    - Preform operation
                    - Do not create duplicate prefixes

Why not use SNMP
    - Multicast
    - Renumbering will be "more fundamental" than other management
      functions
    - Security

Why not use IPSEC for Authentication
    - SA is looked up by SPI + destination address, but destination
      addresses are changing during RR.
    - No dynamic key negotiation protocol for multicast destination
      (correct me if I am wrong)

   Based on discussion will change draft to HMAC SHA1

   Jim Bound mentioned that new docs need to require method for key
   selection.

Open Issues
 - More than 1 match on a single interface
    o repeat operation on each match
 - Require duplicate suppression, or advise against construction of
   non-idempotent combinations?
 - All-routers multicast address is currently only defined at node- and
   link-local scope.  Site- or org-scope would also be useful.
 - Asymmetric authentication scheme might be more appealing
 - No attempt to distribute information for RA fields other than Prefix
   information (e.g., hop limit.)

Nordmark: Thinks this is a good idea.  We should be careful to not
include things which could break things.  Would be better to make it
harder to keep things from breaking.  Might require more elaborate
mechanisms and/or procedures.  Need to be careful to make it harder.

Next steps to update draft to use HMAC and finish missing sections.
Think about Nordmark suggestions.


Advertising site prefixes in RAs / Erik Nordmark
------------------------------------------------

Announcing Site Prefixes in Router Advertisements
 - Goals:
    o Limit effect of renumbering by ensuring that traffic local to the
      site use site-local addresses
    o Do this without requiring a two-faced DNS (i.e., no site local in
      the DNS)
 - Proposal
    o Advise the global prefixes (w/ lifetimes) for the site in ND
      messages
    o The host use this info to maintain a list of the current site
      prefixes
    o The host resolver (gethostbyname function) checks against list of
      prefixes after resolving the name.
    o When one of the addresses retrieves from the DNS matches one of the
      site prefixes (i.e., the first N bits match) then add the corresponding
      site-local address to the front....

[slides showing how to encode in prefix advertisements]

[missing remainder]



Prefix Notation / Bob Hinden
----------------------------

Prefix notations was added to current draft of addressing architecture
document.  General form proposed is:

    ipv6-address / prefix-length

Examples:

    12AB:0000:0000:CD30:0000:0000:0000:0000/60
    12AB::CD30:0:0:0:0/60
    12AB:0:0:CD30::/60
    12AB:0:0:CD30/60

It included a notation (shown in last example) to not require "::" at the
end of the prefix.  Implied left justifying prefix and zero fill remainder.

General consensus of group was that his added complexity and to not
support this (e.g., require "::").


Who Are You / Matt Crawford (5 min)
----------------------------------------------------

Motivation

 - GSE would have made it difficult to have reverse lookup domains.
 - IN=ADDR.ARPA poorly maintained, will IP6.INT be better.
 - Maintenance of delegations will be more difficult in the expected
   frequent-renumbering environment of "THE FUTURE".
 - For access control, or even logging, IP6.INT provides nothing but a
   hint anyway

History
 - Experimental RFC by  W. Simpson, "ICMP Domain Name Messages", RFC 1788.

Format of Packet

  - ICMP Message

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              ID               |            unused             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                            Cookie                             +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Time-To-Live                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    NameLen    |                   FQDN ...                    |
    +-+-+-+-+-+-+-+-+                                               +
    /                                                               /
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Fields:

   Type        TBA1 - FQDN Query (more pronouncably known as Who-Are-
               You or WRU).
               TBA2 - FQDN Reply (possibly to be known as Sam-I-Am).

   Code        For FQDN Query, always zero.
               For FQDN Reply:

               0   Indicates that the Time-To-Live field is meaningful

               1   Indicates that the responding node cannot provide a
                   meaningful TTL for its Address-to-FQDN association.

   Checksum    The ICMPv6 checksum.

   ID          A 16-bit field to aid in matching replies and requests.
               Its value is chosen by the querier and copied from a
               Request to a Reply by the responder.

   Cookie      An opaque 64-bit field to aid in avoiding spoofing.  Its
               value is chosen by the querier and copied from a Request
               to a Reply by the responder.

   Time-To-Live
               The number of seconds that the name may be cached.  For
               compatibility with DNS [1035], this is a 32-bit signed,
               2's-complement number, which must not be negative.

   NameLen     The length in octets of the FQDN, as an 8-bit unsigned
               integer.

   FQDN        The fully-qualified domain name of the responder, as a
               sequence of NameLen US-ASCII octets, with periods
               between the components.

   The last three fields (Time-To-Live, NameLen and FQDN) are not
   present in the FQDN Query.


Steve Deering: Wondered about supporting multiple names in packet?

Alex Conta:  How different form DNS?  Simpler fewer options/etc.
Intended only for reverse lookups.

Usage and Issues
 - The internet could easily get clogged with these messages.  Therefore,
   this could be a back-end to DNS servers, which would catch the answers.
    o What's a good TTL when the responder can't provide one?
    o What about a timeout for negative caching?

Question about viability of current reverse lookup database.  Questioner
thought premise was untrue.  Thought was was getting better.  Response was
that with renumbering this would get even harder to maintain.  This
mechanism does not require manual configuration of a database.

Important to keep this simple.

Features
 - PLUS:  Routing system takes the place of IP6.INT delegation
    o Always current
 - PLUS" A Meaningful TTL is usually available from Autoconf. or DHCP.
 - MINUS: Target must be up and reachable to do a lookup
    o But is it meaningful to say a certain FQDN is associate with an
      address when it isn't.

Comment.  Dialin users do not know their name.  DHCP could tell host
their domain name when they get the address.  Could also return with a
empty name length.

What about negative caching?


Inter-Domain Routing Status / Bob Hinden
----------------------------------------

Covered in document status.


ND Zero Lifetime advertisement issue / Thomas Narten
----------------------------------------------------

Denial-of-Service vulnerability in Stateless Addrconf

Attack:
 - Intruder connects to local link (remote access not sufficient)
 - Listen for RAs, determine what prefixes are in active use
 - Send out a single RA, advertise in-use prefix(es) with lifetime of
   zero

Consequence:
 - Receiving host immediately invalidates address(es) formed via stateless
   autoconf for the specified prefix(es).
 - Host immediately terminates all transport layer connections
   (addresses) in use no longer exists).
 - Every host acts on received RA, entire network effectively brought
   down. 
 - Subsequent RA containing correct (no-zero) Lifetime does not undo
   damage. 

One Possible Solution:
 - When a prefix lifetime reaches zero, host enters DELAY state, doesn't
   actually invalidate for two additional hours.
 - Receipt of subsequent lifetime value > zero cancels DELAY state
 - While in DELAY state, silently ignore additional Lifetime values of
   zero (for receiving prefixes)
 - Result: Intruder's zero Lifetime advertisement effectively ignored;
   subsequent RAs from real router cancel intruders RA before DELAY state
   expires. 

Question for WG?
 - Is this significant threat?
 - Is the cost of fixing vulnerability small enough to justify.
 - Should we fix problem?

There are plenty of denial-of-service vulnerabilities already: Why fix
this one given the others?

 - Other attacks must target individual hosts, one at a time.
 - Other attacks disrupt first-hop path, not the hosts themselves.
    o When intruder leaves, path is restored; host may be able to
      continue.
    o TCP connections break on a timeout, which takes several minutes
    o Doing long-term damage require long-term presence of intruder
      (increasing likelihood they will be discovered). 
    o Vulnerabilities in IPv6 are analogous to those in IPv4 (i.e., IPv6
      doesn't make problem worse than what we have today).
 - In contract to IPv4, IPv6 zero lifetime attack:
    o Single packet is processed by all hosts in the same way.
    o Host actively terminates all existing transport connections
      immediately, no recovery possible.
    o IPv4 has nothing like this; IPv6 has introduced a vulnerability not
      present in IPv4.

Suggestion that before invalidating prefix, send a RS and see if RA is
consistent with message which invalidated prefix.  Discussion and
additional suggestions.

General consensus to fix vulnerability but there are issues with
proposed mechanism.  Author will propose to mailing list.


Advanced API Spec / Matt Thomas
-------------------------------

Any last comments, authors would like to issue working group last call.

Document editor will do a working last call for Informational RFC.



SNMP Issues / Margaret Forythe
------------------------------

Couple of issue with current MIB drafts and discuss solutions.

IPv6 MIB Issues
 - Separate TCP/UDP tables for IPv4 and IPv6
 - No way to represent an IP address in a MIB that can be ether IPv4 or
   IPv6.
 - Various Nit's
    o IP Routing table updates
    o IPv6IfIndex as index in TCP/UDP Tables

Possible Solution(s)
 - Unified IP Address format
 - Single UDP &TCP Tables for IPv6 & IPv4 "connections"
 - Minor MIB cleanup

Unified IP Address
 - Type/version in IP address type?
 - Octet string or OID?
 - SMI Change or Textual conv.
    o SMI change (new App. type) allows type discrimination in SNMP
      packet.
    o SMI change does not permit backwards compat. to current
      managers/agents.
    o SMI change may be politically difficult
    o Display hints in textual convention do not give info to
      mgr. unfamiliar w/ particular MIB.  SMI App types do.

UnifiedIPAddress::= textual convention

 DISPLAY HINT "X" (?)
 
 STATUS current
 
 DESCRIPTION

   "IP Address type for both IPv4 or IPv6 addresses.  Particular type can
    be determined from length.  Length of 4 = IPv4; 16 = IPv6.
    Addresses are stored in network byte order.
    IPv4 addresses should be displayed as with display hint "1d.:; IPv6
    addresses as with "2x:"."

  SYNTAX OCTET STRING (SIZE (4 | 16))

  SMI Applications Type -
    UnifiedIPAdress ::=
      [APPLICATION 7]
        IMPLICIT OCTET STRING (SIZE (4|16))

Will work with MIB author to resolve issues.  When new drafts are out,
IPng Document Editor will issue w.g. last call to move the to
Experimental status.


Destination Locator Rewrititing / Masataka Ohta
------------------------------------------------

Motivation

Protocol Modifications
 - Don't checksum-protect destination locator
 - Modify routing header (w/ authentication) to Preserve the Original
   Locators 
 - PCB lookup with Source and Destination ESDs (both Checksummed).

Modifications to Routing Header
 - Add address[0] to contain the first destination address
    o Extra 16 byte in header
 - Copy, don't swap
    o Faster operation expected
    o Same level of security

  [slide showing change to pkt format]

Comment:  This looks like what Dave Johnson is proposing for mobile IP.
Might be able to combine?


Global ESD Proposal / Bob Hinden
--------------------------------

Presented a proposal which would keep open the option for future
transport protocols to use global ESD.  Proposal was as follows:

  - Require all Interface ID be constructed using EUI-64 framework.  Easy
    for both for devices which have hardware 48bit MAC's and with the use
    of the IANA or vendor specific prefix, easy for serial lines, tunnel
    interfaces, localtalk, etc.  Only cost is use of 64bit ID's.

  - Part of EUI64 is a bit which says if the address has global scope
    (uniqueness).  We require that bit be set correctly.  EUI-64 which
    are built from hardware MAC will be global.  Serial lines, tunnel end
    points, localtalk, etc. will not.

  - We do not make any change to current TCP/UDP connection
    identification, pseudo checksum, etc.  Current transport protocols
    will treat all addresses as opaque 128bit quantities.

  - New transport protocols and/or research projects can tell if the
    destination with which they are about to communicate has an address
    with a global identifier when they get the results of a DNS lookup.  If
    so, then can do what ever ESD magic they want.  In practice many
    (most?) interface ID's will be global.

This proposal would "keep the door open" for global ESDs but limit the
impact now.  The only cost now is requiring 64 bit interface ID and
setting the global scope bit correctly.

Considerable discussion resulted.  Chairs polled the working group:

  0  voted for global ESDs in IPv6
  7  voted for no global ESD in IPv6 (e.g., keeping current interface ID
     behavior)
  33 voted for proposal to use EUI-64 global/local bit to identify if
     interface ID is global.

This was a rough consensus to adopt this approach.  Will be added to
addressing architecture document.


---------------------------------------------------------------------------
---------------------------------------------------------------------------