Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/ipngwg/ipngwg-minutes-95apr.txt

Text File | 1995-05-27 | 24KB | 504 lines

CURRENT_MEETING_REPORT_

Reported by Ross Callon/Bay Networks

Minutes of the IPng Working Group (IPNGWG)

The main agenda item was to review the documents which were (hopefully)
ready to go to Proposed Standard status.  The authors of each document
presented the status of the document, and any changes that have been
fixed due to the Last Call process.  The hope/goal is to prepare these
documents to go forward as Proposed Standards immediately following this
IETF.

After these documents are done, the next ``major piece of work'' is to
straighten out mobility for IPv6.  This however was not planned for this
IETF. There is still some thrashing out to be done by the IESG regarding
which group is to complete the work on IPv6 mobility (e.g., the IPv4
mobility group, the IPv6 group, or a new group).

Core IPv6 documents to be reviewed/progressed:


   o IPv6 base specification -- Steve Deering
   o Addressing architecture -- Bob Hinden
   o Unicast addressing architecture -- Yakov Rehkter
   o Unicast addressing format -- Yakov Rehkter
   o ICMPv6 (including IGMP) -- Alex Conta
   o Security -- Ran Atkinson
   o DNS -- Sue Thompson
   o Neighbor discovery -- Bill Simpson


Masataka Ohta requested a discussion of alternative unicast addressing
methods.  This was added to the agenda.  Brian Carpenter raised the
issue of the ultimate authority for the IPv6 address space.  There is an
IAB/IESG draft out suggesting that the ultimate authority for the IPv6
address space rests with the IANA (Internet Assigned Numbers Authority).
This was included under the extended addressing discussion.


Steve Deering:  IPv6 Base Specification

Issues brought up as a result of the Last Call include:


   o How higher levels compute pseudo headers if the jumbogram option is
     included.  This is straightforward and was fixed prior to the IETF.

   o Destination Options Type that identifies the Destination Options
     Header was assigned number 60.

   o The source routing header that was submitted as Last Call included
     a bit mask.  There was a minor error, related to which bit applied
     to which address in the source route.  This again was corrected.

   o It was proposed to ban the use of the Jumbo Payload option for
     packets which are smaller than 64k (i.e., which do not require the
     Jumbo option).  Question:  How does the group feel about this
     (clearly either would work)?  If we ban the use of Jumbo Payload
     option for smaller packets, this would allow implementations to not
     implement this unless they are attached to links which can handle
     large datagrams.  There was consensus on banning the use of the
     option for small packets.  It was agreed to add a note that if you
     do not implement this option, then you restrict the use of your
     implementation on links which can handle larger packets.

   o The recording of the path during forwarding of source routed IP
     packets has not been carried over to IPv6 (you just swap addresses,
     leaving the original list of addresses in the packet rather than
     replacing them with the addresses of the outgong interfaces).  One
     motivation for this is that cluster addresses want to be left alone
     (you might not go back via the same routers, even if you do go back
     via the same clusters).  This relates to the reversing of source
     routes.  A suggestion is that you do not reverse the source route
     if there is any route available.  The consensus is to leave this as
     it is in the specification.

   o The relative ordering of the authentication and fragmentation
     header:  A concern is that if you first reassemble and then
     authenticate, then bogus fragments can break the whole packet
     (representing a denial of service attack).  However, if you
     authenticate fragments, then bogus fragments are discarded, and the
     correct fragments can be reassembled (with more overhead).  The
     current approach allows either order, but recommends authenticating
     the entire packet (not each fragment).  However, authenticating the
     entire packet (rather than each fragment) implies substantially
     less overhead.  Consensus:  The specification is already clear that
     implementations must be able to receive packets in either order.
     The current order is fine in terms of what is recommended to be
     sent.  Thus no change is necessary.

   o In the introduction of the specification there is a reference to
     the ``region address.''  This needs to be either removed or changed
     to ``Anycast address.''  The one corresponding sentence needs to be
     fixed.  Author's choice regarding how to fix this (this is an
     editorial nit).

   o ERP (Explicit Routing Header):  This is not currently in the base
     specification in detail.  The Route header in the base
     specification will remain compatible with the current state of
     Explicit Routing Header format, by reserving the space but not
     defining the flag fields.  The proposal is that this is not ready
     to be added, and therefore should not be added to the base
     specification.  Consensus is to leave the specification the way
     that it is.

   o Privacy header:  Why isn't the code point in the IPv6 protocol
     specification?  This is largely a style issue (given that the
     privacy header is specified in one of the base documents which will
     go to Proposed Standard).  Bill Simpson proposed removing the
     authentication header from this specification also, and have all
     security, authentication, and privacy stuff in other
     specifications.  The consensus was to delete the authentication
     header section in the IPv6 protocol specification, except to
     include mention of authentication and ESP headers in the order of
     headers section.
     It was also agreed to have a small section listing all the existing
     header types, but referring for code points back to assigned
     numbers.


Bob Hinden:  Addressing Architecture

Output of the PARC meeting was listed as document version -01.  However
version -02 just came out since based on comments received, but did not
quite get to Internet-Draft (came out at the last minute).  Bob
therefore described the delta between the -01 (just after PARC interim
meeting) and the -02 version.


   o Loopback address:  An explicit note will be added that a packet
     addressed to the loopback address is never sent out of a single
     node.  What it means to be a ``node'' or ``device'' is up to the
     implementor of the node/device.

   o The definition of the term ``nearest'' is somewhat unknown.  The
     notion is that this is ``according to the routing protocol's
     measure of distance.''  The word ``nearest'' will be surrounded by
     quotes in the specification, as a minor clarification.

   o The scopes for multicast addresses was discussed.  It was agreed to
     remove the notion of a ``community'' scope.

   o Directed multicast (i.e., a multicast as the last entry of a source
     route):  This is dis-allowed intentionally in the specification.
     This is a problem due to the fact that the directed multicast would
     have the wrong source address to work correctly with current
     multicast routing protocols.  Thus the current text is correct.  A
     different (future) mechanism would be needed for directed
     multicast.

   o Will local use prefixes need to be predefined?  Yes, Bob will add
     this to the document.

   o Question:  What about clusters, packs, anycast, etc.  (whatever it
     is called this week)?  Anycast goes to the nearest (or some one) of
     a group.  Cluster is a special constrained form of anycast, applied
     to any address prefix.  There was a problem with cluster addresses
     related to how a cluster address was identified.  The Pack proposal
     was to generalize how a particular address was chosen to be the
     pack address corresponding to a particular prefix, plus some
     generalization of topological restriction.  The name was changed to
     region, and folks noticed that the definition of regional addresses
     had been generalized to be nothing more than a renamed anycast
     address (perhaps made more complex).  Thus, we now have returned to
     just having Anycast addresses.  Any unicast address can be assigned
     to more than one machine, which causes it to become an anycast
     address.  Any machine to which an anycast address has been assigned
     must know that this is an anycast address.  There is a proposal to
     assign a particular anycast address to the set of all routers on
     any subnet.  Bob will add a clarification of the anycast addresses
     to the current document.


There followed a lengthy discussion of a possible multicast address
space proposed by Masataka Ohta.  It was agreed that this was an
interesting proposal that is worth discussing and considering in the
future, but that we will not be able to resolve the scheme and
understand its implications in this meeting, and therefore should go
forward with the base specification as it currently stands.  We would
like Mr Ohta's proposal to be written up in more detail and distributed
prior to the next IETF (clearly it is beneficial to have an
Internet-Draft early enough to allow considerable discussion and
comments prior to any particular IETF).

It was agreed to progress the first two documents (IPv6 base
specification, IPv6 addressing architecture).  Therefore, a discussion
was started of the provider based addressing specifications (the two
documents by Yakov Rehkter).  There was considerable discussion pro and
con.  This was partially based on whether people like provider based
addresses.  Some opinions ranged from ``provider based addressing is the
best that we know how to do'' to ``provider based addresses are not
ideal in many ways.''  In addition, if we are going to do provider based
addresses, there may be ways to simplify the associated issue with
address changes, for example when a corporation changes its provider.
The continuation of this discussion was postponed to later.


Alex Conta:  ICMPng (Including IGMP)

There were several typos and spelling errors corrected.  References to
ICMP were replaced with ICMPv6 (different protocol value).

Section 2, introductory section entitled ICMP for IPv6, was divided into
several subsections:


   o message general format
   o message source address determination
   o message checksum calculation
   o message processing runed


TBD fields were replaced with the ICMPv6 next header value (58).

Source address determination was clarified in the case of error reports
sent in response to a packet with an anycast destination address.  Also
in the case of ``destination unreachable -- communication
administratively prohibited'' or ``destination unreachable -- address
unreachable,'' and ``Address Too Big.''  There was some concern that
this is somewhat complex, and/or not so clear.  The consensus is that we
will add a sentence saying essentially ``use the address which returns
the most information,'' then say ``for example...''  and include the
current text with ``should'' instead of ``must.''

Fields used in the checksum computation have been clarified in the case
of a Jumbogram.  (question, would there ever be an ICMP jumbogram --
yes, if it were a ping; thus it is worth specifying what to do in this
case).

The handling of unknown error messages was separated from the handling
of unknown informational messages.  Similarly, references to ICMP
messages in general was clarified to separate error and informational
messages.

Some minor editorial corrections were discussed.  An error message was
added for the case of strict source routing when the next hop is not a
neighbor.  Source address determination was clarified for time exceeded
message.  The pointer for use in parameter problem message was also
clarified.

The consensus was that ICMP is ready to go to Proposed Standard.


DNS (AAAA Records):  Sue Thompson

Bill Fink was proposing to split the addresses into two pieces:  A
provider part plus a local part.  Then if you change providers, you
change the higher level part only.

Question:  Why not just assign addresses this way:  So that when you
change only the provider part, you only change one entry in DNS, not all
addresses for one domain.  However, this seems to be a research topic.
Bill Simpson thinks that we have discussed this for a long time, and he
does not want to get back to it now.

Consensus:  The DNS for IPv6 document is ready to go to Proposed
Standard, and represents the state of the art.  Additional work may go
on as experimental.

The earlier discussion at the Palo Alto interim meeting and on the
mailing list about replacing the reverse tree lookup was not extended by
the working group.  The working group decided that the current text on
reverse tree was acceptable for elevation of the specification to
Proposed Standard, and that future design of secure, less cumbersome
approaches would not be precluded by starting from this point.


Bill Simpson:  Neighbor Discovery

A significant issue here is the handling of the node heard mechanism.

It has been suggested that there is not enough explanation in the
neighbor discovery specification regarding why the document is written
the way that it is.  When router discovery was being defined, they went
through existing protocols and decided what they liked, what they did
not like, and what they were trying to solve.  They wanted neighbor
discovery to work for a wide range of types of networks.

A lot of thought has gone into Neighbor discovery for Non-Broadcast
Multi Access media (NBMA). Here you cannot necessarily hear folks who
can hear you.  Also, neighbor discovery needs to work in a no-router
environment, and in via-a-router-when-necessary environment.  Neighbor
discovery specifies:


   o The manner for a node to solicit another node
     (using a certain multicast address hashed from IPv6 address)

   o The manner for a node to answer another node
     (using all nodes multicast)


The neighbor discovery messages include an indication of link quality.
It was agreed that a link quality value needs to be defined for the case
when the interface is not able to measure the link quality (the node can
specify a zero error rate, the link quality is then assumed to be good).

Suggestion:  Allow solicitation to be unicast if the address is known.
Also, allow response to also be sent using unicast.

Issue:  If overhearing the other guys messages is a substantial
advantage, then the node heard field is useless.

Brian Carpenter stated that the assumption of multicast/broadcast in the
NBMA case is dubious.  A different model may be necessary in some cases
(e.g., compare RFC 1577 for ATM).

Several comments were made regarding whether node heard should be in the
packet.  Some folks would like to remove node heard.  If there is a
problem, that you might have heard from too many folks implying too long
a list, you could put an indicator which says ``lots of folks'' in the
packet without being specific (however, the note taker thinks that Bill
Simpson explained that you will never have such a long list in the
``node heard'' field -- there was some misunderstanding in the room on
this issue).

In the general case (where subnet does not provide cheap multicast) when
a router is there, (suppose node A is attempting to contact node B): A
just sends data to a router.  The router then looks for B (The apparent
notion is that routers have to find the hosts anyway).  However, in
sending the solicitation the router semi-lies, using its own link
address along with host A's IPv6 address in the solicitation.  B
responds with a response sent to the all nodes multicast address, which
should imply that A will receive it.

It was suggested that non-transitive or non-reflexive failures can also
happen (with significant frequency) on Ethernet.

A proposal was made that node-heard should be in a separate document
(which might not apply to all types of links).

The term ``Asymmetric reachability'' as used includes error cases:  ``A
can hear B but B can't hear A,'' and ``A can hear B and B can hear C but
A can't hear C.''

Bill is assuming that ATM will solve the multicast/broadcast issue
(i.e., allow efficient multicast over ATM). However, it appears to the
note taker that if ATM does not come up with a multicast that one would
actually want to use in this case, then an alternative approach may be
necessary.

Further discussion of neighbor discovery was deferred to later in the
week.



IPv6 Security:  Ran Atkinson


Delta's since last time:


   o Merged IPv6 and IPv4 work since differences were minor.
   o Moved next header field to the end of the encrypted data.
   o Someone came up with a transform that preserves 64-bit alignment.
   o Changed the way the MD-5 hash was computed.
   o Moved transforms into separate, more clearly-written drafts.


Jim Bound has a major objection to having this go forward as a Proposed
Standard.  His issue is that security being a must forces him to build a
non-exportable product.  There is some question as to whether DES is
really exportable (with a license) or not.  There appears to be some
strong feeling that security is needed, and that exportability is
needed.

After some discussion, it was agreed:


   o From a technical perspective, security including privacy must be
     implemented, and is needed for Internet commerce to work.

   o Some users from outside the US have expressed an interest in
     purchasing systems which include security.



Neighbor Discovery and Addressing

Masataka Ohta presented his reason for being opposed to progression of
the two provider-based addressing documents (by Yakov Rehkter).  He is
against progressing the existing documents on provider based addressing
to Proposed Standard because the approach contains known problems.  This
will lead to a compatibility problem when we have to change addresses in
the future.  Also using part of the address space for provider based
addresses is a potential waste of space if we assign a significant part
of the addressing space to addresses which will become obsolete.

Ohta presented some aspects of his proposal.  His proposal is based on
provider based addressing, but with mechanisms to deal with change of
providers.  However, we did not have time to discuss the proposal in
detail.

In response to Ohta's proposal, Matt Crawford pointed out that the
entire address guarantees global uniqueness, not just the low order
part.  Also, 46 bits (the useful part of the IEEE space) is much larger
than 1012 (the anticipated eventual size of the Internet).

Brian Carpenter, and then the group as a whole, agreed with Ohta's
suggestion to do initial assignment conservatively, to preserve as much
as possible of even the provider-based IPv6 space.  There are two places
where this should be done:  Assignments of prefixes to providers, and
assignments from providers to sites.

There was strong agreement that we need to continue addressing work.
The provider-based documents that Yakov has written are not the end
point.

Bill Simpson is opposed to publishing the provider based addressing
documents as Proposed Standards.  He feels that architecture draft is
incorrect.  He does not feel that there are multiple interoperable
implementations.  He questioned whether we need address assignment for
initial experimentation with IPv6.  Rather, we should plan on telling
folks that they are going to have to renumber in order to do initial
experimentation with IPv6.

Roger Fajman from the National Institute of Health was concerned about
renumbering.  For example, this could happen if your connection is moved
within a provider.  Renumbering is going to be hard in spite of our
efforts.  Support for renumbering needs to be in place before the wide
deployment of IPv6.

There are really four issues:  Addressing; multiple addresses for an
interface (multi-homed addresses); how is local portion of address
assigned; how does all this work with DHCP. A proposal was made that the
addressing document should really be a request for comments (as opposed
to an ``RFC,'' which is of course often interpreted as a ``standard'').

Ross was concerned that we have not heard any new arguments for a year
plus.  In the Internet tradition, when we do not have a perfect solution
and we are not making progress, we have to go with the best that we have
(regardless of however imperfect that may be).  We will then learn from
our experience.

An informal show of hands regarding whether the architecture draft
should be published as an RFC in some form:  Yes, by about 3 to 1, with
a lot of abstentions.  Informational was the rough consensus regarding
which form the document should take.

Same informal show of hands regarding the address assignments:  There
has already been a rough consensus on adding text regarding conservative
assignment.  Overwhelming support for publishing in some form.  Also
consensus that it should be Informational.

We then continued with neighbor discovery:  Several folks had questions
regarding detailed operation, and presented detailed examples so that
Bill Simpson could explain the protocol operation.

Erik Nordmark brought up an example with two routers (R1 and R2) and two
hosts (A and B). A can hear R1, but R1 cannot hear A (i.e., there is an
error in the network, the type of error that node heard is intended to
fix).  A and R2 can hear each other correctly.  Erik's interpretation of
the specification is that A will end up picking one of the two routers
according to a criteria, and may pick R1.  However, when A tries to send
the packet to R1, it does not arrive.  How does node heard fix this
problem?

Bill's response:  this has nothing to do with node heard, and node heard
is not supposed to fix this.  If R1 has a higher preference than R2,
this just will not work.  This lead to the counter-question:  What does
node heard do then?  (Apparently it is useful in the host-to-host case.)

There seemed to be a significant amount of discomfort and lack of
understanding of the approach (including among some implementors who had
read the specification), which is clearly different from there being
known problems.  There were some folks who feel that this is no worse
than, and probably an improvement over, what we have now (ARP). Matt
Crawford suggested that we might need ``router discovery light'' and
``router discovery dark.''  John V. was hearing that this is a
complicated problem, that is not fully understood and not fully
explained in the current document.  Some implementors in this room are
saying that they are not comfortable.  We need to either strip this
protocol down to something better understood, or make it (whether the
description or the protocol) more complete.  The area director suggested
that we need a well understood protocol which does the equivalent of
both ARP and Router Discovery for networks which do not need to survive
asymmetric reachability.

Ross suggested that if we are uncertain about the node heard mechanism,
then the specification should be very clear about what an implementation
should do if it expects the field and it is missing, or vice versa (so
that we have the option of changing the mechanism in the future).

Steve would prefer a small set of protocols for a small set of overall
basic network types (i.e., not just one mechanism for all links, but not
a separate mechanism for every single type of subnetwork either).

Bill Simpson agreed to excise node heard, and questioned how much that
will simplify things.  There appear to be two issues:  Clarity of
document, and correctness of (or comfort with) the technical approach.
The group expressed (by show of hands) a mild preference for taking node
heard out of the document, and putting into another document.  We have
not reached a consensus.  Bill will revise the document.  We will put it
out for working group last call.  Bill will not put it out for three
weeks.  The working group's official editor (Bob Hinden) offered to make
an effort to edit the document for completeness and clarity.  It was
left somewhat unclear how Bob and Bill would interact on this (although
presumably they can work this out off-line).

We may need an interim meeting:  This will be arranged off-line.