Subject: Re: Proposed way forward with the transition mechanisms

From: Erik Nordmark <[email-masked]>
Date: Sun, 1 Aug 2004 15:41:23 -0700 (PDT)

>   IPv4 over IPv6 tunneling mechanism

Did your analysis indicate what type of configuration support is
needed for this, and whether direction connection (e.g. between
two hosts on the same LAN) is required?

The reason I'm asking is because potentially the IPv4 over IPv6 tunneling
is just as rich as the IPv6 over IPv4 tunneling with lots of different
possible requirements. Trying to narrow things down would be useful.

   Erik

---

From: Pekka Savola <[email-masked]>
Date: Mon, 2 Aug 2004 16:26:39 +0300 (EEST)

> possible requirements. Trying to narrow things down would be useful.

(I am not sure if I understand what you meant with direct connection,
above -- clearly if you're directly connected, you don't need to 
tunnel to your peer..)

This is currently only pointed to from the unmanaged analysis, case D
(copied below), which practically seems to say "configured v4-in-v6,
with a tunnel endpoint discovery mechanism".  So, this, at least,
seems to rather straightforward and simple.  The expectation is that
you have an association with the tunnel endpoint.  I think this is
(luckily!) a relatively narrow requirement.

from the unmanaged analysis:

   Local IPv4 capable hosts may want to still access IPv4-only
   services. The proper way to do this for dual-stack nodes in the
   unmanaged network is to develop a form of "IPv4 over IPv6"
   tunneling. There are no standardized solutions and has been very
   little effort devoted by the IETF to this issue, although there is
   ongoing work with [DSTM] and [TSP]. A solution needs to be
   standardized. The standardization will have to cover configuration
   issues, i.e., how to provision the IPv4 capable hosts with the
   address of the local IPv4 tunnel servers.

-- 
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: Tim Chown <[email-masked]>
Date: Mon, 2 Aug 2004 23:47:40 +0100

> above -- clearly if you're directly connected, you don't need to 

Well, if you're "directly connected" in a mechanism that for an IPv6-only
infrastructure tunnels IPv4 over IPv6, I think the implied question is do 
you tunnel direct to the peer, or always via some (other) tunnel end point 
infrastructure/server/device?   (And this may be wider than the same LAN)
 
> (luckily!) a relatively narrow requirement.

No, I think it is also pointed to by the enterprise scenarios, Scenario 3,
which states:

 Scenario 3:   IPv6-only network infrastructure with some
               IPv4-capable nodes/applications needing to
               communicate over the IPv6 infrastructure.
               Enterprise deploying a new network or
               re-structuring an existing network, decides IPv6
               is the basis for most network communication.
               Some IPv4 capable nodes/applications will need
               to communicate over that infrastructure.

This really points to some IPv4-in-IPv6 tunneling capability.   You need 
a mechanism to discover the tunneling service and the tunnel endpoint, 
at least.  One example is DSTM.

Tim

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 02 Aug 2004 20:45:08 -0700

FYI,

The document mentioned in my earlier message (below) does contain
some elements which I believe could go towards an Enterprise Analysis
document - as I am well aware may also be true for some other documents.

Thanks - Fred
[email-masked]

Fred Templin wrote:
> Jonne,
> 
> Obviously, I support ISATAP progressing on standards-track as long
> as it can go forward in the correct way. The current I-D documents
> widely-deployed implementations and is suitable for intra-site operation
> when there are no NATs in the path, which might be OK for experimental
> purposes. But further discussion may be necessary to determine what
> is needed for standards-track.
> 
> In a recent series of I-Ds, I proposed an operational model for ISATAP
> similar to host-specific relay/personal tunnel broker, but the approach
> didn't seem to garner much interest. I'd like to propose a somewhat
> different approach now; for more details, please see:
> 
>  http://www.geocities.com/osprey67/v6v4inet-01a.txt
> 
> Thanks - Fred
> [email-masked]
> 
> Soininen Jonne (Nokia-NET/Helsinki) wrote:
> 
>> Hello everybody,
>> (chair hat off - this is totally my personal view)
>>
>> when writing the proposal for the WG, Pekka and I noticed that we have
>> different view on some issues. In one topic especially, we seemed to
>> have pretty opposing views. This topic is the role of ISATAP.
>> I do personally believe that ISATAP is pointed as the most promising
>> solution for automatic tunneling in the 3GPP analysis document and thus,
>> should be listed as a solution to be standardized.
>> I thought even that there was at least some support in the WG for ISATAP
>> and it had been seen also at least somewhat applicable for enterprise
>> scenarios. This is of course difficult to say as the enterprise analysis
>> document is not existing, yet.
>> However, I would hereby propose as an individual the addition of ISATAP
>> in the list of mechanisms that should be standardized on standards
>> track. (Of course, there has to be consensus in the WG to do that.)
>>
>> I would like to hear what other people feel about this! (Pekka's view I,
>> at least, know already.)
>>
>> Cheers,
>>
>> Jonne.
>> On Thu, 2004-07-29 at 23:07, ext Soininen Jonne (Nokia-NET/Helsinki)
>> wrote:
>>  
>>
>>> Dear v6ops WG,
>>>
>>> our very own AD, David, sent the WG list mail on the July 1st about the
>>> way forward and how he sees the way forward for our little WG. Pekka and
>>> I have discussed the topic and found enough consensus among ourselves to
>>> propose a way forward for the WG. Of course, you the WG, have to say if
>>> you agree with the following approach. We believe that the discussion
>>> should be started now on the WG list and then continue it in the
>>> face-to-face meeting in San Diego to work the details further. The final
>>> decision for the way forward is of course for the WG to make in the
>>> mailing list - as always in the IETF.
>>>
>>> The proposal is to derive the different transition mechanisms from the
>>> Scenarios/Analysis documents and identify either the matching, existing
>>> mechanism, or identify gap and list possible solutions. We have done our
>>> own preliminary analysis. The proposal bellow is for discussion and
>>> should not be considered the final list. We would like to have
>>> discussion if it really does identify all needed mechanisms and just the
>>> needed mechanisms.
>>> Bellow there is a list of mechanisms. This the list that Pekka and I put
>>> together in quite short time. It may or may not be correct and that's
>>> something that we have to discuss on the list and in the face-to-face in
>>> the meeting. So, this is just the baseline to start the discussion.
>>>
>>> In the interest of time, we propose to do this on the list and after
>>> running the process document it into a draft. I can do the draft editing
>>> myself.
>>>
>>> In the following, is the analysis of the different scenarios/analysis
>>> documents (in no particular order).
>>>
>>> 3gpp-analysis:
>>> SIP v4/v6 transition mechanism
>>> Zero-configured IPv6-over-IPv4 tunneling mechanism
>>>
>>> unmanaged:
>>>  Teredo*
>>>  Configured tunneling through NAT
>>> ISP:
>>>  BGP-tunneling*
>>>  Tunnel server/broker
>>> Enterprise:
>>>  Analysis not done.
>>> Summary:
>>>  Teredo*
>>>  BGP-Tunneling*
>>>  SIP v4/v6 transition mechanism - No candidates
>>>  Tunnel Server/Broker - TSP, Silkroad, Ayiya, STEP possible candidates
>>>  Configured tunneling through NATs - No (direct) candidates, but Tunnel
>>>        Server/Broker also addresses this
>>>  Zero-configured IPv6-over-IPv4 tunneling mechanism - TSP, Ayiya, STEP,
>>>        ISATAP possible candidates.
>>>  IPv4 over IPv6 Tunneling - DSTM, TSP, Ayiya possible candidates; many
>>>        tunnel server/broker approaches also address this.
>>>
>>> (* Teredo and BGP-tunneling are already moving forward)
>>>
>>> The suggestion is to go forward with Teredo/BGP-Tunneling immediately,
>>> work on SIP v4/v6 transition in SIP WG(s), and find the correct place
>>> for finding suitable solution for the following:
>>>
>>>  a) zero-configuration both at the client or the server,
>>>  b) IPv6-over-IPv4 tunnels (with NAT traversal support), and
>>>  c) IPv4-over-IPv6 tunnels
>>>
>>> This work should take use of 
>>> draft-ietf-v6ops-assisted-tunneling-requirements-00.txt.
>>>
>>> Cheers,
>>>
>>> Jonne & Pekka - the chairs.
>>>   
>>
> 
> 
>