Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt (fwd)

[Erik Nordmark <Erik.Nordmark@sun.com>]

> I've worked with everyone involved here long enough to respect you 
> and consider you to be reasonable people, so I feel like I may be 
> missing something here...  So, what am I missing?

Margaret,

The main thing I'm struggling with is that you seem to assert
that RFC 3848 solves some transition related problem better than the 
single v4/v6 toggle in mech-v2.

Clearly RFC 3848 has good default rules for various IPv6 addresses
(scope, 6to4) and also fits IPv4 address into the same framework
which is needed. Thus I'm not arguing that it isn't necessary; I'm
arguing that it doesn't solve the hard transition problem related
to transition any better than the single v4/v6 preference toggle.
All it does it to provide a manual configuration mechanism to try
different orderings including different prefix lengths, but that
as the only approach to the hard problem would be insane; we would need
mechanisms to automatically configure this (e.g., DHCP options)
plus some way to make this understandable in the operational world;
far too complex in my opinion.

The transition problem is hard because what we really want is some way to
determine *path* characteristics (such as connectivity, reliability, delay,
throughput) yet RFC 3484 is constrained to only look at the IP addresses.
We know very well that the path characteristics can't be encoded in the pair
of IP addresses, yet given the constraint of the address selection problem
this is all RFC 3484 has to work with.


So what RFC 3484 seems to allow in practice beyond the single v4/v6 toggle
with respect to transition is manual configuration of each node where
the relative order of prefixes which do carry some path characteristics
(such as the 6to4 prefix) can be different; for example one can have the
order
 - native v6
 - IPv4
 - 6to4

Also it is possible to manually configure a node to have longer prefixes
than ::ffff:0:0/96 to deal with private IPv4 addresses such as
::ffff:10.0.0.0/104

But this doesn't in any way solve the problem of determining the path 
characteristics that result from using a particular address pair and
using that to select the address pair which will work best.

In summary I think we must encourage implementation of RFC 3484, because
it is the best we currently have, but we shouldn't view it as a pannacea that 
solves transition related issues of when to use IPv4 vs. IPv6.

   Erik