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

From: Pekka Savola <[email-masked]>
Date: Thu, 15 Jul 2004 10:57:36 +0300 (EEST)

Hello all,

(co-chair hat on)

I'd like to move forward with this by submitting a revised I-D before 
the revision cutoff on Monday.

There was just one comment to this thread, and some off-list
discussion between Margaret and the authors/editors.

I see three kinds of potential resolutions:

 1) Just remove a bit of text and refer normatively to RFC3484.
    This makes it impossible to go for Draft Standard soon.

    If this is done, IPv6 WG must be rechartered to add revising
    RFC3484 to Draft Standard in its deliverables.

 2) Keep the text basically as is.  The draft can't go forward unless 
    Margaret changes her opinion though.

 3) Remove a bit of text, refer informatively to RFC3484, and 
    basically say "DNS result ordering is out of scope of this 
    specification".  (This is a new compromise proposal.) That way, we 
    don't propose the "simple" ordering rules, but don't require 
    implementation of RFC3484 (in this spec) either.

Thoughts?

(co-chair hat off)

If my own opinion is worth anything.. 1) would be inappropriate
because RFC3484 revision isn't even on the IPv6 WG radar yet, and even
if it was, it would probably take a year at least; 3) might be a
reasonable compromise; obviously, I'd prefer 2).. :)

---------- Forwarded message ----------
Date: Mon, 14 Jun 2004 08:53:13 -0400
From: Margaret Wasserman <[email-masked]>
To: [email-masked]
Subject: Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt

Hi All,

A few weeks ago, Pekka Savola sent a summary of IESG
comments to the list that included:

>  1) section 2.2 on DNS result ordering/filtering seems to
>  be considered inappropriately short, and it would be better
>  to just refer to the default address selection RFC3484.
>  (Margaret Wasserman). Filtering is inappropriate (Ted Hardie
>  and Scott Hollenbeck).

The length of the section doesn't bother me.  In fact,
following my suggestion would make it shorter :-).

My objection to this section is that it contains a
simple set of address selection rules, including a
simple preference for IPv4 or IPv6, that has several
well-understood problems.  Those problems were
identified and addressed in RFC 3484.  So, I believe
that we should remove the address selection rules
specified in this section and replace them with a
normative reference to RFC 3484.

>  ==> possibilities include at least:
>  a) keeping the current tense of specifying a "simple" address
>     selection, and referring to RFC3484 for more details, but reword
>     the text appropriately.  Remove filtering but keep ordering. It
>     might require some convincing to make the IESG accept this
>     approach.  (In other words, a simple dual-stack implementation
>     would not necessarily have to implement RFC3484 to be
>     compliant/interoperable with this spec.)

There are several reasons why I do not believe
that this is a good choice.  We know that the simple
address selection (flag to prefer IPv4 or IPv6) does
not work properly. For instance, it causes situations
where global communication will be initiated using a
local source address, even when a global source address
is available.  It also causes situations where hosts
will prefer tunnelled communication over non-tunnelled
communication.

These problems were identified and fixed in RFC 3484,
which is a mandatory part of IPv6.

>  b) remove most of the text, referring to RFC3484.  Note that RFC3484
>  is PS, and we could not advance to DS if we did that.  (In other
>  words, all the dual-stack implementations compliant with this spec
>  would also have to implement RFC3484.)

This is my suggestion.

IMO, the concern that adding a normative reference
to RFC 3484 will prevent promotion to draft standard
is misplaced.  Before moving to DS, a draft must have
two interoperable implementations and "successful
operational experience".  The whole purpose of the
multi-tiered standards process is to identify problems
(such as the address selection problems in this draft)
and correct them before documents move to higher
levels of the standards track.

Margaret

---

From: Alain Durand <[email-masked]>
Date: Thu, 15 Jul 2004 18:23:26 -0700

There is a perception (at least from Margaret) that RFC3484 solves the 
IPv4/IPv6 selection
problem. I do not share that point of view. The issue is much more 
complex,
as hinted in draft-ietf-v6ops-v6onbydefault.
Today, in the current state of IPv6 deployment, a single switch on/off 
would not really be any worse
than implementing RFC3484; however, this is not something you want to 
say in a DS document.

My opinion is that we should delete section 2.2 DNS all together, as 
out of scope.

	- Alain.

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 17 Jul 2004 09:59:51 -0400

Hi Alain,

At 6:23 PM -0700 7/15/04, Alain Durand wrote:
>There is a perception (at least from Margaret) that RFC3484 solves 
>the IPv4/IPv6 selection
>problem. I do not share that point of view. The issue is much more complex,

It is likely that RFC 3484 doesn't resolve every address selection 
issue.  Also, RFC 3484 is complex, and I think that we would all be 
happier with a simpler solution to the address selection problem, but 
we haven't been able to find a simpler solution that actually works. 
Also RFC 3484 solves some serious issues that were identified with 
the single switch mechanism currently described in 
draft-ietf-v6ops-mech-v2.  Also, further progress in this area should 
be made in updates to RFC 3484.

If the v6ops WG believes that there are operational problems with RFC 
3484, we should clearly document them for consideration by the IPv6 
WG.  Or, better yet, we could just go to the IPv6 WG and propose 
solutions.

>Today, in the current state of IPv6 deployment, a single switch 
>on/off would not really be any worse
>than implementing RFC3484; however, this is not something you want 
>to say in a DS document.
>

I am concerned about this option, because it seems to duck the 
problem...  Do you really think it would be okay to publish a 
specification for dual-stack nodes that is silent on the subject of 
address selection?  Without even including a reference to a separate 
specification that covers this topic?

IMO, RFC 3484 is better in many ways (and no worse in others) than 
the single on/off switch described in draft-ietf-v6ops-mech-v2.  So, 
we should be encouraging people to implement RFC 3484, not the single 
switch mechanism.

I believe rather strongly that it would be a mistake to re-publish 
the single switch address selection mechanism and advance it to DS 
when we know that a more complex mechanism is required.  I fear that 
this would cause confusion in the industry about what level of 
address selection support is required for a full IPv6 implementation.

The arguments for publishing this document without a normative 
reference to RFC 3484 seem to be motivated by the goal of publishing 
draft-ietf-v6ops-mech-v2 as a DS by somehow side-stepping the fact 
that it has known technical omissions in the area of address 
selection that we have attempted to address in RFC 3484.

This goal seems to be based on some assumptions that I don't 
necessarily agree with, most notably:

- The assumption that there is some large value to moving 
draft-ietf-v6ops-mech-v2 despite its technical flaws in the area of 
address selection, and/or

- The assumption that RFC 3484 can't (or won't?) be moved to DS any time soon.

Right now, we are not even talking about whether or not to publish 
draft-ietf-v6ops-mech-v2 at DS!  The requested publication status for 
this document is PS,  RFC 3484 is already at PS, and normatively 
referencing RFC 3484 in draft-ietf-v6ops-mech-v2 will not block 
publication of this document.

Also, we're all really the same group of people...  So, if we (as a 
group) consider publishing draft-ietf-v6ops-mech-v2 as a Draft 
Standard to be a high priority, we can do the work to move RFC 3484 
to DS as well.

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?

I don't want to assert my beliefs above those of the entire v6ops WG. 
At this point, though, too few people have weighed in on this issue 
for the opinion of the v6ops WG to be clear (to me, anyway), one way 
or the other.  What do other people think?

Margaret

---

From: Alain Durand <[email-masked]>
Date: Sat, 17 Jul 2004 09:09:41 -0700

> specification that covers this topic?

Look at the table of content of the draft:

   2.  Dual IP Layer Operation..................................    5
          2.1.  Address Configuration...............................    5
          2.2.  DNS.................................................    5
   3.  Configured Tunneling Mechanisms..........................    7
          3.1.  Encapsulation.......................................    8
          3.2.  Tunnel MTU and Fragmentation........................    9
             3.2.1.  Static Tunnel MTU..............................    9
             3.2.2.  Dynamic Tunnel MTU.............................   10
          3.3.  Hop Limit...........................................   11
          3.4.  Handling ICMPv4 errors..............................   12
          3.5.  IPv4 Header Construction............................   14
          3.6.  Decapsulation.......................................   15
          3.7.  Link-Local Addresses................................   18
          3.8.  Neighbor Discovery over Tunnels.....................   19
  4.  Threat Related to Source Address Spoofing................   20
  5.  Security Considerations..................................   21
  6.  Acknowledgments...............

The essence of this draft is really about dual stack and tunneling IPv6 
over IPv4
as _the_ basic transition mechanisms. There is much more than DNS in the
operation of a dual stack node, however the draft only mention DNS,
and, as you mention, is not complete as it does not actually provide
a satisfactory answer to the overall problem.

This is the reason why I think we might as well declare the DNS issues 
out of scope.

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Sun, 25 Jul 2004 09:37:00 +0300 (EEST)

> This is the reason why I think we might as well declare the DNS issues 

I tend to agree with Alain here -- this document does not seem the 
place to describe everything needed on a dual-stack system.

Therefore I removed (in -04, published recently) some specification of 
DNS result ordering, but still kept a shortish summary on IPv6 DNS 
issues which seemed irrespective of that ordering.

Below is what's included in the recent draft:
=======
2.2.  DNS

   The Domain Naming System (DNS) is used in both IPv4 and IPv6 to map
   between hostnames and IP addresses.  A new resource record type named
   "AAAA" has been defined for IPv6 addresses [RFC3596].  Since
   IPv6/IPv4 nodes must be able to interoperate directly with both IPv4
   and IPv6 nodes, they must provide resolver libraries capable of
   dealing with IPv4 "A" records as well as IPv6 "AAAA" records.  Note
   that the lookup of A versus AAAA records is independent of whether
   the DNS packets are carried in IPv4 or IPv6 packets, and that there
   is no assumption that the DNS servers know the IPv4/IPv6 capabilities
   of the requesting node.

   The issues and operational guidelines for using IPv6 with DNS are
   described at more length in other documents [DNSOPV6].

   DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling
   both AAAA and A records.  However, when a query locates an AAAA
   record holding an IPv6 address, and an A record holding an IPv4
   address, the resolver library MAY order the results returned to the
   application in order to influence the version of IP packets used to
   communicate with that specific node -- IPv6 first, or IPv4 first.

   The applications SHOULD be able to specify whether they want IPv4,
   IPv6 or both records [RFC3493].  That defines which address families
   the resolver looks up.  If there isn't an application choice, or if
   the application has requested both, the resolver library MUST NOT
   filter out any records.

   Since most applications try the addresses in the order they are
   returned by the resolver, this can affect the IP version "preference"
   of applications.

   The actual ordering mechanisms are out of scope of this memo.
   Address selection is described at more length in [RFC3484].
====

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 28 Jul 2004 07:46:57 -0700 (PDT)

> 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