Subject: Re: (ngtrans) Re: I-D ACTION:draft-templin-ngtrans-v6v4compat-00. txt

From: "Sellers, Julian P" <[email-masked]>
Date: Thu, 13 Apr 2000 16:59:36 -0400

Fred,

The following is from 3.1 of the draft:

	It is also important to notice that, in the intra-domain case, IPv4
    addresses may not be globally unique but may be allocated through some
    private network addressing scheme which has meaning only within the
    context of that domain. But, we can construct a SECOND form of the
    IPv6-IPv4 compatibility address described in section 2 by inverting
    the sense of the 'u/l' bit for private IPv4 addresses. For example,
    a node with the private (non globally unique) IPv4 address 10.0.0.1
    could be assigned the IPv6-IPv4 compatibility address:

	3FFE:1a05:510:200:0000:5EFE:10.0.0.1

    (using the same example IPv6 prefix and IANA OUI given in section 2)
    with the 'u/l' bit in the EUI-64 interface identifier cleared to
    indicate that this is a LOCAL address. But, such an address could be
    treated using the same routing decision policies given above in the
    intra-domain case since private addresses are eligible for IPv4 routing
	 within that domain.

I don't think this is acceptable because when the u/l bit is clear, no
assumptions can be made regarding the interface-id contents.  Anyone can
assign an interface-id of 0000:5EFE:xxxx:xxxx in which xxxx:xxxx is not an
IPv4 address.

Julian

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 13 Apr 2000 14:30:24 -0700

Julian,

Yes, I think your point is valid. I think perhaps my document
"overloads" the meaning of the u/l bit in that I was planning to
use it to infer whether the embedded IPv4 address is globally
routable or not. (In addition to the intended EUI64 meaning,
which is to tell whether/not a link-level address is eligible
for joining an unrestricted multiple-access datalink.)

However, I think I can re-word the draft to say that the u/l bit
will also be '1' even in the case that the embedded IPv4 address
is non globally routable (i.e. network 10 and its siblings). Two
factors make this possible:

 1) The IPv4 forwarding code in an inter-domain IPv6-in-IPv4 tunnel
    endpoint would recognize the embedded IPv4 address as non globally
    routable and would thus refuse to forward it. (Layer-3
    consideration). 

 2) The EUI64 addresses constructed using the method described in my
    draft would never be used in place of an OEM network interface
    manufacturer's burned-in IEEE 802 MAC address at the datalink
    level. (Layer-2 consideration).

I'll go back and see if I can address this with better wording
in the draft.

Thanks,

Fred
[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Thu, 13 Apr 2000 16:36:21 -0700

The main problem I see with this proposal is related to the sending rules.
I'm not sure to understand how it works.

Next is a quote of the original comments I sent to the author when he
first presented me his draft.

    - Alain.

<==
section 3.1:
    A source node with an
    IPv6-IPv4 compatibility address which sends an IPv6 message to a
    destination node with an IPv6-IPv4 compatibility address can employ
    routing policy decisions such as:

      - if the IPv6 routing table has an entry for the destination's
        IPv6 prefix, and there is a path to gateway for the destination's
        IPv6 prefix through the IPv6 routing infrastructure (*), send as
        a native IPv6 packet to the IPv6 gateway for that prefix

      - if the IPv4 routing table has an entry for a prefix of the
        destination's embedded IPv4 address, tunnel the IPv6 packet
        through the IPv4 routing infrastructure (using IP protocol 41)
        by encapsulating it in the manner described in [MECH] (**)

      - if the IPv6 routing table has an entry for 'default', and there
        is a path to the default IPv6 gateway through the IPv6 routing
        infrastructure (*), send as a native IPv6 packet to the default
        IPv6 gateway

      (*) If there is no path to the IPv6 gateway through the IPv6
          routing infrastructure, tunnel the IPV6 packet through the
          IPv4 routing infrastructure using the gateway's embedded
          IPv4 address as the destination for the tunneled packet.
          This implies that the gateways must also use IPv6-IPv4
          compatibility addresses.

      (**) [MECH] specifies an automatic tunneling mechanism for
           IPv4-compatible addresses formed as the 96-bit prefix
           0:0:0:0:0:0/96 followed by the embedded IPv4 address.
           But, this same mechanism may be used for the IPv6-IPv4
           compatibility address format proposed in this draft
           by truncating the leading 96-bits of the address.
<==

I do not understand choice 1)
"if there is a path to gateway for the destination's
IPv6 prefix through the IPv6 routing infrastructure". This proposal does
not specify how do one discover the existence of such a path.
Typically, how do a host discover that the destination is on an isolated,
non connected IPv6 island?

I fear to understand this this is known by the existence of a non
default IPv6 route for that host...

But, typically a host will have routes for the local prefixes and a default
route
to the nearest router. More, when sending a packet, the host has
no clue about the destination prefix ; all it knows is the destination
address. I would NOT recommend to automatically derived
a /64 prefix out of this destination address and to use this to
walk through the routing table and, worst of all, recommend
that any host should get a default free set of the IPv6 routes...

So, in a typical case where a host only has routing entries for
the local prefixes and the default route AND an IPv4 address,
and my understanding of choice 1) is correct, that is default route
is not taken into account, communication of two 'normal' IPv6 nodes on the same
subnet
will use native IPv6 and communication to any other IPv6 hosts
implementing this proposal will use tunnels over IPv4 regardless
of the IPv6 connectivity. This is, at best, not really optimal...

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 13 Apr 2000 16:44:26 -0700

Alain and others,

I'm about to leave for the day and will be on travel until Wednesday
of next week. I will take this message with me and will respond to
it (and any other comments the group may have) when I return.

Thanks, and sorry I can't respond more immediately...

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 20 Apr 2000 10:27:17 -0700

Alain,

I'm just back from my trip; sorry it has taken me so long to
respond to your message. Regarding your comments on the sending
rules, just so that the group is aware I am including below my
previous response to your personal inquiry from back on March 20th.

But, I'd like to point out (as I also mentioned in a response to
Brian Carpenter) that my work evolved from a focused project that
investigated only one possible IPv6-IPv4 compatibility scenario, and
the text from section 3.1 derived out of that one isolated scenario.
So, I don't think it would be energy well spent to try to defend or
refine this particular text further; that would be like trying to
describe the structure of a complex tree by focusing on one of the
leaves.

Instead, I'd like to take a step back and take a top-down (rather
than bottom-up) look at the possible application for my draft by
writing out a variety of scenarios as was done in the 6to4 draft.
(Brian Carpenter also suggested such an approach). This would allow
a study to compare the relative merits for the 6to4 approach, the
approach in my draft, or a combined approach on a case-by-case basis.
In the process, I would expect the text from section 3.1 from my
draft would be replaced by discussion of sending rules as they
relate to the individual scenarios. My plan would be to then update
the existing draft with the new text describing the scenarios and
present the new version of the draft at the next WG meeting.

Do you concur with this approach?

Regards,

Fred Templin
[email-masked]   

> By this, I mean the source node consults its own IPv6 routing table
> for a prefix match on the IPv6 address of the destination. If there
> is a "reasonable" match, then send the message to the IPv6 gateway
> listed in the IPv6 routing table for this message. But, the source
> node would then need to consult its own IPv6 routing table for a
> prefix match on the IPv6 address of the gateway. This might result
> in an automatic IPv6-in-IPv4 tunnel to the gateway which would then
> forward the message to the destination over either native IPv6
> routing or through yet another automatic tunnel.
>  
> > But, typically a host will have routes for the local prefixes and a default route
> > is not taken into account, communication of two nodes on the same subnet
> You're probably right that most hosts will have routes only for the
> local IPv6 prefixes and a default route to the nearest IPv6 router.
> My routing policy decisions above are cast in wet mud at best and
> need alot more thought. It's almost a situation of there being too
> much flexibility with my scheme, but I think a much tighter set of
> routing policy decisions could be constructed given futher analysis.
> 
> Perhaps the optimal solution would be something like a simultaneous
> consultation of both the IPv6 and IPv4 routing tables followed by a
> choice of the "best" route. For example, if the IPv6 routing table
> lookup returns "default" as the best route, but the IPv4 routing
> table returns a host route for the embedded IPv4 address in the
> interface ID, you might opt to tunnel over IPv4 rather than send
> to the default IPv6 router.

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 26 Apr 2000 15:41:52 -0700

Alain,

Again, I apologize for taking so long to get back to you. My mailer
somehow buried your reply, and I'm just seeing your message for the
first time today. Some comments on your message:

> I understand your approach and desire to look at the problem
> from a higher point of view.

OK. I will work on the scenarios and publish them in a revised
verion of the draft.

> However, I will not consider the sending rules as minor items.
> If they do  not work, there is a major flow in the proposal,
> and, for me, this would be a show stop.

Nor do I consider the sending rules minor items; I am only interested
in approaches that have practical and near-term application for ngtrans;
after all, these transition mechanisms are theoretically for the short
term only and must give way to a fully-native IPv6 infrastructure in
the future.

Please remember that this is version 0 of the draft, however, and that
the sending rules in section 3 derive from one specific scenario. The
sending rules in the draft were my attempt to describe the way my
prototype implementation works for a very specific scenario in which:

  - All hosts engaging in the scheme are single, isolated IPv6 hosts
    within otherwise all-IPv4 subnets
  - All hosts engaging in the scheme are assigned IPv6-IPv4 compatiblity
    addresses as described in my draft

In this scenario (as in any other), prefix information populated in
the IPv6 routing table can provide finer-grained matches for destination
addresses than by just having a 'default' route. But, there NEED NOT be
any routing info other than for 'default' in the IPv6 routing table for
my method to work in this scenario. Additionally, it is highly unlikely
that all IPv6 hosts in the Internet would be assigned IPv6-IPv4
compatibility
addresses as the sending rules for my specific scenario assumes. But, I
have
not yet taken a top-down look at any of the commonly-expected IPv6/IPv4
transition/compatibility deployment scenarios to investigate a set of
sending
rules that will work in the generalized case. So, I simply ask for a
fair
chance to investigate the scenarios and present a generalized set of
sending
rules. I'm confident that this can be done. But if it can't be done,
I'll be
the first to agree that it "doesn't work".

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 26 Apr 2000 16:53:03 -0700

Alain,

> my method to work in this scenario.

Acutally, in the specific and constrained scenario presented in my
draft,
hosts need not even have a 'default' route in their IPv6 routing tables;
at a minimum, they need only have a 'default' route in their IPv4
tables.
But again, the sending rules in my draft are specific to that one
constrained
scenario; my plan is to produce a generalized set of sending rules based
on my analyses of the various anticipated ngtrans deployment schemes.

Fred
[email-masked]