Subject: (IPng 6978) IPng W.G. Minutes for December IETF

From: Bob Hinden <[email-masked]>
Date: Wed, 23 Dec 1998 14:26:17 -0800

IPng Working Group 
December IETF

Bob Hinden / Nokia 
Steve Deering / Cisco
Co-Chairs

Steve Deering introduced the meeting.  Two meeting slots were scheduled.
Bob Hinden took and edited the minutes.

 Thursday 3:30PM - 5:30PM
 Friday 9:00AM - 11:30AM

The agenda was reviewed.  The resulting agenda was:

Agenda:

 - Introduction / S. Deering
 - Review Agenda / S. Deering
 - Unified IPv6/IPsec Stack / K. Kamamoto
 - Document Status / R. Hinden
 - IPv6 Code Points / R. Hinden
 - IPv6 6REN Status and Plans / R. Fink
 - Addressing to Draft Standard / R. Hinden
 - Initial IANA Sub-TLA Assignments / R. Hinden
 - IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter
 - Basic API Revision / J. Bound
 - DNS Extension to Support IP Version 6  / M. Crawford
 - Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering 
 - Jumbograms / S. Deering
 - Router Renumbering / M. Crawford
 - Multicast Listener Discovery Protocol / S. Deering
 - Separating Identifiers and Locators in Addresses: An Analysis of the GSE
   Proposal for IPv6 / L. Zhang, et. al.
 - Site Prefixes in Neighbor Discovery / E. Nordmark
 - Future IPv6 Direction / S. Deering
 - Mobile IPv6 Status / D. Johnson
 - IPv6 TCP and anycast address / Jun-ichiro Itoh
 - RPC and NFS over IPv6 / L. Wu
 - Tunnel Broker / A. Durand

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

Unified IPv6/IPsec Stack / K. Kamamoto
--------------------------------------

We decided to merge our code:

 - INRIA
 - NRL
 - Kame Project
 - to provide a single free reference code

Targets are BSD variants
 - FreeBSD
 - NetBSD
 - OpenBSD
 - BSD/OS

Schedule
 - Hopefully by next summer

Document Status / R. Hinden
---------------------------

 - RFC Published
    o RFC2460 Internet Protocol, Version 6 Specification (DS)
    o RFC2463 ICMPv6 (DS)
    o RFC2461 Neighbor Discovery for IP Version 6 (IPv6) (DS)
    o RFC2462 IPv6 Stateless Address Autoconfiguration (DS)
    o RFC2454 MIB for IPv6: UDP (PS)
    o RFC2452 MIB for IPv6: TCP (PS)
    o RFC2465 MIB for IPv6: Textual Conventions & General Group (PS)
    o RFC2466 MIB for IPv6: ICMPv6 Group (PS)
    o RFC2472 IPv6 over PPP (PS)
    o RFC2471 IPv6 Testing Address Allocation (Experimental)
    o RFC2470 IPv6 Packets over Token Ring Networks (PS)
    o RFC2467 IPv6 Packets over FDDI Networks (PS)
    o RFC2464 IPv6 Packets over Ethernet Networks (PS)
    o RFC2450 Proposed TLA and NLA Assignment Rules (I)
    o RFC2473 Generic Packet Tunneling in IPv6 Specification (PS)

 - IETF Last Call completed for Proposed Standard
    o IP Header Compression / Nov 97
       - Waiting for new draft
    o IPv6 over ARCnet Networks
       - Waiting for new draft
    o Router Renumbering for IPv6
       - IESG Comments

 - Submitted to IESG for Proposed Standard
    o IPv6 Router Alert Option
       - IESG wants to reconcile w/ IPv4 Router Alert
    o Reserved IPv6 Subnet Anycast Addresses
    o DNS Extensions to Support IP Version 6

 - IPng Working Group Last Call Completed for Proposed Standard
    o IPv6 Jumbo Payload Option
    o Transmission of IPv6 over IPv4 Domains without Explicit Tunnels

 - IPng Working Group Last Call Completed for Informational
    o Basic Socket Interface Extensions for IPv6
       - Waiting for new draft
    o Initial IPv6 Sub-TLA ID Assignments

 - IPng Working Group Last Call Completed for Experimental
    o IPv6 Name Lookups Through ICMP

IPv6 Code Points / R. Hinden
----------------------------

 - Assignments for:
    o ICMPv6 Parameters
    o IP Version 6 Parameters
 - Accepted by IANA
 - Available on IANA Assigned Numbers Web Site:

    http://www.iana.org/numbers.html

Carpenter: Important to carefully document IANA<->WG procedures for
parameter assignment.  Best to do as an RFC with big stamp of approval
from the IESG.

Addressing to Draft Standard / R. Hinden
----------------------------------------

 - Addressing Documents
    o RFC2373 IPv6 Addressing Architecture
    o RFC2374 An Aggregatable Global Unicast Address Format

 - Implementation reports available at:

      ftp://playground.sun.com/pub/ipng/implementation-reports/

   file name:

       add-arch-aggregat.txt

    o Additional reports desirable

 - Start working group last call for Draft Standard

Implementation reports available.  Bob proposes to start last call at this
point for advancement of these 2 documents to Draft Standard.  No objections.

ACTION: Document editor will start working group last call to move the
        IPv6 addressing specifications to Draft Standard.

Initial IANA Sub-TLA Assignments / R. Hinden
--------------------------------------------

 - Regional IP Registries plan to start allocating IPv6 addresses in Q1
   1999
    o Responding to requests from ISPs planning production IPv6 service
 - RIRs each need initial blocks of Sub-TLA ID's to assign
 - New draft to propose initial Sub-TLA ID Blocks:

    "Initial IPv6 Sub-TLA ID Assignments"
    <draft-ietf-ipngwg-iana-tla-00.txt>

Background

   | 3  |  13  |   13  |    19   | 16   |          64              |
   +----+------+-------+---------+------+--------------------------+
   | FP | TLA  |Sub-TLA|    NLA  | SLA  |  Interface ID            |
   |    | ID   |ID     |    ID   | ID   |                          |
   +----+------+-------+---------+------+--------------------------+

                   ^
                   |
                   |

    FP = 001 = Format Prefix
    TLA ID = 0x0001 = Top-Level Aggregation Identifier

Sub-TLA ID Assignments

      Binary            Range (Hex)       Assignment
      ----------------  ---------------   -------------------
      0 0000 00XX XXXX  0x0000 - 0x003F   IANA
      0 0000 01XX XXXX  0x0040 - 0x007F   APNIC
      0 0000 10XX XXXX  0x0080 - 0x00BF   ARIN
      0 0000 11XX XXXX  0x00C0 - 0x00FF   RIPE NCC
      0 0001 00XX XXXX  0x0100 - 0x013F   (future assignment)
      0 0001 01XX XXXX  0x0140 - 0x017F   (future assignment)
      0 0001 10XX XXXX  0x0180 - 0x01BF   (future assignment)
      0 0001 11XX XXXX  0x01C0 - 0x01FF   (future assignment)
      0 0010 00XX XXXX  0x0200 - 0x023F   (future assignment)
          .   .    .
          .   .    .
          .   .    .
      1 1111 11XX XXXX  0x1FC0 - 0x1FFF   (future assignment)

      Where "X" indicates "0" or "1".

Carpenter: Tuesday night, the IAB sent a request to IANA to assign
blocks of sub-tla's to APNIC, ARIN, and RIPE-NCC in the same manner as
specified in the draft.

IPv6 6REN Status and Plans / R. Fink
------------------------------------

IPv6 Research and Education Networks Initiative

The problem
 - Given the several years it will take to integrate existing
   implementations of IPv6 into production release products
 - and the several years it will take to work out all the details of
   making Internet applications work transparently over IPv6
 - what do we do during this interval to maintain momentum for IPv6...?

Where we are
 - We have standards, we have lots of implementations... we now need
   deployment
 - The R&E network community can now contribute substantially to IPv6, in
   the way it did to establish the Internet, ...
 - by creating production IPv6 networks suitable for real applications to
   use

A start
 - In early October, ESnet established native IPv6 over ATM peering with
   CAIRN, Internet2/vBNS and CA*net2
 - In December, with WIDE
 - and established an open participation initiative, the 6REN, to act as
   a rallying point for all RENs world-wide to provide production IPv6
   service

Isn't this just the 6bone?
 - The 6bone is a testbed network, operated under a testbed AUP, and is
   not operationally robust due to this fact
 - The 6ren is going to promote and coordinate production quality IPv6
   service
 - The 6ren is NOT a network

6REN participation
 - Free and open to all Research and Education Networks that provide IPv6
   service
 - Other for-profit and not-for-profit IPv6 networks are also encouraged
   to participate on this basis as well
 - The 6REN is more like a NANOG for IPv6

Work underway
 - A planning/formation meeting was held during this IETF Orlando meeting
   week
 - Existing 6bone pTLAs are being approached to find out can participate
   in this effort

More work
 - Working with David Kessens to provide network registry service similar
   to that provided for the 6bone
 - Reverse DNS (ip6.int) registry planned to be provided through ISI,
   under IANA oversight, as done now for 6bone
 - ESnet will provide transit for the 6bone to all 6ren participants
   (with some proviso) next line
 - Convert the early participants to production IPv6 addresses as soon as
   the registries start handing out Sub-TLAs early next year
 - Work on making these networks provide production quality IPv6 service

Also of interest
 - Effort is underway to help Australia and China RENs to develop plans
   and proposals to provide country-wide production IPv6 service
     o AARNET - the Australian Academic and Research Network
     o CERNET - the China Education and Research Network

The Environment Today
 - State as of mid-December 1998

                        +------------+    Direct native IPoverATM
                       /| Internet 2 |    PVC links w/ BGP4+ peering
                      / +------------+
                     /
          +-------+ /              +------+
          |       |/               |      |
          | ESnet |----------------| WIDE |
          |       |\               |      |
          +-------+ \              +------+
              |      \
              |       \
              |        \
           +-------+    \+-------+
           | CA*net|     | CAIRN |
           +-------+     +-------+

Providing...
 - Motivation to run real Internet applications over a native IPv6
   infrastructure
 - A possible incentive might be using it to provide a "quality" path
 - ... and because it's the "right" thing to do :-)

Applications and IPv6
 - Remember, no application we know of needs IPv6 to run
 - This is a feature, not a "bug"
 - This feature is the way we guarantee transitioning from IPv4 to IPv6
   is transparent as possible

Join the 6REN Initiative
 - See the new web site for the 6REN: 
        http://6ren.net
 -Contact Bob Fink <[email-masked]> if you have any questions
                        
Bound: Corporate America doe snot have to wait for Microsoft.  There are
reasons to deploy now.

IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter
----------------------------------------------------

Working group last call.  Draft discussed here and in NGTRANS.

Comments:

Section 7 of document will be removed because it was half baked and draft
will be reissued.

ACTION: Document editor to send "IPv6 over IPv4 w/out Explicit Tunnels"
        to IESG for PS when new draft is out.

Basic API Revision / J. Bound 
------------------------------

As soon as new ID is out, DE is submitted for Informational.

ACTION: Document editor to send "Basic API Revision to IESG for
        informational when new draft is out.

DNS Extension to Support IP Version 6 / Matt Crawford
-----------------------------------------------------

Document Status
 - Chairs requested ADs to advance it on October 15, 1998.
 - Depends on two dnsind wg drafts, which that chair passed to ADs Sep 22
   & Sep 27. 
 - One or both of which depend on "EDNS0" draft that just need a an IANA
   considerations section.

Implementation / Experimentation
 - A6, binary labels and DNAME will be in BIND 9.
 - Experimental variant of 8.2 may be available sooner.

Deployment Concerns
 - What if site is partitioned from the internet for an extended period?
   o At least two classes of solutions, including a spectrum of
     configurations choices in zone. 
      - Need applicability statement
   o Glue records need scrutiny
      - ... to see how much of the same protection is appropriate.
 - What if your provider or DNS parent makes a mistake?
   o Same foot, same gun, new bullet.

Router Renumbering / M. Crawford
--------------------------------

Two small sets of IESG comments received
 - Editorial and wording preferences
 - Request for instructions to implementors and user regarding
   retransmission strategy. 

New draft should resolve IESG issues and allow this to move forward.

Jumbograms / S. Deering
-----------------------

It was reported that we now have two interoperable implementations.  Can
this move to Draft Standard now?  Will this satisfy IESG requirements?
It was already at proposed when it was part of IPv6 specification.
Internet AD answered that it would be better to start at Proposed Standard.

Comment to combine this with TCP/UDP jumbograms to produce one Jumbogram
documents.  After some discussion, documents authors will decide
appropriate approach.

Multicast Listener Discovery Protocol / S. Deering
--------------------------------------------------

A new version of the draft is needed.  Also, found problem with behavior
when query time of zero.  Needs to be defined meaning of zero.  Zero
will mean zero delay.

Deering will issue new draft.

It was noted that is dependent of IPv6 Router Alert.

Concern raised about attack w/ zero value.  Need to make sure these
messages can not be forwarded from routers.

ACTION: Document Editor will start w.g. last call for "Multicast Listener
        Discovery Protocol" for Proposed Standard once new ID is
        published.

Separating Identifiers and Locators in Addresses: An Analysis of the GSE
Proposal for IPv6 / L. Zhang, et. al.
------------------------------------------------------------------------

History
 - Feb '97: IPng interim meeting on GSE proposal
 - draft-00 in summer '97, mostly reporting on the meeting discussion and
   consensus, received lots positive feedback and comments.
 - The authors all got overloaded, dragged on the revision for a
   looooong time period

Current State and Next Step
 - draft--3 (this IETF) mostly focus on the analysis of pro's and con's
   of separating locators and identifiers:
    o Overloading address field with both functions has its architectural
      importance
    o The separation introduces new issues that have no clear solutions
 - Request WG last call to publish the analysis as an Info RFC.

ACTION: Document editor will issue w.g. last call for publishing
        "Separating Identifiers and Locators in Addresses: An Analysis of
        the GSE Proposal for IPv6" as an Informational RFC.

Site Prefixes in Neighbor Discovery / E. Nordmark
-------------------------------------------------

Site prefixes in Neighbor Discovery
<draft-ietf-ipngwg-site-prefixes-02.txt>

Outline
 - Site model including mobile nodes
 - Proposed protocol
 - Mobility issues

Model
 - An interface belongs to (at most) one site.
 - A link belongs to (at most) one site.
 - A node (host or router) can have interfaces in multiple sites.
 - Site boundaries pass through nodes - not through links.

Model for mobile nodes away from home
 - Always considered to have one interface in its home site.
 - This interface is the conceptual tunnel to its home agent and nodes in
   the home site.
 - Implies that mobile nodes are "multi-sited".

Proposal
 - Routers advertise "site prefixes" - global address prefixes assigned
   to the site.
 - Nodes use the site prefixes to determine what global addresses are
   part of the site.
 - Site local (and global) addresses stored in the (global) DNS.
 - "Resolver" filters out site local addresses unless one or more global
   addresses match a site prefix.
    o Site locals only used when peer is known to be in same site as sender.

Prefix option format

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     | Prefix Length |L|A|R|S|Resvd1 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Valid Lifetime                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Preferred Lifetime                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Site PLength  |           Reserved2                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                            Prefix                             +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        S site prefix flag: Site PLength is valid.

        Site PLength: Number of bits in site prefix.

Example

 - RRset in DNS

    2837:a:b:987:X:Y:W:Z1       2000:1:2:987:X:Y:W:Z1
    fec0::987:X:Y:W:Z1          2837:a:b:34:X:Y:W:Z2
    2000:1:2:34:X:Y:W:Z2        fec0::34:X:Y:W:Z2
    2abc:77:66:23:X:Y:W:Z3

 - Advertised site prefixes:

    2837:a:b::0/48      2000:1:2::0/48

 - Addresses used by application:

    fec0::987:X:Y:W:Z1  fec0::34:X:Y:W:Z2

 - Instead if site prefix list is empty apps use:

    2837:a:b:987:X:Y:W:Z1       2000:1:2:987:X:Y:W:Z1
    2837:a:b:34:X:Y:W:Z2        2000:1:2:34:X:Y:W:Z2
    2abc:77:66:23:X:Y:W:Z3

Question about motivation.  Beneficial, if you think internet is not
going to renumber, wants to use site local addresses for all internal
traffic.  Only have external traffic use global addresses.  Make internal
traffic impervious to renumbering.

Comments: 

  This is a big deal and makes DNS resolver very complex. 

  Thinks draft has not been read/understood.  Thinks we should do this.
  Should we add this to BIND9?  Some work in resolver.

  Another motivation for this is that site local address are the IPv6
  equivalent of "Net10" private address space.  Some people think
  having private addresses are important.  This draft helps make this
  work.  Allows site to use both private and public with not difficult
  transition.

  Impact of deployment?  Can we get all implementations done in timely
  manner?  Requiring two-faced DNS would be a mistake.

Mobile nodes
 - Will acquire global care of address(es).
 - Might acquire a site-local care of address.  (but not useful).
 - Retain any site local address from home site.
    o Only use this when communicating over the conceptual interface to
      the home site.
 - Detect when moving away from the home site and back.
    o Using the advertised site prefixes.

Home agents
 - No changes. Proper source address selection when originating packets
   sufficient.

Correspondent nodes
 - When the binding cache for a site local destination has a global care
   of address:
    o Include a Home Agent option containing the site local source
      address.
 - Ensures that the source address of the IPv6 header is a global address
   when the packet leaves the site.

Summary
 - All nodes must start ignoring site local addresses returned from the
   DNS.
 - As site prefixes become advertised these addresses can be used.

Questions/Comments:

   This works by matching up something in ND messages w/ what is in DNS.
   Could also do DNS-DNS matching.  Reply: This wouldn't work for Mobile
   nodes.

   Deering:  Some people are unhappy with this.  

   Any impact on firewalls?  No

   Question about leakage of internal structure of DNS information
   outside of network.

   How would work w/reverse zones.  Answer in draft.  Can construct
   reverse addresses

   Jim Bound thinks this will help deployment.

Chair took poll to see if having to make resolver changes to support this
is too hard.  No strong objection.  Strong agreement to continue this
work.

Future IPv6 Direction / S. Deering
----------------------------------

What should happen next?  Lots of this we could do?  Or not.
 - more auto config, discovery of names, etc.

What chairs had in mind was to hold an interim IPv6 meeting.  Tentatively
first week of February.  Review state of IPv6 protocols and transition
mechanisms.  Identify new works, new approaches, etc.  

Initial proposal to meet at LBNL in S.F. Bay area.  First two day would
be combined NGTRANS and IPng first two days.  Third day would be
coordination, 6REN, 6BONE, etc.

Polled room to see who could attend:  Many would attend.

Another proposal to have meeting in Europe or Japan.  Possible sponsors
should talk to Chairs after meeting.

Editor Note: Subsequent to the meeting it has been announced that the
             Interim meeting will be held on February 2-4 in Grenoble
             France.  Details sent to IPng and NGTRANS mailing lists.

Mobile IPv6 Status / D. Johnson
-------------------------------

<draft-ietf-mobileip-ipv6-07.txt>

Completed w.g. last call and has been submitted to IESG.  IETF last call
should occur soon.

New Encoding for Operational Information

Unique Identifier Sub-Option

Home Agents List Sub-Option

Dynamic Home Agent Address Discovery Details

Comment:  This and RR need to handle "R" bit behavior correctly.

Miscellaneous Changes

Question: Should we put the required part for every host in separate
          document.  Would highlight this functions.  Several comments
          that this is not necessary.

ACTION: Document Editor will produce web page that lists required IPv6
        specifications.

Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering
---------------------------------------------------------------

Previously submitted to IESG for PS.  Waiting for IETF last call.

IPv6 TCP and anycast address / Jun-ichiro Itoh
----------------------------------------------

<draft-itojun-ipv6-tcp-to-anycast-00.txt>

Problem in TCP and anycast
 - Anycast addr MUST NOT be used as source addr
 - Can not disconnect TCP connection to anycast addr, by TCP RST
    o Source address must match the SYN's destination
 - Sender must wait till the TCP SYN timeout comes

       Sender                        Receiver

         S                          R, Anycast A
                   SYN
       _______________ 
                      \______________\
                                     /
                        ______________
       /_______________/      
       \            RST

When this situation happens
 - Any situations possible
    o No way to distinguish anycast addr
 - Anycast addr in DNS database
    o telnet host.foo.com  makes connection to the addr
 - Addr typed in by hand
 - Addr given to client from some server
 - We need a common way to disconnect TCP to anycast addr

Proposed Solution
 - Transmit ICMP addr unreachable
   o No restriction on source addr
   o More quick disconnection possible
      
       Sender                        Receiver

         S                          R, Anycast A
        
                   SYN
       _______________ 
         SYN          \______________\
                                     /
                        ______________
       /_______________/ 
       \           ICMP addr unreach

 - Implemented into KAME IPv6 stack
 - Works fine against BSD-based TCP stack
    o Listen to ICMP errors, disconnect TCP connection if # exceeds limit

Comments:  This should not be the behavior.  TCP is not supposed to close
connections on receipt of ICMP error messages.  This error does not
usually indicate "permeant" error.  BSD is not a good model for this
behavior. 

Issues
 - Per-address notification, not per-port
    o OK since TCP to anycast is always disallowed
 - Security
    o Malicious router can disconnect any TCP session
    o Problem is in ICMP, not new
 - Future update in anycast to allow TCP?
    o Implementations MUST make a flog to disable this
 - Need your experience for non-BSD TCP
    o Experiments welcome, at terminal room
 - UDP6 suffers from this problem too...
    o Example: name server on anycast addr

Deering:  Was hoping there would be a proposal to change TCP to allow
connection initialization using any anycast address.  Special option in
TCP to allow this.  Asked if author interested in creating a TCP option.
Reply: Likes idea but think there are security problems to deal with
this.

Problem w/ UDP is not a severe as with TCP.  Some UDP applications
already work w/ multicast.  DNS is a problem.  

Would like to experiment with this, then submit an internet draft for
consideration by the w.g.

RPC and NFS over IPv6 / L. Wu
-----------------------------

RPC is supposed to be transport independent. Why would it ever be an
issue for RPC over IPv6?
 - RPC service lookup protocol
    o Overview of RPC Service Lookup protocol
    o What are the issues
 - RPC-API

RPC service lookup protocol Overview
 - RPC Service Lookup protocol enables client and server to bind
   dynamically. 
 - It was also know as PORT MAPPER
 - Now it's evolved from the PORT MAPPER (version2) to RPCBIND (version
   3&4).  However PORT MAPPER is more widely deployed.

                                       +----------------+
   +--------+ <program, ver, protocol> |                |
   |        |------------------------->|                |
   | Client |                          |    Server      |
   |        |<-------------------------|                |
   +--------+       <port>             |                |
                                       |                |
                                       +----------------+
   Version 2:
     protocol = 32-bit integer, Port = 32 bit integer
   Version 3&4:
     protocol = string, port = string

RPC IPv6 Service lookup Issues?
 - How to lookup IPv6 RCP services?
    o Using PORT MAPPER
    o Using RPCBIND
    o Enforce IPv6 RPC services to use the port as IPv4 service?

Using PORT MAPPER
 - Portmapper Request: <program, version, protocol>
 - Proposing:
    o Create a new protocol number to indicate services running tcp over
      IPv6 and udp over IPv6.  There is no restriction in the protocol
      to be coincide with IANA number.
      
      or

    o Have PORT MAPPER listens on a different port than 111 for IPv6
      service       

 Editor's Note: in slide, they don't mean changing TCP protocol number,
                just local identifier inside of implementation for port
                mapper.

Using RPCBIND

 RPCBIND request: <program, version, netid>
 
 - Proposing netid to be:
    tcp6 - for service running TCP over IPv6
    udp6 - for service running UCP over IPv6

Enforcing IPv6 service port

 - If we are enforcing IPv6 service port to be the same as IPv4 service on
   a dual stack hosts.  There won't be any issues with IPv6 service
   lookup.

 - Proposing:

    o Not to support the above idea, because it's not possible to
      differentiate a RPC service only support IPv4 on a dual stack host.

Discussion.

RPC API
 - There are two major sets of RPC-APIs:
    o Socket based RPC-API, as known as TS-RPC
    o TLI/XTI based RPC-API, also known as TI-RPC

TS-RPC API
 - Many APIs embedded sockaddr_in as parameters, for example:

    clntudp_create(sockaddr_in *raddr,
                      rpcprog_t, prog,
                      rpcvers_t vers,
                      register int *sockp,
                      u_int sendsz,
                      u_int recvsz)
 - Proposing
    o Create new API that support sockaddr_in6

TI-RPC API
 - It's not an issue for TI-RPC APIs since no sockaddr_in structure is
   exposed 

SUMMARY
 - Use TI-RPC APIs
 - Have a separate service port for IPv4 and IPv6 service, and use
   RPCBIND for RPC service lookup with netid of TCP6 and UDP6 to specify
   services over IPv6
 - Leave PORT MAPPER for IPv4 service lookup only.  If want to extend it
   for IPv6, we have to resolve the issues.
 - Current TS-RPC API is not able to support IPv6.

Tunnel Broker / A. Durand
-------------------------

Tunnel Broker / Server

  <well known> Web page
        +-----+                      +-----+  +-----+
        |     |                     /|  S  |  |  B  |\
        |     |                    / |     |  |     | \
        +-----+          Tunnel   /  +-----+  +-----+  \  IPv6 target
          ^ |            Broker  /                      +------+
          | |                +-----+                    |      |
          | |        +------>|  B  |   IPv6 netowrk     |      |
          | |       / +------|     |\                   |      |
          | |      / /       +-----+ \4                  +------+
        1 | | 2  3/ /           \     \                   /
          | |    / /5            \     V                /
          | V   / /               \  +-----+  +-----+  /
        +----+ / /                 \ |     |  |     | /
        |    |/ /         6          |  S  |  |  S  |/
        |    |=======================|     |  |     |
        +----+                       +-----+  +-----+  
   Dual stack IPv4 host               Tunnel server

The basic idea is to get the address of a tunnel broker from a web page
(step 1 & 2), then running a tunnel broker protocol to the tunnel broker
(steps 3 & 5) automatically obtain the address (similar to the way DHCP
provides addresses) obtain a tunnel endpoint address of a tunnel server
(step 6).  The tunnel broker would communicate with the tunnel server as
part of this process (step 4).

Discussion, many questions.

Plans on experimenting w/ this.  Later might need to standardize a tunnel
broker protocol.

Brian C: Does this replace 6over4 approach.  Reply: No, it is
complementary.

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

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]
--------------------------------------------------------------------