guidelines for the operation of a shared IPv4/IPv6 Internet

Pekka Savola | 5 Aug 2005 21:47

WGLC ent-analysis-03: DSTM

Hi,

(I'll put two most separable & possibly most discussable items in 
separate mails.)

In 8.1:

  Later in the transition process, after the enterprise has
  transitioned to a predominately IPv6 infrastructure, the architect
  should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. Or
  in the case of early deployment of IPv6-dominant networks DSTM can
  be used too.

and in 8.4:

DSTM [DSTM, DSTM+] is a useful tunneling mechanism for later in the
enterprise transition or deployment of IPv6-dominant network links
is desired. DSTM is to being submitted as an IETF Experimental RFC.

==> as it is, DSTM is a way too overloaded a mechanism to be referred to
without more disclaimers or description.  As it is, different people use
"DSTM" to mean at least the following things:
  a) v4-in-v6 tunnels
  b) automatically set-up v4-in-v6 tunnels
  c) automatic set up of v4-in-v6 tunnels when the host
     doesn't have v4 address and an app wants to create a v4 socket
  d) automatic monitoring and tear-down of said v4-over-v6 tunnel
     when the host detects it no longer needs the address/connectivity
  e) plus a number of extensions for even more colorful setups.

(Continue reading)

headers

Francis Dupont | 17 Aug 2005 10:04

Re: WGLC ent-analysis-03: DSTM

 In your previous mail you wrote:

   and in 8.4:

   DSTM [DSTM, DSTM+] is a useful tunneling mechanism for later in the
   enterprise transition or deployment of IPv6-dominant network links
   is desired. DSTM is to being submitted as an IETF Experimental RFC.

   ==> as it is, DSTM is a way too overloaded a mechanism to be referred to
   without more disclaimers or description.

=> the overload (if any) should be solved by the references...

    As it is, different people use
   "DSTM" to mean at least the following things:

=> I saw the birth of DSTM: DSTM is Jim Bound's AIIH + Laurent Toutain's DTI.

     a) v4-in-v6 tunnels
     b) automatically set-up v4-in-v6 tunnels

=> this (b-a) is DTI

     c) automatic set up of v4-in-v6 tunnels when the host
        doesn't have v4 address and an app wants to create a v4 socket

=> this (c-b) is AIIH

     d) automatic monitoring and tear-down of said v4-over-v6 tunnel
        when the host detects it no longer needs the address/connectivity

(Continue reading)

headers

Pekka Savola | 19 Aug 2005 11:51

Re: WGLC ent-analysis-03: DSTM

First off (after writing the response below), let me clarify the list 
of v4-in-v6 tunnel functions:

As it is, different people use "DSTM" to mean at least the following 
things:

  a) (manually configured) v4-in-v6 tunnels [RFC2473]

  b.1) the set-up of the bidirectional v4-in-v6 tunnel with the tunnel
     server(s) which can happen without user intervention, e.g., using
     one of the processes described in draft-palet-v6ops-tun-auto-disc-03.txt.
     This must include a way to auto-configure a v4 address [e.g., DHCPv4].

  b.2)  the automatic set-up of v4-in-v6 tunnels, so that between each
     host, an ad-hoc tunnel can be signalled and set up" [6to4-like
     traffic optimization]

  c) assignment of an address on top of v4-in-v6 tunnel(s), but
     deferred until the application wants to create v4 socket.
     [issues with dual-stack server apps, for example]

  d) automatic monitoring and tear-down of said v4-over-v6 tunnel(s)
     when the host detects it no longer needs the address/connectivity

  e) plus a number of extensions for even more colorful setups (e.g.,
     instead of just assigning an address, assign only certain _ports_
     of an address).

Personally,
  - I believe there is a need for a) [but that's already specified];

(Continue reading)

headers

Francis Dupont | 19 Aug 2005 15:15

Re: WGLC ent-analysis-03: DSTM

 In your previous mail you wrote:

   First off (after writing the response below), let me clarify the list 
   of v4-in-v6 tunnel functions:

   As it is, different people use "DSTM" to mean at least the following 
   things:

     a) (manually configured) v4-in-v6 tunnels [RFC2473]

     b.1) the set-up of the bidirectional v4-in-v6 tunnel with the tunnel
        server(s) which can happen without user intervention, e.g., using
        one of the processes described in
        draft-palet-v6ops-tun-auto-disc-03.txt.

=> note this I-D was submitted years after DSTM and is not a complete
solution (in fact, today it is not a solution at all .

        This must include a way to auto-configure a v4 address [e.g., DHCPv4].

=> I believe you mean something providing the same service than DHCPv4,
not DHCPv4 itself.

     b.2)  the automatic set-up of v4-in-v6 tunnels, so that between each
        host, an ad-hoc tunnel can be signalled and set up" [6to4-like
        traffic optimization]

=> I believe you have "direct tunnels" in the b.2 idea?

     c) assignment of an address on top of v4-in-v6 tunnel(s), but

(Continue reading)

headers

Pekka Savola | 22 Aug 2005 12:10

Re: WGLC ent-analysis-03: DSTM

On Fri, 19 Aug 2005, Francis Dupont wrote:
>     b.1) the set-up of the bidirectional v4-in-v6 tunnel with the tunnel
>        server(s) which can happen without user intervention, e.g., using
>        one of the processes described in
>        draft-palet-v6ops-tun-auto-disc-03.txt.
>
> => note this I-D was submitted years after DSTM and is not a complete
> solution (in fact, today it is not a solution at all .

Within an enterprise network (and having to discover v4-in-v6 TEP, so 
NATs are not an issue), the problem is much more constrained, so e.g., 
DHCPv6 is a possible solution.  Softwires BOF might do something about 
this, or maybe not -- if folks are interested in this kind of problem, 
maybe they should speak up at a forum.  In any case, the same 
approaches as are available for "DSTM" are probably also applicable 
here.

>        This must include a way to auto-configure a v4 address [e.g., DHCPv4].
>
> => I believe you mean something providing the same service than DHCPv4,
> not DHCPv4 itself.

While DHCPv4 may or may not require minor tweaks (e.g., relating to 
link-layer adaptation), I think it could basically be used itself, 
and for the service.  Could you elaborate why you think it's 
inappropriate?

>     b.2)  the automatic set-up of v4-in-v6 tunnels, so that between each
>        host, an ad-hoc tunnel can be signalled and set up" [6to4-like
>        traffic optimization]

(Continue reading)

headers

Francis Dupont | 22 Aug 2005 19:04

Re: WGLC ent-analysis-03: DSTM

 In your previous mail you wrote:

   >        This must include a way to auto-configure a v4 address [e.g., DHCPv4].
   >
   > => I believe you mean something providing the same service than DHCPv4,
   > not DHCPv4 itself.

   While DHCPv4 may or may not require minor tweaks (e.g., relating to 
   link-layer adaptation),

=> using DHCPv4 over a tunnel is *not* a minor tweak.

   I think it could basically be used itself, and for the service.

=> unfortunately this is not true. BTW the code itself can be reused
but this is not the case of the protocol.

   Could you elaborate why you think it's inappropriate?

=> DHCPv4 can't send a packet over a tunnel which has no addresses,
the limitation comes from DHCPv4 itself and from the nature of tunnels.
But as I've explained this is not dramatic: we already have the code
which provides the service, we only need to add some glue to replace
the protocol, or if you prefer this way a small facility for carrying
DHCPv4 messages and a translator (better if you can only reuse the
binary of the server).

   No, "global v4 addresses -> c)" does not follow.

   It is a perfectly fine way to run and use addresses to give each node

(Continue reading)

headers

Pekka Savola | 24 Aug 2005 12:46

Re: WGLC ent-analysis-03: DSTM

On Mon, 22 Aug 2005, Francis Dupont wrote:
> => using DHCPv4 over a tunnel is *not* a minor tweak.

Creating a separate thread out of this.

>   No, "global v4 addresses -> c)" does not follow.
>
>   It is a perfectly fine way to run and use addresses to give each node
>   requiring v4 connectivity a static global address.
>
> => you only assume that anybody has already enough global addresses.
> I'd like that it is true but in fact it is not.

I think you're assuming that everyone with [not "enough", i.e., 
basically everyone] global v4 address will want c) as a consenquence. 
I disagree with that.

I agree that some might see c) as a potential solution.  A subset of 
those might even think c) is worth the trouble.  But it is IMHO too 
wide a generalization to just say "global v4 addresses -> c)".

>   Those which need
>   them only now and then can also use global addresses, but the easiest
>   would probably be using RFC1918 for those nodes.
>
> => RFC 1918 and a NAT? Is it really your idea??

Yes.  People use it, and seem to be pretty happy about doing so.

Remember, we're offering *v6* as an end-to-end protocol which doesn't

(Continue reading)

headers

Francis Dupont | 25 Aug 2005 11:10

Re: WGLC ent-analysis-03: DSTM

 In your previous mail you wrote:

   > => RFC 1918 and a NAT? Is it really your idea??

   Yes.  People use it, and seem to be pretty happy about doing so.

=> this is a philosophical issue... Here is not the right place
to discuss it.

   Remember, we're offering *v6* as an end-to-end protocol which doesn't 
   have to deal with NAT etc.  In that light providing this functionality 
   for v4 might even be counterproductive :)

=> and say that RFC 1918 and a NAT will solve any problem is productive :) ?

   > => Do you argue there is not realistic scenarios where there is no
   > choice and the IPv4 address space has to aggressively be conserved?

   No, I'm not saying that.  What I'm saying is that people will use 
   different (simpler) tools to perform this conservation.  The easiest 
   one at their disposal is RFC1918 and NAT.

=> NAT is not a general solution: it doesn't work with embedded addresses.
So you have no real counter-argument.

   My argument is that let people use RFC1918, NAT, or whatever 
   mechanisms they want for *v4* address conservation, let us focus on 
   *v6* transition, not finding means how to prolong v4 address usage 
   under aggressive conservation.

(Continue reading)

headers

Pekka Savola | 29 Aug 2005 09:34

Re: WGLC ent-analysis-03: DSTM

On Thu, 25 Aug 2005, Francis Dupont wrote:
>   Remember, we're offering *v6* as an end-to-end protocol which doesn't
>   have to deal with NAT etc.  In that light providing this functionality
>   for v4 might even be counterproductive :)
>
> => and say that RFC 1918 and a NAT will solve any problem is productive :) ?

Yes -- at least it will encourage people to see the benefits of v6 in 
a different light :)

>   > => Do you argue there is not realistic scenarios where there is no
>   > choice and the IPv4 address space has to aggressively be conserved?
>
>   No, I'm not saying that.  What I'm saying is that people will use
>   different (simpler) tools to perform this conservation.  The easiest
>   one at their disposal is RFC1918 and NAT.
>
> => NAT is not a general solution: it doesn't work with embedded addresses.
> So you have no real counter-argument.

Yes, it doesn't work, but what I'm asking here is a reality check.

I guess what you're saying is that some sites have binary-only, 10+ 
old applications which have embedded addresses.  Those applications 
work just fine if you use them internally in the site only (using 
RFC1918 addresses).

Do you want to provide such an application to the outside?  -- REALLY? 
Even if you do, I don't think a site has dozens of such applications 
on dozens of hosts.  Those applications are required to work reliably

(Continue reading)

headers

Tim Chown | 29 Aug 2005 12:02

Re: WGLC ent-analysis-03: DSTM

On Mon, Aug 29, 2005 at 10:34:39AM +0300, Pekka Savola wrote:
> 
> I don't think the purpose of any v6ops document is solve problems in 
> one's *v4* network by *v4* mechanisms, so it's not entirely clear if 
> the mechanism is in the scope of this WG.

If you deplay a v6-only network infrastructure then v4 transport is a 'v6
problem'.   I guess he crux of your argument is
a) why not run dual stack, even with v4+NAT
b) why can't apps be updated to use IPv6

Tim

headers

Pekka Savola | 29 Aug 2005 12:37

Re: WGLC ent-analysis-03: DSTM

On Mon, 29 Aug 2005, Tim Chown wrote:
> On Mon, Aug 29, 2005 at 10:34:39AM +0300, Pekka Savola wrote:
>> I don't think the purpose of any v6ops document is solve problems in
>> one's *v4* network by *v4* mechanisms, so it's not entirely clear if
>> the mechanism is in the scope of this WG.
>
> If you deplay a v6-only network infrastructure then v4 transport is a 'v6
> problem'.   I guess he crux of your argument is
> a) why not run dual stack, even with v4+NAT
> b) why can't apps be updated to use IPv6

Depends on what you mean by 'dual stack'.  For this particular thread, 
I think my main arguments are:

  - if you want to run v6-only network but dual-stack hosts, that's 
fine, you can run stuff in v4-in-v6 tunnels -- for example, scenario 
a) or b.1) from the list below.  HOWEVER, I don't see why you [in 
practical scenarios] need mechanisms to give (very) temporary global 
v4 addresses on the nodes, and then take them away (e.g., c) or d) 
from the list below).  You can just deploy private v4 addresses if you 
have address shortage, or use more stable v4 global addresses.

  - the mechanisms which go beyond DHCPv4-like functions for address 
assignment on v4-in-v6 tunnels do not have any bits-on-the-wire 
interoperability requirements, and thus do not require 
standardization.  Such mechanisms can also be brittle and very 
implementation-specific, and I'd be hesitant to even try to encourage 
them.

  - the DSTM spec is not clear enough on its scope and intent and

(Continue reading)

headers

Tim Chown | 30 Aug 2005 11:24

Re: WGLC ent-analysis-03: DSTM

On Mon, Aug 29, 2005 at 01:37:18PM +0300, Pekka Savola wrote:
> On Mon, 29 Aug 2005, Tim Chown wrote:
> >On Mon, Aug 29, 2005 at 10:34:39AM +0300, Pekka Savola wrote:
> >>I don't think the purpose of any v6ops document is solve problems in
> >>one's *v4* network by *v4* mechanisms, so it's not entirely clear if
> >>the mechanism is in the scope of this WG.
> >
> >If you deplay a v6-only network infrastructure then v4 transport is a 'v6
> >problem'.   I guess he crux of your argument is
> >a) why not run dual stack, even with v4+NAT
> >b) why can't apps be updated to use IPv6
> 
> Depends on what you mean by 'dual stack'.  

Sorry, I meant 'on the wire'.  To agree that something 'DSTM-like' is
going to be necessary, we have to assume and agree that IPv6-only
infrastructures will be deployed where some nodes have to use IPv4
communications.   I think we agree on that.

> For this particular thread, I think my main arguments are:
> 
>  - if you want to run v6-only network but dual-stack hosts, that's 
> fine, you can run stuff in v4-in-v6 tunnels -- for example, scenario 
> a) or b.1) from the list below.  

So far so good :)

> HOWEVER, I don't see why you [in 
> practical scenarios] need mechanisms to give (very) temporary global 
> v4 addresses on the nodes, and then take them away (e.g., c) or d)

(Continue reading)

headers

Pekka Savola | 31 Aug 2005 08:22

Re: WGLC ent-analysis-03: DSTM

On Tue, 30 Aug 2005, Tim Chown wrote:
>> HOWEVER, I don't see why you [in
>> practical scenarios] need mechanisms to give (very) temporary global
>> v4 addresses on the nodes, and then take them away (e.g., c) or d)
>> from the list below).  You can just deploy private v4 addresses if you
>> have address shortage, or use more stable v4 global addresses.
>
> Well, there is a tradeoff.  You could run IPv4+NAT on all the nodes that
> need IPv4.   If you have enough IPv4 global addresses you could run stable
> permanent addresses on all those nodes.  Either of these could/should use
> tunnel setup and address allocation mechanisms that could also be used
> by something 'DSTM-like'.
>
> But if you have limited IPv4 global addresses, and would like to avoid NAT,
> then some form of dynamic, short-term addressing is desirable.  I guess the
> question then is how realistic a scenario is that?

Yes that's the question, and in addition, "is this something v6ops WG 
should be concerned about?"  I don't think that's given -- our 
business is (IMHO) not extending the life of (public) IPv4 addresses, 
becuase there are alternatives (get more addresses; use private 
addresses; use proxies)

If someone wants to create a clear specification how you do that, get 
a WG started or whatever, that's OK, but let's not discuss or 
recommend it here.

>>  - the DSTM spec is not clear enough on its scope and intent and
>> should not be referred to in a WG document.  My own take here is (if I
>> understand the intent of the spec) that we don't (anymore) require a

(Continue reading)

headers

Francis Dupont | 29 Aug 2005 12:00

Re: WGLC ent-analysis-03: DSTM

 In your previous mail you wrote:

   > => NAT is not a general solution: it doesn't work with embedded addresses.
   > So you have no real counter-argument.

   Yes, it doesn't work, but what I'm asking here is a reality check.

=> sorry but I am tired to discuss about this topics. You don't want
to consider cases where NATs cannot be used or where people don't want
to use NATs, and this point is obviously NOT in the scope of the WG.

   > => the purpose of the v6ops document is to help to solve problems,
   > not to enforce something. So as the previous scenario is credible
   > DTSM (i.e. c)) has to be referenced.

   I don't think the purpose of any v6ops document is solve problems in 
   one's *v4* network by *v4* mechanisms,

=> DSTM is not a *v4* mechanism.

   so it's not entirely clear if the mechanism is in the scope of this WG.

=> DSTM and relevant scenarios are, this discussion is not.

   I'm not sure I understand the implementation well enough to say 
   whether that would work or not

=> it works even the implementation way I discribed works only for
some kernels (for other kernels the PCB table has to be scanned
for instance because routes are not referenced by PCBs).

(Continue reading)

headers

Christian Huitema | 22 Aug 2005 20:37

RE: WGLC ent-analysis-03: DSTM


>    While DHCPv4 may or may not require minor tweaks (e.g., relating to
>    link-layer adaptation),
> 
> => using DHCPv4 over a tunnel is *not* a minor tweak.

Let see. Assume that you have a native IPv6 "site", over which you can
reliably send multicast packets. Assume that we have defined IPv6
multicast addresses that reach all the nodes within that scope. Then,
you can pretty much port DHCP and ARP over that scope, using the node's
IPv6 address instead of the Ethernet address. You obtain a basic "IPv4
over IPv6" solution. It is hard to be simpler than that.

Obviously, there are a few tricky issues. We need a payload type for
IPv4 (done) and another for ARP (not done). We need a way to properly
delineate the scope of the IPv6 "site", probably using an IPv6 prefix
that shall be configured on every node. We need to get the multicast
addresses registered, and probably registered in a way that attaches
them to the selected IPv6 prefix.

The design becomes a little bit harder if we cannot use multicast,
either because it is not reliable or because it creates too much
overhead. But there are solutions -- certainly simpler than doing IPv4
over ATM.

-- Christian Huitema

headers

Stig Venaas | 30 Aug 2005 11:42

Re: WGLC ent-analysis-03: DSTM

On Mon, Aug 22, 2005 at 11:37:21AM -0700, Christian Huitema wrote:
> 
> >    While DHCPv4 may or may not require minor tweaks (e.g., relating to
> >    link-layer adaptation),
> > 
> > => using DHCPv4 over a tunnel is *not* a minor tweak.
> 
> Let see. Assume that you have a native IPv6 "site", over which you can
> reliably send multicast packets. Assume that we have defined IPv6
> multicast addresses that reach all the nodes within that scope. Then,
> you can pretty much port DHCP and ARP over that scope, using the node's
> IPv6 address instead of the Ethernet address. You obtain a basic "IPv4
> over IPv6" solution. It is hard to be simpler than that.

Sounds quite a bit like 6over4 (:

Stig

headers

Pekka Savola | 23 Aug 2005 12:47

Issues of DHCPv4 over v4-in-v6 tunnel [RE: WGLC ent-analysis-03: DSTM]

I've changed the subject line, as a placeholder for future 
discussions..

On Mon, 22 Aug 2005, Christian Huitema wrote:
>>    While DHCPv4 may or may not require minor tweaks (e.g., relating to
>>    link-layer adaptation),
>>
>> => using DHCPv4 over a tunnel is *not* a minor tweak.
[...]
> The design becomes a little bit harder if we cannot use multicast,
> either because it is not reliable or because it creates too much
> overhead. But there are solutions -- certainly simpler than doing IPv4
> over ATM.

Well, we could have the same assumptions as DHCPv6 -- either 
multicast, or relays (certainly not just multicast).

But can't we just make the assumptions:
  1) the tunnel is point-to-point, so neither side performs ARP (so we 
may not need to define ARP), just throws the packets over.

  2) DHCPv4 server must reside at the tunnel end-point.

Isn't it then pretty much irrelevant which L2 addresses are used by 
the client (in the payload) as long as they're a good identifier in 
the DHCP server's database?

Note that I don't see modifications to DHCPv4 client or server 
software as a problem (but hopefully the changes should be minimized), 
because those sites wanting to deploy v6 dominant networks require

(Continue reading)

headers

Bound, Jim | 17 Aug 2005 12:59

RE: WGLC ent-analysis-03

Hi Pekka,

Others are responding to DSTM below are comments on other points for the
work. 

> Thank you for additional "textual" discussion of the matrix.  
> IMHO it is
> very useful.  While I am skeptic about the matrix approach, 
> modifying that
> goes beyond the point of diminishing returns.  In general, I think the
> document is in a very good shape, though Section 8 (which is a recent
> addition) still requires wider review.

Thanks.

> 1) I still think appendix is a bit inappropriate for this document,
> and it be removed from this doc.  (I did not review it at length.)

Authors feel it is important to keep and we have not seen any pain or
issue within the working group keeping an appendix.  

> 
> 2) [see separate mail on app vs network-driven]

Being responded to by others in the community and a few of the other
authors.

> 
> 3) [see separate mail on DSTM]

(Continue reading)

headers

Bound, Jim | 9 Aug 2005 21:26

RE: WGLC ent-analysis-03: DSTM

Fred,

It is not a strident attitude.  DSTM was work in the IETF for minimum
two years, has been deployed in test networks, and the response was the
authors response not Jim's response.

I think we need applicability around it for sure.

Please don't threaten me or the authors work because of a quick email
that I stated would have more serious follow up.  That is inappropriate
and I would like an apology for your assumption that was my intention?
I think you jumped the gun on the response.  We are not going to remove
DSTM at this time, first we would like to attempt applicability
statements.

Thanks for your input,
/jim 

> -----Original Message-----
> From: Fred Baker [mailto:fred@...] 
> Sent: Tuesday, August 09, 2005 2:58 PM
> To: Bound, Jim
> Cc: Pekka Savola; v6ops@...
> Subject: Re: WGLC ent-analysis-03: DSTM
> 
> Jim:
> 
> I don't think Pekka was saying that Dual-Stack as described in RFCs  
> 1933 and 2765 is not important to operators. I think that he was  
> saying that extending that to include an Experimental protocol that

(Continue reading)

headers

Bound, Jim | 8 Aug 2005 14:05

RE: WGLC ent-analysis-03

thanks for in depth review and comments.  Will respond to each point and
we highly appreciate your consistent review  of this spec and support we
are going to make it very clear in the final spec of your significant
contributions and logic check to us technically.  Sorry I am still
behind from all the IETF work.  Will catch up as I can.

THANK YOU BIG TIME.

/jim 

> -----Original Message-----
> From: owner-v6ops@... 
> [mailto:owner-v6ops@...] On Behalf Of Pekka Savola
> Sent: Friday, August 05, 2005 3:51 PM
> To: v6ops@...
> Subject: WGLC ent-analysis-03
> 
> Hi,
> 
> Thank you for additional "textual" discussion of the matrix.  
> IMHO it is
> very useful.  While I am skeptic about the matrix approach, 
> modifying that
> goes beyond the point of diminishing returns.  In general, I think the
> document is in a very good shape, though Section 8 (which is a recent
> addition) still requires wider review.
> 
> Flights are good at catching up on your reading list :)
> 
> substantial

(Continue reading)

headers

Bound, Jim | 8 Aug 2005 14:01

RE: WGLC ent-analysis-03: DSTM

We are not removing DSTM from this spec all the authors know for a fact
it is important to operators.  If you want further applicability
statements we can do that and there is other work in progress.

Thanks for you input,
/jim 

> -----Original Message-----
> From: owner-v6ops@... 
> [mailto:owner-v6ops@...] On Behalf Of Pekka Savola
> Sent: Friday, August 05, 2005 3:47 PM
> To: v6ops@...
> Subject: WGLC ent-analysis-03: DSTM
> 
> Hi,
> 
> (I'll put two most separable & possibly most discussable items in 
> separate mails.)
> 
> In 8.1:
> 
>   Later in the transition process, after the enterprise has
>   transitioned to a predominately IPv6 infrastructure, the architect
>   should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. Or
>   in the case of early deployment of IPv6-dominant networks DSTM can
>   be used too.
> 
> and in 8.4:
> 
> DSTM [DSTM, DSTM+] is a useful tunneling mechanism for later in the

(Continue reading)

headers

Fred Baker | 9 Aug 2005 20:58

Re: WGLC ent-analysis-03: DSTM

Jim:

I don't think Pekka was saying that Dual-Stack as described in RFCs  
1933 and 2765 is not important to operators. I think that he was  
saying that extending that to include an Experimental protocol that  
has specific algorithms attached to it that haven't been agreed to  
seems an odd recommendation from a working group document.

I think you need to take a little less strident attitude. Your  
commentary re DSTM sounds a little like "this is my protocol and you  
don't get to comment on it". If you can't find a way to accept  
Pekka's commentary, we may need to make this no longer be a working  
group draft, and advise the IESG to ensure that any RFC Editor path  
submission of it be published with a note stating that it was not  
agreed to by the relevant working group.

Lets find common ground here, guys.

Fred

On Aug 8, 2005, at 5:01 AM, Bound, Jim wrote:

> We are not removing DSTM from this spec all the authors know for a  
> fact
> it is important to operators.  If you want further applicability
> statements we can do that and there is other work in progress.
>
> Thanks for you input,
> /jim
>

(Continue reading)

headers

Bound, Jim | 8 Aug 2005 14:03

RE: WGLC ent-analysis-03: application vs network driven

Let us discuss this ok it is valid input.  But yes from our view the
enterprise will select how the network will be deployed but from two
vantage points.  One because they want to begin the infrastructure
deployment and IPv6 readiness, and two to support key applications they
want to operate over IPv6.  

thanks
/jim 

> -----Original Message-----
> From: owner-v6ops@... 
> [mailto:owner-v6ops@...] On Behalf Of Pekka Savola
> Sent: Friday, August 05, 2005 3:49 PM
> To: v6ops@...
> Subject: WGLC ent-analysis-03: application vs network driven
> 
> (I'll put two most separable & possibly most discussable 
> items in separate 
> mails.)
> 
> ==> the document seems to have been written based on the assumption 
> that first the enterprise decides which kind of network it will run 
> (dual-IP, v6-only) and whether its applications will be v6-only, 
> dual-IP or v4, and then takes a look at the surrounding 
> environment -- 
> and the result is often "oops.. we need translation, tunneling, and a 
> number of other complexities for our decision to be fulfilled".
> 
> In some cases, this approach may be appropriate (though I 
> hope this is

(Continue reading)