Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/94dec/area.ipng.94dec.txt

Text File | 1995-02-28 | 13KB | 289 lines

IP: Next Generation Area

Directors:


   o Scott Bradner:  [e-mail]
   o Allison Mankin:  [e-mail]


Area Summary reported by Scott Bradner/Harvard and Allison Mankin/NRL

Meetings of the following groups were held during the 31st IETF meeting
in San Jose:


   o IPNG Directorate (NGDIR)
   o IPv6 MIB BOF (IPV6MIB)
   o New Generation Transition BOF (NGTRANS)
   o Next Generation and OSI BOF (NOSI)
   o Transition and Coexistence Including Testing BOF (TACIT)
   o Address Autoconfiguration Working Group (ADDRCONF)
   o Address Lifetime Expectations Working Group (ALE)
   o IPNG Working Group (IPNGWG)


The IPng Recommendation by the IPng Area to the IESG (RFC 1752) had been
passed in between the Toronto and San Jose IETF meetings.  This was the
first meeting at which the new IPng Working Group met (and met, and met,
and met...).

The IPng Directorate had a final open meeting, at which the main topics
were the duties of the IPng Area before its closing down and
international implications of requiring the encryption protocol header
for IPv6.  The IPng Area was asked to shepherd a group of specifications
(between 10 and 20) to submission, rather than just the base
specification.  The IESG Security Area Director, Jeff Schiller, sat in
and led the security discussion, which renewed consensus for the
recommendation.  The co-Area Directors had two plenary presentations,
one a status update and the other an overview of the state of IPv6
address assignment, with presentations by Bob Hinden, Daniel Karrenberg,
Yakov Rekhter and the IANA (Jon Postel).

Given the recommendation that the IPv6 suite of specifications be ready
for submission to the IESG before the 32nd IETF, it was an even busier
meeting for the IPng Area than Toronto.

The IPng Area will be dissolved by the time of the Danvers IETF, having
completed the duties with which it was charged.


IPv6 MIB BOF (IPV6MIB)

This was the first BOF to discuss network management for IPv6.  It met
for one session in San Jose.  The agenda included changes to existing
standards track SNMPv2 documents, potential changes to existing MIBs and
new and additional MIBs.

The relationship between IPv4, IPv6, and Applications was briefly
addressed.  For example, should (can) we strive for common Managed
Objects between IPv6 and IPv4?  If so, should (can) all or some of the
Managed Object be in common?

The list of MIBs affected by IPv6 were determined to include:


   o MIB-II
   o Forwarding Information Base
   o Routing Protocols
   o Link specific MIBs (e.g.  IPCP)
   o Accounting MIB
   o RMON-II
   o Host MIB


Though there is keen interest in management work related to IPv6, the
BOF did not take up the question of proposing one or more working group
charters.  It was decided to take this up with the the IPng co-Area
Directors and also to start a mailing list for follow up of the BOF's
initial work, ip6mib(-request)@research.ftp.com.



New Generation Transition BOF (NGTRANS) and Transition and
Coexistence Including Testing BOF (TACIT)

The charter for NGTRANS was passed by the IESG and IAB two weeks after
the San Jose meeting, but it met as a BOF for two sessions at San Jose.

The NGTRANS BOF met on Tuesday December 6 and Wednesday December 7.  The
Wednesday meeting was a joint meeting with the TACIT BOF. The
Internet-Drafts discussed at the meeting included Bill Simpson's ``IPv6
deployment'' draft, Bob Gilligan's ``transition mechanisms'' draft, and
Ross Callon's and Dimitry Haskin's ``transition routing issues'' draft.
Alan Lloyd presented some ideas on addressing.  The group's charter was
briefly discussed, as was a general proposal for a division of
responsibility between the TACIT and NGTRANS groups.  The group agreed
in principal to the division of work, with the details to be taken up on
the mailing list.  Bob Gilligan agreed to re-issue the ``transition
mechanisms'' Internet-Draft as a ``mechanisms only'' document, with
policy issues to be discussed in another document.  Remaining work for
the group includes specifying the transition mechanisms in detail, and
working out the routing issues.



Next Generation and OSI BOF (NOSI)


About 35 people attended the BOF. Presentations were made by Brian
Carpenter (summary of possible requirements, scenarios and mechanisms);
Ross Callon (outline of the Avoid Brutal User Transition (ABUT) plan);
Jim Bound, Jack Houldsworth and Dan Harrington (three variants of how to
carry NSAPs in IPv6 headers).

Rapid agreement was reached that three mechanisms should be pursued in
any case:


   o RFC 1006bis (ISO transport over TCP, small mods to existing RFC)

   o Classic CLNP over IPv6 tunnels (NextHeader = CLNP; probably no new
     document needed, at most a very short RFC)

   o TP4 over IPv6 (requires some real work, volunteer needed)


It was also agreed that Ross Callon should write up the ABUT outline.

There was a lot of discussion about the need for and the details of
carrying NSAPs in IPv6 packets.  The ideal would be to find a way to
combine the best aspects of the three proposals.  It was agreed to
continue this discussion on the NOSI list in the expectation of reaching
closure at the next IETF in a second BOF. Also the IANA is looking at
Alan Lloyd's and Jack Houldsworth's proposals to allocate some IPv6
address space as genuine NSAP space.



Address Autoconfiguration Working Group (ADDRCONF)


The three ADDRCONF sessions were spent discussing open issues in the
latest draft document.  The issues spanned design details such as the
constraints needed to ensure unique addresses when operating in
stateless mode, how to form addresses on media other than IEEE 802
links, the need to support address reuse, and how hosts determine a
server is available after it has been down.  Larger issues were also
discussed such as the protocol used to transport messages (link layer,
ICMP or UDP), the need to support DNS autoregistration and the
relationship to DHCPng.  One significant issue was raised regarding
whether it would be better to separate the stateless versus stateful
protocol, but this question was not resolved within the sessions
themselves.  The issue was discussed in the last IPng Working Group
meeting and is to be followed up on the ADDRCONF mailing list.  Some of
the above issues were resolved; having a separate stateless protocol is
likely to make resolution of the remaining issues easier.



Address Lifetime Expectations Working Group (ALE)

The ALE Working Group met on Wednesday evening.  As a result of the
apparent growth trends presented during the Toronto meeting, the group
recommended to the International Engineering Planning Group (IEPG) that
it may soon become necessary for IANA to start assigning network numbers
out of the upper half of Class A (aka:  `A-sharp') number space for
CIDR-like IPv4 address assignments.  The IEPG asked ALE to identify the
issues that such a plan would raise and recommend workarounds.

One issue was discussed during the CIDR Deployment Working Group (CIDRD)
meeting earlier that afternoon:  a router that was configured with a
default next-hop address and a route to a single subnetwork of a Class A
network number was unable to forward packets to the other subnetworks
within that same Class A network.  A software upgrade solved this
problem; ALE and CIDRD recommend having all service providers require
`classless' routers.

Since the IPng Area is expected to disband in the near future and much
of the remaining work also falls within the scope of the CIDRD Working
Group, it was suggested that the IPv4-ALE group merge with CIDRD.

While performing the numerical analysis during the preceding weekend, an
inconsistency was discovered in the two most recent IP Allocation
Reports:  the counts of Assigned and Allocated Network Numbers in the
October report had dropped by 1% for Class B numbers and 14.4% for Class
C when compared to the August report.  Since there is no mechanism in
place for numbers to be returned to IANA, it was assumed that there must
be a bug in the program generating the reports; representatives from the
InterNIC were notified of the problem earlier in the week and planned to
investigate it as soon as possible.

The linear growth model, presented by Tony Li, included these last two
data points while the logistic model, presented by Frank Solensky, did
not.  Both models currently suggest that IPv4 addresses would be
depleted around 2008, give or take three years.


IPNG Working Group (IPNGWG)

The IPng working group held five working group sessions and one
implementors meeting.  The Friday session included joint discussions
with ADDRCONF and NGTRANS.

A highlight of the Sunday meeting was the presentation, by Joel Halpern,
the Routing Area Director, on progress on IPv6 routing protocols:  SDRP,
OSPF, IDRP and IS-IS are all working on IPv6 versions.  The RIPv2
Working Group has a proposal for RIPv2ng ready.  The IPng group
presented a number of arguments to Joel against his reservations about
allowing a RIP to continue into IPv6.  [Note:  Subsequent to this
session, the RIPng work was approved by the Routing Area Director and
the RIPV2 Working Group will take on this task.]  The rest of the Sunday
meeting was devoted to specific implementor concerns, all of which were
then brought to the full working group in the rest of the week.  [Note:
an implementor's meeting does not make decisions regarding protocol
issues.  Thus, any apparent agreement at an implementor's meeting is not
binding, but rather is just a recommendation to the working group.]

The working group agenda for its many sessions was to review all of the
specifications and resolve all open issues that could be identified,
either from the March and Sunday implementors' input or from the floor
of the working group.

The agenda overview was:


   o Review results of implementors meetings
   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


A very high level summary is presented here from a long set of notes
prepared by Bob Hinden.

The working group chose not to split up the base protocol document, so
it will contain the complete ``basic set'' of headers.  The type 0
routing header will be merged with/replaced by the format developed in
the Source Demand Routing Working Group (SDR) for Explicit Routing
Protocol.

In address architecture, there was consensus to use the Pack approach
instead of clusters:  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 proposed unicast provider address formats review centered on
registry format and clarification of the document.  An address registry
can have multiple blocks of addresses assigned to it.  The IANA is the
highest level Internet address registry.  All that routers should assume
about address formats is that they are doing longest prefix match, on
bit boundaries.  It was agreed that the document must make this very
clear, as discussion indicated that it seemed to convey that there was a
fixed 3 bits of registry ID in the format.

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.

Detailed notes on the other agenda topics will be found in the full IPng
Working Group minutes.