draft-durand-v6ops-assisted-tunneling-requirements-00.txt

["JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>]

Hi Alain,

I provide some new comments in-line.

I noticed that in 7.2 you kept "simple mode", probably should be changed to "non-authenticated" to avoid confusions.

Regards,
Jordi

----- Original Message ----- 
From: "Alain Durand" <Alain.Durand@Sun.COM>
To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
Cc: <carlw@mcsr-labs.org>; "Florent Parent" <florent.parent@hexago.com>; <shu@kddilabs.com>; <pekkas@netcore.fi>; <alain.baudot@francetelecom.com>; "Suresh Satapati" <satapati@cisco.com>
Sent: Monday, March 29, 2004 7:16 PM
Subject: Re: assisted tunneling requirement draft (fwd)


> Thank you Jordi for those valuable comments.
> See response inline.
> 
> - Alain.
> 
> On Mar 28, 2004, at 1:23 PM, JORDI PALET MARTINEZ wrote:
> 
> > Hi Pekka, Alain, all,
> >
> > One minor but important issue is using transition instead of migration.
> >
> > Following Pekka suggestions about our auto-discovery document to cover 
> > ISATAP, may make sense also here to reword " Although this negotiation 
> > phase can be automated, this remains fundamentally different from 
> > transition mechanisms like 6to4, teredo or isatap which do not involve 
> > any negotiation phase" ?
> 
> It remains to be proven that there is any benefit in trying to merge 
> all tunneling proposal.
> I, for one, remain very skeptical about this idea.
> Let's apply the right tool for the right problem.

Agree, it might become too much complicate, but Pekka insisted ;-)

> 
> 
> > 4. The Simple Mode is a non-authenticated service, may be we can call 
> > it "Anonymous" Mode (or non-authenticated), to make it more clearer ?
> 
> Good point.
> 
> > 4.2 I would say "This discovery must be automatic at least within an 
> > ISP network", instead of "This discovery must be automatic within an 
> > ISP network.".
> 
> I disagree fundamentally. This would broaden the scope of the problem 
> unnecessarily.
> Also, I'm not sure it would be good: That would transform the IPv4 ISP
> into a transit provider for the v6 ISP without him knowing it...

Well is a fact, it happens today. Anyway, I believe that adding the "at least" is not a "requirement" but opens new options. ISPs can always filter traffic (and some do).

> 
> The focus here is about tunnels brokered by the customer ISP. I think 
> this is a much simpler problem,
> much more useful, with a simple business case behind it.
> By focusing on this problem, I think we have a better chance to be 
> successful.
> This is a fundamental assumption in the draft.

Then I believe it must be further clarified that the goal is only IN the ISP. For example in 2, replace:
      - ISP is offering IPv6 connectivity to its customers initially
      using controlled tunneling infrastructure [ISP, 5.1 Steps in
      Transitioning Customer Connection Networks]
with
      - ISP is offering IPv6 connectivity to ONLY to its customers initially
      using controlled tunneling infrastructure [ISP, 5.1 Steps in
      Transitioning Customer Connection Networks]

BUT, my opinion is that doing so, we are creating two streams -> two drafts, as another one could be almost the same document, but to ensure that non-ISP-own customers could be covered. Instead, the non-authenticated mode already provides a way to do that, right ?

> 
> see also 6.7
> 
> 
> > 5.1 In my opinion DNS delegation is a must in this case (I mean as 
> > supported by the protocol).
> 
> Delegate what exactly? The reverse for the /48 or other prefix length?
> To whom? an address specified by the user? to what address exactly?
> (if the user does not know yet its prefix, there is a chicken and egg 
> problem,
> unless we pass only the lower 80 bits... which I think is adding extra 
> complexity
> for little benefits.
> 
> >
> > 5.2 Agree on 2831 as a must.
> >
> > 6.2 I don't agree with "must be able to abort immediately and display 
> > the customers a message explaining that no service is available". 
> > Instead, if there is another ISP offering the service, the customer 
> > should be informed about that, and have the possibility to use it, 
> > even if non-optimal.
> 
> Again, the focus is about tunnels brokered by the customer ISP.
> The concern is customer wants v6, ISP does not offer native yet but 
> tunnel,
> the user configures the tunnel and 6 month later, the ISP now offers 
> native,
> but the customer does not know and keep using the tunnel.
> Maybe I should clarify this.
> 
> 
> 
> 
> >
> > 6.5 In "A client MAY choose not to send those messages (for example on 
> > ISDN type links), but should then expect that the tunnel may be ...", 
> > I would use "... (specially for any kind of links were the users is 
> > billed by traffic) ...". This is considering GPRS and 3G networks more 
> > than ISDN/PSTN links. One option could be to allow configuring the 
> > periodicity of the keep alive messages.
> 
> For ISDN, the concern is not the traffic generated (very small), but 
> the fact that the line will have
> to be kept up active and the user will be billed by the minute.
> 
> > 6.7 Is lawful interception here to be also supported ?
> 
> As the focus is tunnels brokered by the customer ISP, this aspect
> is, I think, already covered.
> 
> 
> > 7.1 I will say "TSP or other existing TB implementations".
> 
> Good point.
> 
> > May be a 7.3 to mention ISATAP, same as for TSP and Teredo ?
> 
> Ok, tell me, why Isatap? I don't understand how it applies here?
> 
> 
> > I think we need to ensure that users with dynamic IPv4 address can use 
> > the service in both modes, but this can be added in a future version.
> 
> no, we have to do it now! It is covered in the simple mode by 4.3, we 
> just forgot to mention in in section 5.
> Thanks for catching this.
> 
> 
> 
> > Not sure if best name is "assisted tunneling" or "automatic tunneling 
> > set-up" ?
> 
> It is not really automatic... there is a protocol to help an 
> implementation configuring
> the tunnels. by I'm not hung up on names. I'll go with whatever the wg 
> would like.
> 
>


**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.