Basic Transition Mechanisms for IPv6 Hosts and Routers
draft-ietf-v6ops-mech-v2-07

Received changes through RFC Editor sync (changed abstract to 'This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures.

This document obsoletes RFC 2893. [STANDARDS-TRACK]')

[Note]: 'Back to clear Steve''s DISCUSS and for review of other minor changes. html diffs are available from:
http://www.netcore.fi/pekkas/ietf/temp/ Participant in PROTO Team pilot:
Working Group Chair Followup of DISCUSS Comments
http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-discuss-pilot-01.txt' added by Amy Vezza

[Ballot comment]
Reviewed by Joel Halpern, Gen-ART

His review:

This draft is ready for publication as a Proposed Standard RFC.

Minor comment:

The description of tunneling seems to say that it is only for use by
routers.  It does say that the decision about using tunnels should be
based on routing information.  It would be helpful if there were a
short section on "method selection" which stated, for at least most
common circumstances, which method should be used and why.

[Ballot discuss]
3.3: what is the benefit of using TTL 255 here?  Please delete that.  (I see that it's left over from a hint to use GSTM; I asked that that be deleted.  But why leave the TTL suggestion in that case?)  Frankly, I think the entire paragraph is useless, since the remaining text boils down to "do it the standard way".)

[Note]: 'Back to clear Steve''s DISCUSS and for review of other minor changes.

html diffs are available from:
http://www.netcore.fi/pekkas/ietf/temp/

Participant in PROTO Team pilot:
Working Group Chair Followup of DISCUSS Comments
http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-discuss-pilot-01.txt' added by David Kessens

[Note]: '
Back to clear Steve''s DISCUSS and for review of other minor changes.

Participant in PROTO Team pilot:
Working Group Chair Followup of DISCUSS Comments
http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-discuss-pilot-01.txt' added by David Kessens

[Ballot discuss]
Please remove the GSTM suggestion.  It's a very inappropriate mechanism in this case.

Section 5: it's *not* that hard to learn the source address of a tunnel endpoint.

The security section seems to say "just use IPsec".  That's not nearly enough detail on how to do it interoperably.

[Ballot discuss]
This text confuses me somewhat:

  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 filter or order the results
  returned to the application in order to influence the version of IP
  packets used to communicate with that node.  In terms of filtering,
  the resolver library has three alternatives:

  -    Return only the IPv6 address(es) to the application.

  -    Return only the IPv4 address(es) to the application.

  -    Return both types of addresses to the application.

So the resolver can receive a DNS result and remove portions of the answer?  Allowing the resolver to decide which portions of the answer are returned doesn't sound like a good idea to me.

[Ballot discuss]
It may be worth adding to the document that implementations should consider
dynamically changing the state of the configured tunnels depending on the
resolvability of the tunnel's end-point address in the IPv4 routing table. This
comes really handy in deployments with some redundancy and floating static
routes.

Section 3.6:

>    In addition, the node should perform ingress filtering [RFC2827] on
>    the IPv6 source address, similar to on any of its interfaces, e.g.:

>    -  if the tunnel is towards the Internet, check that the site's
>        IPv6 prefixes are not used as the source addresses, or
>
>    -  if the tunnel is towards an edge network, check that the source
>        address belongs to that edge network.

Is this an implementation requirement or a deployment/configuration
recommendation? If the former, than 2119 language should be used, and the doc
needs to explain how the router understand if the tunnel is "towards the
Internet" or "towards an edge network". If the latter, the doc should say
something like "the node should be configured to perform..."

> 3.7.  Link-Local Addresses
...
>    The interface identifier [RFC3513] for such an interface may be based
>    on the 32-bit IPv4 address of an underlying interface, or formed
>    using some other means, as long as it's unique from the other tunnel
>    endpoint with a reasonably high probability.

This doesn't work with multiple tunnels using the same IPv4 interface,
and this, I think, will be the common case.

> 3.8.  Neighbor Discovery over Tunnels
...
>    Not using a link layer address options is consistent with how
>    Deighbor Discovery is used on other point-to-point links.

"Deighbor" -> "Neighbor"

Section 5:

>    Additionally, an implementation must treat interfaces to different
>    links as separate

I'm not sure I understand this part. Is it trying to say that different
tunnels should be considered different p2p interfaces rather than a single
p2mp one?

> e.g. to ensure that Neighbor Discovery packets
>    arriving on one link does not effect other links.  This is especially
>    important for tunnel links.

[Ballot comment]
Given that this document addresses two mechanisms, dual-stacks and tunneling, I'm kind of surprised that the Security Considerations seems to talk exclusively about tunneling. Are there no security considerations in the use of a dual-stack host? Especially given the fact that some applications on a given host may be configured to use only one stack or another, as Section 2 suggests? I can imagine a number of cases in which different protocols may be used in concert by a host (say, SIP and RTP), where conceivably different protocols employing different stacks could be used by the same application. Surely there's some security implications of that.

[Ballot comment]
Since mrw is already holding a discuss on 2.2, I've listed this is a comment,
but it might be worth the authors' considering when they look at her discuss.

I'm concerned both about this text:

  However, when a query locates an AAAA
  record holding an IPv6 address, and an A record holding an IPv4
  address, the resolver library MAY filter or order the results
  returned to the application in order to influence the version of IP
  packets used to communicate with that node.

and the general approach of describing the filtering mechanism
available to the resolver as if it were the primary way of
preferring AAAA to A or vice versa.  The most obvious way
to prefer one address family over the other is to query for
one RR in preference to the other.  You may still get other
data back, of course, but this gives control earlier than
filtering post-facto, and it deserves a mention here. 

To take a random example, if I dig for the AAAA
record associated with ns-ext.isc.org, I get the A record in
the additional section; that might be filtered, but the preference
is already established.  The case they seem to be focused
on is the one like that in which a dig for the ns records for isc.org
returns both A and AAAA records associated with hosts
like ns-ext.isc.org.  That's fine, and it should be included,
but as part of the larger context.  I suspect they simply thought
the choice of RR was too obvious to list, but I'm guessing it
is not for the intended audience of this document.

[Ballot discuss]
Please explain how the GSTM helps here.  Most tunnel links are more than one hop.

Section 5: it's *not* that hard to learn the source address of a tunnel endpoint.

The security section seems to say "just use IPsec".  That's not nearly enough detail on how to do it interoperably.

[Ballot discuss]
Section 2.2 provides a considerable amount of information about how dual stack nodes will handle situations where both A and AAAA addresses are returned by DNS.  This situation is well covered in RFC 3484, and I think it would be better to remove much of this section and simply refer to RFC 3484.

In particular, this section over-simplifies the filtering and ordering mechanisms that are needed to do proper address selection.

I also have two minor editorial comments:

  The most straightforward way for IPv6 nodes to remain compatible with
  IPv4-only nodes is by providing a complete IPv4 implementation.  IPv6
  nodes that provide a complete IPv4 and IPv6 implementations are

s/provide a complete/provide complete

  is no assumption that the DNS server know the IPv4/IPv6 capabilities
  of the requesting node.

s/DNS server know/DNS servers know (or DNS server knows)

[Ballot discuss]
Section 2.2 provides a considerable amount of information about how dual stack nodes will handle situations where both A and AAAA addresses are returned by DNS.  This situation is well covered in RFC 3484, and I think it would be better to remove much of this section and simply refer to RFC 3484.

In particular, this section over-simplifies the filtering and ordering mechanisms that are needed to do proper address selection.

I also have two minor editorial comments:

  The most straightforward way for IPv6 nodes to remain compatible with
  IPv4-only nodes is by providing a complete IPv4 implementation.  IPv6
  nodes that provide a complete IPv4 and IPv6 implementations are

s/provide a complete/provide complete

  is no assumption that the DNS server know the IPv4/IPv6 capabilities
  of the requesting node.

s/DNS server know/DNS servers know (or DNS server knows)

[Ballot discuss]
2.  Dual IP Layer Operation


Section 2.2 provides a considerable amount of information about how dual stack nodes will handle situations where both A and AAAA addresses are returned by DNS.  This situation is well covered in RFC 3484, and I think it would be better to remove much of this section and simply refer to RFC 3484.

In particular, this section over-simplifies the filtering and ordering mechanisms that are needed to do proper address selection.

I also have two minor editorial comments:

  The most straightforward way for IPv6 nodes to remain compatible with
  IPv4-only nodes is by providing a complete IPv4 implementation.  IPv6
  nodes that provide a complete IPv4 and IPv6 implementations are

s/provide a complete/provide complete

  is no assumption that the DNS server know the IPv4/IPv6 capabilities
  of the requesting node.

s/DNS server know/DNS servers know (or DNS server knows)