Subject: draft minutes from IPng WG meetings in Oslo

From: Steve Deering <[email-masked]>
Date: Wed, 28 Jul 1999 07:35:13 -0700

Here are the draft minutes from the Oslo meetings; please send any
corrections to Bob Hinden and me.  Many thanks to Allison for such
fine notes -- reading them almost made up for not being able to
attend in person!

Steve

--------

Minutes of the meetings of the IPng Working Group in Oslo, July 1999

Meetings chaired by Bob Hinden
Minutes recorded by Allison Mankin

Wednesday, July 14

I. Agenda Bashing

It was reiterated that Steve Deering was unable to attend Oslo
because of a family emergency.

Dave Johnson announced that the mobile-ipv6 draft was resubmitted
just before meeting, and it is very close to final, but still needs
to have added clarification about IPSEC. No major agenda item about
it in this IETF's meetings, but attendees invited to comment on IPSEC
there if needed, or else via the email list.

II. Document Status - Bob Hinden,

RFC:

Basic API published as RFC2553.

Approved for PS by IESG:

Jumbograms.

IETF Last Call completed for DS:

Addressing Architecture and Aggregatable Global Unicast - the IESG
needs reports of experience with scoped multicast forwarding and
there is IESG concern about how to standardize architecture docs.
Does DS need to wait until a large enough deployment has occurred to
indicate how scalable the addresses are? During IETF week, there are
some offline discussions related to the 8+8 decision; the IAB
workshop on the Network Layer recommended talking about it.

IETF Last Call completed for PS:

Router Renumbering is back at IESG, and they are not waiting for a revision.

DNS extensions - dependent docs have been approved, but the draft is
waiting for revisions covering how to handle resolver behavior during
the AAAA/A6 transition - an update is on today's agenda.

Multicast Listener Discovery is ready for IESG ballot.

Submitted to IESG for PS:

Router Alert - WG last call finished without comments today, so it
will be sent to IESG now.

Submitted to IESG for Informational:

The GSE analysis was at the IESG for a long time. About two weeks
ago, the authors received a security review from Steve Bellovin,
requested by the IESG. Steve, the authors, some ADs, and Bob Hinden
were to meet during Oslo to discuss the review, and there will
probably be a document revision.

WG Last Call completed for Informational:

The initial sub-TLA assignments draft was never submitted to IESG
because preliminary discussions with the IANA and registry people
suggested we wait for action by them. Their action has happened:
there will be an announcement at the plenary tonight that the IANA
has delegated the first allotments of sub-TLA space to the three
registries.

A Method for Flexible Assignment - This draft is close to be ready
for submission, but the author has been asked to revise it some to
provide more context.

The Case for IPv6 - Some comments are being forwarded to the authors.
Note that this document will be sent to IESG as an IAB doc, not
IPNGWG.

III. Updates - Matt Crawford, FNAL

DNS Lookups:

IETF Last Call was issued 14 June. Remaining issue is specification
of resolver behavior during the aaaa to a6 transition - the straw man
proposal for this had very light discussion on the mailing list.

ICMP Name Lookups:

Near ready for WG Last Call - one known issue is that the lookup
request hashes the name using a CRC32, noting that this should be
fine because it is not a hash for security purposes. Some people have
asked that it use an IPSEC hash instead, simply because IPSEC hashes
already have been implemented in stack and will not entail extra
code. Matt noted finally that there has been no complaint about the
draft's specified multicast address.

Other:

There are potential interactions between Router Renumbering and
mobility: for instance, if you set or clear the R flag in the router
advertisement. Question is how to minimize the coupling of the two
documents so as not to delay the standards track progress of either
one. Hinden commented that RR was further along than IPv6 Mobility,
so perhaps the right thing would be for the latter to reference the
former. Hinden took an action to ask Thomas Narten for an AD opinion
on this, since Thomas was not in the room at that point.

There are similar interactions between RR and the site-prefixes draft.

Questions:

Itojun asked when A6 will be implemented. Answer: Bind 9 will have
it. The last word Matt had was that its ETA is the coming fall, but
Matt got that update 3 months ago.

IV. CSI - Hiroshi Kitamura, NEC

The Secretariat republished the original draft as 01 instead of using
the updated text. This presentation is an update from his
presentation at last IETF.

Connection/Link Status Investigation (CSI) is a traceroute or
pathchar type mechanism using one new HBH option and three new ICMPv6
messages -
- CSI HBH option
- ICMPv6 Status Request/Status Reply/Status Report

The basic mechanism is to send a message with a pre-allocated space
for each hop to record the requested information in. Scalability of
this space is handled by having a node which fills the remaining
space send a Status Report back and forward on the Request with the
original space now cleared for new information. The CSI option may be
disabled by nodes and then they mark a bitmap with 0 in the position
of the skipped node. This mechanism is limited to 24 hops. A change
between the 00 and 01drafts was to eliminate the version field, and
plan on using a new investigation type code when going to a new
version of a particular investigation type.

Issues include: which address to record from among all assigned to an
interface. The proposal would be to use rules like those for source
address selection, keyed to the destination address in the ICMPv6
header.

To economize on the space, there is a mechanism for IP address
compression - in a large scale net: record upper part, small scale
net: lower part. The speaker did not address how you would determine
and specify which compression mode to use.

The speaker stated why CSI can be said to be simple to implement:
none of the envisioned investigation type responses have to be
rapidly processed in the routers and they do not require intelligence
or complexity there - the model is that the data is collected by the
requester and analyzed offline.

The speaker has implemented a tool called tracestatus, and suggests
it can replace ping and traceroute. The code may be released soon.

Comments -

Comment: It's less simple than traceroute, which requires nothing on
routers. It is also not true that you can simplify by saying no
security considerations enter into it. Answer: there are security
considerations in draft 01. Answering about traceroute: if the
function had been seen as necessary early on in the IPv4 development,
then maybe the IPv4 designers would have chosen to create something
like CSI, but IPv4 option problems ruled out that thinking later.

Crawford: Note that timestamp definitions within the draft are
inconsistent. Asks if it is necessary that this be ICMP? Suggests
that the option field might also need to include a Router Alert. Can
routers disable some types of data but allow others? Answer - that
can be set as a policy but as currently specified, the replies cannot
tell the requester about the specifics.

Durand asks if this is a working group item - Hinden says not sure if
WG supports. Similar 1997 proposal by Durand and others did not have
working group support. Preference by Hinden now is keep as individual
submission until work is more mature. If people disagree with that,
say something now. Author is asked to label next draft as individual
submission, not draft-ipngwg-hbh-etc..

Haskins - this might belong in operations area.

V. UDP-Lite - Lars-Ake Larzon , Lulea University

The presentation proposed a small change to UDP aimed at realtime
applications in error-prone environments. IP in cellular nets
experiences errors and delay, and there is an increasing interest in
the use of error-tolerant codecs to get tolerable performance for
realtime flows. For this, the IP/UDP checksumming is not optimal -
UDP will drop damaged packets which the error-tolerant codecs
delivered as damaged but usable. And, of course, disabling the UDP
checksum with a zero value as in IPv4 is not permitted for IPv6.
Transport layer properties wanted for the realtime applications over
cell - low complexity for low protocol overhead, checksum coverage of
just the protocol headers, allowance of delivery of damaged frames.
Proposed solution: UDP's packet length field is redundant because the
IP header has it too - so replace it with a field called Checksum
Coverage that specifies how much of packet from the beginning of the
UDP header should be covered by the checksum. If checksum coverage is
less than packet length then that remaining part of packet will not
be checksummed. Examples:

- Voice over IP (VoIP) using IP/UDP/RTP - cover only headers
- VoIP with compressed RTP - with checksum covering only the headers,
  they have measured that there are 40% fewer context synchronization
  losses and TWICE will succeed more often. More details on this will
  be presented to the AVT WG on Thursday.
- 64 kbps PCM audio over cellular - normally cellular would not be
  used for this voice encoding because of its too limited bandwidth.
  However, there are tests of using it and recovering from the
  extensive packet losses. More packets get through when UDP-Lite is
  used; a clicking sound  occurs from the losses, which the application
  can filter out.

One of the arguments for standardizing on UDP-Lite is low deployment
cost, because it can look exactly like regular UDP by simply having
the full length in the Coverage Field. It could be deployed as a
separate protocol parallel to UDP, but the speaker asks consideration
for replacing UDP in IPv6 with UDP-Lite, since there has been limited
deployment to date.

Comments:

Hinden: First thought is that UDP is usually considered in transport
area. On the other hand, IPNGWG has changed the checksum of TCP/UDP
so it's probably OK to consider UDP-Lite here.

Comment: Doesn't this conflict with having underlying protocols that
are checksummed themselves, like PPP radio? Answer: link protocols
for IP over cellular are not settled yet, and there is ongoing work
on link layers that deliver the damaged frames.

Draves: how does an application ask for less coverage? Answer: the
default behavior is to look like ordinary UDP, and in their
implementation, the application uses a socket option to set lesser
coverage.

Comment: this WG made UDP unsafe for the applications described by
requiring the checksum, unlike IPv4, so it is our responsibility to
fix the problem. The commenter also agrees that the data link layers
haven't been fully defined for newer digital cellular such as UMTS.

Crawford: Though new transport doesn't necessarily belong here, this
WG also has worked on jumbograms, and note this would interact with
jumbograms. Hinden: note a new comment on checksum limitations for
very large datagrams that the IESG had the authors to that draft.
Speaker: we think being able to specify coverage only as far as 64K
would be OK, but also, the semantic of zero in the Coverage field,
meaning the entire packet is covered, means you can request coverage
of the whole jumbogram.

Hinden took an action to talk to the ADs. He'd lean to making a
separate UDP because there have already been investments in UDP as
is. Another of the authors of UDP-Lite added as a last word that the
changes to UDP are 2 lines of code.

VI. TAHI Project: IPv6 Code Verification - Nobuo Okaba, Yokagawa
    Electric Corp.

The TAHI project was started in 1998, funded by the Japanese
government. Its objectives are conformance and interoperability tests
for IPv6, to be made publicly available.

The current coverage is 106 tests for hosts, taking about 6 hours to
complete, and 56 for routers taking about 3.5 hours. Unattended
operation works fine. Among tests of basic function still to be done
are: RS/RA functions of the router and Redirect. The implementations
that have been tested so far are Hitachi NR60, various versions of
KAME, and some NEC prototype host code. The development plan is to
complete the basic spec by 8/99, ICMPv6 by 10/99, IPSEC by 12/99,
v6/v4 Tunnel by 12/99, Address Architecture by 12/99.

Testing on the ipv6-unified kernel will be started next month. Test
package releases are planned every two months. Results for both KAME
and ipv6-unified will be published. Both the test spec and testing
code will be published. Plan an interop event in October in Japan.
Begin checking the TAHI web site for these various developments in
August 1999 - www.tahi.org

Itojun: Can you describe how TAHI is distinguished from UNH. Answer:
a major difference is that all the test programs will be openly
available, as will test results such as the ipv6-unified.

Dave Johnson: When will TAHI make tests for mobile IPv6. Answer:
sometime in 2000. Dave: January looks open.

A demo in the IETF laptop room was available by arrangement. Code to
be tested is welcome. One can get in touch using [email-masked] or
[email-masked].

Question: are the tests hand-coded in C or using a specification
language? Answer: in C.

VII. IPv6 in GSM-like Infrastructure - Hossam Afifi, INRIA Sophia

The hypothesis of this presentation was that the IP over cell phone
standards currently being developed for GSM and its successors could
fail to be deployed because of complexity, and, in that circumstance,
an IPv6 stack for current GSM could become a viable standard. IPv6
can provide improvement and simplification of GSM networking .
Draft-afifi-sixtel-00.txt, by the speaker, Jim Bound and Laurent
Toutain is the basis of the talk.

GSM has a few 100 million users today - both voice and data modems.
It is a success story like the Internet. There is a standard for data
transfer over wireless, GPRS, which is viewed as an extension to GSM.
Hypothesis is that it is not successful like GSM. It is currently
standardized by not deployed. UMTS (3GPP) and IMT2000, representing
the next generation, are not yet standardized.

There are two kinds of mobility in GSM, from cell to cell within one
switch (MSC) and between MSCs. The Home Database is with your home
MSC, and the Visitor Database is updated when you change MSC. The GSM
functions are in a Call Management layer, Mobility Management layer,
and Radio Resource layer. GPRS does not use this architecture, but
has a different fixed database structure. You can have equipment that
is GSM only, GPRS only, or both. GPRS has many complex services,
including a reliable multicast. Frame Relay is used between base
stations and the databases. A slide showed GPRS as having complex
protocol stacks in the database (SGSN) and base stations.

A simple way to add IPv6 to cell telephony is just to use Francis
Dupont's IPv6-supporting device driver for GSM modems. The accepted
view is that IPv6 should be added to the GPRS protocol architecture,
but since GPRS is not deployed and is such a mess, the suggestion
is to bypass it and architect just for GSM.

The draft covers what was proposed in more detail. Highlights:

- Place an IPv6 Router over an adaptation layer over the stack in
  the MSC.
- Design the needed adaptation layer in IETF, and go to ETSI to
  suggest changes as needed to Call Management and Mobility
  Management.
- The architecture would be one MSC/subnet.
- Some needed additions are header compression and mux/demux.
- Use IPv6 mobility for the inter-MSC mobility.
- Have DHCPv6 give the address to a phone on turn-on and add IPSEC
  to the Call Management layer.
- Have DHCPv6 and IPv6 interact on the move to a new MSC, with
  support for this in Mobility Management

The speaker concluded suggesting a poll of whether this proposal is
useful, whether to work on it in the WG, and if there would be
concurrence about the work suggested to be done in ETSI.

Comments -

Eklund, Ericsson: Much of what they would do is already part of GPRS.
For instance, it already includes the ability to choose IPv6 instead
of IPv4. The suggestions represent misunderstanding of GPRS. Eklund's
opinion is that no operator would adopt this scheme. Answer: an
operator Afifi is working with is unhappy with the prospective
performance of GPRS and its complex stack and has expressed interest
in bypassing GPRS. Eklund - the cost of building an alternative means
that all operators are going to use GPRS. I

Hakkunen, Nokia: Also thinks the authors misunderstand what is
happening in GPRS. GPRS is complex because it needs to be. The end
result of the suggested use of GSM would be as complex as GPRS
because it would have to be. Answer: GSM is deployed today. What is
the guarantee that GPRS will be deployed? Hakkunen: Cannot speak
officially, but there is very high pressure for GPRS deployment, and
thinks it will be deployed.

Tsirtis, BT: This is for a good cause, but you could spend a lot of
time trying to get ETSI to change existing standards, or work in the
early days of something that isn't hard and fast yet, and the latter
would be more effective. So IETF should even go beyond GPRS and be
longer term. Suggestion is to go to UMTS [???he may have said DMTS]
instead.

Comment: About the poor performance of GPRS, in normal GSM traffic,
the occasional free slots in the TDM timeslotting scheme are
retrofitted for GPRS. It performs so badly, because there is little
allocation for it yet. Answer: Another reason why GPRS isn't
attractive for the IPv6 over cell.

Hakkunen: Some people are proposing the GPRS stack for UMTS. If IETF
could convince UMTS people to use this solution instead, this would
be most effective.

Hinden: When I first saw the GPRS stack, I saw it as too complex too.
However, it is not certain that this WG can have this work in its
charter. Rather, it seems appropriate to ask the Internet ADs about
looking at the whole IP over cellular media topic. Hinden took an
action to bring it up to the Internet ADs.

Perkins: Timing matters. Make a working group item related to this
now would make it more real. Hinden: It's too late to affect GPRS.

Hinden: Suggests this draft remain an individual submission.

VIII. Preferred Format for Literal IPv6 Addresses in URLs - Hinden

The major goal of the format is to make cut and paste of IPv6 literal
addresses into browsers easy. The draft is browser focused - there
are URLs in a lot of places and it is hard to fix parsing software
everywhere. In the draft in its 01 version, the format is to enclose
the literal address in square brackets. There have been
implementations demonstrating feasibility in MS IE, Mozilla, and Lynx
- these are not production implementations, but their coverage is
good. Hinden would like to start WG Last Call for this to go to PS,
continuing to omit the issue of literal support for non-browser uses
of URL. But it is noted that the IPv6 service location protocol
drafters may be able to use this too.

Itojun: Is it legal to have a square bracket around a regular URL
with FQDN? His implementation accepts finding square brackets there.
Answer: We shouldn't require that it do. Draves: MSRIPv6 IE also
accepts square brackets around the FQDN as an implementation
byproduct.

Comment: Every example has an explicit :80, why? Answer: This was
just to show there would be no problem between the address use of
':' and the port use of ':'. Examples without the port will be
included too. Itojun: please show examples with 3ffe in lower case,
not only upper.

Perkins: Service location protocol for IPv6 is done and is just
waiting for this format to get settled. They will reference the
draft. Narten: SLPv6 is not quite ready, because they need to include
rules about server source address use when multihomed - these should
be reviewed by IPNGWG. In fact, SLPv6 should become an IPNGWG
document, because the SLP working group is trying to shut down.

IX. Privacy Extensions for Stateless Address Autoconfiguration -
    Narten, IBM

The constancy of the Interface ID could (in some cases) be used for
tracking individuals, for instance when the device stays with the
user, like a PDA. A server could tell when you were at home, office,
travelling, based on the changing prefixes. The proposed extension
for privacy is optional because it is not a concern for everyone. In
particular, servers already have a permanent DNS name, so that is
already an identifier for them. Also, many are used to having a
stable IPv4 address, for instance because the DHCP spec encourages
giving the same address. Finally, sites may want to be able to track
use easily, and having nodes be able to become anonymous would be
viewed as a cost to them. Solution requirements:

- Interface identifier must change over time.
- It does not need to be cryptographically random, just unpredictable
  to an outside observer. If there is stable storage, the draft
  provides an algorithm for creating a new IID, otherwise it is to be
  pseudo-randomly generated. The algorithm briefly is to append the
  IID to a 64-bit history value, compute the MD5 message digest, take
  the first 64 bits for the temporary IID, use the temporary as the
  next history value.

Issues -

How frequently to recommend changing? The initial approach is at each
restart (system reboot).

An assumption is that this is a client-only solution. A device that's
both a server and a client may want to use the constant IID for
server use and this stuff for its client communications. Then one has
to get into source address selection issues.

Should this be specified as for use in global addresses?

Collision avoidance - in autoconfiguration now, DAD halts the process
when a duplicate is discovered. But for privacy IID selection
purposes, there should be a retry mechanism.

Is it reasonable to assume that the IEEE identifier will remain
private to node? If it is known already, the generation algorithm may
be predictable. An observer on the same link will certainly know it.
(Comment by someone: this is not for privacy on the same link). The
alternative is not to use the constant IID as a seed. Avoiding using
it is easy, assuming that systems can be expected to generate a
pseudo-random number reasonably well.

Comments -

Crawford: Let people choose their own threat model and decide for
themselves how often to take a dose of this privacy drug. On the
other hand, when restart-based model is not used, some more problems
arise: on changing IID without a restart, the system has to track
addresses in use already, in open connections, and unlike
prefix-changing, it does not get external cues (router
advertisements) to start doing so.

Perkins: Wonders why it is believed that the history list is simpler
than trying to do a new random number each time. No need to
overspecify: a default method for generating the privacy IID is not
needed for interoperation. Also, with respect to the analogy to
prefix-changing, note that address lifetimes are upper bounds - the
system is free to stop using some prefix when it wants to. Answer: It
may be hard to track upper layer users of addresses with the defunct
IID, especially UDP.

Afifi: For this to work, DHCP servers would need modifications,
because clients are identified by their MAC addresses. Answer: If you
are using DHCP, you have to generate a normal link-layer address, not
use an anonymized one.

Nordmark: Is it a privacy concern that DHCP servers know the constant
IIDs of systems? Answer: DHCP is supposed to be trusted. Hinden: You
may not trust a DHCP server you are visiting.

Hinden: The draft will need revision.

Narten: Could the WG comment on whether the simple first cut in the
draft is enough. Draves: Would like to see it include reboot-less
change that can be done more frequently. Others nod.

Question: Who will get to use the IID when a duplicate is found?
Answer: The original owner. Unlike with ARP, there is no problem that
the cache could be corrupted. Question: But if it's a duplicate of a
system that is temporarily down, especially of a server that cannot
change? Answer: This case is okay, because the server should using an
IID with the global-bit. Still, partition could cause problems for
the DAD/retry. Comment: Make the random generation a good function,
likelihood of collision low.

Itojun: Definitely agrees that the frequency of change should be a
choice of user. It's fine to change at reboot time, but give warnings
about issues in reboot-less change.

Comment: There is another case for needing to use both modes of
address simultaneously. Many client-only systems will have to keep a
stable address for the backward translation of name required by some
servers (some telnetd's, smtpd's) and choose to use the private
address only for applications without this constraint. Answer: The
draft doesn't go into this case, because it is a bit of a rathole.
For instance, how will applications decide? Draves: Have stable
address be deprecated and private preferred? Answer: That doesn't
help for the client-only two-mode case. Draves: It does help for
server/client on one system case.

Comment: It may be that DHCP must give out the private addresses
because people are manually configuring addresses with the
low-numbered IIDs such as ::1. It would be bad if there are
collisions for those. They have local-bit set to true, so they are in
same space as the generated private IIDs.

Narten: Note that in the draft, the last thing that is done is to set
the bit to local. Nordmark: DHCP also sets the bit to local, so there
is the prospect of collision with DHCP-assigned addresses. Given the
amount of space, it is not such a big collision risk, but maybe
further structuring of the addresses could be considered. Answer:
could consider getting an EUI prefix for these...

X. Update to Advanced API - Erik Nordmark, Sun

From the time of the LA IETF, implementors have found it too complex,
so the update simplifies it by providing less flexibility. A goal is
to allow implementations to support both the old API (RFC2292) and
this new API. The high order bits of changes between the RFC and this
draft are summarized here:

- Biggest change was to remove IPV6_PKTOPTIONS feature that set many
  options by recursion - it was not possible to know the behavior if
  one of many being set failed - did the others take effect anyway?
  Sticky options can now be set with individual setsockopt calls.
- Added IPV6_RTHDRDSTOPTS to control DSTOPTS that show up before
  routing header, since can no longer control that with omnibus of
  IPV6_PKTOPTIONS.
- Removed the ability to be able to specify HBH and DSTOPTS with
  multiple ancillary data items. Now application is responsible for
  formatting the whole extension header, so protocol stack does not
  have to guess the alignment restrictions etc.
- Added separate IPV6_RECVxxx options to enable the receipt of the
  corresponding ancillary data items. Now the applications uses
  getsockopt to retrieve any sticky options it has set with setsockopt.
- Clarified how and when TCP returns ancillary data items - it must
  when the content changes from one segment to another, but not
  necessarily on each data receive when the content does not change.

These are not all the changes - see list in draft. Some TODO items
are still extant:

- Add mechanism to avoid fragmentation by sending at the minimum IPv6
  MTU, for instance, this would be useful for a DNS server that does
  not want to do Path MTU discovery for a single reply.
- Add MTU notification so that UDP apps can participate in PMTU
  discovery. This could be an ancillary data items received without
  any data, IPV6_PATHMTU, enabled with IPV6_RECV_PATHMTU.
- Add reachability confirmation for UDP and raw socket apps to allow
  them to talk to Neighbor Discovery to defer NUD probes. This could
  be an ancillary data item for sendmsg with zero length called
  IPV6_REACHCONF.

Due to shortage of time, the meeting was advised to look in the draft
for the list of open issues. Implementors need to inspect this draft
carefully. Is anything missing? The authors wants to do one more
crank on it and then be done.

Itojun: It is actually desirable that 2292 and 2292bis both be
supported? If so, 2292bis should have words saying it is an addition.
Answer: Do people need backward compatibility? Please speak up. The
actual preference is that 2292bis should obsolete 2292, but it
depends on the state of implementations.

XI. Site Prefixes in Neighbor Discovery - Erik Nordmark, Sun

Brief summary of the spec -

Store site-local address in the DNS

- RRset contains just site-locals if not connected, site-locals and
  globals if connected.

Routers advertise the global prefixes for the site, typically as a
/48 in the RA prefix options

The resolver/getipnodebyname() filters the RRset

- Test: one or more global addresses falls in site prefix
- Exclude site-locals if not true

The draft is 03. Changes since previous draft include: format change
in option to make better fit with Router Renumbering; change the
rules about suppressing global addresses returned from DNS to
supporess only those that match the global prefixes received from the
RAs; refine the text to handle case when DNS has only site-local
addresses in it (in a non-connected site). Defined multi-sited nodes
(with a single domain name) and tried to flesh out options in this
case; specified that multi-sited nodes can use the site-local
listings of only one site - a multihomed node must have a different
domain name for each site if it wants to use site-local addresses in
all its sites. For more additions and details, see the draft. There
was a shortage of time for the presentation.

The text was changed to reference AAAA/A6 instead of AAAA. But should
it refer just to A6?

Open issue - should the protocol advertise a human-readable name for
each site? Deering has suggested this for multicast scopes in the
past, as something useful for application user interfaces. (For
instance, a user could be asked whether she wanted campus or office).
It would be possible to add an ND option for the human-readable site
name.

Next steps: Get the basic rule (that all implementations, including
those that do not implement ND site-local extensions, ignore
site-locals received in the DNS RRset) into the implementations. The
presentation ran out of time as the meeting time ended, so the
request was made that discussion start on the mailing list about what
the progress should be for this draft.

July 15

Hinden announced (following from an announcement by Mike Roberts,
temporary president of ICANN, at the IETF plenary the night before)
that IANA has officially made the first delegation of IPv6 sub-TLAs
to the Regional Internet Registries - we're not done, but this is
another important step.

The second session of IPNGWG was dedicated to multihoming. There was
one item left over from the first session agenda, to be covered very
quickly:

XII. IPv6 Inverse Neighbor Discovery - Thomas Narten, IBM

This is a document by Alex Conta that started in the ION WG. The IESG
thought it needed more work after ION sent it to them following their
WG last call. It was specified as a Frame Relay-related standard ,
but Narten pointed out that the Inverse ND is more general than its
FR application, so Alex moved the FR-specific stuff into an Appendix,
leaving the generic ND material in the main text The WG is requested
to comments on it to Alex as soon as possible and an IPNGWG Last Call
is requested to take place a few weeks following Oslo.

Multihoming Agenda

XIII. Overview of IP(v6) Multihoming Issues- Deering, presented by
      Rich Draves, Microsoft Research

The agenda and starting points for this WG discussion were developed
by a small design team put together by the WG chairs, which met or
teleconferenced several times in June. It was emphasized that the
design team results have no special status, but just were to serve as
starting point for WG discussion

Multihoming issues arise:

Node
Site

There are pretty close analogies between the node and site cases.

Note multihoming is dynamic - hosts, sites can acquire or lose
addresses - can be multihomed for an interval.

Multihoming issues are not new with IPv6, but the host ones are more
prevalent or maybe more of an issue with IPv6 because of its support
for multiple addresses per interface, for multiple scopes, for
renumbering, and for transition scenarios introducing new interfaces,
such as 6to4. Sites are equally likely to be multihomed in IPv4 or
v6, but IPv6 may introduce the situation that sites are to get/use a
different prefix with each ISP, rather than punching holes.

Issues of -

- Multiple Addresses for a Node: choice of source address, apps that
  use addresses as peer identifiers.
- Multiple Interfaces for a Node: same issues, plus others such as
  that redirect only works if the sender uses the addresses of the
  outgoing and not those of other interfaces. Load-sharing across
  interfaces becomes possible, may or may not be desired.
- Multiple Prefixes for a Site: policy-based preferences for using
  one prefix or not.
- Multiple Attachment Points for a Site: will need to use right
  attachment - some of this is the domain of routing protocols, but
  not entirely. Load-sharing may be desired. How to receive packets
  for prefix of one attachment when it is down, but another is up.
  If ISP is doing ingress filtering, definitely need to choose prefix
  for source address that matches attachment being used.

This is an incomplete list of the many issues. Not all of these need
to be resolved by the WG now, as we have lived with them in IPv4 for
a long time. Figure out the key ones.

Generalized Host Multihoming -

Hosts may have multiple local addresses (LA) and local interfaces
(LI), and hosts may peer with multiple remote addresses (RA).

For each triple <LA, LI, RA> chooses a particular path. There's a
range of possible capabilities:

- At session initiation time, for instance, TCP connect, choose the
  triple most likely to work (e.g. longest prefix match)
- Try multiple triples/paths till one works
- Iterate them over multiple sessions
- Try them all and measure somehow which one is best
- Keep history/experience
- For an ongoing session, detect failure of current path and move
- For an ongoing session, detect availability of a better path
  and move
- Spread session traffic across multiple paths

Later presentations will go into detail of proposed solutions chosen
from above space.

Different Models for Multiple Interface

These were discussed as outgoing, but each has a version for incoming too:

- Strong: the source address MUST belong to the originating interface
- Semi-strong: the source address SHOULD belong to the originating
  interface
- Weak: the source address MAY belong to any interface of the originating
  host

Another take on these models is to consider whether the stack can
choose the interface to use freely or not, when the application has
picked the interface it wants to use.

Advantages of Different Models

The weak model has is simpler to implement because you go into the
routing table and just get whatever match to the destination address
is found. The strong model requires constraining what you can take
from routing table. In IPv6, implementations already have this
problem/ feature of routing-table lookup to some extent because of
the presence of scoped addresses, so the semi-strong model looks
promising intrinsically.

Additional Near-Term Point

- Consider using RFC 2260 - see Itojun's presentation to follow this.

IPv6 Features for (Future) Use in Resolving Multihoming Issues

- Globally-unique Node ID - e.g. when the interface ID is
  autoconfigured using an Ethernet MAC address, with bit indicating
  it is globally unique. The bit was added to the IID field to give
  potential for future transports to use the IID alone for transport
  control block lookup.

- Router Renumbering - border routers can feed prefixes to the
  routers within the site, and it could be used to control what
  prefixes are used.

- Use of Site-Local Addresses - to give intra-site communications
  immunity from external multihoming effects.

- Exchange-based Addressing - assign a single TLA to a set of
  interconnected ISPs, and do flat routing among customers of exchange.
  Pros: multihomed sites can have a single prefix across their multiple
  attachments; also, sites avoid renumbering when they change ISPs. The
  standard IPv6 address architecture has the capability of doing this.

Conclusions

Do a few simple things now. Keep the WG focus on:

- Heuristics for source and destination address selection
- Some aspects of trying multiple paths
- RFC 2260

And provide a host architecture that can evolve to support better
multihoming support in the future.

Multihoming will continue to be a rich source of problems. This
presentation and the next two presentations are meant to be one
group's contribution to the WG discussion.

Comments -

Perkins: Multihoming issues have come up in mobility. IPv6 must
decide whether use careof or home address. Some Stanford University
work developed the concept of a mobility address policy table,
which seems as if it would be generalizable. How the table was
populated was for future study. A pointer was sent to the mailing
list.

Hinden: From some points of view, mobility is another class of
solutions for multihoming. Perkins: People should consider Erik
Nordmark's presentation to mobility WG with implicit tunnels.

Narten: But note the main focus of the ideas from our design team is
not what happens when connection is already up and something happens,
but rather what happens at the outset of connections.

XIV. Multihoming: RFC2260 Approach - Jun-ichiro Hagino (Itojun),
     Research Laboratory, Internet Initiative Japan

Focus is on multihoming support that is possible now. This talk
covers the router stuff: Goal is to try to deliver packets of any
(source, destination) during failure of one or more of the site exit
links

IPv4 uses portable addresses so that prefixes of one provider can
be advertised out of another provider's attachment point. In IPv6,
the portable address concept is not there, and advertisements should
be more restricted.

The next talk by Rich Draves will be about end2end stuff: Goal is to
try to find the best (source, destination) on connection
establishment, and perhaps in more advanced phases, to switch to a
better (source, destination) during the course of a connection.

RFC2260

One of the approaches in RFC2260 guarantees no extra routing
announcement to outside and is friendly with IPv6 aggregation policy.
Sites get ISP-provided addresses from multiple ISPs and are assumed
to route them locally. For IPv4, the assumption is that a site has a
region for each ISP's addresses, and routing exchange within the site
for communication without going outside. IPv6 is different in making
it easy for every end host to get addresses from each of the ISPs if
that is desired.

Let there be a site with a blue ISP and a red ISP, with the red site
border router advertising the red prefix into the red ISP and the
blue site border router advertising blue prefix into the blue ISP.
and the internal routing stated above. Next: establish an IP in IP
tunnel from the blue site border router to the red ISP border router
and vice versa. In the stable state: announce the blue prefix from
the red-to-blue tunnel endpoint in the blue ISP router. When the
blue-blue link fails, so that the stronger route advertising the blue
prefix into the blue ISP has failed, only then will the tunnel backup
route be used and the blue prefix traffic will tunnel to and from the
red site border router. There will be no advertisement of the blue
prefix by the red ISP, so aggregation is not broken.

IPv6 Extensions of RFC 2260 -

- Address assignment: the two (or more) ISP prefixes could be
  assigned in separate regions of the site, as in IPv4, or throughout
  the site, or a combination of some mixed regions and other distinct
  regions.
- Packets can survives ISP filters - use RFC2260 in reverse direction
  and site router tunnels the packet  (source routing might be needed?).

Scalability in a Very Large Site -

Do not try to make a full-mesh configuration of tunnels, because it's
too much mess. In an example where it's easy to see the suitable
partial mesh: the two ISPs of the site portion located in Japan back
each other up, the two ISPs of the site portion located in the US
back each other up, but there is no backup between the countries.

Conclusions -

RFC 2260 is a good base for IPv6 multihoming - it is
aggregation-friendly and does not encourage use of portable addresses.

It is an operational solution - no change to protocol code.

Will ISPs be able to do 2260? Some BGP gurus in Japan have said they
find it feasible.

Scalability - guideline document needed.

Note - Dupont draft talking about RFC 2260 should be reviewed.

Comments -

Dupont: About 2260 in general, it is complex to set it up, and it is
hard to find the expertise for running it. Many ISP policies are
prohibitive of it. Finally, it does not help at all if the provider
border router goes down, only if the link goes down. So 2260 is more
than nothing, but not very capable.

Itojun will try in his home. Mankin: we should set up some trials on
the 6bone.

Hinden: This is one tool for multihoming, but not a complete handling
of the issues. Note that link failures are more common that router
failures. Dupont: in the context where the exit router on the site is
the ISP border router (belongs to the ISP), then a link failure
amounts to an ISP router failure and is not cured by 2260.

Nordmark: What about the potential for distributing the injected
route with IBGP as in 2260?

Comment: One could have a concern with AS number space consumption
being increased by multihoming and 2260 does not help with that.

Itojun: It would be possible to do something with another routing
protocol than BGP.

Tsirtis: It sounds good to combine 2260 with router renumbering as
the earlier presentation said, so that when the link fails (or the
router fails), nodes are told to change prefix.

Itojun: Still RFC 2260 is a good starting point

XV. Design Team's Proposal for IPv6 Multihoming - Rich Draves,
    Microsoft Research

Goals -
Support multihomed sites
- Remove temptation to break the provider addressing plan and
  aggregation - more scalable routing is something IPv6 has to
  come through with.
- Site availability is a key requirement.
- Maintaining existing connections is a bonus, but not crucial - making
  sure new connections can be established goes very far. Business-
  critical apps are designed to be able to restart after a broken
  connection and otherwise recover if TCP breaks.
- Helping multihomed hosts deal is also a bonus, but is not as critical
  an issue as making multihomed sites work properly.

Changes should be kept minimal changes - not rock boat
- No protocol changes
- No TCP/UDP implementation changes
- No API changes
- No application changes.

Ideally nobody would have to do anything and we'll fix these issues :)
Finally an evolvable solution is needed.

Grand Outline

Phase 1 - required work for WG
- RFC2260 approach
- Source address selection
- Destination address ordering
Phase 1.5 - is this required?
- TCP tries multiple source addresses
Phase 2 - future work?
- Additional APIs, e.g. connect to a DNS name
- Centralize destination/source address selection (DNS...)
Phase 3 - definitely in future
- Adjusting paths after probing

Phase 1 - Required Work on Source Address Selection
Using longest-matching prefix.
Getipnodebyname - ordering of destination addresses returned by DNS
leads to source address selection in IPv6 stack.
Pluses, Minuses, Questions:
+Minimal changes
+Scope/prefix matching - local, site, both of you have addresses from
  ISP A.
? Incorporate TCP feedback - to influence future decisions.
- Does not try all pairs - for each destination, will only choose one
  column
- Apps are responsible for any probing of the multiple destination
  addresses - some already do, but most don't
- Another drawback is the need for feedback from the application to
  know when communication is successful, so a UDP without feedback
  can't tell you an address is ok
? Big timeouts during trying list
? Because of having decentralized the source/address selection, it is
  harder for administrators to insert their own controls

Why Not Just Use RFC2260?
- It doesn't help you find common scope/prefix
 - It doesn't help multihomed hosts, whereas the above architecture
  does help some
- It doesn't deal with ISP/router failures, just ISP/link failure
- Using a tunnel is inefficient
- ISPs are willing? As far the design team could find out (admittedly
  not having searched exhaustively), none have implemented or tried
  using RFC2260. It is an extra burden. And why should an ISP help you
  to use another ISP?

Why Not Use Address Selection/Ordering Only and Not RFC2260? Consider:
Site 1 connected to ISP A and ISP B, Site 2 only connected to ISP A
Site 1 has node with address 1a, 1b, Site 2 has node with address 2a
Site 1 will want to use 1a to talk to Site 2. If the link between
Site 1 and ISP A fails, then when it uses ISP B to initiate a TCP
connection to Site 2, it fails.

Question -
Zill: Why not use routing headers? Answer: The team thought about
doing so and it has possibilities. The use of router renumbering
cited by Dupont and others also has possibilities.

Phase 1.5 - is it required?
TCP tries multiple source addresses - it would be necessary to work
out the details.
It would be an implementation change, not a change  to the protocol.
RFC2260 would not be needed for basic availability.
All destination/source address pairs would get tried, but there would
be a tendency for them to be tried in the wrong order because connect
would choose one at a time of one's own interface prefixes at a time
- trying <1a-2a> <1a-2b> instead of <1a-2a> <1b-2b>.
Comments -
Dupont: You could fix this with a new ICMP message to say change
source address. Answer: This would require more work from the router,
having to look at the source addresses being used - team talked about
it, but...
Crawford: It wouldn't work for this case anyway.

Phase 2 - Future Work?
Stack maintains host cache database
DNS-based API
- TCP: connect (DNS-name)
- UDP: connect (DNS-name) - this would return to the applications a
  sorted list of destination/source pairs
- UDP/etc: Would need an API addition to do update-database. This is
  because the stack can't tell if communications are working (even
  the app may not know). This is why the UDP:connect gives the
  application back a list of address pairs.

Phase 3 - Definitely Future Work
- Builds on the host cache database
- Modify TCP for survivability, renumbering - security?
- NUD-like probing for best destination/source pair - would have to
  control the overhead and load on this? An application could be
  willing to pay  with some extra packets for large gain of a better
  path.

Phase 1 Detailing: Source Address Selection
Draft - 01
- Only applies when application has not specified source address
- Define candidate set of source addresses, define pair-wise source
  address comparison
- Always attempts communication using some source address - an
  alternative philosophy would be to fail in some cases, e.g. your
  peer has a global address but you have no global source address
  available. Philosophy in draft is to try anyway, because it
  might work and if so, it's better than nothing. Cases when you don't
  have appropriate scope address are probably due to misconfiguration.
  To fix the problem, administrator may need to be able use the
  communication.

Nordmark: You can make the case especially in multicast, because
peers may actually be on your link, and you have no way to know.
Answer: This can be true in unicast too, for instance, you may have
only a global for someone on your link. Nordmark: unlike in the
multicast case, that can only be due to misconfiguration.

Candidate Source Address Set
- Do routing lookup, take all addresses of interface - RECOMMEND just
  using addresses assigned to outgoing interface, but permit use of
  addresses assigned to other interfaces (depending on the kind of
  peer - when talking to a routing peer, you MUST use an address
  belonging to the interface).
- Question to WG - Under what circumstances (if any) should we allow
  use of addresses not assigned to the sending interface? Maybe if all
  prefixes on the sending interface are deprecated?

Source Address Comparison
- Series of tie-breakers: scope, preferred/deprecated,
  longest-matching-prefix
- Scenario A. Global destination address - pick from 1. link-local
  source address or 2. deprecated global source address...
- Scenario B. Site-local destination address - pick from 1. deprecated
  site-local source address or 2. preferred global source address.
- Answers in draft now A.2, B.2
- Deering and Hinden school of thought is never to use a deprecated
  source address if you have any alternative. A answer would be 1.
  Hinden: Rationale is that site-local meant you were not supposed to
  communicate outside your site or else there was an error so that you
  didn't get your new global prefix. If you start the connection with
  the deprecated address, the site administrators won't find out about
  the mistake quickly. Draves: That's one school of thought. The
  alternative view is that the administrator who made the mistake may
  need ability to use the deprecated to be able to fix the screw-up.
  Hinden: let those administrators use a telnet that allows you to pick
  your choice of source address including breaking these rules. Elz:
  Don't forget these rules are only deals for when the application
  doesn't choose its own source address. You need some apps to be able
  to do this.

Destination Address Ordering

No draft yet

- Try address with smallest scope first.
- Try addresses that have longest possible match with a potential
  source address, if there is a choice within scope.
- Don't unnecessarily perturb the DNS order. If you imagine this as
  a sort, you want it to be like a stable sort, so if you have a tie,
  you don't change the order.
- Avoid extra system calls in the common case, cache in system library,
  so as not to have multiple calls down into stack for all those
  addresses.

Discussion of scopes and destination address choice
Elz: going to write a draft where DNS only returns highest scope and
nodes when they connect algorithmically create smaller scope to use.
If packet gets through and you have a site-local response back, then
change to site-local. You can do this independent of what application
requests. Draves: Some dangers, including that it would add latency.
Elz: Would only add small amount if site is not too big a thing.
Nordmark: Version 00 of the site-local draft had something like this,
but it provides less administrative control, for instance you don't have
option of leaving out the site-local address entries from the DNS for
nodes you know are frequently mobile. You might want to have that
admin control. Elz: Mobile IPv6 has arranged for site-local addresses
to work. Anyway, will write up his draft.

The Grand Outline discussion was consensus of the design team - Phase
1 solves the most pressing problems.

Discussion -

Dupont: TCP survivability/renumbering is entirely solved by mobility
mechanisms.
Narten: Have to disagree, because with mobility, you know when you've
moved, but when a link goes down, or something other than router
advertisements cause a new prefix to be needed, it is not as clearcut
for the sender to know. The change is harder.
Dupont: Have implemented it. It works.
Carpenter: Change term renumbering to something like prefix migration
- your home address is what's going to disappear at the end of the
prefix migration.
Nordmark: If we'd have done Phase 2 two years ago, it would have been
phased in with the new API, but there are perhaps enough people porting
applications now, that the Phase 2 API could not be included in some
implementations. miss some.
Hinden: This isn't an advanced API, it's more basic than basic.
Itojun: There are already many applications using the basic API, so
please don't drop it.
Cheshire - MacOS connects using DNS names and it works fine - AF-DNS
family name
Carpenter: It would be nice because it's a fairly concrete interpretation
of having APIs with a level of abstraction from network layer. Good news
because architecture justified, bad news if it carried along some delay.
Hinden: It might be good that we don't standardize APIs.

Status -
The source address selection draft is out there for working group review.

Hinden then tried to turn the entire discussion into some next
steps/actions.

No voices said not to do Phase 1 - so the next step is either to add
to the source selection document to include destination ordering as
well, or make a new document for it.

Action - Continue source/destination selection draft(s).

Heard fairly strongly that there is value in doing Phase 2 - the
DNS-based API part. We could do something very simple and use it to
get experience. Not everyone has done their IPv6 implementation and
shipped it as a product yet....Also we would hope IPv6 encourages some
new applications, so even if the ports are done, there are new users
of APIs to come.

Action - Start Simple IPv6 API

Crawford: An addition to this would be to use SRV records to find out
the ports too. Some negative responses to this from the room.

Action on 2260 - Next step is to have serious conversations with ISPs
and routing experts - maybe there are serious reasons on their part
not using it. To the design team's not very broad knowledge, it has
not been implemented.

Elz: Note the two ways to talk to ISP: saying something would be
technically nice to do versus saying there are tens of millions in it
for them if they do it. Provided a few well-heeled subscribers demand
RFC 2260, it will be thereafter be provided everyone.

Nordmark: ISPs often don't like tunnels because of issues with
transit or non-transit. They are known not to like 6bone tunnels.

Action - Investigate RFC2260
- Get more ISP opinions
- Consult routing experts
- Conduct 6bone tests

Carpenter: Randy Bush said RFC 2260 has not been used in IPv4 because
it is too complex. This could be a chicken-and-egg problem.

Hinden: Things do change, this is the Internet after all

Shand: Did a draft on this sort of topic 3-4 years ago. He will look
and see if it has any interesting ideas to revive.

Dupont: A lengthy draft on this stuff was just revived by NGTRANS. It
should be moved to IPNGWG.

XVI. Interim Meeting

It would be useful to have an interim meeting focused on multihoming.
When - last week in September is one thought of chairs. A question is
whether it would be good to have it adjacent to an IPv6 Forum
meeting??
Carpenter: Consider whether or not to broaden scope to prefix
migration (renumbering) in general - got clear message from
ISPs in context of last week's workshop.
Hinden: good idea. Others concur.
Carpenter: Prefix migration was Mike O'Dell's phrase, by the way.
Fink: Adjacency to IPv6 Forum meeting does not have strong value
to our community.
Blanchet: First one is just between NANOG and Internet2 members'
meeting anyway.
Nordmark: How many went to IPv6 Forum meetings this week?
Hinden: They were for limited invitees, and not advertised.
Hinden: Please send a message to chairs if you can host the interim
meeting and when you can host it.
Fink: Suggest not broaden scope too much, e.g. to include an NGTRANS
meeting, because this would dilute the ability to get things done.
Looking at some of the transition mechanisms, it may prove a good idea
to have interim specific narrow micro-working groups for making
NGTRANS progress.

[end of minutes]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------

---

From: Jim Bound <[email-masked]>
Date: Wed, 28 Jul 1999 23:56:26 -0400

One comment:
I got a real problem with phase 2 discussions for DNS API but will await
a draft.  The idea was part of a recent ngtrans discussion too.

p.s. Please no one send me private mail on this I will say upfront any
mail on this subject to me will be forwarded to the IPng list.  If you
put PRIVATE in the subject I will just not discuss it with you.  This
must be discussed openly and on the mail list.

thanks
/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 29 Jul 1999 00:23:28 -0400

[Steve/Allison - Excellent minutes thanks........]

Sorry one other clarification comment I woud have made in response to 

>available, as will test results such as the ipv6-unified.

At UNH and at Connectathon the testing to support vendors testing
and interoperability as the code is being developed and the specs.
For example once we agree on src address selection or APIs we can go
build the code and go to a UNH or Connectathon type environment and test
online without fear of being bashed for parts that are incomplete or
interoperability issues in the media or other interests.  The fact 
that vendor X's tests are not open to the public or other vendors (of 
course when your testing together in a room you work together and we 
learn about each others stuff and why we sign Non-Disclosure agreements) 
is not just a policy but a Feature Benefit of using UNH and other such 
forums.

Now if someone is talking about giving vendors an "IPv6 Certificate of
Compliance" thats another issue and has many business and legal issues
for vendors and for goverments.

I am not saying TAHI is not good or important but just clarifying why we
want the UNH tests to be closed.  Its also important to differentiate
vendor product software from non-vendor software for testing.

thanks
/jim

---

From: [email-masked]
Date: Thu, 29 Jul 1999 13:52:39 +0900

>is not just a policy but a Feature Benefit of using UNH and other such 

	Let me clarify.

	TAHI guys provide test tools as free software.  So you can test
	your code in-house, without travelling to Japan nor UNH.
	In this case you will have nothing to disclose to others.  You just
	need to install a test node that runs TAHI tools (which is slightly-
	patched KAME/FreeBSD2.2.8 on PC clones).

	Separately, TAHI guys are able to test your product with you
	face-to-face (of course only when schedule allows).
	They can keep the result hidden, or they can put result onto
	TAHI webpage.  Pls talk with TAHI guys, I think they are flexible
	enough on this issue.
 
>vendor product software from non-vendor software for testing.

	Understood.
	One thing that is not visible from me is, are UNH guys active
	on IPv6 testing these days?  I see few announcements for test events
	lately (last one was Connectathon if I remember correctly).
	Or they mainly test vendor code on request from vendors?

itojun

---

From: Jim Bound <[email-masked]>
Date: Thu, 29 Jul 1999 01:16:12 -0400

OK Itojun...I get it.........thanks

UNH is still active and running test suites on site if you leave a test
system there too and they send you the reports.

I think there is one planned just before Nov Wash DC IETF meeting.

Also I think the next round of specs need testing too after our core
ones especially some transition ones if possible.

p.s. Bill L. at UNH want to say more ?????  Or UNH folks ???

/jim

---

From: OKABE Nobuo <[email-masked]>
Date: Thu, 29 Jul 1999 23:11:37 +0900

Sorry for not responding so quickly.

From: Jim Bound <[email-masked]>
Subject: TESTING IPv6 Re: draft minutes from IPng WG meetings in Oslo 
Date: Thu, 29 Jul 1999 00:23:28 -0400
Message-ID: <[email-masked]>

> vendor product software from non-vendor software for testing.

I understand what you said because we have beeing discussed
about thoes. Let me explain tahi project briefly.

1. We provide test tools freely. you can run tests yourself.
   Even if you don't run the tests, you can exsamin test specifications.

2. We are also planning to give test events near future.

3. Usually, we keep the test result confidential.
   We can open the resut if you want to do so.
   We have opened the test result of KAME exceptionally,
   but have not opened test result of other implemetions.

I don't mean that tahi project compete against UNH ,Connectathon
or something like that. Or I hope that the project cooperates
with UNH and conectathon for IPv6 deployment.

Thanks.

----------
Okabe

---

From: "William H. Lenharth" <[email-masked]>
Date: Thu, 29 Jul 1999 08:13:56 -0400

The testing that we do at UNH is based on IETF specs., and is driven by
vendor based demand.  Our
interest is in promoting and encouraging the rapid development of the
technology, such as IIPv6.  For that reason our testing is closed to
marketting or press personnel.  One of our biggest advantages
is not our vast test suite that we have been developing since 1994, but our
ability to provide knowledgeable engineers to test products WITHOUT vendor
participation or attendence, this I
thing would be particularily important for those companies located outside
the USA.   Also, since
member companies leave and update thier equipment , we have a large testing
network in operation
in our lab, running current implementations.  We will be hosting the next
test period for IPv6 the week before the Nov 1999 IETF meetings in
Washington, DC..Feel free to check our web site (www.iol.unh.edu) or
contact me at [email-masked] for information.