Subject: [v6tc] about automatic discovery of tunnel-endpoints

From: Prakash Jayaraman <[email-masked]>
Date: Mon, 07 Mar 2005 20:42:15 -0600

To continue the open-mike discussion of the tc bof, here are some 
thoughts about automatic discovery of tunnel end-points:

For simple maintenance of the dual-stack CPE devices, it will be a good 
idea to automatically discover tunnel endpoints based on some capabilities.

But I don't see how CPE (mobile/fixed) can do automatic-discovery of 
tunnel endpoints. It may be possible to automatically configure the 
dual-stack CPE using existing protocols.

Every access network has a "network access server" that participates in 
a AAA conversation with the CPE before admitting packets from the CPE 
into the ISP's network. If you choose the appropriate AAA framework 
(authentication methods, protocols, transport, backend servers), it is 
possible to ensure mutual authentication of server identity as well as 
CPE identity. A CPE device comes to know about the network access 
servers dynamically in a number of different ways. Some of them  depend 
on the link-layer (e.g. PPP) and some of them depend on the IP layer 
(e.g. DHCP).

I believe that "discovery of tunnel endpoints" would require some sort 
of capability exchange with NAS. In all cases, this is the only system 
that CPE devices are configured to discover automatically. Any 
subsequent dynamic configuration of the CPE device is done only through 
the NAS. This way automatic-tunnel-endpoint can be termed a "service".

Tunneling protocol itself can be application-specific or universal. It 
is independent of capability-negotiation.  Tunneling protocol may 
involve another AAA conversation, but it seems unnecessary.

- prakash

_______________________________________________
v6tc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/v6tc

---

From: "Miguel Angel Diaz" <[email-masked]>
Date: Tue, 8 Mar 2005 09:48:32 +0100

My coments in line

Regards
Miguel

----- Original Message ----- 
From: "Prakash Jayaraman" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, March 08, 2005 3:42 AM
Subject: [v6tc] about automatic discovery of tunnel-endpoints

> the NAS. This way automatic-tunnel-endpoint can be termed a "service".

AFAIK the final solution for tunnel endpoints (TEP) discovery should be based on the assumption that the CPE has already IPv4 connectivity (otherwise the tunnel has no sense), which means that the users is already authenticated in the ISP's network, so the capability exchange with NAS is not a must under this assumption.

The draft draft-palet-v6ops-tun-auto-disc-03.txt makes an analysis about the advantages/drawbacks to use current service discovery protocols as TEP discovery. Not all the protocols considered in such a draft are aligned with the previous assumption. Indeed some current protocols considered as TEP discovery candidates are layer-II dependant like PPP or DHCP, which means that some kind of data exchange with NAS might be required.

However even if some of these protocols were considered as the best solution for TEP discovery (which is unlikely at the being time) the discovery of the tunnel endpoints and the user's authentication process would be made together because new specific field for PPP and DHCP should be specified which would be exchanged along with the usual login/password/IP_addresses/etc fields in PPP or DHCP. So I guess that it wouldn't be necessary a specific data exchange phase with NAS to discover the nearest TEP. It would be included in the user's authentication process.

> involve another AAA conversation, but it seems unnecessary.

************************************
Barcelona 2005 Global IPv6 Summit
Call for Papers and information available 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: Tim Chown <[email-masked]>
Date: Tue, 8 Mar 2005 23:21:24 +0000

> AFAIK the final solution for tunnel endpoints (TEP) discovery should be based on the assumption that the CPE has already IPv4 connectivity (otherwise the tunnel has no sense), which means that the…

What are the common methods (if any?) for an ISP to inform a SOHO customer
of the correct SMTP server to use?  Seems the TEP could be made available 
by a similar method or channel?

(In the case of my ISP, I have to dig into ISP web support pages...)

Tim

---

From: Prakash Jayaraman <[email-masked]>
Date: Tue, 08 Mar 2005 15:55:12 -0800

The problem under discussion becomes simpler if there is some sort of
capability negotiation with the NAS to figure out which TEP to talk to.
The negotiation may be done during the authentication phase (if there
is one), during configuration phase (e.g. DHCP) or by using some other
negotiation protocol perhaps yet to be defined.

I believe that "auto discovery" applies more to the NAS than the CPE.
The question then becomes "how does the NAS come to know about the
TEP's in the provider's network without any static configuration"?
There are plenty of solutions for this, if everyone agrees on the
problem.  CPE is only involved with some sort of auto-configuration.

If CPE is to be involved in some sort of "discovery", we are running
into issues (and hence solutions) similar to those experienced by
service advertisement protocols and router advertisement protocols.

I have not read the draft you mention below, but I will read it and
send in my comments.

regards,

- prakash

- prakash

---

From: "Miguel Angel Diaz" <[email-masked]>
Date: Wed, 9 Mar 2005 08:16:27 +0100

----- Original Message ----- 
From: "Tim Chown" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 09, 2005 12:21 AM
Subject: Re: [v6tc] about automatic discovery of tunnel-endpoints

> (In the case of my ISP, I have to dig into ISP web support pages...)

I guess the SMTP discovery is an example of what TEP discovery doesn't have to be. In my case my ISP gives information about the SMTP server by sending a letter to the user. I have also the possibility to visit the ISP's support page to get information about the SMTP service. Anyway the user intervention is essential.

The TEP discovery should rely on auto-configuration in order to avoid manual intervention by users.

Regards
Miguel

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 09 Mar 2005 09:28:43 +0100

On Tue, 2005-03-08 at 23:21 +0000, Tim Chown wrote:

>> AFAIK the final solution for tunnel endpoints (TEP) discovery should
>be based on the assumption that the CPE has already IPv4 connectivity
> (otherwise the tunnel has no sense), which means that the users is
> already authenticated in the ISP's network, so the capability exchange
> with NAS is not a must under this assumption.

Fun part on depending on the NAS is that that would again require people
to upgrade their NAS equipment and their CPE's, then they could just as
well directly try to get it to be upgraded to native connectivity.

>(In the case of my ISP, I have to dig into ISP web support pages...)

Thus finding a real interresting service like kazaa, google, ebay,
gmail, hotmail, msn and many many more is easier than finding out the
SMTP hostname (granny: "what is that a hostname?" "what is SMTP?") of
your own ISP.

I am starting to wonder what is so bad about anycast again, except that
there will be a need for many anycast blocks depending on how many
configuration services will be picked or promptly newly invented.

I'll finish up the .service draft and post it to dnsops later today.

Greets,
 Jeroen

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 11 Mar 2005 08:11:33 -0600

Hi Prakash, all,

The I-D that Miguel Angel indicated is a ³short version².

If you like to read a more complete one in addition, I encourage you (and
all the participants of this list), to read:

http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-tun-auto-disc-pre-
03.txt

Comments welcome also on this one ;-)

Regards,
Jordi

De: Prakash Jayaraman <[email-masked]>
Organización: Net.Com
Responder a: <[email-masked]>
Fecha: Tue, 08 Mar 2005 15:55:12 -0800
Para: <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: [v6tc] about automatic discovery of tunnel-endpoints

> AFAIK the final solution for tunnel endpoints (TEP) discovery should be based
> on the assumption that the CPE has already IPv4 connectivity (otherwise the
> tunnel has no sense), which means that the users is already authenticated in
> the ISP's network, so the capability exchange with NAS is not a must under
> this assumption.
>   
The problem under discussion becomes simpler if there is some sort of
capability negotiation with the NAS to figure out which TEP to talk to. The
negotiation may be done during the authentication phase (if there is one),
during configuration phase (e.g. DHCP) or by using some other negotiation
protocol perhaps yet to be defined.

I believe that "auto discovery" applies more to the NAS than the CPE. The
question then becomes "how does the NAS come to know about the TEP's in the
provider's network without any static configuration"? There are plenty of
solutions for this, if everyone agrees on the problem.  CPE is only involved
with some sort of auto-configuration.

If CPE is to be involved in some sort of "discovery", we are running into
issues (and hence solutions) similar to those experienced by service
advertisement protocols and router advertisement protocols.

I have not read the draft you mention below, but I will read it and send in
my comments.

regards,
- prakash

>  
> The draft draft-palet-v6ops-tun-auto-disc-03.txt makes an analysis about the
> advantages/drawbacks to use current service discovery protocols as TEP
> discovery. Not all the protocols considered in such a draft are aligned with
> the previous assumption. Indeed some current protocols considered as TEP
> discovery candidates are layer-II dependant like PPP or DHCP, which means that
> some kind of data exchange with NAS might be required.
> 
> However even if some of these protocols were considered as the best solution
> for TEP discovery (which is unlikely at the being time) the discovery of the
> tunnel endpoints and the user's authentication process would be made together
> because new specific field for PPP and DHCP should be specified which would be
> exchanged along with the usual login/password/IP_addresses/etc fields in PPP
> or DHCP. So I guess that it wouldn't be necessary a specific data exchange
> phase with NAS to discover the nearest TEP. It would be included in the user's
> authentication process.
> 
> 
>   
>  
>>  
> 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.
> 
> 
>   
>  
> 
> 
>