Subject: (IPng 7299) Draft Minutes from the Grenoble IPng w.g.

From: Bob Hinden <[email-masked]>
Date: Wed, 10 Mar 1999 16:57:02 -0800

Attached are the draft minutes from the IPng Working Group meeting held on
February 2-4 in Grenoble.

Comments and corrections to me.

Thanks,
Bob

____________________________________________________________________

IPng Working Group Meeting
February 2-4, 1999
Grenoble, France

Bob Hinden / Nokia
Steve Deering / Cisco
IPng Co-Chairs

Bob Fink / LBNL
Tony Hain / Microsoft
NGTRANS Co-Chairs

Minutes taken by Tony Hain, Steve Deering, Bob Fink and Bob Hinden.
Edited by Bob Hinden.  Minutes for NGTRANS and deployment activities
published separately.

-----------

IPng / NGTRANS

INTERIM MEETING 

February 2-4, 1999

Steve Deering introduced meeting.  Alain Durand gave local arrangements,
terminal room information, daily schedule.

92 registered to attend.
  25 from France
  32 from elsewhere in Europe
  28 from North America
   7 from Japan

SCHEDULE
 Tuesday
   8:00 Registration
   9:00 Welcome speech by IMAG's director
   9:10 Morning session
  11:30 Lunch break & registration
  13:00 Afternoon session 1
  15:00 Afternoon break
  15:30 Afternoon session 2
  18:00 End
  20:00 Rendezvous at Bus station (next to the train station) to take a
	bus to go to the social.
  23:00 Return from the social
 Wednesday
   8:30 Registration
   9:00 Morning session
  11:30 Lunch
  13:00 Afternoon session 1
  15:00 Break
  15:30 Afternoon session 2
  18:00 End
 Thursday
   8:30 Registration
   9:00 Morning session
  11:30 Lunch
  13:00 Afternoon session 1
  15:00 Break
  15:30 Afternoon session 2
  18:00 End

First day is an IPng w.g. meeting.  Second day is an NGTRANS meeting.
Third day is deployment activities (this is not an IETF meeting).  

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

IPng WORKING GROUP

February 2, 1999
Grenoble, France

Bob Hinden / Nokia
Steve Deering / Cisco
Co-Chairs

Introduction / S. Deering
-------------------------

Steve Deering introduced the meeting and collected the attendee required
issue lists.  Chairs will review lunch break and present the results.

IPng charter basically complete, documents are at various points in the
standards process.  Document review for completeness, followed by issues
or additional work.  Continue, Recharter, hibernate decision.

Review and update agenda  / S. Deering
--------------------------------------

The agenda was reviewed.  The following agenda resulted:

 IPng AGENDA

  - Introduction / S. Deering
  - Collect attendee required issue lists (S. Deering)
  - Review and update agenda (S. Deering)
  - Review state/completeness of current IPv6-related protocols
    (B. Hinden)
  - Identify important new IPv6 protocol/standards work
     (detailed agenda follows)
  - Formulate recommendations to the IESG/IAB, re: future IPv6 work
     (detailed agenda follows)

 AGENDA: NEW PROTOCOL / STANDARDS WORK

  - Will IPv6 work for a Billion (or more) PDA's and Mobile
    Phones? (B. Hinden)
  - Securing ICMP/ND/MLD (M. Crawford)
  - State of Plug-and-Play  (B. Hinden)
  - Site Scoping Issues (T. Narten)
  - Issues in IPv6 Multihoming (J. Hagino)
  - Better Support for Multihomed Hosts (R. Draves)
  - Better Support for Multihomed Sites (E. Nordmark)
  - Privacy issues with use of EUI-64 IDs (T. Narten)
  - Source and Destination Address Selection (T. Narten)
  - Making TCP use Global Interface IDs (A. Mankin/T. Narten/M. Crawford)

 AGENDA: FORMULATE RECOMMENDATIONS / S. Deering, B. Hinden
  -  Disposition of IPng w.g.
  -  Extend charter? go on hiatus?
  -  Distribution of work to other existing WGs?
  -  Evaluation of all IETF protocols for "IPv6-readiness"?
  -  Recommendations for establishing new WG(s) or RG(s)?

Review State/Completeness of Current IPv6-Related Protocols (B. Hinden)
-----------------------------------------------------------------------

REVIEW STATE OF IPv6 PROTOCOLS
 -  Draft Standards
 -  Proposed Standards
 -  Informational
 -  Experimental
 -  Current Internet Drafts

DRAFT STANDARDS
 - RFC2460 Internet Protocol, Version 6 (IPv6) Specification

  Issue of advancement to full standard over what time period.  IESG will
  want to insure that protocols are mature.  Discussion on what IESG will
  require to move base protocols to Standard.  Conclusion that we should
  get a clear statement of what the IESG will be looking for.

 - RFC2463 Internet Control Message Protocol (ICMPv6)

    Add scope-exceeded ICMP error msg code
    RFC-editor suggested edits
    Prohibit ICMP error message in response to redirects
    
   ACTION: Document editor to do editing pass and resubmit to IESG for
           same status

 - RFC2461 Neighbor Discovery for IP Version 6 (IPv6)

    Forbid RAs from non-forwarding interfaces
    Issue of NAs without link-layer address

    Suggestion: guidance/interpretations document

 - RFC2462 IPv6 Stateless Address Autoconfiguration

    No issues

 - RFC1981 Path MTU Discovery for IP version 6

    No issues.  Note this was the only spec that progressed without
    recycling!

PROPOSED STANDARDS
 - RFC2373 IP Version 6 Addressing Architecture

    No issues

 - RFC2374 An IPv6 Aggregatable Global Unicast Format

    No issues
    Should decide on what the "core set" of documents is.

 - RFC1886 DNS Extensions to support IP version 6

    Should this be advanced?  Not unless something else that depends on
    it needs to advance to next level.  M. Crawford reported that new
    specification does not include specification of AAAA, does describe
    compatibility.  Conclusion that both specs will need to coexist with
    each other.  The new specification will need to have it's title
    changed.  It is currently has the same title as RFC1886.

 - RFC2147 TCP and UDP over IPv6 Jumbograms

    To be merged with jumbogram hop-by-hop option spec to produce
    combined document.  Work in progress.

 - RFC2080 RIPng for IPv6

    ACTION: Document editor to poke RIP wg to advance to Draft Standard.

 - RFC2283 Multiprotocol Extensions for BGP-4

    Francis reports there will be a new version of this spec, going to
    draft standard; a separate IPv6 specific part is supposed to 
    be published as Proposed standard.  Narten: This is hung in the IESG
    on a normative reference for another doc Summary: Update to RFC2283
    to include IPv6 will be forwarded as proposed; how to it use is
    drafted, but not published;

    ACTION: Document editor will poke chairs (or ADs if necessary).

PROPOSED STANDARDS
 - RFC2464 IPv6 Packets over Ethernet Networks

    No issues

 - RFC2467 IPv6 Packets over FDDI Networks

    No issues

 - RFC2470 IPv6 Packets over Token Ring Networks

    No issues

 - RFC2472 IPv6 over PPP

    No issues

    General conclusion is that IPv6 over Ethernet/FDDI/TR/ PPP should
    move to draft standard when 6 month time goes off.  Need to start
    collecting implementation information and issue last call.

   ACTION: Document Editor start collecting implementation information on
    IPv6 over Ethernet/FDDI/TR/ PPP and issue last call for Draft
    Standard when 6 month timer goes off.

 - RFC2473 Generic Packet Tunneling in IPv6 Specification

    Need to add language about bidirectional tunnels and recycle at
    Proposed Standard.

 - RFC2491 IPv6 over Non-Broadcast Multiple Access (NBMA) Networks

    No issues

PROPOSED STANDARDS
 - RFC2492 IPv6 over ATM Networks

    No issues

 - RFC2452 MIB for IPv6: TCP

    No issues

 - RFC2454 MIB for IPv6: UDP
    
    Bert Weinen: plan to merge with the IPv4 versions of TCP & UDP.  Pick
    up with authors and merge.  Could be done in the ops area.  May not
    be sufficient in other area.

    ACTION: O&M AD's to resolve.

 - RFC2465 MIB for IPv6: Textual Conventions & General Group

    Question about support for site ids

 - RFC2466 MIB for IPv6: ICMPv6 Group

    No issues

    Question about any Implementations?  Nordmark: instrumentation is
    done to support this, but the MIB browser interface is not done.
    Dupont: INRIA has complete implementation.

PROPOSED STANDARDS
 - IP Header Compression (Internet Draft)

    No issues

 - Transmission of IPv6 over ARCnet Networks (Internet Draft)

    No issues

 - Transmission of IPv6 Packets over IPv4 Networks without Explicit
   Tunnels (Internet Draft) 

    No issues

 - Reserved IPv6 Subnet Anycast Addresses (Internet Draft)

    No issues

 - RFC1752 The Recommendation for IP Next Generation Protocol

    Question what to do about this?  Perhaps time for BCP?
    
    ACTION: Document authors (Mankin & Bradner) to decide what to do.

INFORMATIONAL
 - RFC2450 Proposed TLA and NLA Assignment Rules

    No issues

 - RFC1881 IPv6 Address Allocation

    No issues

 - RFC2375 IPv6 Multicast Address Assignments

    ACTION: Document editor needs to get IANA to publish this on their
    web pages

 - RFC2133 Basic Socket Interface Extensions for IPv6

    No issues.  Will become historic when new back socket document is
    published. 

 - Basic Socket Interface Extensions for IPv6 (Internet Draft)

    No issues

 - RFC2292 Advanced Sockets API for IPv6 

    Possible issue with support for home address option from Mobile IP
    Perhaps pass these to API stds bodies, e.g., Xopen, winsock

EXPERIMENTAL

 - RFC2471 IPv6 Testing Address Allocation

    No issues

 - RFC1888 OSI NSAPs and IPv6

    Matt C. notes that this is only current way to embed phone numbers
    in IPv6 addresses

CURRENT INTERNET DRAFTS
 - Initial IPv6 Sub-TLA ID Assignments

    No issues

 - Router Renumbering for IPv6

    Being revised to support reliability mechanisms; will be another
    WG last call

 - Link Local Addressing and Name Resolution in IPv6

    There is interest in this

 - GSE - An Alternate Addressing Architecture for IPv6

    ACTION: Document editor will inform secretariate that this has timed
            out

 - IPng Analysis of the GSE Proposal

    Has been submitted to IESG for Informational.    

CURRENT INTERNET DRAFTS
 - A method of flexible IPv6 address assignments

   Waiting for additional comments, then w.g. last call for Informational.

 - IPv6 Router Alert Option

   Waiting resolution of differences between IPv4 and IPv6 versions.

 - The IPv6 Jumbo Payload Option

   Will be combined with TCP/UDP jumbograms to create single document.

 - Multicast Listener Discovery (MLD) for IPv6

   ACTION: Deering to reissue by ID deadline for Minneapolis

 - DNS Extensions to support IP version 6

   [See discussion on "RFC1886 DNS Extensions to support IP version 6"
    above] 

 - IPv6 Name Lookups Through ICMP

   [No notes]

 - Reverse Address lookup in DNS for IPng

    ACTION: Document editor will inform secretariate that this has timed
            out

CURRENT INTERNET DRAFTS
 - OSPF for IPv6

 - Routing of Scoped Addresses in the Internet Protocol Version 6 (IPv6)

   Continue work.

 - Site Prefixes in Neighbor Discovery

   Continue work.

 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

   Work progressing slowly in DHCP w.g.

 - Extensions for DHCPv6

   Work progressing slowly in DHCP w.g.

 - Mobility Support in IPv6

   About to start last call in Mobile IP w.g.

CURRENT INTERNET DRAFTS
 - IPv6 over Point-to-Point ATM Link

    ACTION: Document editor will inform secretariate that this has timed
            out

 - Transmission of IPv6 Packets over IEEE 1394 Networks

    Would like see progress in IPover1284 w.g.

 - Transmission of IPv6 Packets over Frame Relay Networks

   ION w.g. about to do w.g. last call.

 - Forcing Fragmentation to Network MTU

   [No notes]

 - The Case for IPv6

  Author working on new draft.

Reviewed submitted tasks / S. Deering, B. Fink
----------------------------------------------

Summary of submitted tasks with counts of times topic appeared in "[ ]"s
followed by sub-topics.

   Flow ID  [7]
   Multicastcast routing [8]
     snooping [1]  doing it better [1]  dns [1]
   6 over 4  [1]
   VoIP  [3]
   mobility [18] 
     dns   site local    security     API
   dns discovery [1]
   site multihoming [15]  
      routing   usage
   v6 apps readyness  [5]  
      renumbering   v6 compatibility text
   security [10]
      ND ICMP   MLD   v6 over v6
   management [4]
      nd    mibs    snmpv6     tools
   interior routing [13]
      isisv6  ospv6  other
   address allocation [3]
   aggregation addressing [3]
   encourage implementers [2]
   public relations [1]
   plug & play [11]
   renumbering [3]
      tcp survival
   AAA - dialup [2]
      diameter
   VPN [1]
   Host & router requirements [3]
   Conformance / compliance [3]
   Secure DNS [1]
   Dynamic DNS [1]
   Exchanges [2]
   Anycast [5]
       tcp / udp 
   DNS [4]  
       zones   number of roots
   Measurement [1]
   Host multihoming [5]
   Router autoconfig [2]
   Site definition [1]
   IPv4 competition [1]
   Service location [1]
   QOS - hop by hop reservation [1]
   Building the 6ren [1]
   DHCPv6 [3]
   Ipv6 over IOG [1]
   IPv6 over 1394 [2]
   Compatibility testing organization structure [1]
   Filtering [1]
   Source & destination selection [3]
   ND v6  spec problems [1]
   Free implementations [1]
   Killer app [1]
   Transition [2]  smooth
   Diff serv [1]
   Who are you [1]
   Icmp scope [1]
   Link & site local addressing in multihoming [1]
   V6 interface identifier [1]
   V6 socket api [2]
   NIS & NIS + [1]
   Site local address usage [1]
   Multi-link subnets [1]
   Scope discovery [1]
   Firewalls into the host [1]
   IPv6 addresses in URL's [1]

Discussion of new topics receiving the most votes.

Flow label
----------

Deering described current state.  One issue is if it has end-to-end
semantics, or hop-by-hop.  Currently it is end-to-end.  No one has defined
other usage, though there has been a lot of discussion.

C. Jung described how it might relate to MPLS and it could be us to carry
the MPLS label.  This may be OBE.  Matt Crawford noted that MPLS is
"multiprotocol", hence it should not deal w/ IPv6 differently from IPv4
or any other protocol

J. Bound said that RSVP for IPv6 currently uses the flow label field.
C. Jung is uncomfortable with current flow label definition.  Telabit
said they have implemented flow label and found it useful.  Bound see a
lot of value with current definition because it is very important for
applications for bandwidth brokers in corporate intranets.

Deering suggested that we could define flow label to have either end-end
or hop-hop semantics by using one bit.

Another suggestion that e-e flow label would also be very helpful for user
authentication and billing applications.  Examples: accountable premium
bandwidth.  Flow label is a very good place to carry subscription
information.

Hinden thought there was a loose consensus on keeping the existing
wording, authors could provide flow label detail in additional documents

Deering outlined what we could do.  Choices were:

  1) Drop flow label
  2) Standardize current flow label
  3) Standardize hop-by-hop FL
  4) Standardize hybrid
  5) Leave as is

Polled group.  1) 1
	       2) 11
               3) 0
               4) 13
               5) 26 

No consensus to change behavior or current text.

Multicast Routing
-----------------

Deering reported that PIM, MOSPF, MBGP have IPv6 extensions.  Thinks work
is going along well.  Action here is to keep them moving forward.

Mobility
--------

Work is already in another WG charter (e.g., Mobile IP).  Is the question
mobility in general v.s. mobile IP?  Answer: Mobility in general
Wireless is one of the media.

M. Crawford suggested that we get E163/E164 into IPv6 and let the phone
system take it over

Routing, Interior and Exterior
-----------------------------

Should be in other groups;  Noted that OSPF for IPv6 is only a draft.
Needs to be advanced.

Durand: strange feedback, spec is in draft state but WG is holding
due to lack of implementations, but lack of implementations due to lack
of spec; little pressure to move v6 related work forward

Hinden: routing protocols actually require interoperable implementations
to move forward.  Deering: OSPF is not a high risk since there is not a
competing proposal ISIS is a IPv6 hostile WG so they may have left it out
of their charter.

--------------------------------------
AGENDA: NEW PROTOCOL / STANDARDS WORK
--------------------------------------

Will IPv6 work for a Billion (or more) PDA's and Mobile Phones? (B. Hinden)
---------------------------------------------------------------------------

MOBILE PHONES
 - More Mobile Phones Sold Yearly than PC's
    o 163 Million sold in 1998
 - Currently 300 Million Users
    o Expect to reach a Billion in 2005
 - Every Phone is Networked
 - Next version of GSM has IP in it
    o Every phone will have an IP stack!

Phone networks decided v6 was not applicable since it was not a std
Deering: new groups now taking std status label more seriously Hinden:
Missing piece is wireless mobile, and scale is not addressed Nordmark: Do
the implementers understand the scaling issues Bound: Problem is ISP's
looking at GSM, others misleading that IETF declared v6 dead T'sirtis:
TV's have the same problems Hinden: More things are network appliances,
all this has scaling issues PDA's are getting more networking, and
converging with phones.

PDA'S
 - PDA Market growing Exponentially
 - Networking coming to PDA
    o Wireless just starting
 -  Some PDA's look like Mobile Phones
    o Some Mobile Phones look like PDA's
 - IP Stacks are available for PDA's now

REQUIREMENTS
 - Global Addresses
    o 2 x number of devices
    o Server Applications
 - Auto Configuration
    o Minimum of manual configuration
 - Security
    o Encrypted Transmissions
    o Authenticated Node
 - Mobility
    o Roam between Providers
 - Efficient use of Link
    o Limited bandwidth available
 - Compact Implementations
    o Limited code space

HOW DOES IPv6 DO?
 - Global Addresses
    o Lots of addresses
    o Supports large subnets
 - Auto Configuration
    o Basic functions fine
    o DNS?
    o Secure?
 - Security
    o Basic mechanisms OK
    o Plug and Play?
 - Mobility
    o Mobile IPv6 OK
 - Efficient use of Link
    o Can Header Compression be used?
    o With Security?
 - Compact Implementations
    o Should be OK

NEXT STEPS
 - Need to Address
    o Secure Neighbor Discovery and Autoconfiguration
    o Simpler Service Discovery
 - Should we Pursue this Work
    o Is it an important problem to solve?
    o Are we close enough now?
 - Where / How?
    o IPng w.g.
    o New w.g.

Nordmark: No foreign agent in current spec, general problem is
authentication of guest ethernet. Generally calls are dropped when
switching providers, so roaming registration happens on startup

Securing ICMP/ND/MLD (M. Crawford)
------------------------------------------------

Authenticating an error message
 - Security policy for informational ICMP
 
ND
 - Spoofing & DOS attacks

MLD
  ? what is the problem

Deering: How do you restrict access to multicast?  Crawford: Payload
encryption solves the problem, and the key distribution is someone else's
 
ICMP errors & informational
  - IPsec errors subgroup has worked

Solution space for ND
 - NA security concerns the right of a node to make assertions about an
address
 - RA it is not clear how to delegate the authority ; store certificate at
   subnet router anycast

Draves: how do you resolve NA Crawford: unauthenticated neighbor cache
used just to create authenticated cache Nordmark: router authentication
Crawford: how do you understand that a given prefix is valid for this
subnet; Draves: auto config problem, how do you figure out who is the
authority ???: AAA addresses this with pre-configured shared secret
Deering: multiple smart card slots in every host Mankin: work in trusted
third party solution space as thesis.
 
Solution space for MLD - (blank)
 
Work items
 - ICMP errors
 - Invade the IPsec WG and demand more

Nordmark: No one is working on the problem of how to make this better

ICMP info
 - Done deal
 
ND
 - V6 specific as spin-off of this group ;  RA is harder

 MLD
 - Almost congruent to IGMP?

Site Scoping Issues (T. Narten)
-------------------------------

Multi-homing

Source address selection becomes the key issue

How to assign block to multihomed site

How to assign addresses to nodes within site

Outbound packet filters may block from wrong source

Scope must be same for source & destination is a debated issue

State of Plug-and-Play  (B. Hinden)
-----------------------------------

"Dentist's office"
Secure "Dentist's office"

CONTEXT
 - Plug and Play likely to be IPv6's Carrot
 - Makes IP Easy to Use!
 - Lowers Cost of Ownership for Enterprises and ISP's
 - Enables Network Appliances
    o Phones, PDAs, Games, household appliances, etc.

SCENARIO 1 - ISOLATED

  [isolated figure]

SCENARIO 2 - CONNECTED

  [connected figure]

SECURE PLUG AND PLAY?
 - Is Security and Plug and Play an Oxymoron?
    o Security requires knowledge of a Secret 
    o Autoconfiguration wants to be Stateless
 - If a node knew the Secret
    o Could everything else be automatic?
    o Use Hardware token?

WHERE ARE WE NOW
 - ND and AddrConf
    o Global Address Creation
    o Router Discovery
    o IP Parameters
 - DHCPv6
 - Service Location for IPv6
 - Router Renumbering
    o Centralized reconfiguration of Router Advertisement Information
 - DNS
    o Automatic Creation of Reverse Map

Comment SLP uses URL's

Action: Hinden will write a draft defining preferred literal URL format.

WHAT IS MISSING?
 - DNS
    o How to find DNS Server
    o How to register Node DNS name
 - Services
    o How to find Printers, File Servers, etc.
    o Enterprise and Home Office solution
 - Secure Plug and Play
    o Simple, Easy, and Still Secure?

SOLUTIONS
 - Role of Service Location Protocol
    o Appropriate for General Service Location
    o Works with and without Servers
    o Can simple client only version suffice?
    o Are people implementing it?
 - DNS Server Location
    o Need Something New
 - DNS Name Registration
    o Status of Dynamic DNS Updating? 

DNS SERVER LOCATION
 - Need to Learn
    o Server Address(s)
    o Default Domain
    o Domain Suffix Search list
    o Others?
 - Issues
    o Authentication
    o Lifetimes
    o Changing

APPROACHES
 - Add Attribute to ND Router Advertisements
    o Requires configuring this info in Routers
    o What if no Router?
 - DNS Server Advertisements?
    o Does SL do this?
 - Anycast Address for DNS Servers
    o Requires further communication w/ DNS server to get other related 
information
 - Multicast Address for DNS Servers
    o Use Expanding Ring (TTL) Search

NEXT STEPS
 - Should we Pursue this Work
    o Is it an important problem to solve?
    o Are we close enough now?
 -  Where / How?
    o IPng w.g.
    o New w.g.

Discussion:

Nordmark: Will router to the Internet be a substantial services platform
as well?  Hinden: There will not be a single answer, some want minimalist
router, others want full load.  Deering: We need something that works
like appletalk; when the magic do-it-all box is broken the network still
needs to work.  Bound: Scenario 2 the box wants to be both a router &
host How can telco provide a service on minimal end point, it is
important scenario.  Durand: It is now my home network so now I the last
thing I want is a DNS server.

Conclusions: Making the isolated case work well, and securing
auto-configuration appear to be the important issues.

Issues in IPv6 Multihoming (J. Hagino)
--------------------------------------

 [No notes]

Better Support for Multihomed Hosts (R. Draves)
-----------------------------------------------

Multi-homed hosts defined several ways
 - Host with 2 interfaces into different networks

Host with 2 interfaces into the same network
 - Host with 2 interfaces onto the same link

Interfaces have several definitions
 - Physical interfaces
 - Virtual interface  (will do ND on this)
 - Pseudo interfaces (will not do ND, just exists as a matter of
   convenience)

VPN's & dial-to ISP becoming more popular 

Transition mechanisms encourage multi-homing

Firewalls exist in this space

Problems:

Next hop determination  (really next link)
 - ND has conceptual data structures per interface, but no mechanism to
   identify interface
 - Proposal to add info to RA 

Policy decision by user via multicast announced scope
  - Partial Aggregation is likely to cause more trouble than it helps

Detecting same link
 - Work in IEEE may address this

Switching to different interface
 - General case of the router renumbering issue

Weak v.s. strong host model

Deering: Old issues that will not converge, best we can do is document
the consequences for each choice

Better Support for Multihomed Sites (E. Nordmark)
-------------------------------------------------

API is the only thing missing from the day's discussion

Bound: What part is the API v.s. network layer Deering: The appropriate
place for now it the API doc

Syn6 scope ID - context dependent definition

Modifying all apps is not realistic, so get addr info

Bound: Get addr info is not scaling well in deployment

Source and Destination Address Selection (T. Narten)
----------------------------------------------------

When initiating which address to choose, selecting 'best' is not easy for
applications Favor preferred addresses over deprecated Site local v.s.
global scope; choose global if expectation is to be mobile

One way to scale multi-homed site; assign prefix for both ISP's 

Consider adding a 'middleware' layer that addresses policy

Privacy issues with use of EUI-64 IDs (T. Narten)
-------------------------------------------------

Link prefix obtained from RA.  IID could be exploited to identify user.
Uproar from privacy groups over hardware serial numbers

Potential negative PR

Is there a need to change IID more often than each reboot.  Use clock
value to randomize?

Bound: This could be a lot of work, and we already have a lot of work

Caller ID as  a model 

Making TCP use Global Interface IDs (A. Mankin/T. Narten/M. Crawford)
---------------------------------------------------------------------

 [No notes]

Formulate recommendations to the IESG/IAB, re: future IPv6 work
(S. Deering, B. Hinden)
----------------------------------------------------------------

Note: This session was held on Thursday Feb 4.

WG Docs to Finish up
 - MLD
 - ICMP revision
    o Scope-exceeded err, no error to redirect, editorial
 - Advanced API
 - router renumbering
 - merged jumbo gram specs
 - generic tunneling (add bidirectional tunnels)

Unfinished IPng W.G. work
 - Flow label standardization (no action now)
 - scope issues, source address selection
 - multihomed host/site issues
 - autoconfig <-> DNS <-> mobile IP story
 - URL format for IPv6 literal address.

 - dial-up issues?

  Work still covered under original charter.

Discussion about what "autoconfig <-> DNS story" means.  Mechanisms may
be there, but need to describe.  Additional discussion.  Comment that the
story is written.  Probably no IPng protocol work required.

Nordmark made comment that what about creating names for devices w/out
keyboards (e.g., phones, light switches, etc.).  Need generic names
and/or way of updating name via the network.

New IPng w.g. Tasks
 - Specify transient interface IDs for privacy concerns
 - Specify E.164-in-IPv6 addressing
 - Specify IPv6 over additional media
    o USB ?
    o Bluetooth ?
    o 1O Gig pipe ?
    o IEEE 1394 ?
 - Start an IPv6 "Host/Router requirements" document

Other Current w.g. chores
 - Keep all w.g. docs moving along publication / standardization track
 - Identify "base spec" of docs for advancement to full standard

Other lower-layers WGs to prod
 - DNS, DHCPv6, IPv6-over-Firewire, Mobile IP, RIPv2, OSPF,ISIS, IDR,
   MOSPF, PIM, Diff-Serv, AAA (Diameter), Malloc (maybe)

New work for other W.G.s
 - IPv6 readiness check (incl. MIBS, etc.)
 - Secure ICMP/ND (IPSEC)
 - Authenticate, Autoconfiged hosts (IPSEC)

Other idea to pursue, perhaps in new w.g.(s)
 - Specify how exchanges can work
 - TCP/UDP/host use of anycast
 - Next level of plug-n-play ("appletalk"-like)
 - 6-over-4 cut-through (NHRP-like)
 - More complete story for billions of mobile devices (esp. phones)
 - Multi-link subnets (single subnet spans multiple links)
 - Scope-name discovery
 - Conformance tests
 - Tools for reducing network mgt costs

Possible items for IRTF
 - Transport use of global interface IDs
 - Higher-layer survival of renumbering
 - Router auto-config / auto subnet numbering
 - "Better" multicast address alloc.
 - "Better" VPNs
 - "Better" billing/accounting opportunities
 - Architected MLD snooping
 - Firewall in the host
 - ICMPv3 -> MLD

 Suggestion to add better multicast routing for IPv6.

Other
 - Convey message that "IPv6" is done"; time to implement deploy, and
   port applications
 - Review/strengthen "cast for IPv6", "case against NAT" docs
 - Keep prodding IP address registry
 - Develop a voice-over-IPv6 story
 - Participate move in other WGs
 - Pass API docs to other stds bodies

Suggestion to find individuals to track work in other working groups.  A
specific individual for each group.  Will do a call for volunteers on
mailing list.

Suggestion by AD that we should update charter focus on remaining work and
how to get to completion.

Discussion about how/when to wrap up the working group.  Suggestion that
we go on "hiatus" after "base specs" are completed (Draft standard).  
Other comments that it is important to continue the w.g. to have an
"official" forum to communicate / send recommendations to ICAN, IAB, IP
registries, etc.

Chairs will discuss future w.g. steps w/ AD's and make recommendation to
w.g. 

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

Meeting Adjourned

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

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jim Bound <[email-masked]>
Date: Thu, 11 Mar 1999 11:25:12 -0500

good job. 
thanks
/jim