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

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Wed, 14 Apr 2004 23:37:09 +0200

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" <[email-masked]>
To: "JORDI PALET MARTINEZ" <[email-masked]>
Cc: <[email-masked]>; "Florent Parent" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; "Suresh Satapati" <[email-masked]>
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.

---

From: Alain Durand <[email-masked]>
Date: Wed, 14 Apr 2004 16:10:56 -0700

On Apr 14, 2004, at 2:37 PM, JORDI PALET MARTINEZ wrote:

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

Initially,  section 4 was 'simple mode' and was renamed 'non 
authenticated mode' by reference
to the fact that no specific authentication was required.
This is a left over from that time, thank you for pointing it.

Since then, others made the comment that is this mode is restricted to 
the IPv4 ISP customers,
there is already some kind of authentication in place at the IPv4 
layer, thus calling this
'non authenticated' is a bit of a misnomer...

Any suggestion for a alternate name would be welcome.

Actually, this raises another point. Are both modes (authenticated and 
non-authenticated) necessary?
Will ISPs be willing to deploy such tunnels in the mode described in 
section 4. especially
in light of the security considerations discussed in section 4.4?

Any feedback on this topic from operational ISP people would be greatly 
appreciated.

	- Alain.

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Thu, 15 Apr 2004 01:55:14 +0200

Hi Alain,

See my comments in-line.

Regards,
Jordi

----- Original Message ----- 
From: "Alain Durand" <[email-masked]>
To: "JORDI PALET MARTINEZ" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, April 15, 2004 1:10 AM
Subject: Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt

> authenticated mode' by reference
I know ;-)

> 'non authenticated' is a bit of a misnomer...

I'm not sure to catch this, but let me try ...
Well, in my opinion it depends on the usage done by each ISP deploying it. Some could be willing to keep the service open (even to non-own customers, as today happens with lot's of TBs). Following this rationale, this could support a kind of "anonymous" users (those that access the system with "anonymous/anonymous" user/password ?) or even supporting a mode that doesn't require for sending ANY user/password, right ? I still believe non-authenticated is fine in that case.

> Any suggestion for a alternate name would be welcome.

But if we are sure that we want to force a kind of "anonymous" authentication (request all the time a user/password but it could be anonymous/anonymous), then an alternative name could be "anonymous mode".

But may be entering in this kind of discussion is going too much further for a requirements document and should be part of the protocol itself ?

> in light of the security considerations discussed in section 4.4?

I think so. Actually is happening, and I feel is still important to allow it in the future to facilitate the deployment.