Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/ipngwg/ipngwg-minutes-94dec.txt

Text File | 1995-02-28 | 43KB | 1,010 lines

CURRENT_MEETING_REPORT_

Reported by Robert Hinden/Sun Microsystems

Minutes of the IPng Working Group (IPNGWG)


Introduction

The IPng working group held five working group sessions and one
implementors meeting.  Working group meetings were held on Monday (two
sessions), Tuesday, Wednesday, and Friday.  The implementors meeting was
held on Sunday prior to the working group meetings.

The minutes were produced based on notes taken by Ross Callon, Frank
Solensky, Dan Harrington, and Robert Hinden.  Thanks to Jim Bound and
Steve Deering for reviewing and commenting on the drafts of these
minutes.


IMPLEMENTORS MEETING, SUNDAY

Terminology Notes

The minutes also adhere to convention recently agreed to on the mailing
list for the terms `node', `router' and `host'.  `Nodes' are devices
that are capable of receiving and sending packets and can be divided
into two types:  `routers' forward packets that are not directly
addressed to it while `hosts' do not.


Routing Area Report

As the Routing Area Director, Joel Halpern made a brief presentation on
the status of routing protocol support for IPv6.  Work is in progress
for making changes to IDRP as the primary means of providing inter-area
routing and the working group believes that most of the changes are
relatively straightforward.  The OSPF and IS-IS groups are also
confident that the changes they need to make to provide intra-area
routing support for IPv6 are well understood and are working on draft
documents.

The RIPv2 Working Group has a proposal ready.  Joel expressed some
reservations about allowing RIP to continue into IPv6, largely because
of some of the ways it has been come to be used as opposed to problems
with either the protocol or the underlying distance-vector algorithm
(i.e., hosts using the information seen in passing RIP packets to update
their own forwarding tables).  He was planning to meet with the RIPv2
group during the week to listen to their arguments in favor of continued
support and was reminded by Bob Hinden that the simplicity of the
protocol itself is one of its strengths for non-complex environments and
by Robert Elz that even if use of the protocol is going to be
discouraged, the document should still be written so as to reduce the
likelihood of incompatible implementations springing up as the result of
it not being documented.

[Reporter's Note:  Subsequent to this session, the RIPng work was
approved by the Routing AD and the RIP working group will take on this
task.]



ESP Bit Alignment

Randall Atkinson described some of the concerns about Encapsulated
Security Payload (ESP) proposal raised during discussions within the
security area; one of the main ones was the specified alignment of the
fields:  some of them currently are aligned on 32 bits but not 64-bit
boundaries.  The consensus was to require the addition of
algorithm-dependent padding after the security association ID (SAID) and
immediately before the protected data to maintain 64-bit alignment,
recognizing that this pad may be relatively long in some cases.  Padding
may be random bits rather than zero-filled to make it harder to crack.

There was a discussion about considering the possibility of ``Security
Lite'' in which certain specific packets are authenticated, but not all
packets (for example, security critical ICMP packets such as redirects
are authenticated).  The idea is to make it much harder to break in with
minimal performance impact.

[Reporter's Note:  The remainder of this presentation was repeated at
the Tuesday working group session.  See that section of the minutes.]



API v4-v6 commonality

Jim Bound asks about the APIs:  What happens when an IPv4 application
wishes to interoperate with a server running over IPv6.



Security API

The question was raised on whether separate API documents should be
written:  one that presents the general API and another with security
extensions.  The group preference was to have a single document with an
appendix that describes the details when using DES-64 so as to reduce
the likelihood that implementations will be written that can only
support one.


Multicast Address Mapping

Steve Deering asked the group if it might be advisable to change the
manner in which multicast IP addresses are mapped into Ethernet
addresses.  The current practice is to retain the low-order 23 bits of
the class D address which penalizes performance due to the additional
masking operations.  The group's preference was to reserve a full block
of Ethernet numbers from IEEE and use the entire 48-bit MAC address as
the low end of the 64-bit IPv6 address.


MTU Size

The general consensus of the group was to recommend changing the MTU to
1500 bytes from the current 512, Ran Atkinson pointed out that anything
larger makes life painful for existing satellite communication (SATCOM)
implementations.  Justin Walker reminded the group of a recent
discussion on the mailing list regarding packet fragmentation over
Apple's Localtalk if the MTU is going to be larger than 587 bytes but
the group preferred to use the larger value and request Apple to develop
some means of supporting single-hop fragmentation and reassembly rather
than define IPv6 with the smaller MTU. Justin offered to bring this up
to the right people within Apple.

The minimum buffer reassembly size remains at 1500 bytes.  This would be
reiterated within the regular working group sessions to see if any
significant issues came up as a result.


Route Reversal by ICMP or Destination

The SDRP group accepts the idea of having a bit specify that the route
is believed to be reversible and is to be interpreted as a hint as
opposed to a mandate.  If the bit is not set, the reversing system
realizes that the route is not to be reversed; that is, it must look it
up on its own.


Multicast API

A question came up in regard to the API used on a router when
originating multicast packets:  did some argument need to be added that
specified which interface would be used to transmit a packet?  The
answer was no:  multicast uses a similar API as IPv4 in that a socket
specifies the source address through a bind() call, this determines
which interface is to be used for transmitting packets.  If an attempt
is made to send raw packets to an unbound socket or one that is bound to
INADDR_ANY, it is an error.

The ``all-hosts'' group is defined to be all nodes minus all routers.
Thus, a router by definition is not a host, and must not join the
all-hosts multicast group.  Routers join all-routers and all-nodes.
Hosts join all-hosts and all-nodes.


TCP MSS

None of the current draft specifications point out the fact that TCP
will have to advertise a different Maximum Segment Size (MSS) when used
with IPv6 than with IPv4, over a path with the same MTU, due to the
larger IPv6 header size.  This needs to be documented.


Miscellaneous

Should implementations use IPv6 preferably over IPv4?  How do you know
whether the implementation is doing IPv6-special features?  The current
idea is that use of IPv6 encapsulated over IPv4 as the default.  There
is an argument that it will be easier to deploy IPv6-capable dual-stack
hosts if we make the initial deployment as painless as possible.  Also,
we know for sure that for the next year or two IPv6 will be lower
performance and less robust than IPv4.  Thus, if we really want folks to
deploy IPv6 soon, we should not require that folks actually use it in
those cases that IPv4 would work well.


WORKING GROUP, MONDAY

Steve Deering introduced the meeting.  The goal of the meeting was to
review the specifications and resolve open issues.  There were no
overviews presented, attendees were expected to be familiar with the
documents.


Agenda

   o Review results of implementors meeting
   o IPv6 base protocol specification
   o ICMP/IGMP
   o Addressing architecture
   o Unicast provider address formats
   o NSAP addressing
   o Security
   o Neighbor discovery
   o DNS specification
   o Flow IDs
   o Header compression
   o Proposed new header types


Review Results of Implementors Meeting


Robert Hinden gave an overview of the IPng implementors meeting held at
Digital Cambridge Research Lab.  The implementor's meeting does not make
decisions regarding protocol issues.  Thus, any apparent agreement at an
implementors is not a binding agreement, but rather is just a
recommendation to the working group.  The purpose of this review was to
present the recommendations to the working group and gauge the consensus
on them.

Addressing model:  The implementor's meeting recommended that we stay
with the IP model of one address per interface.  However, a single
address can be assigned to multiple physical interfaces on the same
physical subnet if the implementation treats the multiple interfaces as
a single aggregate and hides the details of this from the Internet
level.  Also, routers may have unnumbered interfaces on point-to-point
links.  For router to host point-to-point links, the host must have an
address.  The working group agreed to this model.

Cluster addresses:  Keep them in the specification as ``reserved.''  Not
actually used until there is a very clear proposal and understanding
regarding how they may be used.  Cluster addresses are currently used
for system discovery, this will need to be resolved.  A suggestion was
made to use the ``pack'' model to augment cluster addresses.  After some
discussion the working group agreed that the ``pack model'' should be
used and the next version of the addressing architecture document should
be updated to reflect this.

Neighbor interactions:  We will continue with the approach in Bill
Simpson's draft.  This continues a request/response model (similar to
the current ARP model), but implemented as extensions to ICMP. This was
agreed to by the working group.

Host knowledge of prefixes:  Agreed that host will learn the subnet
prefix(es) to be used from routing advertisement.  Routers must be able
to include these prefixes in Router Advertisements.  It did not make the
minutes, but some folks recalled that a router should be able to
redirect a host to a different prefix (for example, when there are
multiple logical subnets on a single physical network).  Also, there was
a preference for a router to not advertise any prefix, in which case the
host will need to go to a router.  This is another case in which the
router may need to be able to redirect a host to an address which the
host does not think is on the same subnet.  There appears to be a bit
more work needed in this area.

Scope of Discovery:  Remove the proposed service location extensions
from the discovery document.  The details (e.g., specific packet fields)
of system heard messages are still under consideration.  System heard is
only needed in some circumstances (e.g., wireless links with some
particular characteristics).  What fields should be in the system heard
message is being discussed.  This was agreed to by the working group.

ICMP: There should be a ``packet too big'' message as a separate error
message, and not just a subtype.  The 16-bit error pointer can in theory
point beyond the end of the packet.  These can be useful with IPv6
because of the sequence of header types.  Thus, the pointer tells you
which header it was that was in error.  We need to be clear and
unambiguous regarding where the pointer should point for any particular
error.  This was agreed to by the working group.

ICMP redirects are to be described in Bill Simpson's system discovery
specification.  This was agreed to by the working group.

The ICMP error message is to include a maximum of 576 (or whatever the
min MTU ends up being) bytes of the offending message.  Redirects only
need 40 bytes, but for simplicity should do the same thing as other ICMP
messages.  This was agreed to by the working group.

Auto-address assignment had a 16-bit field which provided the address
lifetime.  It was decided that this was not big enough, so the field has
been expanded to 32 bits, and a value of ``infinity'' defined.  This was
agreed to by the working group.

There was a long discussion of transition and testing.  The
auto-encapsulation rules are to be left as currently defined.  These
issues are in general likely to cause more discussion.

There was discussion regarding DNS. It is desirable to allow
implementations to fall back on local files (for example, to allow
initial testing of hosts before DNS is updated).  This was agreed to by
the working group.

Text representation of addresses was discussed at length, and will be
left as is.  This was agreed to by the working group.

Every host needs to be able to reassemble a datagram up to 1500 bytes.
The minimum MTU remains at 576 (the minimum MTU includes the IP or IPv6
header).

Alan Openheimer of Apple offered to discuss the implications of a larger
MTU on localtalk implementations.  The issue is that localtalk only
supports 576 (or very slightly larger) packets.  Thus, if the 576 MTU
were increased (e.g., to 1024 or 1500), systems with local talk
interfaces would need local (subnet-dependent) fragmentation and
reassembly.  One of the motivations for increasing the MTU size is that
DNS is looking to add new capabilities which require a large minimum MTU
size.  In general, with IPv6 we are trying to avoid internet-layer
fragmentation.  This implies that a larger minimum MTU might be a good
idea.  PPP can support (more than) 1500.  There is an issue with SLIP.
Also, there is a latency issue when a small packet gets behind a large
packet on a slow SLIP or PPP link.

Ran's satellites have a problem with greater than 1024.  If we agree on
greater than 1024, then they will have to tunnel, and pay the price.

Bill Simpson would like link-specific F&R over all or most links.

The rough consensus of the working group was for a minimum MTU of 1500.

Reversing Source Routes:  The implementors meeting recommended a bit in
the source route which states whether the source route is believed to be
reversible.  The degree to which this is ``a hint'' versus ``required''
in each direction was discussed.  1 = OK to reverse.  0 = ``don't
reverse.''  This was agreed to by the working group.

Packets greater than 64k:  Consensus is to use a hop-by-hop option to
use a length field of zero as a flag which says that an option includes
the real length field.  This was agreed to by the working group.


IPv6 Base Protocol Specification

Steve Deering reviewed issues with the current base protocol
specification.

Expected future changes:


   o Have chosen not to split up the document.  (Will have ``the basic
     set'' of headers.)

   o Replace type 0 routing header with ERP


There was a discussion of encoding of the extension headers.  Some folks
would like a common format in the sense that each header starts with a
(implied type and) length in the same place and format.  For example,
this could make it simpler to build certain ``not entirely router''
entities, such as header compression devices which can compress only
some types of headers (and does not want to know anything about other
header types), or fragmenting bridges.  The consensus was to be to leave
things unchanged.

Options have an encoding which tells you what to do if you do not
understand the option.  This is not necessary for things that are
required.  Tracy Mallory is concerned that this is not extensible, in
the sense that if we define a new routing header type in three years old
IPv6 routers will not know how to deal with the new field.  Jim Bound
would like a common format to speed up header parsing.

Routing Header Format, continued:  Robert Elz proposed a piggy backing
format, which allows smallish packets to be combined/nested.  Headers
start with an 8-bit ``next header,'' 8-bit ``protocol'' (this header),
and a 16-bit length.  His proposal allows nesting:  two packets which
use the same IPv6 header can share a header, such that the common header
is only sent once.

We could imagine a case where a packet does not actually carry anything,
but is used, for example, to initialize or continue a flow.  Thus you
want the packet to actually end after some internet-layer (IPv6-related)
header.  This requires that a possible value for next header should
specify ``no next header.''

Jumbograms:  Where does this exceed existing format:  Fragmentation
header.  The proposal is that fragmentation of a packet which is greater
than 65,535 be prohibited.  IPv6 deprecates Fragmentation -- this is
included only for compatibility with old IPv4 stuff (both for header
translation and also for old applications which are designed to run over
IPv4).  These old applications cannot run with bigger than 65,535
anyway, thus there is no need to support fragmentation of datagrams
larger than 65,535 bytes.

This resulted in a discussion of whether jumbo gram support is needed at
all.  There was a clear consensus that there is no need to change the
format of the fragmentation header in order to support fragmentation of
jumbo grams.

TCP MSS needs to be adjusted (since IPv6 header is larger than the IP
header).

Minimum MTU is being raised to 1500, based on this mornings discussion.
This once again makes the minimum reassembly buffer size equal the
subnet MTU.

Destination Options:  These are for ``intermediate destinations,''
meaning routers listed in the source routing field.  The end to end
options can be renamed for this, and the location (before or after the
routing header) will tell you whether it is for the ``real'' end, or for
the next ``mentioned in source route'' router.

Tunneling (IPv6 over IPv6):  There has been lots of mail on the mailing
list.  The underlying encapsulated link is treated just like a normal
data link (this observation can be used to derive all or most details of
the tunnel operation).  There is an issue regarding whether you want to
``expose the TTL of the tunnel,'' by copying the TTL between the two
IPv6 headers, so that traceroute shows the intermediate hops in the
tunnel.  Clearly there are some cases where the folks in the middle do
not want to expose their topology.  Thus, there will be some cases where
it is appropriate to decrement the outer TTL by one for the entire
tunnel.

What if I am doing security type tunneling?  Answer:  Clearly there is a
need for the ``opaque tunnel'' (decrement by one) type of tunnel.  The
question is whether there is a need for the other kind as well.  If we
support more than one kind of tunnel, then the appropriate place to
control which type is at the tunneling point.  It is proposed that the
specification allow both forms of tunnel.  It was pointed out that
regardless of what the specification says, folks are likely to implement
both.  Steve is proposing that the specification should recommend that
both be implemented.  Tracy Mallory pointed out that this is not of much
use unless the link layer of the internal net is returned.  Also, the
address space used interior to the tunnel could very well be different,
resulting in uninterpretable errors.  Also, when there is a
configuration error, the encapsulating end of the tunnel might put in
its own (large) TTL, and the de-encapsulating end of the tunnel might
copy this into the packet header, resulting in the TTL getting larger as
a packet traverses its path (in principle a dangerous thing).  Thus, if
we have two types of tunnels, there is the possibility of (due to an
error) confusing the two types.  There are ways that we could indicate
in the packet which type of tunnel is being used.


ICMP/IGMP Specification

Steve Deering reviewed the current ICMP/IGMP specification.  There is a
new specification, which just came out (on xerox Parc FTP), to become an
Internet-Draft soon.

IGMP is merged into ICMP. The latest version of IGMP is being used.

Packet too big is no longer a subtype of destination unreachable, but
rather is its own ICMP message type.

Unknown Header Type is changed from unreachable to be a subtype of
Parameter Problem.

Redirect is removed from ICMP and put into neighbor discovery.

Should there be a redirect per flow/traffic class?

There should be a new protocol type for IPv6 ICMP.


WORKING GROUP, TUESDAY

Addressing Architecture

Bob Hinden reviewed the remaining issues with the addressing
architecture document.


   o Text formats for addresses
   o Cluster addresses
   o Representation of the default route


There is an issue regarding the use of colons in e-mail addresses (some
folks currently use IPv4 addresses in their e-mail address).  One answer
is to not use IPv6 addresses in e-mail (it is getting a bit big for ease
of use).  Another option is to fix SMTP user agents to accept colons
(they are not used otherwise in e-mail addresses, but some existing
software will not like them).  Some folks think that this is a
non-problem, and if we sit here and list all possible characters we will
be wasting time.  The consensus (not so rough) was that we like the
address text format the way that it is currently defined.

Cluster Addresses:  This is a prefix of length ``n'' bits, followed by
128-n bits of zero.

An alternative is the ``Pack'' addresses.  For any particular
cluster/pack:  Take any specific unicast address (which is appropriate
for this topological part of the network), assign it for use in this
way, and use it as a cluster address.  The pack address approach
therefore avoids the problem of requiring that the prefix not have a
trailing zero (since this would create an ambiguous cluster address),
but requires that systems which need to know their address and also
their associated cluster address will need to be configured (or
auto-configured) with two complete addresses, rather than an address
plus a prefix length.  However, this ``Two-Address-Configuration'' is
probably a good idea regardless of which format is used.

A problem for cluster address approach is that:  (i) you effectively
lose one bit at each level (the last bit at each level must be ``1'');
(ii) If you add a new level split in the middle, you may have to
renumber (and also lose the bit in the middle).  The only way to
guarantee that you will not have to renumber in this case is to only use
addresses with ``1''s in all bit positions, which is clearly
impractical.

The consensus therefore is to use the Pack approach (although not
necessarily the name, which appeared to be less popular than the
technical approach).

Proposal that the zero length prefix be used for default unicast route.
Anything that deals with multicast will need to announce reachability to
a longer prefix to match multicast routes (which will automatically take
precedence over the zero length prefix).



Unicast Provider Address Formats

Yakov Rekhter presented the proposed unicast provider address formats.

An address registry can have multiple blocks of addresses assigned to
it.  The IANA is the highest level Internet address registry.  Bill
Simpson proposed to not fix the provider based address to always use a
particular three bit prefix.  Rather, just assign some blocks for this
purpose.  Steve argued that the three bits is a coincidence, and we have
really done what Bill suggests (and it is just a coincidence that the
first three bits always happens to be the same for currently assigned
unicast provider based addresses).  It was pointed out that this needs
to be very clearly described to avoid misunderstanding.  Thus this
discussion is really editorial (we want to make sure that the document
is clear).  All that routers should assume about address formats is that
they are doing longest prefix match, on bit boundaries.

A number of editorial comments have been received, which Yakov will fold
into the document.

The standard topological hierarchical address discussions (particularly
with respect to multi-homed stub domains) were repeated.

It was agreed that the ``actual allocation'' draft should list actual
providers/address registries, and the address prefixes that are assigned
to them.  These might happen to be assigned
geographically/topologically, with space left for expansion, but we do
not want to stress any geographic basis of this.


NSAP Addressing

Alan Lloyd presented a ``teaser'' (ie, introduction of issues to be
discussed) for the NOSI BOF.

Alan's addressing goals:  To provide harmonization between ISO NSAPs and
IPv6 addresses.  To permit ISO to administer some of the IP address
blocks.  To provide a network design approach that enables address
convergence to IPv6.

Requirement:  to have compatible address forms for NSAPs and IPv6.  IPv6
in NSAPS are easy.  For NSAPs in IPv6, propose to assign first bytes of
IPv6 addresses to be compatible with some NSAP AFIs.  These need to use
assigned NSAPs which fit into 16 bytes.  This thereby allows
``bi-lingual'' addresses.

Migration idea:  (1) consolidate longer NSAPs into Internet NSAPs.  (2)
(I did not get the rest of this, it flew by rather quickly).

Action items:  Get IETF and IANA to do this.  Get ISO to assign
addresses appropriately.

Questions and issues regarding this proposal were deferred to the NOSI
BOF. No consensus was sought at this meeting.  However, Bill made sure
that he voiced his disagreement now, since he is likely to miss the NOSI
BOF.


Security

Ran Atkinson discussed security issues.

Security causes a performance impact.  May cause ``packet bloat'' and
``kernel bloat.''

Common encryption for IPv4 and v6 is impractical (thus you cannot
translate encrypted packets).  This is particularly caused by the lack
of willingness for the IPv4-security group to accept 64-bit alignment.

Padding and alignment (do we want to give up bits in order to keep
everything 64-bit aligned in IPv6?).  Some encryption algorithms require
padding to a natural block size.  The consensus at the implementor's
meeting was that the 64-bit alignment was worth maintaining.  A new
format is proposed to ensure proper padding.  This can require three
pads (one to ensure that encrypted fields start on 64-bit boundary, one
to ensure that the protected data start on a 64-bit boundary, one to
ensure that the encrypted data ends on a proper boundary for the
encryption algorithm being used).

ICMP for IPv4 uses a different protocol ID than ICMP for IPv6.

Do we distinguish different sorts of encrypted data (encapsulated IPv4,
IPv6, ICMP-4, ICMP-6, UDP, TCP, IGMP), or just all as
IPv6-packet-contents?

Straw Poll:  Where should the next header field be:  at the beginning of
encrypted data, or at the end?  Straw vote was just about even, with
``don't care'' being the largest plurality.

When including part of a discarded packet header in an ICMP error
report, the authentication of the interior (discarded) header is not
likely to work.  Thus do not check it.  (note that the same comment
applied to the checksum for IPv4).

A faster alternative to MD5 is being investigated.  This needs to be
checked carefully in order to ensure that it is actually secure.  One
advantage of MD5 is that it is commonly used elsewhere (e.g., SNMP). On
the other hand, MD5 is already considered to be relatively weak.

Suggested to be able to authenticate ``security critical'' packets for
``less processing intensive'' partial security.  The goal is to avoid
paying the performance loss of encrypting all packets, but still be
significantly harder to break than no security.



WORKING GROUP, WEDNESDAY

Neighbor Discovery

Dead Node Detection needs more explanation.  Negative advice from other
layers is the only way to expire a cache entry early (we do not depend
on symmetric paths, this means that receiving a packet on the reverse
path does not ensure that the forward direction works).  If TCP
discovers that it does not get an ACK after multiple tries, then
something is not working, and it is a good idea to invalidate the
associated cache entry and re-solicit router discovery (although there
are many possible causes of this other than the first hop router being
broken).  Link layer down indicators clearly should be used to
invalidate a cache entry.  There was some debate regarding use of good
and bad higher level information.  It was argued that receiving a TCP
ACK ensures that the TCP packets actually arrived at the destination,
which in turn ensures that the forward path works (including the first
hop router).

Another argument for using higher layer information to shorten, but not
to lengthen, the cache timeout is that we are more interested (in case
of doubt) in shortening the timeout:  We need to find failed routers
quickly.  On the other hand, assuming that the general timeout period is
set to imply that router discovery results in a light load on the
network, then there is not much to be gained by lengthening the period.
However, if you shorten the timeout period considerably, then you could
lengthen when an ACK is received.  In this case the host would
re-solicit very rapidly if it ever failed to get the TCP ACK. Clearly
this only works for TCP.

We are agreed that IPv6 hosts MUST not listen to RIP or OSPF packets.

It is proposed to change the lifetime field to hundreds of seconds.
This is because there are some environments where first hop loss needs
to be detected within less than a second (and where the network
administrators are willing to pay for the extra network/host/router
capacity required to do router discovery more often than once a second.
Thus, the standard should make this possible.

Note that router discovery is not intended to indicate that you are
using the wrong first hop -- rather, this is the purpose for the
redirect.

If the cache is timed out, the host does not re-solicit until it has a
packet to send.  At this point, the host should transmit the packet to
the old entry even if it has timed out (and re-solicit router discovery
at the same time):  If the old entry still works, then this is the right
thing.  If the old entry is a black hole, then there is no harm in also
sending the packet in addition to the re-solicit.

Current Text:  For communication from Router to Host, Host to Router, or
host to host, if you have a packet to send and no entry, you send the
packet to the IP unicast address, using a multicast link layer address
which is a (well-known) hash of the IP address.  Then send a solicit.
Note that if the TCP ACK returns, then more TCP packets may subsequently
be sent using the same method.

Proposed at Boston:  Do not transmit the data packet.  Buffer the (most
recent if multiple) data packet while doing the solicit and waiting for
the advert.  However, this should be clarified/extended by allowing
``semi-expired'' cache entries, which are old enough to cause a solicit
when used, but which are young enough that we might as well use then to
forward packet (preferentially to dumping the packet, or buffering
them).  Some folks wanted to think about this, given that it is a
somewhat new proposal.

Gratuitous advertisements (advertisement without a corresponding
solicitation):  A motivation was for a machine with two interfaces on
the same link, that when one interface fails they want to send a
``gratuitous reply'' immediately on the second link, to get arriving
packets to go that way (either by advertising the second link address,
and/or by actively invalidating the first entry, perhaps via using a
lifetime of zero).  An alternative is to change the link layer address
of the second link to be the same as the first, but this does not work
for some hardware.  There appears to be a consensus to allow unsolicited
advertisements, but solely for the purpose of flushing previous
advertisements.  This must not check the mac address, since the ``cancel
previous advertisement'' may come from the systems other mac (the one
which is still working).

Questions:  Are there other concerns?  The following list of topics of
concern was compiled:


   o The system discovery draft should have no mobility in it (for
     clarity purposes) (the mobility protocol is not yet even close to
     agreement).  One motivation was to simplify initial
     implementations.  Another reason is that mobility is not yet
     agreed.  This was vigorously discussed, but no resolution was
     reached.

     [Reporter's Note:  This was discussed and resolved in the Friday
     session.]

   o There should be no reference to cluster addresses.  In some cases
     things are called cluster addresses when they should be subnet
     prefixes, or just prefix.  With this agreement, the comment become
     editorial detail.

   o Change identifiers (changing prefix on a link to a new prefix).
     This got changed to a way to tell hosts that a prefix is going
     away.  This is also used in a remote redirect (which says that this
     old prefix will not be routeable anymore).  Note that remote
     redirect may be used both for mobility, and also for some other
     purposes related to SDRP and policy.

   o ``Target ID.''

   o Hop cache description does not belong in the specification (but
     this has already been removed from base s.d.  specification and
     moved to an appendix).  Thus this comment has been resolved.

   o Routing information extensions are needed to tell a host which
     stuff is attached to the directly attached subnet.

   o The process document talks about having a random solicitation
     delay.  The reason for this is to avoid having everyone expire the
     same cache entry at the same time and all re-solicit at the same
     time.

   o Cluster bit -- one comment did not know why this is there.

   o Why do we not use solicitations to create a cache entry.

   o Source address selection mentions something about longest match.

   o How is the source address specified and what is the packet format?
     A different packet format was also proposed.

   o Redirects.  including remote redirects.

   o Hop Limit advertisement.

   o Static routes should be discussed in processing document (there
     already is a discussion of this).

   o Choosing a source address.

   o Maximum time intervals -- we should allow a wider range.

   o Two things in the document do not belong:  A whole bunch of
     implementation details should be moved to an appendix (some already
     have been).

   o Minimum advertisement interval appears to be too large.

   o General point:  Some of the things in the document are oriented
     towards mobility.  This has not been settled yet.

   o More fields should be added to the general advertisements.

   o A concern about the packet format and use of TLV.


It was not possible to resolve all of these open issues during the time
remaining.  Therefore, the Friday morning implementors meeting was
changed to be a ``real'' working group meeting, a larger room is being
solicited, and we switched to considering DNS.


DNS Specification

Sue Thompson reviewed the issues with the current IPv6 DNS
specification.  A new Internet-Draft was sent out and did not get any
response, except for one comment that it was very well done (from Bill
Simpson).  Inverse lookup is based on nibble boundaries.  This is the
only known issue (since bit boundaries would be nice).  An approach has
been proposed to do the reverse lookup in two queries, using two
different trees.  This will be discussed in more detail in the DNS
group.  We agreed that if the DNS folks fail to agree on the new scheme
quickly, then we will go with the nibble boundary.  It was also pointed
out that folks are not maintaining the inverse tree particularly well
today, and thus we do not want to ask them to populate two reverse
trees.

One suggestion was made that it is not a good idea to be able to map
addresses back into names.  For example, this is likely to be
impractical to automate, and automating DNS tree maintenance is critical
to really large scaling of IPv6.

This discussion was referred to the DNS group (which is meeting later in
the week).


WORKING GROUP, FRIDAY

Auto-Address Configuration

A proposal was made by Steve Deering that we refocus the work on
auto-address configuration.  Specifically that the ADDRCONF Working
Group should only focus on a simple IPng stateless auto-address
configuration mechanism and that all other work in this area be done
using DHCP. This implies that the DHCP working group should be chartered
to develop IPng specific mechanisms for DHCP.

There was a lengthly and heated discussion.  A rough consensus emerged
that it made sense to pursue this path of supporting a very simple
auto-address configuration utilizing router multicasts of prefixes and
hosts using the prefix with local information to create an address as
long as there would be a escape mechanisms to require the hosts to
contact a DHCP server.  The IPng working requests the ADDRCONF Working
Group pursue this.


Mobility

There was a general agreement that while it was important that there be
mobility in IPng, that there was no consensus on which approach to
follow.  As a result the group agreed to remove mobility specific items
from the current discovery drafts.


Core Specifications

The IPng area directors request the working group to define which are
the core IPng specifications.  The definition of core was that these be
the specifications which when completed and submitted for proposed
standard, the IPng area will disband.

The following documents were considered by the IPng working group to be
part of the core set of IPng specifications:


     IPng Specification

         R. Hinden, Editor, IPng Protocol Specification, Internet-Draft,
         draft-hinden-ipng-ipv6-spec-00.txt, October 1994.

     Addressing Architecture

         R. Hinden, Editor, IPng Addressing Architecture,
         Internet-Draft, draft-hinden-ipng-addr-00.txt, October 1994.

         Y. Rekhter, T. Li, An Architecture for IPv6 Unicast Address
         Allocation, Internet-Draft,
         draft-rekhter-ipng-arch-IPv6-addr-01.txt, October 1994

         Y. Rekhter, P. Lothberg, IPv6 Preferred Unicast Address Format,
         Internet-Draft, draft-rekhter-IPv6-address-format-00.txt,
         November 1994.

     Internet Control Message Protocol

         A. Conta, S. Deering, ICMP and IGMP for the Internet Protocol
         Version 6 (IPv6), Internet-Draft,
         draft-ietf-sipp-icmp-igmp-00.txt, September 1994.

     Transition Mechanisms

         R. Gilligan, Simple Internet Transition Overview,
         Internet-Draft, draft-gilligan-ipv6-sit-overview-01.txt,
         November 1994.

         R. Gilligan, E. Nordmark, Transition Mechanisms for IPv6 Hosts
         and Routers, Internet-Draft,
         draft-gilligan-ipv6-trans-mech-00.txt, November 1994.

         D. Haskin, R. Callon, Routing Aspects Of IPv6 Transition,
         Internet-Draft, draft-haskin-ipv6-routing-aspects-00.txt,
         November 1994.

     Security

         R. Atkinson, IPv6 Security Architecture, Internet-Draft,
         draft-atkinson-ipng-sec-00.txt, November 1994.

         R. Atkinson, IPv6 Authentication Header, Internet-Draft,
         draft-atkinson-ipng-auth-00.txt, November 1994.

         R. Atkinson, IPv6 Encapsulating Security Payload (ESP),
         Internet-Draft, draft-atkinson-ipng-esp-00.txt, November 1994.

     Discovery

         W. Simpson, IPv6 Neighbor Discovery -- Design Requirements,
         Internet-Draft, draft-simpson-ipv6-discovery-req-00.txt,
         September 1994.

         W. Simpson, IPv6 Neighbor Discovery -- Processing,
         Internet-Draft, draft-simpson-ipv6-discov-process-01.txt,
         October 1994.

         W. Simpson, IPv6 Neighbor Discovery -- ICMP Message Formats,
         Internet-Draft, draft-simpson-ipv6-discov-formats-01.txt,
         September 1994.

     Domain Name System

         S. Thomson, C. Huitema, DNS Extensions to support IP version 6,
         Internet-Draft, draft-thomson-ipng-dns-00.txt, October 1994.

     Auto Configuration

         D. Katz, IPv6 Address Autoconfiguration Protocol, Message to
         [e-mail] mailing list, October 23, 1994.

     Program Interfaces

         R. Gilligan, S. Thomson, J. Bound, IPv6 Program Interfaces for
         BSD Systems, Internet-Draft,
         draft-gilligan-ipv6-bsd-api-00.txt, October 1994.

     IPng Overview

         R. Hinden, IP Next Generation Overview, Internet-Draft,
         draft-hinden-ipng-overview-00.txt.


The following documents were considered to not be part of the core
specifications:


     Header Compression

         W. Simpson, IPv6 Header Compression, Internet-Draft,
         draft-simpson-ipv6-hc-00.txt, September 1994.

     OSI NSAP Mapping

         B. Carpenter, J. Bound, Recommendations for OSI NSAP usage in
         IP6, Internet-Draft, draft-carpenter-ip6-nsap-map-00.txt,
         August 1994.

     Mobility

         W. Simpson, IPv6 Mobility Support, Internet-Draft,
         draft-simpson-ipv6-mobility-00.txt, November 1994.


The following documents belong to non-IPng working groups, but still
need to be done:


     Routing

         G. Malkin, RIP for IPv6, Internet-Draft,
         draft-ietf-ripv2-ripng-00.txt, November 1994.

         Y. Rekhter, P. Traina, IDRP for IPv6, Internet-Draft,
         draft-ietf-idr-idrp-v6-00.txt, November 1994.

         F. Baker, R. Coltun, OSPF IPv6 Extensions, Internet-Draft,
         draft-ietf-ospf-ipv6-ext-00.txt, November 1994.


Neighbor Discovery

The issues from the Wednesday working group session were discussed in
more detail.

Mobility Extensions:  This will be removed per earlier decision.

Random (dithering) Solicitation Delay:  Group agreed to not delay
initial transmission of router solicitation.

Cluster bit:  Group agreed that each advertised prefix shall have two
associated bits, indicating (a) whether or not the prefix may be used to
form a self-configured host address, and (b) whether or not the hosts
may assume that all destinations with that prefix are directly reachable
on the immediate link.  If no address-configuration-allowed prefixes are
advertised, hosts are expected to use DHCPng to obtain their addresses.

Why not use solicitation to form a cache entry?:  This generated a long
discussion of address resolution issues.  Group agreed to keep current
approach.

Longest match source address (bitwise compare):  No agreement.  Issue
taken off-line.

Range of time values:  Request had been made for 100 msec.  granularity.
No room currently for larger values, hence upper limit of 650 seconds.
Group decision to increase field size to 32 bits.

Redirects:  There was a request for a new code value?  Group decided to
keep as is.

Discuss Static Routes:  Currently not referenced in sending rules.
These need to be reviewed on the list.

Packet format/TLV Concern:  Proposal to redo the formats of the
discovery message to have a fixed header portion with the fields that
are required and to only use the extensions for optional fields.  There
was a weak consensus to further explore issue.  Bob Hinden will work
with Bill Simpson.

Hop Limit Advertisements:  Discussions with conclusion that API should
allow the default value to be overridden.  No change from current
specifications.


Next Meeting

Meeting ended with the announcement of an interim working group meeting,
around the first week in February.  It will be a two day meeting on the
West Coast.

[Reporter's Note:  The meeting was scheduled for February 9 and 10, at
Xerox PARC in Palo Alto, California.]