Subject: presentation notes

From: Richard Draves <[email-masked]>
Date: Thu, 11 Nov 1999 12:23:10 -0800

I was able to listen in on Steve's presentation (thanks Steve!) of my
slides. My mbone connection started working literally a couple seconds
before Steve started the presentation. There were some audio dropouts so I
didn't catch everything. I tried speaking up, but nobody at the meeting
heard anything.

In the discussion of the default policy table...

There were some comments about adding an entry for translatable addresses,
lower precedence than 6to4 and v4-compatible address. That sounds fine to
me.

As to why I gave 6to4 and v4-compatible addresses the same precedence - I
expect 6to4 addresses to see much greater use in practice. But if two hosts
both have both 6to4 and v4-compatible addresses, is there some good default
reason for them to use the 6to4 addresses instead of the v4-compatible
addresses? It seemed more like a site policy/preference if that is desired.

There were some questions about how the examples work, I'll send separate
mail about them.

For controversial issue 1 - the consensus seemed to be Yes & Yes. So we can
have a standards-track document on default destination address ordering &
source address selection, and the document can use MUST while still giving
applications & upper-layers the leeway to override default choices.

For controversial issue 2 - Did I hear Steve say he'd given up on this one?
So there is consensus to use a deprecated source address to avoid using a
source address of insufficient scope? About why I listed policy as a reason
to use a deprecated address - here's an example:

Suppose there are two destination addresses, 6to4 and native, and two
candidate source addresses, 6to4 (preferred) and native (deprecated). The
destination addresses will be ordered 6to4 before native, and for the 6to4
destination the 6to4 source will be chosen. However suppose an application
sends to the native destination address anyway. Then I think it's better to
use the deprecated native source address instead of the preferred 6to4
source address.

For controversial issue 3 (weak vs semi-strong vs strong) - Not enough time
for discussion, no consensus yet.

Thanks,
Rich
--------------------------------------------------------------------
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: Alain Durand <[email-masked]>
Date: Thu, 11 Nov 1999 22:13:09 +0100

>addresses? It seemed more like a site policy/preference if that is desired.

My concern is about phasing out the transition mechanisms
.
Going from 6to4 to native IPv6 seems to me much easier
than going from IPv4 compatible to native IPv6.
The reason being that, when a site use the 6to4 mechanism,
everything within the site is already native. Meaning IPv6
site infrastructure, routers, ...
With IPv4 compatible, communication is directly from
a dual stack host to another dual stack host, no IPv6 infrastructure
whatsoever is used.

Given that, if a site use IPv4 compatible and 6to4 at the same time
it will be much easier when it will move to native IPv6 if already
the communication were using 6to4 than IPv4 compatible addresses.

For this reason, I think we should differentiate 6to4 and IPv4 compatible
and give priority to 6to4.

In the same line, having "default" somewhere in the middle may
have some strange impact if people start using by mistake
not yet defined addresses (outside of 2000::/3)

         - Alain.