Subject: (ngtrans) IPv6-IPv4 compatibility address - new draft version available

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 02 Oct 2000 11:25:44 -0700

Hello,

A new version of the draft entitled:

  "An IPv6-IPv4 Compatibility Aggregatable Global Unicast Address
   Format for Incremental Deployment of IPv6 Nodes Within Predominantly
   IPv4-based Intranets"

is available in the Internet Drafts repository at:

  http://www.ietf.org/internet-drafts/draft-templin-ngtrans-v6v4compat-01.txt

Major changes since version '00' include:

  1) Limits the scope for automatic IPv6-in-IPv4 tunneling to INTRA-SITE
     application only, as indicated by the title change

  2) Deployment considerations giving concrete examples of when this
     mechanism is useful

  3) Unambiguous sending rule for when to route via IPv6 vs. when to
     tunnel via IPv4

  4) Unambiguous address selection rule which imposes no major changes
     for current works in progress

  5) "Automatic deprecation" whereby the mechanism "turns itself off"
     when no longer needed

The draft abstract is attached below. Please send comments to the ngtrans
distribution and/or myself.

Regards,

Fred Templin
[email-masked]

Abstract:

   This document specifies an IPv6-IPv4 compatibility aggregatable
   global unicast address format and its application for incremental
   IPv6 deployment for hosts and routers within predominantly IPv4-based
   Intranets. This document assumes that, during the IPv4 to IPv6 co-
   existence and transition phase, many sites will deploy IPv6
   incrementally (not all at once) on hosts and routers within their
   pre-existing IPv4 interior routing domains; especially those sites
   which have large and complex pre-existing IPv4 infrastructures. In
   such cases, the address format and methods described in this document
   will enable IPv6 deployment for hosts and routers which do not share
   a common multiple access datalink with their default IPv6 gateways.

   While other works in progress in the NGTRANS working group propose
   mechanisms for assigning globally-unique IPv6 address prefixes to
   sites and methods for inter-domain routing between such sites, the
   approach outlined in this memo enables large-scale incremental
   deployment of IPv6 hosts and routers within an individual site's
   pre-existing IPv4 infrastructure without incurring aggregation
   scaling issues at the border gateways nor requiring site-wide
   deployment of special IPv4 services such as multicast. The approach
   proposed by this document supports IPv6 routing within both the
   site-local and global IPv6 routing domains as well as automatic IPv6
   in IPv4 tunneling across portions of a site's IPv4 network which have
   no native IPv6 support. Moreover, this approach supports automatic
   tunneling within sites which use non globally-unique IPv4 address
   assignments, such as when Network Address Translation [NAT] is used.

---

From: Jim Bound <[email-masked]>
Date: Mon, 02 Oct 2000 21:55:59 -0400

Hi Fred,

This draft looks better to me than before and also I am seeing the
advantage it brings to the IPv6 LAN for deployment.  I think we need to
pursue this very seriously in NGTRANS.  I need to reread it again with
my implementor hat on (last read was with my architecture hat on).  But
I think this is inherently useful as I thought 6to4 was as input to you.

regards,
/jim

---

From: Alain Durand <[email-masked]>
Date: Tue, 03 Oct 2000 18:15:00 -0700

>    Format for Incremental Deployment of IPv6 Nodes Within Predominantly

Let me point the following scenario:

Two IPv6 nodes A & B share the same /64 subnet (s), with one of them
(a)  implementing your scheme and the other one (b) not.

Communication from (a) to (b) implies a router (r) on subnet (s) that
understand your scheme.

A typical setup for (b) with current implementations  will be:
    - a default route to a router (R) [Note (R) may be different than (r)]
    - a route for subnet (s) on the interface attached to this link.

When (b) will try to send a packet to (a), it will see (a) is part
of the same subnet, assume that it is on the same link and
will think that (a) is a neighbor thus try neighbor solicitation.
Neighbor discovery will not work. It will get no response.
Communication is broken.

To solve this issue, I see 2 solutions:

- (b) should not believe that (a) is on the same link even though it share
   the same subnet. For that, all routers must advertise the subnet as not on
link.
   You get into the case of a multilink subnet, which is not trivial.
   E.g. traffic from (b) to (a) might go first on (R). So (R) has to either
   implement your scheme or learn from (r) about the attached remote hosts...
   not trivial at all. Btw, it is the case you describe as not working on page
10.

- Or you mandate that all hosts within subnet (s) must implement your scheme.

The second option is, in my opinion, the only viable one. But then I fear it
removes a lot of the value of your proposal, targeted at incremental deployment.

The  problem you are trying to solve seems to be to bring IPv6 connectivity
to an isolated host within a site which has already deployed an IPv6
infrastructure in only some parts of the network .
I think this may be solve more easily by other methods, such as an
internal tunnel broker.

On another point, you claim that your proposal works even in the presence of
NAT or multiple NAT within a site. I do not see how this can be done.
For example, if 2 nodes share the same IPv4 address 10.0.0.1 and are
part of the same /64 IPv6 subnet, I do not see how the tunnel can be set up.

    - Alain.

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 04 Oct 2000 11:44:51 -0700

Alain,

I assume that since you are only talking about IPv6 correspondent nodes
that share the same /64 prefix, you are OK with the case of nodes that
DO NOT share the same /64 prefix - correct? I THINK this will be a fairly
significant (if not predominant) case - would you agree? That said, I
will address the particular scenario you are concerned with:

> (a)  implementing your scheme and the other one (b) not.

When you say "share the same /64 subnet", do you mean "share the same /64
address prefix, but do NOT share the same (multiple access) datalink", or
"share the same datalink"? If the latter, then there is no problem because
(a) would hear (r)'s router advertisements and would automatically discontinue
use of its IPv6-IPv4 compatibility address and construct an IPv6 address via
address autoconfiguration with an interface identifier constructed via a
native IEEE 802.2 MAC address. (b) would cease using (a)'s IPv6-IPv4
compatibility address when it learns that (a) now has a native address due
to the address selection rule which prefers native addresses over IPv6-IPv6
compatibility addresses.

If instead you mean the former (as I presume), then the only logical
scenario is that (a) does NOT share a common datalink with (r) and (b)
DOES share a common datalink with (r). So, I'll continue from here with
 
> Communication from (a) to (b) implies a router (r) on subnet (s) that

Yes, where "subnet" means a common /64 network prefix, but NOT a common
multiple access datalink.
 
> removes a lot of the value of your proposal, targeted at incremental deployment.

As the document states:

=>   When a sender has an interface which shares a common 64-bit routing
=>   prefix with an IPv6-IPv4 compatibility destination address, however,
=>   the sender must assume that the destination is NOT directly reachable
=>   at the datalink level - even though the shared site-level routing
=>   prefix implies otherwise. Instead, if the sender comprises a dual-
=>   stack configuration, it should automatically tunnel the IPv6 packet
=>   (via IPv6-in-IPv4 tunneling as described in [MECH]) to the IPv4
=>   address embedded within the IPv6-IPv4 compatibility destination
=>   address' interface identifier. If the sender is an IPv6-only node
=>   that DOES NOT comprise a dual-stack configuration, however, it has no
=>   means for automatically tunneling the packet via IPv4. In this case:
=>
=>  - If the sender is the host that originates the packet, it should send
=>  the packet to a router that lists the 64-bit prefix in its router
=>  advertisements. If no such router exists, the sender should drop the
=>  packet and return a "No route to host" error indication to the ori-
=>  ginating application.
=>
=>  - If the sender is a router that forwards the packet, it should drop
=>  the packet and send an ICMPv6 "Destination Unreachable" message to the
=>  source

This implies that, for INTRA-SITE operation, IPv6 nodes must implement the
following simple test in ip6_output():

  if (<the destination's /64 prefix matches one of my interface prefixes>) {
+   if (<bytes 8-11 of the destination address == 0x02005EFE>) {
+     <assume destination is NOT on-link; send to a router which
+      advertises this /64 prefix>
+   } else
      <assume destination is on-link; perform ND and/or send directly
       to destination>
  } else {
    <perform an IPv6 routing lookup, and send to the best next-hop gateway>
  }

(Only the pseudo-code lines preceded by "+" are new). So, the solution
proposed by the document is basically the same as your proposed soluton
#2. But, two points about this:

  1) This is only required for INTRA-site operation between currently
     deployed IPv6 nodes and newly-deployed nodes using IPv6-IPv4
     compatibility addresses, and thus only represents a single case
     which may very well not be the predominant case. But even so, are
     there *REALLY* lots of currently-deployed IPv6 nodes which have
     cast-in-stone implementations that won't be upgraded to reflect the
     latest changes to the IPNG and NGTRANS protocol standards in due
     course?? If not, then it becomes merely a race as to whether
     newly-deployed nodes with IPv6-IPv4 compatibility addresses will
     proliferate before the above-described code changes are propagated
     to existing IPv6 nodes. Even if the newly-deployed nodes win the
     race, the INTRA-site issue will go away as existing nodes upgrade
     their IPv6 implementations - unless you believe existing nodes 
     predominantly have implementations which are cast-in-stone and
     will never change. (I somehow tend not to belive this is the case.)

  2) If you are concerned that (b) will discover some (R) that does
     not handle IPv6-IPv4 compatibility addresses when it *could have*
     discovered an (r) that *does* handle such addresses, an easy fix
     is to have (r) advertise a /96 prefix. For example, if the /64
     prefix is:

      3FFE:1a05:510:2422::/64

     and (r) is capable of performing automatic tunneling as per the
     IPv6-IPv4 compatibility scheme, then (r) could advertise:

      3FFE:1a05:510:2422:0200:5EFE::/96

     Then, (b) would prefer (r) over (R) for IPv6-IPv4 compatibility
     address destinations. I didn't want to "go there" in the draft, but
     perhaps I should have..
	 
> I think this may be solve more easily by other methods, such as an

The isolated host is just one limited example of what this is good for. This
scheme also supports entire isolated IPv6 *networks* that are buried within an
administrative domain with a predominantly IPv4-based infrastructure. In this
case, the isolated IPv6 networks will have gateways which use IPv6-IPv4
compatibility addresses for tunnelling across the IPv4 infrastructure, but
will use native IPv6 addresses internally. In fact, if you extrapolate upwards
in terms of what is meant by an "administrative domain", you could postulate
native IPv6 prefixes assignments for all border gateways at the core of the
existing Internet. Then, individual institutions would either deploy native
IPv6 networks or would use IPv6-IPv4 compatibility addresses to automatically
tunnel across portions of the pre-existing IPv4 Internet leading up to the
core. In this case, 6TO4 prefixes would never be needed!!

In short, I believe 6to4 is most useful near the "core" of the heterogeneous
IPv6/IPv4 Internet while my proposed scheme is most useful near the "edges".
To say that transition scenarios will be limited to only one or the other
seems rather inflexible to me. 

> part of the same /64 IPv6 subnet, I do not see how the tunnel can be set up.

If there is a SINGLE private address space in effect within an administrative
domain, then presumably each node will have a unique IPv4 address assignment
within that address space; else IPv4 would be broken. (i.e. For a single
private address space "A", the address assignment 10.0.0.1 must be unique).
If an administrative domain has MULTIPLE independent private address spaces,
then there can potentially be duplicate address assignments on an inter-address
space  basis. (i.e. 10.0.0.1 might exist in both private address space "A"
and private address space "B".) In the case of MULTIPLE independent address
spaces, there must be a unique /64 prefix assignment for each private address
space. Since IPv6 prefix allocations to administrative authorities are expected
to be on a /48 (or larger) granularity, the SLA can be used for "subnetting" to
assign a unique /64 prefix to each private address space. Then, intra-site
IPv6-in-IPv4 tunnelling can be done WITHIN address spaces "A" and "B"
independently of one another, while IPv6 routing can be done between address
spaces "A" and "B" even if the correspondent hosts happen to have identical
(private) IPv4 address assignments. This was not explained in detail in the
document, but can be added easily.
 
>     - Alain.

Fred
[email-masked]