Subject: (IPng 6418) Chicago IPng w.g. Minutes

From: Bob Hinden <[email-masked]>
Date: Wed, 09 Sep 1998 12:53:37 -0700

IPng Meeting
Chicago IETF
August 25 & 27, 1998

Bob Hinden / Nokia, Co-Chair
Steve Deering / Cisco, Co-Chair

Minutes taken and edited by Bob Hinden

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

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

S. Deering introduced the meeting.

Review Agenda / S. Deering
--------------------------

TUESDAY, August 25, 1998, 1545-1800
  Introduction / S. Deering (5 min)
  Review Agenda / S. Deering (5 min)
  UNH Interoperability Testing Report / W. Lenharth (5 min)  
  Document Status / R. Hinden (10 min)
  New Documents to Draft Standard / R. Hinden (5 min)
  IPv6 Address Assignment Status / R. Hinden, R. Fink (10 min)
  IPv6 over NBMA & IPv6 over ATM Status / M. Jork (10 min) 
  Mobile IPv6 Status / D. Johnson (10 min)
  Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering (15 min)
  IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter, C. Jung (30 min)
  DNS Extension to Support IP Version 6  / M. Crawford (30 min) 
  PPP Extension for Prefix Allocation / K. Yamamoto

THURSDAY, August 27, 1998, 0900-1130
  Jumbograms / S. Deering (15 min)
  Maximum header length (or minimum assured payload length) / M. Ohta (15 min)
   & Make PMTUD purely optional                       
  Router Renumbering / M. Crawford (15 min)
  Multicast Listener Discovery Protocol / S. Deering (10 min)
  IPv6 Naming interoperabilty issues / J. Paugh (15 min)
  Should <...-bsd-frag-00.txt> added to Advanced API / M. Andrews 
  IP Address Allocation Ideas / Maarc Blanchet

UNH Interoperability Testing Report / W. Lenharth
-------------------------------------------------

Test period the week prior to the Chicago IETF meeting.  There was a
total of 19 participants from 10 companies/implementations.  There were 3
that were just routers, 1 hosts only and 6 router / hosts.

Companies: Compac(DEC), Telebit(Denmark), Hitachi, WIDE, SUN, IBM,
Masushita, and Microsoft Research.

Tested Areas: Basic Spec, ND, MTU path discovery, BGP4+, RIPng and
redirects.

Analysis of work:

We were unable to get all the routers to participate in a network
configuration.  Some implementations could not run "nslookup ", to get
up to date info from DNS.

IPv6:  Some vendors have serious (halting) type v6 problems, others have
solid implementations.  At this test period about 25% worked well.

Future Plans: The next test period will be at Connectathon99 in March of
1999.  The lab will continue to provide increasingly intense testing in a
v6 network environment, containing routing scenarios and network
configurations using OSPF(v6) as well as BGP4+ and RIPng.

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

RFC Published
   RFC 2373 IP Version 6 Addressing Architecture (PS)
   RFC 2374 An IPv6 Aggregatable Global Unicast Address Format (PS)
   RFC 2375 IPv6 Multicast Address Assignments (Info)

IESG Approved for Draft Standard
   IPv6 Specification
   ICMPv6
   Path MTU Discovery for IPv6
   Neighbor Discovery for IP Version 6 (IPv6)
   IPv6 Stateless Address Autoconfiguration

Deering reported that there will be a new version of the ICMPv6 draft to
fix some editorial oversights, before submission for publication as RFC.

IESG Approved for Proposed Standard
   MIB for IPv6: UDP
   MIB for IPv6: TCP

IESG Approved for Informational
   Proposed TLA and NLA Assignment Rules

IESG Approved for Experimental
   IPv6 Testing Address Allocation

IESG Previously Approved / Waiting for RFC publication
   MIB for IPv6: Textual Conventions & General Group (PS)
   MIB for IPv6: ICMPv6 Group (PS)
   IPv6 over PPP (PS)
   IPv6 Testing Address Allocation (Experimental)
   IPv6 Packets over Token Ring Networks (PS)
   Generic Packet Tunneling in IPv6 Specification (PS)
   IPv6 Packets over FDDI Networks (PS)
   IPv6 Packets over Ethernet Networks (PS)

IETF Last Call completed for Proposed Standard
   IP Header Compression / Nov 97

Submitted to IESG for Proposed Standard
   IPv6 Router Alert Option
     - IESG wants to reconcile w/ IPv4 Router Alert

IPng Working Group Last Call Completed for Proposed Standard
   Router Renumbering for IPv6

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

Carpenter also noted the Business Case for IPv6 draft, originally a Bay
Networks white paper, most recently edited by Charlie Perkins, to
eventually be published as an IAB document.  Solicits review from ipngwg.
We will do a WG Last Call when Charlie gives the go-ahead.

ACTION: Document editor will issue a w.g. last call when author give the
        go ahead.

New Documents to Draft Standard / R. Hinden 
-------------------------------------------

 - Start Planning Next Set of Document for Draft Standard
 - Possible Candidates
    Addressing Architecture
    Aggregation Formats
    IPv6 over Ethernet, FDDI, TR, PPP
    Others?
 - Next Step is to Collect Implementation Information

ACTION: Document editor will start process to advance Addressing
        Architecture, Aggregation format, and IPv6over<LINK> to Draft
        Standard.  Will also recommend any other documents currently at
        Proposed Standard.

IPv6 Address Assignment Status / R. Hinden, R. Fink
---------------------------------------------------

Address Assignment Status
 - "Proposed TLA/NLA Assignment Rules"
   o Updated based on comments from LA IETF
   o Presented Approach at RIPE Meeting in Stockholm
   o Revised based on comments received at RIPE Meeting
   o Revised based on email comments
 - Submitted to IESG for "Informational" Status
   o IESG Approved on 18 Aug 1998

Next Steps
 - Plan is for TLA/NLA Assignment Rules to become New IANA Document
 - First Requests made to Registries for Sub-TLA Assignments

Bob Fink reported that the following IPv6 sub-TLA requests have been
made:
	uunet-uk  to  RIPE-NCC
	ESnet     to  ARIN
	WIDE      to  APNIC

 - Primary intent of these initial requests is to assist registries
   in setting up their process and in interpreting the TLA/NLA rules.

 - We are NOT trying to start an Sub-TLA "Land Rush".  

 - If you NEED an IPv6 Sub-TLA AND are familiar with the "Rules" RFC,
   please proceed, otherwise wait.

IPv6 over NBMA & IPv6 over ATM Status / M. Jork
-----------------------------------------------

ION WG Last call ended
 - draft-ietf-ion-ipv6-01.txt
 - draft-ietf-ion-atm-02.txt
 - draft-ietf-ion-fr-00.txt
 - draft-ietf-ion-ind-00.txt

Issues around IPv6 over ATM in PVC mode raised by the WIDE project have
been resolved one week after the last IETF.

New ND option number in <draft-ietf-ion-ipv6-01.txt> needs official
blessing.

Document editor reported that he has put together "tentative" assignments
for this and other pending requests (e.g., IPv6 options, ICMPv6 types,
etc.).  These have been sent to the IANA.  Expects them to be approved in
a few weeks.  

ACTION: Put the "tentative" assignments on the IPng web site until the
        IANA publish them.

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

Changes in the latest Mobile IPv6 Draft

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

Completed Mobile IP w.g. last call.

Minor Changes and Corrections 
 - Advertisement Interval option MAY be included by any router, not just
   by home agents
 - Any router MAY use relaxed limits on MaxRtrAdvInterval and
   MinRtrAdvInterval to allow faster Advertisements
 - Documented new limits on MAX RTR SOLICITATIONS and RTR SOLICITATION
   INTERVAL for mobile nodes sending Router Solicitations while away from
   home
 - If a mobile node has multiple home addresses using different interface
   identifiers, it SHOULD send a separate Binding Update to its home
   agent for each
 - Finally filled in Section 2, giving a comparison of Mobile IPv6 with
   Mobile IP for IPv4

Modified Prefix Information Option Format On Router Advertisement:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Type    |     Length    | Prefix Length |L|A|R|Reserved1| 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                         Valid Lifetime                        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                     Preferred Lifetime                        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                            Reserved2                          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   +                                                               + 
   |                                                               | 
   +                            Prefix                             + 
   |                                                               | 
   +                                                               + 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

New flag bit Router Address (R): 
 - Set to indicate whole Prefix field is router's address 
 - Compatible with existing uses of Prefix field 
 - Router MUST include in solicited Router Advertisement 
 - Router SHOULD include in unsolicited Router Advertisements 

New Home Agent Information Option Format 
 - On Router Advertisement: 

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Type    |     Length    |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |      Home Agent Preference    |     Home Agent Lifetime       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

 - Allows home agent to advertise values about itself: 
    o Preference: Signed value (default 0) used for sorting reply list
      for dynamic home agent address discovery
    o Lifetime: Can give lifetime separately from router lifetime
 - Use in dynamic home agent address discovery:
    o Home agents remember values in Home Agents List
    o In discovery reply, home agent includes self in list only if not
      highest preference

Receiving Packets While Away From Home 
 - IPv6 suggests that nodes MAY reverse received Routing header for
   response packets (if authenticated)
 - But for mobile node away from home this is bad: 
    o Routing header directs packet to care-of address then to home
      address
    o Reversing Routing header would send response out looped back
      through care-of address too
    o Inefficient, and confusing to receiving node 
 - For response packets by mobile node away from home:
    o SHOULD NOT include care-of address as first hop in route
    o If no other hops, SHOULD NOT include Routing header

Address Scope Issues 
 - Packets addressed to a mobile node's site-local address:
    o Consensus is SHOULD be forwarded while away from home
    o But this behavior MUST be configurable to disable it
    o This default might change as ``sites'' and site-local addresses
      become better defined
 - Multicast packets with link-local < scope < global:
    o Same as site-local unicast above 
    o This default may change as multicast scopes become better defined

Binding Lifetime Rules 
 - New rules specified to limit lifetimes:
    o On primary care-of address registration: 
       - Home agent MUST reduce lifetime to no greater than remaining
         prefix lifetime
    o When sending a Binding Update: 
       - Mobile node MUST NOT send lifetime greater than remaining
         binding lifetime for home registration 
 - Ensures no use of binding beyond home address lifetime

Renumbering the Home Network 
 - Home agent watches for ``important'' Router Advertisements:
    o The preferred or valid lifetime for an existing prefix on the home
      link is reduced
    o A new prefix is introduced on the home link 
    o State of home agent's AdvManagedFlag flag changes 
 - When any of these occur:
    o Home agent tunnels constructed Router Advertisement with changed
      info and Binding Request to mobile node
    o Retransmits until Binding Request is answered
    o Ensures important Router Advertisement changes seen by mobile node

Question about implementation experience.  Currently CMU (adding current
IPSEC (FreeBSD), Lancaster university (Linux), National Univ. of
Singapore (Linux).

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

<draft-ietf-ipngwg-resv-anycast-00.txt>

Which part of Address Space to Reserve?
 - Many official and unofficial Uses of low-numbered interface ID's
   o End os a point-point link
   o Tunnel endpoints
   o Manually configured unicast addresses when a hardware token is not
     available for the network interface.
   o Manually configured static addresses for each of the routers on a
     link. 
 - Not possible in practice to "reserve" them for a new use (anycast).
   Thus reserve high end of space, not low end.

Reserved Subnet Anycast Addresses
 - Reserve highest 128 interface ID values for subnet anycast
 - Reserved subnetanycast addresses format:

            n bits                  121-n      7 bits
  +-----------------------------+-----------+------------+
  |      subnet prefix          |1111...1111| anycast ID |
  +-----------------------------+-----------+------------+
                                |  Interface ID field    |

 - The anycast ID identifies a particular reserved anycast addresses
   within the subnet prefix:

   Decimal     Hex       Description
   -------     ------    -------------

   127         7F        Reserved
   126         7E        Mobile IPv6 Home-Agents anycast
   0-125       00-7D     Reserved

 - Reserved in EVERY prefix on ALL links.

How Many Addresses to Reserve
 - Minimum size of interface ID is currently undefined in IPv6
 - We don't want to change that with this draft
 - But minimum size of interface ID must be bigger than reserved part of
   space: 
   o Some part if interface ID space is for anycast
   o Rest of space allows some unicast addresses
   o Reserving 128 addresses allow 1-byte interface ID's
 - Careful management retains additional flexibility:
    o Assign new anycast IDs in descending numerical order
    o Can reduce number of reserved IDs if not all assigned yet
    o Can increase number of reserved IDs if can be sure not in use for
      unicast (or if can change unicast assignments)

Discussion:

Is 127 the correct size?  Suggestions?

Deering added that the issue was what is min size of interface ID.  Do we
think that we may have Interface ID's that are smaller than 64 bits.

Nordmark: Could we move boundary to get more if we need them.

Discussion about how many to have.  Not strong opinion to change size.
Size will be kept 127.

Problem w/ bit flip, will be fixed in new version of draft.

ACTION: Document editor will issue a w.g. last call after new draft is
out.

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

Work started out in IPng, moved to NGTRANS because was related to
transition, but now back here because is another cast of IPover<Foo>
document.  Needs to be standardized in IPng w.g.

 - Uses IPv4 multicast (on site) as virtual multicast LAN.
 - No changes of IPv6 model
 - Just another IPv6over<Foo>

Two implementations currently
 - Microsoft Research on NT
 - UCLA on FreeBSD

Any issues?  Advance to Proposed Standard?

Question and discussion about default MTU size.

Suggestion to reduce to 1460 to allow tunneling / options / etc.
Discussion.  Decision to leave as is.

ACTION: Document editor will issue a w.g. last call after new draft is
        out.

DNS Extension to Support IP Version 6  / M. Crawford
----------------------------------------------------

Status of -ipngwg-dns-lookups-01
 - Merges dns-lookups-00 and aaaa-03.
    o Modified AAAA RDATA format, discussed to death in L.A.
       - 128 bits + prefix length + prefix DNS name
 - Address space delegations rely on new DNS features
    o Binary labels
       - Longest match lookups no longer needed
    o DNAME RR
 - Ready for W.G. last call

MUSTs and SHOULDs
 - AAAA prefix name MUST NOT indicate a AAAA w/ a longer prefix.  (Equal
   is OK). 
    o No good way to signal an error, so offending record MUST be ignored;
      others may exist.
    o Suggest zone maintainers run a check.
 - Address delegations SHOULD all be through DNAME, never NS.
 - SUGGEST using the tag "ipv6" uniformly in the reverse zones.

Examples

 X.EXAMPLE is dual-homed to A & B; A is dual-homed to C & D.

 $ORIGIN X.EXAMPLE
  wwww		   AAAA  ::1234::567:9ABC:DEF0 64	subnet-1.ip6
  subnet-1.ip6	   AAAA  0:0:0:1::		    48	ip6
  ip6		   AAAA  0::0		    48	subscriber-x.ip6.A.NET.
  		   AAAA  0::0		    48	subscriber-x.ip6.B.NET.
  \[x0001/16].ip6  DNAME			subnet-1.ip6
  \[x123456789ABCDEF0].subnet-1.ip6 PTR		www

 $ORIGIN ip6.A.NET
  subscriber-x	AAAA  0:0:0011::	    40	A.NET.ip6.C.NET.
               	AAAA  0:0:0011::	    40	A.NET.ip6.D.NET.
  \[x11/8]	DNAME			    ip6.X.EXAMPLE.

Usage/Deployment Notes
 - Higher and lower network entities (e.g., provider and site) must agree
   on a name like "subscriber-x" to hold the delegated prefix bits, or ...
 - Binary label corresponding to the delegated bits themselves could be
   used for that
    o Then the lower zone would have to be touched when renumbered, but
      this might be fair exchange for the unification of forward and
      reverse delegation data.

No issues raised.

Question about phase in v.s. flash cut over.  When will this DNS code be
available.  6BONE issue?

ACTION: Document editor will issue a w.g. last call when new draft is
        out. 

PPP Extension  for Prefix Allocation / Kazu Yamamoto
--------------------------------------------------------------

IPv6CP extension for prefix allocation

    +--------+--------+
    |  IPv4  |  IPv6  |    
    +--------+--------+
    |  IPCP  | IPV6CP |    
    +--------+--------+
    |       LCP       |
    +-----------------+

 - IPCP can allocate only one IPv4 address
 - In IPv6 environment, we want more!
 - Prefix allocation is necessary
 - New IPV6CP option for prefix allocation

Question about could ND be used to do this instead?  Could use this to
report prefixes?  Wasn't sure.  Might be a possibility.

IPV6CP Prefix Options

 - Common format for Request and ACK
  
     +-------+-------+-------+---------+
     | Type  | Lengt | Res.  | Entry # |
     +-------+-------+-------+---------+
     |      Reserved         | Pref Len|
     +-----------------------+---------+
     |   Valid Lifetime                |  \
     +---------------------------------+   |
     |   Preferred Lifetime            |   |
     +---------------------------------+   |      Entry
     |   IPv6 Prefix 0-3               |   |
     +---------------------------------+   |
     |   IPv6 Prefix 4-7               |  / 
     +---------------------------------+   
     |      next entry                 |
     |                                 |

Discussion.

Question asked is prefix permanent or does it go away when the PPP
connection is down?  Or how is prefix refreshed when lifetime expires?
Would like prefix to be permanent.

If approved for PPP, we should also do this for DHCP (e.g., allocation
prefix).  Maybe not a good idea.

Point made that Router Renumbering could be used for this as well.  Not
good to have multiple ways to do the same thing.  Better to use current
mechanism.

Needs further discussion.

------------------------------------------------
THURSDAY, August 27, 1998, 0900-1130
------------------------------------------------

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

When IESG advanced base IPv6 spec from Proposed Standard to Draft
Standard, one issue the IESG had was that there wasn't enough
implementation experience w/ the Jumbogram option.  The option was
removed from the base spec and published as a new internet draft.

Deering added some text to describe some error cases that were not
handled in the original text.  
Encourages people to do more real testing w/ this option.

The chairs plan is to submit the new draft for Proposed Standard and to
request Draft Standard status once interoperability has been demonstrated.

Report from Kevin Lahey (NASA Ames) that they have it running on NetBSD and
would like to do testing w/ other implementations.  They could also host
testing w/ other implementations.

Maximum header length (or minimum assured payload length) & 
Make PMTUD purely optional / M. Ohta (15 min)
------------------------------------------------------------

Limit Maximum Header Lengths
----------------------------

The Header Length Problem
 - Header Length + Playload length <= Reconstruction Buffer Size (1500 or
   ...) 
 - Fragmentation does not help
 - TCP does not work if headers before the TCP header >= 1480
 - DNS assumes minimally assured Payload length of 512 (though with a
   wrong estimate of UDP header length)
 - Not all headers are under application control

Proposal
 - Allow Transport Protocols assure minimum payload length (after
   transport header) of 1024 by making transport header length <= 64) 
 - Limit Maximum Header Length before Transport Header 192 (or 412)
   (unless PMTU is larger than 1500?  But your PMTU may vary
   dynamically...)  

Make PMTU Discovery Optional
----------------------------

Why Large MTU
 - Larger MTU means less header and packet processing overhead
 - You may want to have a LAN with huge MTU (even though RTT is small
   and CRC-error prone)
 - PMTU will almost always be between 1280 and 1500

PMTUD not Useful
 - PMTUD had limited usefulness when minimum MTU was 576
 - PMTUD not applicable for one time connectionless communication
 - PMTUD not applicable for multicast (hosts will be efficient enough to
   be able to decode multicasted video with MTU of 1280)

PMTUD is BAD because 
 - Extra burden on Routers by retry
 - No specification on retry interval

Proposal
 - Make PMTUD purely optional
 - Host should always assume PMTUD of 1280

Discussion on Limit Maximum Header Lengths:

Deering: On first topic, after discussion on mailing list, doesn't think
problem being handled is a real problem.  Applications will not create
extremely large headers.  It is a theorical problem.  As soon as a
budget is imposed on max header size, then one is forced to create limits
for every header type.  Doesn't think this will work.  In most cases every
header will be less than the maximum length.  Example of UDP of w/ IPv4
shows the problem could theoretically happen, but in practice does not.
Would also limit headers in control packets where there there is not an
issue w/ transport payload size.

Nordmark: With IPSEC in IPv4, there does not appear to be a problem
today.  No limit on IPSEC headers.  Thinks it is very limiting to limit
size.  In the future link MTU's may be different.  We should not
constrain the flexibility now without a strong reason.  It is very hard
to predict what the future will be in 20 years.  We should make it
flexible.

Comment that we should not put arbitrary limits on header size.  

Discussion on Make PMTU Discovery Optional:

Kazu:  Dislikes problems because TCP exchanges MSS, TCP can find
appropriate MTU by itself.  Doesn't like this limitation.

Deering: If there is not a retry interval, there should be.  It should be
around 10 minutes.  This is not a great load on routers.  Not
significant.  Someone reported that the retry interval in current RFC is
10 minutes.

More general issue is that eliminating the PMTUD creates an "internet
cell size" for all time.  We should not limit this.  We might want bigger
MTU's later.  What we have now is a wonderful scheme that has zero cost
and will allow us to adapt to future changes.

Comment that just because applications work well w/ 1280 or less now,
doesn't mean that they will do so in the future.  We should not limit
what we can do in the future.

Deering polled the room on each proposal.  Strong consensus to not adopt
proposed changes.

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

Issues addressed by -04 draft
 - Various working changes and typos
 - Gathering more definitions together
 - Random delay in responses.
 - Multicast target limited to an All-Routers address of site- or
   link-scope. 
    o This eliminates an obscure error condition.
 - List address formats forbidden to create, define error flag if one is
   attempted. 
 - InterfaceIndex in result message now comes from IPv6 MIB.
 - Clarify ICMPv6 checks
 - Define changes of prefix to same value so that is is never unconfigured
 - List ND parameters affected by RR.

Not addressed by -04 , in -05 alpha
 - MinLen, MaxLen bounding lengths of prefixes to be tested
 - Add explicit bounds checking for certain fields, and an error flag if
   checks flag.
 - State that implementation algorithm may vary as longs as results are
   the same. 

Not address by -04, in -05 beta
 - Limit of random response delay should be msec, not seconds
 - Use purely IPSEC, no custom authentication
    o Added a new message type to support this: Sequence Number Reset
    o Meaning: Invalidate all keys used for RR, reset Recorded Sequence
      Number to zero. 

Questions about network partitions.  Answer is that Reset is "idempotent"
and can be retransmitted.

Kazu: How could site ask request to be renumbered.  Answer: no request
reply, but provider could retransmit advertisement.

Deering: How can this be used for initial prefix assignments?

Discussion about how this could be used for initial router
configuration.

Comment to add clarification that routers should save this new info in
non-volatile storage.

ACTION: Document editor will forward to IESG for PS.  W.G. last call was
completed prior to previous IETF meeting.

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

Received comments on clarification of text.  Believes there are several
implementations.

Deering explained that MLD for IPv6 is based on IGMP version 2 for IPv4.
Version 3 of IGMP currently being designed, and a new working group will
probably be formed to shepherd that work through the Standards process.
We would expect a corresponding new version of MLD to also be an output
of that work.  The new version of IGMP/MLD adds the capability to specify
a "source filter" when joining a multicast group, so as to request
reception of multicast from ONLY a specified set of sources, or from ALL
BUT a specified set of sources.  The new version will be backwards
compatible with the current version, that is, in the presence of current
version implementations the new version will revert to current behavior.

Comment that MLD requires Router Alert.  Need to make sure that Router
Alert moves forward.

ACTION: Document editor will issue a w.g. last call when new draft is
published.

IPv6 Naming interoperabilty issues / J. Paugh
---------------------------------------------

Current Proposal for Storing IP Addresses
 - IPv4 and IPv6 addresses stored separately
 - NIS map, NIS+ table and /etc file created for IPv6 addresses
 - Prevents existing IPv4 applications from unexpectedly receiving IPv6
   addresses
 - Separate IPv6 database can be served by older slave/replica

New IPv6 Database Created
 - nodes.byname/nodes.byaddr maps for NIS
 - nodes.org_dir table for NIS+
 - AAAA record for DNS
 - /etc/nodes file for local file
 - Updated utilities to create nodes database
    o ypmake(1M), nisaddent(1M), nispopulate(1M), etc.

[slide w/ graphic]

Issues W/ Current Proposal
 - Stuck w/two "hosts" files, for ever
    o No provision for deprecating "hosts" database (/etc/hosts,
      hosts.byname, etc.)
    o Nuisance administration long after transition period
    o AI_ALL lookups requires two call s to name services
 - Is it possible to put IPv4 and IPv6 addresses in one place and still
   preserve backward compatibility with legacy applications?

An Alternative Approach
 - IPv4 and IPv6 addresses stored together /etc/nodes
 - /etc/hosts preserved for legacy applications
 - IPv6 applications will use /etc/nodes for v4 and v6 addresses.  IPv4
   lookup will fail over to /etc/hosts
 - Legacy applications lookup will continue to use /etc/hosts.

Long Term Benefits
 - One database, one lookup for IPv4 and IPv6 addresses
 - /etc/hosts can be deprecated, leaving one database for IP addresses
 - Simplified administration of one database

Risks
 - During transition, two locations for IPv4 addresses creates
   synchronization issue
 - Requires comprehensive update policies and administration model during
   transition
 - Lookups for IPv6 hosts with no IPv4 interface will always fail over
   to hosts, requiring two lookups (will require code change when
   "hosts"is removed).

Comments: Given failover, could put all IPv4 in /etc/hosts, and later add
them to database w/ IPv6 addresses.  

Should <...-bsd-frag-00.txt> added to Advanced API / M. Andrews 
---------------------------------------------------------------

Draft designed to tell kernel that it needs to always fragment and not do
path MTU discovery.  Only comments were based on security.

Wants to know if should add this to Advanced API document.

Discussion.  Consensus to fold this into revision of Advance API draft.

IP Address Allocation Ideas / Maarc Blanchet
--------------------------------------------

<draft-blancet-ipaddressalloc-00.txt>

IPv4
 - RFC1219 on the assignment of subnet numbers
 - Able to delay your decision for the final subnet mask of your net
   without renumbering.
 - Use leftmost bits for network numbers
 - Use rightmost bits for host numbers

IPv4 Example

   +------------------------+--------+--------+
   |                        |        |        |
   +------------------------+--------+--------+
                                   <--->
                              100        001
                              010        010
                              110        011
                              001        100
                              101        101
                              011        110
                              111        111

IPv6
 - Prefixes
 - Many allocation boundaries (TLA, subTLA, NLA, XLA, YLA, SLA, DLA,
   department,...)...)
 - Draft proposes a generalization of RFC-1219
    o Use left bits for the TLA allocation prefixes
    o Use rightmost bits for the LLA (last level aggregator)
    o Use <<centermost>> bits for all others

IPv6 Example

   +--------+--------+--------+------------+--------+--------+
   |        |        |        |            |        |        |
   +--------+--------+--------+------------+--------+--------+
            |      <-|->    <-|->        <-|->      |

      100                        001000                   001
      010                        000100                   010
      110                        001000                   011
      001                        001100                   100
      101                        010000                   101
      011                        010100                   110
      111                        011000                   111
                                 011100
                                 000010

Considerations
 - This is not a new allocation scheme for IPv6
 - It is there to help any organization that is allocating addresses (at
   any level: ex.: SLA to departments)
 - Informational

Discussion:

Deering thinks that a document discussing this would be valuable.
Not everyone knows these "tricks".  Nordmark thinks it makes sense to
provide the correct allocations for IPv6.  

Document should be "Informational".  Not a Standard track or BCP.

Important to change title to be clearer that this document is an IPv6
address assignment plan.

ACTION: Document editor will issue w.g. last call when new draft is out.

AAAA Record Code Point / Matt Crawford
--------------------------------------

Current RFC
 - Complete IPv6 Address (16)

Draft
 - Address "suffix"  (16)
 - Prefix length  (1)
 - Prefix DNS Name  (var)

Alternate (New RR Type)
 - Prefix length  (1)
 - Address "suffix"  (1-16)
 - Prefix DNS Name  (var)

Augments for a new RR type
 - Avoid complaints of a wrong RDATA length
 - Can add a "Type A additional section processing" rule to the new type. 
 - Save a few bytes in DNS replies
   o Estimate ~50 bytes in a "typical" NS or MX reply

Arguments against
 ????

Discussion:

Would new type require resolver to make additional requests?  New
resolver would not get new record.  When could new resolver code be
available?  Adding a new type would probably make transition easier.
Bounds thinks new type code is a good idea.  It might take a year to
deploy change, but..

Strong consensus for new type code.

Comment that record name also needs to change.  Suggestion for "A6".  

Consensus to remove unneeded initial bytes.

ACTION: Document editor will issue w.g. last call when new draft is
        published. 

Prefix Allocation / Kazu Yamamoto
---------------------------------

Model of Prefix Allocation

       +----------------+
       |                |
       |      ISP       |
       |                |
       +-------+--------+
               |
              +-+
              | |
              +-+
               |
               |
               |   <----- prefix allocation
               |
               |
              +-+
              | |
              +-+
               |
       +-------+--------+
       |                | <------ Renumbering
       |     Site       |         aka
       |                |         prefix distribution
       +----------------+

Prefix Allocation
 - Interaction w/ ISP
 - Request and Response
 - Shared key w/ ISP
 - Over tunnel?

Prefix distribution
 - Within Site
 - Command and Report
 - Secret key within site

Requirements for prefix allocation
 - Request and response
 - Key separation
 - Server discovery

Discussion:

Deering thinks that site prefix allocation being temporary
is not correct model.  More sites will be moving to permanent
allocations.  

Comment autoconfiguration is very important.  Doesn't like using PPP for
this, but would like to see routers autoconfigure.  Protocol mechanisms
is useful for cable modems, xDSL modems/routers, etc.  Likes models for
appropriate for many situations.

Some customers will not want it to be automatic, but there are scenarios
that this will useful.  Note made that DHCPv6 might be able to be
extended to handle this service.

Bringing up a new link is an implied "request".  Link coming up could
cause RR message to be sent.

Maybe a new w.g. could be formed to handle this and related issues.
Could be very broad.  Important issue.  Not sure proposed mechanisms are
adequate.  Distinction between mechanisms that require centralized
administration and those that do not.

This is an important issue.  We should continue discussion on the mailing
list.  This is very good start.  Well put on agenda for the next
meeting.

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

Charlie Perkins asked for comments on "case for IPv6" draft.  Please send
him comments at <[email-masked]>.  This is an IAB document.  Draft
is:

  <draft-ietf-iab-case-for-ipv6-02.txt

A IPng w.g. last call will be issued when the next version is published.

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

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